기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
SCP 평가
참고
이 섹션의 정보는 백업 정책, 태그 정책, 채팅 애플리케이션 정책 또는 AI 서비스 옵트아웃 정책을 포함한 관리 정책 유형에는 적용되지 않습니다. 자세한 내용은 관리 정책 상속에 대한 이해 단원을 참조하십시오.
AWS Organizations에서 여러 수준의 다양한 서비스 제어 정책 (SCP) 을 연결할 수 있으므로 SCP가 평가되는 방식을 이해하면 올바른 결과를 산출하는 SCP를 작성하는 데 도움이 될 수 있습니다.
SCP가 Allow와 협력하는 방식
특정 계정에 대한 권한을 허용하려면 계정(대상 계정 자체 포함)의 직접 경로에 대한 루트부터 각 OU까지 모든 수준에서 명시적인 Allow 설명이 있어야 합니다. SCPs 활성화하면는 모든 서비스 및 작업을 허용하는 FullAWSAccess
예를 들어 그림 1과 2에 표시된 시나리오를 살펴보겠습니다. 계정 B에서 권한 또는 서비스를 허용하려면 권한 또는 서비스를 허용하는 SCP를 루트, 프로덕션 OU 및 계정 B 자체에 연결해야 합니다.
SCP 평가는 기본 거부 모델을 따릅니다. 즉, SCP에서 명시적으로 허용되지 않은 권한은 거부됩니다. 루트, 프로덕션 OU 또는 계정 B와 같은 수준의 SCP에 허용되는 설명이 없으면 액세스가 거부됩니다.
그림 1: 루트, 프로덕션 OU 및 계정 B에 Allow 설명이 첨부된 조직 구조의 예
그림 2: 프로덕션 OU에서 누락된 Allow 설명이 있는 조직 구조의 예와 이것이 계정 B에 미치는 영향
SCP가 거부를 처리하는 방식
특정 계정에 대한 권한이 거부되는 경우, 루트에서 각 OU를 거쳐 계정의 직접 경로(대상 계정 자체 포함)에 있는 모든 SCP가 해당 권한을 거부할 수 있습니다.
예를 들어 프로덕션 OU에 특정 서비스에 대한 명시적 Deny 설명이 있는 SCP가 연결되어 있다고 가정해 보겠습니다. 그림 3과 같이 루트와 계정 B에 연결된 또 다른 SCP가 있는데, 이는 동일한 서비스에 대한 액세스를 명시적으로 허용합니다. 따라서 조직의 모든 수준에 연결된 거부 정책을 모든 OU 및 해당 계정 아래에 있는 멤버 계정에서 평가하므로 계정 A와 계정 B 모두 서비스에 대한 액세스가 거부됩니다.
그림 3: 프로덕션 OU에 Deny 설명이 연결된 조직 구조의 예와 이것이 계정 B에 미치는 영향
SCP 사용 전략
SCPs를 작성하는 동안 Allow 및 Deny 명령문의 조합을 사용하여 조직에서 의도한 작업과 서비스를 허용할 수 있습니다. Deny 명령문은 루트 또는 OUs 수준에서 적용될 때 해당 명령문의 모든 계정에 영향을 미치기 때문에 조직 또는 OU의 더 광범위한 부분에 적용되어야 하는 제한을 구현하는 강력한 방법입니다.
예를 들어 멤버 계정이 조직을 나가지 못하도록 방지 루트 수준에서에 대한 Deny 문을 사용하여 정책을 구현할 수 있으며, 이는 조직의 모든 계정에 적용됩니다. 거부 명령문은 예외를 생성하는 데 유용할 수 있는 조건 요소도 지원합니다.
작은 정보
IAM에서 서비스가 마지막으로 액세스한 데이터를 사용하여 필요한 AWS 서비스 로만 액세스를 제한하도록 SCP를 업데이트할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 Organizations에서 서비스가 마지막으로 액세스한 데이터 보기를 참조하세요.
AWS Organizations 는 생성 시 모든 루트, OU 및 계정에 FullAWSAccessAllow 명령문을 사용하여 특정 서비스만 허용할 수 있습니다.
두 명령문을 조합한 정책은 멤버 계정이 조직을 떠나는 것을 방지하고 원하는 AWS 서비스의 사용을 허용하는 다음 예와 유사할 수 있습니다. 조직 관리자는 FullAWSAccess 정책을 분리하고 대신에 이 정책을 연결하면 됩니다.
조직에서 여러 서비스 제어 정책(SCPs)을 AWS 적용하는 방법을 보여주려면 다음 조직 구조 및 시나리오를 고려하세요.
시나리오 1: 거부 정책의 영향
이 시나리오는 조직 내 상위 수준의 거부 정책이 아래의 모든 계정에 미치는 영향을 보여줍니다. 샌드박스 OU에 "전체 AWS 액세스" 및 "S3 액세스 거부" 정책이 모두 있고 계정 B에 "EC2 액세스 거부" 정책이 있는 경우 결과적으로 계정 B는 S3(OU 수준 거부) 및 EC2(계정 수준 거부)에 액세스할 수 없습니다. 계정 A에는 S3 액세스 권한이 없습니다(OU 수준 거부에서).
시나리오 2: 허용 정책은 모든 수준에서 존재해야 합니다.
이 시나리오는 SCPs에서 허용 정책이 작동하는 방식을 보여줍니다. 서비스에 액세스하려면 루트에서 계정까지 모든 수준에서 명시적인 허용이 있어야 합니다. 여기서 샌드박스 OU에는 EC2 서비스 액세스만 명시적으로 허용하는 "EC2 액세스 허용" 정책이 있으므로 계정 A와 B에는 EC2 액세스만 있습니다.
시나리오 3: 루트 수준에서 Allow 문 누락의 영향
SCP의 루트 수준에서 "허용" 문이 누락된 것은 조직의 모든 멤버 계정에 대한 AWS 서비스 및 작업에 대한 모든 액세스를 효과적으로 차단하는 중요한 잘못된 구성입니다.
시나리오 4: 계층화된 거부 문 및 결과 권한
이 시나리오는 2단계 심층 OU 구조를 보여줍니다. 루트 및 워크로드 OU에는 모두 "전체 AWS 액세스"가 있고, 테스트 OU에는 "EC2 AWS 액세스 거부"가 있는 "전체 액세스"가 있으며, 프로덕션 OU에는 "전체 AWS 액세스"가 있습니다. 따라서 계정 D는 EC2 및 계정 E와 F를 제외한 모든 서비스 액세스 권한을 갖습니다.
시나리오 5: OU 수준의 정책이 서비스 액세스를 제한하도록 허용
이 시나리오에서는 허용 정책을 사용하여 특정 서비스에 대한 액세스를 제한하는 방법을 보여줍니다. 테스트 OU에는 "EC2 액세스 허용" 정책이 있습니다. 즉, 계정 D에는 EC2 서비스만 허용됩니다. 프로덕션 OU는 "전체 AWS 액세스"를 유지하므로 계정 E와 F는 모든 서비스에 액세스할 수 있습니다. 이는 루트 수준에서 더 광범위한 허용을 유지하면서 OU 수준에서 더 제한적인 허용 정책을 구현할 수 있는 방법을 보여줍니다.
시나리오 6: 하위 수준 허용에 관계없이 루트 수준 거부가 모든 계정에 영향을 미침
이 시나리오는 하위 수준의 허용 정책에 관계없이 루트 수준의 거부 정책이 조직의 모든 계정에 영향을 미친다는 것을 보여줍니다. 루트에는 "전체 AWS 액세스" 및 "S3 액세스 거부" 정책이 모두 있습니다. 테스트 OU에 "S3 액세스 허용" 정책이 있더라도 루트 수준 S3 거부가 우선합니다. 테스트 OU는 S3 액세스만 허용하지만 루트 수준에서는 S3가 거부되므로 계정 D에는 서비스 액세스 권한이 없습니다. 계정 E와 F는 루트 수준에서 명시적 거부로 인해 S3를 제외한 다른 서비스에 액세스할 수 있습니다.
