IAM과 자격 증명

IAM의 구성요소 — 자격 증명과 정책

IAM은 두 종류의 대상을 다룹니다. 요청을 보내는 주체인 자격 증명(identity)과, 그 주체가 무엇을 할 수 있는지 적어 둔 정책(policy)입니다. 자격 증명에는 사용자 · 그룹 · 역할이 있고, 정책은 네 자리에 붙을 수 있습니다 — 자격 증명에, 리소스에, 권한 경계로, 그리고 세션에. 시험 문항이 어려워지는 지점은 언제나 이 네 자리에 붙은 정책이 하나의 결정으로 합쳐지는 규칙입니다.

사용자와 그룹 — 장기 자격 증명이 있는 쪽

IAM 사용자는 사람이나 애플리케이션에 대응하는 자격 증명이며, 콘솔 비밀번호와 액세스 키 같은 장기 자격 증명을 가질 수 있습니다. 장기라는 말은 만료되지 않는다는 뜻이고, 만료되지 않는 자격 증명은 유출되었을 때 우리가 직접 회수하기 전까지 계속 유효합니다. 이 한 문장이 이 장 전체의 방향을 결정합니다.

사용자 그룹은 권한을 묶어 관리하기 위한 장치입니다. 그룹에 자격 증명 기반 정책을 붙이면 그 그룹의 모든 사용자가 권한을 받습니다. 다만 그룹에는 시험이 노리는 제약이 세 개 있습니다.

• 그룹은 중첩할 수 없습니다. 그룹 안에는 사용자만 넣을 수 있고 다른 그룹은 넣을 수 없습니다.
• 그룹은 정책의 Principal이 될 수 없습니다. IAM 사용 설명서는 "그룹은 인증이 아니라 권한에 관한 것이고 Principal은 인증된 IAM 엔터티"이기 때문이라고 설명합니다. 따라서 S3 버킷 정책에서 그룹을 지정할 수 없습니다.
• 계정의 모든 사용자를 자동으로 포함하는 기본 그룹은 없습니다. 필요하면 직접 만들어야 합니다.

역할 — 장기 자격 증명이 없는 쪽

IAM 역할도 권한 정책을 가진 자격 증명이지만, 사용자와 결정적으로 다른 점이 있습니다. IAM 사용 설명서는 역할에 대해 "한 사람에게 고유하게 묶이는 대신 필요한 누구든 맡을 수 있도록 만들어졌고, 비밀번호나 액세스 키 같은 표준 장기 자격 증명이 없다"고 정의합니다. 역할을 맡으면 그 자리에서 만료 시각이 있는 임시 자격 증명이 발급됩니다.

역할은 두 개의 정책으로 이루어집니다. 이 이원 구조가 역할 문항의 핵심입니다.

"역할을 만들었는데 접근이 안 된다"는 상황은 대부분 둘 중 하나만 고친 경우입니다. 권한 정책만 넓히면 맡을 수 없고, 신뢰 정책만 넓히면 맡은 뒤에 아무것도 못 합니다.

EC2에서 API를 호출한다 — 액세스 키인가 역할인가 SAA 빈출

이 절은 이 장에서 가장 자주 출제되는 판단 하나만 다룹니다. EC2 인스턴스 위의 애플리케이션이 Amazon S3나 Amazon DynamoDB를 호출해야 할 때 무엇을 쓰는가. 정답은 거의 언제나 IAM 역할이고, 액세스 키를 인스턴스에 심는 선택지는 오답 유도로 가장 많이 쓰이는 패턴입니다.

액세스 키가 오답인 이유

이유를 "보안상 좋지 않아서"로 외우면 응용이 안 됩니다. IAM 사용 설명서가 임시 자격 증명의 장점으로 드는 항목이 그대로 근거입니다.

aws configure set aws_access_key_id "$APP_KEY_ID"
aws configure set aws_secret_access_key "$APP_SECRET"
aws s3 cp ./report.csv s3://example-app-reports/

aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=AppServerProfile

