Amazon SCS-C02: 아이덴티티 및 액세스 관리 — 학습 가이드

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

자격 증명(Identity), 보안 주체(Principal), 정책 평가

IAM은 자격 증명(Identity) (사용자, 그룹, 역할)과 보안 주체(Principal) (요청을 하는 인증된 엔티티)를 구분합니다. 사용자는 정적 자격 증명을 가진 장기적인 엔티티입니다. 반면 역할은 자체 자격 증명이 없으며, 수임되어 단기 STS 토큰을 생성합니다. 그룹은 사용자에게 정책을 연결하기 위한 컨테이너로, 보안 주체가 될 수 없으며 수임할 수도 없습니다.

모든 API 호출은 결정론적 평가 체인을 통과합니다. 어디서든 명시적 Deny(거부)가 우선 적용되고, 그 다음 조직 수준의 SCP가 허용해야 하며, 그 다음 권한 경계가 허용해야 하고, 그 다음 세션 정책(있는 경우)이 허용해야 합니다. 마지막으로 최소한 하나의 자격 증명 기반 또는 리소스 기반 정책에 Allow(허용)가 포함되어야 합니다. 어느 Allow 계층이라도 누락되면 암시적 거부가 발생합니다. 이것이 계층화가 중요한 이유입니다. SCP가 s3:DeleteBucket을 거부하거나 권한 경계에서 S3를 완전히 생략하면, s3:*를 부여하는 자격 증명 정책은 의미가 없습니다.

리소스 기반 정책(S3 버킷 정책, KMS 키 정책, SNS 토픽 정책, Lambda 함수 정책)은 호출자 측에 자격 증명 정책이 없어도 보안 주체에게 직접 액세스 권한을 부여할 수 있습니다. 이는 동일 계정 내에서 가능합니다. 교차 계정 액세스의 경우, 소스 계정의 자격 증명 정책과 대상 계정의 리소스 정책 양쪽 모두에서 해당 작업을 허용해야 합니다.

역할, 신뢰 정책, AssumeRole

역할에는 두 가지 정책 문서가 있습니다. 하나는 신뢰 정책(누가 역할을 수임할 수 있는지)이고, 다른 하나는 하나 이상의 권한 정책(수임 후 무엇을 할 수 있는지)입니다. 신뢰 정책은 역할 자체에 대한 리소스 기반 정책으로, sts:AssumeRole 작업을 사용합니다. 일치하는 신뢰 정책이 없으면, 호출자의 자격 증명 정책에 sts:AssumeRole이 있더라도 AssumeRole은 AccessDenied 오류와 함께 실패합니다.

교차 계정 위임의 경우, 신뢰 정책은 신뢰하는 계정 또는 해당 계정의 특정 역할/사용자 ARN을 지정하며, 특히 서드파티 액세스에 중요하게 사용되는 ExternalId를 강제합니다:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalId는 혼동된 대리인(confused deputy) 문제로부터 보호합니다. 이것이 없으면 여러 고객 계정의 역할을 수임하는 서드파티 SaaS 제공업체가 속아서 엉뚱한 고객의 역할에 대해 작업을 수행하도록 유도될 수 있습니다. 조건에서 sts:ExternalId를 생략하거나 sts:AssumeRole 호출 시 잘못된 값을 전달하면 역할 수임 시 AccessDenied가 발생합니다. 이는 모니터링이나 CSPM 도구 같은 벤더를 온보딩할 때 흔히 발생하는 잘못된 구성입니다.

AWS 서비스(Lambda, EC2, ECS 작업)의 경우, 신뢰 정책은 서비스 보안 주체(예: "Service": "lambda.amazonaws.com")를 지정합니다. S3 액세스가 필요한 Lambda 함수는 버킷에 대한 s3:GetObject 및 s3:PutObject 권한을 부여하는 실행 역할을 수임해야 합니다. 또는 S3 버킷 정책에서 해당 함수의 역할 ARN을 보안 주체로 지정할 수도 있습니다. 단일 계정 내에서는 두 메커니즘 중 어느 것이든 단독으로 작동합니다.

권한 경계

권한 경계는 사용자 또는 역할에 연결되는 고급 제어 기능으로, 자격 증명 기반 정책이 어떤 권한을 부여하는지와 관계없이 해당 자격 증명이 가질 수 있는 최대 권한을 제한합니다. 유효 권한은 자격 증명 정책과 경계의 교집합입니다. 그룹 정책이 ec2:*를 부여하더라도 경계가 ec2:Describe*만 허용한다면, 사용자는 설명(describe) 작업만 수행할 수 있습니다.

