Amazon Web Services 한국 블로그
AWS IAM 역할과 함께 신뢰 정책을 사용하는 방법
AWS Identity and Access Management (IAM) Role (역할)은 고객이 AWS에서 운영하는 방식에서 중요한 구성 요소입니다. 이 게시물에서는 클라우드 보안 아키텍트 및 계정 관리자가 신뢰 정책을 사용하여 오용으로부터 IAM 역할을 보호할 수 있는 방법을 자세히 살펴보겠습니다. 이 게시물을 통해서 IAM 역할을 사용하여 대규모로 작동하는 신뢰 정책을 구축하고 조직의 리소스에 대한 액세스를 제어하는 가드레일을 제공하는 방법을 알게 될 것입니다.
일반적으로 AWS에서 IAM 역할을 사용할 수 있는 네 가지 시나리오가 있습니다.
- 한 AWS 서비스가 다른 AWS 서비스에 액세스 – AWS 서비스가 다른 AWS 서비스 또는 함수에 액세스해야 하는 경우 해당 액세스 권한을 부여하는 역할을 생성할 수 있습니다.
- 한 AWS 계정이 다른 AWS 계정에 액세스 – 이 용례는 일반적으로 크로스 계정 역할 패턴이라고 합니다. 이렇게 하면 다른 AWS 계정의 사람 또는 머신 IAM 보안 주체가 이 역할을 맡고 이 계정의 리소스에 대해 조치를 취할 수 있습니다.
- 제3자 웹 아이덴티티에 액세스 필요 – 이 용례에서는 Google 및 Facebook 같은 제3자 시스템이나 Amazon Cognito에서 자격 증명을 가진 사용자가 역할을 사용하여 계정의 리소스에 액세스할 수 있습니다.
- SAML2.0 페더레이션을 사용한 인증 – 사용자가 Single Sign-On 워크플로를 사용하여 AWS 계정에 액세스할 수 있도록 IAM 역할을 사용하여 연결하려는 Active Directory를 사용하는 엔터프라이즈에서 일반적으로 사용됩니다.
모든 경우에 IAM 역할의 구성은 IAM 사용자의 구성과 동일하며 다음 특성에 의해서만 구분됩니다.
- IAM 역할에는 장기 보안 인증이 연결되어 있지 않으며, 보안 주체(IAM 사용자, 머신 또는 기타 인증된 아이덴티티)가 IAM 역할을 맡고 해당 역할에 할당된 권한을 상속합니다.
- 보안 주체가 IAM 역할을 맡는 경우 발급되는 토큰은 일시적입니다. 만료되면 보안 인증 정보가 유출되고 재사용되는 것과 관련된 위험이 줄어듭니다.
- IAM 역할에는 다른 보안 주체가 맡을 수 있도록 충족해야 하는 조건을 정의하는 신뢰 정책이 있습니다. 이 신뢰 정책은 권한 에스컬레이션과 관련된 위험을 줄입니다.
권장 사항: IAM 사용자와 같은 영구 보안 인증보다는 임시 IAM 역할을 광범위하게 사용해야 합니다. 자세한 내용은 다음 페이지를 검토하십시오. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
AWS 계정에 액세스할 수 있는 사용자 목록은 시간이 지남에 따라 변경될 수 있지만 AWS 계정을 관리하는 데 사용되는 역할은 변경되지 않을 수 있습니다. IAM 역할을 사용하면 기본적으로 엔터프라이즈 아이덴티티 시스템(SAML 2.0)이 권한 시스템(AWS IAM 정책)에서 분리되므로 각 역할을 간편하게 관리할 수 있습니다.
AWS IAM 역할에 대한 액세스 관리
AWS IAM 역할에 적용할 수 있는 정책 유형을 참조하여 엔터프라이즈 아이덴티티 시스템과 권한 시스템 간의 관계를 생성하는 방법을 자세히 살펴보겠습니다.
IAM 역할에는 정책을 사용하는 세 곳이 있습니다.
- 권한 정책(인라인 및 연결) – 이러한 정책은 역할을 맡는 보안 주체가 수행(또는 제한)할 수 있는 권한과 리소스를 정의합니다.
- 권한 경계 – 권한 경계는 관리형 정책을 사용하여 아이덴티티 기반 정책이 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 엔터티의 권한 경계를 사용하면 아이덴티티 기반 권한 정책과 권한 경계 모두에서 허용되는 작업만 수행할 수 있습니다.
- 신뢰 관계 – 이 정책은 역할을 맡을 수 있는 보안 주체와 조건을 정의합니다. 이를 IAM 역할에 대한 리소스 기반 정책 이라고도 합니다. 이 정책을 간단히 ‘신뢰 정책’이라고 지칭합니다.
역할은 사람 사용자 또는 머신 보안 주체(예: Amazon Elastic Computer Cloud(Amazon EC2) 인스턴스 또는 AWS Lambda 함수)에서 맡을 수 있습니다. 이 게시물의 나머지 부분에서는 신뢰 정책을 구성하여 보안 주체가 역할을 사용하는 조건을 줄이는 방법을 알아봅니다.
간단한 신뢰 정책의 예
일반적인 용례는 제3자에서 해당 계정의 구성을 검토할 수 있도록 계정에 보안 감사 액세스를 제공해야 하는 경우입니다. 관련 권한 정책을 IAM 역할에 연결한 후 크로스 계정 신뢰 정책을 추가하여 제3자 감사자가 sts:AssumeRole API를 호출하여 감사된 계정에서 액세스 권한을 승격할 수 있도록 해야 합니다. 다음 신뢰 정책은 AWS 관리 콘솔을 통해 생성된 정책 예를 보여 줍니다.
보시다시피 Effect, Action 및 Condition 구성 요소가 있는 다른 IAM 정책과 구조가 동일합니다. 또한 Principal 파라미터는 있지만 Resource 속성은 없습니다. 이는 신뢰 정책의 맥락에서 리소스가 IAM 역할이기 때문입니다. 같은 이유로 Action 파라미터는 sts:AssumeRole, sts:AssumeRoleWithSAML 또는 sts:AssumeRoleWithWebIdentity 값 중 하나로만 설정됩니다.
참고: 정책의
Principal속성에 있는 root 접미사는 AWS 계정이 생성될 때 생성되는 특별하고 강력한 루트 사용자 보안 주체가 아니라 “계정에서 인증되고 권한이 부여된 보안 주체”와 같습니다.
Principal 속성을 사용하여 범위 축소
신뢰 정책에서 Principal 속성은 IAM 역할을 맡을 수 있는 다른 보안 주체를 나타냅니다. 위의 예에서 111122223333은 감사자의 AWS 계정에 대한 AWS 계정 번호를 나타냅니다. 실제로 이렇게 하면 sts:AssumeRole 권한이 있는 111122223333 AWS 계정의 모든 보안 주체가 이 역할을 맡을 수 있습니다.
특정 IAM 사용자 계정에 대한 액세스를 제한하려면 111122223333 계정의 IAM 사용자 LiJuan만 이 역할을 맡을 수 있도록 다음 예와 같이 신뢰 정책을 정의하면 됩니다. LiJuan이 작동하려면 IAM 사용자에게 sts:AssumeRole 권한도 연결되어 있어야 합니다.
Principal 속성에 설정된 보안 주체는 IAM 설명서에 정의된 모든 보안 주체가 될 수 있으며 AWS 또는 페더레이션 보안 주체를 지칭할 수 있습니다. 하나의 특별 조건 외에 신뢰 정책에 대해 Principal 내에서 와일드카드(“*” 또는 “?”)를 사용할 수 없습니다. 이 조건은 잠시 후에 다시 설명하겠습니다. 보안 주체의 숨겨진 보안 주체 ID에 연결하는 신뢰 정책을 제출할 때 변환이 발생하므로 언급하는 보안 주체를 정확하게 정의해야 합니다. 보안 주체에 와일드카드가 있는 경우 그렇게 할 수 없습니다.
Principal 파라미터에 와일드카드를 사용할 수 있는 유일한 시나리오는 파라미터 값이 “*” 와일드카드인 경우입니다. IAM 역할의 사용을 제한하기 위해 정책 문에서 Conditional 속성을 명확하게 정의하지 않는 한 Principal에 글로벌 와일드카드 “*”를 사용하지 않는 것이 좋습니다. Conditional 속성을 사용하지 않으면 누구인지 상관없이 모든 AWS 계정의 모든 보안 주체가 역할을 가정할 수 있기 때문입니다.
AWS에서 아이덴티티 페더레이션 사용
SAML 2.0을 준수하는 엔터프라이즈 아이덴티티 서비스의 페더레이션 사용자에게는 IAM 역할을 사용하여 AWS 계정에 액세스할 수 있는 권한이 부여됩니다. 이 연결의 사용자 대 역할 구성은 SAML 2.0 아이덴티티 공급자 내에서 설정되지만 IAM의 신뢰 정책에도 제어를 적용하여 부정 사용을 줄여야 합니다.
Principal 속성에는 SAML 매핑에 대한 구성 정보가 포함되어 있으므로 Active Directory의 경우 신뢰 정책에서 Condition 속성을 사용하여 AWS 계정 관리 관점에서 역할의 사용을 제한해야 합니다. 이는 나중에 설명하는 것처럼 SourceIp 주소를 제한하거나 사용 가능한 SAML 관련 조건 키를 하나 이상 사용하여 수행할 수 있습니다. 여기서는 역할을 실용적으로 사용할 수 있는 보안 주체 집합을 줄이는 데 가능한 한 구체적으로 설명하는 것이 좋습니다. 이렇게 하려면 신뢰 정책의 Condition 속성에 한정자를 추가하는 것이 가장 좋습니다.
사용할 수 있는 기본 신뢰 정책 예가 포함된 SAML 2.0 페더레이션용 역할을 생성하는 방법에 대한 유용한 가이드가 있습니다.
신뢰 정책에서 Condition 속성을 사용하여 범위 축소
신뢰 정책의 Condition 문은 역할을 맡으려는 보안 주체에 대한 추가 요구 사항을 설정합니다. Condition 속성을 설정하지 않으면 IAM 엔진은 이 정책의 Principal 속성에만 의존하여 역할 가정을 승인합니다. Principal 속성 내에서 와일드카드를 사용할 수 없기 때문에 Condition 속성은 보안 주체를 지정하지 않고도 역할을 맡을 수 있는 사용자 집합을 줄일 수 있는 매우 유연한 방법입니다.
식별자를 기반으로 역할 사용 제한
때로는 여러 역할을 관리하는 팀이 어떤 역할이 무엇을 달성했는지 혼란스러워서 실수로 잘못된 역할을 맡을 수 있습니다. 이를 Confused Deputy 문제라고 합니다. 다음 섹션에서는 이러한 위험을 빠르게 줄일 수 있는 방법을 보여 줍니다.
다음 신뢰 정책에서는 111122223333 AWS 계정의 보안 주체가 역할을 맡기 위해 요청할 때 특별한 구문을 제공해야 합니다. 이 조건을 추가하면 111122223333 계정의 누군가가 실수로 이 역할을 맡게 될 위험이 줄어듭니다. 이 구문은 ExternalID 조건부 컨텍스트 키를 지정하여 구성됩니다.
위의 신뢰 정책 예에서 ExampleSpecialPhrase 값은 비밀번호나 암호가 아닙니다. ExternalID 조건을 추가하면 콘솔을 사용하여 이 역할을 맡지 못하도록 제한됩니다. 이 ExternalID 인수를 역할 가정 API 호출에 추가하는 유일한 방법은 AWS Command Line Interface(AWS CLI) 또는 프로그래밍 인터페이스를 사용하는 것입니다. 이 조건이 있다고 해서 이 관계 및 ExternalId에 대해 아는 사용자가 권한 있는 권한 집합이 무엇인지 가정하는 것을 막을 수는 없지만 Confused Deputy 문제와 같은 위험을 관리하는 데 도움이 됩니다. 고객이 AWS 계정의 이름과 일치하는 ExternalID를 사용하는 것을 볼 수 있습니다. 이는 운영자가 자신이 작업 중이라고 여기는 계정에서 작업하고 있는지 확인하는 데 효과적입니다.
다중 인증을 기반으로 역할 사용 제한
Condition 속성을 사용하면 이 역할을 사용하는 것이 허용되기 전에 이 역할을 맡는 보안 주체가 다중 인증(MFA) 검사를 통과하도록 요구할 수도 있습니다. 이는 역할의 잘못된 사용과 관련된 위험을 다시 제한하고 보안 주체의 아이덴티티에 대한 몇 가지 보증을 추가합니다.
위의 신뢰 정책 예에서는 MultiFactorAuthPresent 조건부 컨텍스트 키도 도입했습니다. AWS 글로벌 조건 컨텍스트 키 설명서에 따르면 다음 컨텍스트에서는 MultiFactorAuthPresent 조건부 컨텍스트 키가 sts:AssumeRole 요청에 적용되지 않습니다.
- CLI 또는 API에서 액세스 키를 사용하는 경우
- MFA 없이 임시 보안 인증을 사용하는 경우
- 사용자가 AWS 콘솔에 로그인하는 경우
- 서비스(예: AWS CloudFormation 또는 Amazon Athena)가 세션 보안 인증을 다시 사용하여 다른 API를 호출하는 경우
- 페더레이션을 통해 인증이 수행된 경우
위의 예에서 MultiFactorAuthPresent 조건부 컨텍스트 키에 BoolIfExists 한정자를 사용하면 다음과 같은 경우 조건이 true로 평가됩니다.
- 보안 주체 유형에는 MFA가 연결되어 있을 수 있으며 실제로 연결되어 있습니다.
또는 - 보안 주체 유형에는 MFA가 연결될 수 없습니다.
이는 미묘한 차이지만 신뢰 정책에서 이 조건부 키를 모든 보안 주체 유형에서 훨씬 더 유연하게 사용할 수 있습니다.
시간을 기반으로 역할 사용 제한
보안 감사와 같은 활동 중에는 활동이 시간 제한적이고 일시적인 경우가 많습니다. 감사 활동이 끝난 후에도 IAM 역할을 맡을 수 있는 위험이 있으며, 이는 바람직하지 않을 수 있습니다. 신뢰 정책의 Condition 속성에 시간 조건을 추가하여 이 위험을 관리할 수 있습니다. 즉, 고객은 활동 직후에 생성된 IAM 역할을 비활성화하는 대신 신뢰 정책에 날짜 제한을 구축할 수 있습니다. 이렇게 하려면 다음과 같이 정책 속성 문을 사용할 수 있습니다.
IP 주소 또는 CIDR 범위를 기반으로 역할 사용 제한
보안 감사의 감사자가 알려진 고정 IP 주소를 사용하는 경우 해당 정보를 신뢰 정책에 구축하면 다른 IP 주소 또는 CIDR 범위에서 AssumeRole API 함수를 호출하는 권한이 부여되지 않은 행위자가 역할을 맡을 기회를 더욱 줄일 수 있습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}태그를 기반으로 역할 사용 제한
또한 IAM 태깅 기능은 유연하고 조정 가능한 신뢰 정책을 구축하여 IAM 관리를 위한 속성 기반 액세스 제어(ABAC) 모델을 생성하는 데도 도움이 될 수 있습니다. 특정 키와 값으로 이미 태그가 지정된 보안 주체만 특정 역할을 맡을 수 있도록 허용하는 신뢰 정책을 구축할 수 있습니다. 다음 예에서는 AWS 계정 111122223333의 IAM 보안 주체에 department = OperationsTeam으로 태그를 지정하여 IAM 역할을 맡을 수 있도록 해야 합니다.
이 효과를 만들고 싶다면 위의 PrincipalTag 패턴을 사용하는 것이 좋습니다. 하지만 고유한 IAM 보안 주체에 다시 태그를 지정하거나 맡을 수 있는 다른 IAM 역할에 다시 태그를 지정하는 기능을 제한하기 위해 권한 경계 정책 내에서 aws:PrincipalTag 조건을 사용하여 어떤 보안 주체에 iam:TagUser, iam:TagRole, iam:UnTagUser 및 iam:UnTagRole 권한이 부여되는지에 대해서도 주의해야 합니다.
역할 체인
제3자에서 직접 IAM 역할을 사용하고 있거나 이미 역할을 맡은 AWS 서비스 리소스가 (다른 계정에서) 다른 역할을 맡아야 하는 경우가 있으며, 고객이 해당 원격 계정의 특정 IAM 역할만 계정에서 만든 IAM 역할을 맡을 수 있도록 허용하는 경우도 있습니다. 역할 체인을 사용하여 동일한 계정 또는 AWS 조직 내에서 또는 제3자 AWS 계정에서 맡은 역할을 사용하여 허용된 역할 에스컬레이션 경로를 구축할 수 있습니다.
Principal 속성의 조합을 사용하여 AWS 계정으로 범위를 축소하고, aws:UserId 글로벌 조건부 컨텍스트 키를 사용하여 RoleId를 사용하는 특정 역할로 범위를 축소하는 다음 신뢰 정책 예를 고려해 보십시오. 맡을 수 있는 역할의 RoleId를 캡처하려면 AWS CLI를 사용하여 다음 명령을 실행하면 됩니다.
다음은 AWS 계정 111122223333에서 CrossAccountAuditor 역할로만 제한하는 신뢰 정책의 예입니다.
IAM 사용자를 사용 중이고 CrossAccountAuditor IAM 역할을 맡은 경우 위의 정책은 aws sts assume-role을 호출하는 AWS CLI와 콘솔을 통해 작동합니다.
이 유형의 신뢰 정책은 Amazon EC2와 같은 서비스에도 적용되므로 할당된 인스턴스 프로파일 역할을 사용하는 인스턴스가 다른 계정의 역할을 맡아서 작업을 수행할 수 있습니다. 이 용례는 게시물 뒷부분에서 다루겠습니다.
종합
AWS 고객은 위의 모든 Principal 속성과 Condition 속성을 조합하여 제3자로 또는 고유한 조직 내에서까지 확장하려는 신뢰를 강화할 수 있습니다. IAM 역할에 대해 누적된 신뢰 정책을 생성하여 다음과 같은 효과를 얻을 수 있습니다.
AWS 계정 번호 111122223333의 PauloSantos 사용자만 MFA로 인증되고 203.0.113.0~203.0.113.24 CIDR 범위의 IP 주소에서 로그인하고 날짜가 2020년 9월 1일 정오부터 2020년 9월 7일 정오 사이인 경우 역할을 맡을 수 있도록 허용합니다.
고객이 이를 사용하여 sts:AssumeRole 외에 연결된 권한이 없는 IAM 사용자를 생성하는 것을 볼 수 있습니다. 그런 다음 IAM 사용자와 IAM 역할 간에 신뢰 관계가 구성되므로 IAM 사용자 아이덴티티 풀(pool)을 전혀 업데이트하지 않고도 누가 어떤 역할에 액세스할 수 있는지 유연하게 정의할 수 있습니다.
신뢰 정책에서 NotPrincipal의 사용
또한 신뢰 정책에 NotPrincipal 조건을 구축할 수도 있습니다. 다시 말하지만 정책에 불필요한 복잡성과 혼란을 초래할 수 있기 때문에 이는 최선의 선택은 아닙니다. 대신 매우 간단하고 규범적인 Principal 문을 사용하여 이러한 문제를 피할 수 있습니다.
NotPrincipal이 있는 문은 Deny 문도 사용할 수 있으므로 잘못 이해하는 경우 의도하지 않은 오용 또는 부정 사용 기회가 발생할 수 있는 상당히 당황스러운 정책 논리를 생성할 수 있습니다.
다음은 신뢰 정책에서 Deny 및 NotPrincipal을 사용할 수 있는 예입니다. 하지만 이는 단일 Allow 문에 arn:aws:iam::123456789012:role/CoreAccess를 추가하는 것과 동일한 효과가 있음을 알 수 있습니다. 일반적으로 신뢰 정책에서 NotPrincipal 문이 있는 Deny의 경우 불필요한 복잡성이 발생하므로 피해야 합니다.
Principal 속성은 역할을 맡을 수 있는 속성 집합을 줄이기 위해 매우 구체적이어야 하며, IAM 역할 신뢰 정책은 해당 Allow 문이 신뢰 정책에 명시적으로 없는 경우 액세스를 허용하지 않습니다. 정책 로직에 불필요한 복잡성을 도입하는 것보다 가능한 경우 자동거부방식 정책 평가 로직을 사용하는 것이 좋습니다.
역할을 맡는 AWS 서비스에 대한 신뢰 정책 생성
AWS 서비스가 작동하기 위해 IAM 역할에 액세스해야 하는 컨텍스트에는 두 가지 유형이 있습니다.
- AWS 서비스에서 관리하는 리소스(예: Amazon EC2 또는 Lambda)는 다른 AWS 리소스에서 함수를 실행하기 위해 IAM 역할에 액세스해야 하며, 그렇게 하기 위한 권한이 필요합니다.
- Amazon Elastic Container Service(Amazon ECS) 또는 Amazon Lex와 같은 다른 AWS 서비스에서 기능을 추상화하는 AWS 서비스는 AWS 리소스에서 함수를 실행하기 위한 액세스 권한이 필요합니다. 이러한 역할을 서비스 연결 역할이라고 하며 이 게시물의 범위를 벗어나는 특수한 경우입니다.
두 컨텍스트 모두에서 서비스 자체가 행위자로 있습니다. 이 서비스는 IAM 역할을 맡게 되므로 Lambda 함수에 보안 인증 정보를 제공하거나(첫 번째 컨텍스트) 이러한 보안 인증을 사용하여 작업을 수행할 수 있습니다(두 번째 컨텍스트). 위의 예에서 특정 함수로 작업하는 사용자에게 에스컬레이션 메커니즘을 제공하기 위해 사람 운영자가 IAM 역할을 사용하는 것과 마찬가지로, Lambda 함수, Amazon EC2 인스턴스 및 AWS CloudFormation 같은 AWS 리소스에도 동일한 메커니즘이 필요합니다. AWS 서비스용 IAM 역할을 생성하는 방법에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
사람 운영자와 AWS 서비스에 대한 IAM 역할은 신뢰 정책에 정의된 보안 주체가 다르더라도 완전히 동일합니다. 정책의 Principal은 해당 함수에 대한 역할을 맡을 수 있는 AWS 서비스를 정의합니다.
다음은 Amazon EC2 인스턴스가 맡도록 설계된 역할에 대한 신뢰 정책의 예입니다. 제공된 보안 주체가 ec2.amazonaws.com 서비스임을 알 수 있습니다.
AWS 리소스의 모든 구성에는 해당 함수에 고유한 특정 역할을 전달해야 합니다. 따라서 2개의 Amazon EC2 시작 구성이 있는 경우 필요한 권한이 현재 동일하더라도 2개의 개별 IAM 역할을 설계해야 합니다. 이렇게 하면 IAM 역할을 구성에 다시 연결할 필요 없이 각 구성에서 시간이 지남에 따라 필요한 권한을 늘리거나 줄일 수 있으므로 권한 에스컬레이션 위험이 발생할 수 있습니다. 대신 각 IAM 역할에 연결된 권한을 개별적으로 업데이트하여 하나의 서비스 리소스에서만 사용할 수 있습니다. 이는 위험의 잠재적 영향을 줄이는 데 도움이 됩니다. 역할 관리를 자동화하는 것도 도움이 될 것입니다.
일부 고객이 특정 Amazon EC2 인스턴스에만 전달할 수 있도록 IAM 역할에 대한 신뢰 정책을 설계할 수 있는지 문의했습니다. 이는 직접적으로 가능하지 않습니다. EC2 인스턴스에 대한 Amazon 리소스 이름(ARN)을 신뢰 정책의 Principal에 배치할 수 없으며, 신뢰 정책에서 태그 기반 조건 문을 사용하여 특정 리소스가 역할을 사용할 수 있는 기능을 제한할 수도 없습니다.
유일한 옵션은 IAM 역할을 AWS 리소스에 연결할 것으로 예상되는 IAM 보안 주체의 권한 정책 내에서 iam:PassRole 작업에 대한 액세스를 관리하는 것입니다. 이 특수 작업은 보안 주체가 AWS 서비스 또는 AWS 리소스에 다른 IAM 역할을 연결하려고 할 때 평가됩니다.
권한 정책 및 권한 경계와 함께 iam:PassRole 작업에 대한 액세스 제한을 사용해야 합니다. 즉, EC2 인스턴스에서 맡은 역할에 대한 신뢰 정책을 사용하여 이를 달성하는 것이 아니라 Amazon EC2의 인스턴스 프로파일에 역할을 연결할 수 있는 기능이 제한됩니다. 이 접근 방식을 사용하면 EC2 인스턴스에 역할을 연결하는 보안 주체와 인스턴스 자체의 크기 조정을 훨씬 쉽게 관리할 수 있습니다.
역할 이름 앞에 EC2-Webserver-가 접두부(prefix)로 없는 경우 연결된 역할이 다음 권한 정책을 사용하여 Amazon EC2 인스턴스에 다른 역할을 연결할 수 있는 기능을 제한하기 위해 권한 정책을 사용할 수 있습니다.
결론
이제 대규모로 작동하는 강력하고 효과적인 신뢰 정책을 구축하는 데 필요한 모든 도구를 사용할 수 있으므로 조직 외부에서 계정의 리소스에 액세스하려는 사용자와 사용자를 위한 가드레일을 제공할 수 있습니다.
정책 로직이 항상 간단한 것은 아니므로 샌드박스 계정을 사용하여 아이디어를 시험해 보는 것이 좋습니다. 일반적으로 단순함이 영리함을 이겨야 합니다. 정책 언어를 검소하게 사용할 수 있는 IAM 정책 및 문도 향후 다른 IAM 관리자가 읽고 해석하고 업데이트하기 어려울 수 있습니다. 신뢰 정책을 단순하게 유지하면 모든 사람이 이해하고 효과적으로 관리하고 사용할 수 있는 IAM 관계를 구축하는 데 도움이 됩니다.
이 블로그 게시물에 대한 피드백이 있는 경우 아래의 댓글 섹션에서 제출해 주십시오. 이 게시물에 대해 궁금한 점이 있으면 AWS IAM 포럼에서 새 스레드를 시작하거나 AWS Support에 문의하십시오.
AWS 보안의 방법 콘텐츠, 뉴스 및 기능 발표에 대한 내용이 궁금하십니까? Twitter에서 AWS를 팔로우하십시오.
Jonathan Jenkyn
Jonathan은 AWS Professional Services의 선임 보안 성장 전략 컨설턴트입니다. 그는 장애인 단체 선호도 그룹의 정회원이며 자선 운동 및 사회적 책임 운동을 지원하는 여러 Amazon 이니셔티브를 구축했습니다. 1998년부터 그는 암호화 프리미티브 구현에서 엔터프라이즈 보안 거버넌스 관리에 이르기까지 다양한 수준에서 IT 보안에 관여해 왔습니다. 직장 밖에서 그는 달리기, 자전거 타기, BHF 및 Ipswich Hospital Charity 기금 모금, 아내와 다섯 자녀와 함께 시간 보내기 등을 즐깁니다.