AWS IAM 개요

AWS IAM 은 AWS 리소스(EC2, S3, RDS 등)에 대한 접근 권한을 안전하게 제어하기 위한 서비스입니다. 클라우드 서비스를 처음 접하면 EC2, S3, ECS 같은 서버 및 배포 서비스들 위주로 학습하게 되고, IAM은 관심 없는 분들이 종종 있었습니다. 소규모 조직일수록 구축과 배포에 초점을 맞추기 때문에 더 그런 것 같습니다. 그런 분들을 대상으로 포스팅해보았습니다.

 

1. IAM 이란

S3를 파일서버로 사용하는 EC2 백엔드가 있습니다. 개발환경과 운영환경을 나누어 S3도 각각 구성했습니다. 개발자는 실수로 개발환경 백엔드 앱에서 운영 S3 주소를 사용했습니다. 모든 테스트 데이터가 운영환경에 반영 되어 데이터가 오염되었습니다. 작은 규모에서는 배포 전 주의 요소를 체크리스트로 관리 가능하지만, 규모가 커질수록 개발 담당자가 변경되기도하고 사이드 이펙트가 발생하여 안전한 배포를 보장하기 힘든 환경이 되어가고 있습니다.

 

또 다른 예로 IAM 사용자를 전사적으로 몇 개만 사용하는 조직이 있습니다. 웹 콘솔 접근, ECR과 통합된 CI/CD 과정, 각종 서버에서 AWS 자격 증명을 모두 "Admin" 이라고 불리는 슈퍼 계정 하나에서 발급하여 구성하고 있습니다. 이 문제는 보안의 심각성 뿐만 아니라 해결하기 위해 오랜 시간이 걸릴 것입니다.

 

위의 간단한 상황은 AWS 서비스들간의 접근 권한 관리가 체계적으로 이루어지지 않아 발생하는 보안취약 및 잠재적인 오류 위험 상황입니다. IAM은 AWS 서비스들(EC2, RDS, ...)의 접근 권한을 안전하게 제어하기 위한 서비스입니다. 단순히 웹 콘솔에 접근하는 관리자나 개발자 계정별 접근권한을 관리하는 것을 넘어 AWS의 어떤 서비스가 다른 어떤 서비스로부터 무엇을 할 수 있는지와 같은 세분화된 관리 체계를 제공합니다.

2. 구성 요소들

IAM의 구성요소는 [작업], [정책], [역할], [사용자], [사용자 그룹] 입니다. 각 관계를 도식화하면 아래와 같습니다.

 

2-1. 작업(Action)과 정책(Policy) - 무엇을 하는지

AWS의 모든 서비스에는 서비스별 작업목록이 존재합니다. 해당 서비스와 관련된 모든 작업들의 모음입니다. 예를들어 S3:PutObject  작업은 S3에 객체를 업로드 할 수 있습니다. 정책은 이러한 작업 배열을 허용하거나 거부하며 생성합니다. 만약 ec2:* (EC2의 모든)작업을 허용하는 정책을 생성하면 이 정책을 보유한 역할은 EC2 서비스의 모든 작업을 할 수 있습니다. 하지만 같은 대상이 ec2 작업을 거부하는 역할을 동시에 보유하면 명시적인 거부 정책이 우선되어 작업이 거부됩니다.

 

작업들은 AWS 인프라 전반에서 사용할 수 있는 모든 작업을 담고있기 때문에 모두 검토하기 불가능한 수준입니다. 일반적으로 사용되는 EC2의 작업들은 나열(197), 읽기(44), 쓰기(451), 권한 관리(16), 태그 지정(2)로 총 710개 작업이 있습니다. 그래서 AWS에서는 일반적인 요구사항에서 필요할법한 작업을 모아 1천여 개의 정책을 미리 등록해두었습니다. 이를 AWS 관리형 정책이라고 합니다. 반대로 고객이 커스텀해서 정책을 구성하는 경우 고객 관리형 정책입니다.

 

2-2. 역할(Role)과 사용자(User) - 누가 하는지

이런 정책들은 역할에 다대다(n:m) 맵핑됩니다. 예를들어 비용과 관련된 Billing 서비스의 정책들은 아마도 사내 super-admin-role 과 같은 역할이 가지고 있을만합니다.

사용자는 조직 구성원별 홍길동 계정, 김철수 계정과 같이 구성할하거나 ECR에 도커 레지스트리를 업로드하기 위한 사용자 ecr-uploader 같은 논리적인 사용자를 만들수도 있습니다. 이러한 사용자가 생성될 때마다 각각 역할을 부여하기 번거롭기 때문에 [사용자 그룹]을 만들어 사용자 그룹에 역할을 부여해두면 추후 사용자를 그룹에만 할당하여 모든 역할을 부여합니다. 사용자 그룹은 보통 developer, admin, ... 등등으로 구성가능합니다. 또한 역할은 정책뿐만 아니라 작업을 바로 연결 할수도 있습니다. 이를 인라인 정책이라고 합니다.

 

3. ID 제공 업체

CLI나 애플리케이션에서 AWS에 접근할 때 전통적으로는 IAM 사용자를 생성하고 Access Key ID와 Secret Access Key를 발급받아 사용합니다. 하지만 이 방식은 장기적으로 키를 노출하거나 깃 저장소/시크릿에 남겨 두면 보안 위험이 있으므로 정기적인 키 로테이션(90일권장)이 필요합니다.

이를 대신해 AWS는 STS(Security Token Service)와 OIDC(OpenID Connect) 표준을 결합한 임시 보안 자격증명 방식을 제공합니다. 예를 들어 GitHub Actions 같은 CI/CD 플랫폼과 OIDC를 연동하면, 파이프라인은 GitHub가 발행한 ID 토큰을 사용해 AWS STS에서 만료되는 임시 자격증명(AccessKeyId, SecretAccessKey, SessionToken) 을 발급받습니다. 이렇게 하면 장기 비밀키를 저장할 필요가 없어 보안 위험을 크게 줄일 수 있습니다. 이와 관련된 경험은 별도 포스팅으로 정리할 계획입니다.