권한 경계는 주로 권한 위임에 사용됩니다. 즉, 개발자가 자신의 애플리케이션을 위한 IAM 역할을 생성하도록 허용하되, 그들이 생성하는 모든 역할에 특정 경계를 적용하도록 요구하는 것입니다. 개발자를 위한 IAM 정책은 iam:CreateRole 및 iam:PutRolePolicy에 대해 "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary"와 같은 조건을 포함합니다. 이는 권한 상승을 방지하면서도 셀프서비스를 가능하게 합니다.

그룹 멤버십이나 추가로 연결된 정책이 경계나 SCP를 “재정의"할 수 있다는 것은 흔한 오해입니다. 그럴 수 없습니다. 경계와 SCP는 상한선이지 하한선이 아닙니다.

조건을 통한 MFA 강제

두 가지 조건 키가 MFA 정책을 좌우합니다: aws:MultiFactorAuthPresent(Boolean, MFA를 사용하여 세션을 얻은 경우 true)와 aws:MultiFactorAuthAge(숫자, MFA가 검증된 후 경과한 시간(초))입니다. 민감한 API에 MFA를 강제하고 세션 수명을 제한하는 정책은 다음과 같습니다:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

2시간은 7,200초입니다. Bool 대신 BoolIfExists를 사용하는 것은 해당 키를 절대 전달하지 않는 서비스 보안 주체 호출에 대해 미묘한 위험을 초래할 수 있습니다. 이 경우 BoolIfExists는 true로 평가되어 사실상 해당 호출자에 대한 검사를 우회하게 됩니다. 따라서 사람 사용자에 대한 강제가 목적일 때는 Bool을 사용하는 것이 좋습니다.

장기 액세스 키를 사용하는 CLI 및 SDK 요청은 MFA 컨텍스트를 포함하지 않으므로, 사용자는 먼저 sts:GetSessionToken(--serial-number 및 --token-code 사용) 또는 sts:AssumeRole(--serial-number/--token-code 사용)을 호출하여 MFA 컨텍스트가 포함된 임시 자격 증명을 얻어야 합니다. 이 단기 자격 증명은 MultiFactorAuthPresent 조건을 충족시킵니다:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center와 페더레이션

IAM Identity Center(이전 AWS SSO)는 AWS Organization 전반에 걸쳐 인력의 액세스를 중앙에서 관리합니다. **권한 세트(Permission sets)**는 템플릿으로, 사용자나 그룹이 할당될 때 Identity Center가 각 대상 계정 내부에 IAM 역할로 구체화합니다. 할당은 세 가지 요소를 바인딩합니다: 보안 주체(Identity Center 디렉터리 또는 Okta/Entra ID와 같은 외부 IdP의 사용자 또는 그룹), 권한 세트, 그리고 하나 이상의 계정입니다.

권한 세트는 AWS 관리형 정책, 고객 관리형 정책(이름으로 참조되므로 각 대상 계정에 존재해야 함), 인라인 정책, 그리고 권한 경계를 포함할 수 있습니다. 권한 세트를 편집하면 Identity Center는 기반이 되는 역할을 다시 프로비저닝하므로, 해당 역할을 직접 편집해서는 안 됩니다.

Identity Center 외부의 SAML 페더레이션의 경우, AWS는 IAM SAML 공급자 객체에 등록된 IdP 메타데이터를 기준으로 어설션의 서명을 검증합니다. IdP가 서명 인증서를 교체(rotate)할 때 업데이트된 메타데이터 XML을 업로드해야 합니다. 그렇지 않으면 STS는 InvalidIdentityToken / Response Signature Invalid 오류를 반환합니다. aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... 명령어로 메타데이터를 업데이트하는 것이 오버헤드가 가장 적은 해결책입니다. 공급자를 다시 만들거나 신뢰 관계를 재구성할 필요가 없습니다.

루트 계정, 자격 증명 보고서 및 최소 권한 원칙

루트 사용자는 제거할 수 없는 전체 액세스 권한을 가지며 비상용 ID(break-glass identity)로 취급해야 합니다. 하드웨어 또는 가상 MFA 디바이스를 활성화하고, 루트 액세스 키는 모두 삭제하며, 일상적인 작업에 사용하지 않고, 자격 증명은 오프라인에 보관해야 합니다. 조직 루트나 OU 수준에서 SCP를 사용하여 멤버 계정의 관리자조차 GuardDuty를 비활성화하거나, CloudTrail을 삭제하거나, 특정 리전을 이탈하는 것을 방지할 수 있습니다. SCP는 절대 권한을 부여하지 않으며, 멤버 계정의 IAM이 부여할 수 있는 권한을 필터링할 뿐입니다.

