클라우드 환경에서 보안 사고를 이야기할 때 방화벽, 취약점, 악성코드 같은 기술적 통제를 먼저 떠올리기 쉽다. 그러나 실제 클라우드에서는 누가 어떤 리소스에 어떤 권한으로 접근할 수 있는지를 결정하는 IAM(Identity and Access Management)이 보안의 중심에 가깝다.
온프레미스 환경에서는 네트워크 경계와 서버 계정이 접근 통제의 중요한 기준이었다. 반면 클라우드에서는 사용자뿐 아니라 애플리케이션, 가상머신, 컨테이너, 자동화 도구 같은 워크로드도 각각 하나의 신원으로 동작한다. 이 신원에 역할과 정책이 연결되고, 그 정책이 특정 계정·프로젝트·구독·리소스에 적용된다.
문제는 IAM이 단순히 “사용자에게 권한을 주는 기능”이 아니라는 점이다. 신원, 역할, 정책, 리소스 범위, 상속, 조건, 임시 자격 증명 등이 서로 결합되어 최종 권한을 결정한다. 따라서 설정 하나가 잘못되면 예상보다 훨씬 넓은 범위의 접근 권한이 만들어질 수 있다.
- 클라우드 IAM의 기본 구조
- IAM 권한은 어떻게 결정되는가
- 권한 설정 오류가 자주 발생하는 원인
- 권한 오류가 위험한 이유
- 기업에서 IAM을 운영할 때 필요한 통제
- 실무자 관점
- 결론
1. 클라우드 IAM의 기본 구조
IAM 구조는 클라우드 서비스마다 명칭에 차이가 있지만 기본 개념은 비슷하다. 일반적으로 다음 다섯 요소로 이해할 수 있다.
| 구성 요소 | 의미 | 예시 |
|---|---|---|
| 신원 또는 보안 주체 | 접근을 요청하는 사용자나 시스템 | 사용자, 그룹, 애플리케이션, 서비스 계정, 워크로드 |
| 역할 | 여러 권한을 업무 단위로 묶은 집합 | 읽기 전용, 운영자, 관리자 |
| 정책 | 어떤 행동을 허용하거나 제한할지 정의하는 규칙 | 특정 API 실행 허용, 특정 리소스 접근 제한 |
| 리소스 | 실제 접근 대상 | 가상머신, 스토리지, 데이터베이스, 키 관리 서비스 |
| 범위 | 역할이나 정책이 적용되는 영역 | 조직, 계정, 구독, 프로젝트, 리소스 그룹, 개별 리소스 |
가장 단순하게 표현하면 IAM은 다음 질문에 답하는 체계다.
누가 → 어떤 권한으로 → 어떤 리소스에 → 어떤 조건에서 접근할 수 있는가
여기서 중요한 것은 사용자만 신원이 아니라는 점이다. 클라우드에서는 애플리케이션이나 자동화 프로그램도 API를 호출하고 데이터를 읽거나 인프라를 변경한다. 따라서 사람의 계정뿐 아니라 워크로드 신원과 서비스 계정 역시 동일한 수준으로 관리해야 한다.
2. IAM 권한은 어떻게 결정되는가
신원과 인증
사용자나 시스템이 클라우드에 접근하려면 먼저 자신이 누구인지 증명해야 한다. 기업 환경에서는 계정을 클라우드마다 별도로 생성하기보다 사내 IdP(Identity Provider)와 연동해 통합 인증 또는 페더레이션을 사용하는 경우가 많다.
인증이 완료되었다고 해서 모든 리소스에 접근할 수 있는 것은 아니다. 인증은 “누구인지 확인하는 과정”이고, 인가는 “무엇을 할 수 있는지 결정하는 과정”이다.
역할과 정책
사용자나 워크로드에는 직접 권한을 하나씩 부여하기보다 역할이나 정책을 연결하는 방식이 일반적이다. 예를 들어 운영 담당자에게 가상머신 조회와 재시작 권한은 필요할 수 있지만 IAM 정책 변경이나 결제 계정 관리 권한까지 필요하지는 않을 수 있다. 이 경우 업무에 필요한 권한만 포함된 역할을 부여하는 것이 최소 권한 원칙에 부합한다.
문제는 편의를 위해 관리자 역할처럼 범위가 큰 권한을 사용하기 시작하면서 발생한다. 처음에는 테스트나 긴급 작업을 위해 부여했던 권한이 그대로 남아 장기간 사용되는 경우도 많다.
리소스 범위와 상속
IAM에서 특히 이해하기 어려운 부분이 범위와 상속이다. 클라우드 환경은 일반적으로 조직, 계정이나 구독, 프로젝트나 리소스 그룹, 개별 리소스처럼 계층적으로 구성된다. 상위 범위에 권한을 부여하면 하위에 있는 여러 리소스에 동일한 권한이 적용될 수 있다.
예를 들어 특정 스토리지 하나만 관리하면 되는 사용자에게 프로젝트 전체 범위의 관리자 역할을 부여하면 실제 업무 범위를 넘어 다른 리소스까지 변경할 수 있게 된다. 따라서 역할의 종류뿐 아니라 그 역할이 어느 범위에 적용되는지까지 함께 확인해야 한다.
3. 권한 설정 오류가 자주 발생하는 원인
1) 업무 편의를 위해 과도한 역할을 부여하는 경우
가장 흔한 문제는 필요한 권한을 세부적으로 정의하기 번거롭다는 이유로 관리자나 소유자처럼 강력한 역할을 부여하는 것이다. 개발이나 운영 초기에는 빠르게 문제를 해결할 수 있지만, 시간이 지나면서 누가 왜 그 권한을 가지고 있는지 파악하기 어려워진다.
최소 권한 원칙은 처음부터 완벽한 정책을 작성해야 한다는 의미라기보다, 실제 사용 권한을 확인하면서 지속적으로 불필요한 권한을 제거해 나가는 방식으로 이해하는 것이 현실적이다.
2) 역할은 적절하지만 적용 범위가 너무 넓은 경우
역할 자체가 위험하지 않아 보여도 범위를 잘못 선택하면 권한이 크게 확대될 수 있다. 예를 들어 특정 프로젝트만 관리해야 하는 사용자에게 조직 전체 범위의 역할이 부여되면 여러 프로젝트와 리소스에 동일한 권한이 전달될 수 있다.
특히 상위 정책이 하위 리소스로 상속되는 구조에서는 개별 리소스의 설정만 확인해서는 실제 유효 권한을 판단하기 어렵다. 따라서 IAM 점검에서는 항상 Role과 Scope를 하나의 세트로 확인해야 한다.
3) 사용자에게 권한을 직접 계속 부여하는 경우
초기에는 몇 명 되지 않아 사용자별로 직접 권한을 부여해도 관리가 가능하다. 그러나 조직이 커지면 사용자에게 직접 연결된 권한이 계속 쌓인다. 부서 이동이나 직무 변경이 발생했을 때 새 권한은 추가되지만 기존 권한은 제거되지 않는 현상을 권한 누적 또는 권한 크리프(Privilege Creep)라고 부를 수 있다.
이 문제를 줄이려면 사용자 개인보다는 업무 역할을 기준으로 그룹을 만들고, 그룹과 역할을 연결하는 구조가 관리하기 쉽다.
4) 서비스 계정과 워크로드 신원을 사람 계정보다 느슨하게 관리하는 경우
애플리케이션, 배치 프로그램, CI/CD, 서버리스 함수, 가상머신 역시 클라우드 리소스에 접근하기 위해 권한이 필요하다. 실무에서는 사람 계정에는 MFA와 퇴사자 계정 회수 절차를 적용하면서도 서비스 계정에는 장기간 사용하는 비밀키나 액세스 키를 남겨두는 경우가 있다.
이런 자격 증명이 소스코드, 설정 파일, 배포 스크립트 등에 노출되면 공격자는 사용자 로그인 없이 API를 통해 클라우드에 접근할 수 있다. 가능하다면 장기 키보다 역할 기반의 임시 자격 증명이나 워크로드 신원 체계를 사용하는 편이 안전하다.
5) 퇴사·부서 이동·프로젝트 종료 후 권한이 남는 경우
IAM의 위험은 새 권한을 잘못 부여할 때만 생기는 것이 아니다. 프로젝트가 종료되거나 담당자가 변경되었는데 기존 역할, 그룹 멤버십, 서비스 계정, 액세스 키가 그대로 남아 있으면 관리되지 않는 권한이 계속 증가한다.
정기적인 Access Review가 필요한 이유도 여기에 있다. 권한 검토에서는 단순히 “계정이 존재하는가”만 확인할 것이 아니라 다음을 함께 확인해야 한다.
- 현재 업무에 필요한 권한인가
- 최근 실제 사용된 권한인가
- 상위 그룹을 통해 추가 권한을 받고 있지 않은가
- 서비스 계정이나 자동화 계정의 소유자가 명확한가
- 장기 미사용 역할과 자격 증명이 남아 있지 않은가
6) 사용자 정의 역할과 자동화 정책이 지나치게 넓은 경우
클라우드 IAM은 세밀한 권한 제어를 위해 사용자 정의 역할이나 정책을 제공한다. 그러나 여러 작업을 한 번에 허용하기 위해 와일드카드나 광범위한 API 권한을 사용하면 향후 서비스 기능이 추가되거나 정책이 재사용될 때 의도하지 않은 권한까지 포함될 수 있다.
또한 Terraform 같은 IaC나 배포 자동화에서 잘못된 IAM 설정이 템플릿으로 만들어지면 하나의 실수가 여러 계정이나 프로젝트로 반복 배포될 수 있다. 자동화는 수동 설정 오류를 줄일 수 있지만, 잘못된 정책을 빠르게 확산시킬 수도 있다는 점을 고려해야 한다.
4. 권한 오류가 위험한 이유
IAM 권한 오류는 그 자체로 즉시 사고를 발생시키지 않을 수도 있다. 그러나 계정이나 워크로드가 침해되었을 때 공격자가 사용할 수 있는 범위를 크게 넓힌다.
예를 들어 읽기 권한만 가진 계정이 탈취되면 정보 조회 수준에 머물 수 있지만, 관리자 권한이 부여된 계정이 탈취되면 다음과 같은 행동이 가능해질 수 있다.
- 중요 데이터 조회 또는 삭제
- 신규 계정이나 역할 생성
- 보안 설정 변경
- 로그 또는 모니터링 설정 변경
- 외부 계정에 접근 권한 부여
- 클라우드 리소스 생성 및 비용 발생
- 추가 자격 증명 확보를 통한 권한 확대
결국 IAM에서 중요한 것은 “계정이 탈취되지 않도록 하는 것”만이 아니라 계정이 탈취되더라도 피해 범위를 제한하는 것이다. 이 관점에서 최소 권한과 범위 제한은 예방 통제인 동시에 침해 사고의 영향도를 줄이는 통제다.
5. 기업에서 IAM을 운영할 때 필요한 통제
최소 권한을 기본값으로 사용
사용자와 워크로드에는 업무 수행에 필요한 최소 권한만 부여해야 한다. 특히 관리자나 소유자 역할은 예외적으로 관리하고, 일반 업무 계정과 관리자 작업 계정을 분리하는 것이 좋다.
사용자보다 그룹과 역할 중심으로 관리
직원 개인에게 직접 권한을 부여하면 시간이 지날수록 구조가 복잡해진다. 직무 또는 업무 기능별 그룹을 만들고 그룹에 역할을 연결하면 입사, 이동, 퇴사 시 권한 변경을 보다 일관되게 관리할 수 있다.
상위 범위의 권한을 최소화
조직, 관리 그룹, 구독, 프로젝트처럼 상위 레벨에 부여된 권한은 하위 리소스까지 광범위하게 영향을 줄 수 있다. 가능하면 필요한 가장 좁은 범위에서 역할을 부여하고, 상위 범위의 관리자 권한은 별도로 검토해야 한다.
장기 자격 증명을 줄이고 임시 권한을 활용
사람과 워크로드 모두 가능하다면 장기간 유지되는 비밀번호나 액세스 키보다 페더레이션, 역할 기반 접근, 임시 자격 증명을 사용하는 것이 바람직하다. 관리자 권한이 필요한 경우에도 상시 관리자 계정보다는 필요할 때 일정 시간 동안만 권한을 활성화하는 JIT(Just-In-Time) 방식이 위험을 줄이는 데 도움이 된다.
정기적인 권한 검토
IAM은 한 번 설정한 뒤 끝나는 영역이 아니다. 조직과 업무는 계속 변하기 때문에 정기적으로 다음 항목을 확인해야 한다.
- 미사용 사용자와 서비스 계정
- 장기 미사용 역할
- 불필요한 관리자 권한
- 상위 범위에 부여된 역할
- 사용자에게 직접 부여된 예외 권한
- 오래된 액세스 키와 비밀 정보
- 외부 조직 또는 다른 계정에 대한 접근 권한
변경 로그와 분석 기능 활용
대부분의 주요 클라우드는 IAM 정책 변경과 권한 사용 기록을 로그로 남길 수 있고, 과도한 권한이나 외부 공개 가능성을 분석하는 기능도 제공한다. IAM 점검을 엑셀 목록만으로 수행하기보다 실제 사용 기록과 정책 변경 이력을 함께 확인하면 불필요한 권한을 찾는 데 도움이 된다.
6. 실무자 관점
현장에서 IAM을 어렵게 만드는 가장 큰 원인은 기능 부족보다 운영 책임과 권한 기준이 명확하지 않은 것인 경우가 많다. 예를 들어 보안 부서는 최소 권한을 요구하지만 운영 부서는 장애 대응을 이유로 넓은 권한을 원할 수 있다. 개발자는 배포 편의를 위해 관리자 역할을 요구하고, 담당자가 바뀐 뒤에도 기존 권한이 그대로 유지되기도 한다.
이 문제를 기술 설정만으로 해결하기는 어렵다. 기업에서는 최소한 다음 세 가지 기준을 정해 둘 필요가 있다.
첫째, 어떤 직무가 어떤 클라우드 역할을 받을 수 있는지 역할 기준을 정의해야 한다. 둘째, 관리자 권한이나 예외 권한에는 승인자와 만료 시점을 지정해야 한다. 셋째, 정기적인 권한 재검토에서 단순 계정 목록이 아니라 사용자·그룹·역할·범위·상속 관계를 함께 검토해야 한다.
특히 멀티클라우드 환경에서는 각 클라우드의 IAM 명칭과 정책 구조가 다르기 때문에 “AWS 관리자”, “Azure 소유자”, “Google Cloud 프로젝트 권한”을 각각 따로 관리하기보다 기업 차원의 공통 권한 모델을 먼저 정의한 뒤 각 플랫폼 역할에 매핑하는 방식이 효율적이다.
IAM의 목표는 모든 사용자에게 불편을 주는 것이 아니라, 필요한 업무는 수행할 수 있으면서 불필요한 권한은 남지 않도록 만드는 것이다.
7. 결론
클라우드 IAM은 사용자 계정 관리 기능이 아니라 클라우드 전체의 접근 권한을 결정하는 핵심 보안 체계다. IAM의 실제 권한은 사용자 하나만 확인해서 판단할 수 없다. 신원, 그룹, 역할, 정책, 리소스 범위, 상속 관계, 서비스 계정, 임시 자격 증명 같은 요소가 함께 작동한다.
권한 설정 오류는 대부분 복잡한 해킹 기법보다 운영 편의, 넓은 역할, 잘못된 범위, 미정리 권한, 장기 자격 증명처럼 일상적인 관리 과정에서 발생한다.
필요한 신원에, 필요한 역할을, 필요한 범위에서, 필요한 기간 동안만 부여하고 지속적으로 검토한다.
클라우드 환경이 커질수록 IAM은 단순 계정 관리가 아니라 전체 보안 아키텍처의 중심 통제로 다뤄야 한다.