# AWS 파트너를 위한 IAM 임시 위임 ## 개요 IAM 임시 위임을 사용하면 AWS 고객이 대화형 안내 워크플로를 통해 AWS 파트너 제품을 원활하게 온보딩 및/또는 AWS 환경에 통합할 수 있습니다. 고객은 AWS 파트너에게 필요한 AWS 서비스를 구성할 수 있는 제한된 임시 액세스 권한을 부여하여 온보딩 마찰을 줄이고 가치 실현 시간을 단축할 수 있습니다. 파트너는 IAM 임시 위임을 통해 다음을 수행할 수 있습니다. + 자동화된 리소스 프로비저닝으로 고객 온보딩 간소화 + 수동 구성 단계를 없애 통합 복잡성 최소화 + 고객이 승인한 투명한 권한을 통해 신뢰 구축 + 권한 경계를 사용하여 장기 액세스 패턴으로 지속적인 작업 지원 ## 작동 방식 1. *파트너가 위임 요청 생성* - 파트너가 필요한 권한과 기간을 지정하는 요청을 생성합니다. 1. *고객이 AWS Console에서 검토* - 고객이 어떤 권한 파트너가 왜 요청하는지 정확하게 확인합니다. 1. *고객 승인* - 고객이 요청을 승인하고 교환 토큰을 릴리스합니다. 토큰이 지정된 해당 SNS 주제의 파트너에게 전송됩니다. 1. *파트너가 임시 자격 증명 수신* - 파트너가 토큰을 임시 AWS 자격 증명으로 교환합니다. 1. *파트너가 리소스 구성* - 파트너가 자격 증명을 사용하여 고객 계정에 필요한 리소스를 설정합니다. ## 파트너 자격 임시 위임 통합을 받으려면 파트너가 다음 요구 사항을 충족해야 합니다. + *ISV Accelerate 참여* - [ISV Accelerate(ISVA)](https://aws.amazon.com/partners/programs/isv-accelerate/) 프로그램에 등록해야 합니다. + *AWS Marketplace 목록* - 제품이 AWS Marketplace에 ‘Deployed on AWS‘ 배지와 함께 나열되어 있어야 합니다. ## 온보딩 프로세스 다음 단계를 완료하여 임시 위임을 제품에 통합합니다. 1. *1단계: 요건 검토* 이 설명서를 검토하여 자격 요건을 이해하고 아래 파트너 설문지를 작성합니다. 1. *2단계: 온보딩 요청 제출* aws-iam-partner-onboarding@amazon.com으로 이메일을 보내거나 AWS 담당자에게 문의합니다. 아래 표의 모든 필수 필드와 함께 작성된 파트너 설문지를 포함합니다. 1. *3단계: AWS 검증 및 검토* AWS는 다음을 수행합니다. + 자격 기준을 충족하는지 검증 + 정책 템플릿 및 권한 경계 검토 + 제출된 아티팩트에 대한 피드백 제공 1. *4단계: 정책 구체화* AWS 피드백에 답하고 필요에 따라 업데이트된 정책 템플릿 또는 권한 경계를 제출합니다. 1. *5단계: 등록 완료* 승인되면 AWS는 다음을 수행합니다. + 지정된 계정에 대한 API 액세스 활성화 + 정책 템플릿 및 권한 경계에 대한 ARN 공유(해당하는 경우) 온보딩이 완료되면 확인 메시지가 표시됩니다. 그런 다음 등록된 계정에서 임시 위임 API, CreateDelegationRequest 및 GetDelegatedAccessToken에 액세스하고, 위임 요청 워크플로를 제품에 통합할 수 있습니다. ## 파트너 설문지 다음 표에는 파트너 온보딩에 필요한 정보가 나열되어 있습니다. | 정보 | 설명 | 필수 | | --- | --- | --- | | Partner Central AccountID | [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login)에 등록된 계정의 AWS 계정 ID입니다. | 예 | | PartnerId | [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login)에서 제공하는 파트너 ID입니다. | 아니요 | | AWS Marketplace 제품 ID | [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login)에서 제공하는 제품의 제품 ID입니다. | 예 | | AWS accountIDs | 임시 위임 API를 직접 호출하는 데 사용할 AWS 계정 ID 목록입니다. 여기에는 프로덕션 계정과 비프로덕션/테스트 계정이 모두 포함되어야 합니다. | 예 | | 파트너 이름 | 이 이름은 고객이 임시 위임 요청을 검토할 때 AWS Management Console에 표시됩니다. | 예 | | 연락처 이메일 | 통합에 대해 연락하는 데 사용할 수 있는 하나 이상의 이메일 주소입니다. | 예 | | 요청자 도메인 | 사용자의 도메인(예: www.example.com) | 예 | | 통합 설명 | 이 기능을 사용하여 해결하려는 사용 사례에 대한 간단한 설명입니다. 설명서 또는 기타 공개 자료에 대한 참조 링크를 포함할 수 있습니다. | 예 | | 아키텍처 다이어그램 | 통합 사용 사례를 보여주는 아키텍처 다이어그램입니다. | 아니요 | | 정책 템플릿 | 이 기능에 대해 하나 이상의 정책 템플릿을 등록해야 합니다. 정책 템플릿은 고객의 AWS 계정에서 요청하려는 임시 권한을 정의합니다. 자세한 내용은 정책 템플릿 섹션을 참조하세요. | 예 | | 정책 템플릿 이름 | 등록할 정책 템플릿의 이름입니다. | 예 | | 권한 경계 | 임시 권한을 사용하여 고객 계정에서 IAM 역할을 생성하려면 IAM에 권한 경계를 등록해야 합니다. 권한 경계는 역할에 대한 최대 권한을 제한하기 위해 생성한 IAM 역할에 연결됩니다. 선택한 AWS 관리형 정책을 권한 경계로 사용하거나 새 사용자 지정 권한 경계(JSON)를 등록할 수 있습니다. 자세한 내용은 권한 경계 섹션을 참조하세요. | 아니요 | | 권한 경계 이름 | 권한 경계의 이름입니다. 형식은 arn:aws:iam::partner:policy/permission\$1boundary//\$1입니다. 정책 이름에는 생성 날짜가 접미사로 포함되어야 합니다. 권한 경계가 생성된 후에는 이름을 업데이트할 수 없습니다. 기존 AWS 관리형 정책을 사용하는 경우, 관리형 정책 ARN을 대신 제공합니다. | 아니요 | | 권한 경계 설명 | 권한 경계에 대한 설명입니다. 권한 경계가 생성된 후에는 이 설명을 업데이트할 수 없습니다. | 아니요 | # 통합 이해 온보딩 프로세스를 완료한 후 IAM 임시 위임과의 통합을 구축할 수 있습니다. 완전한 통합에는 일반적으로 세 가지 주요 작업 범주가 포함됩니다. ## 1. 사용자 경험 및 워크플로 설계 임시 위임 워크플로를 통해 고객을 안내하는 파트너 애플리케이션에서 프런트엔드 환경을 구축합니다. 파트너 애플리케이션은 다음을 수행해야 합니다. + 고객이 임시 액세스 권한을 부여할 수 있는 명확한 온보딩 또는 구성 흐름을 제시합니다. 이 작업에 ‘IAM 임시 위임으로 배포’와 같이 명확하게 레이블을 지정합니다. + CreateDelegationRequest API에서 반환한 콘솔 링크를 사용하여 고객을 AWS Management Console로 리디렉션하여 위임 요청을 검토하고 승인합니다. + 요청되는 권한과 이유에 대한 적절한 메시지를 제공합니다. 고객은 위임 요청 세부 정보 페이지에서 이 메시지를 볼 수 있습니다. + 고객이 AWS에서 승인을 완료한 후 애플리케이션에 대한 고객의 반환을 처리합니다. ## 2. API 통합 IAM 임시 위임 API 사용하여 위임 요청을 보내고 관리합니다. AWS 계정이 등록되면 다음 API에 액세스할 수 있습니다. + *IAM CreateDelegationRequest* - 고객 AWS 계정에 대한 위임 요청을 생성합니다. 이 API는 요청을 검토하고 승인하기 위해 고객을 리디렉션하는 콘솔 링크를 반환합니다. + *AWS STS GetDelegatedAccessToken* - 고객이 위임 요청을 승인한 후 임시 AWS 자격 증명을 검색합니다. 이러한 자격 증명을 사용하여 고객 계정에서 작업을 수행합니다. 통합은 요청 생성, 상태 모니터링, 승인 시 임시 자격 증명 검색 등 위임 요청의 전체 수명 주기를 처리해야 합니다. ## 3. 리소스 구성 및 오케스트레이션 임시 자격 증명을 얻으면 필요한 워크플로를 오케스트레이션하여 고객 AWS 계정의 리소스를 구성합니다. 여기에는 다음이 포함될 수 있습니다. + AWS 서비스 API를 직접 호출하여 리소스 생성 및 구성 + AWS CloudFormation 템플릿을 사용하여 인프라 배포 + 지속적인 액세스를 위한 IAM 역할 생성(권한 경계 사용 필요) 오케스트레이션 로직은 멱등성이 있어야 하며 고객이 위임 승인을 재시도하거나 수정해야 할 수 있으므로 실패를 정상적으로 처리해야 합니다. # 권한 이해 기능 온보딩 프로세스의 일환으로 고객 AWS 계정에서 요청하려는 권한을 정의하는 정책을 IAM에 등록해야 합니다. 이 등록 프로세스는 고객에게 보다 일관된 경험을 제공하고 정책 작성의 일반적인 위험을 방지하는 데 도움이 됩니다. 등록 중에는 AWS가 일련의 검증을 기준으로 정책을 평가합니다. 이러한 검증은 정책 형식 및 구조를 표준화하고 알려진 안티 패턴에 대한 기본 보호를 제공하기 위한 것입니다. 또한 검증을 통해 권한 에스컬레이션, 의도하지 않은 교차 계정 액세스, 고객 계정의 고부가가치 리소스에 대한 광범위한 액세스의 리스크를 줄일 수 있습니다. ## 권한 유형 AWS는 임시 및 장기 권한이라는 두 가지 권한 범주를 고려합니다. ### 임시 권한 임시 권한은 임시 위임된 액세스 세션에 할당된 권한을 제한합니다. 임시 권한은 위임된 세션에 적용되는 정책 템플릿에 설명되어 있습니다. 템플릿은 위임 요청을 생성할 때 제공하는 파라미터를 지원합니다. 그러면 이러한 파라미터 값이 세션에 바인딩됩니다. 임시 권한은 현재 AWS STS에서 사용할 수 있는 세션 정책과 동일한 방식으로 작동합니다. 정책은 기본 사용자의 기능을 제한하지만 추가 액세스 권한은 부여하지 않습니다. 자세한 내용은 AWS STS 설명서의 세션 정책을 참조하세요. ### 장기 권한 장기 권한은 임시 액세스를 통해 생성되거나 관리되는 모든 역할의 권한을 제한합니다. 장기 권한은 IAM 권한 경계로 구현됩니다. 온보딩의 일부로 AWS에 하나 이상의 권한 경계를 제출할 수 있습니다. 승인되면 AWS는 정책에서 참조할 수 있는 정책 ARN을 사용자와 공유합니다. 이러한 경계 정책에는 두 가지 주목할 만한 특징이 있습니다. 첫째, 변경할 수 없습니다. 권한을 업데이트하려면 새 권한 경계를 등록할 수 있습니다. 그런 다음 새 위임 요청을 전송하여 새 권한 경계를 고객의 역할에 연결할 수 있습니다. 둘째, 정책이 템플릿화되지 않습니다. 동일한 경계 정책은 전역적으로 공유되므로 고객별로 변경할 수 없습니다. **중요** 권한 경계의 최대 크기 제한은 6,144자입니다. **참고** 권한 경계 또는 정책 템플릿을 업데이트하려면 aws-iam-partner-onboarding@amazon.com으로 IAM에 문의하세요. 새 권한 경계가 등록되면 고객에게 위임 요청을 보내 IAM 역할을 업데이트하고 새로 등록된 권한 경계를 연결할 수 있습니다. 자세한 내용은 예시 섹션을 참조하세요. ## 사용 사례 예시: 데이터 처리 워크로드 고객 계정에서 데이터 처리 워크로드를 실행하는 제품 제공업체를 예로 들어보겠습니다. 이 제공업체는 초기 온보딩 중에 인프라를 설정해야 하지만 워크로드를 운영하려면 지속적인 액세스도 필요합니다. *임시 권한(최초 설정용):* + Amazon EC2 인스턴스, VPC 및 보안 그룹 생성 + 처리된 데이터를 위한 Amazon S3 버킷 생성 + 지속적인 작업을 위한 IAM 역할 생성 + IAM 역할에 권한 경계 연결 *장기 권한(진행 중인 작업에 대한 권한 경계가 있는 IAM 역할):* + Amazon EC2 인스턴스를 시작하고 중지하여 처리 작업 실행 + Amazon S3 버킷에서 입력 데이터 읽기 + 처리된 결과를 Amazon S3 버킷에 쓰기 임시 권한은 온보딩 중에 인프라를 구성하는 데 한 번 사용됩니다. 이 프로세스 중에 생성된 IAM 역할에는 최대 권한을 지속적인 워크로드 관리에 필요한 작업으로만 제한하는 권한 경계가 있습니다. 이는 역할의 정책이 수정되더라도 경계에 정의된 권한을 초과하지 않도록 보장합니다. # 정책 평가 지침 AWS는 일련의 지침에 따라 제출된 정책을 평가합니다. 정책 템플릿과 권한 경계 모두에 동일한 평가 지침이 적용되며, 적절한 경우 사소한 차이가 기록됩니다. 평가를 위해 서비스를 개별 그룹으로 구분합니다. 가장 중요한 차이점은 액세스, 자격 증명 및 키를 관리하는 보안에 민감한 서비스입니다. 이러한 서비스에 대한 액세스 권한을 부여하는 정책은 수행 중인 작업에 좁게 초점을 맞춰야 합니다. 보안에 민감한 서비스로는 AWS Identity and Access Management(IAM), AWS Key Management Service(KMS), AWS Resource Access Manager(RAM), AWS IAM Identity Center, AWS Organizations, AWS Secrets Manager 등이 있습니다. 두 번째 차이점은 계정 경계를 넘어 데이터에 액세스할 수 있는 서비스입니다. 이러한 서비스에 대한 정책에는 의도하지 않은 교차 계정 액세스를 방지하기 위한 보호가 포함되어야 합니다. ## 일반적인 검증 모든 정책 설명은 다음 지침을 따라야 합니다. + 모든 문에는 효과, 작업(또는 NotAction), 리소스 및 조건 필드가 순서대로 포함되어야 합니다. + 단일 문 내의 모든 작업은 알파벳순으로 나열되어야 합니다. + 정책에 포함된 모든 ARN 관련 서비스에 대한 공개 설명서에 정의된 구문을 따라야 합니다. + NotAction 필드는 거부 문에서만 사용할 수 있습니다. + Allow 문의 작업에는 서비스 코드가 포함되어야 합니다. 일반 와일드카드(‘\$1’)는 허용되지 않습니다. ## 보안에 민감한 서비스 제한 위에서 언급한 보안에 민감한 서비스에는 다음과 같은 제한 사항이 적용됩니다. + Allow 문의 작업은 [service]:\$1보다 구체적이어야 합니다. + 임시 액세스 정책 템플릿에 대한 명령문 허용의 작업에는 와일드카드가 포함되어서는 안 됩니다. + iam:PassRole 또는 iam:CreateServiceLinkedRole과 같은 민감한 작업에는 특정 리소스 또는 조건부 검사와 같은 추가 범위가 필요합니다. 이 작업에는 다음이 포함됩니다. + IAM 역할 전달 중 + IAM 역할 수정 작업 + IAM 정책 수정 작업 + AWS KMS 쓰기 또는 암호화 작업 + AWS RAM 쓰기 또는 공유 작업 + AWS 보안 암호를 검색 또는 수정하거나 리소스 정책을 수정하기 위한 Secrets Manager 작업 + 다른 작업에는 iam:ListUsers 또는 iam:GetPolicy와 같은 와일드카드 리소스를 사용할 수 있습니다. + iam:CreateAccessKey와 같은 자격 증명을 관리하는 작업은 차단됩니다. ## IAM 관련 제한 사항 IAM의 경우: + IAM 역할 및 정책에는 제한된 쓰기 작업만 허용됩니다. 사용자, 그룹 및 인증서와 같은 다른 IAM 리소스에 대한 권한은 요청할 수 없습니다. + 정책 연결 또는 인라인 정책 관리 작업은 권한 경계가 있는 역할로 제한됩니다. 권한 경계는 파트너가 제공하거나 허용된 AWS 관리형 정책 목록에 있어야 합니다. AWS 관리형 정책은 권한이 높거나 관리 권한을 부여하지 않는 경우 허용될 수 있습니다. 예를 들어 특정 직무에 대한 AWS 관리형 정책 또는 SecurityAudit 정책이 허용될 수 있습니다. AWS는 온보딩 프로세스 중에 각 AWS 관리형 정책을 건별로 검토합니다. + 정책 관리는 파트너별 경로가 arn:aws:iam::@\$1AccountId\$1:policy/partner\$1domain.com/[feature]\$1인 정책에만 허용됩니다. + 태그는 리소스 생성 중에만, 그리고 역할 및 정책에 대해서만 적용할 수 있습니다. + iam:PassRole 검사는 특정 이름 또는 경로 접두사와 일치해야 합니다. ## AWS STS 관련 제한 사항 AWS STS의 경우: + sts:AssumeRole은 특정 역할 ARN, 역할 ARN 접두사로 범위가 지정되거나 계정 또는 조직 ID/조직 단위 집합으로 제한되어야 합니다. ## IAM Identity Center 제한 사항 AWS IAM Identity Center의 경우 다음 작업이 차단됩니다. + 권한 관리를 처리하는 모든 작업(예: sso:AttachCustomerManagedPolicyReferenceToPermissionSet) + AWS Identity Store의 사용자, 그룹 및 멤버십 수정 + 태그 관리 ## AWS Organizations 제한 사항 AWS Organizations의 경우 읽기 작업만 허용됩니다. ## 추가 서비스별 검증 + glue:GetConnection 또는 redshift:GetClusterCredentials와 같은 보안 암호 또는 자격 증명을 획득하는 작업에는 전체 ARN, ARN 접두사 또는 태그와 일치하는 조건이 있어야 합니다. + Amazon Redshift의 경우: redshift:GetClusterCredentials는 특정 데이터베이스 이름에만 허용되고 redshift:GetClusterCredentialsWithIAM은 특정 작업 그룹 이름에만 허용됩니다. **참고** 계정에서 IAM 리소스를 관리할 때는 arn:aws:iam::111122223333:role/partner.com/rolename 같은 이름을 나타내는 경로를 사용하는 것이 좋습니다. 이렇게 하면 통합과 관련된 리소스를 차별화하고 고객이 검색, 감사 및 분석을 더 쉽게 수행할 수 있습니다. ## 교차 계정 액세스 요구 사항 교차 계정 액세스를 잠재적으로 허용하는 문에는 다음 중 하나 이상이 포함되어야 합니다. + 리소스의 계정 또는 조직을 지정하는 조건(예: 하나 이상의 예상 값과 일치하는 aws:ResourceOrgId) + 특정 계정을 포함하는 리소스 필드(예: arn:aws:sqs:\$1:111122223333:\$1) + 와일드카드가 아닌 계정과 전체 리소스 이름을 포함하는 리소스 필드(예: arn:aws:s3:::full-bucket-name) **참고** 교차 계정 액세스는 명확한 비즈니스 타당성이 요구되는 필요한 민감한 기능입니다. AWS는 온보딩 프로세스 중에 교차 계정 액세스의 필요성을 신중하게 검토합니다. # 정책 템플릿 정책 템플릿은 파트너가 고객의 계정에서 요청하는 임시 권한을 정의하도록 설계된 새로운 IAM 구문입니다. 일반 IAM 정책과 마찬가지로 Effect, Action, Resource 및 Condition 요소가 있는 문을 사용하여 권한을 정의합니다. 주요 차이점은 위임 요청을 생성할 때 정책 템플릿에 실제 값으로 대체되는 파라미터(예: @\$1bucketName\$1)가 포함되어 있다는 것입니다. ## 정책 템플릿의 작동 방식 온보딩 프로세스의 일환으로 정책 템플릿을 AWS에 등록합니다. AWS는 위임 요청을 생성할 때 참조하는 고유한 ARN을 각 템플릿에 할당합니다. 위임 요청을 생성할 때 다음을 지정합니다. + 정책 템플릿 ARN + 템플릿으로 대체할 파라미터 값 AWS는 템플릿을 파라미터 값과 결합하여 표준 IAM 정책을 생성합니다. 고객은 위임 요청을 승인할 때 이 최종 렌더링된 정책을 검토하여 부여될 권한을 정확히 확인합니다. **참고** 최종 렌더링된 정책의 최대 크기 제한은 2,048자입니다. 다음은 템플릿 대체의 작동 방식을 보여주는 간단한 예입니다. 정책 템플릿: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] } ``` 위임 요청에 제공된 파라미터: ``` { "Name": "bucketName", "Values": ["customer-data-bucket"], "Type": "String" } ``` 최종 렌더링된 정책(고객이 보는 내용): ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::customer-data-bucket/*" } ] } ``` ## 템플릿 구문 정책 템플릿은 두 가지 주요 기능인 파라미터 대체와 조건문을 사용하여 유연성을 제공합니다. 파라미터 대체를 사용하면 위임 요청을 생성할 때 실제 값으로 대체되는 템플릿의 자리 표시자를 정의할 수 있습니다. 조건부 문을 사용하면 파라미터 값을 기반으로 전체 정책 문을 포함하거나 제외할 수 있습니다. ### 파라미터 대체 및 유형 @\$1parameterName\$1 구문을 사용하여 정책 템플릿에서 파라미터를 정의합니다. 위임 요청을 생성할 때 각 파라미터의 유형을 지정해야 합니다. #### 문자열 템플릿으로 직접 대체되는 단일 값입니다. 템플릿: ``` "Resource": "arn:aws:s3:::@{bucketName}/*" ``` 파라미터: ``` { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" } ``` 렌더링된 결과: ``` "Resource": "arn:aws:s3:::my-bucket/*" ``` #### StringList 여러 리소스 항목을 생성하는 여러 값입니다. 리소스 ARN에서 StringList 파라미터를 사용하면 확장되어 각 값에 대해 별도의 리소스 항목을 생성합니다. 템플릿: ``` "Resource": "arn:aws:s3:::@{bucketNames}/*" ``` 파라미터: ``` { "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" } ``` 렌더링된 결과: ``` "Resource": [ "arn:aws:s3:::bucket-1/*", "arn:aws:s3:::bucket-2/*" ] ``` #### 제품 간 동작 동일한 리소스 ARN에 여러 파라미터가 사용되는 경우 StringList 파라미터는 모든 조합의 교차 곱을 생성합니다. 템플릿: ``` "Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*" ``` 파라미터: ``` [ { "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" }, { "Name": "prefix", "Values": ["data"], "Type": "String" } ] ``` 렌더링된 결과: ``` "Resource": [ "arn:aws:s3:::bucket-1/data/*", "arn:aws:s3:::bucket-2/data/*" ] ``` ### 조건문 @Enabled 지시문을 사용하여 파라미터 값을 기반으로 전체 문을 조건부로 포함하거나 제외합니다. 구문: + @Enabled: "parameterName" - 파라미터 값이 ‘True’일 때 문 포함 + @Enabled: "\$1parameterName" - 파라미터 값이 ‘True’가 아닐 때(음수) 문 포함 템플릿: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "@Enabled": "ENABLE_S3_WRITE", "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] } ``` 파라미터(ENABLE\$1S3\$1WRITE가 ‘True’인 경우): ``` [ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["True"], "Type": "String" } ] ``` 렌더링된 결과: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" } ] } ``` 파라미터(ENABLE\$1S3\$1WRITE가 ‘False’인 경우): ``` [ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["False"], "Type": "String" } ] ``` 렌더링된 결과: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" } ] } ``` ENABLE\$1S3\$1WRITE가 ‘True’로 설정되면 조건문이 포함됩니다. ‘False’로 설정되면 문이 렌더링된 정책에서 제외됩니다. ## 추가 예제 다음 예시에서는 임시 위임에서 정책 템플릿을 사용하는 일반적인 패턴을 보여줍니다. 장기 액세스를 위한 권한 경계가 있는 IAM 역할을 생성하는 데 중점을 두고 특정 리소스에 대한 권한 범위를 조정하기 위한 다양한 전략을 보여줍니다. 이 예에서는 ARN 접두사, 리소스 태깅 및 권한 경계 업데이트와 같은 기술을 사용하여 유연성과 보안의 균형을 맞추는 방법을 보여줍니다. ### 예시 1: 특정 리소스에 대한 장기 액세스 권한 부여 다음 권한 경계는 ‘partner.com’에 대한 ‘SQSAccessorBoundary’로 제출됩니다. ``` { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ``` **참고** 여기에는 열린 리소스 정책이 있는 다른 계정의 대기열에 대한 액세스 권한을 부여하지 않도록 하는 동일한 계정 조건이 포함됩니다. 경계는 모든 고객에 걸쳐 공유되고 템플릿화할 수 없으므로 고객의 계정 ID에 대한 직접 참조를 포함할 수 없습니다. 이 정책의 첫 번째 버전이므로 ARN은 arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$115입니다. 임시 액세스 권한을 위해 다음 정책 템플릿이 제출됩니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:ListQueues" ], "Resource": "arn:aws:sqs:*:*:*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] } ``` ### 예시 2: ARN 접두사 사용 권한 경계는 액세스를 제한하는 리소스 ARN 접두사를 지정할 수 있습니다. ``` "Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*" ``` 이렇게 하면 해당 접두사가 있는 리소스에만 액세스할 수 있으므로 액세스 가능한 리소스의 범위가 줄어듭니다. ### 예시 3: 리소스 액세스 제어에 태그 사용 임시로 위임된 액세스 중에 리소스에 태그를 지정하고 장기 액세스 제어를 위해 해당 태그에 의존할 수 있습니다. 태깅된 리소스에 대한 액세스를 허용하는 권한 경계: ``` { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:ResourceTag/ManagedByPartnerDotCom": "false" }, "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ``` 생성 시 새 대기열에 태그를 지정하는 정책 템플릿: ``` { "Effect": "Allow", "Action": [ "sqs:CreateQueue", "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:RequestTag/ManagedByPartnerDotCom": "false" } } } ``` 기존 대기열에 태깅하고 역할을 생성하는 정책 템플릿: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": "ManagedByPartnerDotCom" } } }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] } ``` 이 접근 방식을 통해 고객은 장기적으로 액세스할 수 있는 특정 리소스를 명시적으로 확인할 수 있습니다. ### 예시 4: 권한 경계 업데이트 권한 경계를 업데이트하려면 새 버전을 새 날짜 접미사로 등록하고 대체 권한을 요청합니다. 추가 권한으로 권한 경계를 업데이트: ``` { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:PurgeQueue", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ``` 두 번째 버전으로 이 정책에는 ARN: arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$120이 있습니다. 기존 역할의 권한 경계를 업데이트하는 정책 템플릿: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PutRolePermissionsBoundary" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20" } } } ] } ``` 고객은 이 위임 요청을 승인하여 기존 역할에 대한 권한 경계를 업데이트해야 합니다. # 통합 구축 ## 요청 수명 주기 이해 통합을 구축하기 전에, 생성부터 완료까지 위임 요청이 어떻게 진행되는지 이해하는 것이 중요합니다. ### 요청 상태 위임 요청은 다음 상태로 진행됩니다. | State | 설명 | | --- | --- | | 할당되지 않음 | 요청이 생성되었지만 아직 고객 계정 및 IAM 위탁자와 연결되지 않았습니다. 요청이 대상 계정을 지정하지 않거나 대상 계정 ID로 생성되었지만 계정 소유자가 아직 요청하지 않았을 수 있습니다. | | 할당됨 | 요청이 고객 계정과 연결되고 검토 대기 중입니다. | | 승인 보류 중 | 고객이 승인을 위해 관리자에게 요청을 전달했습니다. | | 수락됨 | 고객이 요청을 승인했지만 교환 토큰이 아직 릴리스되지 않았습니다. | | 완료됨 | 교환 토큰이 제품 제공업체에 릴리스되었습니다. 위임 기간(교환 토큰 유효성)은 요청이 완료 상태에 도달하면 시작됩니다. | | 거부됨 | 고객이 요청을 거부함 | | 만료됨 | 비활성 또는 제한 시간으로 인해 요청이 만료되었습니다. | ### 상태 전환 *정상 흐름(승인 경로)* + 할당되지 않음 → 할당됨: 고객이 요청을 자신의 계정과 연결 + 할당됨 → 수락됨 또는 할당됨 → 승인 대기 중: 고객이 요청을 직접 승인하거나 검토를 위해 관리자에게 전달 + 승인 보류 중 → 수락됨: 관리자가 요청을 승인 + 수락됨 → 완료됨: 고객이 교환 토큰을 릴리스 *거부 경로* + 할당됨 → 거부됨: 고객이 요청을 거부 + 승인 보류 중 → 거부됨: 관리자가 요청을 거부 + 수락됨 → 거부됨: 고객이 토큰을 릴리스하기 전에 승인을 취소 *만료 경로* 지정된 기간 내에 조치를 취하지 않으면 요청이 자동으로 만료됩니다. + 할당되지 않음 → 만료됨(1일) + 할당됨 → 만료됨(7일) + 승인 대기 중 → 만료됨(7일) + 수락됨 → 만료됨(7일) + 거부됨 → 만료됨(7일) + 완료됨 → 만료됨(7일) *터미널 상태* 다음은 최종 상태입니다(추가 전환 없음). + 완료됨: 교환 토큰 전송됨 + 거부됨: 요청이 거부됨 + 만료됨: 요청 시간 초과 또는 위임 기간 종료 만료된 요청은 보존 기간 이후에 시스템에서 최종 삭제됩니다. ### 애플리케이션에서 위임 요청 상태 관리 파트너는 시스템에서 위임 요청 상태를 추적하고 고객에게 표시해야 합니다. 상태 변경에 대한 SNS 알림을 받으면 이러한 업데이트를 백엔드에 저장하고 고객용 UI에 반영합니다. 대기 중 승인 상태에 특히 주의하세요. 고객이 검토를 위해 관리자에게 요청을 전달하면 AWS가 대기 중 승인 알림을 보냅니다. 요청은 관리자 작업을 기다리는 동안 최대 7일 동안이 상태를 유지할 수 있습니다. 이 시간 동안 고객의 요청이 애플리케이션에서 관리자 승인 대기 중임을 고객에게 보여줍니다. 고객이 요청 상태를 확인하거나 관리자에게 후속 조치를 취할 수 있는 AWS Console에 대한 딥 링크를 제공하는 것이 좋습니다. 백엔드에서 상태 시스템을 올바르게 처리하고 각 단계에서 고객에게 올바른 상태 정보를 표시하는 것이 우수한 통합 경험을 위해 중요합니다. ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/delegation-states.png) ## 알림 구성 IAM은 Amazon Simple Notification Service(SNS)를 사용하여 위임 요청 상태 변경 사항을 사용자에게 전달합니다. 위임 요청을 생성할 때 등록된 AWS 계정의 SNS 주제 ARN을 제공해야 합니다. IAM은 고객이 요청을 승인 또는 거부할 때와 교환 토큰이 준비될 때를 포함하여 중요한 이벤트에 대한 메시지를 이 주제에 게시합니다. **참고** SNS 주제는 옵트인 AWS 리전에 있을 수 없습니다. SNS 주제는 기본적으로 활성화된 AWS 리전에 있어야 합니다. 옵트인 리전 목록은 AWS 계정 관리 가이드의 AWS 리전 관리를 참조하세요. ### SNS 주제 구성 위임 요청 알림을 받으려면 메시지를 게시할 수 있는 IAM 권한을 부여하도록 SNS 주제를 구성해야 합니다. SNS 주제 정책에 다음 정책 문을 추가합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowIAMServiceToPublish", "Effect": "Allow", "Principal": { "Service": "iam.amazonaws.com" }, "Action": "SNS:Publish", "Resource": "arn:aws:sns:REGION:ACCOUNT-ID:TOPIC-NAME" } ] } ``` **중요** SNS 주제는 등록된 AWS 계정 중 하나에 있어야 합니다. IAM은 다른 계정의 SNS 주제를 수락하지 않습니다. 주제 정책이 올바르게 구성되지 않은 경우 상태 변경 알림 또는 교환 토큰이 수신되지 않습니다. ### 알림 유형 IAM은 두 가지 유형의 알림을 보냅니다. *StateChange 알림* 위임 요청이 새 상태(할당됨, 승인 보류 중, 수락됨, 완료됨, 거부됨, 만료됨)로 전환될 때 전송됩니다. *ExchangeToken 알림* 고객이 위임 토큰을 릴리스하면 전송됩니다(완료됨 상태). 이 알림에는 자격 증명을 얻는 데 필요한 교환 토큰이 포함되어 있습니다. ### 알림 상태 다음 위임 요청 상태에 대한 알림을 받게 됩니다. | State | 알림 유형 | 설명 | | --- | --- | --- | | 할당됨 | StateChange | 요청이 고객 계정과 연결되었습니다. | | 승인 보류 중 | StateChange | 고객이 승인을 위해 관리자에게 요청을 전달했습니다. | | 수락됨 | StateChange | 고객이 요청을 승인했지만 아직 토큰을 릴리스하지 않았습니다. | | 완료됨 | StateChange | 고객이 교환 토큰을 릴리스했습니다. | | 완료됨 | ExchangeToken | 이 알림에는 Exchange 토큰이 포함되어 있습니다. | | REJECTED | StateChange | 고객이 요청을 거부함 | | EXPIRED | StateChange | 완료 전에 요청이 만료됨 | ### 알림 메시지 형식 IAM은 표준 SNS 알림을 게시합니다. 위임 요청 정보는 메시지 필드에 JSON 문자열로 포함됩니다. *공통 필드(모든 알림)* | Field | Type | 설명 | | --- | --- | --- | | Type | 문자열 | ‘StateChange’ 또는 ‘ExchangeToken’ | | RequestId | 문자열 | IAM 위임 요청 ID | | RequestorWorkflowId | 문자열 | 요청을 생성할 때 제공한 워크플로 ID | | State | 문자열 | 요청의 현재 상태 | | OwnerAccountId | 문자열 | 고객의 AWS 계정 ID | | UpdatedAt | 문자열 | 상태 변경 시점의 타임스탬프(ISO 8601 형식) | *추가 필드(ExchangeToken 알림만 해당)* | Field | Type | 설명 | | --- | --- | --- | | ExchangeToken | 문자열 | AWS STS GetDelegatedAccessToken API를 사용하여 자격 증명과 교환할 토큰 | | ExpiresAt | 문자열 | 위임된 액세스가 만료되는 경우(ISO 8601 형식) | ### 알림 예제 *StateChange 알림* ``` { "Type": "Notification", "MessageId": "61ee8ad4-6eec-56b5-8f3d-eba57556aa13", "TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications", "Message": "{\"RequestorWorkflowId\":\"workflow-12345\",\"Type\":\"StateChange\",\"RequestId\":\"dr-abc123\",\"State\":\"ACCEPTED\",\"OwnerAccountId\":\"111122223333\",\"UpdatedAt\":\"2025-01-15T10:30:00.123Z\"}", "Timestamp": "2025-01-15T10:30:00.456Z", "SignatureVersion": "1", "Signature": "...", "SigningCertURL": "...", "UnsubscribeURL": "..." } ``` *ExchangeToken 알림* ``` { "Type": "Notification", "MessageId": "e44e5435-c72c-5333-aba3-354406782f5b", "TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications", "Message": "{\"RequestId\":\"dr-abc123\",\"RequestorWorkflowId\":\"workflow-12345\",\"State\":\"FINALIZED\",\"OwnerAccountId\":\"111122223333\",\"ExchangeToken\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\"ExpiresAt\":\"2025-01-15T18:30:00.123Z\",\"UpdatedAt\":\"2025-01-15T10:30:00.456Z\",\"Type\":\"ExchangeToken\"}", "Timestamp": "2025-01-15T10:30:00.789Z", "SignatureVersion": "1", "Signature": "...", "SigningCertURL": "...", "UnsubscribeURL": "..." } ``` ## 교환 토큰 고객이 위임 요청을 수락하고 완료하면 IAM에서 교환 토큰 또는 거래 토큰이 발급됩니다. 제품 제공업체는 이 교환 또는 거래 토큰을 사용하여 AWS AWS STS GetDelegatedAccessToken API를 직접 호출함으로써 고객이 승인한 권한으로 임시 AWS 자격 증명을 얻습니다. 교환 토큰 자체는 AWS 리소스에 대한 액세스 권한을 부여하지 않으므로 AWS STS를 통해 실제 자격 증명으로 교환해야 합니다. 교환 토큰은 위임 요청을 생성한 제품 제공업체 계정에서만 사용할 수 있습니다. 요청 계정은 토큰에 포함되어 있으므로 승인된 제품 제공업체만 고객 계정에 액세스할 수 있는 자격 증명을 얻을 수 있습니다. ### 액세스 기간 위임 기간은 고객이 교환 토큰을 릴리스할 때 시작되며 제품 제공업체가 교환 토큰을 사용할 때가 아닙니다. 고객이 토큰을 릴리스하면: + 제품 제공업체가 SNS 알림을 통해 토큰을 수신합니다. + 자격 증명으로 즉시 교환할 수 있습니다. + 자격 증명 만료 시점: 릴리스 시간 \$1 승인 기간 + 제품 제공업체는 만료 전에 토큰을 여러 번 교환하여 필요한 경우 새 자격 증명을 얻을 수 있습니다. ### 다중 재시도 제품 제공업체는 유효 기간 동안 토큰을 여러 번 교환하여 새 자격 증명을 얻을 수 있습니다. 하지만 동일한 교환 토큰에서 얻은 모든 자격 증명은 토큰을 릴리스한 시기에 따라 동시에 만료됩니다. 예: 2시간 위임 요청을 승인하고 오전 10시에 토큰을 릴리스하는 경우: | 토큰 릴리스 시간 | 토큰 교환 시간 | 자격 증명 만료 | 사용 가능한 시간 | | --- | --- | --- | --- | | 오전 10시 00분 | 오전 10시 00분 | 오후 12시 | 2시간 | | 오전 10시 00분 | 오전 10시 20분 | 오후 12시 | 1시간 40분 | | 오전 10시 00분 | 오전 11시 40분 | 오후 12시 | 20분 | | 오전 10시 00분 | 오후 12:10 | 실패(토큰 만료됨) | 0분 | 표에 나와 있듯이 유효 기간 후반에 토큰을 교환하면 제품 제공업체의 사용 시간이 줄어듭니다.