최소 권한 원칙은 직관이 아닌 도구를 통해 운영됩니다. IAM 자격 증명 보고서(credential report)(aws iam generate-credential-report 실행 후 get-credential-report)를 생성하여 사용하지 않는 사용자, 오래된 액세스 키, MFA가 없는 사용자를 찾아내십시오. IAM Access Analyzer를 사용하여 데이터를 교차 계정으로 노출하는 리소스 정책을 식별하고, CloudTrail 활동을 기반으로 적정 규모의 정책을 생성하십시오. 마지막으로 액세스한(last-accessed) 데이터(aws iam get-service-last-accessed-details)를 사용하여 역할에서 사용하지 않는 서비스 권한을 제거하십시오.

마지막으로 명시적으로 언급할 가치가 있는 함정은 ID에 Allow를 추가하는 것만으로 충분하다고 가정하는 것입니다. KMS 키 정책이 여러분의 역할을 명시하지 않거나, SCP가 해당 작업을 거부하거나, 권한 경계에서 이를 누락하면 호출은 여전히 실패합니다. AccessDenied 문제를 해결할 때는 항상 SCP, 권한 경계, 자격 증명 정책, 리소스 정책, 세션 정책 등 전체 스택을 감사해야 합니다.

실제 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 관리, 프로덕션, 개발 워크로드를 위해 3개의 계정으로 구성된 AWS Organization을 운영하고 있으며, 민감한 거래 및 고객 데이터는 프로덕션 계정에 있습니다. 현재 레거시 장기 IAM 사용자, 계약직 직원 계정, Okta SAML 자격 증명 공급자가 혼재되어 있어 액세스 제어가 일관되지 않고 여러 계정에 역할 구성이 흩어져 있습니다.

과제: 최근 한 계약직 직원의 손상된 자격 증명이 MFA 없이 교차 계정 역할을 수임하여 과도한 작업을 수행하는 사고가 발생했습니다. 이는 권한 경계나 중앙 집중식 권한 세트가 없었기 때문입니다. Meridian은 페더레이션과 역할 신뢰 관계를 강화하고, 모든 계정에 걸쳐 MFA와 최소 권한 원칙을 강제해야 합니다.

권장 접근 방식:

Okta SAML과 통합된 AWS IAM Identity Center를 단일 페더레이션 ID 플레인으로 배포하고, 모든 사람 사용자와 계약직 직원을 장기 IAM 사용자에서 Identity Center 기반 계정으로 마이그레이션하며, 레거시 IAM 사용자의 콘솔/키 사용을 비활성화합니다.
IAM Identity Center에서 멤버 계정의 IAM 역할에 매핑되는 중앙 집중식 권한 세트를 생성하고, 모든 역할에 대해 IAM 권한 경계(IAM 정책으로 정의됨)를 구현합니다. AWS CloudFormation StackSets를 사용하여 이 경계와 역할 템플릿을 여러 계정에 배포합니다.
교차 계정 역할 신뢰 정책을 업데이트하여 Identity Center 보안 주체 ARN에서의 sts:AssumeRole만 허용하고, MFA(예: aws:MultiFactorAuthPresent) 및 소스 계정 제한 조건을 포함하도록 합니다. 세션 태그에 ID 속성을 포함하도록 요구합니다.
IdP(Okta)에서 MFA를 강제하고, 역할 세션에 MFA 조건을 요구하여 AWS에 이 강제 사항을 반영합니다. AWS Organizations에서 SCP(서비스 제어 정책)를 적용하여 콘솔 액세스나 신규 IAM 사용자 생성을 거부합니다.
지속적인 모니터링 및 정책 검증을 위해 AWS CloudTrail, AWS Config, IAM Access Analyzer를 활성화하고, 탐지 결과를 CloudWatch/GuardDuty로 전송하여 경고 및 자동화된 해결 워크플로를 구축합니다.

근거: IAM Identity Center를 통해 페더레이션을 중앙 집중화하고, 권한 세트와 경계로 최소 권한 원칙을 강제하며, 신뢰 정책에서 MFA를 요구하고, 조직 수준의 SCP와 모니터링을 적용하는 것은 영향 반경(blast radius)을 줄이고, 권한 상승을 방지하며, 감사 가능성을 제공하는 AWS 모범 사례에 부합합니다.

IAM 역할과 신뢰 정책: PassRole과 AssumeRole

IAM 역할에는 두 가지 별개의 정책 영역이 있으며, 이 둘을 혼동하는 것이 대부분의 계정 간 권한 부여 실패의 근본 원인입니다. 신뢰 정책(AssumeRolePolicyDocument)은 누가 어떤 조건에서 역할을 수임할 수 있는지를 정의합니다. 권한 정책은 수임된 역할이 무엇을 할 수 있는지를 정의합니다. 두 정책 모두 해당 작업을 허용해야 하며, 신뢰 정책만으로는 S3, KMS 또는 다른 어떤 것에도 접근 권한을 부여하지 않습니다.

