AWS IAM

AWS Identity and Access Management; AWS IAM
AWS 자원에 누가(인증) 무엇을 할 수 있는지(권한 부여)를 정하는 AWS의 자격 증명·접근 관리 서비스. 사용자, 그룹, 역할, 정책으로 권한을 표현한다.

AWS에 들어오는 모든 API 요청은 IAM을 거친다. 콘솔 클릭, CLI 명령, 애플리케이션의 SDK 호출 모두 결국 "이 보안 주체(principal)가 이 리소스에 이 작업을 해도 되는가"를 IAM 정책으로 판정받는다. 기본값은 거부이고, 정책이 명시적으로 허용해야 요청이 통과한다. 일반 개념으로서의 자격 증명 관리는 IAM 문서를 참조한다.

핵심 개념

구성 요소	설명	자격 증명
루트 사용자	계정을 만들 때 쓴 이메일로 로그인하는 사용자. 모든 권한을 가진다.	이메일과 암호(장기)
IAM 사용자	계정 안에 만든 개별 사용자	콘솔 암호, 액세스 키(장기)
IAM 사용자 그룹	사용자 묶음. 그룹에 정책을 붙이면 소속 사용자가 권한을 받는다. 그룹은 중첩할 수 없고 정책의 보안 주체가 될 수 없다.	없음
IAM 역할	특정 사람에게 묶이지 않은 권한 묶음. 신뢰된 주체가 수임(assume)해서 쓴다.	임시 자격 증명(STS 발급)
정책	허용·거부 규칙을 적은 JSON 문서	해당 없음

루트 사용자

루트 사용자는 계정의 모든 자원과 결제에 무제한 접근할 수 있으므로 일상 작업에 쓰지 않는다.

강력한 암호와 MFA를 설정한다. 가능하면 패스키나 보안 키 같은 피싱 방지 MFA를 쓴다.
루트 사용자 액세스 키는 만들지 않는다.
루트 사용자로만 할 수 있는 작업(독립 계정의 이메일·루트 암호 변경, 독립 계정 해지, 일부 결제 작업, 모든 보안 주체를 막아 버린 S3 버킷 정책이나 SQS 정책 삭제 등)이 필요할 때만 로그인한다.
AWS Organizations를 쓰면 멤버 계정의 루트 자격 증명을 중앙에서 제거하고, 필요한 루트 작업은 관리 계정에서 대신 수행할 수 있다.

IAM 사용자

IAM 사용자는 이름과 장기 자격 증명을 가진다. 현재 AWS는 사람은 AWS IAM Identity Center나 외부 ID 공급자 페더레이션으로 임시 자격 증명을 받아 쓰고, 워크로드는 IAM 역할을 쓰는 것을 권장한다. 장기 액세스 키가 꼭 필요한 경우(타사 도구 등)에는 MFA를 걸고 키를 주기적으로 교체하며, 쓰지 않는 사용자와 키는 지운다.

IAM 정책

구분	자격 증명 기반 정책	리소스 기반 정책
연결 대상	사용자, 그룹, 역할	S3 버킷, SQS 대기열, KMS 키, Lambda 함수, 역할(신뢰 정책) 등
Principal 요소	없음(붙은 대상이 주체)	필수(누구에게 허용하는지 명시)
교차 계정	상대 계정 리소스 정책도 허용해야 함	다른 계정 주체를 직접 지정 가능
형태	관리형 또는 인라인	항상 인라인(리소스에 내장)

관리형 정책과 인라인 정책

AWS 관리형 정책: AWS가 만들고 갱신한다. 여러 주체에 재사용한다. 출발점으로 쓰되 대개 권한이 넓다.
고객 관리형 정책: 직접 만들어 여러 주체에 붙인다. 버전 관리가 된다. 최소 권한 구현의 주된 수단이다.
인라인 정책: 특정 사용자·그룹·역할 하나에만 들어가는 정책. 주체를 지우면 같이 지워진다. 엄격한 1:1 관계가 필요할 때만 쓴다.

정책 예시

S3 버킷 하나에 대해 객체 읽기만 허용하고, 회사 IP 대역이 아니면 거부하는 자격 증명 기반 정책이다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::example-reports",
        "arn:aws:s3:::example-reports/*"
      ]
    },
    {
      "Sid": "DenyOutsideOffice",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {"aws:SourceIp": "203.0.113.0/24"}
      }
    }
  ]
}

정책 평가 로직

① 기본은 암묵적 거부다. 루트 사용자만 예외다.
② 적용되는 모든 정책(SCP·RCP, 리소스 기반 정책, 자격 증명 기반 정책, 권한 경계, 세션 정책) 가운데 명시적 Deny가 하나라도 있으면 최종 거부다.
③ AWS Organizations의 SCP(주체 쪽)와 RCP(리소스 쪽)가 허용하지 않으면 거부다.
④ 같은 계정 안에서는 자격 증명 기반 정책 또는 리소스 기반 정책 중 하나만 허용해도 된다(합집합).
⑤ 권한 경계와 세션 정책이 있으면 그 범위 안에 있어야 한다(교집합).

