보안 엔클레이브를 사용하여 매우 민감한 워크로드를 보호하고 격리
이 지침은 국가 안보, 국방 및 국가 법 집행 기관의 민감한 워크로드를 위한 포괄적인 클라우드 아키텍처를 구축하는 방법을 보여줍니다. AWS의 다중 계정 아키텍처를 사용하면 민감한 데이터와 워크로드를 안전하게 유지하면서 임무를 완수할 수 있습니다. 이 지침은 다양한 미국 보안 프레임워크에 맞춰 중앙 ID 및 액세스 관리, 거버넌스, 데이터 보안, 포괄적인 로깅, 네트워크 설계 및 세분화를 처리하면서 엄격하고 고유한 보안 및 규정 준수 요구 사항을 충족할 수 있도록 설계되었습니다.
참고: [고지 사항]
아키텍처 다이어그램
-
개요
-
조직 관리 계정
-
보안 계정
-
인프라 계정
-
애플리케이션, 커뮤니티, 팀 또는 그룹 계정(민감한 경우)
-
개요
-
이 아키텍처 다이어그램은 고유한 보안 및 규정 준수 요구 사항이 있는 포괄적인 다중 계정 워크로드를 구성하는 방법에 대한 개요를 제공합니다. 이 지침을 배포하는 방법에 대한 자세한 내용을 보려면 다른 탭을 여세요.
1단계
서비스 제어 정책(SCP)에 따라 여러 계정을 보유한 AWS Organizations의 조직: 조직은 단일 고객 엔터티가 제어하는 여러 개의 개별 AWS 계정을 그룹화합니다. 개별 AWS 계정은 마치 다른 AWS 고객이 소유한 것처럼 워크로드 또는 환경 간에 강력한 컨트롤 플레인 및 데이터 플레인 격리를 제공합니다.2단계
관리 계정은 조직을 생성하는 데 사용됩니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다.- 조직에 계정을 생성하고 모든 조직 단위(OU)에 대한 정책을 관리합니다.
- 다음 OU를 조직에 소속시킵니다.
- 보안 OU
- 인프라 OU
- 민감한 애플리케이션 OU
각 OU에는 디자인당 하나 이상의 멤버 계정 또는 중첩된 OU가 있습니다.
3단계
애플리케이션 OU에는 애플리케이션 제공 및 수명 주기 관리 전용으로 사용되는 여러 개의 중첩된 OU가 있으며 다음을 포함합니다.- 개발 OU
- 테스트 OU
- 프로덕션 OU
- 공유된 OU
또한 샌드박스 OU는 민감하지 않은 워크로드로 프로비저닝할 수도 있습니다.
-
조직 관리 계정
-
이 아키텍처 다이어그램은 조직이 단일 고객 엔터티에 의해 모두 제어되는 여러 계정을 그룹화하는 방법을 보여줍니다. 이 아키텍처 다이어그램의 단계에 따라 이 지침의 조직 관리 계정 부분을 배포합니다.
1단계
여러 계정을 가진 조직: 조직은 단일 고객 엔터티에 의해 제어되는 여러 개의 개별 AWS 계정을 그룹화합니다. 이를 통해 결제를 통합하고, OU를 사용하여 계정을 그룹화하고, SCP를 사용하여 조직의 예방적 제어를 쉽게 배포할 수 있습니다.2단계
예방적 보안 제어: SCP가 구현하는 이러한 제어는 아키텍처를 보호하고 가드레일 비활성화를 방지하며 바람직하지 않은 사용자 행동을 차단합니다. SCP는 주로 AWS 계정, OU 또는 조직 수준에서 특정 또는 전체 범주의 API 작업을 거부하는 데 사용되는 가드레일 메커니즘을 제공합니다. 이를 사용하여 워크로드가 지정된 AWS 리전에만 배포되도록 하거나 특정 AWS 서비스에 대한 액세스를 거부할 수 있습니다.
3단계
자동화: 자동화는 조직이 새로운 팀과 워크로드를 온보딩함에 따라 새 AWS 계정을 추가할 때 가드레일이 일관되게 적용되도록 합니다. 규정 준수 드리프트를 해결하고 루트 조직 계정에 가드레일을 제공합니다.
4단계
암호화: 고객 관리형 키를 사용하는 AWS Key Management Service(AWS KMS)는 Amazon Simple Storage Service(S3) 버킷, Amazon Elastic Block Store(Amazon EBS) 볼륨, Amazon Relational Database Service(RDS) 데이터베이스 또는 기타 AWS 스토리지 서비스에 있든 관계없이 FIPS 140-2로 검증된 암호화를 사용하여 저장된 데이터를 암호화합니다. TLS 1.2 이상을 사용하여 전송 중 데이터를 보호합니다.5단계
Single Sign-On: AWS Identity and Access Management(IAM)의 기능인 IAM Identity Center는 권한 있는 보안 주체에 대해 조직 전체의 AWS 계정에 중앙 집중식 IAM 역할 위임을 제공하는 데 사용됩니다. 조직의 기존 ID는 고객의 기존 Active Directory(AD) ID 스토어 또는 다른 타사 ID 제공업체(idP)에서 가져올 수 있습니다.AWS는 WebAuthn, FIDO2 및 U2F(Universal 2nd Factor) 인증 및 디바이스를 지원하는 인증 앱, 보안 키 및 내장 인증기를 사용하여 다중 인증 적용을 용이하게 합니다.
-
보안 계정
-
이 아키텍처 다이어그램은 AWS 서비스 및 계정 전반에 걸쳐 포괄적인 로그 수집을 중앙 집중식으로 구성하는 방법을 보여줍니다. 이 아키텍처 다이어그램의 단계에 따라 이 지침의 보안 계정 부분을 배포합니다.
1단계
중앙 집중식 로깅: 이 아키텍처는 AWS 서비스 및 계정 전반의 포괄적인 로그 수집 및 중앙 집중화를 규정합니다. AWS CloudTrail 로그는 조직 전체에서 작동하여 클라우드 환경 전반에 걸쳐 완전한 컨트롤 플레인 감사 기능을 제공합니다.클라우드 네이티브 AWS 로깅 서비스인 Amazon CloudWatch 로그는 운영 체제 및 애플리케이션 로그, VPC 흐름 로그, 도메인 이름 시스템 로그를 비롯한 다양한 로그를 캡처하는 데 사용됩니다. 이 로그는 중앙 집중화되어 정의된 보안 담당자만 사용할 수 있습니다.
2단계
중앙 집중식 보안 모니터링: 다양한 유형의 탐지 보안 제어의 자동 배포를 통해 고객의 AWS 조직 전체에 규정 준수 드리프트 및 보안 위협이 드러납니다. 여기에는 조직의 모든 계정에서 다양한 AWS 보안 서비스를 활성화하는 것이 포함됩니다.이러한 보안 서비스에는 Amazon GuardDuty, AWS Security Hub, AWS Config, AWS Firewall Manager, Amazon Macie, IAM Access Analyzer, CloudWatch 경보가 있습니다. 모든 보안 조사 결과 및 규정 준수 드리프트를 조직 전체에서 쉽게 파악할 수 있도록 다중 계정 환경 전반의 제어 및 가시성을 단일 중앙 보안 도구 계정에 위임해야 합니다.
3단계
보기 전용 액세스 및 검색 기능: 보안 계정에는 인시던트 발생 시 조사를 용이하게 하기 위해 조직 전체에 보기 전용 액세스(각 계정의 CloudWatch 콘솔에 대한 액세스 포함)가 제공됩니다.
보기 전용 액세스는 데이터에 대한 액세스를 제공하지 않는다는 점에서 읽기 전용 액세스와 다릅니다. 선택적 추가 기능을 사용하면 포괄적인 중앙 집중식 로그 세트를 사용하여 검색 가능하고 상관 관계 및 기본 대시보드가 제공됩니다.
-
인프라 계정
-
이 아키텍처 다이어그램은 Virtual Private Cloud(VPC)를 사용하여 중앙 집중화되고 격리된 네트워킹 환경을 구축하는 방법을 보여줍니다. 이 아키텍처 다이어그램의 단계에 따라 이 지침의 인프라 계정 부분을 배포합니다.
1단계
중앙 집중식 격리 네트워킹: Amazon Virtual Private Cloud(VPC)를 통해 구축된 VPC는 공유 네트워크 계정에 중앙 집중화된 워크로드 간의 데이터 플레인 격리를 생성하는 데 사용됩니다. 중앙 집중화는 강력한 업무 분리 및 비용 최적화를 촉진합니다.2단계
조정된 연결: AWS Transit Gateway, AWS Site-to-Site VPN, 차세대 방화벽 및 AWS Direct Connect(해당하는 경우)를 사용하여 온 프레미스 환경에 대한 연결, 인터넷 송신, 공유 리소스 및 AWS API가 중앙의 수신 및 송신 지점에서 조정됩니다.3단계
대체 옵션: 중앙 집중식 VPC 아키텍처가 모든 고객에게 적합한 것은 아닙니다. 비용 최적화에 관심이 없는 고객을 위해 중앙 공유 네트워크 계정의 Transit Gateway를 통해 상호 연결된 로컬 계정 기반 VPC용 옵션을 제공합니다.
두 옵션 모두에서 아키텍처는 비용 효율성을 위해 중앙 집중식 엔드포인트를 사용하여 AWS 퍼블릭 API 엔드포인트를 고객의 프라이빗 VPC 주소 스페이스로 이동하도록 규정합니다.
4단계
중앙 집중식 인그레스 및 이그레스 서비스형 인프라(IaaS) 검사: IaaS 기반 워크로드에 대한 중앙 집중식 인그레스 및 이그레스 요구 사항은 흔히 볼 수 있습니다. 아키텍처는 이 기능을 제공하므로 고객은 AWS Network Firewall, AWS WAF 또는 Elastic Load Balancing(ELB)를 통한 Application Load Balancer와 같은 기본 AWS 인그레스 및 이그레스 방화벽 검사 서비스가 요구 사항을 충족하는지 판단할 수 있습니다.그렇지 않은 경우 고객은 타사 방화벽 어플라이언스로 이러한 기능을 보강할 수 있습니다. 아키텍처는 AWS 방화벽으로 시작하여 타사 방화벽으로 전환하거나 인그레스 및 이그레스 방화벽 기술의 조합을 사용할 수 있도록 지원합니다.
-
애플리케이션, 커뮤니티, 팀 또는 그룹 계정(민감한 경우)
-
이 아키텍처 다이어그램은 소프트웨어 개발 수명 주기의 여러 단계에 속하는 워크로드 간 또는 서로 다른 IT 관리자 역할 간의 세분화 및 분리를 구성하는 방법을 보여줍니다. 이 아키텍처 다이어그램의 단계에 따라 이 지침의 애플리케이션, 커뮤니티, 팀 또는 그룹 계정 부분을 배포합니다.
1단계
세분화 및 분리: 아키텍처는 단순히 소프트웨어 개발 수명 주기의 여러 단계에 속하는 워크로드 간 또는 서로 다른 IT 관리 역할(예: 네트워킹, 인그레스 및 이그레스 방화벽, 워크로드 간) 간의 강력한 세분화 및 분리만 제공하는 것은 아닙니다.ELB 및 AWS WAF와 같은 서비스와 함께 AWS Nitro System의 하드웨어에 적용되는 상태 유지 방화벽에 모든 인스턴스 또는 구성 요소를 래핑하여 환경을 미세분할하는 강력한 네트워크 구역 지정 아키텍처도 제공합니다.
2단계
모든 네트워크 흐름은 엄격하게 적용되며 명시적으로 허용되지 않는 한 애플리케이션 간, 애플리케이션 내 계층 간, 애플리케이션 계층의 노드 간 수평적 이동이 방지됩니다. 또한 CI/CD 아키텍처에 대한 권장 사항을 통해 개발, 테스트 및 프로덕션 간의 라우팅이 방지되어 개발자의 민첩성을 높이고 적절한 승인을 받은 환경 간의 코드 프로모션이 용이합니다.
Well-Architected 원칙
AWS Well-Architected Framework는 클라우드에서 시스템을 구축하는 동안 사용자가 내리는 의사 결정의 장단점을 이해하는 데 도움이 됩니다. 이 프레임워크의 6가지 원칙을 통해 안정적이고 안전하며 효과적이고 비용 효율적이며 지속 가능한 시스템을 설계 및 운영하기 위한 아키텍처 모범 사례를 배울 수 있습니다. AWS Management Console에서 추가 요금 없이 사용할 수 있는 AWS Well-Architected Tool을 사용하면 각 원칙에 대한 여러 질문에 답하여 이러한 모범 사례와 비교하며 워크로드를 검토할 수 있습니다.
위의 아키텍처 다이어그램은 Well-Architected 모범 사례를 고려하여 생성된 솔루션의 예시입니다. Well-Architected를 완전히 충족하려면 가능한 많은 Well-Architected 모범 사례를 따라야 합니다.
-
운영 우수성
이 지침에서는 AWS CloudFormation 스택 및 구성을 갖춘 조직을 사용하여 AWS 환경의 안전한 기반을 구축합니다. 이는 기술 보안 제어의 구현을 가속화하는 코드형 인프라(IaC) 솔루션을 제공합니다. 구성 규칙은 규정된 아키텍처에 부정적인 영향을 미치는 것으로 확인된 모든 구성 델타를 해결합니다. 민감한 기밀 워크로드에 AWS 글로벌 상용 인프라를 사용하고 보안 시스템을 자동화하여 프로세스 및 절차를 지속적으로 개선하면서 임무를 더 빠르게 수행할 수 있습니다.
-
보안
이 지침에서는 조직을 사용하여 CloudTrail을 통한 API 로깅과 같은 조직 가드레일의 배포를 용이하게 합니다. 이 지침은 또한 규범적 AWS SCP를 가드레일 메커니즘으로 사용하여 예방적 제어를 제공합니다. 이 메커니즘은 주로 환경 내에서 특정 또는 전체 API 범주를 거부(워크로드가 지정된 리전에만 배포되도록 하기 위해)하거나 특정 AWS 서비스에 대한 액세스를 거부하는 데 사용됩니다. CloudTrail 및 CloudWatch 로그는 AWS 서비스 및 계정 전반에 걸쳐 규정된 포괄적인 로그 수집 및 중앙 집중화를 지원합니다. AWS 보안 기능 및 다양한 보안 관련 서비스는 세계에서 가장 엄격한 보안 요구 사항을 충족하는 데 도움이 되는 정의된 패턴으로 구성됩니다.
-
신뢰성
이 지침은 여러 가용 영역을 사용하므로 하나의 가용 영역이 손실되어도 애플리케이션 가용성에 영향을 미치지 않습니다. CloudFormation을 사용하여 안전하고 통제된 방식으로 인프라의 프로비저닝 및 업데이트를 자동화할 수 있습니다. 또한 이 지침은 사용자 환경 내에서 AWS 리소스 구성 및 구성 변경을 평가하기 위한 사전 구축된 규칙을 제공합니다. 또는 AWS Lambda에서 사용자 지정 규칙을 생성하여 모범 사례 및 지침을 정의할 수도 있습니다. 요구 사항에 맞게 환경을 확장하는 기능을 자동화하고 잘못된 구성이나 일시적인 네트워크 문제와 같은 장애를 완화할 수 있습니다.
-
성능 효율성
이 지침은 단일 게이트웨이를 통해 여러 VPC를 연결하고 중앙 허브 역할을 하는 Transit Gateway를 사용해 클라우드 인프라 관리를 단순화하여 네트워크 아키텍처를 쉽게 확장하고 유지 관리할 수 있도록 합니다. 이를 통해 네트워크 아키텍처가 단순화되고 조직 내 여러 AWS 계정 간에 효율적으로 트래픽을 라우팅할 수 있습니다.
-
비용 최적화
이 지침은 불필요한 비용이나 최적이 아닌 리소스의 사용을 방지하거나 제거할 수 있는 기능을 제공합니다. 조직은 리소스 사용과 비용 최적화를 강력하게 분리할 수 있도록 중앙 집중화 및 통합 결제를 제공합니다. 이 지침은 비용 효율성을 위해 중앙 집중식 엔드포인트를 사용하여 AWS 퍼블릭 API 엔드포인트를 프라이빗 VPC 주소 스페이스로 이동하는 방법을 설명합니다. 또한 AWS Cost & Usage Report(AWS CUR)를 사용하여 AWS 사용량을 추적하고 요금을 추정할 수 있습니다.
-
지속 가능성
이 지침은 자체 데이터 센터 내 워크로드 관리와 관련된 탄소 발자국을 줄이는 데 도움이 됩니다. AWS 글로벌 인프라는 기존 데이터 센터보다 지원 인프라(예: 전력, 냉각, 네트워킹), 높은 사용률, 더 빠른 기술 갱신을 제공합니다. 또한 워크로드의 세분화 및 분리를 통해 불필요한 데이터 이동을 줄일 수 있으며, Amazon S3는 스토리지 계층과 데이터를 효율적인 스토리지 계층으로 자동 이동하는 기능을 제공합니다.
구현 리소스
샘플 코드를 시작점으로 사용할 수 있습니다. 이 샘플 코드는 업계에서 검증되었고 권장되는 것이지만 최종적인 것은 아니며, 시작하는 데 도움을 줄 것입니다.
관련 콘텐츠
TSE-SE 샘플 구성(LZA 자동화 엔진 사용)
신뢰할 수 있는 보안 엔클레이브 - 센서티브 에디션
고지 사항
샘플 코드, 소프트웨어 라이브러리, 명령줄 도구, 개념 증명, 템플릿 또는 기타 관련 기술(AWS 직원을 통해 제공되는 상기 항목 포함)은 AWS 이용 계약 또는 귀하와 AWS 간의 서면 계약(둘 중 해당되는 것)에 따라 AWS 콘텐츠로 제공됩니다. 이 AWS 콘텐츠를 프로덕션 계정, 프로덕션 또는 기타 중요한 데이터에 사용해서는 안 됩니다. 귀하는 특정 품질 제어 방식 및 표준에 따라 프로덕션급 사용에 적절하게 샘플 코드와 같은 AWS 콘텐츠를 테스트, 보호 및 최적화할 책임이 있습니다. AWS 콘텐츠를 배포하면 Amazon EC2 인스턴스를 실행하거나 Amazon S3 스토리지를 사용할 때와 같이 요금이 부과되는 AWS 리소스를 생성하거나 사용하는 것에 대한 AWS 요금이 발생할 수 있습니다.
본 지침에 서드 파티 서비스 또는 조직이 언급되어 있다고 해서 Amazon 또는 AWS와 서드 파티 간의 보증, 후원 또는 제휴를 의미하지는 않습니다. AWS의 지침을 기술적 시작점으로 사용할 수 있으며 아키텍처를 배포할 때 서드 파티 서비스와의 통합을 사용자 지정할 수 있습니다.