클라우드 IAM 최소 권한은 역할 이름이 아니라 사용 흔적으로 만든다

Developer, PowerUser, OpsAdmin 같은 역할 이름은 업무를 설명할 뿐 실제 권한을 보장하지 않는다. 복사된 관리형 정책, 와일드카드 자원, 오래된 서비스 계정이 쌓이면 역할 하나가 수백 개 작업을 허용할 수 있다. 반대로 무작정 권한을 삭제하면 야간 배치나 재해복구 때만 필요한 작업이 실패한다.

최소 권한은 한 번의 정리 프로젝트가 아니라 관측, 축소, 검증, 예외 만료를 반복하는 운영 루프다.

사람과 워크로드를 먼저 분리한다

사람 계정과 애플리케이션 계정은 수명과 인증 방식이 다르다.

구분	기본 원칙
일반 사용자	SSO, 짧은 세션, 역할 기반 접근
관리자	별도 권한 상승, 강한 인증, 사유 기록
CI/CD	저장소·환경별 신뢰 조건, 단기 토큰
서버·컨테이너	인스턴스·워크로드 ID, 정적 키 금지
외부 공급자	전용 역할, 계정·리소스 제한, 만료
비상 접근	봉인된 절차, 사용 경보, 사후 검토

장기 액세스 키를 발급해 비밀 저장소에 넣는 방식보다 클라우드의 워크로드 아이덴티티와 연합 인증을 우선 사용한다. 키가 불가피하면 소유자, 용도, 마지막 사용, 회전·폐기일을 관리한다.

계정·기기·워크로드를 신원 중심으로 나누는 상위 설계는 제로 트러스트의 출발점은 네트워크가 아니라 신원 경계다, 관리자 인증 강화 순서는 피싱 저항 MFA 전환 로드맵과 함께 점검할 수 있다.

사용 흔적으로 권한 후보를 만든다

권한 분석에는 최소 30~90일 등 업무 주기를 포함하는 기간이 필요할 수 있다. 월말, 분기 결산, 장애 대응처럼 드문 작업이 있기 때문이다. 기간은 시스템 특성에 맞춰 정한다.

1. 현재 정책과 신뢰 관계를 수집한다.
2. 실제 API 호출·자원·리전·조건을 집계한다.
3. 사용되지 않은 작업과 자원을 축소 후보로 표시한다.
4. 복구·배치·비상 절차의 드문 권한을 소유자와 확인한다.
5. 경고 또는 시뮬레이션으로 영향 범위를 검증한다.
6. 작은 그룹에서 정책을 적용하고 거부 로그를 관찰한다.
7. 안정화 후 조직 전체로 확대한다.

“사용되지 않음”은 삭제 근거이지 자동 삭제 명령은 아니다. 로그 누락, 다른 계정의 대리 호출, 제어 평면과 데이터 평면 차이를 확인해야 한다.

정책을 작업·자원·조건으로 좁힌다

최소 권한은 Action만 줄이는 것이 아니다.

• 작업: 읽기, 쓰기, 삭제, 권한 변경을 분리한다.
• 자원: 전체 계정이 아니라 프로젝트·버킷·키·테이블로 좁힌다.
• 조건: 환경, 태그, 리전, 네트워크, 기기 신뢰, 세션 속성을 사용한다.
• 시간: 상시 권한 대신 승인된 기간에만 활성화한다.
• 경로: 사람이 직접 운영 API를 호출하지 않고 배포 파이프라인을 거치게 한다.

와일드카드가 필요한 서비스도 있다. 그 경우 왜 필요한지, 어떤 조건으로 피해 범위를 제한했는지, 언제 다시 검토할지 남긴다.

적시 권한 상승(JIT)

고위험 작업은 상시 역할에 넣지 않고 요청 기반으로 제공한다.

request:
  role: production-database-operator
  scope: project-a/prod
  reason: incident INC-4821
  duration_minutes: 60
  approver_group: oncall-security
