IAM — Identity and Access Management

IAM(Identity and Access Management)은 AWS의 모든 보안의 출발점입니다. 아무리 잘 설계된 인프라도 잘못된 권한 설정 하나가 전체를 무너뜨릴 수 있습니다. 2019년 Capital One 데이터 유출 사고는 IAM Role 설정 오류로 EC2 인스턴스가 S3의 모든 버킷에 접근할 수 있었던 것이 원인이었습니다. 이처럼 IAM은 단순한 설정이 아니라 보안 아키텍처의 핵심입니다.

IAM은 크게 4가지 개념으로 이루어집니다: 누구인가(Principal), 무엇을 할 수 있는가(Permission), 어디에(Resource), 어떤 조건에서(Condition) — 이 4가지가 모여 하나의 IAM Policy를 구성합니다.

이미지 출처: © Amazon Web Services, Inc. — How IAM works (교육 목적 인용)

이 챕터에서는 실제로 IAM User를 만들고, Group으로 묶어 권한을 관리하고, EC2가 S3에 접근할 수 있도록 Role을 설정하는 실습을 중심으로 진행합니다.

IAM User, Group, Role의 차이

IAM User는 특정 사람 또는 서비스를 위한 장기(Long-term) 자격증명입니다. 이름·비밀번호·Access Key를 가지며, AWS 콘솔 로그인이나 CLI 사용에 쓰입니다. 팀원 A에게 IAM User를 만들어 주면 그 사람만의 독립적인 AWS 접근 자격이 생깁니다.

IAM Group은 IAM User의 집합입니다. Group에 Policy(권한)를 붙이면 Group에 속한 모든 User가 그 권한을 자동으로 상속받습니다. 예를 들어 Developers Group에 S3 읽기 권한을 부여하면, 개발자 5명 모두가 S3를 읽을 수 있습니다. 나중에 개발자가 추가되면 Group에 넣기만 하면 됩니다.

IAM Role은 사람이 아니라 서비스(EC2, Lambda)나 외부 계정이 가정(Assume)하는 임시(Short-term) 자격증명입니다. EC2 인스턴스가 S3에 파일을 업로드해야 할 때, 코드 안에 Access Key를 하드코딩하는 것은 매우 위험합니다. 대신 EC2에 S3WriteRole을 부착하면, EC2는 자동으로 임시 자격증명을 얻어 S3에 접근할 수 있습니다.

모범 사례: Lambda, EC2, ECS Task는 모두 User가 아닌 Role을 사용해야 합니다. Role은 자동으로 교체되는 임시 자격증명을 사용하므로, 누출되어도 만료 시간이 짧습니다.

IAM Policy: 권한의 언어

IAM Policy는 JSON 형식으로 작성된 권한 명세서입니다. 모든 Policy에는 Statement 배열이 있고, 각 Statement는 Effect(Allow/Deny), Action(무엇을), Resource(어디에) 세 가지 핵심 요소를 가집니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
      }
    }
  ]
}

위 Policy는 '특정 IP 대역에서 my-bucket 버킷 안의 모든 객체에 대해 읽기·쓰기를 허용한다'는 뜻입니다. AWS는 Default Deny 원칙을 사용합니다. 명시적으로 Allow하지 않은 모든 것은 기본적으로 거부됩니다. 또한 하나라도 Explicit Deny가 있으면 Allow보다 우선합니다.

Policy 유형은 크게 2가지입니다.

• AWS Managed Policy: AWS가 사전에 정의한 Policy (AdministratorAccess, AmazonS3ReadOnlyAccess 등). 빠르게 권한을 부여할 때 편리하지만 필요 이상으로 권한이 넓을 수 있습니다.

• Customer Managed Policy: 직접 만드는 Policy. 최소 권한 원칙을 적용하기에 적합합니다.

최소 권한 원칙(Least Privilege): 반드시 필요한 권한만 부여하고, 나머지는 모두 거부하는 원칙입니다. 처음에는 넓은 권한으로 시작해도 되지만, 프로덕션에서는 IAM Access Analyzer를 사용해 실제로 사용 중인 권한만 남기고 나머지를 제거해야 합니다.

MFA와 보안 모범 사례

MFA(Multi-Factor Authentication)는 비밀번호 외에 추가 인증 요소를 요구하는 보안 장치입니다. Google Authenticator나 Authy 같은 TOTP 앱, 또는 YubiKey 같은 하드웨어 토큰을 사용합니다. Root User와 관리자 권한 User에는 반드시 MFA를 활성화해야 합니다.

Access Key는 AWS CLI나 SDK를 사용할 때 필요한 Access Key ID + Secret Access Key 쌍입니다. 몇 가지 주의사항:

• Secret Access Key는 생성 시 딱 한 번만 볼 수 있습니다. 잃어버리면 새로 만들어야 합니다.

• Access Key를 GitHub 같은 공개 저장소에 절대 커밋하지 마세요. AWS는 자동으로 탐지하고 이메일을 보내지만, 그 사이에 이미 비용이 청구될 수 있습니다.

• EC2·Lambda에서는 Access Key 대신 IAM Role을 사용하세요.

• Access Key는 주기적으로 교체(Rotate)하세요.

AWS 보안 모범 사례 체크리스트:

• ✅ Root User에 MFA 활성화
• ✅ Root User Access Key 삭제
• ✅ 일상 작업용 IAM User 생성
• ✅ 필요한 서비스(EC2, Lambda)에 Role 적용
• ✅ CloudTrail 활성화 (모든 API 호출 기록)
• ✅ Access Analyzer로 외부 접근 가능한 리소스 감사