IAM 거버넌스

담당 역할: IAM/보안 엔지니어

권한 거버넌스는 클라우드 보안 사고의 가장 흔한 근본 원인이다. 정체성(identity)이 전통적인 네트워크 경계를 대체하면서, 누가 접근하는지 관리·감시·통제하는 방식 자체를 다시 설계해야 한다는 공감대가 업계에 형성되어 있다. 멀티클라우드 환경은 문제를 더 어렵게 만든다 — AWS는 정책 기반, Azure Entra ID는 사용자 중심, GCP IAM은 리소스 중심 모델을 쓴다.

• 최소권한(Least Privilege): 사람·워크로드·서비스 계정에게 업무에 필요한 만큼만 권한을 줘라. “일단 넉넉하게 주고 나중에 줄이자”는 실제로 거의 일어나지 않는다. 최초 설계 단계부터 최소로 시작하라.

• Just-In-Time(JIT) 접근: 상시 권한을 없애고, 필요한 시점에만 시한부로 권한을 부여하라. Azure의 PIM(Privileged Identity Management)이 대표 구현이다.

• Zero Trust: 암묵적 신뢰를 두지 말고 모든 것을 명시적으로 검증하며 항상 최소권한을 강제하라. NIST SP 800-207이 표준 근거이며, NIST CSF 2.0은 Govern·Identify·Protect·Detect·Respond·Recover 전 기능에 아이덴티티 거버넌스를 통합한다.

• 비인간 신원(Non-Human Identity) 관리: 서비스 계정·워크로드 아이덴티티·CI/CD 파이프라인도 사람과 똑같이 최소권한·주기 검토의 대상이다. 장기 자격증명(access key)을 없애고 단기 토큰(OIDC 등)으로 바꿔라.

• 지속적 접근 검토(Continuous Access Review): 권한을 한 번 부여하고 끝내지 마라. AI 보조 리스크 스코어링을 포함해 왜 아직도 이 권한이 필요한지 주기적으로 재검증하라.

1. 1단계 — 중앙 아이덴티티 통합 — 모든 계정·구독·프로젝트가 하나의 IdP로 SSO 인증하도록 통합하라. 클라우드별 개별 계정은 첫 단계에서 금지하라.

2. 2단계 — 장기 자격증명 제거 — IAM 사용자와 정적 액세스 키를 단계적으로 폐기하라. 사람은 SSO 연동 임시 자격증명으로, 워크로드는 OIDC 연동 또는 인스턴스 역할로 전환하라.

3. 3단계 — 역할(Role) 카탈로그 설계 — 업무 기능 단위로 표준 역할을 설계하고, 개인별 커스텀 정책을 금지하라. 역할은 최소권한에서 시작해 실제 필요가 증명될 때만 확장하라.

4. 4단계 — JIT 승격 체계 도입 — 관리자급 권한이 필요한 작업은 상시 부여 대신 신청·승인 기반 시한부 승격으로 전환하라.

5. 5단계 — 비인간 신원 인벤토리화 — 서비스 계정·CI/CD 역할·서드파티 통합의 전체 목록을 만들고 권한 범위와 사용 여부를 정기 검토하라.

6. 6단계 — 지속적 접근 검토 자동화 — 분기 단위 수동 검토를 넘어, 미사용 권한을 자동 탐지·알림하는 CIEM 도구를 도입하라.

이 원칙은 “권한을 주고 통제로 막는다”가 아니라 “애초에 권한 자체를 주지 않아 물리적으로 불가능하게 만든다”는 사고 전환이다.

① 읽기 전용 IAM을 통한 위임 경계 구조화 — AI 에이전트나 외부 협력자에게 “이만큼만 해라”고 지시하는 대신, ViewOnlyAccess 정책만 부여해 쓰기 액션 자체를 원천 봉쇄하라. 실행은 관리자 권한을 가진 사람만 하도록 역할을 분리하라.

② Plan-Apply 권한분리(Two-Atlantis 패턴) — Terraform 자동화 도구를 plan 전용/apply 전용 두 인스턴스로 물리 분리하고, 각각 별도 IAM role을 부여하라. PR 작성자가 plan 단계 실행 환경을 완전히 장악해도, 탈취 가능한 최대 권한은 plan 수준을 넘지 못한다. apply 실행은 리뷰어의 승인과 명시적 코멘트라는 2단계 인간 승인 게이트를 통과해야 트리거된다.

③ Declarative Policy를 통한 조직 레벨 통제 — 앞 두 사례가 행위자 단위의 권한 축소라면, AWS Organizations의 선언형 정책은 같은 원칙을 리소스 설정 상태 단위로 적용한 조직 레벨 버전이다. “VPC 오너가 알아서 잘 설정하겠지”라는 개별 계정 신뢰 모델을 “조직이 설정을 강제하고 오너의 변경권 자체를 뺏는다”는 중앙 강제 모델로 바꾼다.

• 모든 사용자가 중앙 IdP를 통해 SSO로 인증하는가, 클라우드별 개별 계정이 남아 있지 않은가?

• 정적 IAM 액세스 키가 조직 전체에서 제거되었는가, 또는 제거 계획이 있는가?

• 관리자급 권한이 상시 부여가 아니라 JIT 승격으로 관리되는가?

• 서비스 계정·CI/CD 역할의 전체 인벤토리가 존재하고 주기적으로 검토되는가?

• IaC 배포 파이프라인에서 plan과 apply의 IAM 권한이 분리되어 있는가?

• 권한 신청·승인 프로세스가 문서화되어 있고, 신청 입구는 넓게·승인 출구는 엄밀하게 설계되어 있는가?

• “일단 AdministratorAccess로”: 긴급 배포 압박 속에서 임시로 전체 권한을 주고 그대로 방치하는 것이 가장 흔한 사고 원인이다.

• 개인별 커스텀 정책을 남발한다: 표준 역할 대신 개인 요청마다 새 정책을 만들면, 시간이 지날수록 아무도 전체 권한 지형을 파악할 수 없다.

• 서비스 계정을 감사 대상에서 뺀다: 사람 계정만 정기 검토하고 서비스 계정·자동화 역할은 방치하는 경우가 많다. 실제로는 서비스 계정이 더 강력한 권한을 갖는 경우가 흔하다.

• JIT 승격 승인이 병목이 된다: 승인이 너무 느리면 엔지니어는 공유 계정이나 상시 권한 같은 우회 경로를 찾는다. 그러면 거버넌스는 무력화된다.