controls:
  require_mfa: true
  require_managed_device: true
  record_session: where_supported
  alert_on_activation: true
  revoke_automatically: true

승인자가 같은 작업의 직접 실행자와 항상 동일하면 견제 효과가 약해질 수 있다. 조직 규모에 맞춰 독립 승인을 두되, 긴급 상황에서 지연되지 않도록 비상 경로와 사후 검토를 설계한다.

서비스 계정과 신뢰 정책

워크로드 역할의 권한 정책만 보고 끝내면 안 된다. 누가 그 역할을 맡을 수 있는지 정하는 신뢰 정책이 더 위험할 수 있다.

• 저장소, 브랜치, 환경, 배포 워크플로를 신뢰 조건에 포함한다.
• 외부 계정 신뢰에는 정확한 계정·역할과 외부 ID를 사용한다.
• 조직 전체 또는 모든 서비스 주체를 허용하는 신뢰를 피한다.
• 역할 연쇄를 추적해 간접 권한 상승 경로를 찾는다.
• 서비스 계정 생성·키 발급 권한을 제한한다.
• 권한 정책과 신뢰 정책 변경을 모두 경보한다.

탐지 신호

• 관리자·권한 위임·정책 편집 작업의 갑작스러운 증가
• 새 장기 키 생성, 오래된 키 사용 재개, 키의 지역·IP 변화
• 평소 사용하지 않던 리전·서비스의 API 호출
• 광범위한 List, Get, Export 뒤의 대량 데이터 접근
• 역할 신뢰 주체, 외부 계정, 조건 삭제 변경
• 권한 축소 배포 후 AccessDenied 급증
• 소유자 없는 서비스 계정과 장기간 미사용 역할
• 비상 권한 사용 후 사후 검토 미완료

거부 로그는 공격 신호이면서 권한 축소 품질 신호다. 정책 변경 직후 특정 정상 작업만 실패하면 롤백 또는 정교화가 필요하고, 여러 계정에서 탐색성 호출이 반복되면 침해를 의심한다.

안전한 축소와 롤백

권한 정책은 버전 관리하고 이전 버전으로 빠르게 되돌릴 수 있게 한다. 단, 전체 관리자 정책을 임시로 붙이는 롤백은 피한다.

1. 대상 사용자·워크로드를 작은 범위로 선택한다.
2. 정책 시뮬레이션과 테스트 환경 실행을 수행한다.
3. 운영 적용 전에 대응 담당자와 롤백 명령을 준비한다.
4. 거부 로그와 핵심 업무 지표를 관찰한다.
5. 실패한 작업에 필요한 최소 권한만 추가한다.
6. 임시 추가 권한에는 만료와 후속 티켓을 둔다.

정기 검토 체크리스트

• 사람·워크로드·외부 공급자 계정이 구분돼 있는가.
• 장기 키 대신 연합 인증과 단기 자격 증명을 사용하는가.
• 권한 분석 기간이 월말·분기·복구 작업을 포함하는가.
• 작업뿐 아니라 자원과 조건이 제한돼 있는가.
• 관리자 권한이 적시 승인과 자동 만료로 제공되는가.
• 신뢰 정책과 역할 연쇄를 검토하는가.
• 미사용 권한·역할·키에 소유자와 폐기 기한이 있는가.
• 정책 축소 후 거부 로그와 업무 장애를 확인하는가.

참고 기준

• CISA Zero Trust Maturity Model
• AWS IAM Access Analyzer
• Google Cloud Policy Intelligence
• Microsoft Entra Access Reviews
• CIS Critical Security Controls

결론

최소 권한은 역할을 새로 이름 짓는 일이 아니라 실제 사용을 근거로 상시 권한을 줄이고 필요한 순간에만 권한을 제공하는 일이다. API 사용 기록, 거부 로그, 신뢰 정책, 예외 만료를 같은 루프에서 관리하면 보안과 운영 안정성을 동시에 지킬 수 있다.