보안을 위한 AWS Organizations 사용

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

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

RCPs는 리소스가 동일한 조직에 속하는지 여부에 관계없이 조직 계정 내의 리소스에 적용되는 가드레일입니다. SCPs와 마찬가지로 RCPs 관리 계정의 리소스에 영향을 주지 않으며 권한을 부여하지 않습니다. RCP를 OU에 연결하면 OU 아래의 하위 OUs 및 계정에 의해 RCP가 상속됩니다. RCPs 조직의 리소스에 사용할 수 있는 최대 권한을 중앙에서 제어하며 현재 AWS 서비스의 하위 집합을 지원합니다. OUs용 SCPs를 설계할 때는 IAM 정책 시뮬레이터를 사용하여 변경 사항을 평가하는 것이 좋습니다. 또한 IAM에서 서비스에서 마지막으로 액세스한 데이터를 검토하고 AWS CloudTrail을 사용하여 API 수준에서 서비스 사용량을 로깅하여 SCP 변경의 잠재적 영향을 이해해야 합니다.

SCPs와 RCPs는 독립적인 제어입니다. SCPs 또는 RCPs만 활성화하거나 적용하려는 액세스 제어에 따라 두 정책 유형을 함께 사용하도록 선택할 수 있습니다. 예를 들어 조직의 보안 주체가 조직 외부의 리소스에 액세스하지 못하도록 하려면 SCPs를 사용하여이 제어를 적용합니다. 외부 자격 증명이 리소스에 액세스하지 못하도록 제한하려면 RCPs를 사용하여이 제어를 적용합니다. RCP 및 SCPs에 대한 자세한 내용과 사용 사례는 AWS Organizations 설명서의 SCPs 및 RCPs 사용을 참조하세요.

AWS Organizations 선언적 정책을 사용하여 조직 전체에서 특정 AWS 서비스에 대해 원하는 구성을 중앙에서 선언하고 적용할 수 있습니다. 예를 들어 조직 전체에서 Amazon VPC 리소스에 대한 퍼블릭 인터넷 액세스를 차단할 수 있습니다. SCPs 및 RCPs와 같은 권한 부여 정책과 달리 선언적 정책은 AWS 서비스의 컨트롤 플레인에 적용됩니다. 권한 부여 정책은 APIs에 대한 액세스를 규제하는 반면, 선언적 정책은 내구성 있는 의도를 적용하기 위해 서비스 수준에서 직접 적용됩니다. 이러한 정책은 서비스가 새로운 기능이나 APIs. 새 계정이 조직에 추가되거나 새 보안 주체 및 리소스가 생성될 때도 기준 구성이 유지됩니다. 선언적 정책은 전체 조직 또는 특정 OUs 또는 계정에 적용할 수 있습니다.

모든 AWS 계정에는 기본적으로 모든 AWS 리소스에 대한 전체 권한을 가진 단일 루트 사용자가 있습니다.   보안 모범 사례로 루트 사용자가 명시적으로 필요한 몇 가지 작업을 제외하고 루트 사용자를 사용하지 않는 것이 좋습니다. AWS Organizations를 통해 여러 AWS 계정을 관리하는 경우 루트 로그인을 중앙에서 비활성화한 다음 모든 멤버 계정을 대신하여 루트 권한 있는 작업을 수행할 수 있습니다. 멤버 계정에 대한 루트 액세스를 중앙에서 관리한 후 루트 사용자 암호, 액세스 키 및 서명 인증서를 삭제하고 멤버 계정에 대한 멀티 팩터 인증(MFA)을 비활성화할 수 있습니다. 중앙 관리형 루트 액세스로 생성된 새 계정에는 기본적으로 루트 사용자 자격 증명이 없습니다. 멤버 계정은 루트 사용자로 로그인하거나 루트 사용자의 암호 복구를 수행할 수 없습니다.

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

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

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