# AWS 계정 관리 및 분리
조직의 보고 구조를 미러링하는 대신 기능, 규정 준수 요구 사항 또는 공통 제어 요소를 기반으로 별도의 계정과 그룹 계정에 워크로드를 구성하는 것이 좋습니다. AWS에서 계정은 하드 경계를 가지고 있습니다. 예를 들어 프로덕션 워크로드를 개발 및 테스트 워크로드에서 격리하려면 계정 수준의 분리를 적극 권장합니다.
**중앙에서 계정 관리**: AWS Organizations는 AWS [계정 생성 및 관리 그리고 생성된 계정에 대한 제어를 자동화](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html)합니다. AWS Organizations를 통해 계정을 생성할 때는 사용할 이메일 주소를 신중히 선택해야 합니다. 이 이메일 주소가 암호를 재설정할 수 있는 루트 사용자가 되기 때문입니다. Organizations를 사용하면 여러 계정을 [조직 단위(OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)로 그룹화하여 워크로드의 요구 사항과 용도에 따라 서로 다른 환경을 나타낼 수 있습니다.
**중앙에서 제어 설정:** 적절한 수준의 특정 서비스, 리전 및 서비스 작업만 허용하여 AWS 계정에서 수행할 수 있는 작업을 제어하세요. AWS Organizations에서는 서비스 제어 정책(SCP)을 사용하여 모든 [AWS Identity and Access Management](https://aws.amazon.com/iam/)(IAM) 사용자 및 역할에 적용되는 조직, 조직 단위 또는 계정 수준에서 권한 가드레일을 적용할 수 있습니다. 예를 들어 사용자가 명시적으로 허용하지 않은 리전에서는 리소스를 시작하지 못하도록 제한하는 SCP를 적용할 수 있습니다. AWS Control Tower는 여러 계정을 간편하게 설정하고 관리하는 방법을 제공합니다. 이는 AWS Organizations에서 계정 설정 및 프로비저닝을 자동화하고 [가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)(예방 및 탐지 포함)을 적용하며 대시보드를 제공하여 가시성을 확보합니다.
**중앙에서 서비스 및 리소스 구성**: AWS Organizations를 사용하면 모든 계정에 적용되는 [AWS 서비스](https://aws.amazon.com/organizations/features/)를 구성할 수 있습니다. 예를 들어 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)을 사용하면 조직 전체에서 수행되는 모든 작업을 중앙에서 로깅하도록 구성하고 구성원 계정이 로깅을 비활성화하지 않도록 할 수 있습니다. 또한 [AWS Config](https://aws.amazon.com/config/)을 사용하여 정의한 규칙에 대해 중앙에서 데이터를 집계할 수 있으므로 워크로드를 감사하여 규정 준수 여부를 확인하고, 변화에 신속하게 반응하도록 지원할 수 있습니다. AWS CloudFormation [StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)를 사용하면 조직 내의 여러 계정 및 OU에 걸쳐 AWS CloudFormation 스택을 중앙에서 관리할 수 있습니다. 이렇게 하면 보안 요구 사항에 부합하도록 새 계정을 자동으로 프로비저닝할 수 있습니다.
보안 서비스의 위임된 관리 기능을 사용하여 조직의 결제(관리) 계정에서 관리에 사용되는 계정을 분리합니다. GuardDuty, Security Hub, AWS Config 등의 여러 AWS 서비스에서는 관리 기능을 위해 특정 계정을 지정하는 등 AWS Organizations와의 통합을 지원합니다.
**Topics**
+ [SEC01-BP01 계정을 사용하여 워크로드 분리](sec_securely_operate_multi_accounts.md)
+ [SEC01-BP02 계정 루트 사용자 및 속성 보호](sec_securely_operate_aws_account.md)
# SEC01-BP01 계정을 사용하여 워크로드 분리
다중 계정 전략을 통해 환경(예: 프로덕션, 개발 및 테스트)과 워크로드 간에 일반적인 가드레일 및 격리를 설정합니다. 계정 수준의 분리는 보안, 청구 및 액세스에 대한 강력한 격리 경계를 제공하므로 강력하게 권장됩니다.
**원하는 성과:** 클라우드 운영, 관련 없는 워크로드 및 환경을 별도의 계정으로 격리하여 클라우드 인프라 전반의 보안을 강화하는 계정 구조.
**일반적인 안티 패턴**:
+ 데이터 민감도 수준이 서로 다른 관련 없는 여러 워크로드를 동일한 계정에 배치합니다.
+ 잘못 정의된 조직 단위(OU) 구조입니다.
**이 모범 사례 확립의 이점:**
+ 워크로드가 의도치 않게 액세스되는 경우 영향 범위가 감소합니다.
+ AWS 서비스, 리소스 및 리전에 대한 액세스 권한의 중앙 거버넌스.
+ 보안 서비스의 정책 및 중앙 집중식 관리를 통해 클라우드 인프라의 보안을 유지 관리합니다.
+ 자동화된 계정 생성 및 유지 관리 프로세스.
+ 규정 준수 및 규제 요구 사항에 대한 인프라의 중앙 집중식 감사.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
AWS 계정은 서로 다른 민감도 수준에서 작동하는 워크로드 또는 리소스 간에 보안 격리 경계를 제공합니다. AWS는 다중 계정 전략을 통해 대규모로 클라우드 워크로드를 관리할 수 있는 도구를 제공하여 이 격리 경계를 활용할 수 있습니다. AWS에 대한 다중 계정 전략의 개념, 패턴 및 구현에 대한 지침은[Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)를 참조하세요.
중앙 관리 하에 여러 AWS 계정이 있는 경우 조직 단위(OU) 계층으로 정의된 계층 구조로 계정을 구성해야 합니다. 그런 다음 보안 제어를 구성하고 OU 및 구성원 계정에 적용하여 조직의 구성원 계정에 일관된 예방적인 제어를 설정할 수 있습니다. 보안 제어는 상속되므로 OU 계층 구조의 하위 수준에 있는 구성원 계정이 사용 가능한 권한을 필터링할 수 있습니다. 우수한 설계는 이 상속을 활용하여 각 구성원 계정에 대해 원하는 보안 제어를 달성하는 데 필요한 보안 정책의 수와 복잡성을 줄입니다.
[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 및 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)는 AWS 환경에서 이 다중 계정 구조를 구현하고 관리하는 데 사용할 수 있는 두 가지 서비스입니다. AWS Organizations를 사용하면 하나 이상의 OU 계층으로 정의된 계층 구조로 계정을 구성할 수 있습니다. 각 OU에는 여러 구성원 계정이 포함되어 있습니다. [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCP)을 사용하면 조직 관리자가 구성원 계정에 대한 세분화된 예방 제어를 설정할 수 있으며, [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)를 사용하면 구성원 계정에 대한 사전 예방 및 탐지 제어를 설정할 수 있습니다. 많은 AWS 서비스가 [AWS Organizations와 통합](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)되어 위임된 관리 제어를 제공하고 조직의 모든 구성원 계정 전체의 서비스별 작업을 수행합니다.
AWS Organizations 위에 계층화된 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)에서는 [랜딩 존](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)이 있는 다중 계정 AWS 환경에 대한 원클릭 모범 사례 설정을 제공합니다. 랜딩 존은 Control Tower가 구축한 다중 계정 환경의 진입점입니다. Control Tower는 AWS Organizations에 비해 몇 가지 [이점](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/)을 제공합니다. 개선된 계정 거버넌스를 제공하는 세 가지 이점은 다음과 같습니다.
+ 조직에 참여하도록 승인된 계정에 자동으로 적용되는 통합 필수 보안 제어.
+ 주어진 OU 세트에 대해 활성화 또는 비활성화할 수 있는 선택적 제어.
+ [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html)는 조직 내에서 미리 승인된 기준과 구성 옵션을 포함하는 계정의 자동화된 배포를 제공합니다.
**구현 단계**
1. **조직 단위 구조 설계:** 적절하게 설계된 조직 단위 구조는 서비스 제어 정책 및 기타 보안 제어를 생성하고 유지 관리하는 데 필요한 관리 부담을 줄여줍니다. 조직 단위 구조는 [비즈니스 요구 사항, 데이터 민감도 및 워크로드 구조에 맞춰 조정](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)해야 합니다.
1. **다중 계정 환경을 위한 랜딩 존 생성:** 랜딩 존은 조직이 워크로드를 신속하게 개발, 실행 및 배포할 수 있는 일관된 보안 및 인프라 기반을 제공합니다. [맞춤형으로 구축된 랜딩 존 또는 AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html)를 사용하여 환경을 오케스트레이션할 수 있습니다.
1. **가드레일 설정:** 랜딩 존을 통해 환경에 일관된 보안 가드레일을 구현합니다. AWS Control Tower[https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html)는 배포할 수 있는 [필수](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html) 및 선택적 제어 목록을 제공합니다. 필수 제어는 Control Tower를 구현할 때 자동으로 배포됩니다. 적극 권장되는 선택적 제어 목록을 검토하고 요구 사항에 적합한 제어를 구현합니다.
1. **새로 추가된 리전에 대한 액세스 권한 제한:** 새 AWS 리전의 경우 사용자 및 역할과 같은 IAM 리소스는 사용자가 지정하는 리전으로만 전파됩니다. 이 작업은 [Control Tower를 사용할 때 콘솔](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html)을 통해 수행하거나 [AWS Organizations에서 IAM 권한 정책](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/)을 조정하여 수행할 수 있습니다.
1. **AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) 고려**: StackSets를 사용하면 IAM 정책, 역할, 그룹을 포함한 리소스를 승인된 템플릿에서 다양한 AWS 계정 및 리전에 배포할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](sec_identities_identity_provider.md)
**관련 문서:**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 보안 감사 지침](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Use CloudFormation StackSets to provision resources across multiple AWS 계정 and regions](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/)
+ [Organizations FAQ](https://aws.amazon.com/organizations/faqs/)
+ [AWS Organizations 용어 및 개념](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
+ [Best Practices for Service Control Policies in an AWS Organizations Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [AWS Account Management 참조 안내서](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html)
+ [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
**관련 비디오:**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Building and Governing Multiple Accounts using AWS Control Tower](https://www.youtube.com/watch?v=agpyuvRv5oo)
+ [Enable Control Tower for Existing Organizations](https://www.youtube.com/watch?v=CwRy0t8nfgM)
# SEC01-BP02 계정 루트 사용자 및 속성 보호
루트 사용자는 계정 내의 모든 리소스에 대한 전체 관리 액세스 권한이 있는 AWS 계정에서 가장 권한이 높은 사용자이며 경우에 따라 보안 정책의 제약을 받을 수 없습니다. 루트 사용자에 대한 프로그래밍 방식 액세스 권한을 비활성화하고, 루트 사용자에 대한 적절한 제어를 설정하며, 루트 사용자의 일상적인 사용을 방지하면 루트 자격 증명이 의도치 않게 노출되어 클라우드 환경이 손상될 위험을 줄일 수 있습니다.
**원하는 성과:** 루트 사용자를 보호하면 루트 사용자 자격 증명 남용으로 인해 우발적이거나 의도적인 손상이 발생할 가능성을 줄일 수 있습니다. 탐지 제어를 설정하면 루트 사용자를 사용하여 작업을 수행할 때 적절한 담당자에게 알릴 수도 있습니다.
**일반적인 안티 패턴:**
+ 루트 사용자 자격 증명이 필요한 몇 가지 작업 이외의 작업에 루트 사용자를 사용합니다.
+ 긴급 상황에서의 중요한 인프라, 프로세스 및 인력 기능을 확인하기 위한 비상 계획을 정기적으로 테스트하는 데 소홀합니다.
+ 일반적인 계정 로그인 흐름만 고려하고 대체 계정 복구 방법을 고려하거나 테스트하는 데 소홀합니다.
+ DNS, 이메일 서버 및 전화 공급자가 계정 복구 흐름에서 사용되므로 중요한 보안 경계의 일부로 처리하지 않습니다.
**이 모범 사례 확립의 이점:** 루트 사용자에 대한 액세스를 보호하면 계정의 작업이 제어되고 감사된다는 확신을 얻을 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
AWS는 계정을 보호하는 데 도움이 되는 다양한 도구를 제공합니다. 그러나 이러한 조치는 대부분 기본적으로 활성화되어 있지 않으므로 이를 구현하기 위해서는 직접적인 조치를 취해야 합니다. AWS 계정 보호를 위한 기본 단계로 다음 권장 사항을 고려해 보세요. 이러한 단계를 구현할 때 보안 제어를 지속적으로 평가하고 모니터링하는 프로세스를 구축하는 것이 중요합니다.
AWS 계정을 처음 생성할 때 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 자격 증명을 생성하는 것으로 시작합니다. 이 자격 증명을 AWS 계정 루트 사용자라고 합니다. 계정을 생성할 때 사용한 이메일 주소와 암호를 입력하여 루트 사용자로 로그인할 수 있습니다. AWS 루트 사용자에게 부여된 높은 액세스 권한으로 인해 [특별히 이를 필요](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)로 하는 작업을 수행하려면 AWS 루트 사용자의 사용을 제한해야 합니다. 루트 사용자 로그인 자격 증명은 철저하게 보호되어야 하며 AWS 계정 루트 사용자에 대해 항상 다중 인증(MFA)을 활성화해야 합니다.
사용자 이름, 암호 및 다중 인증(MFA) 디바이스를 사용하여 루트 사용자에 로그인하는 일반적인 인증 흐름 외에도 이메일 주소 및 계정과 연결된 전화번호에 대한 액세스 권한이 부여된 AWS 계정 루트 사용자에 로그인하는 계정 복구 흐름이 있습니다. 따라서 복구 이메일이 전송되는 루트 사용자 이메일 계정을 보호하는 것과 계정과 연결된 전화번호를 보호하는 것이 동일하게 중요합니다. 또한 루트 사용자와 연결된 이메일 주소가 동일한 AWS 계정의 이메일 서버 또는 도메인 이름 서비스(DNS) 리소스에서 호스팅되는 잠재적인 순환 종속성도 고려하세요.
AWS Organizations를 사용하는 경우 각각 루트 사용자가 있는 여러 AWS 계정이 있습니다. 하나의 계정이 관리 계정으로 지정되면 여러 계층의 구성원 계정을 관리 계정 아래 추가할 수 있습니다. 관리 계정의 루트 사용자 보호에 우선순위를 지정한 다음 구성원 계정 루트 사용자의 주소를 기재합니다. 관리 계정의 루트 사용자를 보호하기 위한 전략은 구성원 계정 루트 사용자와 다를 수 있으며, 구성원 계정 루트 사용자에게 예방 보안 제어를 적용할 수 있습니다.
**구현 단계**
루트 사용자에 대한 제어를 설정하려면 다음 구현 단계를 수행하는 것이 좋습니다. 해당하는 경우 권장 사항은 [CIS AWS Foundations benchmark version 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html)에서 교차 참조됩니다. 이러한 단계 외에도 AWS 계정 및 리소스 보호를 위해 [AWS 모범 사례 지침](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)을 참조하세요.
**예방 제어**
1. 계정의 정확한 [연락처 정보](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)를 설정합니다.
1. 이 정보는 분실한 암호 복구 흐름, 분실한 MFA 디바이스 계정 복구 흐름 및 팀과의 중요한 보안 관련 커뮤니케이션에 사용됩니다.
1. 회사 도메인에서 호스팅하는 이메일 주소(배포 목록 선호)를 루트 사용자의 이메일 주소로 사용합니다. 개인의 이메일 계정이 아닌 배포 목록을 사용하면 장기간에 걸쳐 루트 계정에 액세스할 수 있는 추가 중복성과 연속성이 제공됩니다.
1. 연락처 정보에 표시된 전화번호는 이 목적을 위한 보안 전용 전화여야 합니다. 전화번호를 표시하거나 다름 사람과 공유해서는 안 됩니다.
1. 루트 사용자의 액세스 키를 생성하지 않습니다. 액세스 키가 있으면 제거합니다(CIS 1.4).
1. 루트 사용자에 대한 장기 프로그래밍 방식 자격 증명(액세스 및 보안 암호 키)을 제거합니다.
1. 루트 사용자 액세스 키가 이미 있는 경우 해당 키를 사용하여 AWS Identity and Access Management(IAM) 역할에서 임시 액세스 키를 사용하도록 프로세스를 전환한 다음, [루트 사용자 액세스 키를 삭제](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key)해야 합니다.
1. 루트 사용자의 자격 증명을 저장해야 하는지 여부를 결정합니다.
1. AWS Organizations를 사용하여 새 구성원 계정을 생성하는 경우 새 구성원 계정에 대한 루트 사용자의 초기 암호가 사용자에게 노출되지 않는 임의의 값으로 설정됩니다. 필요한 경우 AWS 조직 관리 계정의 암호 재설정 흐름을 사용하여 [구성원 계정에 대한 액세스 권한을 얻는](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root) 것이 좋습니다.
1. 독립 실행형 AWS 계정 또는 관리 AWS 조직 계정의 경우 루트 사용자에 대한 자격 증명을 생성하고 안전하게 저장하는 것이 좋습니다. 루트 사용자에 대해 MFA를 사용합니다.
1. AWS 다중 계정 환경에서 구성원 계정 루트 사용자에 대한 예방 제어를 활성화합니다.
1. 구성원 계정의 경우 [루트 사용자에 대한 루트 액세스 키 생성 금지](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys) 예방 가드레일 사용을 고려하세요.
1. 구성원 계정의 경우 [루트 사용자로 작업 금지](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions) 예방 가드레일 사용을 고려하세요.
1. 루트 사용자에 대한 자격 증명이 필요한 경우:
1. 복잡한 암호를 사용합니다.
1. 루트 사용자, 특히 AWS Organizations 관리(지급인) 계정에 대해 다중 인증(MFA)을 활성화합니다(CIS 1.5).
1. 단일 사용 디바이스는 MFA 코드가 포함된 디바이스가 다른 용도로 재사용될 가능성을 줄일 수 있으므로 복원력 및 보안을 위해 하드웨어 MFA 디바이스를 고려합니다. 배터리로 구동되는 하드웨어 MFA 디바이스가 정기적으로 대체되는지 확인합니다. (CIS 1.6)
+ 루트 사용자용 MFA를 구성하려면 [가상 MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) 또는 [하드웨어 MFA 디바이스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root)를 생성하는 방법에 대한 지침을 따르세요.
1. 백업을 위해 여러 MFA 디바이스를 등록하는 것이 좋습니다. [계정당 최대 8개의 MFA 디바이스가 허용됩니다.](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/)
+ 루트 사용자에 대해 둘 이상의 MFA 디바이스를 등록하면 [MFA 디바이스가 손실된 경우 계정을 복구하는 흐름](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/)이 자동으로 비활성화됩니다.
1. 암호를 안전하게 저장하고, 암호를 전자적으로 저장하는 경우 순환 종속성을 고려합니다. 암호를 획득하는 데 동일한 AWS 계정에 대한 액세스 권한이 필요한 방식으로 암호를 저장하지 않습니다.
1. 선택 사항: 루트 사용자에 대한 주기적인 암호 교체 일정을 설정하는 것이 좋습니다.
+ 자격 증명 관리 모범 사례는 규정 및 정책 요구 사항에 따라 다릅니다. MFA로 보호되는 루트 사용자는 단일 인증 요소로 암호에 의존하지 않습니다.
+ 주기적으로 [루트 사용자 암호를 변경](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_change-root.html)하면 의도치 않게 노출된 암호가 남용될 위험이 줄어듭니다.
**탐지 제어**
+ 루트 자격 증명의 사용을 감지하는 경보를 생성합니다(CIS 1.7). [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)에서는 [RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) 조사 결과를 통해 루트 사용자 API 자격 증명 사용을 모니터링하고 알림을 제공할 수 있습니다.
+ [AWS Config를 위한 AWS Well-Architected Security Pillar 적합성 팩](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html)에 포함된 탐지 제어를 평가 및 구현합니다. 또는 AWS Control Tower를 사용하는 경우 Control Tower 내에서 사용 가능한 [제어 기능이 강력히 권장](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html)됩니다.
**운영 지침**
+ 조직에서 루트 사용자 자격 증명에 대한 액세스 권한을 갖는 담당자를 결정합니다.
+ 루트 사용자 액세스 권한을 획득하는 데 필요한 모든 자격 증명 및 MFA에 대한 액세스 권한을 한 명의 개인이 갖지 않도록 2인 규칙을 사용합니다.
+ 한 명의 개인이 아닌 조직에서 계정과 연결된 전화번호 및 이메일 별칭(암호 재설정 및 MFA 재설정 흐름에 사용됨)에 대한 제어 권한을 유지 관리하는지 확인합니다.
+ 루트 사용자는 예외적으로만 사용합니다(CIS 1.7).
+ AWS 루트 사용자는 관리 작업이라 하더라도 일상 작업에는 사용하면 안 됩니다. [루트 사용자가 필요한 AWS 작업](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)을 수행하려면 루트 사용자로만 로그인합니다. 다른 모든 작업은 적절한 역할이 있는 다른 사용자가 수행해야 합니다.
+ 루트 사용자 자격 증명을 사용해야 하는 긴급 상황이 발생하기 전에 절차를 테스트할 수 있도록 루트 사용자에 대한 액세스 권한이 작동하는지 주기적으로 확인합니다.
+ 계정과 연결된 이메일 주소와 [대체 연락처](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)에 나열된 이메일 주소가 작동하는지 주기적으로 확인합니다. abuse@amazon.com에서 수신된 보안 알림이 있는지 이러한 이메일 받은 편지함을 모니터링합니다. 또한 계정과 연결된 모든 전화번호가 작동하는지 확인합니다.
+ 루트 계정 남용에 대응하기 위한 인시던트 대응 절차를 준비합니다. AWS 계정에서 인시던트 대응 전략 구축에 대한 자세한 내용은 [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) 및 [보안 원칙 백서의 인시던트 대응 섹션](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)에 나온 모범 사례를 참조하세요.
## 리소스
**관련 모범 사례:**
+ [SEC01-BP01 계정을 사용하여 워크로드 분리](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 강력한 로그인 메커니즘 사용](sec_identities_enforce_mechanisms.md)
+ [SEC03-BP02 최소 권한 액세스 부여](sec_permissions_least_privileges.md)
+ [SEC03-BP03 긴급 액세스 프로세스 설정](sec_permissions_emergency_process.md)
+ [SEC10-BP05 액세스 권한 사전 프로비저닝](sec_incident_response_pre_provision_access.md)
**관련 문서:**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 보안 감사 지침](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Amazon GuardDuty – root credential usage alert](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage)
+ [Step-by-step guidance on monitoring for root credential use through CloudTrail](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-20)
+ [에서 사용하도록 승인된 MFA 토큰AWS](https://aws.amazon.com/iam/features/mfa/)
+ AWS에서 [break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) 구현
+ [Top 10 security items to improve in your AWS 계정](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/)
+ [에서 승인되지 않은 활동이 감지되면 어떻게 해야 하나요?AWS 계정](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/)
**관련 비디오:**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Limiting use of AWS root credentials](https://youtu.be/SMjvtxXOXdU?t=979) from AWS re:inforce 2022 – Security best practices with AWS IAM