AWS IAM 역할과 함께 신뢰 정책을 사용하는 방법
이 글은 AWS Security Blog에 게재된 How to use trust policies with IAM roles의 한국어 번역으로 김성헌 AWS 보안 컨설턴트가 번역 및 검수하였습니다.
2023년 6월 20일: AWS Identity and Access Management(IAM) 신뢰 정책 설명의 주요 요소에서 와일드카드 사용과 관련된 혼동을 피하기 위해 이 게시물의 문구가 업데이트되었습니다.
2022년 11월 3일: 정책 설명의 일부 구문 오류를 수정하고 추가 사용 사례를 추가하기 위해 이 게시물을 업데이트했습니다.
2021년 8월 30일: 이 게시물은 현재 계속 업데이트 중입니다.
AWS Identity and Access Management (IAM) 역할은 고객이AWS를 운영하는 방법에서 중요한 구성 요소입니다. 이 블로그에서는 역할 신뢰 정책이 작동하는 방식과 이러한 정책을 사용하여 역할을 수행하는 방식을 제한할 수 있는 방법에 대해 자세히 설명합니다.
AWS에서 IAM 역할을 사용할 수 있는 몇 가지 시나리오가 있습니다:
- AWS 서비스 또는 리소스가 다른 AWS 리소스에 액세스 – AWS 리소스가 다른 AWS 서비스, 기능 또는 리소스에 액세스해야 하는 경우 해당 AWS 리소스가 사용할 수 있는 적절한 사용 권한을 가진 역할을 생성할 수 있습니다. AWS Lambda 및 Amazon Elastic Container Service(Amazon ECS)와 같은 서비스는 해당 서비스에서 실행 중인 코드에 임시 자격 증명을 제공하기 위해 역할을 이용합니다.
- AWS 외부에서 실행되는 디바이스가 사용할 AWS 자격 증명 생성 – AWS IAM Roles Anywhere, AWS IoT Core 및 AWS Systems Manager 하이브리드 인스턴스는 AWS에서 실행되지 않는 애플리케이션, 디바이스 및 서버에 역할 세션 자격 증명을 제공할 수 있습니다.
- AWS 계정에서 다른 AWS 계정 접근 –이 사용 사례를 일반적으로 교차 계정 역할 패턴이라고 합니다. 이를 통해 한 AWS 계정의 사람 또는 머신 IAM 주체가 이 역할을 이용하여 다른 AWS 계정 내의 리소스에 대해 작업을 수행할 수 있습니다. 대상 계정의 리소스에 교차 계정 액세스를 부여하는 데 사용할 수 있는 리소스 기반 정책이 없는 경우 역할이 이 동작을 활성화하는 것으로 간주됩니다.
- Web 자격 증명 공급자 또는 OpenID Connect(OIDC)로 인증된 사용자가 AWS 리소스에 엑세스 – 이 사용 사례를 통해 Facebook 또는 GitHub, Amazon Cognito와 같은 OIDC 제공자의 ID 또는 기타 일반 OIDC 제공자가 AWS 계정의 리소스에 액세스하는 경우 역할을 활용할 수 있습니다.
- SAML 2.0 federation을 활용한 사용자 인증 – 이는 고객이 Okta, Microsoft Azure Active Directory 또는 ADFS(Active Directory Federation Services)와 같은 회사 ID 공급자(IdP) 또는 AWS IAM Identity Center(AWS Single Sign-On의 후속)에서 사용자를 AWS로 federation할 때 발생합니다.
IAM 역할은 앞선 사용 사례에서 자격이 인정되는 IAM 주체 중 하나입니다. IAM 역할은 IAM 사용자와 다음과 같이 구분됩니다:
- IAM 역할에는 장기 AWS 자격 증명이 연결될 수 없습니다. 대신 인증된 주체(IAM 사용자, AWS 서비스 또는 기타 인증된 자격 증명)가 IAM 역할을 활용하고 해당 역할에 할당된 사용 권한을 상속합니다.
- IAM 역할과 연결된 자격 증명은 일시적이며 만료됩니다.
- IAM 역할에는 다른 주체가 역할을 수행할 수 있도록 충족해야 하는 조건을 정의하는 신뢰 정책이 있습니다.
AWS IAM 역할에 대한 액세스 관리
IAM 역할에 적용할 수 있는 정책 유형을 이해하여 IAM 역할에 대한 액세스를 제어하는 방법에 대해 자세히 살펴보겠습니다.
IAM 역할에 정책이 사용되는 세 가지 상황이 있습니다:
- 신뢰 정책 – 신뢰 정책은 역할을 맡을 수 있는 주체와 조건을 정의합니다. 신뢰 정책은 IAM 역할에 대한 특정 리소스 기반 정책 유형입니다. 신뢰 정책은 이 블로그 게시물의 나머지 부분에 초점을 맞춥니다.
- 자격 증명 기반 정책(인라인 및 관리형) – 이러한 정책은 역할의 사용자가 수행할 수 있는 권한(또는 수행할 수 없는 권한)과 리소스를 정의합니다.
- 권한 경계 – 권한 경계는 관리되는 정책을 사용하여 역할에 대한 최대 권한을 설정하기 위한 고급 기능입니다. 주체의 사용 권한 경계를 사용하면 자격 증명 기반 사용 권한 정책과 사용 권한 경계에서 모두 허용하는 작업만 수행할 수 있습니다. 권한 경계를 사용하여 IAM 역할 생성과 같은 권한 관리 작업을 비관리자에게 위임하여 그들이 셀프 서비스로 역할을 생성할 수 있습니다.
이 블로그의 나머지에서는 신뢰 정책을 구성하여 역할을 사용할 수 있는 조건을 적용하는 방법에 대해 알아봅니다.
간단한 신뢰 정책의 예
일반적인 사용 사례는 계정 B의 역할을 이용하기 위해 계정 A의 역할에 대한 액세스 권한을 제공해야 하는 경우입니다. 이를 위해 계정 B의 신뢰 정책에 계정 A의 인증된 주체가 sts:AssumeRole API 호출을 통해 역할을 맡을 수 있는 항목을 추가합니다.
중요: IAM 역할의 신뢰 정책에서 :root를 참조하는 경우 의도한 것보다 많은 주체가 역할을 맡을 수 있도록 허용할 수 있으므로 특정 주체 또는 조건만 역할을 맡을 수 있도록 주체 요소 또는 조건을 사용하는 것이 좋습니다. 이 게시물의 뒷부분에서 이 액세스를 보다 구체적인 주체로 제한하는 방법을 보여 줍니다.
이 신뢰 정책은 효과, 액션 및 조건 구성 요소가 있는 다른 IAM 정책과 동일한 구조를 가집니다. 또한 기본 요소는 있지만 리소스 요소는 없습니다. 이는 리소스가 IAM 역할 자체이기 때문입니다. 동일한 이유로 Action 요소는 역할 사용을 위해 관련 액션으로만 설정됩니다.
참고: 정책의 Principal 속성에 있는 접미사 :root는 해당 계정의 루트 사용자가 아닌 계정의 Principal과 동일합니다.
Principal 속성을 사용하여 범위 축소
신뢰 정책에서 Principal 속성은 IAM 역할을 맡을 수 있는 다른 보안 주체를 나타냅니다. 위의 예에서 111122223333은 감사자의 AWS 계정에 대한 AWS 계정 번호를 나타냅니다. 이를 통해 sts: AssumeRole 권한이 있는 111122223333 계정의 모든 보안 주체가 이 역할을 맡을 수 있습니다.
특정 IAM 역할이 역할을 맡을 수 있도록 하려면 Principal 속성에 해당 역할을 추가할 수 있습니다. 예를 들어, 다음 신뢰 정책은 111122223333 계정의 IAM 역할 LiJuan만 연결된 역할을 맡을 수 있도록 허용합니다.
주체 속성에 포함된 주체는 IAM 문서에 정의된 주체가 될 수 있으며 AWS 또는 federation 보안 주체를 참조할 수 있습니다. 신뢰 정책에 대해 주체 속성에 와일드카드(“*” 또는 “?“)를 사용할 수 없으며, 나중에 다룰 한 가지 경우는 예외입니다. 각 보안 주체의 ID에 연결된 신뢰 정책을 제출할 때 변환이 발생하기 때문에 참조하는 주체를 정확하게 정의해야 합니다. 자세한 내용은 IAM 리소스 기반 정책에 알 수 없는 주체 형식이 있는 이유를 참고하십시오.
IAM 역할의 신뢰 정책에 동일한 계정의 보안 주체가 직접 있는 경우, 해당 보안 주체가 역할을 활용하기 위해 자격 증명의 연결 정책에 명시적인 자격이 필요하지 않습니다.
신뢰 정책에서 Condition 속성 사용
역할 신뢰 정책의 Condition 속성은 역할을 맡으려는 Principal에 대한 추가 요구 사항을 설정합니다. Condition 속성은 보안 주체를 지정하지 않고도 역할을 맡을 수 있는 사용자 집합을 줄일 수 있는 유연한 방법입니다.
역할 신뢰 정책의 Condition 속성은 AWS의 자격 증명 기반 정책 및 기타 리소스 정책의 condition 속성과 동일하게 작동합니다.
AWS에서 SAML identity federation 사용
SAML 2.0 준수하는 IdP federation 사용자에게는 IAM 역할을 사용하여 AWS 계정에 액세스할 수 있는 권한이 부여됩니다. SAML 2.0 IdP가 사용하는 디렉토리에서 설정되고 IdP가 서명한 SAML assertion 내에 배치되는 역할을 엔터프라이즈 사용자와 매핑합니다.
SAML federation에 대한 역할 신뢰 정책의 Principal 속성 요소에는 동일한 AWS 계정에 있는 SAML IdP의 ARN이 포함됩니다. 다른 계정의 IdP를 참조할 수 없습니다. SAML federation에서 사용하는 역할은 역할 신뢰 정책에서 SAML에 대한 조건 키를 사용할 수 있습니다.
SAML에서 사용하는 역할에 대한 역할 신뢰 정책은 SAML IDP의 ARN을 Principal 요소에 배치하고 SAML assertion의 의도된 대상(SAML:aud)을 확인합니다. Audience condition 설정은 AWS용 SAML assertion만 역할을 이용하는데 사용할 수 있다는 것을 의미하기 때문에 중요합니다:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRoleWithSAML",
"Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/PROVIDER-NAME"},
"Condition": {"StringEquals": {"SAML:aud": "<https://signin.aws.amazon.com/saml>"}}
}
}AWS 설명서에서는 SAML 2.0 federation에 대한 역할 생성에 대해 자세히 설명합니다. 복원력을 위해 여러 AWS Region에서 SAML이 담당하는 역할의 역할 신뢰 정책을 관리하는 방법에 대한 자세한 내용은 블로그 게시물 failover를 위한 리전 SAML 엔드포인트 사용 방법을 참조하십시오.
AWS에 대한 직원 액세스를 federation하기 위해 AWS IAM Identity Center(AWS Single Sign-On의 후속)를 사용하여 SAML을 통해 IAM 역할에 대한 액세스를 중개할 수 있습니다. IAM Identity Center에서 관리하는 역할은 IAM에서 직접 신뢰 정책을 수정할 수 없습니다.
역할 신뢰 정책에 사용되는 SAML IDP는 역할과 동일한 계정에 있어야 합니다.
WebIdentity를 사용한 역할 활용
웹 자격 증명 공급자 및 OpenID Connect(OIDC)를 준수하는 공급자에서 발행한 토큰을 사용하여 역할을 활용할 수도 있습니다.
계정에서 OpenID Connect 자격 증명 공급자를 생성한 후, OpenID Connect 자격 증명 공급자가 역할을 사용하도록 설정할 수 있습니다.
다음은 자격 증명 제공자 auth.example.com 에서 역할을 사용할 수 있는 신뢰 정책입니다. 여기서 sub claim 값은 Administrator 와aud는 MyappWebIdentity입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::11112222333:oidc-provider/auth.example.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"auth.example.com:sub": "Administrator",
"auth.example.com:aud": "MyappWebIdentity"
}
}
}
]
}
OIDC 자격 증명 제공자가 이용하는 역할에 사용되는 조건 키에는 항상 OIDC 자격 증명 제공자의 이름(예: auth.example.com )이 접두사로 붙습니다. 따라서 aud, sub 및 amr과 같은 ID 토큰의 클레임을 사용하려면 조건 키로 평가할 신뢰 정책에서 각각 auth.example.com:aud, auth.example.com:sub, 및 auth.example.com:amr, 로 접두사가 붙습니다. STS 설명서에 나열된 ID 토큰 클레임만 역할 신뢰 정책에서 조건 키로 사용할 수 있습니다.
역할 신뢰 정책에서 :aud 조건을 설정하여 AWS 계정에서 역할을 활용하는데 사용되는 토큰이 해당 용도로 사용되는 토큰인지, 웹 자격 증명 공급자가 Google 또는 GitHub와 같은 퍼블릭 또는 다중 테넌트 자격 증명 공급자인 경우 응용 프로그램 또는 테넌트용 토큰인지 확인하는 것이 중요합니다.
Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터에는 OIDC 자격 증명 제공자 기능이 있으며 AWS 계정의 역할을 맡는 데 사용할 수 있습니다.
역할을 활용하는데 사용되는 OIDC 자격 증명 제공자는 역할과 동일한 AWS 계정에 있어야 합니다.
IAM 구분자에 따라 역할 사용을 제한하기
때로는, AWS 계정의 리소스에 대한 접근 권한을 서드파티에게 허용해야 하는 일이 있습니다.
예를들어, AWS 계정을 모니터링하고 비용 최적화에 대한 도움을 받기 위해 Example Corp라는 서드파티 회사를 고용했다고 가정해봅시다. 매일 AWS 사용량을 추적하기 위해 Example Corp는 비용을 추적할 대상인 AWS 리소스에 대한 접근이 필요한 상황입니다. 이 경우, IAM 역할을 만들어 Example Corp 에게 IAM 역할에 대한 사용권한을 위임할 수 있습니다. 하지만 Example Corp 의 서비스를 이용하는 고객이 여럿인 경우, 자신의 계정에 대한 작업권한만 갖고 있는 다른 고객이 Example Corp에게 여러분의 AWS 계정에 특정 작업을 수행하도록 할 수 있습니다. 이러한 문제를 교차 계정의 혼동된 대리인 문제라고 합니다. 이번 섹션에서는 이러한 혼동된 대리인 문제 위험을 완화하는 방법을 보여줍니다.
다음 신뢰 정책에서는 Example Corp의 AWS 계정인 444455556666의 누군가가 이 역할을 위임받기 위해 외부 ID 라고 하는 특별한 문자열을 제공해야 합니다. 이 조건을 추가함으로써 444455556666 계정의 누군가가 실수로 이 역할을 위임받는 위험을 감소 시킵니다. 이 구문은 외부 ID 조건부 컨텍스트 키를 지정하는 것으로 구성할 수 있습니다.
외부 ID는 역할을 위임받는 Example Corp와 같은 서드 파티에 의해 생성되어야 하며, 이 외부 ID는 Example Corp 가 고객에게 역할 위임을 요청할 때 사용하는 다른 역할과 연결되어야 합니다.
이 구성을 하면, Example Corp 의 다른 고객이 여러분의 외부 ID를 알게 되더라도 Example Corp 이 테넌트를 통해 여러분의 외부 ID를 사용하도록 강요할 수 없기 때문에, External Corp 의 다른 고객들이 External Corp 에게 역할을 대신 위임받도록 강요하는 것을 방지합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ExampleCorpRole"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "ExampleUniquePhrase"
}
}
}
]
}
위의 신뢰 정책에서 외부 ID 는 서비스 제공자의 모든 고객들마다 고유한 값을 가져야 합니다. 외부 ID 는 비밀번호나 암호가 아니기 때문에 역할의 신뢰 정책을 볼 수 있는 권한을 가진 모든 사용자가 값을 확인할 수 있습니다.
만약 여러분이 고객 계정의 역할을 위임받는 경우, 고객을 대신해서 고유한 외부 ID 를 생성하여 고객과 연결하는 것이 모범 사례이며, 고객이 외부 ID 를 특정하여 지정하도록 허용해서는 안 됩니다.
별도의 Allow 조건 문이 없는 이상, sts:ExternalId 조건이 지정되어 있는 역할은 AWS 콘솔을 통해 위임을 요청할 수 없습니다.
IP 주소 또는 CIDR 범위를 기반으로 역할 사용을 제한하기
역할의 신뢰 정책에 IP 주소 조건을 추가하여 역할을 위임받을 수 있는 네트워크 범위를 제한할 수 있습니다. 예를들어, 회사의 사내망 또는 VPN 네트워크 내에서만 역할을 받을 수 있도록 제한할 수 있습니다. 아래의 신뢰 정책은 203.0.113.0/24 CIDR 범위 내에서만 역할을 위임받는 것을 허락하는 예시입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/IpBoundedRole"
},
"Action": "sts:AssumeRole",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}
신뢰 정책에 aws:SourceIP 조건문을 사용함으로써 역할을 위임받을 수 있는 소스 IP 범위를 제한할 수 있습니다. 하지만 이 조건문은 역할을 위임받은 뒤 그 자격증명을 사용하는 IP 범위를 제한하는 것을 의미하지는 않습니다. 역할의 자격증명이 사용되는 IP 대역을 제한하기 위해서는 aws:SourceIP 조건문을 주체의 자격 증명 기반 정책 또는 서비스 제어 정책에 적용해야 합니다.자격증명이 사용될 수 있는 곳을 제한하는 정책에 대한 더 많은 정보가 필요하다면, AWS에서 데이터 경계 설정하기를 참고하시기 바랍니다.
태그를 사용하여 역할 사용을 제한하기
IAM 태깅 기능을 사용하여 유연하고 어댑티브한 신뢰 정책을 만들 수 있습니다. Amazon Simple Storage Service (Amazon S3) 버킷 내에 위치한 오브젝트에 접근할 때와 마찬가지 방법으로 IAM 역할을 위임받기 위해 속성 기반 액세스 제어(ABAC) 모델을 사용할 수 있습니다. 특정한 키/값 태그가 있는 주체만 역할을 위임받을 수 있도록 신뢰 정책을 만들 수 있습니다. 아래의 예시는 AWS 계정 111122223333의 IAM 주체에 지정된 department 태그의 값이 IAM 역할에 지정된 owningDepartment 태그의 값과 일치해야만 위임이 가능하도록 구성된 신뢰 정책입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department":"${aws:ResourceTag/owningDepartment}"
}
}
}
]
}
예를 들어 이 정책에서 역할에 지정된 owningDepartment 태그의 값이 재무팀인 경우, 111122223333 계정 내 주체에도 department 태그의 값이 동일하게 재무팀으로 지정되어 있어야 이 역할을 위임할 수 있습니다.
ABAC을 사욜할 때는 리소스, 주체 및 세션에 태그를 지정할 수 있는 사람에 대한 거버넌스를 만드는 것이 중요합니다. 만약 누군가 임의로 리소스, 주체 또는 세션에 지정된 태그를 변경 또는 수정할 수 있다면 의도와 다르게 리소스에 접근할 수 있게 됩니다. 교차 계정 역할 위임에 태그를 사용하는 경우, 제어할 수 없는 AWS 계정의 주체는 여러분의 organization과 다른 태그 거버넌스를 갖고 있을 수 있으므로 이를 고려해야 합니다. 태그 정책을 사용하여 organization내의 태그 거버넌스를 만드는데 활용할 수 있으며, 이 블로그 포스트의 뒤쪽에서 역할의 신뢰 정책을 사용하여 태그를 관리하는 예시를 확인할 수 있습니다.
더 많은 정보는 AWS를 위한 속성 기반 액세스 제어를 참고하시기 바랍니다.
조직 내의 주체만 역할 위임을 할 수 있도록 제한하기
2016년 발표 이후, AWS를 사용하는 대다수의 기업 고객들이 AWS Organizations을 사용하고 있습니다. AWS Organizations 는 여러분이 논리적인 바운더리와 공통된 가드레일 정책을 적용할 AWS 계정을 묶어 놓는 조직 단위(OU) 을 통해 AWS 계정에 조직적인 구조를 만들 수 있도록 지원합니다. PrincipalOrgID 조건 키를 사용하면 AWS Organizations 에 등록되어 있는 계정의 주체만 역할을 사용할 수 있도록 제한할 수 있습니다.
아래의 예시는 AWS 서비스와 조직 ID가 o-abcd12efg1 인 조직에 등록된 계정의 주체가 아닌 경우 역할의 위임을 거부하는 정책입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": ""
},
"Action": "sts:AssumeRole",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-abcd12efg1"
},
"Bool": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
이 예시 정책에서 StringNotEquals 컨디션 키는 특정한 조직에 등록된 계정의 주체가 아닌 경우, 이 역할을 위임하지 못하도록 합니다.
AWS 서비스에서 사용하는 AWS 역할은 AWS 서비스에서 위임할 수 있어야 합니다. 앞의 예시 정책에서aws:PrincipalIsAWSService 컨디션 키를 추가함으로써 AWS 서비스 주체가 명시적 거부의 영향을 받지 않도록 했습니다. AWS 서비스를 포함한 모든 주체가 이 역할을 위임받기 위해서는 여전히 명시적으로 허용하는 구문이 있어야 합니다. aws:PrincipalIsAWSService 컨디션 키의 값을 true 로 설정한 정책 구문을 추가하면, AWS 서비스 주체가 고객의 리소스에 대한 요청을 할 때 앞의 예시 정책의 영향을 받지 않으며, 추가된 허용 정책에 의해 서비스 주체가 역할을 위임할 수 있게 됩니다.
또한, aws:PrincipalOrgPaths 조건 키를 사용하면, 조직의 특정 OU 에 속한 계정에 대해서만 역할의 위임을 제한하는 보다 세밀한 권한 정책을 만들 수 있습니다.
거부문으로 보안 불변성 적용하기
조직 내 주체에게만 역할 위임을 허용하는 것이 보안 불변성의 예입니다. 보안 불변성은 항상 적용하고자 하는 보안 원칙입니다. 신뢰 정책에서 거부문은 역할을 위임받지 못하도록 제한하는데 유용합니다. AWS 정책 평가에서 거부문이 있으면 허용 문이 오버라이드 됩니다. 따라서 조직 외부의 주체가 역할을 위임받을 수 없도록 제한하는 등 절대 허용해서는 안 되는 조건에는 거부 문을 사용하는 것이 좋습니다.
Cloudtrail 에서 쉽게 작업을 추적할 수 있도록 역할 세션에 소스 ID를 설정하기
역할을 위임받을 때 소스 ID를 갖도록 역할 세션을 구성할 수 있습니다. 이 방법은 사용자가 SAML2.0 또는 Web Identity/OpenID Connect 과 IAM 페더레이션을 통해 역할을 위임할 때 일반적으로 사용하는 방법입니다. 역할 세션에서 소스 ID 속성을 설정하도록 IdP를 구성할 수 있습니다. 소스 ID를 설정하면 이 역할 세션에서 수행한 작업에 대한 AWS CloudTrail 로그에 소스 ID가 포함되므로 역할이 수행한 작업을 해당 역할을 맡은 사용자로 추적할 수 있습니다. 또한 다른 역할을 맡은 경우 해당 역할 세션이 소스 ID 속성을 따릅니다.
소스 ID를 설정하려면 역할의 신뢰 정책에서 IdP에 sts:SetSourceIdentity 권한을 부여해야 합니다.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": ["sts:AssumeRoleWithSAML","sts:SetSourceIdentity"],
"Principal": {"Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"},
"Condition": {"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}}
}
}
소스 ID가 설정된 역할 세션이 두 번째 역할을 위임받으려면 두 번째 역할의 신뢰 정책에도 sts:SetSourceIdentity 권한이 있어야 합니다. 그렇지 않으면 첫 번째 역할은 두 번째 역할을 위임받을 수 없습니다.
또한 sts:SourceIdentity 조건 키를 사용하여 설정되어 있는 SourceIdentity 속성이 정해진 표준을 따르도록 강제할 수 있습니다.
"Condition": {
"StringLike": {"sts:SourceIdentity": "@example.org"}
}
위 예시의 Condition 구문에서는 모든 요청에 @example.org가 포함되도록 강제합니다.
역할 세션에 태그를 설정하기
역할 세션에 태그를 설정하여 IAM 및 리소스 정책 인가에 대한 의사결정에 사용할 수 있습니다. 역할 세션의 태그는 IAM 역할의 태그와 동일한 조건 키 (aws:PrincipalTag/TagKey)로 평가됩니다. 역할을 위임받으면서 설정된 태그 값은 역할에 연결된 태그 값보다 우선 적용됩니다.
AWS 계정의 Principal 태그를 기반으로 권한을 부여하는 경우, 계정의 세션 태그와 Principal 태그를 설정할 수 있는 사용자를 제한하여 의도하지 않은 사용자에게 액세스 권한이 부여되지 않도록 하는 것이 중요합니다.
역할 세션에 태그를 지정하는 기능은 역할의 신뢰 정책에서 sts:TagSession 권한을 사용하여 부여해야 하며, 조건 및 조건 키를 사용하여 어떤 태그를 어떤 값으로 설정할 것인지 제한할 수 있습니다.
아래 예시는 111122223333 계정의 주체가 이 역할을 맡을 수 있도록 허용하고, Project, CostCenter 및 Department에 대한 세개의 세션 태그를 설정하도록 강제하는 역할의 신뢰 정책입니다. 이때 Department 태그는 Engineering 또는 Marketing 중 하나여야 합니다. 세번째 조건문을 사용하면 역할을 맡을 때 Project 및 Department 태그를 전이형으로 설정할 수 있습니다. 태그에 대한 조건은 AssumeRole 권한과 동일한 허용 문에 있으므로 이러한 태그를 설정해야 합니다.
{
"Effect": "Allow",
"Action": ["sts:TagSession","sts:AssumeRole"],
"Principal": {"AWS": "arn:aws:iam::111122223333:root"},
"Condition": {
"StringLike": {
"aws:RequestTag/Project": "",
"aws:RequestTag/CostCenter": ""
},
"StringEquals": {
"aws:RequestTag/Department": [
"Engineering",
"Marketing"
]
},
"ForAllValues:StringEquals": {
"sts:TransitiveTagKeys": [
"Project",
"Department"
]
}
}
}
역할 세션이 다른 역할을 위임받게 되면 이전 역할 세션의 전이 태그가 다음 역할의 세션에 동일한 값으로 설정됩니다. 자세한 내용은 세션 태그를 사용하여 역할 연결하기를 참고하시기 바랍니다.
특정 태그를 설정하지 못하도록 제한하려면 sts:TagSession 작업과 함께 거부 문을 사용할 수 있습니다. 아래 예시에서는 세션에 Admin 태그를 사용하려는 시도가 거부됩니다.
{
"Effect": "Deny",
"Action": "sts:TagSession",
"Principal": {"AWS": ""},
"Condition": {
"Null": {
"aws:RequestTag/Admin": false
}
}
}
다음 예시에서는 Team 태그로 Admin을 설정하려는 요청은 거부하지만 다른 태그 값으로 설정하려는 요청은 허용하는 것을 보여줍니다.
{
"Effect": "Deny",
"Action": "sts:TagSession",
"Principal": {"AWS": ""},
"Condition": {
"StringEquals": {
"aws:RequestTag/Team": "Admin"
}
}
},
{
"Effect": "Allow",
"Action": "sts:TagSession",
"Principal": {"AWS": ""},
"Condition": {
"StringLike": {
"aws:RequestTag/Team": ""
}
}
}
신뢰 정책에서 역할이 삭제되면 어떻게 되나요?
신뢰 정책에서 Principal 의 구성 값으로 특정한 역할을 지정하는 경우, AWS는 권한을 부여 하기 위해 역할마다 할당된 고유한 역할 ID 를 사용하게 됩니다. 예를들어, 앞의 예시 정책에서 언급했던 ExampleCorpRole 역할을 111122223333 계정에서 삭제하고 다시 생성한다면, 고유한 역할 ID가 변경됩니다. 따라서 새로 다시 생성한 ExampleCorpRole은 신뢰 정책의 Principal 구성 값이 달라져 기존 동일한 이름으로는 맡을 수 있었던 역할을 더이상 맡을 수 없게 됩니다.
역할이 삭제 되는 경우, 삭제된 역할을 참조하던 나머지 역할의 신뢰 정책에 삭제된 역할의 고유한 역할 ID가 신뢰정책의 Principal 구성요소에 표시됩니다.
"Principal": {"AWS": "AROA1234567123456D"}
이 정책은 현재 유효하지 않은 역할 ID 를 참조하고 있기 때문에 유효하지 않은 역할 ID 를 먼저 삭제한 뒤 수정해야 합니다. 원래 사용하던 역할의 ARN을 확인하려면 CloudTrail 로그 중 UpdateAssumeRolePolicy 및 CreateRole 이벤트에 대한 로그의 신뢰 정책 부분을 확인하시면 됩니다.
정책문의 Principal 구성요소 사용에 대한 더 자세한 정보는 IAM 역할 보안주체 문서를 확인하시기 바랍니다.
신뢰 정책문의 Condition 블록에서 Principal 구문은 역할 ID 를 참조하지 않고 대신 역할의 ARN을 참조합니다. 아래의 신뢰 정책문에서는 ExampleCorpRole을 삭제한 뒤 다시 생성한 경우에도 자신을 신뢰하고 있는 역할을 계속해서 맡을 수 있습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": "arn:aws:iam::111122223333:role/ExampleCorpRole"
}
}
}
]
}
역할의 신뢰 정책을 만들 때에는 역할이 삭제 됐을 때 어떻게 동작할 것인지 결정해야 합니다. 조직의 보안 태세에 따라 삭제된 뒤 다시 생성된 역할이 더 이상 계정에서 사용될 수 없도록 구성해야 한다면 Principal 구성 요소에 특정한 주체를 적절하게 사용할 수 있습니다. 또는 정해진 주체가 삭제되었다가 다시 만들어지는 경우 역할을 계속 사용할 수 있도록 구성할 수도 있습니다.
같은 계정 내에서 역할을 사용하는 것을 허용하려면 aws:PrincipalArn 조건을 :root 주체로 설정하시기 바랍니다. 이때 역할을 사용하는 주체는 sts:AssumeRole 작업을 주체의 자격 증명 기반 정책에서 허용해야 합니다.
정책에 와일드카드를 사용하기
앞서 와일드카드는 Principal 구성 시 ARN의 일부로 사용할 수 없다고 언급했습니다. 하지만 와일드카드는 정책의 Condition 문에서는 사용할 수 있습니다. 따라서 와일드카드는 신뢰 정책의 Condition 블록에서 ArnLike 또는 StringLike 조건과 함께 사용할 수 있습니다. 이 기능은 역할의 ARN을 정확하게 알 수 없지만 위임된 관리자와 같이 알려진 경로에 의해 역할이 만들어지는 경우에만 사용하도록 제한하는 등의 사례에 사용할 수 있습니다.
다음 정책은 111122223333 계정에서 OpsRoles 경로에서만 맡을 수 있도록 구성된 예시입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::111122223333:role/OpsRoles/"
}
}
}
]
}
전체 계정에 대해 허용하는 대신 가능한 특정 경로 또는 주체만 역할을 사용할 수 있도록 제한하는 것이 모범사례입니다.
다중 정책 구문을 사용하기
지금까지 이 블로그 포스팅에서는 단일 정책 문에 대한 예시만을 다뤘습니다. 하지만 신뢰 정책은 AWS 의 다른 정책과 마찬가지로 다중 정책 구문을 사용할 수 있습니다. 단, 역할의 신뢰 정책 길이의 할당량내로 정책문의 길이가 제한됩니다.
아래의 예시는 ExampleRole 이 정해진 네트워크 범위 (203.0.113.0/24) 내에서 AssumeRole 작업과 TagSession 작업을 할 수 있도록 허용하는 정책과 Admin 태그를 사용할 수 없도록 하는 정책문을 조합하여 사용하는 정책문을 보여 줍니다. 이처럼 여러개의 정책문을 조합하여 복잡한 역할 신뢰 정책을 만들 수 있습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/ExampleRole"
]
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
},
{
"Effect": "Deny",
"Action": "sts:TagSession",
"Principal": {
"AWS": ""
},
"Condition": {
"Null": {
"aws:RequestTag/Admin": false
}
}
}
]
}
여러 개의 정책문을 조합하여 사용할 수는 있지만, 가장 좋은 것은 정해진 목적으로만 역할을 사용하고, 서로 다른 AWS 서비스간에는 역할을 공유하여 사용하지 않는 것이 중요합니다. 즉, 사용 목적이 다르거나 각 AWS 서비스마다 서로 다른 정책을 사용하고, 서로 다른 주체가 동일한 IAM 역할에 접근하는 상황을 만들지 않는 것이 모범 사례입니다.
역할 세션 자격증명을 제공하는 서비스와 함께 사용하기
IAM Role Anywhere, AWS IoT Core 및 System Manager 와 같은 서비스는 AWS 외부에서 동작하는 기기, 서버 및 애플리케이션에 AWS 역할 세션의 자격증명을 전달할 수 있습니다. 이러한 역할은 AWS 서비스에서 사용되며, AWS 서비스에 의해 인증된 후 기기, 서버 및 애플리케이션으로 전달됩니다.
해당 서비스와 각각의 요구사항에 대한 더 많은 정보가 필요하면 다음 읽기 자료를 참고하시기 바랍니다.
- IAM Role Anywhere: Trust policy
- AWS IoT Core 자격 증명 공급자를 사용하여 AWS 서비스에 직접 호출 권한 부여하기
- Systems Manager : 하이브리드 및 멀티클라우드 환경을 위한 IAM 서비스 역할 생성
역할 체인
한 역할이 다른 역할을 맡는 것을 역할 체인이라고 합니다. 역할 체인에 의해 만들어진 세션의 수명은 역할이 허용하도록 구성된 최대 세션 길이와 관계 없이 최대 1시간으로 설정됩니다.
다른 방법으로 역할을 맡게 되는 경우는 역할 체인에 해당되지 않으므로 이러한 세션 시간 제한이 적용되지 않습니다.
결론
이 게시글에서는 특정 주체가 특정 조건에서 역할을 맡도록 제한하고, 여러 개의 정책 문을 서로 다른 조건과 결합하여 IAM 역할에 대한 신뢰 정책을 만드는 방법을 배웠습니다. 또한 소스 ID 및 세션 태그와 같은 기능을 사용하는 방법, 계정 간 혼동된 대리인 문제로부터 보호하는 방법, 그리고 Principal 구성 요소간의 미묘한 차이에 대해서 학습했습니다. 이제 잘 정의된 신뢰 정책을 이용하여 조직 내의 역할에 대한 강력하고, 효과적인 권한 관리를 해보시기 바랍니다.
이 게시물에 대한 피드백이 있는 경우 아래의 댓글 세션에 의견을 제출하세요. 이 게시물에 대한 질문이 있는 경우 AWS Support 팀을 통해 문의해주시기 바랍니다.
– Jonathan Jenkyn, 선임 보안 성장 전략 컨설턴트, AWS
– Liam Wadman, 솔루션즈 아키텍트, AWS
Source: AWS IAM 역할과 함께 신뢰 정책을 사용하는 방법
