기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # SRA 빌딩 블록 - AWS Organizations, 계정 및 가드레일 | | | --- | | [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua) 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다. | AWS 보안 서비스, 제어 및 상호 작용은 AWS[ 다중 계정 전략](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)과 자격 증명 및 액세스 관리 가드레일의 기반에 가장 잘 사용됩니다. 이러한 가드레일은 최소 권한, 업무 분리 및 개인 정보 보호를 구현할 수 있는 기능을 설정하고 필요한 제어 유형, 각 보안 서비스가 관리되는 위치, AWS SRA에서 데이터와 권한을 공유하는 방법에 대한 결정을 지원합니다. AWS 계정 는 리소스에 대한 보안, 액세스 및 결제 경계를 AWS 제공하며 리소스 독립성과 격리를 달성할 수 있습니다. 여러 *계정을 사용하여 AWS 환경 구성* 백서의 [여러 섹션을 사용하면 이점 AWS 계정](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html)에 설명된 대로 여러 AWS 계정 를 사용하면 보안 요구 사항을 충족하는 데 중요한 역할을 합니다. 예를 들어, 기업의 보고 구조를 미러링하는 대신 함수, 규정 준수 요구 사항 또는 일반적인 제어 세트를 기반으로 조직 단위(OU) 내의 개별 계정 및 그룹 계정에 워크로드를 구성할 수 있습니다. 워크로드가 증가함에 따라 기업이 공통 가드레일을 설정할 수 있도록 보안 및 인프라를 염두에 두세요. 이 접근 방식은 워크로드 간에 강력한 경계와 제어를 제공합니다. 계정 수준 분리 AWS Organizations는와 함께 프로덕션 환경을 개발 및 테스트 환경에서 격리하거나 Payment Card Industry Data Security Standard(PCI DSS) 또는 Health Insurance Portability and Accountability Act(HIPAA)와 같은 다양한 분류의 데이터를 처리하는 워크로드 간에 강력한 논리적 경계를 제공하는 데 사용됩니다. 단일 계정으로 AWS 여정을 시작할 수 있지만 워크로드의 크기와 복잡성이 증가함에 따라 여러 계정을 설정하는 것이 AWS 좋습니다. 권한을 사용하면 AWS 리소스에 대한 액세스를 지정할 수 있습니다. 보안 *주체*(사용자, 그룹 및 역할)라고 하는 IAM 엔터티에 권한이 부여됩니다. 기본적으로 보안 주체는 권한 없이 시작합니다. IAM 보안 주체는 권한을 부여할 AWS 때까지에서 아무 작업도 수행할 수 없으며, 전체 AWS 조직만큼 광범위하게 적용되거나 보안 주체, 작업, 리소스 및 조건의 개별 조합만큼 세분화된 가드레일을 설정할 수 있습니다. # 보안을 AWS Organizations 위한 사용 | | | --- | | [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua) 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다. | [AWS Organizations](https://aws.amazon.com/organizations/)는 AWS 리소스를 확장하고 확장함에 따라 환경을 중앙에서 관리하고 관리하는 데 도움이 됩니다. 를 사용하면 프로그래밍 방식으로 새 AWS Organizations를 생성하고 AWS 계정, 리소스를 할당하고, 계정을 그룹화하여 워크로드를 구성하고, 거버넌스를 위해 계정 또는 계정 그룹에 정책을 적용할 수 있습니다. AWS 조직은 단일 단위로 관리할 수 AWS 계정 있도록를 통합합니다. 0개 이상의 멤버 계정과 함께 하나의 관리 계정이 있습니다. 관리 계정 또는 특정에 대해 위임된 관리자로 할당된 계정에 상주해야 하는 일부 중앙 관리형 프로세스를 제외하고 대부분의 워크로드는 멤버 계정에 상주합니다 AWS 서비스. 보안 팀이 AWS 조직을 대신하여 보안 요구 사항을 관리할 수 있도록 중앙 위치에서 도구와 액세스를 제공할 수 있습니다. AWS 조직 내에서 중요한 리소스를 공유하여 리소스 중복을 줄일 수 있습니다. 워크로드의 요구 사항 및 목적에 따라 다양한 환경을 나타낼 수 있는 [AWS 조직 단위(OUs)로 계정을 그룹화할 수](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) 있습니다. AWS Organizations 또한는 조직의 모든 멤버 계정에 추가 보안 제어를 중앙에서 적용할 수 있는 여러 정책을 제공합니다. 이 섹션에서는 서비스 제어 정책(SCPs), 리소스 제어 정책(RCPs) 및 선언적 정책에 중점을 둡니다. 를 사용하면 [SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 및 [RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) 사용하여 AWS 조직, OU 또는 계정 수준에서 권한 가드레일을 적용할 AWS Organizations수 있습니다. SCPs는 관리 계정(이 계정에서 워크로드를 실행하지 않는 이유 중 하나)을 제외하고 조직 계정 내의 보안 주체에 적용되는 가드레일입니다. SCP를 OU에 연결하면 SCP는 해당 OU의 하위 OUs 및 계정에 의해 상속됩니다. SCPs 권한을 부여하지 않습니다. 대신 AWS 조직, OU 또는 계정의 보안 주체에 사용할 수 있는 최대 권한을 지정합니다. 실제로 권한을 부여하려면의 보안 주체 [또는 리소스에 자격 증명 기반 또는 리소스 기반 정책을](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) 연결해야 합니다. AWS 계정 예를 들어 SCP가 모든 Amazon S3에 대한 액세스를 거부하는 경우 SCP의 영향을 받는 보안 주체는 IAM 정책을 통해 명시적으로 액세스 권한이** **부여되더라도 Amazon S3에 액세스할 수 없습니다. IAM 정책 평가 방법, SCPs, 액세스 권한 부여 또는 거부 방법에 대한 자세한 내용은 IAM 설명서의 [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)을 참조하세요. RCPs는 리소스가 동일한 조직에 속하는지 여부에 관계없이 조직의 계정 내 리소스에 적용되는 가드레일입니다. SCPs와 마찬가지로 RCPs 관리 계정의 리소스에 영향을 주지 않으며 권한을 부여하지 않습니다. RCP를 OU에 연결하면 OU 아래의 하위 OUs 및 계정에 의해 RCP가 상속됩니다. RCPs 조직 내 리소스에 사용할 수 있는 최대 권한을 중앙에서 제어하며 현재의 하위 집합을 지원합니다 AWS 서비스. OUs용 SCPs를 설계할 때는 [IAM 정책 시뮬레이터](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)를 사용하여 변경 사항을 평가하는 것이 좋습니다. 또한 [IAM에서 마지막으로 액세스한 서비스 데이터를](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) 검토하고 [AWS CloudTrail 를 사용하여 API 수준에서 서비스 사용량을 로깅](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html)하여 SCP 변경의 잠재적 영향을 이해해야 합니다. SCP와 RCP는 독립적인 제어입니다. SCPs 또는 RCPs만 활성화하거나 적용하려는 액세스 제어에 따라 두 정책 유형을 함께 사용하도록 선택할 수 있습니다. 예를 들어 조직의 보안 주체가 조직 외부의 리소스에 액세스하지 못하도록 하려면 SCPs를 사용하여이 제어를 적용합니다. 외부 자격 증명이 리소스에 액세스하지 못하도록 제한하려면 RCPs를 사용하여이 제어를 적용합니다. RCP 및 SCPs에 대한 자세한 내용과 사용 사례는 AWS Organizations 설명서의 [ SCPs 및 RCPs 사용을 참조하세요](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html#when-to-use-scps-and-rcps). AWS Organizations 선언적 정책을 사용하여 조직 전체에서 지정된에 대해 원하는 구성을 중앙 AWS 서비스 에서 선언하고 적용할 수 있습니다. 예를 들어 조직 전체에서 Amazon VPC 리소스에 대한 퍼블릭 인터넷 액세스를 차단할 수 있습니다. SCPs 및 RCPs와 같은 권한 부여 정책과 달리 선언적 정책은 AWS 서비스의 컨트롤 플레인에 적용됩니다. 권한 부여 정책은 APIs에 대한 액세스를 규제하는 반면, 선언적 정책은 내구성 있는 의도를 적용하기 위해 서비스 수준에서 직접 적용됩니다. 이러한 정책은 서비스가 새로운 기능 또는 APIs를 도입하더라도 AWS 서비스 에 대한 기준 구성을 항상 유지하도록 보장합니다. 새 계정이 조직에 추가되거나 새 위탁자 및 리소스가 생성될 때도 기준 구성이 유지됩니다. 선언적 정책은 전체 조직 또는 특정 OUs 또는 계정에 적용할 수 있습니다. 모든 AWS 계정 에는 기본적으로 모든 AWS 리소스에 대한 전체 권한을 가진 단일 [루트 사용자가](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 있습니다.   보안 모범 사례로 루트 사용자가 명시적으로 필요한 [몇 가지 작업을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) 제외하고 루트 사용자를 사용하지 않는 것이 좋습니다. 여러를 AWS 계정 통해 관리하는 경우 루트 로그인을 중앙에서 비활성화한 다음 모든 멤버 계정을 대신하여 루트 권한 있는 작업을 수행할 AWS Organizations수 있습니다. 멤버 계정에 대한 [루트 액세스를 중앙에서 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)한 후 루트 사용자 암호, 액세스 키 및 서명 인증서를 삭제하고 멤버 계정에 대한 다중 인증(MFA)을 비활성화할 수 있습니다. 중앙 관리형 루트 액세스로 생성된 새 계정에는 기본적으로 루트 사용자 자격 증명이 없습니다. 멤버 계정은 루트 사용자로 로그인하거나 루트 사용자의 암호 복구를 수행할 수 없습니다. [AWS Control Tower](https://aws.amazon.com/controltower/)는 여러 계정을 설정하고 관리하는 간소화된 방법을 제공합니다. 조직의 계정 AWS 설정을 자동화하고, 프로비저닝을 자동화하고, [제어](https://docs.aws.amazon.com/controltower/latest/controlreference/controls-reference.html)(예방 및 탐지 제어 포함)를 적용하고, 가시성을 위한 대시보드를 제공합니다. 추가 IAM 관리 정책인 [권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)는 특정 IAM 보안 주체(사용자 또는 역할)에 연결되며 자격 증명 기반 정책이 IAM 보안 주체에 부여할 수 있는 최대 권한을 설정합니다. AWS Organizations 는 모든 계정에 [AWS 서비스](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) 적용되는를 구성하는 데 도움이 됩니다. 예를 들어 [CloudTrail](https://aws.amazon.com/cloudtrail/)을 사용하여 AWS 조직 전체에서 수행된 모든 작업에 대한 중앙 로깅을 구성하고 멤버 계정이 로깅을 비활성화하지 못하도록 할 수 있습니다. 또한를 사용하여 정의한 규칙에 대한 데이터를 중앙에서 집계할 수 [AWS Config](https://aws.amazon.com/config/)있으므로 워크로드의 규정 준수를 감사하고 변경 사항에 신속하게 대응할 수 있습니다. [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)를 사용하여 AWS 조직의 계정 및 OUs에서 CloudFormation 스택을 중앙에서 관리할 수 있으므로 보안 요구 사항에 맞게 새 계정을 자동으로 프로비저닝할 수 있습니다. 의 기본 구성은 SCPs *거부 목록*으로 사용할 수 있도록 AWS Organizations 지원합니다. 거부 목록 전략을 사용하면 멤버 계정 관리자는 특정 서비스 또는 작업 세트를 거부하는 SCP를 생성하고 연결할 때까지 모든 서비스 및 작업을 위임할 수 있습니다. 거부 문은가 새 서비스를 AWS 추가할 때 업데이트할 필요가 없으므로 허용 목록보다 유지 관리가 적게 필요합니다. 거부 문은 일반적으로 문자 길이가 짧기 때문에 SCPs의 최대 크기 이내로 유지하는 것이 더 쉽습니다. `Effect` 요소의 값이 `Deny`인 문에서는 특정 리소스에 대한 액세스를 제한하거나 SCP가 효력을 발휘하는 조건을 정의할 수도 있습니다. 반대로 SCP의 `Allow` 문은 모든 리소스(`"*"`)에 적용되며 조건에 의해 제한될 수 없습니다. 자세한 내용과 예제는 AWS Organizations 설명서의 [ SCPs 사용을 위한 전략을 참조하세요](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html). **설계 고려 사항** 또는 SCPs *허용 목록*으로 사용하려면 AWS 관리형 `FullAWSAccess` SCP를 허용하려는 서비스 및 작업만 명시적으로 허용하는 SCP로 바꿔야 합니다. 지정된 계정에 대해 권한을 활성화하려면 모든 SCP(루트에서 계정에 대한 직접 경로의 각 OU까지, 심지어 계정 자체에 연결됨)가 해당 권한을 허용해야 합니다. 이 모델은 본질적으로 더 제한적이며 규제가 높고 민감한 워크로드에 적합할 수 있습니다. 이 접근 방식을 사용하려면에서 OU까지의 경로에 있는 모든 IAM 서비스 또는 작업을 명시적으로 허용 AWS 계정 해야 합니다. 거부 목록과 허용 목록 전략의 조합을 사용하는 것이 가장 좋습니다. 허용 목록을 사용하여 AWS 조직 내에서 사용할 수 있도록 AWS 서비스 승인된 허용 목록을 정의하고 조직의 루트 AWS 에이 SCP를 연결합니다. 개발 환경당 허용되는 서비스 세트가 다른 경우 각 OU에 각 SCPs 연결합니다. 그런 다음 거부 목록을 사용하여 특정 IAM 작업을 명시적으로 거부하여 엔터프라이즈 가드레일을 정의할 수 있습니다. RCPs의 하위 집합에 대한 리소스에 적용됩니다 AWS 서비스. 자세한 내용은 설명서[의 RCPs를 AWS 서비스 지원하는 목록을 참조하세요](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#rcp-supported-services). AWS Organizations 의 기본 구성은 RCPs 거부 목록으로 사용할 수 있도록 AWS Organizations 지원합니다. 조직에서 RCPs 활성화하면 라는 AWS 관리형 정책`RCPFullAWSAccess`이 조직 루트, 모든 OU 및 조직의 모든 계정에 자동으로 연결됩니다. 이 정책은 분리할 수 없습니다. 이 기본 RCP를 사용하면 모든 보안 주체 및 작업에 대한 액세스 권한이 RCP 평가를 통과할 수 있습니다. 즉, RCPs 생성 및 연결을 시작할 때까지 기존 IAM 권한은 모두 그대로 작동합니다. 이 AWS 관리형 정책은 액세스 권한을 부여하지 않습니다. 그런 다음 새 RCPs 거부 문 목록으로 작성하여 조직의 리소스에 대한 액세스를 차단할 수 있습니다. # 관리 계정, 신뢰할 수 있는 액세스 및 위임된 관리자 | | | --- | | [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua) 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다. | 관리 계정( AWS 조직 관리 계정 또는 조직 관리 계정이라고도 함)은 고유하며 다른 모든 계정과 구별됩니다 AWS Organizations. 조직을 생성하는 계정입니다 AWS . 이 계정에서 AWS 조직에서 AWS 계정 를 생성하고, 조직에 다른 기존 계정을 AWS 초대하고(두 유형 모두 *멤버 계정으로* 간주), AWS 조직에서 계정을 제거하고, AWS 조직 내 루트, OUs 또는 계정에 IAM 정책을 적용할 수 있습니다. 관리 계정은 조직의 모든 멤버 계정에 영향을 미치는 SCPs, RCPs 및 서비스 배포(예: CloudTrail)를 통해 범용 보안 가드레일을 배포합니다 AWS . 관리 계정의 권한을 추가로 제한하기 위해 가능한 경우 보안 계정과 같은 다른 적절한 계정에 해당 권한을 위임할 수 있습니다. 관리 계정은 지급인 계정을 담당하며 멤버 계정에서 발생한 모든 요금을 지불해야 합니다. AWS 조직의 관리 계정은 전환할 수 없습니다. 는 한 번에 하나의 AWS 조직의 멤버일 AWS 계정 수 있습니다. 관리 계정이 보유한 영향의 기능과 범위 때문에이 계정에 대한 액세스를 제한하고 필요한 역할에만 권한을 부여하는 것이 좋습니다. 이를 지원하는 두 가지 기능은 [신뢰할 수 있는 액세스](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html)와 [위임된 관리자](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrated-services-list.html)입니다. 신뢰할 수 있는 액세스를 사용하여 신뢰할 수 AWS 서비스 있는 *서비스*라고 하는 지정한가 사용자를 대신하여 AWS 조직 및 해당 계정에서 작업을 수행할 수 있도록 할 수 있습니다. 이 과정에는 신뢰할 수 있는 서비스에 대한 권한 부여가 포함되지만 IAM 사용자 또는 역할에 대한 권한에는 달리 영향을 미치지 않습니다. 신뢰할 수 있는 액세스를 사용하여 신뢰할 수 있는 서비스가 사용자를 대신하여 AWS 조직의 계정에 유지할 설정 및 구성 세부 정보를 지정할 수 있습니다. 예를 들어 AWS SRA의 [조직 관리 계정](org-management.md) 섹션에서는 조직의 모든 계정에 AWS CloudTrail 조직 추적을 생성할 수 있는 신뢰할 수 있는 액세스 권한을 CloudTrail 서비스에 부여하는 방법을 설명합니다. 일부는에서 위임된 관리자 기능을 AWS 서비스 지원합니다 AWS Organizations. 이 기능을 사용하면* *호환되는 서비스가 AWS 조직의 AWS멤버 계정을 해당 서비스의 AWS 조직 계정에 대한 관리자로 등록할 수 있습니다. 이 기능은 엔터프라이즈 내 여러 팀이 책임에 따라 별도의 계정을 사용하여 환경 AWS 서비스 전체에서를 관리할 수 있는 유연성을 제공합니다. 현재 위임된 관리자를 지원하는 AWS SRA의 AWS 보안 서비스에는 IAM Identity Center, AWS Config, AWS Firewall Manager, Amazon GuardDuty, IAM Access Analyzer, Amazon Macie, AWS Security Hub Cloud Security Posture Management(AWS Security Hub CSPM), Amazon Detective AWS Audit Manager, Amazon Inspector 및가 포함됩니다 AWS Systems Manager. 위임된 관리자 기능의 사용은 AWS SRA에서 모범 사례로 강조되며 보안 관련 서비스의 관리를 보안 도구 계정에 위임합니다. # 전용 계정 구조 | | | --- | | [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua) 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다. | AWS 계정 는 리소스에 대한 보안, 액세스 및 결제 경계를 제공하며 리소스 독립성과 격리를 달성할 수 있습니다 AWS . 기본적으로 계정 간에는 액세스할 수 없습니다. OU 및 계정 구조를 설계할 때는 보안 및 인프라를 염두에 두고 시작하십시오. 이러한 특정 함수에 대한 기본 OUs 세트를 인프라 및 보안 OUs로 분할하여 생성하는 것이 좋습니다. 이러한 OU 및 계정 권장 사항은 및 다중 계정 구조 설계에 대한 보다 광범위 AWS Organizations 하고 포괄적인 지침의 하위 집합을 캡처합니다. 전체 권장 사항은 설명서의 [여러 계정을 사용하여 AWS 환경 구성](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 및를 [사용한 조직 단위 모범 사례를 AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/) 참조하세요. AWS AWS SRA는 다음 계정을 활용하여 효과적인 보안 작업을 수행합니다 AWS. 이러한 전용 계정은 업무 분리를 보장하고, 애플리케이션 및 데이터의 다양한 민감한 요소에 대한 다양한 거버넌스 및 액세스 정책을 지원하며, 보안 이벤트의 영향을 완화하는 데 도움이 됩니다. 이어지는 토론에서는 프로덕션(*생산*) 계정과 관련 워크로드에 중점을 둡니다. 소프트웨어 개발 수명 주기(SDLC) 계정(대개 *개발* 및 *테스트* 계정이라고 함)은 결과물을 스테이징하기 위한 것이며 프로덕션 계정과 다른 보안 정책 세트로 운영될 수 있습니다. | | | **Account** | **OU** | **보안 역할** | | --- |--- |--- | | 관리  | — | 모든 및 계정의 중앙 거버넌스 AWS 리전 및 관리. 조직의 루트를 호스팅 AWS 계정 하는 입니다 AWS . | | 보안 도구 | 보안 | 광범위하게 적용되는 보안 서비스(예: GuardDuty, Security Hub CSPM, Audit Manager, Detective, Amazon Inspector 및 AWS Config) 운영 AWS 계정, 보안 알림 및 대응 모니터링 및 자동화 AWS 계정 를 위한 전용 서비스입니다. (에서 보안 OU 아래에 있는 계정의 AWS Control Tower기본 이름은 *감사 계정*입니다.) | | 로그 보관 | 보안 | AWS 리전 모든 및 AWS 계정 에 대한 모든 로깅 및 백업을 수집하고 보관하는 데 전용입니다 AWS 계정. 이는 변경할 수 없는 스토리지로 설계되어야 합니다. | | Network | 인프라 | 애플리케이션과 더 광범위한 인터넷 간의 게이트웨이입니다. 네트워크 계정은 개별 애플리케이션 워크로드, 보안 및 기타 인프라에서 광범위한 네트워킹 서비스, 구성 및 작업을 격리합니다. | | 공유 서비스 | 인프라 | 이 계정은 여러 애플리케이션과 팀이 결과를 제공하는 데 사용하는 서비스를 지원합니다. 예를 들어 Identity Center 디렉터리 서비스(Active Directory), 메시징 서비스 및 메타데이터 서비스가 있습니다. | | 애플리케이션 | 워크로드 | AWS 계정 는 AWS 조직의 애플리케이션을 호스팅하고 워크로드를 수행합니다. (이를 *워크로드 계정*이라고도 합니다.) 팀에 매핑되는 대신 소프트웨어 서비스를 격리하기 위해 애플리케이션 계정을 생성해야 합니다. 이렇게 하면 배포된 애플리케이션이 조직 변화에 대한 복원력을 높일 수 있습니다. | # AWS AWS SRA의 조직 및 계정 구조 | | | --- | | [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua) 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다. | 다음 다이어그램은 특정 서비스를 표시하지 않고 AWS SRA의 상위 수준 구조를 캡처합니다. 이전 섹션에서 설명한 전용 계정 구조를 반영하며, 아키텍처의 기본 구성 요소에 대한 논의 방향을 잡기 위해 여기에 다이어그램을 포함합니다. + 다이어그램에 표시된 모든 계정은 단일 AWS 조직의 일부입니다. + 다이어그램의 왼쪽 상단에는 AWS 조직을 생성하는 데 사용되는 조직 관리 계정이 있습니다. + 조직 관리 계정 아래에는 두 개의 특정 계정이 있는 보안 OU가 있습니다. 하나는 보안 도구용이고 다른 하나는 로그 아카이브용입니다. + 오른쪽에는 네트워크 계정과 공유 서비스 계정이 있는 인프라 OU가 있습니다. + 다이어그램 하단에는 엔터프라이즈 애플리케이션을 포함하는 애플리케이션 계정과 연결된 워크로드 OU가 있습니다. 이 지침에서 모든 계정은 단일에서 작동하는 프로덕션(prod) 계정으로 간주됩니다 AWS 리전. 대부분 AWS 서비스 ([글로벌 서비스](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/global-services.html) 제외)은 리전별로 범위가 지정되므로 서비스에 대한 제어 및 데이터 영역이 각각 독립적으로 존재합니다 AWS 리전. 따라서 전체 AWS 환경에 대한 적용 범위를 보장하려면 사용 AWS 리전 하려는 모든에이 아키텍처를 복제해야 합니다. 특정에 워크로드가 없는 경우 [SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region) 사용하거나 로깅 및 모니터링 메커니즘을 사용하여 리전을 비활성화 AWS 리전해야 합니다. Security Hub CSPM을 사용하여 여러에서 단일 집계 리전으로 조사 결과 및 보안 점수를 집계 AWS 리전 하여 중앙 집중식 가시성을 확보할 수 있습니다. 대규모 계정 집합으로 AWS 조직을 호스팅할 때는 계정 배포 및 계정 거버넌스를 용이하게 하는 오케스트레이션 계층을 사용하는 것이 좋습니다.는 AWS 다중 계정 환경을 설정하고 관리하는 간단한 방법을 AWS Control Tower 제공합니다. [GitHub 리포지토리](https://github.com/aws-samples/aws-security-reference-architecture-examples)의 AWS SRA 코드 샘플은 [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 솔루션을 사용하여 AWS SRA 권장 구조를 배포하는 방법을 보여줍니다. ![\[AWS SRA의 상위 수준 구조(서비스 제외).\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/consolidated.png) # AWS 조직 전체에 보안 서비스 적용 | | | --- | | [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua) 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다. | [이전 섹션에서](value.md) 설명한 대로 고객은 전체 보안 서비스 세트를 AWS 고려하고 전략적으로 구성할 수 있는 추가 방법을 찾고 있습니다. 오늘날 가장 일반적인 조직 접근 방식은 각 서비스의 기능에 따라 기본 함수별로 보안 서비스를 그룹화하는 *것입니다*. AWS CAF의 보안 관점에는 자격 증명 및 액세스 관리, 인프라 보호, 데이터 보호, 위협 탐지 등 9가지 기능 기능이 나열되어 있습니다. 이러한 기능 역량 AWS 서비스 과 일치시키는 것은 각 영역에서 구현 결정을 내리는 실용적인 방법입니다. 예를 들어 ID 및 액세스 관리를 살펴볼 때 IAM 및 IAM Identity Center는 고려해야 할 서비스입니다. 위협 탐지 접근 방식을 설계할 때 GuardDuty가 첫 번째 고려 사항일 수 있습니다. 이 기능 보기를 보완하기 위해 교차 절단 구조 보기를 사용하여 보안을 볼 수도 있습니다. 즉, "자격 증명, 논리적 액세스 또는 위협 탐지 메커니즘을 제어하고 보호하려면 어떤 방법을 사용해야 AWS 서비스 합니까?"라고 묻는 것 외에도 "전체 AWS 조직에 어떤 방법을 적용 AWS 서비스 해야 합니까? 애플리케이션의 코어에서 Amazon EC2 인스턴스를 보호하기 위해 마련해야 하는 방어 계층은 무엇입니까?" 이 보기에서는 AWS 서비스 및 기능을 AWS 환경의 계층에 매핑합니다. 일부 서비스 및 기능은 전체 AWS 조직에서 제어를 구현하는 데 적합합니다. 예를 들어 Amazon S3 버킷에 대한 퍼블릭 액세스를 차단하는 것은이 계층에서 특정 제어입니다. 개별 계정 설정의 일부가 아닌 루트 조직에서 수행하는 것이 좋습니다. 다른 서비스 및 기능은 내의 개별 리소스를 보호하는 데 가장 적합합니다 AWS 계정. 프라이빗 TLS 인증서가 필요한 계정 내에서 하위 인증 기관(CA)을 구현하는 것이이 범주의 예입니다. 또 다른 똑같이 중요한 그룹화는 AWS 인프라의 가상 네트워크 계층에 영향을 미치는 서비스로 구성됩니다. 다음 다이어그램은 일반적인 AWS 환경의 6개 계층, 즉 AWS 조직, 조직 단위(OU), 계정, 네트워크 인프라, 보안 주체 및 리소스를 보여줍니다. ![\[AWS 환경의 6개 계층.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/six-layers.png) 각 계층의 제어 및 보호를 포함하여 이러한 구조적 컨텍스트의 서비스를 이해하면 AWS 환경 전체에서 defense-in-depth 전략을 계획하고 구현하는 데 도움이 됩니다. 이 관점에서는 위에서 아래로(예: "전체 AWS 조직에 보안 제어를 구현하는 데 어떤 서비스를 사용합니까?")와 아래에서 위로(예: "이 EC2 인스턴스에 대한 제어를 관리하는 서비스는 무엇입니까?") 질문에 모두 답할 수 있습니다. 이 섹션에서는 AWS 환경의 요소를 살펴보고 관련 보안 서비스 및 기능을 식별합니다. 물론 일부 에는 광범위한 기능 세트 AWS 서비스 가 있으며 여러 보안 목표를 지원합니다. 이러한 서비스는 AWS 환경의 여러 요소를 지원할 수 있습니다. 명확성을 위해 일부 서비스가 명시된 목표에 어떻게 부합하는지에 대한 간략한 설명을 제공합니다. [다음 섹션에서는](architecture.md) 각 섹션 내의 개별 서비스에 대한 추가 설명을 제공합니다 AWS 계정. ## 조직 전체 또는 여러 계정 최상위 수준에는 AWS 조직의 여러 계정(전체 조직 또는 특정 OU 포함)에 거버넌스 및 제어 기능 또는 가드레일을 적용하도록 설계된 AWS 서비스 및 기능이 있습니다. OUs 서비스 제어 정책(SCPs) 및 리소스 제어 정책(RCPs)은 예방적 AWS 조직 전체 가드레일을 제공하는 IAM 기능의 좋은 예입니다. AWS Organizations 또한는 AWS 서비스 대규모로에 대한 기준 구성을 중앙에서 정의하고 적용하는 선언적 정책을 제공합니다. 또 다른 예는 해당 *조직의 모든에 대한 모든 이벤트를 로깅하는 조직 추적* AWS 계정 을 통해 모니터링을 제공하는 CloudTrail입니다. AWS 이 포괄적인 추적은 각 계정에서 생성될 수 있는 개별 추적과 구별됩니다. 세 번째 예는 AWS 조직의 모든 계정에서 여러 리소스를 구성, 적용 및 관리하는 데 사용할 수 있는 AWS WAF 규칙 AWS Firewall Manager, AWS WAF 클래식 규칙, AWS Shield Advanced 보호, Amazon Virtual Private Cloud(Amazon VPC) 보안 그룹, AWS Network Firewall 정책 및 Amazon Route 53 Resolver DNS 방화벽 정책입니다. 다음 다이어그램에서 별표(\$1)로 표시된 서비스는 조직 전체 및 계정 중심의 이중 범위로 작동합니다. 이러한 서비스는 기본적으로 개별 계정 내에서 보안을 모니터링하거나 제어하는 데 도움이 됩니다. 그러나 중앙 집중식 가시성 및 관리를 위해 여러 계정의 결과를 조직 전체 계정으로 집계하는 기능도 지원합니다. 명확성을 위해 전체 OU AWS 계정또는 AWS 조직에 적용되는 SCPs를 고려하세요. 반대로 계정 수준(개별 조사 결과가 생성되는 곳)과 결과를 집계하여 보고 관리할 수 있는 AWS 조직 수준(위임된 관리자 기능 사용) 모두에서 GuardDuty를 구성하고 관리할 수 있습니다. ![\[조직 전체 및 계정 중심의 보안 서비스.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/org-multi-account.png) ## AWS 계정 OUs 내에는 내의 여러 유형의 요소를 보호하는 데 도움이 되는 서비스가 있습니다 AWS 계정. 예를 들어 AWS Secrets Manager 는 일반적으로 특정 계정에서 관리되며 리소스(예: 데이터베이스 자격 증명 또는 인증 정보), 애플리케이션 및 해당 계정 AWS 서비스 의 리소스를 보호합니다. IAM Access Analyzer는 외부의 보안 주체가 지정된 리소스에 액세스할 수 있을 때 결과를 생성하도록 구성할 수 있습니다 AWS 계정. 이전 단원에서 언급했듯이 이러한 서비스 중 대부분은 내에서 구성하고 관리할 수도 AWS Organizations있으므로 여러 계정에서 관리할 수 있습니다. 이러한 서비스는 다이어그램에 별표(\$1)로 표시됩니다. 또한 여러 계정의 결과를 더 쉽게 집계하고 단일 계정으로 전달할 수 있습니다. 이를 통해 개별 애플리케이션 팀은 워크로드와 관련된 보안 요구 사항을 관리할 수 있는 유연성과 가시성을 제공하면서 중앙 집중식 보안 팀에 거버넌스와 가시성을 제공할 수 있습니다. GuardDuty는 이러한 서비스의 예입니다. GuardDuty는 단일 계정과 연결된 리소스 및 활동을 모니터링하며, 여러 멤버 계정(예: AWS 조직의 모든 계정)의 GuardDuty 조사 결과는 위임된 관리자 계정에서 수집, 확인 및 관리할 수 있습니다. ![\[계정 내에서 여러 유형의 요소를 보호하는 보안 서비스입니다 AWS .\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/aws-account.png) ## 가상 네트워크, 컴퓨팅 및 콘텐츠 전송 네트워크 액세스는 보안에 매우 중요하며 컴퓨팅 인프라는 많은 AWS 워크로드의 기본 구성 요소이므로 이러한 리소스 전용 AWS 보안 서비스와 기능이 많이 있습니다. 예를 들어 Amazon Inspector는 AWS 워크로드의 취약성을 지속적으로 검사하는 취약성 관리 서비스입니다. 이러한 스캔에는 환경의 Amazon EC2 인스턴스에 허용되는 네트워크 경로가 있음을 나타내는 네트워크 연결성 검사가 포함됩니다. Amazon VPC를 사용하면 AWS 리소스를 시작할 수 있는 가상 네트워크를 정의할 수 있습니다. 이 가상 네트워크는 기존 네트워크와 매우 유사하며 다양한 기능과 이점을 포함합니다. VPC 엔드포인트를 사용하면 인터넷 경로 AWS PrivateLink 없이 VPC를 지원되는 AWS 서비스 및에서 제공하는 엔드포인트 서비스에 비공개로 연결할 수 있습니다. 다음 다이어그램은 네트워크, 컴퓨팅 및 콘텐츠 전송 인프라에 초점을 맞춘 보안 서비스를 보여줍니다. ![\[네트워크, 컴퓨팅 또는 콘텐츠 전송 인프라에 초점을 맞춘 보안 서비스\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/virtual-network.png) ## 보안 주체 및 리소스 AWS 보안 주체 및 AWS 리소스(IAM 정책과 함께)는 자격 증명 및 액세스 관리의 기본 요소입니다 AWS. 의 인증된 보안 주체는 작업을 수행하고 AWS 리소스에 액세스할 AWS 수 있습니다. 보안 주체는 AWS 계정 루트 사용자 및 IAM 사용자로 인증하거나 역할을 수임하여 인증할 수 있습니다.  **참고** AWS 루트 사용자 계정과 연결된 영구 API 키를 생성하지 마십시오. 루트 사용자 계정에 대한 액세스는 [루트 사용자가 필요한 작업](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root)으로만 제한한 다음 엄격한 예외 및 승인 프로세스를 통해서만 제한해야 합니다. 계정의 루트 사용자를 보호하는 모범 사례는 [IAM 설명서를](https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html) 참조하세요. AWS 리소스는 작업할 수 AWS 서비스 있는 내에 있는 객체입니다. 예를 들어 EC2 인스턴스, CloudFormation 스택, Amazon Simple Notification Service(Amazon SNS) 주제 및 S3 버킷이 있습니다. IAM 정책은 IAM 보안 주체(사용자, 그룹 또는 역할) 또는 AWS 리소스와 연결될 때 권한을 정의하는 객체입니다. [자격 증명 기반 정책은](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)** **보안 주체(역할, 사용자 및 사용자 그룹)에 연결하여 보안 주체가 수행할 수 있는 작업, 리소스 및 조건을 제어하는 정책 문서입니다. [리소스 기반 정책은](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)** ** S3 버킷과 같은 리소스에 연결하는 정책 문서입니다. 이러한 정책은 지정된 보안 주체에게 해당 리소스에 대해 특정 작업을 수행하고 해당 권한에 대한 조건을 정의할 수 있는 권한을 부여합니다. 리소스 기반 정책은 인라인 정책입니다. [IAM 리소스](iam-resources.md) 섹션에서는 IAM 정책의 유형과 사용 방법을 자세히 살펴봅니다. 이 논의에서 사물을 단순하게 유지하기 위해 계정 보안 주체에서 운영하거나 계정 보안 주체에 적용하는 주요 목적이 있는 IAM 보안 주체에 대한 AWS 보안 서비스 및 기능을 나열합니다. IAM 권한 정책의 유연성과 광범위한 효과를 인정하면서 이러한 단순성을 유지합니다. 정책의 단일 문은 여러 유형의 AWS 엔터티에 영향을 미칠 수 있습니다. 예를 들어 IAM 자격 증명 기반 정책이 IAM 보안 주체와 연결되어 있고 해당 보안 주체에 대한 권한(허용, 거부)을 정의하더라도이 정책은 지정된 작업, 리소스 및 조건에 대한 권한도 암시적으로 정의합니다. 이러한 방식으로 자격 증명 기반 정책은 리소스에 대한 권한을 정의하는 데 중요한 요소일 수 있습니다. 다음 다이어그램은 보안 주체에 대한 AWS AWS 보안 서비스 및 기능을 보여줍니다. 자격 증명 기반 정책은 IAM 사용자, 그룹 또는 역할에 연결됩니다. 이러한 정책으로 자격 증명이 수행할 수 있는 작업(권한)을 지정할 수 있습니다. IAM 세션 정책은 사용자가 역할을 수임할 때 세션에서 전달하는 [인라인 권한 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) 입니다. 정책을 직접 전달하거나 자격 증명 [이 연동될 때 정책을 삽입하도록 자격 증명 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) 브로커를 구성할 수 있습니다. 이렇게 하면 여러 사용자가 동일한 역할을 수임하면서도 고유한 세션 권한을 가질 수 있으므로 관리자가 생성해야 하는 역할 수를 줄일 수 있습니다. IAM Identity Center 서비스는 AWS Organizations 및 AWS API 작업과 통합되며 AWS 계정 에서 SSO 액세스 및 사용자 권한을 관리하는 데 도움이 됩니다 AWS Organizations. ![\[AWS 계정 보안 주체를 위한 보안 서비스 및 기능.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/principals.png) 다음 다이어그램은 계정 리소스에 대한 서비스 및 기능을 보여줍니다. 리소스 기반 정책은 리소스에 연결됩니다. 예를 들어 리소스 기반 정책을 S3 버킷, Amazon Simple Queue Service(Amazon SQS) 대기열, VPC 엔드포인트 및 AWS KMS 암호화 키에 연결할 수 있습니다. 리소스 기반 정책을 사용하여 리소스에 액세스할 수 있는 사용자와 리소스에 대해 수행할 수 있는 작업을 지정할 수 있습니다. S3 버킷 정책, AWS KMS 키 정책 및 VPC 엔드포인트 정책은 리소스 기반 정책의 유형입니다. IAM Access Analyzer를 사용하면 외부 엔터티와 공유되는 조직 및 계정 내 리소스(예: S3 버킷 또는 IAM 역할)를 식별할 수 있습니다. 이를 통해 리소스 및 데이터에 대한 의도하지 않은 액세스를 식별할 수 있으며, 이는 보안 위험입니다. 이를 AWS Config 통해에서 지원되는 AWS 리소스의 구성을 평가, 감사 및 평가할 수 있습니다 AWS 계정. AWS 리소스 구성을 AWS Config 지속적으로 모니터링 및 기록하고 기록된 구성을 원하는 구성과 비교하여 자동으로 평가합니다. ![\[AWS 계정 리소스에 대한 보안 서비스 및 기능.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/security-reference-architecture/images/resources.png)