# IAM 역할 생성
역할을 생성하려면 AWS Management Console, AWS CLI, Tools for Windows PowerShell 또는 IAM API를 사용할 수 있습니다.
AWS Management Console을 사용하는 경우 마법사가 역할 생성 절차를 단계별로 안내합니다. 마법사의 진행 단계는 생성하는 역할 대상이 AWS 서비스일 때, AWS 계정일 때, 혹은 SAML 또는 OIDC 페더레이션 보안 주체일 때에 따라 약간 다릅니다.
**IAM 사용자 역할**
이 역할을 생성하여 AWS 계정 내에 또는 소유하고 있는 다른 AWS 계정에 정의된 역할에 권한을 위임합니다. 한 계정의 사용자는 동일한 또는 다른 계정의 역할로 전환할 수 있습니다. 사용자는 역할을 사용하는 동안 해당 작업만을 수행하고 해당 역할에서 허용한 리소스만 액세스할 수 있지만, 이들의 원래 사용자 권한은 일시 중지된 상태입니다. 사용자가 역할을 끝내면 원래 사용자 권한이 회복됩니다.
자세한 내용은 [IAM 사용자에게 권한을 부여할 역할 생성](id_roles_create_for-user.md) 섹션을 참조하세요.
크로스 계정 액세스 역할 생성에 대한 자세한 내용은 [사용자 지정 트러스트 정책을 사용하여 역할 생성](id_roles_create_for-custom.md)의 내용을 참조하세요.
**AWS 서비스 역할**
이 역할을 생성하여 사용자 대신 작업을 수행할 권한을 부여하는 역할을 서비스에 위임합니다. 서비스에 전달하는 [서비스 역할](id_roles.md#iam-term-service-role)에는 서비스가 해당 서비스와 연결된 작업을 수행할 수 있도록 허용하는 권한이 포함된 IAM 정책이 있어야 합니다. 각 AWS 서비스마다 서로 다른 권한이 필요합니다.
서비스 역할 생성에 대한 자세한 내용은 [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md)의 내용을 참조하세요.
서비스 연결 역할 생성에 대한 자세한 내용은 [서비스 연결 역할 생성](id_roles_create-service-linked-role.md)의 내용을 참조하세요.
**ID 페더레이션 역할**
이 역할을 생성하여 AWS 외부에 이미 ID가 있는 사용자에게 권한을 위임합니다. 자격 증명 공급자를 사용하면 사용자 지정 로그인 코드를 생성할 필요도, 그리고 자신의 사용자 자격 증명을 관리할 필요도 없습니다. 외부 사용자는 IdP를 통해 로그인하고, 이러한 외부 자격 증명에 계정의 AWS 리소스를 사용할 권한을 제공할 수 있습니다. ID 제공업체를 사용하면 애플리케이션에서 사용자 액세스 키 같은 장기 보안 자격 증명을 배포하거나 포함할 필요가 없으므로 AWS 계정을 안전하게 보호할 수 있습니다.
자세한 내용은 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.
# IAM 사용자에게 권한을 부여할 역할 생성
IAM 역할을 사용해 AWS 리소스에 대한 액세스 권한을 제공할 수 있습니다. IAM 역할을 사용해 *신뢰하는* 계정과 다른 AWS *신뢰받는* 계정 간에 신뢰 관계를 설정할 수 있습니다. 신뢰하는 계정은 액세스되는 리소스를 소유하고 신뢰받는 계정은 리소스에 대한 액세스가 필요한 사용자를 저장합니다. 그러나, 다른 계정이 해당 계정의 리소스를 소유할 수 있는 가능성이 있습니다. 예를 들어, 신뢰받는 계정은 신뢰 계정이 Amazon S3 버킷의 새로운 객체를 생성하는 것처럼 새로운 리소스를 생성하도록 허용할 수 있습니다. 이러한 경우, 리소스를 생성하는 계정은 리소스를 소유하고 누구에게 리소스에 대한 액세스를 부여할지 제어합니다.
신뢰 관계를 생성한 후 신뢰받는 계정의 IAM 사용자 또는 애플리케이션은 AWS Security Token Service(AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업을 사용할 수 있습니다. 이 작업은 계정의 AWS 리소스에 액세스할 수 있는 임시 보안 자격 증명을 제공합니다.
계정은 둘 다 직접 제어할 수 있거나 사용자가 속한 계정의 경우 타사가 제어할 수 있습니다. 사용자가 있는 다른 계정이 귀하가 제어하지 않는 AWS 계정에 있는 경우 `externalId` 속성을 사용할 수 있습니다. 외부 ID는 나와 서드 파티 계정의 관리자 간에 합의한 숫자 또는 단어가 될 수 있습니다. 이 옵션은 요청에 올바른 `sts:ExternalID`가 포함된 경우에만 사용자가 역할을 맡을 수 있도록 허용하는 조건을 신뢰 정책에 자동으로 추가합니다. 자세한 내용은 [타사가 소유한 AWS 계정에 액세스](id_roles_common-scenarios_third-party.md) 섹션을 참조하세요.
역할을 사용해 권한을 위임하는 방법에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요. 서비스 연결을 사용하여 서비스가 해당 계정의 리소스에 액세스할 수 있도록 허용하는 방법은 [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md) 섹션을 참조하세요.
## IAM 역할 생성(콘솔)
AWS Management Console을 사용하여 IAM 사용자가 수임할 수 있는 역할을 생성할 수 있습니다. 예를 들면 프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자가 프로덕션 계정의 리소스에 액세스할 수 있도록 하는 역할 생성에 대한 개괄적 정보는 [분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example) 섹션을 참조하세요.
**최소 권한**
다음 단계를 수행하려면 적어도 다음과 같은 IAM 권한이 있어야 합니다.
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`
------
#### [ Console ]
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 콘솔의 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **AWS 계정** 역할 유형을 선택합니다.
1. 계정에 대한 역할을 생성하려면 **이 계정(This account)**을 선택합니다. 다른 계정에 대한 역할을 생성하려면 **다른 AWS 계정**을 선택하고 리소스에 대한 액세스 권한을 부여할 **계정 ID**를 입력합니다.
지정된 계정의 관리자는 해당 계정의 IAM 사용자에게 이 역할을 수임할 수 있는 권한을 부여할 수 있습니다. 이를 위해 관리자는 `sts:AssumeRole` 작업에 대한 권한을 부여하는 정책을 사용자나 그룹에 연결합니다. 이 정책은 역할의 ARN을 `Resource`로 지정해야 합니다.
1. 통제권이 없는 계정의 사용자에게 권한을 부여하려면 사용자는 이 역할을 프로그래밍 방식으로 가정하고 **외부 ID 필요(Require external ID)**를 선택합니다. 외부 ID는 나와 서드 파티 계정의 관리자 간에 합의한 숫자 또는 단어가 될 수 있습니다. 이 옵션은 요청에 올바른 `sts:ExternalID`가 포함된 경우에만 사용자가 역할을 맡을 수 있도록 허용하는 조건을 신뢰 정책에 자동으로 추가합니다. 자세한 내용은 [타사가 소유한 AWS 계정에 액세스](id_roles_common-scenarios_third-party.md) 섹션을 참조하세요.
**중요**
이 옵션을 선택하면 역할로의 액세스가 AWS CLI, Tools for Windows PowerShell 또는 AWS API를 통해서만 가능하도록 제한됩니다. 이는 AWS 콘솔을 사용해 해당 신뢰 정책에 `externalId` 조건이 있는 역할로 전환할 수 없기 때문입니다. 하지만 관련 SDK를 통해 스크립트나 애플리케이션을 작성하여 프로그래밍 방식으로 이러한 종류의 액세스를 만들 수 있습니다. 자세한 내용 및 샘플 스크립트는 AWS 보안 블로그의 [AWS Management Console에 대한 크로스 계정 액세스를 가능하게 하는 방법](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)을 참조하세요.
1. 멀티 팩터 인증(MFA)으로 로그인하는 사용자로 역할을 제한하려면, **Require MFA(MFA 필요)**를 선택합니다. 이렇게 하면 MFA 로그인을 확인하는 역할의 신뢰 정책에 조건이 추가됩니다. 역할을 맡으려는 사용자는 구성된 MFA 디바이스에서 임시 일회용 암호로 로그인해야 합니다. MFA 인증을 사용하지 않는 사용자는 역할을 맡을 수 없습니다. MFA에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.
1. **다음**을 선택합니다.
1. IAM은 계정의 AWS 관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 **정책 생성**을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. 역할을 위임하려는 대상에 제공할 권한 정책 옆의 확인란을 선택하세요. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.
1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 고급 기능입니다.
**권한 경계 설정** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용**을 선택합니다. 정책을 선택하여 권한 경계를 사용합니다.
1. **다음**을 선택합니다.
1. **역할 이름**에 역할의 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 역할 이름이 정책에서 또는 ARN의 일부로 사용되는 경우 역할 이름은 대소문자를 구분합니다. 콘솔에서 고객에게 역할 이름이 표시되는 경우(예: 로그인 프로세스 중) 역할 이름은 대소문자를 구분하지 않습니다. 다양한 엔터티가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.
1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.
1. **1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities)** 또는 **2단계: 권한 추가(Step 2: Add permissions)** 섹션에서 **편집(Edit)**을 선택하여 역할에 대한 사용 사례와 권한을 편집합니다. 편집을 위해 이전 페이지로 돌아갑니다.
1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.
1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
**중요**
필요한 구성의 절반이 끝났습니다. 이제 신뢰할 수 있는 계정의 개별 사용자에게 콘솔의 역할로 전환하거나 역할을 프로그래밍 방식으로 위임할 수 있는 권한을 부여해야 합니다. 이 단계에 대한 자세한 내용은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.
------
## IAM 역할 생성(AWS CLI)
AWS CLI에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 AWS CLI를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.
**크로스 계정 액세스에 대한 역할을 만들려면(AWS CLI)**
1. 역할 생성: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)
1. 역할에 관리형 권한 정책 연결: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
또는
역할을 위한 인라인 권한 정책 생성: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 역할에 추가: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
자세한 내용은 [IAM 역할의 태그 관리(AWS CLI 또는 AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api) 섹션을 참조하세요.
1. (선택 사항) 역할([aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.
이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.
다음 예는 단순한 환경에서 크로스 계정 역할을 생성하는 가장 일반적인 단계 중 첫 두 단계를 보여줍니다. 이 예제는 `123456789012` 계정에 있는 모든 사용자가 역할을 수임하고 `example_bucket` Amazon S3 버킷을 볼 수 있도록 허용합니다. 이 예제에서도 Windows가 구동되는 클라이언트 컴퓨터를 사용 중이며 명령줄 인터페이스를 계정 자격 증명 및 리전으로 이미 구성했다고 가정합니다. 자세한 내용은 [AWS 명령줄 인터페이스 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)을 참조하세요.
이 예제는 역할을 생성할 경우 첫 번째 명령의 다음 신뢰 정책을 포함합니다. 이 신뢰 정책은 `123456789012` 계정에서 사용자가 `AssumeRole` 작업을 사용하여 역할을 가정할 수 있도록 허용합니다. 단, 사용자가 `SerialNumber` 및 `TokenCode` 파라미터를 사용하는 MFA 인증을 제공하는 경우에만 허용합니다. MFA에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
]
}
```
------
**중요**
`Principal` 요소에 특정 IAM 역할 또는 사용자에 대한 ARN이 포함되어 있으면, 정책을 저장할 때 해당 ARN이 고유 보안 주체 ID로 변환됩니다. 그러면 누군가가 해당 역할 또는 사용자를 제거하고 다시 만들어 본인의 권한을 에스컬레이션할 위험을 완화할 수 있습니다. 일반적으로 콘솔에서는 이 ID가 보이지 않습니다. 신뢰 정책이 표시될 때 해당 ARN으로 다시 역변환되기 때문입니다. 그러나 역할 또는 사용자를 삭제할 경우, 보안 주체 ID가 콘솔에 표시됩니다. AWS에서 더 이상 이를 ARN에 다시 매핑할 수 없기 때문입니다. 따라서 신뢰 정책의 `Principal` 요소에서 참조된 사용자 또는 역할을 삭제하고 다시 생성하는 경우, ARN을 바꾸도록 역할을 편집해야 합니다.
두 번째 명령을 사용할 경우, 기존 관리형 정책을 역할에 연결해야 합니다. 다음 권한 정책에서는 역할을 수임하는 사용자가 `example_bucket` Amazon S3 버킷에서 `ListBucket` 작업만 수행하도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
]
}
```
------
이 `Test-UserAccess-Role` 역할을 생성하기 위해서는 이전 신뢰 정책을 `trustpolicyforacct123456789012.json` 이름으로 로컬 `policies` 드라이브의 `C:` 폴더에 먼저 저장해야 합니다. 그런 다음 이전 권한 정책을 고객 관리형 정책으로서 `PolicyForRole` 이름으로 AWS 계정에 저장합니다. 그러고 나면 다음 명령을 사용하여 역할을 만들고 관리형 정책을 연결합니다.
```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json
# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```
**중요**
필요한 구성의 절반이 끝났습니다. 이제 신뢰할 수 있는 계정의 개별 사용자에게 역할로 전환할 수 있는 권한을 부여해야 합니다. 이 단계에 대한 자세한 내용은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.
역할을 만든 다음 AWS 작업을 수행하거나 AWS 리소스에 액세스할 수 있는 권한을 부여해야 `123456789012` 계정의 사용자가 역할을 위임할 수 있습니다. 자세한 내용은 [IAM 역할로 전환(AWS CLI)](id_roles_use_switch-role-cli.md) 섹션을 참조하세요.
## IAM 역할 생성(AWS API)
AWS API에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 API를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.
**코드로 역할을 만들려면(AWS API)**
1. 역할 만들기: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
역할의 신뢰 정책에 대해 파일 위치를 지정할 수 있습니다.
1. 역할에 관리형 권한 정책 연결: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
또는
역할을 위한 인라인 권한 정책 생성: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
**중요**
필요한 구성의 절반이 끝났습니다. 이제 신뢰할 수 있는 계정의 개별 사용자에게 역할로 전환할 수 있는 권한을 부여해야 합니다. 이 단계에 대한 자세한 내용은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.
1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 사용자에게 추가: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
자세한 내용은 [IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)](id_tags_users.md#id_tags_users_procs-cli-api) 섹션을 참조하세요.
1. (선택 사항) 역할([PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.
이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.
역할을 만든 다음 AWS 작업을 수행하거나 AWS 리소스에 액세스할 수 있는 권한을 부여해야 계정의 사용자에게 권한을 부여하여 역할을 위임할 수 있습니다. 역할 위임하기에 대한 자세한 내용은 [IAM 역할로 전환(AWS API)](id_roles_use_switch-role-api.md) 섹션을 참조하세요.
## IAM 역할 생성(AWS CloudFormation)
AWS CloudFormation에서 IAM 역할을 생성하는 방법에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [리소스 및 속성 참조](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html)와 [예제](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples)를 참조하세요.
AWS CloudFormation의 IAM 템플릿에 관한 자세한 정보는 *AWS CloudFormation 사용 설명서*의 [AWS Identity and Access Management 템플릿 코드 조각](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)을 참조하세요.
# AWS 서비스에 대한 권한을 위임할 역할 생성
AWS 서비스는 역할을 사용하여 서비스가 사용자를 대신하여 다른 서비스의 리소스로 액세스할 수 있어야 합니다. 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임한 역할을 [서비스 역할](id_roles.md#iam-term-service-role)이라고 합니다. 역할이 서비스에 대해 특수한 목적을 수행하는 경우 [서비스 연결 역할](id_roles.md#iam-term-service-linked-role)로 분류됩니다. 서비스 연결 역할을 사용하여 지원되는 서비스 또는 서비스가 임시 자격 증명의 형식을 지원하는지 여부를 확인하려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요. 개별 서비스가 역할을 사용하는 방법을 알아보려면 테이블에서 서비스 이름을 선택하여 해당 서비스의 설명서를 확인합니다.
`PassRole` 권한을 설정할 때 사용자에게 부여하려는 역할보다 더 많은 권한이 있는 역할을 사용자가 넘기지 않도록 해야 합니다. 예를 들어 Alice가 Amazon S3 작업을 수행하는 것이 허용되지 않을 수 있습니다. Alice가 Amazon S3 작업을 허용하는 서비스에 역할을 넘길 수 있으면 해당 서비스에서 작업 실행 시 Alice를 대신하여 Amazon S3 작업을 수행할 수 있습니다.
역할을 통해 권한을 위임하는 방법에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요.
## 서비스 역할 권한
IAM 엔터티(사용자 또는 역할)가 서비스 연결 역할을 작성하거나 편집할 수 있도록 권한을 구성해야 합니다.
**참고**
서비스 연결 역할의 ARN에는 다음 정책에 `SERVICE-NAME.amazonaws.com`으로 표시된 서비스 보안 주체가 포함됩니다. 서비스 보안 주체는 대소문자를 구분하고 AWS 서비스마다 형식이 다를 수 있으므로 추측하지 마세요. 서비스의 보안 주체를 보려면 해당 서비스 링크된 역할 설명서 섹션을 참조하세요.
**IAM 엔터티가 특정 서비스 역할을 생성하도록 허용하려면**
서비스 역할을 생성해야 하는 IAM 엔터티에 다음 정책을 추가합니다. 이 정책으로 특정 서비스에 대하여 구체적인 이름이 있는 서비스 역할을 만들 수 있습니다. 그런 다음 관리형 또는 인라인 정책을 해당 역할에 연결할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
]
}
```
------
**IAM 엔터티가 모든 서비스 역할을 생성하도록 허용하려면**
AWS에서는 관리 사용자만 서비스 역할을 생성할 수 있도록 허용하는 것이 좋습니다. 역할을 생성하고 정책을 연결할 수 있는 권한이 있는 사람은 자신의 권한을 에스컬레이션할 수 있습니다. 대신 필요한 역할만 생성하거나 관리자가 대신 서비스 역할을 생성하도록 허용하는 정책을 만듭니다.
관리자가 사용자 전체 AWS 계정에 액세스할 수 있도록 허용하는 정책을 연결하려면 [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS 관리형 정책을 사용합니다.
**IAM 엔터티가 서비스 역할을 편집할 수 있도록 허용하려면**
서비스 역할을 편집해야 하는 IAM 엔터티에 다음 정책을 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EditSpecificServiceRole",
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:PutRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
},
{
"Sid": "ViewRolesAndPolicies",
"Effect": "Allow",
"Action": [
"iam:GetPolicy",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
------
**IAM 엔터티가 특정 서비스 역할을 삭제하도록 허용하려면**
특정 서비스 역할을 삭제해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.
```
{
"Effect": "Allow",
"Action": "iam:DeleteRole",
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```
**IAM 엔터티가 모든 서비스 역할을 삭제하도록 허용하려면**
AWS에서는 관리 사용자만 서비스 역할을 삭제할 수 있도록 허용하는 것이 좋습니다. 대신, 필요한 역할만 삭제하거나 관리자가 대신 서비스 역할을 삭제하도록 허용하는 정책을 만듭니다.
관리자가 사용자 전체 AWS 계정에 액세스할 수 있도록 허용하는 정책을 연결하려면 [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS 관리형 정책을 사용합니다.
## AWS 서비스에 대한 역할 생성(콘솔)
AWS Management Console을 사용하여 서비스의 역할을 만들 수 있습니다. 일부 서비스는 두 개 이상의 서비스 역할을 지원하기 때문에 어떤 사용 사례를 선택할지 확인하려면 해당 서비스의 [AWS 설명서](https://docs.aws.amazon.com/) 섹션을 참조하세요. 서비스에서 역할을 위임할 수 있도록 역할에 필요한 신뢰 정책과 권한 정책을 할당하는 방법을 알아볼 수 있습니다. 역할에 대한 권한을 관리할 수 절차는 서비스가 어떻게 사용 사례를 정의하느냐와 서비스 링크된 역할을 생성할 수 있는지 여부에 따라 다양할 수 있습니다.
------
#### [ Console ]
**AWS 서비스의 역할을 생성하는 방법(IAM 콘솔)**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. IAM 콘솔의 탐색 창에서 **역할**을 선택하고 **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 유형**에서 **AWS 서비스**를 선택합니다.
1. **서비스 또는 사용 사례**의 경우 서비스를 선택한 다음, 사용 사례를 선택합니다. 사용 사례는 서비스에 필요한 신뢰 정책을 포함하도록 서비스에서 정의합니다.
1. **다음**을 선택합니다.
1. **권한 정책**의 경우 선택한 사용 사례에 따라 옵션이 달라집니다.
+ 서비스가 역할에 대한 권한을 정의하는 경우 권한 정책을 선택할 수 없습니다.
+ 제한된 권한 정책 세트에서 선택합니다.
+ 모든 권한 정책에서 선택합니다.
+ 권한 정책 없음을 선택하고 역할이 생성된 후 정책을 생성한 다음, 정책을 역할에 연결합니다.
1. (선택 사항) [권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 선택합니다. 이는 서비스 역할에서 사용 가능한 고급 기능이며 서비스에 연결된 역할은 아닙니다.
1. **권한 경계 설정** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용**을 선택합니다.
IAM은 계정의 AWS 관리형 또는 고객 관리형 정책 목록을 포함합니다.
1. 정책을 선택하여 권한 경계를 사용합니다.
1. **다음**을 선택합니다.
1. **역할 이름**의 경우 옵션은 서비스에 따라 달라집니다.
+ 서비스에서 역할 이름을 정의하는 경우 이 역할 이름을 편집할 수 없습니다.
+ 서비스에서 역할 이름에 대한 접두사를 정의하는 경우 사용자가 선택적 접미사를 입력할 수 있습니다.
+ 서비스에서 역할 이름을 정의하지 않는 경우 역할 이름을 지정할 수 있습니다.
**중요**
역할 이름을 지정할 때는 다음 사항에 유의하세요.
역할 이름은 AWS 계정 내에서 고유해야 하지만 대소문자를 구분하지는 않습니다.
예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들지 마세요. 역할 이름이 정책 또는 ARN의 일부로 사용되는 경우 역할 이름은 대소문자를 구분합니다. 그러나 로그인 프로세스와 같이 콘솔에서 역할 이름이 고객에게 표시되는 경우에는 역할 이름이 대소문자를 구분하지 않습니다.
다른 엔터티가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.
1. (선택 사항) **설명**에 역할에 대한 설명을 입력합니다.
1. (선택 사항) 역할에 대한 사용 사례와 권한을 편집하려면 **1단계: 신뢰할 수 있는 엔터티 선택** 또는 **2단계: 권한 추가** 섹션에서 **편집**을 선택합니다.
1. (선택 사항) 역할을 식별, 구성 또는 검색하려면 태그를 키-값 페어로 추가합니다. IAM에서 태그 사용에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS Identity and Access Management 리소스용 태그](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)를 참조하세요.
1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
------
## 서비스에 대한 역할 생성(AWS CLI)
AWS CLI에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 AWS CLI를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 작업 중인 서비스가 Amazon EC2인 경우에도 인스턴스 프로파일을 생성하여 거기에 역할을 추가해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.
**AWS CLI에서 AWS 서비스에 대한 역할을 만들려면**
1. 다음 `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` 명령은 *Test-Role*이라는 역할을 생성하고 해당 역할에 신뢰 정책을 연결합니다.
`aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`
1. 역할에 관리형 권한 정책 연결: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html).
예를 들어 `attach-role-policy` 명령은 `ReadOnlyAccess`라는 AWS 관리형 정책을 `ReadOnlyRole`이라는 IAM 역할에 연결합니다.
`aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`
또는
역할을 위한 인라인 권한 정책 생성: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
인라인 권한 정책을 추가하려면 다음 예제를 참조하세요.
`aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`
1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 역할에 추가: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
자세한 내용은 [IAM 역할의 태그 관리(AWS CLI 또는 AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api) 섹션을 참조하세요.
1. (선택 사항) 역할([aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.
이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.
Amazon EC2 또는 Amazon EC2를 사용하는 다른 AWS 서비스에 대해 역할을 사용할 경우 인스턴스 프로파일에 역할을 저장해야 합니다. 인스턴스 프로파일은 시작할 때 Amazon EC2 인스턴스에 연결할 수 있는 역할을 위한 컨테이너입니다. 하나의 인스턴스 프로파일은 하나의 역할만 포함할 수 있으며 이 제한은 늘릴 수 없습니다. AWS Management Console을 사용하여 역할을 생성한 경우 역할과 동일한 이름을 지닌 인스턴스 프로파일이 자동으로 생성됩니다. 인스턴스 프로파일에 대한 자세한 내용은 [인스턴스 프로파일 사용](id_roles_use_switch-role-ec2_instance-profiles.md) 섹션을 참조하세요. 역할을 사용하여 EC2 인스턴스를 시작하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)를 참조하세요.
**인스턴스 프로파일을 만들고 여기에 역할을 저장하려면(AWS CLI)**
1. 인스턴스 프로파일 생성: [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)
1. 인스턴스 프로파일에 역할 추가: [aws iam add-role-to-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html)
아래 AWS CLI 예제 명령 집합은 역할을 생성하고 권한을 연결하는 첫 두 단계를 보여줍니다. 인스턴스 프로파일을 생성하고 프로필에 역할을 추가하는 두 단계를 보여주기도 합니다. 이 예제 신뢰 정책은 Amazon EC2 서비스가 역할을 수임하고 `example_bucket` Amazon S3 버킷을 볼 수 있도록 허용합니다. 이 예제에서는 Windows를 실행하는 클라이언트 컴퓨터에서 실행 중이며 계정 자격 증명 및 리전으로 이미 명령줄 인터페이스를 구성했다고도 가정합니다. 자세한 내용은 [AWS 명령줄 인터페이스 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)을 참조하세요.
이 예제는 역할을 생성할 경우 첫 번째 명령의 다음 신뢰 정책을 포함합니다. 이 신뢰 정책은 Amazon EC2 서비스가 역할을 수임하도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
```
------
두 번째 명령을 사용할 경우, 권한 정책을 역할에 연결해야 합니다. 다음 예제 권한 정책에서는 역할이 `example_bucket` Amazon S3 버킷에서 `ListBucket` 작업만 수행하도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
이 `Test-Role-for-EC2` 역할을 생성하기 위해서는 먼저 이전 신뢰 정책을 `trustpolicyforec2.json` 이름으로, 이전 권한 정책을 `permissionspolicyforec2.json` 이름으로 로컬 `C:` 드라이브의 `policies` 디렉터리에 저장해야 합니다. 그러고 나면 다음 명령을 사용하여 역할을 만들고 인라인 정책을 연결, 인스턴스 프로파일 생성 및 인스턴스 프로파일에 역할을 추가합니다.
```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json
# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json
# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3
# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```
EC2 인스턴스를 시작할 때 AWS 콘솔을 사용하는 경우 **인스턴스 세부 정보 구성** 페이지에 인스턴스 프로파일 이름을 지정합니다. `aws ec2 run-instances` CLI 명령을 사용하는 경우 `--iam-instance-profile` 파라미터를 지정합니다.
## 서비스에 대한 역할 생성(AWS API)
AWS API에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 API를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 작업 중인 서비스가 Amazon EC2인 경우에도 인스턴스 프로파일을 생성하여 거기에 역할을 추가해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.
**AWS 서비스에 대한 역학을 생성하려면(AWS API)**
1. 역할 만들기: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
역할의 신뢰 정책에 대해 파일 위치를 지정할 수 있습니다.
1. 역할에 관리형 권한 정책 연결: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
또는
역할을 위한 인라인 권한 정책 생성: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 사용자에게 추가: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
자세한 내용은 [IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)](id_tags_users.md#id_tags_users_procs-cli-api) 섹션을 참조하세요.
1. (선택 사항) 역할([PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.
이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.
Amazon EC2 또는 Amazon EC2를 사용하는 다른 AWS 서비스에 대해 역할을 사용할 경우 인스턴스 프로파일에 역할을 저장해야 합니다. 인스턴스 프로파일은 역할에 대한 컨테이너입니다. 각 인스턴스 프로파일은 하나의 역할만 포함할 수 있으며 이 제한은 늘릴 수 없습니다. AWS Management Console에서 역할을 생성한 경우 역할과 동일한 이름을 지닌 인스턴스 프로파일이 자동으로 생성됩니다. 인스턴스 프로파일에 대한 자세한 내용은 [인스턴스 프로파일 사용](id_roles_use_switch-role-ec2_instance-profiles.md)을 참조하세요. 역할을 사용하여 Amazon EC2 인스턴스를 시작하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)를 참조하세요.
**인스턴스 프로파일을 만들고 여기에 역할을 저장하려면(AWS API)**
1. 인스턴스 프로파일 생성: [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html)
1. 인스턴스 프로파일에 역할 추가: [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html)
# 서비스 연결 역할 생성
서비스 연결 역할은 AWS 서비스에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 해당 서비스에서 사전 정의하며 서비스에서 다른 AWS 서비스를 직접적으로 자동 호출하기 위해 필요한 모든 권한을 포함합니다. 또한 연결된 서비스는 서비스 연결 역할을 만들고 수정하며 삭제하는 방법을 정의합니다. 서비스는 역할을 자동으로 만들거나 삭제할 수 있습니다. 서비스의 프로세스나 마법사를 사용하여 사용자가 역할을 만들거나 수정하거나 삭제하도록 허용할 수도 있습니다. 또는 사용자가 IAM을 사용하여 역할을 생성하거나 삭제해야 할 수도 있습니다. 방법과 관계없이 서비스 연결 역할은 서비스 설정 프로세스를 단순화합니다. 서비스가 사용자를 대신하여 작업을 완료하도록 권한을 수동으로 추가할 필요가 없기 때문입니다.
**참고**
서비스 역할은 서비스 연결 역할과 다르다는 점을 기억하세요. 서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하는 것으로 가정하는 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)입니다. IAM 관리자는 IAM 내에서 서비스 역할을 생성, 수정 및 삭제할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [Create a role to delegate permissions to an AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)를 참조하세요. 서비스 연결 역할은 AWS 서비스에 연결된 서비스 역할의 한 유형입니다. 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은 AWS 계정에 나타나고, 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.
연결된 서비스에서 서비스 연결 역할 권한을 정의하므로 정의되지 않은 경우에만 해당 역할로 서비스를 수행할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다.
역할을 삭제하려면 먼저 관련 리소스를 삭제해야 합니다. 이렇게 하면 리소스에 액세스할 수 있는 권한이 실수로 제거되는 것을 방지할 수 있습니다.
**작은 정보**
서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.
## 서비스 연결 역할 권한
사용자 또는 역할이 서비스 연결 역할을 작성하거나 편집할 수 있도록 IAM 엔터티(사용자 또는 역할)의 권한을 구성해야 합니다.
**참고**
서비스 링크된 역할에 대한 ARN은 정책에서 `SERVICE-NAME.amazonaws.com`으로 나타내지는 서비스 보안 주체를 포함합니다. 각 경우마다 다르고 AWS 서비스에 따라 형식이 다양하기 때문에 서비스 보안 주체를 알기 어렵습니다. 서비스의 보안 주체를 보려면 해당 서비스 링크된 역할 설명서 섹션을 참조하세요.
**IAM 엔터티가 특정 서비스 연결 역할을 만들 수 있도록 허용하려면**
서비스 연결 역할을 생성해야 하는 IAM 엔터티에 다음 정책을 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
"Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
]
}
```
------
**IAM 엔터티가 서비스 연결 역할을 생성할 수 있도록 허용하려면**
서비스 연결 역할 또는 필요한 정책을 포함해야 하는 모든 서비스 역할을 생성해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 이 정책 명령문은 IAM 엔터티가 역할에 정책을 연결하는 것을 허용하지 않습니다.
```
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**IAM 엔터티가 서비스 역할의 설명을 편집할 수 있도록 허용하려면**
서비스 연결 역할 또는 서비스 역할의 설명을 편집해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.
```
{
"Effect": "Allow",
"Action": "iam:UpdateRoleDescription",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**IAM 엔터티가 특정 서비스 연결 역할을 삭제하도록 허용하려면**
서비스 연결 역할을 삭제해야 하는 IAM 개엔터티의 권한 정책에 다음 명령문을 추가합니다.
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```
**IAM 엔터티가 서비스 연결 역할을 삭제할 수 있도록 허용하려면**
서비스 연결 역할만 삭제하고 서비스 역할은 삭제하지 않는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**IAM 엔터티가 기존 역할을 서비스에 전달하도록 허용하려면**
일부 AWS 서비스를 사용하면 새 서비스에 연결된 역할을 생성하지 않고, 그 대신에 서비스에 기존 역할을 전달할 수 있습니다. 이렇게 하려면 사용자에게 서비스에 *역할을 전달*할 수 있는 권한이 있어야 합니다. 역할을 생성해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 또한 이 정책 설명에서는 엔터티가 전달할 역할을 선택할 수 있는 역할 목록을 볼 수 있도록 허용합니다. 자세한 내용은 [사용자에게 AWS 서비스에 역할을 전달할 권한 부여](id_roles_use_passrole.md) 섹션을 참조하세요.
```
{
"Sid": "PolicyStatementToAllowUserToListRoles",
"Effect": "Allow",
"Action": ["iam:ListRoles"],
"Resource": "*"
},
{
"Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```
## 간접 권한과 서비스 연결 역할을 통한 간접 권한
서비스 연결 역할에서 부여한 권한은 간접적으로 다른 사용자 및 역할에게 양도할 수 있습니다. AWS 서비스가 서비스 연결 역할을 사용하는 경우 해당 서비스 연결 역할은 자체 권한을 사용하여 다른 AWS 서비스를 호출할 수 있습니다. 즉, 서비스 연결 역할을 사용하는 서비스를 호출할 권한이 있는 사용자 및 역할은 해당 서비스 연결 역할로 액세스할 수 있는 서비스에 간접적으로 액세스할 수 있습니다.
예를 들어, Amazon RDS DB 인스턴스를 생성할 때 [RDS용 서비스 연결 역할](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html)이 아직 존재하지 않는다면 자동으로 하나가 생성됩니다. 이렇게 생성된 서비스 연결 역할은 사용자가 DB 인스턴스를 편집할 때마다 RDS에게 사용자 대신 Amazon EC2, Amazon SNS, Amazon CloudWatch Logs 및 Amazon Kinesis를 호출하도록 허용합니다. 계정의 사용자 및 역할이 RDS 데이터베이스를 수정하거나 생성하도록 허용하면 RDS를 호출하여 Amazon EC2, Amazon SNS, Amazon CloudWatch Logs 로그 및 Amazon Kinesis 리소스와 간접적으로 상호 작용할 수 있습니다. RDS는 서비스 연결 역할을 사용하여 해당 리소스에 액세스하기 때문입니다.
### 서비스 연결 역할을 생성하는 방법
서비스 연결 역할을 만드는 데 사용하는 방법은 서비스에 따라 다릅니다. 경우에 따라 서비스 연결 역할을 수동으로 만들 필요가 없습니다. 예를 들어 사용자가 서비스의 특정 작업(리소스 만들기 등)을 수행할 때 서비스가 서비스 연결 역할을 자동으로 생성할 수 있습니다. 또한, 서비스가 서비스 연결 역할 지원을 시작하기 전에 서비스를 사용한 경우에는 서비스가 자동으로 해당 계정에 역할을 생성했을 수 있습니다. 자세한 내용은 [내 AWS 계정에 표시되는 새 역할](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared) 섹션을 참조하세요.
다른 경우에는 서비스에서 서비스 콘솔, API 또는 CLI를 사용하여 서비스 연결 역할을 수동으로 만들도록 허용할 수 있습니다. 서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 서비스가 서비스 연결 역할 생성을 지원하는지 여부를 알아보려면 **예** 링크를 선택하여 해당 서비스의 서비스 연결 역할 설명서 섹션을 참조하세요.
서비스가 역할 생성을 지원하지 않는 경우에는 IAM을 사용하여 서비스 연결 역할을 생성할 수 있습니다.
**중요**
서비스 연결 역할은 [AWS 계정의 IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities) 제한을 계산하는 데 포함되지만, 한도에 도달한 경우에도 계정에 서비스 연결 역할을 생성할 수 있습니다. 한도를 초과해도 생성할 수 있는 역할은 서비스 연결 역할뿐입니다.
### 서비스 연결 역할 만들기(콘솔)
IAM에서 서비스 연결 역할을 생성하기 전에, 연결된 서비스가 서비스 역할을 자동으로 생성하는지 확인합니다. 또한 서비스의 콘솔, API, CLI 등에서 역할을 생성할 수 있는지를 알아봅니다.
**서비스 연결 역할을 만드는 방법(콘솔)**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. IAM 콘솔의 탐색 창에서 **역할(Roles)**을 선택합니다. 그런 다음 **역할 생성**을 선택합니다.
1. **AWS 서비스** 역할 유형을 선택합니다.
1. 서비스의 사용 사례를 선택합니다. 사용 사례는 서비스에 필요한 신뢰 정책을 포함하기 위해 서비스에서 정합니다. 그리고 **다음(Next)**을 선택합니다.
1. 하나 이상의 권한 정책을 선택하여 역할에 연결합니다. 선택한 사용 사례에 따라 서비스에서 다음을 수행할 수 있습니다.
+ 역할에서 사용하는 권한을 정의할 수 있습니다.
+ 제한된 권한 세트에서 선택할 수 있습니다.
+ 모든 권한 중에서 선택할 수 있습니다.
+ 여기서 정책을 선택하지 않고, 나중에 정책을 만들어 역할에 연결할 수 있도록 허용합니다.
역할에 제공하려는 권한을 할당하는 정책 옆에 있는 확인란을 선택한 후 **다음**을 선택하세요.
**참고**
지정하는 권한은 역할을 사용하는 모든 주체가 사용할 수 있습니다. 기본적으로 역할은 권한이 없습니다.
1. **역할 이름**의 경우 역할 이름 사용자 지정 수준은 서비스에서 정합니다. 서비스에서 역할 이름을 정한 경우 이 옵션을 편집할 수 없습니다. 다른 경우에는 서비스에서 역할에 대한 접두사를 정의하고 사용자가 선택적 접미사를 입력할 수 있습니다.
가능한 경우 기본 이름에 추가할 역할 이름 접미사를 입력합니다. 이 접미사는 이 역할의 목적을 파악하는 데 도움이 됩니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어, 이름이 **\$1SAMPLE**과 **\$1sample**, 두 가지로 지정된 역할을 만들 수는 없습니다. 다양한 주체가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.
1. (선택 사항) **설명(Description)**에서 새로운 서비스 연결 역할에 대한 설명을 편집합니다.
1. 생성하는 동안에는 서비스 연결 역할에 태그를 연결할 수 없습니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.
1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
### 서비스 연결 역할 만들기(AWS CLI)
IAM에서 서비스 연결 역할을 만들기 전에, 연결된 서비스가 서비스 역할을 자동으로 생성하는지 그리고 서비스의 CLI에서 사용자가 역할을 만들 수 있는지를 확인합니다. 서비스 CLI가 지원되지 않는 경우 IAM 명령을 사용하여 서비스가 역할을 위임하는 데 필요한 인라인 정책과 신뢰 정책을 포함하는 서비스 연결 역할을 생성할 수 있습니다.
**서비스 연결 역할(AWS CLI)을 만들려면**
다음 명령을 실행합니다.
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```
### 서비스 연결 역할 만들기(AWS API)
IAM에서 서비스 연결 역할을 만들기 전에, 연결된 서비스가 서비스 역할을 자동으로 생성하는지 그리고 서비스의 API에서 사용자가 역할을 만들 수 있는지를 확인합니다. 서비스 API가 지원되지 않는 경우 AWS API를 사용하여 서비스가 역할을 위임하는 데 필요한 인라인 정책과 신뢰 정책을 포함하는 서비스 연결 역할을 만들 수 있습니다.
**서비스 연결 역할(AWS API)**을 만들려면
[CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API 호출을 사용합니다. 요청 시 `SERVICE_NAME_URL.amazonaws.com` 서비스 이름을 지정합니다.
예를 들어 **Lex 봇** 서비스 연결 역할을 만들려면 `lex.amazonaws.com`을 사용합니다.
# 타사 ID 공급자에 대한 역할 생성
AWS 계정에 속하는 IAM 사용자를 생성하는 대신에 자격 증명 공급자를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 연동 및 자격 증명 공급자에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.
## OIDC 및 SAML 페더레이션 보안 주체에 대한 역할 생성(콘솔)
페더레이션 사용자의 역할을 생성하는 절차는 타사 공급자 선택에 따라 다릅니다.
+ OIDC(OpenID Connect)에 대한 내용은 [OpenID Connect 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_oidc.md) 항목을 참조하세요.
+ SAML 2.0은 [SAML 2.0 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_saml.md) 섹션을 참조하세요.
## 페더레이션 액세스의 역할 만들기(AWS CLI)
AWS CLI에서 지원되는 자격 증명 공급자(OIDC 또는 SAML)의 역할을 만드는 절차는 동일합니다. 차이는 필수 선행 단계에서 생성하는 신뢰 정책의 내용에 있습니다. 사용하고 있는 공급자의 유형에 대한 **필수 선행 조건** 섹션에 나와 있는 절차에서부터 시작하세요.
+ OIDC 공급자의 경우 [OIDC 역할 생성을 위한 사전 조건](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites) 섹션을 참조하세요.
+ SAML 공급자의 경우 [SAML 역할을 생성하기 위한 사전 조건](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites) 섹션을 참조하세요.
AWS CLI에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 AWS CLI를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.
**역할 생성(AWS CLI)**
1. 역할 생성: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)
1. 역할에 권한 정책 연결: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
또는
역할을 위한 인라인 권한 정책 생성: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 역할에 추가: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
자세한 내용은 [IAM 역할의 태그 관리(AWS CLI 또는 AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api) 섹션을 참조하세요.
1. (선택 사항) 역할([aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.
이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.
다음 예는 단순한 환경에서 자격 증명 공급자를 생성하는 가장 일반적인 단계 중 첫 두 단계를 보여줍니다. 이 예제는 `123456789012` 계정에 있는 모든 사용자가 역할을 수임하고 `example_bucket` Amazon S3 버킷을 볼 수 있도록 허용합니다. 또한 이 예는 Windows가 구동중인 컴퓨터에서 AWS CLI를 실행하고 있으며 자격 증명으로 AWS CLI를 이미 구성했다고 가정합니다. 자세한 내용은 [AWS Command Line Interface 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) 섹션을 참조하세요.
다음 예는 사용자가 Amazon Cognito를 사용하여 로그인하는 경우 모바일 앱에 대해 설계되는 신뢰 정책을 보여줍니다. 이 예제에서 *us-east:12345678-ffff-ffff-ffff-123456*은 Amazon Cognito에 의해 할당된 자격 증명 풀 ID를 나타냅니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}
}
```
------
다음 권한 정책에서는 역할을 수임하는 사용자가 `example_bucket` Amazon S3 버킷에서 `ListBucket` 작업만 수행하도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
이 `Test-Cognito-Role` 역할을 생성하기 위해서는 이전 신뢰 정책을 `trustpolicyforcognitofederation.json` 이름으로 이전 권한 정책을 `permspolicyforcognitofederation.json` 이름으로 로컬 `policies` 드라이브의 `C:` 폴더에 먼저 저장해야 합니다. 그러고 나면 다음 명령을 사용하여 역할을 만들고 인라인 정책을 연결합니다.
```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json
# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```
## 페더레이션 액세스의 역할 만들기(AWS API)
AWS CLI에서 지원되는 자격 증명 공급자(OIDC 또는 SAML)의 역할을 만드는 절차는 동일합니다. 차이는 필수 선행 단계에서 생성하는 신뢰 정책의 내용에 있습니다. 사용하고 있는 공급자의 유형에 대한 **필수 선행 조건** 섹션에 나와 있는 절차에서부터 시작하세요.
+ OIDC 공급자의 경우 [OIDC 역할 생성을 위한 사전 조건](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites) 섹션을 참조하세요.
+ SAML 공급자의 경우 [SAML 역할을 생성하기 위한 사전 조건](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites) 섹션을 참조하세요.
**역할 생성(AWS API)**
1. 역할 만들기: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
1. 역할에 권한 정책 연결: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
또는
역할을 위한 인라인 권한 정책 생성: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 사용자에게 추가: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
자세한 내용은 [IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)](id_tags_users.md#id_tags_users_procs-cli-api) 섹션을 참조하세요.
1. (선택 사항) 역할([PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.
이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.
# OpenID Connect 페더레이션을 위한 역할 생성(콘솔)
AWS 계정에 AWS Identity and Access Management 사용자를 생성하는 대신 OpenID Connect(OIDC) 페더레이션형 ID 제공업체를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 페더레이션과 IdP에 대한 자세한 내용을 알아보려면 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.
## OIDC 역할 생성을 위한 사전 조건
OIDC 페더레이션을 위한 역할을 만들기 전에 먼저 다음 사전 조건 단계를 완료해야 합니다.
**OIDC 페더레이션을 위한 역할 생성 준비**
1. 페더레이션 OIDC ID를 제공하는 하나 이상의 서비스로 가입합니다. AWS 리소스로 액세스가 필요한 앱을 생성하면 공급자 정보로 앱도 구성합니다. 이렇게 하면 제공업체는 앱의 고유한 애플리케이션 및 시청자 ID를 제공합니다. (공급자마다 이 프로세스에 대해 다른 용어를 사용합니다. 이 가이드에서는 공급자에 앱을 식별하는 프로세스를 *구성*이라는 용어로 설명합니다.) 각 공급자로 여러 개의 앱을 구성하거나 단일 앱을 통해 다양한 공급자를 구성할 수 있습니다. 다음과 같이 ID 제공자에 대한 정보를 봅니다.
+ [Login with Amazon 개발자 센터](https://login.amazon.com/)
+ Facebook 개발자 사이트의 [앱 또는 웹 사이트에 Facebook 로그인 추가하기](https://developers.facebook.com/docs/facebook-login/v2.1)
+ Google 개발자 사이트의 [OAuth 2.0을 사용한 로그인(OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login)
1. IdP로부터 필요한 정보를 받은 후 IAM에서 IdP를 생성합니다. 자세한 내용은 [IAM에서 OIDC(OpenID Connect) ID 공급자 생성](id_roles_providers_create_oidc.md) 단원을 참조하세요.
**중요**
Google, Facebook 또는 Amazon Cognito의 OIDC IdP를 사용하는 경우 AWS Management Console에서 IAM IdP를 별도로 생성하지 마세요. 이러한 OIDC ID 제공자는 이미 AWS에 내장되어 있고 용도에 맞게 사용할 수 있습니다. 이 단계를 건너뛰고 다음 단계에서 IdP를 사용하여 새 역할을 생성합니다.
1. IdP를 통해 인증된 사용자가 맡을 역할에 대한 정책을 준비합니다. 다른 어떤 역할과 마찬가지로 모바일 앱을 위한 역할에는 2개의 정책이 포함됩니다. 하나는 역할을 위임할 사용자를 지정하는 신뢰 정책입니다. 다른 하나는 모바일 앱의 액세스가 허용 또는 거부되는 AWS 작업 및 리소스를 지정하는 권한 정책입니다.
웹 IdP의 경우, [Amazon Cognito](https://aws.amazon.com/cognito/)를 사용하여 보안 인증을 관리하는 것이 좋습니다. 이 경우 이 예제와 비슷한 신뢰 정책을 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
"ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
}
}
}
```
------
`us-east-2:12345678-abcd-abcd-abcd-123456`을 Amazon Cognito에서 할당하는 아이덴티티 풀 ID로 바꿉니다.
신뢰 정책을 생성할 때 OIDC IdP를 수동으로 구성하려면 자체 앱만이 이 역할을 수임한다고 보장하는 세 가지 값을 사용해야 합니다.
+ `Action` 요소에 대해서는 `sts:AssumeRoleWithWebIdentity` 작업을 사용하세요.
+ `Principal` 요소에 대해서는 `{"Federated":providerUrl/providerArn}` 문자열을 사용하세요.
+ 일부 범용 OIDC IdP의 경우, `providerUrl`이 URL입니다. 다음 예제는 일부 범용 IdP에 대해 보안 주체를 지정하는 방법을 포함합니다.
`"Principal":{"Federated":"cognito-identity.amazonaws.com"}`
`"Principal":{"Federated":"www.amazon.com"}`
`"Principal":{"Federated":"graph.facebook.com"}`
`"Principal":{"Federated":"accounts.google.com"}`
+ 다른 OIDC 제공업체의 경우, 다음 예제와 같이 [Step 2](#idpoidcstep2)에서 생성한 OIDC IdP의 Amazon 리소스 이름(ARN)을 사용합니다.
`"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
+ 권한을 제한하려면 `Condition` 요소에 `StringEquals` 조건을 사용합니다. 자격 증명 풀 ID(Amazon Cognito용) 또는 앱 ID(다른 공급자용)를 테스트합니다. 아이덴티티 풀 ID는 IdP를 통해 앱을 구성할 때 얻은 앱 ID와 일치해야 합니다. 이러한 ID 간의 일치는 요청이 앱에서 오는지 확인합니다.
**참고**
Amazon Cognito 자격 증명 풀의 IAM 역할은 서비스 보안 주체 `cognito-identity.amazonaws.com`의 역할 수임을 신뢰합니다. 이 유형의 역할에는 역할을 수임할 수 있는 보안 주체를 제한하기 위한 조건 키가 하나 이상 포함되어야 합니다.
[크로스 계정 IAM 역할](access_policies-cross-account-resource-access.md)을 수임하는 Amazon Cognito 자격 증명 풀에는 추가 고려 사항이 적용됩니다. 이러한 역할의 신뢰 정책은 `cognito-identity.amazonaws.com` 서비스 보안 주체를 수락해야 하며 의도한 자격 증명 풀의 사용자로 역할 수임을 제한하는 `aud` 조건 키를 포함해야 합니다. 이 조건 없이 Amazon Cognito 자격 증명 풀을 신뢰하는 정책은 의도하지 않은 자격 증명 풀의 사용자가 역할을 맡을 수 있는 위험을 야기합니다. 자세한 내용은 **Amazon Cognito 개발자 안내서의 [Trust policies for IAM roles in Basic (Classic) authentication](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies)을 참조하세요.
사용하는 IdP에 따라 다음 예제 중 하나와 비슷한 조건 요소를 생성합니다.
`"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`
`"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`
`"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`
`"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`
OIDC 공급자의 경우 다음 예시와 같이 `aud` 컨텍스트 키로 OIDC IdP의 정규화된 URL을 사용합니다.
`"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**참고**
역할의 신뢰 정책에서 보안 주체에 대한 값은 하나의 IdP에 고유합니다. OIDC 역할은 오직 하나의 보안 주체만을 지정할 수 있습니다. 따라서 모바일 앱이 사용자에게 1개 이상의 IdP에서 로그인할 수 있게 허용한다면 지원하고자 하는 각각의 IdP에 대한 개별 역할을 생성합니다. 각 IdP에 대한 개별 신뢰 정책을 생성합니다.
사용자가 모바일 앱을 사용하여 Login with Amazon에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 예제에서 *amzn1.application-oa2-123456*은 Login with Amazon을 이용해 앱을 구성할 때 Amazon에서 할당하는 앱 ID를 나타냅니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForLoginWithAmazon",
"Effect": "Allow",
"Principal": {"Federated": "www.amazon.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
}]
}
```
------
사용자가 모바일 앱을 사용하여 Facebook에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서 *111222333444555*는 Facebook에서 할당하는 앱 ID를 나타냅니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForFacebook",
"Effect": "Allow",
"Principal": {"Federated": "graph.facebook.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
}]
}
```
------
사용자가 모바일 앱을 사용하여 Google에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서 *666777888999000*은 Google에서 할당하는 앱 ID를 나타냅니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForGoogle",
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
}]
}
```
------
사용자가 모바일 앱을 사용하여 Amazon Cognito에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서 *us-east:12345678-ffff-ffff-ffff-123456*은 Amazon Cognito에서 할당하는 아이덴티티 풀 ID를 나타냅니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}]
}
```
------
## OIDC 역할 생성
사전 요구 사항을 완료한 후에는 IAM에서 역할을 생성할 수 있습니다. 인식된 공유 OpenID Connect(OIDC) ID 공급자(IdP)의 경우 IAM은 **ID 공급자 제어라고 하는 JSON 웹 토큰(JWT)의 특정 클레임을 명시적으로 평가해야 합니다. **ID 공급자 제어가 있는 OIDC IdP에 대한 자세한 내용은 [공유 OIDC 공급자의 ID 공급자 제어](id_roles_providers_oidc_secure-by-default.md) 섹션을 참조하세요.
다음 절차는 AWS Management Console에서 OIDC 페더레이션 역할을 생성하는 방법을 설명합니다. AWS CLI 또는 AWS API에 역할을 만들려면 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md)의 절차 섹션을 참조하세요.
**중요**
Amazon Cognito를 사용하는 경우 Amazon Cognito 콘솔을 사용하여 역할을 설정합니다. 그 외에는 IAM 콘솔을 사용하여 OIDC 페더레이션의 역할을 생성합니다.
**OIDC 페더레이션을 위한 IAM 역할 생성**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. 신뢰할 수 있는 엔터티 유형으로 **웹 자격 증명**을 선택하고 **다음**을 선택합니다.
1. **자격 증명 공급자(Identity provider)**에서 역할의 IdP를 선택합니다.
+ 개별 웹 IdP에 대한 역할을 생성하는 경우, **Login with Amazon**, **Facebook** 또는 **Google**을 선택합니다.
**참고**
지원할 각 IdP에 대해 별도의 역할을 생성해야 합니다.
+ Amazon Cognito의 고급 시나리오 역할을 생성하려는 경우 **Amazon Cognito**를 선택합니다.
**참고**
고급 시나리오에서 작업하는 경우에만 Amazon Cognito에서 사용할 역할을 수동으로 생성해야 합니다. 그렇지 않은 경우 Amazon Cognito가 역할을 대신 생성할 수 있습니다. 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [자격 증명 풀(페더레이션 자격 증명) 외부 자격 증명 공급자](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html)를 참조하세요.
+ GitHub 작업을 위한 역할을 만들려는 경우 먼저 GitHub OIDC 공급자를 IAM에 추가해야 합니다. IAM에 GitHub OIDC 공급자를 추가한 후 **token.actions.githubusercontent.com**을 선택합니다.
**참고**
GitHub의 OIDC 제공자를 페더레이션형 ID로 신뢰하도록 AWS를 구성하는 방법에 대한 자세한 내용은 [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)를 참조하세요. GitHub용 IAM IdP와 관련된 역할에 대한 액세스를 제한하는 모범 사례에 대한 자세한 내용은 이 페이지의 [GitHub OIDC ID 제공자의 역할 구성](#idp_oidc_Create_GitHub)을 참조하세요.
+ HashiCorp Cloud Platform(HCP) Terraform에 대한 역할을 생성하려면 먼저 Terraform OIDC 제공자를 IAM에 추가해야 합니다. IAM에 Terraform OIDC 제공자를 추가한 후 **app.terraform.io**를 선택합니다.
**중요**
HashiCorp Cloud Platform(HCP) Terraform OIDC 제공자에 대한 IAM 역할은 역할 신뢰 정책에서 IAM 조건 키 `app.terraform.io:sub`를 평가해야 합니다. 이 조건 키는 역할을 수임할 수 있는 HCP Terraform 조직, 프로젝트, 워크스페이스 또는 실행 단계를 제한합니다. 이 조건 키가 없으면 신뢰 정책은 조직 외부의 ID로 역할 및 AWS 리소스에 대한 액세스 권한을 부여합니다. 이는 최소 권한 원칙에 부합하지 않습니다.
AWS 계정의 HCP Terraform OIDC 제공자와 연결된 역할에 대한 역할 신뢰 정책을 설정하거나 수정하지만 IAM 조건 키 `app.terraform.io:sub`를 평가하지 않으면 오류가 발생합니다. 또한 AWS STS는 역할 신뢰 정책이 이 조건 키를 평가하지 않는 경우 권한 부여 요청을 거부합니다.
1. 요청된 정보는 선택한 OIDC 공급자에 따라 다릅니다.
+ 애플리케이션의 식별자를 입력합니다. 식별자의 레이블은 선택하는 제공업체를 기준으로 변경됩니다.
+ Login with Amazon용 역할을 생성하려는 경우 **애플리케이션 ID(Application ID)** 상자에 앱 ID를 입력합니다.
+ Facebook용 역할을 생성하려는 경우 **애플리케이션 ID(Application ID)** 상자에 앱 ID를 입력합니다.
+ Google용 역할을 생성하려는 경우 **대상(Audience)** 상자에 대상 사용자 이름을 입력합니다.
+ Amazon Cognito용 역할을 생성하려는 경우 Amazon Cognito 애플리케이션용으로 생성한 아이덴티티 풀의 ID를 **자격 증명 풀 ID(Identity Pool ID)** 상자에 입력합니다.
+ GitHub 작업을 위한 역할을 만들려는 경우 다음 세부 정보를 입력하세요.
+ **대상**에서 `sts.amazonaws.com`을 입력합니다.
+ **GitHub 조직**에 GitHub 조직 이름을 입력합니다. GitHub 조직 이름은 필수이며 대시(-)를 포함한 영숫자여야 합니다. GitHub 조직 이름에 와일드카드 문자(\$1 및?)는 사용할 수 없습니다.
+ (선택 사항) **GitHub 리포지토리**에 GitHub 리포지토리 이름을 입력합니다. 값을 지정하지 않을 경우 기본값은 와일드카드(`*`)입니다.
+ (선택 사항) **GitHub 브랜치**에 GitHub 브랜치 이름을 입력합니다. 값을 지정하지 않을 경우 기본값은 와일드카드(`*`)입니다.
+ HashiCorp Cloud Platform(HCP) Terraform에 대한 역할을 생성하려면 다음 세부 정보를 입력합니다.
+ **대상**에서 `aws.workload.identity`을 입력합니다.
+ **조직**에 조직 이름을 입력합니다. 모든 조직에 와일드카드 문자(`*`)를 지정할 수 있습니다.
+ **프로젝트**에 프로젝트 이름을 입력합니다. 모든 프로젝트에 와일드카드 문자(`*`)를 지정할 수 있습니다.
+ **WorkSpace**에 WorkSpace 이름을 입력합니다. 모든 워크스페이스에 와일드카드 문자(`*`)를 지정할 수 있습니다.
+ **실행 단계**에 실행 단계 이름을 입력합니다. 모든 실행 단계에 와일드카드 문자(`*`)를 지정할 수 있습니다.
1. (선택 사항) 애플리케이션 사용자가 역할에서 부여한 권한을 사용하기 위해 충족해야 하는 추가 조건을 만들려면 **조건(선택 사항)**에서 **조건 추가**를 클릭합니다. 예를 들어, 특정 IAM 사용자 ID에만 AWS 리소스에 대한 액세스 권한을 부여하는 조건을 추가할 수 있습니다. 역할을 만든 후에 신뢰 정책에 조건을 추가할 수도 있습니다. 자세한 내용은 [역할 트러스트 정책 업데이트](id_roles_update-role-trust-policy.md) 섹션을 참조하세요.
1. OIDC 정보를 검토하고 **다음**을 선택합니다.
1. IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 **정책 생성(Create policy)**을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. OIDC 사용자에게 제공하려는 권한 정책 옆의 확인란을 선택하세요. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.
1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 고급 기능입니다.
**권한 경계(Permissions boundary)** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)**을 선택합니다. 정책을 선택하여 권한 경계를 사용합니다.
1. **다음**을 선택합니다.
1. **역할 이름(Role name)**에 역할 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자를 구분하지 않습니다. 예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들 수는 없습니다. 다른 AWS 리소스가 역할을 참조할 수 있기 때문에 역할을 생성한 후에는 역할 이름을 편집할 수 없습니다.
1. (선택 사항) **설명(Description)**에 새 역할에 대한 설명을 입력합니다.
1. 역할에 대한 사용 사례와 권한을 편집하려면 **1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities)** 또는 **2단계: 권한 추가(Step 2: Add permissions)** 섹션에서 **편집(Edit)**을 선택합니다.
1. (선택 사항) 역할에 메타데이터를 추가하려면 태그를 키-값 페어로 연결합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.
1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
## GitHub OIDC ID 제공자의 역할 구성
GitHub를 OIDC ID 제공업체(idP)로 사용하는 경우 IAM IdP와 연결된 역할을 수임할 수 있는 엔터티를 제한하는 것이 좋습니다. 신뢰 정책에 조건문을 포함하면 특정 GitHub 조직, 리포지토리 또는 분기로 역할을 제한할 수 있습니다. 문자열 조건 연산자가 있는 조건 키 `token.actions.githubusercontent.com:sub`을(를) 사용하여 액세스를 제한할 수 있습니다. 특정 리포지토리 또는 GitHub 조직 내 리포지토리 또는 분기 세트로 조건을 제한하는 것이 좋습니다. GitHub의 OIDC를 페더레이션형 ID로 신뢰하도록 AWS를 구성하는 방법에 대한 자세한 내용을 알아보려면 [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)(GitHub 문서 - Amazon Web Services에서 OpenID Connect 구성)를 참조하세요.
작업 워크플로나 OIDC 정책에서 GitHub 환경을 사용하는 경우 보안을 강화하기 위해 환경에 보호 규칙을 추가하는 것이 좋습니다. 배포 브랜치와 태그를 사용하여 환경에 배포할 수 있는 브랜치와 태그를 제한하세요. 보호 규칙을 사용하여 환경을 구성하는 방법에 대한 자세한 내용은 GitHub의 *배포를 위한 환경 사용* 문서의 [배포 브랜치 및 태그](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags)를 참조하세요.
GitHub의 OIDC IdP가 사용자 역할의 신뢰할 수 있는 보안 주체인 경우 IAM은 역할 신뢰 정책 조건을 검사하여 조건 키 `token.actions.githubusercontent.com:sub`이(가) 맞는지, 또 그 값이 와일드카드 문자(\$1 및 ?)만이거나 무효는 아닌지 확인합니다. IAM은 신뢰 정책이 생성되거나 업데이트될 때 이 검사를 수행합니다. 조건 키`token.actions.githubusercontent.com:sub`이(가) 존재하지 않거나 키 값이 언급된 값 기준을 충족하지 않으면 요청이 실패하고 오류가 반환됩니다.
**중요**
조건 키 `token.actions.githubusercontent.com:sub`을(를) 특정 조직이나 리포지토리에 한정하지 않으면 제어할 수 없는 조직이나 리포지토리의 GitHub 작업이 AWS 계정의 GitHub IAM IdP와 연결된 역할을 수임할 수 있습니다.
다음 예제 신뢰 정책은 정의된 GitHub 조직, 리포지토리 및 분기에 대한 액세스를 제한합니다. 아래 예에서 조건 키 `token.actions.githubusercontent.com:sub` 값은 GitHub에서 문서화한 기본 주제 값 형식입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
}
}
}
]
}
```
------
다음 예제 조건은 정의된 GitHub 조직 및 리포지토리에 대한 액세스를 제한하지만 리포지토리 내의 모든 분기에 대한 액세스 권한을 부여합니다.
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
}
}
```
다음 예제 조건은 정의된 GitHub 조직 내의 모든 리포지토리 또는 분기에 대한 액세스를 제한합니다. 조건 키 `token.actions.githubusercontent.com:sub`은(는) GitHub 조직 내에서 GitHub 작업에 대한 액세스를 제한하는 특정 값으로 제한하는 것이 좋습니다.
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
}
}
```
정책에서 조건 확인을 위해 사용 가능한 OIDC 페더레이션 키에 대한 자세한 정보는 [AWS OIDC 페더레이션에서 사용 가능한 키](reference_policies_iam-condition-keys.md#condition-keys-wif) 섹션을 참조하세요.
# SAML 2.0 페더레이션을 위한 역할 생성(콘솔)
AWS 계정에 속하는 IAM 사용자를 생성하는 대신에 SAML 2.0 페더레이션을 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 연동 및 자격 증명 공급자에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.
**참고**
페더레이션 복원력을 개선하려면 여러 SAML 로그인 엔드포인트를 지원하도록 IdP 및 AWS 페더레이션을 구성하는 것이 좋습니다. 자세한 내용은 AWS 보안 블로그 문서 [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)(장애 조치에 리전 SAML 엔드포인트를 사용하는 방법)를 참조하세요.
## SAML 역할을 생성하기 위한 사전 조건
SAML 2.0 페더레이션을 위한 역할을 만들기 전에 먼저 다음 필수 선행 단계를 완료해야 합니다.
**SAML 2.0 연동을 위한 역할 생성을 준비하려면**
1. SAML 기반 페더레이션을 위한 역할을 생성하기 전에 IAM에서 SAML 공급자를 만들어야 합니다. 자세한 내용은 [IAM에서 SAML ID 공급자 생성](id_roles_providers_create_saml.md) 섹션을 참조하세요.
1. SAML 2.0 인증 사용자들이 수임할 역할에 대한 정책을 준비합니다. 다른 어떤 역할과 마찬가지로 SAML 연동을 위한 역할에는 2개의 정책이 포함됩니다. 하나는 역할을 맡을 수 있는 사용자를 지정하는 역할 신뢰 정책이고, 다른 하나는 SAML 페더레이션 보안 주체의 액세스가 허용 또는 거부되는 AWS 작업 및 리소스를 지정하는 IAM 권한 정책입니다.
역할에 대한 신뢰 정책을 생성할 때 애플리케이션만 역할을 수임할 수 있도록 세 가지 값을 사용해야 합니다.
+ `Action` 요소에 대해서는 `sts:AssumeRoleWithSAML` 작업을 사용하세요.
+ `Principal` 요소에 대해서는 `{"Federated":ARNofIdentityProvider}` 문자열을 사용하세요. `ARNofIdentityProvider`를 [Step 1](#idpsamlstep1)에서 만든 [SAML 자격 증명 공급자](id_roles_providers_saml.md)의 ARN으로 바꿉니다.
+ `Condition` 요소의 경우 `StringEquals` 조건을 사용하여 SAML 응답의 `saml:aud` 속성이 콘솔에 로그인할 때 브라우저에 표시되는 URL과 일치하는지 테스트합니다. 이 로그인 엔드포인트 URL은 ID 제공업체의 SAML 수신자 속성입니다. 특정 리전 내에 로그인 URL을 포함할 수 있습니다. AWS에서는 페더레이션 복원력을 개선하기 위해 글로벌 엔드포인트 대신 리전별 엔드포인트를 사용할 것을 권장합니다. 가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요.
SAML 암호화가 필요한 경우 로그인 URL에는 AWS가 SAML 제공업체에 할당하는 고유 식별자가 포함되어야 합니다. IAM 콘솔에서 ID 제공업체를 선택해서 세부 정보 페이지를 표시하여 고유 식별자를 볼 수 있습니다.
`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`
다음 예는 SAML 페더레이션 사용자를 위해 설계된 신뢰 정책입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRoleWithSAML",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
},
"Condition": {
"StringEquals": {
"SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
}
}
}
}
```
------
보안 주체 ARN을 IAM에서 만든 SAML 공급자의 실제 ARN으로 바꿉니다. ARN에는 고유의 계정 ID와 공급자 이름이 있습니다.
## SAML 역할 생성
사전 조건 단계를 완료한 후에는 SAML 기반 연동을 위한 역할을 생성합니다.
**SAML 기반 연동을 위한 역할을 생성하려면**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. IAM 콘솔의 탐색 창에서 **역할**과 **역할 생성**을 차례대로 선택합니다.
1. **SAML 2.0 federation(SAML 2.0 연동)** 역할 유형을 선택합니다.
1. **SAML 공급자 선택(Select a SAML provider)**에서 역할의 제공업체를 선택합니다.
1. SAML 2.0 액세스 수준 방법을 선택합니다.
+ **Allow programmatic access only(프로그래밍 방식의 액세스만 허용)**을 선택하여 AWS API 또는 AWS CLI에서 프로그래밍 방식으로 위임할 수 있는 역할을 만듭니다.
+ 그런 다음 **프로그래밍 방식 및 AWS Management Console 액세스 허용**을 선택하여 AWS Management Console에서 프로그래밍 방식으로 수임할 수 있는 역할을 생성합니다.
이렇게 생성된 두 역할은 비슷하지만 콘솔에서 위임할 수도 있는 역할에는 특정 조건을 포함하는 신뢰 정책을 포함합니다. 이 조건은 SAML 대상(`SAML:aud` 속성)이 SAML 제공업체에 대한 AWS 로그인 엔드포인트로 설정되도록 명시적으로 보장합니다.
1. 속성을 정의하는 절차는 액세스 유형에 따라 다릅니다.
+ 프로그래밍 방식 액세스를 위한 역할을 만드는 경우, **속성** 목록에서 속성을 선택합니다. 그런 다음 **값(Value)** 상자에 역할에 포함시킬 값을 입력합니다. 이렇게 하면 지정한 속성을 포함하는 SAML 인증 응답(어설션)을 소유한 자격 증명 공급자의 사용자로 역할 액세스가 제한됩니다. 하나 이상의 속성을 지정해야 역할이 조직의 일부 사용자 집합으로 제한됩니다.
+ 프로그래밍 방식 AWS Management Console 액세스를 위한 역할을 생성하는 경우 **로그인 엔드포인트** 섹션은 콘솔에 로그인할 때 브라우저에 표시되는 URL을 정의합니다. 이 엔드포인트는 [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml) 컨텍스트 키에 매핑되는 ID 제공업체의 SAML 수신자 속성입니다. 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.
1. **리전별 엔드포인트** 또는 **비리전별 엔드포인트**를 선택합니다. 페더레이션 복원력을 개선하려면 여러 리전별 SAML 로그인 엔드포인트를 사용하는 것이 좋습니다.
1. **리전**에서 SAML 제공업체가 AWS 로그인을 지원하는 리전을 선택합니다.
1. **고유 식별자를 포함하는 로그인 URL**에서 로그인 엔드포인트에 AWS가 SAML ID 제공업체에 할당하는 고유 식별자가 포함되는지 여부를 선택합니다. 이 옵션은 암호화된 SAML 어설션에 필요합니다. 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요.
1. 신뢰 정책에 속성 관련 조건을 더 추가하려면 **조건(선택 사항)(Condition (optional))**을 선택하고 추가 조건을 선택한 후 값을 지정합니다.
**참고**
이 목록에는 가장 많이 사용되는 SAML 속성이 포함되어 있습니다. IAM은 조건을 생성하는 데 사용할 수 있는 추가 속성을 지원합니다. 지원되는 속성 목록은 [SAML 연동에 사용할 수 있는 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml)를 참조하세요. 목록에는 없지만 지원되는 SAML 속성의 조건이 필요한 경우, 해당 조건을 수동으로 추가할 수 있습니다. 이렇게 하려면 역할을 만든 후 신뢰 정책을 편집합니다.
1. SAML 2.0 신뢰 정보를 검토한 후 **다음(Next)**을 선택합니다.
1. IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 **정책 생성(Create policy)**을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. SAML 페더레이션 사용자에게 제공하려는 권한 정책 옆의 확인란을 선택합니다. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.
1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 고급 기능입니다.
**권한 경계(Permissions boundary)** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)**을 선택합니다. 정책을 선택하여 권한 경계를 사용합니다.
1. **다음**을 선택합니다.
1. **다음: 검토**를 선택합니다.
1. **역할 이름(Role name)**에 역할 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들 수는 없습니다. 기타 AWS 리소스가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.
1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.
1. **1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities)** 또는 **2단계: 권한 추가(Step 2: Add permissions)** 섹션에서 **편집(Edit)**을 선택하여 역할에 대한 사용 사례와 권한을 편집합니다.
1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.
1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
역할을 만든 후, AWS에 대한 정보로 자격 증명 공급자 소프트웨어를 구성하여 SAML 신뢰를 완료합니다. 이 정보는 SAML 페더레이션 사용자가 사용했으면 하는 역할을 포함합니다. 이를 가리켜 IdP와 AWS 간 신뢰 당사자 신뢰 구성이라고 합니다. 자세한 내용은 [신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성](id_roles_providers_create_saml_relying-party.md) 섹션을 참조하세요.
# 사용자 지정 트러스트 정책을 사용하여 역할 생성
사용자 지정 신뢰 정책을 생성하여 액세스를 위임하고 다른 사람이 AWS 계정에서 작업을 수행하도록 허용할 수 있습니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요.
역할을 사용해 권한을 위임하는 방법에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요.
## 사용자 지정 신뢰 정책을 사용하여 IAM 역할 생성(콘솔)
AWS Management Console을 사용하여 IAM 사용자가 수임할 수 있는 역할을 생성할 수 있습니다. 예를 들면 프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자가 프로덕션 계정의 리소스에 액세스할 수 있도록 하는 역할 생성에 대한 개괄적 정보는 [분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example) 섹션을 참조하세요.
**사용자 지정 신뢰 정책을 사용하여 역할 생성(콘솔)**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 콘솔의 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **사용자 지정 신뢰 정책(Custom trust policy)** 역할 유형을 선택합니다.
1. **사용자 지정 신뢰 정책(Custom trust policy)** 섹션에서 역할의 사용자 지정 신뢰 정책을 입력하거나 붙여 넣습니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요.
1. [정책 검증](access_policies_policy-validator.md) 동안 생성된 모든 보안 경고, 오류 또는 일반 경고를 해결하고 **다음**을 선택합니다.
1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 서비스 역할에서 사용 가능한 고급 기능이며 서비스에 연결된 역할은 아닙니다.
**권한 경계(Permissions boundary)** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)**을 선택합니다. IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 정책을 선택하여 권한 경계를 사용합니다.
1. **다음**을 선택합니다.
1. **역할 이름**의 경우 역할 이름 사용자 지정 수준은 서비스에서 정합니다. 서비스에서 역할 이름을 정한 경우 이 옵션을 편집할 수 없습니다. 다른 경우에는 서비스에서 역할 이름의 접두사를 정의하고 사용자가 선택적 접미사를 입력할 수 있습니다. 일부 서비스는 역할의 전체 이름을 지정할 수 있습니다.
가능하다면 역할 이름 또는 역할 이름 접미사를 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들 수는 없습니다. 기타 AWS 리소스가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.
1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.
1. (선택 사항) **1단계: 신뢰할 수 있는 엔터티 선택** 또는 **2단계: 권한 추가** 섹션에서 **편집**을 선택하여 역할의 사용자 지정 정책과 권한을 편집합니다.
1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.
1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
# 액세스 권한 위임을 위한 정책의 예
다음 예제는 AWS 계정의 리소스에 대한 액세스를 AWS 계정에게 허용 또는 부여하는 방법을 보여줍니다. 이러한 예제 JSON 정책 문서를 사용하여 IAM 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.
**Topics**
+ [역할을 사용하여 다른 AWS 계정의 리소스에 대한 액세스 권한 위임](#example-delegate-xaccount-rolesapi)
+ [정책을 사용하여 서비스에 대한 액세스 권한 위임](#id_roles_create_policy-examples-access-to-services)
+ [리소스 기반의 정책을 사용하여 다른 계정의 Amazon S3 버킷에 대한 액세스 권한 위임](#example-delegate-xaccount-S3)
+ [리소스 기반의 정책을 사용하여 다른 계정의 Amazon SQS 대기열에 대한 액세스 권한 위임](#example-delegate-xaccount-SQS)
+ [계정이 액세스 거부될 경우 액세스 권한을 위임할 수 없음](#example-delegate-xaccount-SQS-denied)
## 역할을 사용하여 다른 AWS 계정의 리소스에 대한 액세스 권한 위임
IAM 역할을 사용하여 한 계정의 사용자에게 다른 계정의 AWS 리소스에 대한 액세스 권한을 부여하는 방법에 대한 자세한 내용은 [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](tutorial_cross-account-with-roles.md) 섹션을 참조하세요.
**중요**
역할 신뢰 정책의 `Principal` 요소에 특정 역할이나 사용자에 대한 ARN을 포함할 수 있습니다. 정책을 저장하면 AWS가 ARN을 고유한 보안 주체 ID로 변환합니다. 그러면 누군가가 해당 역할 또는 사용자를 제거하고 다시 만들어 본인의 권한을 에스컬레이션할 위험을 완화할 수 있습니다. 일반적으로 콘솔에서는 이 ID가 보이지 않습니다. 신뢰 정책이 표시될 때 해당 ARN으로 다시 역변환되기 때문입니다. 그러나 해당 역할 또는 사용자를 삭제하면 관계가 깨집니다. 사용자 또는 역할을 다시 만들더라도 해당 정책이 더 이상 적용되지 않습니다. 신뢰 정책에 저장된 보안 주체 ID와 일치하지 않기 때문입니다. 이 경우 보안 주체 ID가 콘솔에 표시됩니다. AWS에서 더 이상 이를 ARN에 다시 매핑할 수 없기 때문입니다. 결과적으로 신뢰 정책의 `Principal` 요소에서 참조된 사용자 또는 역할을 삭제하고 다시 생성하는 경우, ARN을 바꾸도록 역할을 편집해야 합니다. 그러면 정책을 저장할 때 ARN이 새 보안 주체 ID로 변환됩니다.
## 정책을 사용하여 서비스에 대한 액세스 권한 위임
다음 예제는 역할에 연결할 수 있는 정책을 보여줍니다. 이 정책은 Amazon EMR 서비스와 AWS Data Pipeline 서비스가 역할을 수행할 수 있도록 합니다. 그러면 서비스가 해당 역할에 할당된 권한 정책에서 부여한 모든 작업을 수행할 수 있습니다(표시되지 않음). 여러 서비스 보안 주체를 지정할 때 `Service` 요소를 두 개 지정하면 안 됩니다. 하나만 지정할 수 있습니다. 대신 여러 서비스 보안 주체의 배열을 하나의 `Service` 요소의 값으로 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"elasticmapreduce.amazonaws.com",
"datapipeline.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## 리소스 기반의 정책을 사용하여 다른 계정의 Amazon S3 버킷에 대한 액세스 권한 위임
이 예에서 계정 A는 리소스 기반 정책(Amazon S3 [버킷 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html))을 사용하여 계정 B에게 계정 A의 S3 버킷에 액세스할 수 있는 완전한 권한을 부여합니다. 그런 다음 계정 B는 IAM 사용자 정책을 생성하여 계정 A의 버킷에 대한 해당 액세스 권한을 계정 B의 사용자 중 하나에게 위임합니다.
계정 A의 S3 버킷 정책은 다음 정책과 같을 수 있습니다. 이 예제에서 계정 A의 S3 버킷 이름은 **amzn-s3-demo-bucket이고, 계정 B의 계정 번호는 111122223333입니다. 계정 B에서는 개별 사용자 또는 그룹을 지정하지 않고 오직 계정 자체만 지정할 뿐입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBAccess1",
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
또는 계정 A가 Amazon S3 [액세스 제어 목록(ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html)을 사용하여 계정 B에 S3 버킷 또는 버킷 내 단일 객체에 대한 액세스 권한을 부여할 수 있습니다. 이 경우 유일한 변경 사항은 계정 A가 계정 B에게 액세스 권한을 부여하는 방식입니다. 이 예의 다음 부분에서 설명한 것처럼 계정 B는 여전히 정책을 사용하여 계정 B의 IAM 그룹에 액세스 권한을 위임합니다. S3 버킷 및 객체에 대한 액세스를 관리하는 방법에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [액세스 제어](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html)를 참조하세요.
계정 B의 관리자는 다음 정책 샘플을 생성할 수 있습니다. 이 정책은 계정 B의 그룹 또는 사용자에게 읽기 액세스를 허용하며, 이전 정책은 B 계정에 대한 액세스 권한을 부여합니다. 하지만 계정 B의 개별 그룹과 사용자는 그룹 또는 사용자 정책이 리소스에 대한 권한을 명시적으로 부여할 때까지는 그 리소스에 액세스할 수 없습니다. 이 정책의 권한은 이전 크로스 계정 정책에 있는 권한의 하위 집합에 불과할 수 있습니다. 계정 B는 첫 번째 정책에서 계정 A가 계정 B에게 부여한 권한보다 더 많은 권한을 자신의 그룹 또는 사용자에게 위임할 수 없습니다. 이 정책에서 `Action` 요소는 `List` 작업만을 허용하도록 명시적으로 정의되고 이 정책의 `Resource` 요소는 계정 A에 의해 적용되는 버킷 정책의 `Resource`와 일치합니다.
이 정책을 적용하기 위해 계정 B는 IAM을 사용하여 이 정책을 계정 B의 해당 사용자(또는 그룹)에게 연결합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:List*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
## 리소스 기반의 정책을 사용하여 다른 계정의 Amazon SQS 대기열에 대한 액세스 권한 위임
다음 예에서 계정 A에는 계정 B에 대한 액세스 권한을 대기열에 부여하기 위해 대기열에 연결된 리소스 기반 정책을 사용하는 Amazon SQS 대기열이 있습니다. 그러면 계정 B는 IAM 그룹 정책을 사용하여 계정 B의 그룹에 액세스 권한을 위임합니다.
다음 대기열 정책 예에서는 계정 B에 계정 A의 대기열 *queue1*에 대한 `SendMessage` 및 `ReceiveMessage` 작업을 2014년 11월 30일 정오부터 오후 3시까지만 수행할 수 있는 권한을 부여합니다. 계정 B의 계정 번호는 1111-2222-3333입니다. 계정 A는 Amazon SQS를 사용하여 이 정책을 구현합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": ["arn:aws:sqs:*:123456789012:queue1"],
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
"DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
}
}
}
```
------
계정 B의 그룹에게 액세스 권한을 위임하기 위한 계정 B의 정책은 다음 예와 같을 수 있습니다. 계정 B는 IAM을 사용하여 이 정책을 그룹(또는 사용자)에게 연결합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:queue1"
}
}
```
------
앞의 IAM 사용자 정책에 대한 예제에서 계정 B는 와일드카드를 사용하여 해당 사용자에게 계정 A의 대기열에서 모든 Amazon SQS 작업을 수행할 수 있는 액세스 권한을 부여했습니다. 하지만 계정 B는 액세스 권한이 부여된 범위까지만 액세스 권한을 위임할 수 있습니다. 두 번째 정책이 있는 계정 B 그룹은 2014년 11월 30일 정오부터 오후 3시까지만 대기열에 액세스할 수 있습니다. 사용자는 계정 A의 Amazon SQS 대기열 정책에 정의된 대로 `SendMessage` 및 `ReceiveMessage` 작업만 수행할 수 있습니다.
## 계정이 액세스 거부될 경우 액세스 권한을 위임할 수 없음
다른 계정에서 사용자의 상위 계정에 대한 액세스를 명시적으로 거부할 경우 AWS 계정은 다른 계정의 리소스에 대한 액세스 권한을 위임할 수 없습니다. 이 거부는 사용자가 액세스 권한을 부여하는 기존 정책을 가지고 있는지 여부에 상관없이 해당 계정의 사용자에게 전파됩니다.
계정 A가 계정 A의 S3 버킷에 계정 A의 버킷에 대한 계정 B의 액세스를 명시적으로 거부하는 버킷 정책을 계정 A의 S3 버킷에 작성하는 경우를 예로 들어 보겠습니다. 계정 B는 계정 B의 사용자에게 계정 A의 버킷에 대한 액세스 권한을 부여하는 IAM 사용자 정책을 작성합니다. 계정 A의 S3 버킷에 적용된 명시적 거부는 계정 B의 사용자에게 전파되고 계정 B의 사용자에게 액세스 권한을 부여하는 IAM 사용자 정책보다 우선합니다. (권한 평가 방식에 대한 자세한 내용은 [정책 평가 로직](reference_policies_evaluation-logic.md) 섹션을 참조하세요.)
계정 A의 버킷 정책은 다음과 같을 수 있습니다. 이 예제에서 계정 A의 S3 버킷 이름은 **amzn-s3-demo-bucket이고, 계정 B의 계정 번호는 1111-2222-3333입니다. 계정 A는 Amazon S3를 사용하여 이 정책을 구현합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBDeny",
"Effect": "Deny",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
이 명시적 거부는 계정 A의 S3 버킷에 액세스할 수 있는 권한을 제공하는 계정 B의 모든 정책을 재정의합니다.