AWS를 사용하면서 가장 자주 만나는 오류 중 하나는 "Access Denied"입니다. 권한이 없다는 메시지입니다. IAM(Identity and Access Management)은 "누가 무엇을 할 수 있는가"를 결정하는 AWS의 핵심 보안 서비스입니다. 이 글에서는 IAM의 기본부터 고급 개념까지 쉽게 설명합니다.
IAM 기본 구성 요소
회사의 출입 관리 시스템을 상상해보세요. 직원들은 각자 사원증(사용자)을 가지고 있고, 부서별로 다른 구역에 출입할 수 있습니다. IAM도 같은 구조입니다.
사용자(User)는 AWS에 접근하는 개인이나 애플리케이션입니다. 각 사용자는 고유한 자격 증명(비밀번호 또는 액세스 키)을 가집니다.
그룹(Group)은 사용자들을 묶어서 같은 권한을 한 번에 부여하는 단위입니다. "개발팀" 그룹을 만들어서 모든 개발자에게 동일한 권한을 부여하면, 새 개발자가 들어올 때 그룹에 추가만 하면 됩니다. 중요한 점은 그룹 안에 그룹을 넣을 수 없다는 것입니다.
역할(Role)은 사람이 아닌 AWS 서비스나 외부 사용자에게 임시로 권한을 부여합니다. EC2 인스턴스가 S3 버킷에 접근해야 할 때, 접근 키를 인스턴스에 넣는 대신 역할을 부여합니다. 역할은 만료 시간이 있는 임시 자격 증명을 발급합니다.
정책(Policy)은 "어떤 서비스의 어떤 액션을 어떤 리소스에 허용하거나 거부한다"는 규칙을 JSON 형식으로 적은 문서입니다.
정책의 종류
IAM에는 여러 종류의 정책이 있습니다. 각각 다른 목적과 적용 방식이 있습니다.
자격 증명 기반 정책(Identity-based Policy)은 사용자, 그룹, 역할에 부착합니다. "이 사람(또는 서비스)이 무엇을 할 수 있는가"를 정의합니다. AWS 관리형 정책(AWS Managed Policy)과 고객 관리형 정책(Customer Managed Policy)이 있습니다.
리소스 기반 정책(Resource-based Policy)은 S3 버킷, SQS 큐, KMS 키 등 리소스 자체에 부착합니다. "이 리소스에 누가 접근할 수 있는가"를 정의합니다. 자격 증명 기반 정책과 달리 Principal(접근 주체)을 명시해야 합니다. 다른 계정의 사용자에게 직접 접근을 허용할 때 유용합니다.
권한 경계(Permission Boundary)는 사용자나 역할이 가질 수 있는 최대 권한의 한도를 설정합니다. 마치 "이 범위 안에서만 권한을 부여할 수 있다"는 울타리를 치는 것입니다. 예를 들어, 팀장에게 IAM 사용자를 만들 권한을 주었지만, 팀장이 자신보다 높은 권한을 가진 사용자를 만들지 못하게 제한할 때 사용합니다.
SCP(Service Control Policy)는 이전 글에서 설명한 Organizations 수준의 제한입니다.
| 정책 유형 | 부착 대상 | 주요 특징 | |-----------|----------|----------| | Identity-based | 사용자, 그룹, 역할 | 자격 증명이 무엇을 할 수 있는지 정의 | | Resource-based | S3, SQS, KMS 등 리소스 | Principal 지정 필요, 크로스 계정 가능 | | Permission Boundary | 사용자, 역할 | 최대 허용 권한의 상한선 | | SCP | OU, 계정 | 조직 수준 제한, 관리 계정에 미적용 |
정책 평가 로직 — 접근 허용 여부 결정 방식
이것이 IAM에서 가장 어렵고 중요한 부분입니다. AWS는 요청이 들어오면 여러 정책을 검토해서 허용 여부를 결정합니다.
핵심 규칙은 세 단계입니다. 첫 번째로, 명시적 거부(Explicit Deny)가 있으면 무조건 거부합니다. 다른 어떤 허용 정책이 있어도 Deny가 하나라도 있으면 접근이 차단됩니다. 두 번째로, 명시적 허용(Explicit Allow)이 있고 Deny가 없으면 허용합니다. 세 번째로, 아무 정책도 없으면 묵시적 거부(Implicit Deny)입니다. AWS에서는 기본적으로 모든 것이 거부입니다.
같은 계정 안에서의 규칙: 자격 증명 기반 정책 또는 리소스 기반 정책 중 하나라도 허용하면 접근이 가능합니다(합집합).
다른 계정 간의 규칙: 자격 증명 기반 정책과 리소스 기반 정책 모두 허용해야 접근이 가능합니다(교집합). 한쪽에만 허용이 있어도 거부됩니다.
실제 상황 예를 들어봅시다. 개발자 A에게 S3 버킷에 대한 읽기 허용 정책이 있습니다. 그런데 접근이 거부됩니다. 왜일까요? 가능한 원인으로는 SCP에서 S3 서비스를 차단, Permission Boundary에서 S3 접근을 제외, S3 버킷의 리소스 기반 정책에서 명시적 거부, VPC 엔드포인트 정책에서 차단 등이 있습니다.
시험 핵심: "Allow 정책이 있는데 접근이 거부된다면?" 하면 명시적 Deny가 어딘가에 있는지 확인(SCP, Permission Boundary, 리소스 기반 정책)이 정답입니다.
MFA — 이중 인증으로 계정 보호하기
비밀번호만으로 계정을 보호하는 것은 충분하지 않습니다. 비밀번호가 유출되면 계정이 바로 탈취됩니다. MFA(Multi-Factor Authentication)는 비밀번호 외에 추가 인증 수단을 요구합니다. ATM에서 카드와 비밀번호를 동시에 필요로 하는 것과 같습니다.
MFA 유형은 세 가지입니다. 가상 MFA 디바이스는 스마트폰 앱(Google Authenticator, Authy 등)입니다. 30초마다 바뀌는 6자리 코드를 생성합니다. 하드웨어 MFA 디바이스는 YubiKey 같은 물리적 디바이스입니다. U2F 보안 키는 USB에 꽂는 FIDO 표준 보안 키입니다.
IAM 정책에서 MFA를 강제할 수 있습니다. aws:MultiFactorAuthPresent 조건 키를 사용해서 MFA 없이는 특정 작업을 거부하는 정책을 만들 수 있습니다. 예를 들어 "MFA 없이는 EC2 인스턴스를 삭제할 수 없다"는 정책을 만들 수 있습니다.
루트 계정에는 특히 MFA를 반드시 활성화해야 합니다. 루트 계정은 AWS 계정의 모든 권한을 가지므로 최고 수준으로 보호해야 합니다.
시험 핵심: "MFA를 설정하지 않은 사용자의 API 호출을 차단하려면?" 하면 IAM 정책에 aws:MultiFactorAuthPresent 조건 추가가 정답입니다.
페더레이션 — 외부 계정으로 AWS 로그인하기
회사 직원들이 이미 Active Directory 계정을 가지고 있습니다. AWS에 접속할 때마다 별도의 AWS IAM 계정을 만들지 않고 기존 회사 계정을 그대로 사용하고 싶습니다. 이것이 페더레이션(Federation)입니다.
SAML 2.0 페더레이션은 기업 환경에서 가장 많이 사용합니다. 회사의 Active Directory 또는 ADFS(Active Directory Federation Services)와 AWS를 연동합니다. 직원들이 회사 SSO 포털에 로그인하면, STS AssumeRoleWithSAML을 통해 임시 AWS 자격 증명이 발급되고 AWS 콘솔에 접근할 수 있습니다.
OIDC 페더레이션은 모바일 앱이나 웹 앱에서 Google, Facebook, Apple 계정으로 로그인한 후 AWS 리소스에 접근하는 방식입니다. Amazon Cognito가 이 과정을 간소화해줍니다.
AWS IAM Identity Center(구 AWS SSO)는 여러 AWS 계정에 대한 중앙 집중식 SSO를 제공합니다. 한 번 로그인으로 권한이 있는 모든 계정의 콘솔에 접근할 수 있습니다. Organizations와 통합되어 있고, Permission Sets로 계정별 권한을 관리합니다. 멀티 계정 환경에서 가장 권장되는 방식입니다.
시험 핵심: "회사 Active Directory 사용자가 AWS 콘솔에 접근하려면?" 하면 SAML 2.0 페더레이션 또는 IAM Identity Center가 정답입니다.
IAM Access Analyzer — 외부에 노출된 리소스 찾기
어느 날 S3 버킷이 전 세계 누구나 접근할 수 있도록 공개되어 있다는 것을 발견했습니다. 언제부터 그랬는지, 다른 리소스는 괜찮은지 확인해야 합니다. IAM Access Analyzer가 이런 상황을 자동으로 찾아줍니다.
IAM Access Analyzer는 외부(다른 계정 또는 인터넷)에서 접근 가능한 리소스를 자동으로 분석합니다. 자물쇠를 잠그지 않은 문을 찾아주는 보안 점검 도구입니다.
분석 대상 리소스는 S3 버킷 정책, IAM 역할의 신뢰 정책, KMS 키 정책, SQS 큐 정책, Lambda 함수 정책, Secrets Manager 비밀 정책입니다.
외부에서 접근 가능한 리소스가 발견되면 "Finding"을 생성합니다. Finding을 검토해서 의도된 공유이면 "보관(Archive)"으로 처리하고, 의도하지 않은 공개이면 정책을 수정해서 접근을 차단합니다.
Access Analyzer에는 추가 기능도 있습니다. 정책 생성 기능은 CloudTrail 로그를 분석해서 실제로 사용된 권한만 포함하는 최소 권한 정책을 자동으로 만들어줍니다. 정책 검증 기능은 IAM 정책의 문법 오류나 모범 사례 위반을 체크합니다.
시험 핵심: "S3 버킷이 외부에 공개되어 있는지 자동으로 확인하려면?" 하면 IAM Access Analyzer가 정답입니다.
서비스 연결 역할 (Service-Linked Roles)
AWS 서비스들이 다른 AWS 리소스를 관리하기 위해 자동으로 생성하는 특별한 역할입니다. Auto Scaling이 EC2 인스턴스를 생성하고 종료하려면 권한이 필요한데, 이를 위해 서비스 연결 역할이 자동으로 만들어집니다.
사용자가 직접 수정하거나 삭제하기 어렵고, 해당 서비스만 이 역할을 사용할 수 있습니다. Auto Scaling, ElastiCache, RDS, CloudFormation 등 많은 서비스가 서비스 연결 역할을 사용합니다.
액세스 키 관리
프로그램이 AWS API를 직접 호출할 때는 비밀번호 대신 액세스 키(Access Key ID + Secret Access Key)를 사용합니다. AWS CLI 사용, SDK 호출, 서버에서 직접 API 호출할 때 필요합니다.
액세스 키 관리 모범 사례입니다. 사용자당 최대 2개의 액세스 키를 만들 수 있습니다(교체할 때 잠깐 두 개가 공존하도록). 정기적으로 키를 교체(로테이션)해야 합니다. 루트 계정의 액세스 키는 만들지 않거나 즉시 삭제합니다. IAM Credential Report를 생성하면 모든 사용자의 액세스 키 사용 현황과 마지막 사용 날짜를 확인할 수 있습니다.
STS 임시 자격 증명
AWS STS(Security Token Service)는 만료 시간이 있는 임시 자격 증명을 발급합니다. 장기 자격 증명(액세스 키)보다 안전합니다.
AssumeRole은 같은 계정이나 다른 계정의 역할을 맡아서 임시 자격 증명을 얻습니다.
AssumeRoleWithSAML은 SAML 기반 페더레이션에서 사용합니다.
AssumeRoleWithWebIdentity는 OIDC 기반 페더레이션(Google, Facebook 등)에서 사용합니다.