보안을 위한 AWS Organizations 사용 - AWS 규범적 지침

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

보안을 위한 AWS Organizations 사용

간단한 설문 조사를 통해 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다.

AWS Organizations는 AWS 리소스를 성장시키고 확장함에 따라 환경을 중앙에서 관리하고 관리하는 데 도움이 됩니다. AWS Organizations를 사용하면 프로그래밍 방식으로 새 AWS 계정을 생성하고, 리소스를 할당하고, 계정을 그룹화하여 워크로드를 구성하고, 거버넌스를 위해 계정 또는 계정 그룹에 정책을 적용할 수 있습니다. AWS 조직은 AWS 계정을 통합하여 단일 단위로 관리할 수 있습니다. 0개 이상의 멤버 계정과 함께 하나의 관리 계정이 있습니다. 관리 계정 또는 특정 AWS 서비스의 위임된 관리자로 할당된 계정에 상주해야 하는 일부 중앙 관리형 프로세스를 제외하고 대부분의 워크로드는 멤버 계정에 상주합니다. 보안 팀이 AWS 조직을 대신하여 보안 요구 사항을 관리할 수 있도록 중앙 위치에서 도구와 액세스를 제공할 수 있습니다. AWS 조직 내에서 중요한 리소스를 공유하여 리소스 중복을 줄일 수 있습니다. 워크로드의 요구 사항 및 목적에 따라 다양한 환경을 나타낼 수 있는 AWS 조직 단위(OUs)로 계정을 그룹화할 수 있습니다.

AWS Organizations를 사용하면 서비스 제어 정책(SCPs)을 사용하여 AWS 조직, OU 또는 계정 수준에서 권한 가드레일을 적용할 수 있습니다. 이러한 가드레일은 관리 계정(이 계정에서 워크로드를 실행하지 않는 이유 중 하나)을 제외하고 조직 계정 내의 보안 주체에게 적용됩니다. OU에 SCP를 연결하면 OU에 있는 하위 OUs 및 계정에 의해 상속됩니다. SCPs는 권한을 부여하지 않습니다. 대신 SCPs는 AWS 조직, OU 또는 계정에 대한 최대 권한을 지정합니다. 실제로 권한을 부여하려면 AWS 계정의 보안 주체 또는 리소스에 자격 증명 기반 또는 리소스 기반 정책을 연결해야 합니다. 예를 들어 SCP가 모든 Amazon S3에 대한 액세스를 거부하는 경우 SCP 정책을 통해 액세스 권한이 명시적으로 부여되더라도 IAM의 영향을 받는 보안 주체는 Amazon S3에 액세스할 수 없습니다. IAM 정책 평가 방법, SCPs의 역할, 액세스 권한 부여 또는 거부 방법에 대한 자세한 내용은 IAM 설명서의 정책 평가 로직을 참조하세요. 

AWS Control Tower는 여러 계정을 설정하고 관리하는 간소화된 방법을 제공합니다. Word AWS 조직의 계정 설정을 자동화하고, 프로비저닝을 자동화하고, 가드레일(예방 및 탐지 제어 포함)을 적용하고, 가시성을 위한 대시보드를 제공합니다. 추가 IAM 관리 정책인 권한 경계는 특정 IAM 엔터티(사용자 또는 역할)에 연결되며 자격 증명 기반 정책이 IAM 엔터티에 부여할 수 있는 최대 권한을 설정합니다.

AWS Organizations는 모든 계정에 적용되는 AWS 서비스를 구성하는 데 도움이 됩니다. 예를 들어 AWSWord CloudTrail를 사용하여 AWS 조직 전체에서 수행된 모든 작업에 대한 중앙 로깅을 구성하고 멤버 계정이 로깅을 비활성화하지 못하도록 할 수 있습니다. 또한 AWS Config를 사용하여 정의한 규칙에 대한 데이터를 중앙에서 집계할 수 있으므로 워크로드의 규정 준수를 감사하고 변경 사항에 빠르게 대응할 수 있습니다. AWS CloudFormation StackSetsWord를 사용하여 Word 조직의 계정 및 AWS에서 OUs AWS CloudFormation Word스택을 중앙에서 관리할 수 있으므로 보안 요구 사항에 맞게 새 계정을 자동으로 프로비저닝할 수 있습니다. 

AWS Organizations의 기본 구성은 SCPs를 거부 목록으로 사용하는 것을 지원합니다. 거부 목록 전략을 사용하면 멤버 계정 관리자는 특정 서비스 또는 작업 세트를 거부하는 SCP를 생성하고 연결할 때까지 모든 서비스와 작업을 위임할 수 있습니다. 거부 문은 AWS가 새 서비스를 추가할 때 업데이트할 필요가 없으므로 허용 목록보다 유지 관리가 덜 필요합니다. 거부 문은 일반적으로 문자 길이가 짧기 때문에 SCPs의 최대 크기 이내로 유지하는 것이 더 쉽습니다. Effect 요소의 값이 인 문에서는 특정 리소스에 대한 액세스를 제한하거나 SCPs가 적용되는 시기에 대한 조건을 정의할 수도 Deny있습니다. 반대로 SCP의 Allow 문은 모든 리소스("*")에 적용되며 조건에 의해 제한될 수 없습니다. 자세한 내용과 예제는 SCPs Organizations 설명서의 Word 사용에 대한 전략을 참조하세요. AWS

설계 고려 사항

  • 또는 SCPs를 허용 목록으로 사용하려면 AWS 관리FullAWSAccessSCP를 허용하려는 서비스 및 작업만 명시적으로 허용하는 SCP로 교체해야 합니다. 지정된 계정에 대해 권한을 활성화하려면 모든 SCP(루트에서 계정에 대한 직접 경로의 각 OU를 통해, 심지어 계정 자체에 연결됨)에서 해당 권한을 허용해야 합니다. 이 모델은 본질적으로 더 제한적이며 고도로 규제되고 민감한 워크로드에 적합할 수 있습니다. 이 접근 방식을 사용하려면 IAM 계정에서 OU까지의 경로에 있는 모든 AWS 서비스 또는 작업을 명시적으로 허용해야 합니다.

  • 거부 목록과 허용 목록 전략의 조합을 사용하는 것이 가장 좋습니다. 허용 목록을 사용하여 AWS 조직 내에서 사용하도록 승인된 허용되는 AWS 서비스 목록을 정의하고 SCP 조직의 루트에이 AWS를 연결합니다. 개발 환경에 따라 허용되는 서비스 세트가 다른 경우 각 OU에 해당 SCPs를 연결합니다. 그런 다음 거부 목록을 사용하여 특정 IAM 작업을 명시적으로 거부하여 엔터프라이즈 가드레일을 정의할 수 있습니다.