프린시펄이 sts:AssumeRole을 호출하면, STS는 호출하는 자격 증명과 세션 컨텍스트(소스 IP, MFA 상태, 세션 태그, 외부 ID)를 기반으로 대상 역할의 신뢰 정책을 평가합니다. 또한 호출하는 프린시펄은 해당 역할 ARN에 대해 sts:AssumeRole을 Allow하는 자격 증명 기반 정책을 가지고 있어야 합니다. 이러한 이중 요구 사항 덕분에 계정 경계를 넘어 안전하게 역할을 수임할 수 있습니다.

MFA와 외부 ID를 요구하는 표준적인 계정 간 신뢰 정책은 다음과 같습니다:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

aws:MultiFactorAuthPresent 키는 수임 가능한 역할의 신뢰 정책에서만 의미가 있습니다. 왜냐하면 MFA 컨텍스트는 다운스트림 서비스 호출이 아닌 STS 호출 시점에 설정되기 때문입니다. S3 버킷 정책이나 역할의 권한 정책에 MFA 조건을 추가하는 것은 흔한 실수입니다. 원래 사용자가 MFA로 인증했더라도 수임된 역할 세션은 일반적으로 aws:MultiFactorAuthPresent=true를 전달하지 않으므로, 이러한 조건은 모든 것을 조용히 거부하게 됩니다. 역할 수임 시점에 MFA를 강제하고, 장기 세션에 대해 재인증을 강제하려면 aws:MultiFactorAuthAge를 사용하십시오.

PassRole은 시험 시나리오에서 혼동을 일으키는 두 번째 관문입니다. CloudFormation, EC2, Lambda 또는 CodeBuild와 같은 서비스에게 특정 역할 권한으로 실행하도록 지시할 때, 호출하는 자격 증명은 iam:PassRole 권한을 가지고 있어야 합니다.

실제 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 프로덕션, 개발, CI/CD 도구용 계정을 분리하여 다중 계정 AWS Organization을 운영하고 있습니다. 이들은 계정 간 배포를 위해 중앙 집중식 IAM 역할을 사용하며, 서드파티 CI 에이전트는 역할을 수임하여 인프라 변경을 수행합니다. 자격 증명 경계는 역할 신뢰 정책으로 강제되며, 일부 팀은 인스턴스나 태스크에 역할을 연결하기 위해 iam:PassRole 권한이 부여된 장기 인스턴스 프로파일과 Lambda 함수를 사용합니다.

과제: 최근 감사에서 지나치게 광범위한 iam:PassRole 권한으로 인해 CI/CD 프린시펄이 Administrator 역할을 EC2 인스턴스 프로파일에 전달할 수 있었고, 공격자가 AssumeRole 신뢰 관계를 악용하여 여러 계정에 걸쳐 과도한 권한을 획득한 사실이 발견되었습니다.

권장 접근 방식:

AWS CloudTrail과 Amazon EventBridge를 사용하여 최근의 iam:PassRole 및 sts:AssumeRole API 호출을 식별하고, CloudTrail Lake 또는 Athena에서 쿼리를 실행하여 어떤 프린시펄이 어떤 역할 ARN을 언제 전달했는지 목록을 만듭니다.
여러 계정에 걸쳐 IAM Access Analyzer(IAM용)를 실행하여 리소스 기반 신뢰 정책의 노출을 발견하고, Organization 외부나 외부 프린시펄이 수임할 수 있는 역할 목록을 확인합니다.
광범위한 iam:PassRole 정책을 Resource에 정확한 역할 ARN을 지정하는 최소 권한 IAM 정책으로 교체하고, aws:PassedToService 또는 aws:PrincipalOrgID와 같은 조건 키를 추가하여 누가, 무엇이 해당 역할을 받을 수 있는지 제한합니다.
역할 신뢰 정책을 강화하여 조건을 요구하도록 합니다. 즉, aws:PrincipalOrgID를 사용하고, 서드파티에는 sts:ExternalId를 사용하며, aws:SourceIdentity를 요구하고 최대 세션 기간을 강제하여 알 수 없는 프린시펄에 의한 광범위한 AssumeRole을 방지합니다.
Amazon EventBridge 규칙을 구성하여 iam:PassRole 및 AssumeRole 이상 행위를 탐지하고, Amazon SNS로 알림을 보내며, 자동화된 Lambda 플레이북을 생성하여 지나치게 광범위한 정책을 취소하거나 수정하고, 지속적인 규정 준수를 위해 AWS Security Hub 및 AWS Config에 결과를 기록합니다.

근거: 이 접근 방식은 PassRole 대상과 신뢰 정책을 강화하여 최소 권한 및 심층 방어 원칙을 강제하는 동시에, 로깅 및 모니터링을 통해 탐지 및 자동화된 해결을 가능하게 합니다. 이는 IAM 및 연동에 대한 AWS 모범 사례와 일치합니다.

모든 도메인 · 위협 탐지 및 알림 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →