# 보안 기초
보안 원칙은 보안 태세를 개선할 수 있는 방식으로 클라우드 기술을 활용하여 데이터, 시스템 및 자산을 보호하는 방법을 설명합니다. 이 백서에서는 AWS에서 보안 워크로드를 설계하기 위한 심층 모범 사례 지침을 제공합니다.
## 설계 원칙
클라우드에는 워크로드 보안을 강화할 수 있는 여러 가지 원칙이 존재합니다.
+ **강력한 자격 증명 기반 구현:** 최소 권한 원칙을 구현하고 AWS 리소스와의 각 상호 작용에 대한 적절한 권한을 부여하여 업무를 분리합니다. 자격 증명 관리를 중앙 집중화하고 장기적인 정적 자격 증명에 대한 의존도를 해소하는 것을 목표로 합니다.
+ **추적 기능 유지 관리:** 실시간으로 환경에 대한 작업 및 변경 사항을 모니터링하고 알림을 전송하며 감사합니다. 로그 및 지표 수집을 시스템과 통합하여 자동으로 조사하고 조치를 취합니다.
+ **모든 계층에 보안 적용:** 여러 보안 제어와 함께 심층 방어 접근 방식을 적용합니다. 모든 계층(예: 네트워크 엣지, VPC, 로드 밸런싱, 모든 인스턴스 및 컴퓨팅 서비스, 운영 체제, 애플리케이션, 코드)에 적용됩니다.
+ **보안 모범 사례의 자동 적용:** 자동화된 소프트웨어 기반의 보안 메커니즘은 안전한 규모 조정 능력을 빠르고 비용 효율적으로 향상시킵니다. 버전 제어가 가능한 템플릿에서 코드로 정의되고 관리되는 제어 기능의 구현을 비롯한 보안 아키텍처를 생성합니다.
+ **전송 중 데이터 및 보관 중인 데이터 보호:** 데이터를 민감도 수준에 따라 분류하고 적절한 경우 암호화, 토큰화 및 액세스 제어와 같은 메커니즘을 사용합니다.
+ **사람들이 데이터에 쉽게 접근할 수 없도록 유지:** 데이터에 대한 직접 액세스 또는 수동 처리의 필요성을 줄이거나 없애기 위한 메커니즘 및 도구를 사용합니다. 이를 통해 민감한 데이터를 처리할 때 잘못된 취급이나 수정 및 수작업으로 인한 오류의 위험을 줄일 수 있습니다.
+ **보안 이벤트에 대비:** 조직의 요구 사항에 부합하는 인시던트 관리 및 조사 정책과 프로세스를 통해 사고에 대비합니다. 인시던트 대응 시뮬레이션을 실행하고 자동화된 도구를 사용하여 감지, 조사 및 복구 속도를 높입니다.
## 정의
클라우드의 보안은 다음의 7가지 영역으로 구성됩니다.
+ [보안 기초](#security)
+ [자격 증명 및 액세스 관리](identity-and-access-management.md)
+ [탐지](detection.md)
+ [인프라 보호](infrastructure-protection.md)
+ [데이터 보호](data-protection.md)
+ [인시던트 대응](incident-response.md)
+ [애플리케이션 보안](application-security.md)
# 공동 책임
보안과 규정 준수는 AWS와 고객의 공동 책임입니다. 이 공동 모델은 고객의 운영 부담을 더는 데 도움이 될 수 있습니다. 호스트 운영 체제 및 가상화 계층부터 서비스 운영 시설의 물리적 보안에 이르는 구성 요소를 AWS에서 운영, 관리 및 제어하기 때문입니다. 고객의 책임 및 관리 범위에는 AWS가 제공하는 보안 그룹 방화벽의 구성과 게스트 운영 체제(업데이트 및 보안 패치 포함) 및 기타 관련 애플리케이션 소프트웨어가 포함됩니다. 사용하는 서비스, 서비스를 IT 환경에 통합하는 과정 및 준거법과 규제에 따라 책임 범위가 다르기 때문에 고객은 선택하고자 하는 서비스에 대해 신중해야 합니다. 또한 이러한 공동 책임은 본질적으로 유연성을 제공하며 배포를 허용하는 제어 권한을 고객에게 부여합니다. 다음 차트에서 볼 수 있듯이 이 책임의 차이를 일반적으로 클라우드 ‘자체’의 보안과 클라우드 ‘내부’의 보안이라고 합니다.
**AWS의 '클라우드 자체 보안' 책임** - AWS는 AWS 클라우드에서 제공되는 모든 서비스를 실행하는 인프라를 보호할 책임이 있습니다. 이 인프라는 AWS 클라우드 서비스를 실행하는 하드웨어, 소프트웨어, 네트워킹 및 시설로 구성됩니다.
**고객의 '클라우드 내부 보안' 책임** - 고객의 책임은 고객이 선택하는 AWS 클라우드 서비스에 따라 결정됩니다. 서비스에 따라 고객이 보안 책임의 일환으로서 수행해야 하는 구성 작업의 양이 달라집니다. 예를 들어, Amazon Elastic Compute Cloud(Amazon EC2)와 같은 서비스는 서비스형 인프라(IaaS)로 분류되므로 고객이 필수 보안 구성 및 관리 작업을 모두 수행해야 합니다. Amazon EC2 인스턴스를 배포하는 고객의 경우 게스트 운영 체제 관리(업데이트 및 보안 패치 포함), 고객이 인스턴스에 설치하는 모든 애플리케이션 소프트웨어 또는 유틸리티, 각 인스턴스에 AWS에서 제공하는 방화벽 구성(보안 그룹이라고 함)에 대한 책임이 있습니다. Amazon S3 및 Amazon DynamoDB와 같은 추상화된 서비스의 경우 AWS는 인프라 계층, 운영 체제, 플랫폼을 작동하고, 고객은 엔드포인트에 액세스하여 데이터를 저장 및 검색합니다. 고객은 데이터를 관리하고(암호화 옵션 포함), 자산을 분류하며, IAM 도구를 사용하여 적절한 권한을 적용할 책임이 있습니다.
![\[Shared responsibility model diagram showing customer and AWS security roles in cloud services.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/security-pillar/images/aws-shared-responsibility.png)
*그림 1: AWS 공동 책임 모델.*
이 고객/AWS 공동 책임 모델은 IT 제어로도 확대 적용됩니다. IT 환경을 운영하는 책임을 AWS와 고객이 공유하는 것과 마찬가지로, IT 제어의 관리, 운영, 확인 또한 공유됩니다. AWS는 이전에는 고객이 관리했던 AWS 환경에 배포된 물리적 인프라와 관련한 제어를 관리함으로써 운영 제어의 고객 부담을 완화하는 데 도움을 줄 수 있습니다. 고객마다 AWS에서 배포된 방법이 다르므로 고객은 특정 IT 제어 관리를 AWS로 전환하여 새로운 분산 제어 환경을 이용할 수 있습니다. 그런 다음 고객은 제공된 AWS 제어 및 규정 준수 설명서를 참조하여 필요한 제어 평가 및 검증 절차를 실시할 수 있습니다. 다음은 AWS, AWS 고객 또는 이 모두가 관리하는 제어의 예제입니다.
**상속된 제어** - 고객이 AWS로부터 완전히 상속하는 제어입니다.
+ 물리적 및 환경 제어
**공유 제어** - 별개의 컨텍스트 또는 관점에서 인프라 계층 및 고객 계층 모두에 적용되는 제어입니다. 공동 제어에서 AWS는 인프라에 대한 요구 사항을 제공하고 고객은 AWS 서비스 사용과 관련한 자체적인 제어 구현을 제공해야 합니다. 그러한 예는 다음과 같습니다.
+ 패치 관리 - AWS는 인프라 내의 패치 작업과 결함 수정에 대한 책임이 있지만, 고객은 게스트 운영 체제와 애플리케이션 패치 작업에 책임이 있습니다.
+ 구성 관리 - AWS는 자체 인프라 디바이스의 구성을 유지 관리하지만, 고객은 자체 게스트 운영 체제, 데이터베이스, 애플리케이션 구성에 책임이 있습니다.
+ 인식 및 교육 - AWS는 AWS 직원을 교육하며 고객은 자체 직원을 교육시켜야 합니다.
**고객별** - AWS 서비스 내에서 배포하는 애플리케이션에 따라 고객이 전적으로 책임을 져야 하는 제어입니다. 그러한 예는 다음과 같습니다.
+ 고객이 특정 보안 환경 내에서 데이터를 라우팅하거나 배치해야 하는 서비스 및 통신 보호 또는 영역 보안입니다.
# 거버넌스
전반적인 접근 방식의 일부로 보안 거버넌스를 포함하는 것은 위험 관리에 도움이 되는 정책과 제어 목표를 정의하여 비즈니스 목표 달성을 지원하기 위한 것입니다. 보안 제어 목표에 계층화된 접근 방식을 사용하여 위험을 관리합니다. 각 계층은 이전 계층을 기반으로 구현합니다. AWS 공동 책임 모델을 이해하는 것이 가장 기본적인 계층입니다. 이 모델을 이해하면 고객 측에서 어떤 부분에 책임이 있는지, AWS로부터 어떤 책임을 상속하는지 명확히 알 수 있습니다. 이때 [AWS 아티팩트](https://aws.amazon.com/artifact/)가 유용한 리소스입니다. 이를 사용하면 AWS의 보안 및 규정 준수 보고서에 온디맨드로 액세스하고 온라인 계약을 선택할 수 있습니다.
다음 계층에서 대부분의 제어 목표를 달성하세요. 플랫폼 전반의 기능이 이 계층에 있습니다. 예를 들어, 이 계층에는 AWS 계정 벤딩 프로세스, AWS IAM Identity Center과 같은 자격 증명 제공업체와의 통합, 일반적인 탐지 제어가 포함됩니다. 플랫폼 거버넌스 프로세스의 결과 중 일부도 이 계층에 있습니다. 새로운 AWS 서비스를 사용하고자 할 때 AWS Organizations 서비스에서 서비스 제어 정책(SCP)을 업데이트하여 서비스를 처음 사용할 때 적용할 가드레일을 제공할 수 있습니다. 다른 SCP를 사용하여 일반적인 보안 제어 목표(보안 불변수라고 함)를 구현할 수 있습니다. 보안 불변수는 여러 개의 계정, 조직 단위 또는 전체 AWS 조직에 적용하는 제어 목표 또는 구성입니다. 일반적으로 인프라가 실행되는 리전의 수를 제한하거나 탐지 제어 비활성화를 차단하는 것을 예로 들 수 있습니다. 이 중간 계층에는 구성 규칙 또는 파이프라인 검사 등 코드화된 정책도 포함됩니다.
상단 계층은 제품 팀이 제어 목표를 충족하는 영역입니다. 제품 팀이 제어하는 애플리케이션에서 구현이 수행되기 때문입니다. 애플리케이션에 입력 검증을 구현하거나 마이크로서비스 간에 자격 증명이 정확히 전달되도록 하는 것을 예로 들 수 있습니다. 제품 팀에서 구성을 담당하지만, 여전히 중간 계층으로부터 일부 기능을 상속할 수 있습니다.
제어를 어디에 구현하든 목표는 같습니다. 바로 위험을 관리하는 것입니다. 위험 관리 프레임워크의 범위는 특정 업계, 리전 또는 기술에 적용됩니다. 기본 목표는 발생 가능성과 결과에 따라 위험을 강조하는 것입니다. 이를 *내재된 위험*이라고 합니다. 그런 다음 발생 가능성, 결과 또는 둘 다를 축소하는 제어 목표를 정의할 수 있습니다. 그러고 나서 제어 조치가 마련된 상태에서 위험의 결과가 무엇일지 볼 수 있습니다. 이를 *잔존* 위험이라고 합니다. 제어 목표는 하나의 워크로드나 여러 개의 워크로드에 적용할 수 있습니다. 다음 다이어그램은 일반적인 위험 매트릭스를 보여줍니다. 발생 가능성은 이전 발생 빈도를 기반으로 하며 결과는 이벤트로 인한 재정, 평판, 시간 비용을 기반으로 합니다.
![\[Risk matrix showing likelihood vs. consequence, with risk levels from low to critical.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/security-pillar/images/risk-matrix.png)
*그림 2: 위험 수준 발생 가능성 매트릭스*
# 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
# 안전한 워크로드 운영
안전한 워크로드 운영에는 설계에서 구축, 실행, 지속적 개선까지 워크로드의 전체 수명 주기가 포함됩니다. 클라우드에서 안전하게 운영하는 역량을 향상하는 한 가지 방법은 거버넌스에 조직적 접근 방식을 취하는 것입니다. 거버넌스는 관여된 사람의 선의의 판단에 전적으로 의존하지 않고 일관되게 의사 결정을 이끄는 방식입니다. 거버넌스 모델과 프로세스는 ‘특정 워크로드에 대한 제어 목표가 충족되며 제어 목표가 해당 워크로드에 적합한지 어떻게 알 수 있는가?’라는 질문에 대답을 제시합니다. 의사 결정에 일관된 접근 방식을 적용하면 워크로드 배포의 속도가 빨라지고 조직 내 보안 역량의 기준을 높이는 데 도움이 됩니다.
워크로드를 안전하게 운영하려면 모든 보안 영역에 중요한 모범 사례를 적용해야 합니다. 운영 우수성에 대해 조직 및 워크로드 수준에서 정의한 요구 사항 및 프로세스를 모든 영역에 적용하세요. AWS, 업계 권장 사항 및 위협 인텔리전스를 최신 상태로 유지하면 위협 모델 및 제어 목표를 발전시키는 데 도움이 됩니다. 보안 프로세스, 테스트 및 검증을 자동화하면 보안 작업 규모를 조정하는 데 도움이 됩니다.
자동화를 통해 프로세스의 일관성과 반복 가능성을 확보할 수 있습니다. 사람은 많은 일에서 뛰어난 역량을 보입니다. 하지만 그러한 사람이라도 동일한 업무를 반복해서 수행할 때 전혀 실수를 하지 않으리라 보장할 수는 없습니다. 런북이 잘 작성되었더라도 사람들이 반복적인 작업을 일관적으로 수행하지 않을 것이라는 위험이 있습니다. 사람들의 책임이 서로 다르며 익숙하지 않은 알림에 대응해야 할 때는 그 위험이 특히 더 큽니다. 하지만 자동화는 매번 같은 방식으로 반응합니다. 애플리케이션을 배포하는 가장 좋은 방법은 자동화를 사용하는 것입니다. 배포를 실행하는 코드를 테스트한 후 배포를 수행하는 데 사용할 수 있습니다. 그러면 변경 프로세스에 대한 신뢰도가 높아지고 실패한 변경에 대한 위험이 낮아집니다.
구성이 제어 목표에 부합하는지 확인하기 위해 자동화와 배포된 애플리케이션을 비프로덕션 환경에서 먼저 테스트합니다. 그러면 자동화가 모든 단계를 올바르게 수행했는지 입증할 수 있습니다. 또한 개발 및 배포 주기의 초기에 피드백을 얻어 재작업을 줄일 수 있습니다. 배포 오류의 가능성을 줄이려면 사람이 아닌 코드를 사용하여 구성을 변경합니다. 애플리케이션을 다시 배포해야 한다면 자동화를 사용하는 경우 배포가 훨씬 쉽습니다. 추가 제어 목표를 정의할 때 모든 워크로드에 적용되도록 자동화에 쉽게 추가하면 됩니다.
개별 워크로드 담당자가 워크로드별 보안을 위해 노력하게 하는 대신 공동의 기능과 공유 구성 요소를 사용하여 시간을 절약하세요. 여러 팀이 사용할 수 있는 서비스의 예로는 AWS 계정 생성 프로세스, 인력을 위한 중앙 집중화된 자격 증명, 일반적인 로깅 구성, AMI 및 컨테이너 기반 이미지 생성이 있습니다. 이 접근 방식을 사용하면 빌더가 워크로드 주기 시간을 개선하고 일관적으로 보안 제어 목표를 달성하는 데 도움이 됩니다. 팀의 일관성이 높아지면 제어 목표를 검증하고 이해관계자에게 제어 태세와 위험 포지션을 더 효과적으로 보고할 수 있습니다.
**Topics**
+ [SEC01-BP03 제어 목표 파악 및 검증](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 보안 위협 및 권장 사항에 대한 최신 정보 파악](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 보안 관리 범위 축소](sec_securely_operate_reduce_management_scope.md)
+ [SEC01-BP06 표준 보안 제어의 배포 자동화](sec_securely_operate_automate_security_controls.md)
+ [SEC01-BP07 위협 모델을 사용하여 위협 식별 및 완화 조치의 우선순위 지정](sec_securely_operate_threat_model.md)
+ [SEC01-BP08 새로운 보안 서비스 및 기능을 정기적으로 평가 및 구현](sec_securely_operate_implement_services_features.md)
# SEC01-BP03 제어 목표 파악 및 검증
위협 모델에서 식별된 규정 준수 요구 사항 및 위험을 기준으로, 워크로드에 적용해야 하는 제어 목표와 제어 항목을 도출하고 검증합니다. 제어 목표 및 제어에 대한 지속적인 검증은 위험 완화의 효과를 측정하는 데 도움이 됩니다.
**원하는 성과:** 비즈니스의 보안 제어 목표가 잘 정의되고 규정 준수 요구 사항에 맞게 조정됩니다. 제어는 자동화와 정책을 통해 구현 및 시행되며 목표 달성의 효율성 측면이 지속적으로 평가됩니다. 특정 시점과 일정 기간의 효과 증명을 감사자에게 쉽게 보고할 수 있습니다.
**일반적인 안티 패턴:**
+ 비즈니스와 관련하여 확실한 보안에 대한 규제 요구 사항, 시장 기대치 및 업계 표준을 제대로 이해하고 있지 않습니다.
+ 사이버 보안 프레임워크와 제어 목표가 비즈니스 요구 사항에 맞지 않습니다.
+ 제어 구현이 측정 가능한 방식으로 제어 목표와 밀접하게 일치하지 않습니다.
+ 자동화를 통해 제어의 효과를 보고하지 않습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
보안 제어 목표의 기초를 형성할 수 있는 일반적인 사이버 보안 프레임워크가 많이 있습니다. 비즈니스에 대한 규제 요구 사항, 시장 기대치, 업계 표준을 고려하여 요구 사항을 가장 잘 지원하는 프레임워크를 결정하세요. 예를 들어, [AICPA SOC 2](https://aws.amazon.com/compliance/soc-faqs/), [HITRUST](https://aws.amazon.com/compliance/hitrust/), [PCI-DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO 27001](https://aws.amazon.com/compliance/iso-27001-faqs/), [NIST SP 800-53](https://aws.amazon.com/compliance/nist/)이 포함됩니다.
제어 목표를 파악한 경우, 사용하는 AWS 서비스가 해당 목표를 달성하는 데 어떤 도움이 되는지 이해해야 합니다. [AWS Artifact](https://aws.amazon.com/artifact/)를 사용하여 AWS에서 포괄하는 책임 범위를 설명하는 대상 프레임워크에 맞게 조정된 문서와 보고서 그리고 사용자 책임에 속하는 나머지 범위에 대한 지침을 찾아보세요. 다양한 프레임워크 제어 설명에 부합하는 추가적인 서비스별 지침은 [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)를 참조하세요.
목표 달성을 위한 제어를 정의할 때 예방적 제어를 바탕으로 실행을 체계화하고 감지 제어를 사용하여 완화를 자동화하세요. [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 사용하여 AWS Organizations에서 리소스 구성 및 작업이 규정을 준수하지 못하는 일이 없도록 방지할 수 있습니다. 규정 미준수 리소스를 모니터링하고 보고한 다음, 해당 동작이 확실해지면 규칙을 실행 모델로 전환하도록 [AWS Config](https://aws.amazon.com/config/)에서 규칙을 구현합니다. 사이버 보안 프레임워크에 맞게 미리 정의된 관리형 규칙 세트를 배포하려면 첫 번째 옵션으로 [AWS Security Hub CSPM 표준](https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html) 사용을 평가합니다. AWS Foundational Security Best Practices(FSBP) 표준과 CIS AWS Foundations Benchmark는 여러 표준 프레임워크에서 공유되는 많은 목표에 부합하는 제어 기능을 갖추고 있어 좋은 출발점이 될 수 있습니다. Security Hub CSPM에 기본적으로 원하는 제어 감지 기능이 없는 경우 [AWS Config 규정 준수 팩](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)을 사용하여 보완할 수 있습니다.
AWS 글로벌 보안 및 규정 준수 가속화(GSCA) 팀이 권장하는 [APN 파트너 번들](https://aws.amazon.com/partners/programs/gsca/bundles/)을 사용하여 보안 고문, 컨설팅 기관, 증거 수집 및 보고 시스템, 감사자 및 필요한 경우 기타 보완 서비스의 도움을 받을 수 있습니다.
### 구현 단계
1. 일반적인 사이버 보안 프레임워크를 평가하고 선택한 목표에 맞게 제어 목표를 조정합니다.
1. AWS Artifact를 사용하는 프레임워크에 대한 지침 및 책임 관련 문서를 얻습니다. 공동 책임 모델에서 AWS가 부담하는 규정 준수 부분과 사용자의 책임인 부분을 이해합니다.
1. SCP, 리소스 정책, 역할 신뢰 정책 및 기타 가드레일을 사용하여 리소스 구성 및 작업이 규정을 준수하지 못하는 일이 없도록 합니다.
1. 제어 목표에 맞는 Security Hub CSPM 표준 및 AWS Config 규정 준수 팩 배포를 평가합니다.
## 리소스
**관련 모범 사례:**
+ [SEC03-BP01 액세스 요구 사항 정의](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_define.html)
+ [SEC04-BP01 서비스 및 애플리케이션 로깅 구성](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_app_service_logging.html)
+ [SEC07-BP01 데이터 분류 체계 이해](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_identify_data.html)
+ [OPS01-BP03 거버넌스 요구 사항 평가](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_governance_reqs.html)
+ [OPS01-BP04 규정 준수 요구 사항 평가](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_compliance_reqs.html)
+ [PERF01-BP05 정책 및 참조 아키텍처 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_use_policies_and_reference_architectures.html)
+ [COST02-BP01 조직 요구 사항에 따라 정책 개발](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html)
**관련 문서:**
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**관련 도구:**
+ [AWS Artifact](https://aws.amazon.com/artifact/)
# SEC01-BP04 보안 위협 및 권장 사항에 대한 최신 정보 파악
업계 위협 인텔리전스 간행물과 업데이트를 위한 데이터 피드를 모니터링하여 최신 위협 및 방어 조치를 파악하세요. 최신 위협 데이터를 기반으로 자동 업데이트되는 관리형 서비스 제품을 평가합니다.
**원하는 성과:** 업계 간행물에 최신 위협 및 권장 사항이 업데이트되므로, 지속적으로 정보를 얻을 수 있습니다. 자동화를 사용하여 새로운 위협을 식별할 때 잠재적 취약성과 노출을 탐지합니다. 이러한 위협에 대해 완화 조치를 취합니다. 최신 위협 인텔리전스로 자동 업데이트되는 AWS 서비스를 채택합니다.
**일반적인 안티 패턴:**
+ 최신 위협 인텔리전스에 대한 정보를 지속적으로 파악할 수 있는 신뢰할 수 있고 반복 가능한 메커니즘이 없습니다.
+ 잠재적 취약성 및 노출에 대해 인적 검토가 필요한 기술 포트폴리오, 워크로드, 종속성에 대한 인벤토리를 수동으로 유지 관리합니다.
+ 워크로드 및 종속성을 알려진 위협 완화 기능을 제공하는 최신 지원 버전으로 업데이트할 수 있는 메커니즘이 없습니다.
**이 모범 사례 확립의 이점:** 위협 인텔리전스 소스를 사용하여 최신 상태를 유지하면 비즈니스에 영향을 미칠 수 있는 위협 환경의 중요한 변화를 놓칠 위험이 줄어듭니다. 워크로드에 잠재적인 취약성이나 노출이 존재하는 부분과 그 종속성을 스캔, 탐지 및 해결하기 위한 자동화 기능을 마련하면 수동 대안에 비해 위험을 빠르고 예측 가능하게 완화하는 데 도움이 될 수 있습니다. 이를 통해 취약성 완화와 관련된 시간과 비용을 제어할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
신뢰할 수 있는 위협 인텔리전스 발행물을 검토하여 위협 상황을 파악합니다. 알려진 적대적 전술, 기법 및 절차(TTP)에 대한 문서는 [MITRE ATT&CK](https://attack.mitre.org/) 기술 자료를 참조하세요. MITRE의 [Common Vulnerabilities and Exposures](https://cve.org/) 목록을 검토하여 사용 중인 제품의 알려진 취약성에 대한 최신 정보를 확인합니다. 널리 알려진 OWASP(Open Worldwide Application Security Project)의 인기 [OWASP Top 10](https://owasp.org/www-project-top-ten/) 프로젝트를 통해 웹 애플리케이션에 대한 중대한 위험을 이해합니다.
CVE용 AWS [보안 공지](https://aws.amazon.com/security/security-bulletins/)를 참조하여 AWS 보안 이벤트 및 권장되는 수정 단계에 대한 최신 정보를 확인합니다.
최신 상태를 유지하는 데 드는 전반적인 수고를 덜고 오버헤드를 줄이려면 시간이 지남에 따라 새로운 위협 인텔리전스를 자동으로 통합하는 AWS 서비스를 사용하는 것이 좋습니다. 예를 들어, [Amazon GuardDuty](https://aws.amazon.com/guardduty/)에서는 계정 내에서 비정상적인 동작과 위협 서명을 탐지하기 위한 업계 위협 인텔리전스를 최신 상태로 유지할 수 있습니다. [Amazon Inspector](https://aws.amazon.com/inspector/)에서는 연속 스캔 기능에 사용하는 CVE의 데이터베이스를 자동으로 최신 상태로 유지합니다. [AWS WAF](https://aws.amazon.com/waf/) 및 [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) 모두 새로운 위협이 발생하면 자동으로 업데이트되는 관리형 규칙 그룹을 제공합니다.
자동화된 플릿 관리 및 패치 적용의 경우 [Well-Architected 운영 우수성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)을 검토하세요.
## 구현 단계
+ 비즈니스 및 업계와 관련된 위협 인텔리전스 간행물의 최신 소식을 구독합니다. AWS 보안 공지를 구독합니다.
+ Amazon GuardDuty 및 Amazon Inspector와 같이 새로운 위협 인텔리전스를 자동으로 통합하는 서비스 채택을 고려해 보세요.
+ Well-Architected 운영 우수성 원칙의 모범 사례에 부합하는 플릿 관리 및 패치 적용 전략을 배포합니다.
## 리소스
**관련 모범 사례:**
+ [SEC01-BP07 위협 모델을 사용하여 위협 식별 및 완화 조치의 우선순위 지정](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_threat_model.html)
+ [OPS01-BP05 위협 환경 평가](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_eval_threat_landscape.html)
+ [OPS11-BP01 지속적인 개선을 위한 프로세스 마련](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_evolve_ops_process_cont_imp.html)
# SEC01-BP05 보안 관리 범위 축소
특정 제어 기능의 관리를 AWS(*관리형 서비스*)로 전환하는 AWS 서비스를 사용하여 보안 범위를 줄일 수 있는지를 결정합니다. 이러한 서비스는 인프라 프로비저닝, 소프트웨어 설정, 패치 적용, 백업과 같은 보안 유지 관리 작업을 줄이는 데 도움이 될 수 있습니다.
**원하는 성과:** 워크로드에 맞는 AWS 서비스를 선택할 때 보안 관리 범위를 고려합니다. 관리 오버헤드 및 유지 관리 작업에 드는 비용(총 소유 비용(TCO))은 다른 Well-Architected 고려 사항 외에도 선택한 서비스 비용을 기준으로 산정됩니다. AWS 제어 및 규정 준수 설명서를 제어 평가 및 검증 절차에 통합합니다.
**일반적인 안티 패턴:**
+ 선택한 서비스에 대한 공동 책임 모델을 완전히 이해하지 않고 워크로드를 배포합니다.
+ 상응하는 관리형 서비스를 평가하지 않고 가상 머신에서 데이터베이스 및 기타 기술을 호스팅합니다.
+ 관리형 서비스 옵션과 비교할 때 보안 관리 작업을 가상 머신의 호스팅 기술에 대한 총 소유 비용에 포함하지 않습니다.
**이 모범 사례 확립의 이점:** 관리형 서비스를 사용하면 운영 보안 제어를 관리하는 데 따르는 전반적인 부담을 낮추고 보안 위험과 총 소유 비용을 줄일 수 있습니다. 특정 보안 작업에 걸리는 시간을 비즈니스에 더 많은 가치를 제공하는 작업에 재투자할 수 있습니다. 또한, 관리형 서비스는 일부 제어 요구 사항을 AWS로 전환하여 규정 준수 요구 사항의 범위를 줄일 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
AWS 기반 워크로드의 구성 요소를 통합하는 방법에는 여러 가지가 있습니다. Amazon EC2 인스턴스에 기술을 설치하고 실행하려면 사용자가 전체 보안 책임의 가장 큰 부분을 맡아야 하는 경우가 많습니다. 특정 제어 기능을 운영하는 데 따르는 부담을 줄이려면 사용자가 지는 공동 책임 모델의 범위를 줄이는 AWS 관리형 서비스를 식별하고, 기존 아키텍처에서 이를 사용하는 방법을 이해해야 합니다. 예를 들어 데이터베이스 배포에 [Amazon Relational Database Service(RDS)](https://aws.amazon.com/rds/) 사용, 컨테이너 오케스트레이션에 [Amazon Elastic Kubernetes Service(Amazon EKS)](https://aws.amazon.com/eks/) 또는 [Amazon Elastic Container Service(Amazon ECS)](https://aws.amazon.com/ecs/) 사용 또는 [서버리스 옵션](https://aws.amazon.com/serverless/) 사용이 포함됩니다. 새 애플리케이션을 구축할 때는 보안 제어를 구현하고 관리하는 데 필요한 시간과 비용을 줄이는 데 어떤 서비스가 도움이 될 수 있는지 생각해 보세요.
규정 준수 요구 사항도 서비스를 선택할 때 고려할 요인이 될 수 있습니다. 관리형 서비스는 일부 요구 사항의 규정 준수를 AWS로 전환할 수 있습니다. 운영 및 관리하는 서비스의 양상을 감사하고 관련 AWS 감사 보고서의 제어 설명을 수락하는 데 있어 규정 준수 팀이 어느 정도 편안함을 느끼는지 규정 준수 팀과 논의하세요. [AWS Artifact](https://aws.amazon.com/artifact/)에서 발견된 감사 아티팩트를 감사 기관이나 규제 기관에 AWS 보안 통제의 증거로 제공할 수 있습니다. 또한 일부 AWS 감사 아티팩트에서 제공하는 책임 지침을 [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)와 함께 사용하여 아키텍처를 설계할 수 있습니다. 이 지침은 시스템의 특정 사용 사례를 지원하기 위해 적용해야 하는 추가 보안 제어를 결정하는 데 도움이 됩니다.
관리형 서비스를 사용할 경우 리소스를 최신 버전으로 업데이트하는 프로세스를 숙지해야 합니다(예: Amazon RDS에서 관리하는 데이터베이스 버전 또는 AWS Lambda 함수의 프로그래밍 언어 런타임 업데이트). 관리형 서비스가 이 작업을 대신 수행할 수도 있지만, 업데이트 시기를 구성하고 운영에 미치는 영향을 이해하는 것은 사용자의 책임입니다. [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/)와 같은 도구를 사용하면 환경 전체에서 이러한 업데이트를 추적하고 관리할 수 있습니다.
### 구현 단계
1. 관리형 서비스로 대체할 수 있는 워크로드 구성 요소를 평가하세요.
1. 워크로드를 AWS로 마이그레이션하는 경우 워크로드를 리호스팅, 리팩터링, 리플랫포밍, 재구축 또는 교체해야 하는지 평가할 때 관리에 드는 시간 및 비용 절감과 위험 감소를 고려해야 합니다. 때로는 마이그레이션을 시작할 때 추가적으로 투자하여 장기적으로 상당한 비용을 절감할 수 있습니다.
1. 자체 기술 배포를 설치하고 관리하는 대신 관리형 서비스(예: Amazon RDS)를 구현하는 것을 고려해 보세요.
1. AWS Artifact의 책임 지침을 참조하여 워크로드에 적용해야 하는 보안 제어를 결정하세요.
1. 사용 중인 리소스의 인벤토리를 유지하고 최신 서비스와 접근 방식을 최신 상태로 유지하여 범위를 줄일 수 있는 새로운 기회를 찾아보세요.
## 리소스
**관련 모범 사례:**
+ [PERF02-BP01 워크로드에 가장 적합한 컴퓨팅 옵션 선택](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_compute_hardware_select_best_compute_options.html)
+ [PERF03-BP01 데이터 액세스 및 스토리지 요구 사항을 가장 잘 지원하는 목적별 데이터 스토어 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_data_use_purpose_built_data_store.html)
+ [SUS05-BP03 관리형 서비스 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_hardware_a4.html)
**관련 문서:**
+ [Planned lifecycle events for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)
**관련 도구:**
+ [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Artifact](https://aws.amazon.com/artifact/)
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**관련 비디오:**
+ [How do I migrate to an Amazon RDS or Aurora MySQL DB instance using AWS DMS?](https://www.youtube.com/watch?v=vqgSdD5vkS0)
+ [AWS re:Invent 2023 - Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
# SEC01-BP06 표준 보안 제어의 배포 자동화
AWS 환경 전반에서 표준인 보안 제어 기능을 개발하고 배포할 때 최신 DevOps 사례를 적용하세요. 코드형 인프라(IaC) 템플릿을 사용하여 표준 보안 제어 및 구성을 정의하고, 버전 제어 시스템에서 변경 사항을 캡처하고, CI/CD 파이프라인의 일부로 변경 사항을 테스트하며, AWS 환경에 변경 사항을 자동으로 배포할 수 있습니다.
**원하는 성과:** IaC 템플릿이 표준화된 보안 제어를 캡처하고 이를 버전 제어 시스템에 적용합니다. CI/CD 파이프라인은 변경 사항을 탐지하고 AWS 환경 테스트 및 배포를 자동화하는 곳에 마련되어 있습니다. 배포를 진행하기 전에 템플릿의 구성 오류를 탐지하고 알림을 보내기 위한 가드레일이 있습니다. 워크로드는 표준 제어 기능이 적용되는 환경에 배포됩니다. 팀은 셀프 서비스 메커니즘을 통해 승인된 서비스 구성을 배포할 수 있습니다. 제어 구성, 스크립트 및 관련 데이터를 위한 안전한 백업 및 복구 전략이 마련되어 있습니다.
**일반적인 안티 패턴:**
+ 웹 콘솔 또는 명령줄 인터페이스를 통해 표준 보안 제어 기능을 수동으로 변경합니다.
+ 개별 워크로드 팀에 의존하여 중앙 팀이 정의한 제어 기능을 수동으로 구현합니다.
+ 워크로드 팀의 요청에 따라 중앙 보안 팀에 의존하여 워크로드 수준 제어 기능을 배포합니다.
+ 동일한 개인 또는 팀이 적절히 업무를 분담하거나 점검하며 균형을 맞추지 않고 보안 제어 자동화 스크립트를 개발, 테스트 및 배포할 수 있습니다.
**이 모범 사례 확립의 이점:** 템플릿을 사용하여 표준 보안 제어를 정의하면 버전 제어 시스템을 통해 시간 경과에 따른 변경 사항을 추적하고 비교할 수 있습니다. 자동화를 사용하여 변경 사항을 테스트하고 배포하면 표준화와 예측 가능성을 높여 배포가 성공할 확률이 커지고 수동 반복 작업을 줄일 수 있습니다. 워크로드 팀이 승인된 서비스 및 구성을 배포할 수 있는 셀프 서비스 메커니즘을 제공하면 구성 오류 및 오용의 위험을 줄일 수 있습니다. 또한, 개발 프로세스 초기에 제어 기능을 통합하는 데도 도움이 됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
[SEC01-BP01 계정을 사용하여 워크로드 분리](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html)에서 설명한 사례에 따라 AWS Organizations를 사용하여 관리하는 여러 환경에 여러 AWS 계정이 필요합니다. 이러한 각 환경과 워크로드에는 별도의 보안 제어가 필요할 수 있지만, 조직 전체에서 일부 보안 제어를 표준화할 수 있습니다. 예로는 중앙 집중식 ID 제공업체 통합, 네트워크 및 방화벽 정의, 로그 저장 및 분석을 위한 표준 위치 구성 등이 있습니다. *코드형 인프라*(IaC)를 사용하여 인프라 프로비저닝에 동일하게 엄격한 애플리케이션 코드 개발을 적용할 수 있는 것과 마찬가지로, IaC를 통해 표준 보안 제어를 정의하고 배포할 수도 있습니다.
가능하면 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)과 같은 선언적인 방법으로 보안 제어를 정의하고 소스 제어 시스템에 저장합니다. DevOps 관행을 바탕으로 보다 예측 가능한 릴리스를 위해 제어 기능을 자동으로 배포하고, [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)와 같은 도구를 사용하여 자동화된 테스트를 수행하며, 배포된 제어 기능과 원하는 구성 간의 차이를 탐지합니다. [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) 등 서비스를 사용하여 CI/CD 파이프라인을 구성할 수 있습니다. [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)의 지침 참조하여 다른 배포 파이프라인과 분리된 자체 계정에서 이러한 서비스를 구성하세요.
템플릿을 정의하여 AWS 계정, 서비스 및 구성을 정의하고 배포하는 것을 표준화할 수도 있습니다. 이 기술을 사용하면 중앙 보안 팀에서 정의를 관리하고 셀프 서비스 접근 방식을 통해 워크로드 팀에 제공할 수 있습니다. 이를 달성하는 한 가지 방법은 워크로드 팀이 자체 파이프라인 배포에 통합 가능한 *제품*으로 템플릿을 게시할 수 있는 [Service Catalog](https://aws.amazon.com/servicecatalog/)를 사용하는 것입니다. [AWS Control Tower](https://aws.amazon.com/controltower/)를 사용하는 경우 일부 템플릿과 제어 기능을 시작점으로 삼을 수 있습니다. 또한 Control Tower는 [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/af-customization-page.html) 기능을 제공하여 워크로드 팀이 정의한 표준을 통해 새로운 AWS 계정 계정을 만들 수 있도록 합니다. 이 기능을 사용하면 중앙 팀에 종속되지 않고 워크로드 팀에서 필요하다고 판단한 경우 새 계정을 승인하고 생성할 수 있습니다. 이러한 계정은 제공하는 기능, 처리 중인 데이터의 민감도 또는 동작과 같은 이유에 따라 다양한 워크로드 구성 요소를 분리하는 데 필요할 수 있습니다.
## 구현 단계
1. 버전 관리 시스템에서 템플릿을 저장하고 유지 관리하는 방법을 결정합니다.
1. CI/CD 파이프라인을 생성하여 템플릿을 테스트하고 배포합니다. 잘못된 구성이 있는지 점검하고 템플릿이 기업 표준을 준수하는지 확인하는 테스트를 정의합니다.
1. 워크로드 팀이 요구 사항에 따라 AWS 계정을 배포하고 서비스할 수 있도록 표준화된 템플릿 카탈로그를 구축합니다.
1. 제어 구성, 스크립트 및 관련 데이터에 대한 안전한 백업 및 복구 전략을 구현합니다.
## 리소스
**관련 모범 사례:**
+ [OPS05-BP01 버전 관리 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_version_control.html)
+ [OPS05-BP04 구축 및 배포 관리 시스템 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_build_mgmt_sys.html)
+ [REL08-BP05 자동화를 통한 변경 사항 배포](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_automated_changemgmt.html)
+ [SUS06-BP01 지속 가능성 개선을 신속하게 도입할 수 있는 방법 채택](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_dev_a2.html)
**관련 문서:**
+ [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)
**관련 예제:**
+ [Automate account creation, and resource provisioning using Service Catalog, AWS Organizations, and AWS Lambda](https://aws.amazon.com/blogs/mt/automate-account-creation-and-resource-provisioning-using-aws-service-catalog-aws-organizations-and-aws-lambda/)
+ [Strengthen the DevOps pipeline and protect data with AWS Secrets Manager, AWS KMS, and AWS Certificate Manager](https://aws.amazon.com/blogs/security/strengthen-the-devops-pipeline-and-protect-data-with-aws-secrets-manager-aws-kms-and-aws-certificate-manager/)
**관련 도구:**
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [Landing Zone Accelerator on AWS](https://github.com/awslabs/landing-zone-accelerator-on-aws)
# SEC01-BP07 위협 모델을 사용하여 위협 식별 및 완화 조치의 우선순위 지정
위협 모델링을 수행하여 워크로드에 대한 잠재적 위협 및 관련 완화 조치의 최신 등록을 식별하고 유지 관리합니다. 보안 위협 우선순위를 지정하고 보안 제어 완화 조치를 조정하여 방지, 감지 및 대응합니다. 워크로드와 진화하는 보안 환경에 맞춰 이를 보완하고 유지 관리합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
**위협 모델링이란 무엇인가요?**
"위협 모델링은 가치 있는 것을 보호한다는 맥락에서 위협과 완화 조치를 식별, 전달 및 이해하기 위해 작동합니다." – [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
**위협 모델을 사용해야 하는 이유는 무엇인가요?**
시스템은 복잡하고 시간이 지남에 따라 점점 더 복잡해지고 기능이 향상되어 더 많은 비즈니스 가치를 제공하고 고객 만족도와 참여도를 향상시킵니다. 즉, IT 설계를 결정할 때는 계속해서 증가하는 사용 사례를 고려해야 합니다. 이러한 복잡성과 사용 사례 순열의 수는 일반적으로 위협을 찾고 완화하는 데 구조화되지 않은 접근 방식을 비효율적으로 만듭니다. 대신 시스템에 대한 잠재적인 위협을 열거할 뿐만 아니라 조직의 제한된 리소스가 시스템의 전체 보안 태세를 개선하는 데 최대한 영향을 미칠 수 있도록 완화 조치를 고안하고 우선순위를 지정하는 체계적인 접근 방식이 필요합니다.
위협 모델링은 수명 주기 후반에 비해 상대적으로 완화 조치 관련 비용과 노력이 적게 필요한 설계 프로세스 초기에 문제를 찾아 해결하는 것을 목표로 이러한 체계적인 접근 방식을 제공하도록 설계되었습니다. 이 접근 방식은 [*시프트-레프트* 보안](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview)이라는 업계 원칙과 일치합니다. 궁극적으로 위협 모델링은 조직의 위험 관리 프로세스와 통합되며 위협 기반 접근 방식을 사용하여 구현할 제어에 대한 결정을 내리는 데 도움이 됩니다.
**위협 모델링은 언제 수행해야 하나요?**
워크로드의 수명 주기에서 가능한 한 빠르게 위협 모델링을 시작합니다. 그러면 식별한 위협에 대해 유연성을 높일 수 있습니다. 소프트웨어 버그와 마찬가지로 위협을 조기에 식별할수록 위협을 해결하는 것이 더 비용 효율적입니다. 위협 모델은 최신 상태를 유지해야 하는 문서로 워크로드가 변경됨에 따라 계속 진화해야 합니다. 주요 변경 사항이 있거나 위협 환경이 변경되거나 새로운 기능 또는 서비스를 채택하는 경우를 포함하여 시간이 지남에 따라 위협 모델을 보완합니다.
### 구현 단계
**위협 모델링을 어떻게 수행할 수 있나요?**
위협 모델링을 수행하는 방법에는 여러 가지가 있습니다. 프로그래밍 언어와 마찬가지로 각각 장단점이 있으므로 자신에게 가장 적합한 방법을 선택해야 합니다. 한 가지 접근 방식은 [Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame)으로 시작하는 것입니다. 여기에서는 위협 모델링 실습에 대한 구조를 제공하기 위해 개방형 질문을 제시합니다.
1. **어떤 작업을 하고 있나요?**
이 질문의 목적은 구축 중인 시스템과 보안과 관련된 해당 시스템에 대한 세부 정보를 이해하고 동의하는 데 도움을 주기 위한 것입니다. 모델이나 다이어그램을 생성하는 것은 가령 [데이터 흐름 다이어그램](https://en.wikipedia.org/wiki/Data-flow_diagram)을 사용하여 구축 항목을 시각화하는 데 도움이 되므로 이 질문에 답하는 가장 일반적인 방법입니다. 시스템에 대한 권한 수임과 중요한 세부 정보를 작성하는 것도 범위를 정의하는 데 도움이 됩니다. 이를 통해 위협 모델에 기여하는 모든 담당자가 동일한 작업에 집중하고 범위 이외의 주제(시스템의 오래된 버전 포함)로 벗어나 시간을 허비하는 것을 방지할 수 있습니다. 예를 들어 웹 애플리케이션을 구축하는 경우, 사용자 설계를 통해 영향을 미칠 수 없기 때문에 브라우저 클라이언트에 대한 운영 체제의 신뢰할 수 있는 부팅 시퀀스에 대해 위협 모델링을 수행할 필요가 없습니다.
1. **잘못되면 어떻게 되나요?**
이 질문을 통해 시스템에 대한 위협을 식별합니다. 위협은 원치 않는 영향을 미치고 시스템의 보안에 영향을 미칠 수 있는 우발적이거나 의도적인 작업 또는 이벤트입니다. 무엇이 잘못될 수 있는지에 대한 명확한 이해 없이는 위협에 대해 대응할 수 있는 방법이 아무 것도 없습니다.
무엇이 잘못될 수 있는지에 대한 표준 목록은 없습니다. 이 목록을 작성하려면 팀 내 모든 개인과 위협 모델링 수행에 [관여하는 관련 대상자](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips) 간의 브레인스토밍과 협업이 필요합니다. [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security))와 같은 위협 식별 모델을 사용하여 브레인스토밍을 지원할 수 있습니다. 이 모델은 스푸핑, 변조, 거부, 정보 공개, 서비스 거부 및 권한 상승과 같이 평가할 다양한 범주를 제안합니다. 또한 [OWASP Top 10](https://owasp.org/www-project-top-ten/), [HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/), 조직의 자체 위협 카탈로그를 포함하여 아이디어를 얻을 수 있는 기존 목록과 연구를 검토하여 브레인스토밍을 지원할 수 있습니다.
1. **이에 대해 무엇을 할 수 있나요?**
이전 질문의 경우와 마찬가지로 가능한 모든 완화 조치에 대한 표준 목록은 없습니다. 이 단계에 대한 입력은 이전 단계에서 식별된 위협, 행위자 및 개선 영역입니다.
보안과 규정 준수는 [AWS와 고객의 공동 책임](https://aws.amazon.com/compliance/shared-responsibility-model/)입니다. '이에 대해 무엇을 할 수 있나요?'라고 질문할 때 '이에 대한 책임은 누구에게 있나요?'라고 질문하는 것임을 이해하는 것이 중요합니다. 사용자와 AWS 간의 책임 균형을 이해하면 위협 모델링 수행의 범위를 관리되는 완화 조치로 지정하는 데 도움이 됩니다. 이러한 완화 조치는 일반적으로 AWS 서비스 구성 옵션과 자체 시스템별 완화 조치의 조합으로 이루어집니다.
공동 책임에서 AWS가 맡은 부분의 경우 [AWS 서비스가 많은 규정 준수 프로그램의 범위에 속해 있다는 것](https://aws.amazon.com/compliance/services-in-scope/)을 알 수 있습니다. 이러한 프로그램을 통해 클라우드의 보안 및 규정 준수를 유지하기 위해 AWS에 마련된 강력한 제어 기능을 이해할 수 있습니다. AWS 고객은 [AWS Artifact](https://aws.amazon.com/artifact/)에서 이러한 프로그램의 감사 보고서를 다운로드할 수 있습니다.
사용 중인 AWS 서비스에 관계없이 항상 고객 책임의 요소가 있으며 이러한 책임에 맞는 완화 조치가 위협 모델에 포함되어야 합니다. AWS 서비스 자체에 대한 보안 제어 완화 조치를 위해 자격 증명 및 액세스 관리(인증 및 권한 부여), 데이터 보호(저장 데이터 및 전송 중 데이터), 인프라 보안, 로깅, 모니터링과 같은 도메인을 포함한 도메인 전반에서 보안 제어 구현을 고려해야 합니다. 각 AWS 서비스에 대한 설명서에는 완화 조치로 고려할 보안 제어에 대한 지침을 제공하는 [보안 전용 장](https://docs.aws.amazon.com/security/)이 있습니다. 작성 중인 코드와 해당 코드 종속성을 고려하고 이러한 위협을 해결하기 위해 마련할 수 있는 제어에 대해 생각하는 것이 중요합니다. 이러한 제어는 [입력 검증](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [세션 처리](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling) 및 [경계 처리](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)와 같은 기능에 해당될 수 있습니다. 대부분의 취약성은 사용자 지정 코드에서 발생하는 경우가 많으므로 이 영역에 집중하세요.
1. **잘 수행했나요?**
목표는 팀과 조직이 위협 모델의 품질과 시간이 지남에 따라 위협 모델링을 수행하는 속도를 모두 개선하는 것입니다. 이러한 개선은 연습, 학습, 지도, 검토의 조합에서 비롯됩니다. 더 자세히 알아보고 실습하려면 사용자와 팀이 [Threat modeling the right way for builders 교육 과정](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) 또는 [워크숍](https://catalog.workshops.aws/threatmodel/en-US)을 완료하는 것이 좋습니다. 또한 위협 모델링을 조직의 애플리케이션 개발 수명 주기에 통합하는 방법에 대한 지침은 AWS 보안 블로그에서 [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 게시물을 참조하세요.
**Threat Composer**
위협 모델링을 수행하는 데 도움과 안내를 받으려면 위협 모델링 시 가치 창출 시간을 단축하는 것을 목표로 하는 [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 도구를 사용하는 것이 좋습니다. 이 도구는 다음과 같은 작업을 수행하는 데 도움이 됩니다.
+ 자연스러운 비선형 워크플로우에서 작동하는 [위협 문법](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar)에 맞게 유용한 위협 설명을 작성합니다.
+ 사람이 읽을 수 있는 위협 모델을 생성합니다.
+ 기계가 읽을 수 있는 위협 모델을 생성하여 위협 모델을 코드로 취급할 수 있습니다.
+ Insights Dashboard를 사용하여 품질 및 커버리지 개선 영역을 빠르게 식별할 수 있도록 도와줍니다.
자세한 내용을 보려면 Threat Composer를 방문하여 시스템 정의 **Example Workspace**로 전환합니다.
## 리소스
**관련 모범 사례:**
+ [SEC01-BP03 제어 목표 파악 및 검증](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 보안 위협 및 권장 사항에 대한 최신 정보 파악](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 보안 관리 범위 축소](sec_securely_operate_reduce_management_scope.md)
+ [SEC01-BP08 새로운 보안 서비스 및 기능을 정기적으로 평가 및 구현](sec_securely_operate_implement_services_features.md)
**관련 문서:**
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (AWS Security Blog)
+ [ NIST: Guide to Data-Centric System Threat Modelling ](https://csrc.nist.gov/publications/detail/sp/800-154/draft)
**관련 비디오:**
+ [AWS Summit ANZ 2021 - How to approach threat modeling ](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery ](https://www.youtube.com/watch?v=DjNPihdWHeA)
**관련 교육:**
+ [ Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [ Threat modeling the right way for builders – AWS 워크숍 ](https://catalog.workshops.aws/threatmodel)
**관련 도구:**
+ [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer)
# SEC01-BP08 새로운 보안 서비스 및 기능을 정기적으로 평가 및 구현
워크로드의 보안 상태를 개선할 수 있는 AWS 및 AWS 파트너의 보안 서비스와 기능을 평가하고 구현합니다.
**원하는 성과:** AWS 및 AWS 파트너가 출시한 새로운 기능 및 서비스를 알려주는 표준 관행이 마련되어 있습니다. 이러한 최신 기능이 환경과 워크로드에 대한 현재 제어 설계와 새로운 제어 설계에 어떤 영향을 미치는지 평가합니다.
**일반적인 안티 패턴:**
+ AWS 블로그와 RSS 피드를 구독하여 관련 새 기능 및 서비스를 신속하게 알아보지 않습니다.
+ 2차 소스에서 제공하는 보안 서비스 및 기능에 대한 소식 및 업데이트를 적극 활용합니다.
+ 조직의 AWS 사용자에게 최신 업데이트에 대한 새로운 정보를 계속 파악하도록 권장하지 않습니다.
**이 모범 사례 확립의 이점:** 새로운 보안 서비스 및 기능을 잘 파악하면 클라우드 환경 및 워크로드의 제어 구현에 대해 정보에 입각한 결정을 내릴 수 있습니다. 이러한 소스는 진화하는 보안 환경과 새롭게 등장하는 위협으로부터 AWS 서비스를 보호하는 데 사용할 수 있는 방법에 대한 인식을 높이는 데 도움이 됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
AWS는 다음과 같은 여러 채널을 통해 고객에게 새로운 보안 서비스 및 기능을 안내합니다.
+ [AWS의 새로운 소식](https://aws.amazon.com/new)
+ [AWS 뉴스 블로그](https://aws.amazon.com/blogs/aws/)
+ [AWS 보안 블로그](https://aws.amazon.com/blogs/security/)
+ [AWS 보안 공지](https://aws.amazon.com/security/security-bulletins/)
+ [AWS 문서 개요](https://aws.amazon.com/documentation/)
Amazon Simple Notification Service(SNS)를 통해 [AWS 일간 기능 업데이트](https://aws.amazon.com/blogs/aws/subscribe-to-aws-daily-feature-updates-via-amazon-sns/) 주제를 구독하여 업데이트에 대한 포괄적인 일일 요약 정보를 확인할 수 있습니다. [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_sns.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-announcements.html)와 같은 일부 보안 서비스는 해당 서비스에 대한 새로운 표준, 조사 결과 및 기타 업데이트 관련 정보를 파악할 수 있도록 자체 SNS 주제를 제공합니다.
나아가 매년 전 세계에서 개최되는 [컨퍼런스, 이벤트, 웨비나](https://aws.amazon.com/events/)를 통해 새로운 서비스와 기능에 대해 자세히 발표하고 설명합니다. 특히 주목할 것은 연례 [AWS re:Inforce](https://reinforce.awsevents.com/) 보안 컨퍼런스와 보다 일반적인 [AWS re:Invent](https://reinvent.awsevents.com/) 컨퍼런스입니다. 앞서 언급한 AWS 뉴스 채널은 이러한 컨퍼런스에서 보안 및 기타 서비스에 대해 발표한 내용을 공유합니다. YouTube의 [AWS Events 채널](https://www.youtube.com/c/AWSEventsChannel)에서 온라인으로 심층 분석 교육 브레이크아웃 세션을 볼 수 있습니다.
또한 [AWS 계정 팀](https://aws.amazon.com/startups/learn/meet-your-aws-account-team)에 최신 보안 서비스 업데이트 및 권장 사항에 대해 문의할 수 있습니다. 직접 연결되는 연락처 정보가 없는 경우 [영업 지원 양식](https://aws.amazon.com/contact-us/sales-support/)을 통해 팀에 문의할 수 있습니다. 마찬가지로, [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/)를 구독한 경우 TAM(Technical Account Manager)으로부터 매주 업데이트를 받고 정기적인 검토 회의 일정을 잡을 수 있습니다.
### 구현 단계
1. 좋아하는 RSS 리더와 함께 다양한 블로그와 게시판을 구독하거나 일간 기능 업데이트 SNS 주제를 구독합니다.
1. 어떤 AWS 이벤트에 참석해야 하는지 평가하여 새로운 기능과 서비스에 대해 직접 알아보세요.
1. 보안 서비스 및 기능 업데이트에 관한 질문이 있으면 AWS 계정 팀과 회의를 진행하세요.
1. Enterprise Support를 구독하여 TAM(Technical Account Manager)과 정기적으로 상담하는 것을 고려해 보세요.
## 리소스
**관련 모범 사례:**
+ [PERF01-BP01 사용 가능한 클라우드 서비스 및 기능 학습 및 이해](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_understand_cloud_services_and_features.html)
+ [COST01-BP07 새로운 서비스 릴리스로 최신 상태 유지](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management_scheduled.html)