교차 계정 접근은 양쪽 모두 허용해야 한다. 요청자 계정의 자격 증명 기반 정책이 허용하고, 리소스 계정의 리소스 기반 정책(또는 역할 신뢰 정책)도 허용해야 한다.

권한 경계

권한 경계(permissions boundary)는 사용자나 역할이 가질 수 있는 최대 권한을 정하는 관리형 정책이다. 권한을 주지는 않고 상한만 둔다. 개발자에게 "역할을 직접 만들 권한"을 주되, 만드는 역할에 특정 경계를 반드시 붙이게 하여 자기 권한보다 큰 역할을 만들지 못하게 하는 위임 시나리오에 쓴다.

IAM 역할

역할은 장기 자격 증명이 없고, 수임하면 AWS STS가 임시 자격 증명을 발급한다. 역할에는 두 가지 정책이 있다. 신뢰 정책은 누가 이 역할을 수임할 수 있는지, 권한 정책은 수임한 뒤 무엇을 할 수 있는지를 정한다.

사용 형태	설명
EC2 인스턴스 프로파일	EC2에 역할을 전달하는 컨테이너. 인스턴스 안의 애플리케이션은 인스턴스 메타데이터로 임시 자격 증명을 받는다. 액세스 키를 서버에 저장하지 않는다.
서비스 역할·실행 역할	Lambda 실행 역할, ECS 작업 역할처럼 AWS 서비스가 대신 작업할 때 쓰는 역할
교차 계정 역할	계정 B의 역할 신뢰 정책에 계정 A를 지정하고, 계정 A의 사용자가 그 역할로 전환한다.
페더레이션 역할	SAML 2.0 또는 OIDC로 외부 ID 공급자에서 인증한 사용자가 역할을 수임한다.
서비스 연결 역할	특정 AWS 서비스가 미리 정의해 생성·관리하는 역할

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
      "Action": "sts:AssumeRole",
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

위는 계정 111122223333의 주체가 MFA 인증을 했을 때만 역할을 수임할 수 있게 하는 신뢰 정책이다. 실제로 수임하려면 그 계정에서도 해당 사용자에게 sts:AssumeRole을 허용해야 한다.

AWS STS

AWS Security Token Service(STS)는 역할 수임과 페더레이션에 쓰이는 임시 보안 자격 증명(액세스 키 ID, 비밀 액세스 키, 세션 토큰)을 발급한다. 임시 자격 증명은 만료되면 자동으로 무효가 되므로 교체나 폐기를 따로 관리할 필요가 없다.

AssumeRole: IAM 주체가 같은 계정 또는 다른 계정의 역할을 수임한다. 콘솔의 역할 전환도 같은 원리다.
AssumeRoleWithSAML, AssumeRoleWithWebIdentity: SAML 2.0, OIDC 공급자에서 인증한 사용자가 역할을 수임한다.
역할 세션은 기본 1시간이고, 역할의 최대 세션 기간은 1시간에서 12시간 사이로 정할 수 있다. 역할에서 다른 역할로 연쇄 수임(role chaining)하면 세션은 최대 1시간이다.
수임할 때 세션 정책을 넘겨 권한을 더 좁힐 수 있다. 세션 정책으로 역할 권한보다 넓은 권한을 줄 수는 없다.

최소 권한 운영

AWS 관리형 정책으로 시작하되, IAM Access Analyzer로 실제 접근 활동을 분석해 필요한 작업만 담은 정책을 생성한다.
Access Analyzer로 외부 계정이나 퍼블릭에 열린 리소스를 찾고, 정책 문법과 보안 경고를 검증한다.
조건(aws:SourceIp, aws:PrincipalOrgID, MFA 여부, 태그)으로 허용 범위를 더 좁힌다. 태그 조건을 쓰면 속성 기반 접근 제어(ABAC)를 구현할 수 있다.
여러 계정의 공통 가드레일은 SCP, 계정 안의 권한 위임은 권한 경계로 나눠 쓴다.

시험 포인트

EC2·Lambda·ECS 위 애플리케이션이 AWS API를 호출해야 하면 역할을 붙인다. 액세스 키를 코드·환경 변수·AMI에 넣는 선택지는 오답이다.
다른 계정 자원에 접근해야 하면 교차 계정 역할(STS AssumeRole) 또는 리소스 기반 정책을 쓴다. 상대 계정에 IAM 사용자를 만들어 키를 공유하는 것은 오답이다.
명시적 Deny는 어떤 Allow보다 우선한다. 같은 계정에서는 자격 증명 기반과 리소스 기반 정책 중 하나만 허용해도 되지만, 권한 경계·SCP는 상한이다.
루트 사용자는 MFA 설정 후 봉인하고, 사람마다 개별 자격 증명을 쓴다. 많은 사용자나 여러 계정이면 IAM Identity Center가 정답에 가깝다.
"개발자가 역할을 만들 수 있게 하되 자기보다 큰 권한은 못 주게" → 권한 경계.

같이 보기

참고 문헌