기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 에서 Essential Eight 성숙도에 도달하기 위한 지표 사례 연구 AWS
사례 연구

이 장에서는 AWS에서 Essential Eight 성숙도를 대상으로 하는 정부 기관에 대한 참고용 사례 연구를 제공합니다.

**Topics**
+ [

# 시나리오 및 아키텍처 개요
](scenario.md)
+ [

# 워크로드 예제: 서버리스 데이터 레이크
](serverless-data-lake.md)
+ [

# 워크로드 예제: 컨테이너화된 웹 서비스
](containerised-web-service.md)
+ [

# 워크로드 예제: Amazon EC2에서 COTS 소프트웨어
](cots-software.md)

# 시나리오 및 아키텍처 개요
개요

정부 기관은 AWS 클라우드에 세 가지 워크로드를 보유합니다.
+ Amazon Simple Storage Service(Amazon S3)를 스토리지 및 AWS Lambda 추출, 변환 및 로드(ETL) 작업에 사용하는 [서버리스 데이터 레이크](serverless-data-lake.md) 
+ Amazon Elastic Container Service(Amazon ECS)에서 실행되고 Amazon Relational Database Service(Amazon RDS)의 데이터베이스를 사용하는 [컨테이너화된 웹 서비스](containerised-web-service.md)
+ Amazon EC2에서 실행되는 [상용 기성품(COTS) 소프트웨어](cots-software.md)

*클라우드 팀은* 조직을 위한 중앙 집중식 플랫폼을 제공하여 AWS 환경에 대한 핵심 서비스를 실행합니다. 클라우드 팀은 AWS 환경에 대한 핵심 서비스를 제공합니다. 각 워크로드는 *개발자 팀* 또는 *전달 팀*이라고도 하는 고유한 *애플리케이션 팀*에서 소유합니다.

## 핵심 아키텍처


클라우드 팀은 이미에서 AWS 클라우드에서 다음 기능을 설정했습니다.
+ 자격 증명 연동은 Microsoft Entra ID(이전 *Azure Active Directory*) 인스턴스 AWS IAM Identity Center 에 연결됩니다. 페더레이션은 MFA, 사용자 계정의 자동 만료, AWS Identity and Access Management (IAM) 역할을 통한 수명이 짧은 자격 증명 사용을 적용합니다.
+ 중앙 집중식 AMI 파이프라인은 EC2 Image Builder에서 OS 및 코어 애플리케이션을 패치하는 데 사용됩니다.
+ Amazon Inspector는 취약성을 식별할 수 있으며 모든 보안 조사 결과는 중앙 집중식 관리를 위해 Amazon GuardDuty로 전송됩니다.
+ 설정된 메커니즘은 애플리케이션 제어 규칙을 업데이트하고, 사이버 보안 이벤트에 대응하며, 규정 준수 격차를 검토하는 데 사용됩니다.
+ AWS CloudTrail 는 로깅 및 모니터링에 사용됩니다.
+ 루트 사용자의 로그인과 같은 보안 이벤트는 알림을 시작합니다.
+ SCP 및 VPC 엔드포인트 정책은 AWS 환경에 대한 데이터 경계를 설정합니다.
+ SCP 애플리케이션 팀이 CloudTrail 및 AWS Config와 같은 보안 및 로깅 서비스를 비활성화하지 못하도록 합니다.
+ AWS Config 조사 결과는 보안을 AWS 계정 위해 AWS 조직 전체의에서 단일 로 집계됩니다.
+  AWS Config [ACSC Essential 8 적합성 팩](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-acsc_essential_8.html)은 조직의 모든 AWS 계정 에서 활성화됩니다.

# 워크로드 예제: 서버리스 데이터 레이크
서버리스 데이터 레이크

이 워크로드는 [테마 1: 관리형 서비스 사용](theme-1.md)의 예제입니다.

데이터 레이크는 스토리지 및 ETL에 Amazon S3 AWS Lambda 를 사용합니다. 이러한 리소스는 AWS Cloud Development Kit (AWS CDK) 앱에서 정의됩니다. 시스템 변경 사항은를 통해 배포됩니다 AWS CodePipeline. 이 파이프라인은 애플리케이션 팀으로 제한됩니다. 애플리케이션 팀이 코드 리포지토리에 대해 풀 요청을 하면 [2인 규칙](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/best-practice-5.2---implement-least-privilege-policies-for-source-and-downstream-systems..html)이 사용됩니다.

이 워크로드의 경우 애플리케이션 팀은 Essential Eight 전략을 처리하기 위해 다음 작업을 수행합니다.

