기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 서비스 제어 정책(SCP) 서비스 제어 정책(SCP)은 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형입니다. SCP는 조직 내 모든 IAM 사용자 및 IAM 역할에 대해 사용 가능한 최대 권한을 중앙에서 제어합니다. SCP를 사용하면 조직의 액세스 제어 지침에 따라 계정을 유지할 수 있습니다. SCP는 [활성화된 모든 기능을 가진](orgs_manage_org_support-all-features.md) 조직에서만 사용할 수 있습니다. 조직이 통합 결제 기능만 지원한다면 SCP를 이용할 수 없습니다. SCP 활성화에 대한 지침은 [정책 유형 활성화](enable-policy-type.md) 단원을 참조하세요. SCP는 조직 내 IAM 사용자 및 IAM 역할에 권한을 부여하지 않습니다. SCP는 어떠한 권한도 부여하지 않습니다. SCP는 조직 내 IAM 사용자 및 IAM 역할이 수행할 수 있는 작업에 대한 권한 가드레일을 정의하거나 제한을 설정합니다. 권한을 부여하려면 관리자가 IAM 사용자 및 IAM 역할에 연결된 자격 증명 기반 정책, 계정의 리소스에 연결된 리소스 기반 정책 등 액세스를 제어하는 정책을 연결해야 합니다. 자세한 내용은 IAM 사용 설명서에서 [자격 증명 기반 정책 및 리소스 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)을 참조하세요.** [유효 권한](#scp-effects-on-permissions)은 SCP와 [리소스 제어 정책(RCP)](orgs_manage_policies_rcps.md)이 허용하는 권한과 ID 및 리소스 기반 정책이 허용하는 권한 간의 논리적 교집합입니다. **SCP는 관리 계정의 사용자 또는 역할에 영향을 미치지 않습니다.** SCP는 관리 계정의 사용자 또는 역할에 영향을 미치지 않습니다. 조직의 멤버 계정에만 영향을 줍니다. 이는 또한 SCP가 위임된 관리자로 지정된 멤버 계정에도 적용됨을 의미합니다. ****이 페이지의 주제**** + [SCP의 효과 테스트](#scp-warning-testing-effect) + [SCP의 최대 크기](#scp-size-limit) + [조직 내 여러 수준에 SCP 연결하기](#scp-about-inheritance) + [권한에 대한 SCP 효과](#scp-effects-on-permissions) + [액세스 데이터를 사용하여 SCP 개선](#data-from-iam) + [작업 및 엔터티는 SCP로 제한할 수 없습니다.](#not-restricted-by-scp) + [SCP 평가](orgs_manage_policies_scps_evaluation.md) + [SCP 구문](orgs_manage_policies_scps_syntax.md) + [서비스 제어 정책 예](orgs_manage_policies_scps_examples.md) + [를 사용하여 서비스 제어 정책(SCPs) 문제 해결 AWS Organizations](org_troubleshoot_policies.md) ## SCP의 효과 테스트 AWS 에서는 정책이 계정에 미치는 영향을 철저히 테스트하지 않고 SCPs를 조직의 루트에 연결하지 않을 것을 강력히 권장합니다. 대신 한 번에 하나씩, 또는 소량 단위로 계정을 옮길 수 있는 OU를 만들어 사용자가 주요 서비스를 이용하지 못하는 일이 없게 하세요. 서비스가 계정에 사용되는지 확인하는 한 가지 방법은 [IAM에서 마지막으로 데이터를 액세스한 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)를 살펴보는 것입니다. 또 다른 방법은를 [사용하여 API 수준에서 서비스 사용량을 로깅 AWS CloudTrail 하는](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html) 것입니다. **참고** **FullAWSAccess** 정책을 수정하거나 허용된 작업이 포함된 별도의 정책으로 대체하지 않는 한 이 정책을 제거해서는 안 됩니다. 그렇지 않으면 멤버 계정의 모든 AWS 작업이 실패합니다. ## SCP의 최대 크기 SCP 내 모든 문자는 [최대 크기](orgs_reference_limits.md#min-max-values)를 기준으로 계수됩니다. 이 설명서의 예제는 가독성을 높이기 위한 추가 공백으로 포맷된 SCP를 보여 줍니다. 하지만 정책 크기가 최대 크기에 근접한 경우 공백을 저장하려면 인용 부호 바깥에 있는 공백 문자(예: 공백 및 줄 바꿈)를 모두 삭제할 수 있습니다. **작은 정보** 시각적 편집기를 사용하여 SCP를 작성합니다. 편집기가 자동으로 불필요한 공백을 제거합니다. ## 조직 내 여러 수준에 SCP 연결하기 SCP가 작동하는 방식에 대한 자세한 설명은 [SCP 평가](orgs_manage_policies_scps_evaluation.md)을(를) 참조하세요. ## 권한에 대한 SCP 효과 SCPs는 AWS Identity and Access Management 권한 정책과 유사하며 거의 동일한 구문을 사용합니다. 그러나 SCP는 권한을 부여하지는 않습니다. 대신 SCP는 조직 내 IAM 사용자 및 IAM 역할에 대한 사용 가능한 최대 권한을 지정하는 액세스 제어입니다. 자세한 내용은 *IAM 사용자 안내서*의 [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)을 참조하세요. + SCP는 조직에 속한 계정이 관리하는 ***IAM 사용자 및 역할에만 영향을 줍니다***. SCP는 리소스 기반 정책에 직접 영향을 주지 않습니다. 조직 외부 계정의 사용자 또는 역할에도 영향을 주지 않습니다. 예를 들어 조직의 A 계정이 소유하는 Amazon S3 버킷을 가정해 보겠습니다. 버킷 정책(리소스 기반 정책)은 조직 외부의 B 계정에 속한 사용자에게 액세스 권한을 부여합니다. A 계정에는 SCP가 연결되어 있습니다. 해당 SCP는 B 계정의 외부 사용자에게 적용되지 않습니다. 이 SCP는 조직의 A 계정이 관리하는 사용자에게만 적용됩니다. + SCP는 멤버 계정의 IAM 사용자 및 역할(멤버 계정의 루트 사용자 포함)에 대해 권한을 제한합니다. 각 계정은 ***모든*** 상위 계정이 허용하는 권한만 갖게 됩니다. 권한이 계정 이상의 수준에서 묵시적으로나(`Allow` 정책문에 포함되지 않음) 명시적으로(`Deny` 정책문에 포함됨) 막혀 있다면, 영향받는 계정에 있는 사용자나 역할은 계정 관리자가 \$1/\$1 권한이 있는 `AdministratorAccess` IAM 정책을 사용자에 연결하더라도 해당 권한을 사용할 수 없습니다. + SCP는 조직의 ***멤버*** 계정에만 영향을 미칩니다. 관리 계정의 사용자 또는 역할에는 영향을 미치지 않습니다. 이는 또한 SCP가 위임된 관리자로 지정된 멤버 계정에도 적용됨을 의미합니다. 자세한 내용은 [관리 계정의 모범 사례](orgs_best-practices_mgmt-acct.md) 단원을 참조하십시오. + 사용자와 역할이 적절한 IAM 권한 정책으로 권한을 부여받아야 한다는 사실은 변하지 않습니다. IAM 권한 정책이 없는 사용자는 관련 SCP가 모든 서비스와 작업을 허용해도 액세스 권한이 없습니다. + 사용자나 역할에게 관련 SCP가 허용하는 작업에 대한 액세스를 부여하는 IAM 권한 정책이 있으면 사용자나 역할이 해당 작업을 수행할 수 있습니다. + 사용자나 역할에 관련 SCP가 허용하지 않거나 명시적으로 거부한 작업의 액세스 권한을 부여하는 IAM 권한 정책이 있으면 사용자나 역할이 해당 작업을 수행할 수 없습니다. + SCP는 ***루트 사용자를 포함하여*** 추가된 계정의 모든 사용자와 역할에 영향을 줍니다. 유일한 예외는 [작업 및 엔터티는 SCP로 제한할 수 없습니다.](#not-restricted-by-scp)에 설명되어 있습니다. + SCP는 어떠한 서비스 연결 역할에도 영향을 미치지 ***않습니다***. 서비스 연결 역할을 사용하면 다른 AWS 서비스 를와 통합할 수 AWS Organizations 있으며 SCPs에 의해 제한될 수 없습니다. + 루트에서 SCP 정책 유형을 비활성화하면 해당 루트의 모든 AWS Organizations 엔터티에서 모든 SCPs가 자동으로 분리됩니다. AWS Organizations 엔터티에는 조직 단위, 조직 및 계정이 포함됩니다. 루트에서 SCP를 다시 활성화하면, 해당 루트는 루트의 모든 개체에 자동적으로 연결된 기본 `FullAWSAccess` 정책으로 돌아갑니다. SCP를 비활성화하기 전에 이루어진 SCP와 AWS Organizations 개체 연결은 모두 사라지며, 수동으로 다시 연결할 수는 있지만 자동으로 복원되지는 않습니다. + 권한 경계(고급 IAM 기능)와 SCP가 둘 다 있는 경우 권한 경계, SCP 및 자격 증명 기반 정책 모두에서 해당 작업을 허용해야 합니다. ## 액세스 데이터를 사용하여 SCP 개선 관리 계정 자격 증명으로 로그인하면 IAM 콘솔의 **AWS Organizations** 섹션에서 AWS Organizations 엔터티 또는 정책에 대해 [마지막으로 액세스한 서비스 데이터를](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) 볼 수 있습니다. IAM의 AWS Command Line Interface (AWS CLI) 또는 AWS API를 사용하여 서비스에서 마지막으로 액세스한 데이터를 검색할 수도 있습니다. 이 데이터에는 AWS Organizations 계정의 IAM 사용자 및 역할이 마지막으로 액세스를 시도한 허용된 서비스 및 시기에 대한 정보가 포함됩니다. 이 정보를 사용하여 사용되지 않는 권한을 확인할 수 있으므로 SCP를 구체화함으로써 [최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)의 원칙을 보다 잘 준수할 수 있습니다. 예를 들어 세 가지 AWS 서비스에 대한 액세스를 금지하는 [거부 목록 SCP](orgs_manage_policies_scps_evaluation.md#how_scps_deny)가 있다고 합시다. SCP의 `Deny` 문에 없는 모든 서비스는 허용됩니다. IAM에서 서비스가 마지막으로 액세스한 데이터는 SCP에서 AWS 서비스 허용하지만 사용되지 않는 데이터를 알려줍니다. 이 정보로 SCP를 업데이트하여 필요 없는 서비스에 대한 액세스를 거부할 수 있습니다. 자세한 내용은 IAM 사용 설명서에서 다음 주제를 참조하세요. + [Organizations에서 서비스가 마지막으로 액세스한 데이터 보기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) + [ 데이터를 사용하여 조직 단위의 권한 구체화](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-example-scenarios.html#access_policies_access-advisor-reduce-permissions-orgs) ## 작업 및 엔터티는 SCP로 제한할 수 없습니다. 다음 작업은 ***SCP***를 사용해 제한할 수 없습니다. + 관리 계정이 수행하는 모든 작업 + 서비스 연결 역할에 연결된 권한을 사용한 모든 작업. + 루트 사용자로 Enterprise Support 플랜 등록하기 + CloudFront 프라이빗 콘텐츠에 대한 신뢰할 수 있는 서명자 기능 제공 + 루트 사용자로 Amazon Lightsail 이메일 서버 및 Amazon EC2 인스턴스에 대한 역방향 DNS 구성 + 일부 AWS관련 서비스에 대한 작업: + Alexa Top Sites + Alexa Web Information Service + Amazon Mechanical Turk + Amazon 제품 마케팅 API # SCP 평가 **참고** 이 섹션의 정보는 백업 정책, 태그 정책, 채팅 애플리케이션 정책 또는 AI 서비스 옵트아웃 정책을 비롯한 관리 정책 유형에 적용되지 ***않습니다***. 자세한 내용은 [관리 정책 상속에 대한 이해](orgs_manage_policies_inheritance_mgmt.md) 단원을 참조하십시오. AWS Organizations에서 여러 수준의 다양한 서비스 제어 정책 (SCP) 을 연결할 수 있으므로 SCP가 평가되는 방식을 이해하면 올바른 결과를 산출하는 SCP를 작성하는 데 도움이 될 수 있습니다. **Topics** + [SCP가 Allow와 협력하는 방식](#how_scps_allow) + [SCP가 거부를 처리하는 방식](#how_scps_deny) + [SCP 사용 전략](#strategy_using_scps) ## SCP가 Allow와 협력하는 방식 특정 계정에 대한 권한을 **허용**하려면 계정(대상 계정 자체 포함)의 직접 경로에 대한 루트부터 각 OU까지 모든 수준에서 **명시적인 `Allow` 설명**이 있어야 합니다. 따라서 SCPs 활성화하면가 모든 서비스 및 작업을 허용하는 [FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess)라는 AWS 관리형 SCP 정책을 AWS Organizations 연결합니다. 조직의 어느 수준에서도 이 정책을 제거하고 교체하지 않으면 해당 수준 이하의 모든 OU와 계정은 어떤 조치도 취하지 못하게 됩니다. 예를 들어 그림 1과 2에 표시된 시나리오를 살펴보겠습니다. 계정 B에서 권한 또는 서비스를 허용하려면 권한 또는 서비스를 허용하는 SCP를 루트, 프로덕션 OU 및 계정 B 자체에 연결해야 합니다. SCP 평가는 기본 거부 모델을 따릅니다. 즉, SCP에서 명시적으로 허용되지 않은 권한은 거부됩니다. 루트, 프로덕션 OU 또는 계정 B와 같은 수준의 SCP에 허용되는 설명이 없으면 액세스가 거부됩니다. ![\[루트, 프로덕션 OU 및 계정 B에 허용(Allow) 문이 연결된 조직 구조의 예\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_allow_1.png) *그림 1: 루트, 프로덕션 OU 및 계정 B에 `Allow` 문이 연결된 조직 구조의 예* ![\[프로덕션 OU에서 누락된 허용(Allow) 문이 있는 조직 구조의 예와 이것이 계정 B에 미치는 영향\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_allow_2.png) *그림 2: 프로덕션 OU에서 누락된 `Allow` 문이 있는 조직 구조의 예와 이것이 계정 B에 미치는 영향* ## SCP가 거부를 처리하는 방식 특정 계정에 대한 권한이 **거부**되는 경우, 루트에서 각 OU를 거쳐 계정의 직접 경로(대상 계정 자체 포함)에 있는 **모든 SCP**가 해당 권한을 거부할 수 있습니다. 예를 들어 프로덕션 OU에 특정 서비스에 대한 명시적 `Deny` 설명이 있는 SCP가 연결되어 있다고 가정해 보겠습니다. 그림 3과 같이 루트와 계정 B에 연결된 또 다른 SCP가 있는데, 이는 동일한 서비스에 대한 액세스를 명시적으로 허용합니다. 따라서 조직의 모든 수준에 연결된 거부 정책을 모든 OU 및 해당 계정 아래에 있는 멤버 계정에서 평가하므로 계정 A와 계정 B 모두 서비스에 대한 액세스가 거부됩니다. ![\[프로덕션 OU에 거부(Deny) 문이 연결된 조직 구조의 예와 이것이 계정 B에 미치는 영향\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_deny_1.png) *그림 3: 프로덕션 OU에 `Deny` 문이 연결된 조직 구조의 예와 이것이 계정 B에 미치는 영향* ## SCP 사용 전략 SCP를 작성할 때 `Allow` 및 `Deny` 문을 조합하여 조직에서 의도한 조치와 서비스를 허용할 수 있습니다. `Deny` 문은 루트 수준이나 OU 수준에서 적용되면 그 아래 있는 모든 계정에 적용되기 때문에 조직 또는 OU의 더 넓은 부분에 적용되어야 하는 제한을 구현할 수 있는 강력한 방법입니다. **작은 정보** [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)에서 [서비스가 마지막으로 액세스한 데이터](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)를 사용하여 필요한 AWS 서비스 로만 액세스를 제한하도록 SCP를 업데이트할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 [Organizations에서 서비스가 마지막으로 액세스한 데이터 보기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html)를 참조하세요. AWS Organizations 는 생성 시 모든 루트, OU 및 계정에 [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess)라는 AWS 관리형 SCP를 연결합니다. 이 정책은 모든 서비스와 작업을 허용합니다. SCP를 업데이트하여 명시적으로 허용되지 않는 한 새 AWS 서비스 가 허용되지 않도록 **FullAWSAccess**를 서비스 세트만 허용하는 정책으로 바꿀 수 있습니다. SCPs 예를 들어 조직에서 사용자 환경의 하위 집합 서비스만 사용하도록 허용하려는 경우 `Allow` 명령문을 사용하여 특정 서비스만 허용할 수 있습니다. 루트 수준 또는 모든 수준에서 **FullAWSAccess**를 교체하도록 선택할 수 있습니다. 루트에 서비스별 허용 목록 SCP를 연결하면 루트 아래의 모든 OUs 및 계정에 자동으로 적용됩니다. 즉, 단일 루트 수준 정책이 시나리오 7과 같이 전체 조직에 걸쳐 효과적인 서비스 허용 목록을 결정합니다. 또는 각 OU 및 계정에서 **FullAWSAccess**를 제거하고 교체하여 조직 단위 또는 개별 계정마다 다른 보다 세분화된 서비스 허용 목록을 구현할 수 있습니다. 참고: 허용 문과 암시적 deny-by-default 모델에만 의존하면 더 넓거나 중첩되는 허용 문이 더 제한적인 문을 재정의할 수 있으므로 의도하지 않은 액세스로 이어질 수 있습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" } ] } ``` ------ 두 명령문을 조합한 정책은 멤버 계정이 조직을 떠나는 것을 방지하고 원하는 AWS 서비스의 사용을 허용하는 다음 예와 유사할 수 있습니다. 조직 관리자는 **FullAWSAccess** 정책을 분리하고 대신에 이 정책을 연결하면 됩니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] } ``` ------ AWS 조직에서 여러 서비스 제어 정책(SCP)을 적용하는 방법을 보여주려면 다음 조직 구조 및 시나리오를 고려하세요. ### 시나리오 1: 거부 정책의 영향 이 시나리오는 조직 내 상위 수준의 거부 정책이 아래의 모든 계정에 미치는 영향을 보여줍니다. 샌드박스 OU에 "전체 AWS 액세스" 및 "S3 액세스 거부" 정책이 모두 있고 계정 B에 "EC2 액세스 거부" 정책이 있는 경우 결과적으로 계정 B는 S3(OU 수준 거부) 및 EC2(계정 수준 거부)에 액세스할 수 없습니다. 계정 A에는 S3 액세스 권한이 없습니다(OU 수준 거부에서). ![\[시나리오 1: 거부 정책의 영향\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_1.png) ### 시나리오 2: 모든 수준에서 허용 정책이 존재해야 함 이 시나리오는 SCP에서 허용 정책이 작동하는 방식을 보여줍니다. 서비스에 액세스하려면 루트에서 계정까지 모든 수준에서 명시적인 허용이 있어야 합니다. 여기서 샌드박스 OU에는 EC2 서비스 액세스만 명시적으로 허용하는 ‘EC2 액세스 허용’ 정책이 있으므로 계정 A와 B에는 EC2 액세스 권한만 있습니다. ![\[시나리오 2: 모든 수준에서 허용 정책이 존재해야 함\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_2.png) ### 시나리오 3: 루트 수준에서 허용(Allow) 문 누락의 영향 SCP의 루트 수준에서 "허용" 문이 누락된 것은 조직의 모든 멤버 계정에 대한 AWS 서비스 및 작업에 대한 모든 액세스를 효과적으로 차단하는 중요한 잘못된 구성입니다. ![\[시나리오 3: 루트 수준에서 허용(Allow) 문 누락의 영향\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_3.png) ### 시나리오 4: 계층화된 거부(Deny) 문 및 결과 권한 이 시나리오는 2단계 심층 OU 구조를 보여줍니다. 루트 및 워크로드 OU에는 모두 "전체 AWS 액세스"가 있고, 테스트 OU에는 "EC2 AWS 액세스 거부"가 있는 "전체 액세스"가 있으며, 프로덕션 OU에는 "전체 AWS 액세스"가 있습니다. 결과적으로, 계정 D는 EC2를 제외한 모든 서비스에 대한 액세스 권한을 가지며, 계정 E와 F는 모든 서비스에 대한 액세스 권한을 가집니다. ![\[시나리오 4: 계층화된 거부(Deny) 문 및 결과 권한\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_4.png) ### 시나리오 5: OU 수준의 정책이 서비스 액세스를 제한하도록 허용 이 시나리오에서는 허용 정책을 사용하여 특정 서비스에 대한 액세스를 제한하는 방법을 보여줍니다. 테스트 OU에는 ‘EC2 액세스 허용’ 정책이 있습니다. 즉, 계정 D에는 EC2 서비스만 허용됩니다. 프로덕션 OU는 ‘전체 AWS 액세스’를 유지하므로 계정 E와 F는 모든 서비스에 액세스할 수 있습니다. 이는 어떻게 루트 수준에서는 더 광범위한 허용 정책을 유지하면서 OU 수준에서는 더 제한적인 허용 정책을 구현할 수 있는지 보여줍니다. ![\[시나리오 5: OU 수준의 정책이 서비스 액세스를 제한하도록 허용\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_5.png) ### 시나리오 6: 하위 수준 허용과 관계없이 루트 수준 거부가 모든 계정에 영향을 미칩니다 이 시나리오는 하위 수준의 정책 허용에 관계없이 루트 수준의 거부 정책이 조직의 모든 계정에 영향을 미친다는 것을 보여줍니다. 루트에는 "전체 AWS 액세스" 및 "S3 액세스 거부" 정책이 모두 있습니다. 테스트 OU에 ‘S3 액세스 허용’ 정책이 있더라도 루트 수준 S3 거부가 우선합니다. 테스트 OU는 S3 액세스만 허용하지만 루트 수준에서는 S3가 거부되므로 계정 D에는 서비스 액세스 권한이 없습니다. 계정 E와 F는 루트 수준에서 명시적 거부로 인해 S3를 제외한 다른 서비스에 액세스할 수 있습니다. ![\[시나리오 6: 하위 수준 허용과 관계없이 루트 수준 거부가 모든 계정에 영향을 미칩니다\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_6.png) ### 시나리오 7: OU 수준 액세스를 제한하는 루트 수준 사용자 지정 허용 정책 이 시나리오는 명시적 서비스가 있는 SCPs 내에서 루트 수준에서 적용될 때 어떻게 작동하는지 보여줍니다 AWS Organizations. 조직 루트 수준에서는 제한된 AWS 서비스 세트에 대한 액세스를 명시적으로 허용하는 두 개의 사용자 지정 "서비스 허용" SCPs가 연결됩니다. SCP\$11은 IAM 및 Amazon EC2를 허용하고, SCP\$12는 Amazon S3 및 Amazon CloudWatch를 허용합니다. 조직 단위(OU) 수준에서 기본 FullAWSAccess 정책은 연결된 상태로 유지됩니다. 그러나 교차 동작으로 인해 이러한 OUs의 계정 A와 B는 루트 수준 SCP가 명시적으로 허용하는 서비스에만 액세스할 수 있습니다. 더 제한적인 루트 정책이 우선하므로 더 낮은 조직 수준에서 부여된 광범위한 권한과 관계없이 IAM, EC2, S3 및 CloudWatch 서비스에 대한 액세스만 효과적으로 제한합니다. ![\[시나리오 7: OU 수준 액세스를 제한하는 루트 수준 사용자 지정 허용 정책\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/images/scp_scenario_7.png) # SCP 구문 서비스 제어 정책(SCPs AWS Identity and Access Management (IAM) 권한 정책 및 [리소스 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)(예: Amazon S3 버킷 정책)에서 사용하는 구문과 유사한 구문을 사용합니다. IAM 정책과 그 구문에 대한 자세한 내용은 [IAM 사용 설명서](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)의 *IAM 정책 개요*를 참조하세요. SCP는 [JSON](http://json.org) 규칙에 따라 구성된 일반 텍스트 파일입니다. SCP는 이번 주제에서 설명하는 요소를 사용합니다. **참고** SCP 내 모든 문자는 [최대 크기](orgs_reference_limits.md#min-max-values)를 기준으로 계수됩니다. 이 설명서의 예제는 가독성을 높이기 위한 추가 공백으로 포맷된 SCP를 보여 줍니다. 하지만 정책 크기가 최대 크기에 근접한 경우 공백을 저장하려면 인용 부호 바깥에 있는 공백 문자(예: 공백 및 줄 바꿈)를 모두 삭제할 수 있습니다. SCP에 대한 일반적인 내용은 [서비스 제어 정책(SCP)](orgs_manage_policies_scps.md) 단원을 참조하세요. ## 요소 요약 다음 표에는 SCP에서 사용할 수 있는 정책 요소가 요약되어 있습니다. 일부 정책 요소는 작업을 거부하는 SCP에서만 사용할 수 있습니다. **지원되는 효과(Supported effects)** 열에는 SCP에서 각 정책 요소와 함께 사용할 수 있는 효과 유형이 나열되어 있습니다. | 요소 | 용도 | 지원되는 효과 | | --- | --- | --- | | [작업](#scp-syntax-action) | SCP가 허용하거나 거부하는 AWS 서비스 및 작업을 지정합니다. | `Allow`, `Deny` | | [효과](#scp-syntax-effect) | SCP 문이 계정의 IAM 사용자 및 역할에 대해 액세스를 [허용](orgs_manage_policies_scps_evaluation.md#how_scps_allow)하는지, 아니면 [거부](orgs_manage_policies_scps_evaluation.md#how_scps_deny)하는지를 정의합니다. | `Allow`, `Deny` | | [Statement](#scp-syntax-statement) | 정책 요소 컨테이너의 역할을 합니다. SCP에 여러 문을 포함할 수 있습니다. | `Allow`, `Deny` | | [Statement ID(Sid)](#scp-syntax-sid) | (선택 사항) 문의 표시 이름을 제공합니다. | `Allow`, `Deny` | | [버전](#scp-syntax-version) | 정책을 처리하는 데 사용할 언어 구문 규칙을 지정합니다. | `Allow`, `Deny` | | [조건](#scp-syntax-condition) | 문이 효력을 발휘하는 조건을 지정합니다. | `Allow,``Deny` | | [NotAction](#scp-syntax-action) | SCP에서 제외되는 AWS 서비스 및 작업을 지정합니다. `Action` 요소 대신 사용합니다. | `Allow,``Deny` | | [리소스](#scp-syntax-resource) | SCP가 적용되는 AWS 리소스를 지정합니다. | `Allow,``Deny` | | [NotResource](#scp-syntax-resource) | SCP에서 제외되는 AWS 리소스를 지정합니다. Resource 요소 대신 사용합니다. | `Allow`, `Deny` | 다음 섹션에서는 SCP에서 정책 요소가 사용되는 방식에 대한 자세한 설명 및 예제를 제공합니다. **Topics** + [요소 요약](#scp-elements-table) + [`Action` 및 `NotAction` 요소](#scp-syntax-action) + [`Condition` 요소](#scp-syntax-condition) + [`Effect` 요소](#scp-syntax-effect) + [`Resource`및 `NotResource` 요소](#scp-syntax-resource) + [`Statement` 요소](#scp-syntax-statement) + [Statement ID(`Sid`) 요소](#scp-syntax-sid) + [`Version` 요소](#scp-syntax-version) + [지원되지 않는 요소](#scp-syntax-unsupported) ## `Action` 및 `NotAction` 요소 `Action` 또는 `NotAction` 요소의 값은 문에 의해 허용되거나 거부되는 AWS 서비스 및 작업을 식별하는 문자열 목록(JSON 배열)입니다. 각 문자열은 서비스의 소문자 약자("s3", "ec2", "iam" 또는 "organizations" 등) 뒤에 콜론이 오고 그 뒤에 해당 서비스의 작업이 붙는 형태로 구성됩니다. Action 및 NotAction은 대/소문자를 구분하지 않습니다. 일반적으로 각 단어는 첫 글자만 대문자로, 나머지는 소문자로 입력합니다. 예를 들어 `"s3:ListAllMyBuckets"`입니다. SCP에서 별표(\$1) 또는 물음표(?) 와 같은 와일드카드 문자도 사용할 수도 있습니다. + 이름의 일부를 공유하는 여러 작업을 일치시키려면 별표(\$1)를 와일드카드로 사용하십시오. `"s3:*"` 값은 Amazon S3 서비스의 모든 작업을 의미합니다. `"ec2:Describe*"` 값은 "Describe"로 시작하는 EC2 작업에만 대응합니다. + 단일 문자를 일치시키려면 물음표(?) 와일드카드를 사용하십시오. AWS Organizations SCPs 및 IAM 권한 정책 모두에서 지원하는 모든 서비스 및 작업 목록은 *IAM 사용 설명서*의 [AWS 서비스에 사용되는 작업, 리소스 및 조건 키를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actionsconditions.html). 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: Action](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html) 및 [IAM JSON 정책 요소: NotAction](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html)을 참조하세요. ### `Action` 요소 예제 다음은 계정 관리자가 계정의 EC2 인스턴스에 대한 권한 설명, 시작, 중단, 중지를 위임하게 하는 문이 포함된 SCP를 보여주는 예제입니다. 이 예제는 [허용 목록](orgs_manage_policies_scps_evaluation.md#how_scps_allow)의 예입니다. 허용 목록은 기본 `Allow *` 정책이 연결되지 ***않아*** 기본적으로 권한이 묵시적으로 거부되는 때에 유용합니다. 기본 `Allow *` 정책이 다음과 같은 정책이 연결된 루트, OU 또는 계정에 여전히 연결돼 있다면, 해당 정책은 영향을 주지 못하게 됩니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs", "ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances", "ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances" ], "Resource": "*" } } ``` ------ 다음 예제는 연결된 계정에서 사용하지 않으려는 서비스에 대해 [액세스를 거부](orgs_manage_policies_scps_evaluation.md#how_scps_deny)하는 방법을 보여 줍니다. 기본 `"Allow *"` SCP가 모든 OU와 루트에 여전히 연결돼 있다고 가정합니다. 이 예제 정책은 연결 계정에 있는 계정 관리자가 IAM, Amazon EC2, Amazon RDS 서비스에 대해 어떤 권한도 위임하지 못하게 합니다. 이러한 권한을 거부하는 다른 연결된 정책이 없는 한, 다른 서비스의 모든 작업을 위임할 수 있습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": [ "iam:*", "ec2:*", "rds:*" ], "Resource": "*" } } ``` ------ ### `NotAction` 요소 예제 다음 예제에서는 `NotAction` 요소를 사용하여 정책의 효과에서 AWS 서비스를 제외하는 방법을 보여줍니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LimitActionsInRegion", "Effect": "Deny", "NotAction": "iam:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": "us-west-1" } } } ] } ``` ------ 이 문에서 영향을 받는 계정은 IAM 작업을 사용하는 경우를 AWS 리전제외하고 지정된에서 작업을 수행하는 것으로 제한됩니다. ## `Condition` 요소 SCP에서 허용 및 거부 문에 `Condition` 요소를 지정할 수 있습니다. 다음 예제에서는 SCP에서 허용 문과 함께 조건 요소를 사용하여 특정 보안 주체가 AWS 서비스에 액세스하도록 허용하는 방법을 보여줍니다. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowServicesForSpecificPrincipal", "Effect":"Allow", "Action":[ "ec2:*", "s3:*", "rds:*", "lambda:*", "cloudformation:*", "iam:*", "cloudwatch:*" ], "Resource":"*", "Condition":{ "StringEquals":{ "aws:PrincipalArn":[ "arn:aws:iam::123456789012:role/specific-role" ] } } } ] } ``` 다음 예제에서는 SCP에서 거부 문이 있는 조건 요소를 사용하여 지정된 서비스의 작업을 제외하고 `eu-central-1` 및 `eu-west-1` 리전 외부의 모든 작업에 대한 액세스를 제한하는 방법을 보여줍니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAllOutsideEU", "Effect": "Deny", "NotAction": [ "cloudfront:*", "iam:*", "route53:*", "support:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "eu-central-1", "eu-west-1" ] } } } ] } ``` ------ 자세한 정보는 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)을 참조하세요. ## `Effect` 요소 각 문에는 `Effect` 요소 하나가 있어야 합니다. 이때 값은 `Allow` 또는 `Deny`가 될 수 있습니다. 이것은 같은 문에서 나열하는 모든 작업에 영향을 줍니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 효과](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html)를 참조하세요. ### `"Effect": "Allow"` 다음 예제는 계정 사용자가 Amazon S3 서비스를 위한 작업을 수행하도록 허용하는 `Allow` 값을 갖는 `Effect` 요소를 포함한 문이 있는 SCP를 보여줍니다. 이 예제는 [허용 목록 전략](orgs_manage_policies_scps_evaluation.md#how_scps_allow)을 사용하는 조직에서 유용하게 활용할 수 있습니다(기본 `FullAWSAccess` 정책이 모두 분리되어 있어 기본적으로 권한이 묵시적으로 거부되는 전략). 결과적으로 이 문은 연결된 모든 계정에 대해 Amazon S3 권한을 [허용](orgs_manage_policies_scps_evaluation.md#how_scps_allow)합니다. ``` { "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } } ``` 이 문은 IAM 권한 정책과 동일한 `Allow` 값 키워드를 사용하지만, SCP에서는 실제로 사용자에게 특정 작업을 수행할 수 있는 권한을 부여하지 않습니다. 대신에 SCP가 조직 내 계정, 조직 단위(OU) 또는 계정에 대한 최대 권한을 지정하는 필터 역할을 합니다. 이전 예제에서, 계정의 사용자에게 `AdministratorAccess` 관리형 정책이 연결돼 있다 하더라도 이 SCP는 영향받는 계정의 ***모든*** 사용자가 Amazon S3 작업만 할 수 있게 합니다. ### `"Effect": "Deny"` `Effect` 요소의 값이 `Deny`인 문에서는 특정 리소스에 대한 액세스를 제한하거나 SCP가 효력을 발휘하는 조건을 정의할 수도 있습니다. 다음 예제는 거부 문에서 조건 키를 사용하는 방법을 보여줍니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotEquals": { "ec2:InstanceType": "t2.micro" } } } } ``` ------ SCP에서 이 문은 Amazon EC2 인스턴스가 `t2.micro`로 설정되지 않은 경우 영향받는 계정(SCP가 계정 자체에 연결된 계정 또는 계정을 포함한 조직 루트 또는 OU에 연결된 계정)이 Amazon EC2 인스턴스를 시작하는 것을 금지하는 가드레일을 설정합니다. 이 작업을 허용하는 IAM 정책이 계정에 연결되어 있더라도 SCP에 의해 생성된 가드레일이 이를 금지합니다. ## `Resource`및 `NotResource` 요소 `Effect` 요소의 값이 `Allow`인 문에서는 SCP의 `Resource` 요소에 "\$1"만 지정할 수 있습니다. 개별 Amazon 리소스 이름(ARN) 리소스를 지정할 수 없습니다. 리소스 요소에서 별표(\$1) 또는 물음표(?)와 같은 와일드카드 문자를 사용할 수 있습니다. + 이름의 일부를 공유하는 여러 작업을 일치시키려면 별표(\$1)를 와일드카드로 사용하세요. + 단일 문자를 일치시키려면 물음표(?) 와일드카드를 사용하십시오. `Effect` 요소의 값이 `Deny`인 문에서는 다음 예제와 같이 개별 ARN을 지정하는 것이 *가능*합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAccessToAdminRole", "Effect": "Deny", "Action": [ "iam:AttachRolePolicy", "iam:DeleteRole", "iam:DeleteRolePermissionsBoundary", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": [ "arn:aws:iam::*:role/role-to-deny" ] } ] } ``` ------ 이 SCP는 영향받는 계정의 IAM 사용자 및 역할이 조직 내 모든 계정에 생성된 공통 관리 IAM 역할을 변경하지 못하게 제한합니다. 다음 예에서는 `NotResource` 요소를 사용하여 정책 효과에서 특정 Amazon Bedrock 모델을 제외하는 방법을 보여줍니다. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"Statement1", "Effect":"Deny", "Action":[ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "NotResource":[ "arn:aws:bedrock:*::foundation-model/model-to-permit" ] } ] } ``` 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 리소스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html)를 참조하세요. ## `Statement` 요소 SCP는 하나 이상의 `Statement` 요소로 구성됩니다. 정책은 `Statement` 키워드 하나만 가질 수 있지만, 값은 ([ ] 문자로 구분한) JSON 문 어레이가 될 수 있습니다. 다음 예제는 하나의 `Effect`, `Action` 및 `Resource` 요소로 구성된 한 문을 보여줍니다. ``` "Statement": { "Effect": "Allow", "Action": "*", "Resource": "*" } ``` 다음 예제는 하나의 `Statement` 요소 안에 어레이 목록으로 존재하는 문 2개를 보여줍니다. 첫 번째 문은 모든 작업을 허용하지만 두 번째 문은 모든 EC2 작업을 거부합니다. 그 결과 계정 관리자는 Amazon Elastic Compute Cloud(Amazon EC2)를 *제외한* 모든 출처의 권한을 위임할 수 있습니다. ``` "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "ec2:*", "Resource": "*" } ] ``` 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 문](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html)을 참조하세요. ## Statement ID(`Sid`) 요소 `Sid`는 정책 문에 입력되는 식별자(옵션)입니다. `Sid` 값은 문 배열에서 각 문에 할당할 수 있습니다. 다음 예제 SCP는 샘플 `Sid` 문을 보여줍니다. ``` { "Statement": { "Sid": "AllowsAllActions", "Effect": "Allow", "Action": "*", "Resource": "*" } } ``` 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_id.html)를 참조하세요. ## `Version` 요소 모든 SCP에는 값이 `"2012-10-17"`인 `Version` 요소가 있어야 합니다. 이 버전 값은 IAM 권한 정책의 최신 버전과 같습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 버전](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html)을 참조하세요. ## 지원되지 않는 요소 다음 요소는 SCP에서 지원되지 않습니다. + `NotPrincipal` + `Principal` # 서비스 제어 정책 예 이 주제에 나온 예제 [서비스 제어 정책(SCP)](orgs_manage_policies_scps.md)은 정보 제공용입니다. **이 예제를 사용하기 전에** 조직에서 이러한 예제 SCPs 사용하기 전에 다음 사항을 고려하세요. [서비스 제어 정책(SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)은 대략적인 가드레일로 사용하기 위한 것이며 액세스를 직접 부여하지 않습니다. 실제로 권한을 부여하려면 관리자가 여전히 계정의 IAM 보안 주체 또는 리소스에 자격 [증명 기반 또는 리소스 기반 정책을](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) 연결해야 합니다. 유효 권한은 서비스 제어 정책/리소스 제어 정책과 자격 증명 정책 또는 서비스 제어 정책/리소스 제어 정책과 리소스 정책 간의 논리적 교집합입니다. 권한에 대한 SCP 효과에 대한 자세한 내용은 여기에서 확인할 수 [있습니다](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). 조직, 조직 단위 또는 계정에 연결된 경우 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)은 조직, 조직 단위 또는 계정의 모든 계정에 대해 사용 가능한 최대 권한을 중앙에서 제어합니다. 조직의 여러 수준에서 SCP를 적용할 수 있으므로 [SCPs 평가](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) 방법을 이해하면 올바른 결과를 산출하는 SCPs를 작성하는 데 도움이 될 수 있습니다. 이 리포지토리의 서비스 제어 정책은 예제로 표시됩니다. 정책이 계정에 미치는 영향을 철저히 테스트하지 않고 SCPs를 연결해서는 안 됩니다. 구현하려는 정책이 준비되면 프로덕션 환경을 나타낼 수 있는 별도의 조직 또는 OU에서 테스트하는 것이 좋습니다. 테스트를 마치면 더 구체적인 OUs에 변경 사항을 배포한 다음 시간이 지남에 따라 더 광범위하고 더 광범위한 OUs에 변경 사항을 천천히 배포해야 합니다. 이 리포지토리의 SCP 예제는 [거부 목록 전략을](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps) 사용합니다. 즉, [FullAWSAccess](https://console.aws.amazon.com/organizations/?#/policies/p-FullAWSAccess) 정책 또는 조직 엔터티에 연결된 액세스가 작업을 허용하도록 허용하는 기타 정책도 필요합니다. 또한 자격 증명 기반 또는 리소스 기반 정책을 사용하여 보안 주체에게 적절한 권한을 부여해야 합니다. **작은 정보** [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)에서 [서비스가 마지막으로 액세스한 데이터](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)를 사용하여 필요한 AWS 서비스 로만 액세스를 제한하도록 SCP를 업데이트할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 [Organizations에서 서비스가 마지막으로 액세스한 데이터 보기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html)를 참조하세요. ## GitHub 리포지토리 + [서비스 제어 정책 예제](https://github.com/aws-samples/service-control-policy-examples) -이 GitHub 리포지토리에는 AWS SCPs 있습니다. # 를 사용하여 서비스 제어 정책(SCPs) 문제 해결 AWS Organizations 여기에 있는 정보를 사용하여 서비스 제어 정책(SCP)에서 발견되는 일반적인 오류를 진단하고 해결하세요. 의 서비스 제어 정책(SCPs) AWS Organizations 은 IAM 정책과 유사하며 공통 구문을 공유합니다. 이 구문은 [JavaScript Object Notation](http://www.json.org)(JSON) 규칙으로 시작합니다. JSON은 객체를 구성하는 이름과 값 쌍으로 *객체를* 설명합니다. [IAM 정책 문법](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html)은 정책을 사용하여 권한을 부여하는 AWS 서비스 에서 어떤 이름과 값이 의미를 가지며 어떤 의미로 이해되는지를 정의함으로써 JSON을 기반으로 생성됩니다. AWS Organizations 는 IAM 구문 및 문법의 하위 집합을 사용합니다. 자세한 내용은 [SCP 구문](orgs_manage_policies_scps_syntax.md)을 참조하세요. **Topics** + [정책 객체가 하나 이상인 경우](#morethanonepolicyblock) + [Statement 요소가 하나 이상인 경우](#morethanonestatement) + [정책 문서가 최대 크기를 초과함](#scptoolong) ## 정책 객체가 하나 이상인 경우 SCP는 단 하나의 JSON 객체로 구성되어야 합니다. 객체는 중괄호 \$1 \$1로 묶어 표시합니다. 대괄호 [ ] 안에 중괄호 \$1 \$1를 추가로 삽입하여 JSON 객체 내에 다른 객체를 중첩시킬 수도 있지만 정책에 따라 중괄호 \$1 \$1를 묶는 대괄호 [ ]는 하나로 제한됩니다. 다음 예제는 ***올바르지 않은데***, 최상위 레벨에 (*붉은색*으로 호출한) 객체 2개가 있기 때문입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ 하지만 올바른 정책 문법을 사용하여 이전 예제의 의도를 만족하는 방법도 있습니다. 2개의 정책 객체에 `Statement` 요소를 각각 추가하지 않고 두 블록을 단일 `Statement` 요소로 결합하면 됩니다. 그러면 다음 예제와 같이 `Statement` 요소가 두 객체 배열을 값으로 인식합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` 이 예제는 서로 효과가 다른 요소 2개가 있어 요소가 하나인 `Statement`로 추가 압축할 수 없습니다. 일반적으로 각 문의 `Effect`와 `Resource` 요소가 같을 때만 문을 결합할 수 있습니다. ## Statement 요소가 하나 이상인 경우 이 오류는 처음에는 이전 섹션에 나온 오류의 변형처럼 보일지도 모릅니다. 하지만 구문으로 보면 다른 유형의 오류입니다. 다음 예제를 보면 중괄호 \$1 \$1 한 쌍이 최상위 레벨로 정책 객체 하나만 표시하고 있습니다. 하지만 객체에 포함된 `Statement` 요소는 2개입니다. SCP는 콜론 왼쪽의 이름(`Statement`)과 오른쪽의 값으로 구성된 `Statement` 요소 1개만 포함해야 합니다. 그리고, `Statement` 요소의 값은 `Effect` 요소 1개와 `Action` 요소 1개, 그리고 `Resource` 요소 1개가 중괄호 \$1 \$1로 묶여 구성된 객체가 되어야 합니다. 다음은 예제는 ***올바르지 않은데***, 정책 객체에 `Statement` 요소 2개가 있기 때문입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ 값 객체는 다수의 값 객체 배열이 될 수 있으므로 이 문제는 다음 예제와 같이 `Statement` 요소 2개를 객체 배열을 통해 하나의 요소로 결합하여 해결할 수 있습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource":"*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ `Statement` 요소 값이 객체 배열이 되었습니다. 예제의 배열은 두 객체로 구성되며, 각 객체 자체가 정확한 `Statement` 요소 값으로 인식됩니다. 배열을 구성하는 각 객체는 쉼표로 구분합니다. ## 정책 문서가 최대 크기를 초과함 SCP 문서의 최대 크기는 5,120자입니다. 이 최대 크기는 공백을 포함하여 모든 문자를 포함합니다. SCP의 크기를 줄이려면 인용 부호 바깥에 있는 공백 문자(예: 공백 및 줄 바꿈)를 모두 제거할 수 있습니다. **참고** 를 사용하여 정책을 저장하면 JSON 요소와 인용 부호 외부 사이의 AWS Management Console추가 공백이 제거되고 계산되지 않습니다. SDK 작업 또는를 사용하여 정책을 저장하면 제공된 대로 AWS CLI정책이 정확히 저장되며 문자가 자동으로 제거되지 않습니다.