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

# 워크로드 예제: Amazon EC2에서 COTS 소프트웨어
<a name="cots-software"></a>

이 워크로드는 [테마 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 계획을 생성합니다.
+ 애플리케이션 팀은 매월 백업 복원을 수동으로 수행하기 위해 메커니즘을 구현합니다.