*애플리케이션 제어*
+ 애플리케이션 팀은 GuardDuty에서 [Lambda 보호](https://docs.aws.amazon.com/guardduty/latest/ug/lambda-protection.html)를 활성화하고 Amazon Inspector에서 [Lambda 스캔](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)을 활성화합니다.
+ 애플리케이션 팀은 [Amazon Inspector 조사 결과를 관리](https://docs.aws.amazon.com/inspector/latest/user/findings-managing-automating-responses.html#findings-managing-eventbridge-tutorial)하고 검사하는 메커니즘을 구현합니다.

*애플리케이션 패치*
+ 애플리케이션 팀은 Amazon Inspector에서 Lambda 스캔을 활성화하고 더 이상 사용되지 않거나 취약한 라이브러리에 대한 알림을 구성합니다.
+ 애플리케이션 팀은 AWS Config 가 자산 검색을 위한 AWS 리소스를 추적할 수 있도록 합니다.

*관리 권한 제한*
+ [핵심 아키텍처](scenario.md#core-architecture) 섹션에서 설명한 대로 애플리케이션 팀은 이미 배포 파이프라인의 승인 규칙을 통해 프로덕션 배포에 대한 액세스를 제한합니다.
+ 애플리케이션 팀은 [핵심 아키텍처](scenario.md#core-architecture) 섹션에서 설명한 대로 중앙 집중식 ID 페더레이션 및 중앙 집중식 로깅 솔루션을 사용합니다.
+ 애플리케이션 팀은 AWS CloudTrail 추적 및 Amazon CloudWatch 필터를 생성합니다.
+ 애플리케이션 팀은 CodePipeline 배포 및 AWS CloudFormation 스택 삭제에 대한 Amazon Simple Notification Service(Amazon SNS) 알림을 설정합니다.

*운영 체제 패치*
+ 애플리케이션 팀은 Amazon Inspector에서 Lambda 스캔을 활성화하고 더 이상 사용되지 않거나 취약한 라이브러리에 대한 알림을 구성합니다.

*멀티 팩터 인증*
+ 애플리케이션 팀은 [핵심 아키텍처](scenario.md#core-architecture) 섹션에서 설명한 대로 중앙 집중식 ID 페더레이션 솔루션을 사용합니다. 이 솔루션은 MFA를 적용하고 인증을 로깅하며 의심스러운 MFA 이벤트에 대해 알림을 생성하거나 자동으로 응답합니다.

*정기 백업*
+ 애플리케이션 팀은 AWS CDK 앱, Lambda 함수 및 구성과 같은 [코드를 코드 리포지토리](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)에 저장합니다.
+ 애플리케이션 팀은 버전 관리 및 Amazon S3 Object Lock을 활성화하여 객체 삭제 또는 수정을 방지합니다.
+ 애플리케이션 팀은 전체 데이터세트를 다른 AWS 리전에 복제하는 대신 기본 제공 Amazon S3 내구성을 사용합니다.
+ 애플리케이션 팀은 데이터 주권 요구 사항을 AWS 리전 충족하는 다른에서 워크로드 사본을 실행합니다. Amazon DynamoDB 글로벌 테이블과 Amazon S3 [교차 리전 복제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario)를 사용하여 기본 리전에서 보조 리전으로 데이터를 자동 복제합니다.

# 워크로드 예제: 컨테이너화된 웹 서비스
컨테이너화된 웹 서비스

이 워크로드는 [테마 2: 보안 파이프라인을 통해 변경 불가능한 인프라 관리](theme-2.md)의 예제입니다.

웹 서비스는 Amazon ECS에서 실행되며 Amazon RDS의 데이터베이스를 사용합니다. 애플리케이션 팀은 CloudFormation 템플릿에서 이러한 리소스를 정의합니다. 컨테이너는 EC2 Image Builder로 생성되어 Amazon ECR에 저장됩니다. 애플리케이션 팀은를 통해 시스템에 변경 사항을 배포합니다 AWS CodePipeline. 이 파이프라인은 애플리케이션 팀으로 제한됩니다. 애플리케이션 팀이 코드 리포지토리에 대해 풀 요청을 하면 [2인 규칙](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/best-practice-5.2---implement-least-privilege-policies-for-source-and-downstream-systems..html)이 사용됩니다.

이 워크로드의 경우 애플리케이션 팀은 Essential Eight 전략을 처리하기 위해 다음 작업을 수행합니다.

*애플리케이션 제어*
+ 애플리케이션 팀은 [Amazon Inspector에서 Amazon ECR 컨테이너 이미지를 스캔](https://docs.aws.amazon.com/inspector/latest/user/scanning-ecr.html)하는 기능을 지원합니다.
+ 애플리케이션 팀은 [파일 액세스 정책 대몬(fapolicyd)](https://github.com/linux-application-whitelisting/fapolicyd/blob/main/README.md) 보안 도구를 EC2 Image Builder 파이프라인에 빌드합니다. 자세한 내용은 ACSC 웹 사이트의 [Implementing Application Control](https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/system-hardening/implementing-application-control)을 참조하세요.
+ 애플리케이션 팀은 Amazon CloudWatch Logs에 출력을 로깅하도록 Amazon ECS 태스크 정의를 구성합니다.
+ 애플리케이션 팀은 Amazon Inspector 조사 결과를 관리하고 검사하는 메커니즘을 구현합니다.

*애플리케이션 패치*
+ 애플리케이션 팀은 Amazon Inspector에서 Amazon ECR 컨테이너 이미지 스캔을 활성화하고 더 이상 사용되지 않거나 취약한 라이브러리에 대한 알림을 구성합니다.
+ 애플리케이션 팀은 Amazon Inspector 조사 결과에 대한 응답을 자동화합니다. 새로운 조사 결과는 Amazon EventBridge 트리거를 통해 배포 파이프라인을 시작하며, 이때 CodePipeline이 대상입니다.
+ 애플리케이션 팀은 AWS Config 가 자산 검색을 위한 AWS 리소스를 추적할 수 있도록 합니다.

*관리 권한 제한*
+ 애플리케이션 팀은 이미 배포 파이프라인의 승인 규칙을 통해 프로덕션 배포에 대한 액세스를 제한합니다.
+ 애플리케이션 팀은 자격 증명 교체 및 중앙 집중식 로깅을 위해 중앙 집중식 클라우드 팀의 ID 페더레이션에 의존합니다.
+ 애플리케이션 팀은 CloudTrail 추적 및 CloudWatch 필터를 생성합니다.
+ 애플리케이션 팀은 CodePipeline 배포 및 CloudFormation 스택 삭제에 대한 Amazon SNS 알림을 설정합니다.

*운영 체제 패치*
+ 애플리케이션 팀은 Amazon Inspector에서 Amazon ECR 컨테이너 이미지 스캔을 활성화하고 OS 패치 업데이트에 대한 알림을 구성합니다.
+ 애플리케이션 팀은 Amazon Inspector 조사 결과에 대한 응답을 자동화합니다. 새로운 조사 결과는 EventBridge 트리거를 통해 배포 파이프라인을 시작하며, 이때 CodePipeline이 대상입니다.
+ 애플리케이션 팀은 업데이트에 대한 알림을 받을 수 있도록 Amazon RDS 이벤트 알림을 구독합니다. 이러한 업데이트를 수동으로 적용할지 아니면 Amazon RDS에서 자동으로 적용할지에 관해 비즈니스 소유자와 함께 위험 기반 의사 결정을 내립니다.
+ 애플리케이션 팀은 유지 관리 이벤트의 영향을 줄이기 위해 Amazon RDS 인스턴스를 다중 가용 영역 클러스터로 구성합니다.

*멀티 팩터 인증*
+ 애플리케이션 팀은 [핵심 아키텍처](scenario.md#core-architecture) 섹션에서 설명한 대로 중앙 집중식 ID 페더레이션 솔루션을 사용합니다. 이 솔루션은 MFA를 적용하고 인증을 로깅하며 의심스러운 MFA 이벤트에 대해 알림을 생성하거나 자동으로 응답합니다.

*정기 백업*
+ 애플리케이션 팀은 Amazon RDS 클러스터의 데이터 백업을 자동화 AWS Backup 하도록를 구성합니다.
+ 애플리케이션 팀은 CloudFormation 템플릿을 코드 리포지토리에 저장합니다.
+ 애플리케이션 팀은 자동화된 파이프라인을 개발하여 [다른 리전에서 워크로드 사본을 생성하고 자동 테스트를 실행합니다](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)(AWS 블로그 게시물). 자동화된 테스트가 실행되면 파이프라인이 스택을 삭제합니다. 이 파이프라인은 한 달에 한 번 자동으로 실행되며 복구 절차의 효과를 검증합니다.

# 워크로드 예제: Amazon EC2에서 COTS 소프트웨어
COTS 소프트웨어

이 워크로드는 [테마 3: 자동화를 통해 변경 가능한 인프라 관리](theme-3.md)의 예제입니다.

Amazon EC2에서 실행되는 워크로드는 AWS Management Console을 사용하여 수동으로 생성되었습니다. 개발자는 EC2 인스턴스에 로그인하고 소프트웨어를 업데이트하여 시스템을 수동으로 업데이트합니다.

이 워크로드의 경우 클라우드 및 애플리케이션 팀은 Essential Eight 전략을 처리하기 위해 다음 작업을 수행합니다.

*애플리케이션 제어*
+ 클라우드 팀은 중앙 집중식 AMI 파이프라인을 구성하여 AWS Systems Manager 에이전트(SSM 에이전트), CloudWatch 에이전트 및 SELinux를 설치하고 구성합니다. 조직의 모든 계정에서 결과 AMI를 공유합니다.
+ 클라우드 팀은 AWS Config 규칙을 사용하여 실행 중인 모든 [EC2 인스턴스가 Systems Manager에서 관리되고](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html) [SSM 에이전트, CloudWatch 에이전트 및 SELinux가 설치되어](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-applications-required.html) 있는지 확인합니다.
+ 클라우드 팀은 Amazon OpenSearch Service에서 실행되는 중앙 집중식 보안 정보 및 이벤트 관리(SIEM) 솔루션으로 Amazon CloudWatch Logs 출력을 보냅니다.
+ 애플리케이션 팀은 메커니즘을 구현하여 AWS Config, GuardDuty 및 Amazon Inspector의 결과를 검사하고 관리합니다. 클라우드 팀은 애플리케이션 팀이 놓친 결과를 포착하기 위해 자체 메커니즘을 구현합니다. 조사 결과를 처리하기 위한 취약성 관리 프로그램 생성에 대한 자세한 지침은 [AWS에서 확장 가능한 취약성 관리 프로그램 빌드](https://docs.aws.amazon.com/prescriptive-guidance/latest/vulnerability-management/introduction.html)를 참조하세요.

*애플리케이션 패치*
+ 애플리케이션 팀은 Amazon Inspector 조사 결과를 기반으로 인스턴스를 패치합니다.
+ 클라우드 팀은 기본 AMI를 패치하고 애플리케이션 팀은 AMI가 변경될 때 알림을 받습니다.
+ 애플리케이션 팀은 워크로드에 필요한 포트의 트래픽만 허용하도록 [보안 그룹 규칙](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)을 구성하여 EC2 인스턴스에 대한 직접 액세스를 제한합니다.
+ 애플리케이션 팀은 [Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html)를 사용하여 개별 인스턴스에 로그인하는 대신 인스턴스에 패치를 적용합니다.
+ EC2 인스턴스 그룹에서 임의 명령을 실행하기 위해 애플리케이션 팀은 [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)를 사용합니다.
+ 드문 경우지만 애플리케이션 팀이 인스턴스에 직접 액세스해야 하는 경우 [Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)를 사용합니다. 이 액세스 접근 방식은 페더레이션 ID를 사용하고 감사 목적으로 모든 세션 활동을 로깅합니다.

*관리 권한 제한*
+ 애플리케이션 팀은 워크로드에 필요한 포트에서만 트래픽을 허용하도록 [보안 그룹 규칙](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)을 구성합니다. 이렇게 하면 Amazon EC2 인스턴스에 대한 직접 액세스를 제한하고 사용자가 Session Manager를 통해 EC2 인스턴스에 액세스해야 합니다.
+ 애플리케이션 팀은 자격 증명 교체 및 중앙 집중식 로깅을 위해 중앙 집중식 클라우드 팀의 ID 페더레이션에 의존합니다.
+ 애플리케이션 팀은 CloudTrail 추적 및 CloudWatch 필터를 생성합니다.
+ 애플리케이션 팀은 CodePipeline 배포 및 CloudFormation 스택 삭제에 대한 Amazon SNS 알림을 설정합니다.

*운영 체제 패치*
+ 클라우드 팀은 기본 AMI를 패치하고 애플리케이션 팀은 AMI가 변경될 때 알림을 받습니다. 애플리케이션 팀은 이 AMI를 사용하여 새 인스턴스를 배포한 다음 Systems Manager의 기능인 [State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)를 사용하여 필요한 소프트웨어를 설치합니다.
+ 애플리케이션 팀은 Patch Manager를 사용하여 개별 인스턴스에 로그인하는 대신 인스턴스에 패치를 적용합니다.
+ EC2 인스턴스 그룹에서 임의 명령을 실행하기 위해 애플리케이션 팀은 Run Command를 사용합니다.
+ 드문 경우지만 애플리케이션 팀이 직접 액세스해야 하는 경우 Session Manager를 사용합니다.

*멀티 팩터 인증*
+ 애플리케이션 팀은 [핵심 아키텍처](scenario.md#core-architecture) 섹션에서 설명한 대로 중앙 집중식 ID 페더레이션 솔루션을 사용합니다. 이 솔루션은 MFA를 적용하고 인증을 로깅하며 의심스러운 MFA 이벤트에 대해 알림을 생성하거나 자동으로 응답합니다.

*정기 백업*
+ 애플리케이션 팀은 EC2 인스턴스 및 Amazon Elastic Block Store(Amazon EBS) 볼륨에 대한 AWS Backup 계획을 생성합니다.
+ 애플리케이션 팀은 매월 백업 복원을 수동으로 수행하기 위해 메커니즘을 구현합니다.