AWS IAM

팀원이 늘고 자동화도 붙는데 같은 액세스 키를 여러 곳에서 돌려 쓰면, 사고가 나도 누가 어떤 권한으로 무엇을 했는지 추적하기 어렵습니다. 서비스마다 필요한 권한만 좁혀 주지 못하면 작은 스크립트 하나가 계정 전체 위험으로 번집니다.

AWS 초기에는 루트 계정 키를 그대로 코드에 넣어 배포하거나, 팀원끼리 같은 액세스 키를 돌려 쓰는 일이 흔했습니다. 실제로 개발자가 루트 키를 GitHub에 커밋해 공개 리포지토리에 노출된 사고가 반복됐고, 공격자가 그 키로 수십 분 안에 수백 대의 EC2 인스턴스를 띄워 채굴에 동원한 사례도 보고됐습니다. 퇴사자의 액세스 키를 회수하지 않아 몇 달 뒤에야 비정상 과금을 발견한 팀도 있었습니다. 이런 사고가 쌓이면서, 고정 키 대신 임시 자격증명을 쓰고, 사람과 서비스를 역할 단위로 나눠 필요한 권한만 부여하는 모델이 필요해졌습니다. IAM은 그 압력에서 나온 결과로, '기본적으로 아무것도 허용하지 않고 명시적으로 열어주는' 방식을 AWS 계정의 기본 보안 모델로 자리잡게 했습니다.

IAM은 사용자, 그룹, 역할, 정책을 분리해두는 방식으로 최소 권한 원칙을 구현합니다. 사람은 사용자 계정을 통해 콘솔과 CLI에 접근하고, 공통 권한은 그룹으로 묶어 사용자에 붙입니다. 서비스는 사람 계정 대신 역할을 맡아 임시 자격증명으로 필요한 리소스에만 접근합니다. 이 구조 덕분에 Lambda 함수는 S3 읽기 권한만 있는 역할을 부여받고 그 이상은 시도조차 할 수 없게 됩니다. 정책은 JSON으로 어떤 서비스의 어떤 작업을 어떤 리소스에 허용할지 명시하므로, 필요한 범위 이상을 열어줬는지 코드처럼 검토하고 관리할 수 있습니다. 이 분리 구조가 없으면 공유 키 하나가 유출될 때 계정 전체가 노출되지만, 역할과 최소 정책이 조합되면 사고 범위가 그 역할에 허용된 작업으로만 제한됩니다.

IAM과 Cognito는 둘 다 인증처럼 보이지만 대상이 다릅니다. IAM은 AWS 계정 안의 사람과 서비스 권한을 다루고, Cognito는 애플리케이션 최종 사용자의 로그인과 토큰 발급을 다룹니다. 콘솔·CLI·서비스 역할 권한이 문제면 IAM을 보고, 앱 사용자 가입과 로그인 흐름이 문제면 Cognito를 보면 됩니다.

CI/CD 파이프라인에서 배포 역할을 만들어 S3 업로드와 CloudFront 무효화만 허용하고, 그 외 작업은 차단하는 구성이 흔합니다. 개발자에게는 스테이징 환경의 특정 리소스만 접근할 수 있는 정책을 부여하고 프로덕션은 별도 승인 절차를 거치도록 분리하기도 합니다. Lambda 함수가 DynamoDB 테이블 하나만 읽게 하거나, EC2 인스턴스가 특정 S3 버킷에만 쓸 수 있게 역할을 좁히면, 해당 리소스가 침해되더라도 피해가 그 범위 안에서 멈춥니다. 최종 사용자 로그인 흐름을 직접 제공하거나 데이터 암호화 키 자체를 관리하는 계층은 아닙니다.