# 애플리케이션 쪽에는 아무 설정도 하지 않습니다.
aws s3 cp ./report.csv s3://example-app-reports/

인스턴스 프로파일 — 역할을 인스턴스에 붙이는 그릇

EC2 인스턴스에는 역할을 직접 붙이지 않고 인스턴스 프로파일(instance profile)이라는 그릇을 통해 붙입니다. 인스턴스 프로파일 하나에는 역할 하나가 들어갑니다. 콘솔에서 역할을 만들면 같은 이름의 인스턴스 프로파일이 함께 만들어져서 이 계층이 잘 보이지 않지만, CLI나 CloudFormation으로 만들 때는 직접 만들어야 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEc2ToAssumeThisRole",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Principal이 사람이나 계정이 아니라 서비스라는 점을 눈여겨봅니다. "이 역할은 EC2 서비스가 맡을 수 있다"는 선언이며, 이 문장이 없으면 인스턴스 프로파일에 넣어도 자격 증명이 나오지 않습니다.

애플리케이션은 어떻게 자격 증명을 찾는가

SDK와 AWS CLI는 정해진 순서로 자격 증명을 탐색합니다. 환경 변수와 자격 증명 파일이 앞쪽에 있고, 인스턴스 메타데이터가 뒤쪽에 있습니다. 그래서 액세스 키를 환경 변수에 남겨 두면 역할을 붙여도 그 키가 먼저 쓰입니다. 역할로 전환할 때는 옛 키를 지우는 것까지가 한 작업입니다.

# 역할이 제대로 붙었다면 Arn 이 assumed-role/... 형태로 나옵니다.
aws sts get-caller-identity \
  --query '[Account,Arn]' \
  --output text

정책 문서의 구조

IAM 정책은 JSON 문서입니다. 요소의 순서는 의미가 없지만 어떤 요소가 있고 없느냐가 정책의 종류를 결정합니다. 특히 Principal의 유무가 자격 증명 기반 정책과 리소스 기반 정책을 가릅니다.

요소별 역할

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-app-reports"
    },
    {
      "Sid": "ReadObjectsUnderPrefix",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-app-reports/daily/*"
    }
  ]
}

두 문장이 나뉜 이유가 곧 시험 포인트입니다. s3:ListBucket은 버킷에 대한 작업이라 대상이 arn:aws:s3:::버킷이름이고, s3:GetObject는 객체에 대한 작업이라 대상이 arn:aws:s3:::버킷이름/키입니다. 하나의 ARN으로 둘 다 처리하려다 "목록은 되는데 읽기가 안 된다"가 나옵니다.

Condition — 최소 권한을 만드는 도구

조건은 "누가 무엇을"에 "어떤 상황에서"를 더합니다. 전역 조건 키는 어느 서비스에서나 쓸 수 있고, 서비스별 조건 키도 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyWhenNotUsingTls",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-app-reports",
        "arn:aws:s3:::example-app-reports/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    },
    {
      "Sid": "RequireMfaForDeletes",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::example-app-reports/*",
      "Condition": {
        "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
      }
    }
  ]
}

두 문장 모두 Effect가 Deny라는 점이 중요합니다. "TLS를 쓸 때만 허용"을 Allow + 조건으로 쓰면 다른 정책의 Allow를 막지 못합니다. 강제하고 싶은 규칙은 조건부 Deny로 씁니다.

관리형 정책과 인라인 정책

리소스 기반 정책은 관리형이 될 수 없고 항상 인라인입니다. S3 버킷 정책이나 KMS 키 정책을 "관리형 정책으로 만들어 여러 버킷에 붙인다"는 서술은 성립하지 않습니다.

정책 평가 로직 — 최종 결정이 나오는 순서 SAA 빈출

여러 정책이 동시에 적용될 때 AWS가 결정을 내리는 절차는 정해져 있습니다. IAM 사용 설명서의 서술을 그대로 옮기면 기본은 암묵적 거부이고, 어떤 정책에서든 명시적 거부가 하나라도 있으면 즉시 거부이며, 명시적 허용만이 기본 거부를 뒤집습니다.

세 단계로 요약한 우선순위

1. 암묵적 거부(implicit deny) — 아무 정책도 언급하지 않은 작업은 거부됩니다. 이것이 기본값이며, 계정 루트 사용자만 예외입니다.
2. 명시적 허용(explicit allow) — 자격 증명 기반 정책이나 리소스 기반 정책에 Allow가 있으면 기본 거부를 덮습니다.
3. 명시적 거부(explicit deny) — 어느 정책에 있든 Deny가 하나라도 있으면 앞의 모든 허용을 이깁니다. 거부는 되돌릴 수 없습니다.

따라서 우선순위는 명시적 거부 > 명시적 허용 > 암묵적 거부입니다. 실무에서 이 성질이 유용한 이유는, "무슨 일이 있어도 막아야 하는 것"을 딱 한 군데에 Deny로 적으면 아래쪽에서 실수로 허용해도 뚫리지 않기 때문입니다.

합집합인가 교집합인가

평가 순서보다 자주 틀리는 것이 결합 규칙입니다. 조합에 따라 "둘 중 하나만 허용해도 통과"와 "둘 다 허용해야 통과"가 갈립니다.

규칙을 하나로 압축하면 이렇습니다. 권한을 주는 정책끼리는 합쳐지고, 상한을 정하는 정책은 곱해집니다. 여기에 "명시적 거부는 어느 정책에 있든 전부를 이긴다"를 얹으면 평가 로직이 끝납니다.

자격 증명 기반 정책과 리소스 기반 정책

같은 접근을 허용하는 방법이 두 가지 있습니다. 주체 쪽에 "너는 저기에 갈 수 있다"고 적거나, 리소스 쪽에 "저 사람은 들어와도 된다"고 적는 것입니다. 어느 쪽에 적느냐가 관리 방식과 교차 계정 동작을 바꿉니다.

리소스 기반 정책을 지원하는 대표 리소스

모든 서비스가 리소스 기반 정책을 지원하지는 않습니다. IAM 사용 설명서는 예로 Amazon S3 버킷, Amazon SQS 큐, VPC 엔드포인트, AWS KMS 키를 듭니다. 여기에 IAM 역할의 신뢰 정책도 리소스 기반 정책이라는 사실을 더하면 시험 범위가 거의 덮입니다.

교차 계정 접근 — 양쪽이 모두 허용해야 한다

계정 경계를 넘는 순간 규칙이 바뀝니다. IAM 사용 설명서는 이 점을 명시적으로 강조합니다 — 계정 A의 호출자는 계정 B의 리소스를 부를 수 있는 자격 증명 기반 정책을 가져야 하고, 동시에 계정 B의 리소스 기반 정책이 계정 A의 호출자를 허용해야 합니다. 양쪽에 정책이 없으면 요청은 실패합니다.

구현 방법은 두 갈래이고, 무엇을 공유하느냐로 갈립니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPartnerAccountRoleToRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AnalyticsReader"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-app-reports",
        "arn:aws:s3:::example-app-reports/*"
      ]
    }
  ]
}

이 정책만으로는 부족합니다. 계정 123456789012 쪽에서도 AnalyticsReader 역할에 s3:GetObject를 허용하는 자격 증명 기반 정책이 붙어 있어야 합니다. S3 접근 제어의 나머지 절반(퍼블릭 액세스 차단, 객체 소유권)은 8장 S3와 오브젝트 스토리지에서 다룹니다.

AWS STS와 역할 수임

AWS Security Token Service(STS)는 임시 보안 자격 증명을 발급하는 서비스입니다. 발급된 자격 증명은 액세스 키 ID · 비밀 액세스 키 · 세션 토큰 세 값으로 이루어지고, 만료 시각이 있습니다. IAM 사용 설명서는 임시 자격 증명의 장점으로 "장기 자격 증명을 애플리케이션에 배포하거나 심을 필요가 없다"와 "수명이 제한되어 있으므로 교체하거나 명시적으로 폐기할 필요가 없다"를 듭니다.

상황에 따라 다른 API

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AnalyticsReader \
  --role-session-name analytics-batch \
  --external-id example-external-id \
  --duration-seconds 3600 \
  --query 'Credentials.Expiration'

신뢰 정책과 외부 ID

역할을 만드는 쪽(신뢰하는 계정, 리소스 소유자)이 신뢰 정책에 상대 계정(신뢰받는 계정)을 적습니다. 문제는 상대 계정이 우리와 같은 조직이 아닐 때입니다. 상대 계정 전체를 신뢰하면 그 계정의 모든 주체가 역할을 맡을 수 있게 됩니다.

외부 ID(external ID)는 이때 쓰는 장치입니다. STS API 문서는 "교차 계정 역할은 보통 한 계정 전체를 신뢰하도록 설정되므로, 신뢰하는 계정의 관리자가 외부 ID를 발급해 그 ID를 아는 사람만 역할을 맡게 한다"고 설명합니다. 서드파티 서비스에 우리 계정 접근을 위임할 때의 표준 구성입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPartnerWithExternalId",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

세션 길이와 역할 연쇄

세션 길이는 무한정 늘릴 수 없습니다. STS API 문서에서 확인되는 값은 다음과 같습니다.

역할 연쇄란 역할로 받은 임시 자격 증명으로 또 다른 역할을 맡는 것입니다. 여기서 자주 나오는 함정이 하나 있습니다 — EC2 인스턴스가 인스턴스 프로파일의 역할로 API를 호출하는 것은 역할 연쇄가 아닙니다. 따라서 1시간 제한도 적용되지 않습니다.

상한을 정하는 정책 — SCP와 권한 경계

지금까지의 정책은 권한을 주는 쪽이었습니다. 여기서 다루는 두 가지는 권한을 주지 않고 상한만 정합니다. 둘을 구분하는 것이 도메인 1에서 반복적으로 요구됩니다.

서비스 제어 정책(SCP) — 계정 전체의 상한

SCP는 AWS Organizations의 정책이며, 조직 루트 · OU · 개별 계정 중 어디에나 붙습니다. 성질은 두 문장으로 요약됩니다.

• SCP는 권한을 부여하지 않습니다. 조직이나 OU의 최대 권한만 정합니다. 실제 허용은 여전히 IAM 정책이 해야 하고, SCP는 그 위에 씌우는 뚜껑입니다.
• SCP는 멤버 계정의 루트 사용자에게도 적용됩니다. IAM 정책으로는 루트를 제한할 수 없으므로, 루트를 통제하는 유일한 수단이 SCP입니다.

조직을 전체 기능으로 만들어야 SCP를 쓸 수 있습니다. 통합 결제 전용으로 만든 조직에서는 어떤 정책 유형도 활성화되지 않습니다 (1장 AWS Organizations).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": [
        "organizations:LeaveOrganization",
        "account:CloseAccount"
      ],
      "Resource": "*"
    }
  ]
}

권한 경계 — 엔터티 하나의 상한

권한 경계는 관리형 정책을 IAM 사용자나 역할 하나에 상한으로 붙이는 기능입니다. IAM 사용 설명서의 표현으로는 "자격 증명 기반 정책이 그 엔터티에 부여할 수 있는 최대 권한을 설정"하며, "권한을 제한할 뿐 그 자체로는 권한을 주지 않습니다." 실효 권한은 자격 증명 기반 정책과 권한 경계의 교집합입니다.

가장 중요한 용도는 권한 관리 업무의 위임입니다. 개발팀장에게 "사용자와 역할을 만들 수 있는 권한"을 주고 싶은데 그대로 주면 관리자 권한을 가진 사용자를 만들어 버릴 수 있습니다. 새로 만드는 엔터티에 특정 권한 경계를 반드시 붙이도록 조건을 걸면 위임하면서도 상한을 유지할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateUsersOnlyWithBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateUser",
        "iam:AttachUserPolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/TeamBoundary"
        }
      }
    }
  ]
}

SCP와 권한 경계는 무엇이 다른가

AWS IAM Identity Center와 페더레이션 선택

계정이 늘어나면 계정마다 IAM 사용자를 만드는 방식이 무너집니다. 입사자가 오면 계정 수만큼 사용자를 만들어야 하고, 퇴사자가 나가면 계정 수만큼 지워야 하며, 하나라도 빠뜨리면 접근이 남습니다. 이 문제를 푸는 것이 페더레이션이고, AWS의 표준 답이 AWS IAM Identity Center입니다.

권한 집합이 하는 일

IAM Identity Center는 사용자와 그룹을 한 곳에서 관리하고, 권한 집합(permission set)을 만들어 "어느 그룹이 어느 계정에서 무엇을 할 수 있는가"를 정의합니다. 권한 집합을 계정에 할당하면 그 계정 안에 대응하는 역할이 자동으로 만들어지고, 사용자는 로그인 포털에서 계정과 역할을 골라 임시 자격 증명을 받습니다.

결과적으로 얻는 것은 세 가지입니다.

• 자격 증명이 한 곳에만 존재하므로 퇴사 처리가 한 번이면 끝납니다.
• 계정마다 IAM 사용자를 만들지 않으므로 장기 자격 증명이 생기지 않습니다.
• 권한 집합을 고치면 할당된 모든 계정에 반영됩니다.

무엇을 고를 것인가 — 페더레이션 판단 기준

시험은 서비스를 설명하게 하지 않고 고르게 합니다. 기준은 누구에게 접근을 주는가 하나입니다.

Amazon Cognito와 AWS Directory Service의 세부 동작은 16장 보안·암호화·거버넌스에서 다룹니다. 여기서는 사람 대 직원이면 Identity Center, 사람 대 앱 사용자면 Cognito, 사람이 아니면 역할이라는 세 갈래만 확실히 해 둡니다.

흔한 오해

시험 포인트 정리

이 장의 주제는 전부 보안 아키텍처 설계(30%)에 속합니다. 아래 표의 함정 열이 실제 오답 선택지가 만들어지는 자리입니다.

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 3장 · VPC 네트워킹 기초 IAM이 "누가 무엇을"이라면 VPC는 "어디서 어디로"입니다. 보안 그룹과 네트워크 ACL이 만드는 두 번째 통제 계층을 다룹니다. 기본개념 · SAA 최우선
• 16장 · 보안·암호화·거버넌스 KMS 키 정책은 리소스 기반 정책의 대표 사례입니다. Amazon Cognito와 AWS Directory Service의 세부 동작도 여기서 다룹니다. 기본개념 · SAA 최우선
• 케이스 1 · EC2에 액세스 키를 심어 배포했다 이 장에서 소거 대상으로 배운 구성이 실제로 어떤 사고로 이어지는지, 그리고 역할로 전환하는 순서를 따라갑니다. 아키텍처 케이스
• 보안 빠른참조 자주 쓰는 IAM 정책 패턴, 암호화 옵션 매트릭스, 정책 유형별 결합 규칙을 한 화면에 모았습니다. 빠른참조
• 도메인 1 · 보안 아키텍처 설계 (30%) 과제 진술 세 개의 해설과 출제 포인트, 그리고 이 장과의 매핑을 정리했습니다. 가중치가 가장 큰 도메인입니다. 시험 대비 · 최우선
• 실습 11 · KMS 고객 관리형 키로 암호화 키 정책이라는 리소스 기반 정책을 직접 써 보면서 IAM 정책과의 결합 규칙을 손으로 확인합니다. 실습 예제

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• IAM 사용 설명서 — 액세스 관리 개요 — 자격 증명 · 정책 · 요청 평가의 기본 구조
• IAM 사용 설명서 — IAM 사용자 그룹 — 그룹을 중첩할 수 없다는 점, 그룹을 Principal로 지정할 수 없다는 점, 기본 그룹이 없다는 점
• IAM 사용 설명서 — IAM 역할 — 역할의 정의와 사용 주체
• IAM 사용 설명서 — 역할 용어와 개념 — 역할에 장기 자격 증명이 없다는 정의, 서비스 역할과 서비스 연결 역할의 구분, 신뢰 정책이 필수 리소스 기반 정책이며 Principal에 와일드카드를 쓸 수 없다는 점, 역할 연쇄가 세션을 1시간으로 제한하며 EC2 인스턴스 역할 사용은 연쇄가 아니라는 점, 위임에서 신뢰하는 계정과 신뢰받는 계정의 관계
• IAM 사용 설명서 — JSON 정책 요소 레퍼런스 — 요소 목록과 Action/NotAction, Principal/NotPrincipal, Resource/NotResource가 상호 배타적이라는 점
• IAM 사용 설명서 — IAM의 정책과 권한 — 정책 유형 구분과 관리형·인라인 정책
• IAM 사용 설명서 — 자격 증명 기반 정책과 리소스 기반 정책 — 리소스 기반 정책이 인라인만 가능하다는 점, 같은 계정에서는 둘 중 하나만 허용해도 통과한다는 점, 계정 간 요청은 양쪽 계정에 정책이 있어야 한다는 점
• IAM 사용 설명서 — 정책 평가 로직 — 기본이 암묵적 거부라는 점, 명시적 거부가 모든 허용을 이긴다는 점, 정책 유형별 평가 순서
• IAM 사용 설명서 — IAM 엔터티의 권한 경계 — 권한 경계가 최대 권한만 정하고 권한을 부여하지 않는다는 점, 자격 증명 기반 정책과의 교집합, SCP·권한 경계·자격 증명 기반 정책 세 가지가 모두 허용해야 한다는 점, 권한 관리 위임 시나리오
• IAM 사용 설명서 — 임시 보안 자격 증명 — 임시 자격 증명의 수명과 장점, 기업 페더레이션과 웹 자격 증명 페더레이션의 구분
• IAM 사용 설명서 — STS 자격 증명 비교 — AssumeRole 계열 작업과 GetSessionToken의 용도 구분
• IAM 사용 설명서 — 서드파티에 접근을 부여할 때의 외부 ID — 외부 ID가 필요한 이유와 사용 방법
• IAM 사용 설명서 — 역할 사용 — 역할의 최대 세션 길이 설정
• IAM 사용 설명서 — 보안 모범 사례 — 장기 자격 증명 대신 임시 자격 증명을 쓰라는 권고
• AWS STS API 레퍼런스 — AssumeRole — DurationSeconds의 하한 900초와 역할 최대 세션 길이(1–12시간), 역할 연쇄 시 1시간 제한, 세션 정책이 교집합이라는 점, 인라인·관리형 세션 정책의 평문 2,048자 제한과 관리형 정책 ARN 10개 제한, ExternalId와 MFA 조건
• IAM 사용 설명서 — 임시 보안 자격 증명 요청 — GetSessionToken의 세션 길이 범위(900초–129,600초, 기본 43,200초)와 각 STS 작업의 호출 조건
• Amazon EC2 사용 설명서 — Amazon EC2의 IAM 역할 — 인스턴스 프로파일로 역할을 연결하고 애플리케이션이 임시 자격 증명을 받는 구조
• AWS Organizations 사용 설명서 — 정책 관리 — 정책 유형의 활성화와 부착 위치
• AWS Organizations 사용 설명서 — SCP 전략 — SCP가 최대 권한만 정하며 멤버 계정 루트 사용자에게도 적용된다는 점, 허용 목록과 거부 목록 전략
• AWS Organizations 사용 설명서 — 용어와 개념 — 전체 기능과 통합 결제 전용 기능 집합의 차이
• AWS IAM Identity Center 사용 설명서 — 서비스 개요 — 중앙 집중식 자격 증명 관리와 권한 집합을 통한 다중 계정 접근
• AWS IAM Identity Center 사용 설명서 — 계정 관리 — 권한 집합을 계정에 할당하는 방식