기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 클라우드에 대한 Essential Eight 전략의 재해석
다음은 Microsoft 기반 인터넷 연결 네트워크에 대해 설계된 원래의 Essential Eight 완화 전략입니다.
+ 애플리케이션 제어
+ 애플리케이션 패치
+ Microsoft Office 매크로 설정 구성
+ 사용자 애플리케이션 하드닝
+ 관리 권한 제한
+ 운영 체제 패치
+ 다중 인증
+ 정기 백업
Essential Eight 프레임워크는 클라우드 환경을 위해 설계되지 않았음을 반복하는 것이 중요합니다. 그러나 기본 원칙이 적용되며 Essential Eight 전략과 AWS Well-Architected Framework 모범 사례 간에 중복됩니다.
다양한 클라우드 네이티브 접근 방식은 보안을 개선하고 규정 준수 부담을 크게 줄일 수 있습니다. 온프레미스 환경에서는 보안의 모든 측면을 책임지며 상속된 제어는 없습니다. 클라우드에서 워크로드를 실행할 때 AWS 는 서비스를 실행하는 인프라를 보호할 책임이 있습니다. 또한 자동화 및 관리형 서비스를 사용하여 규정 준수 부담을 줄일 수도 있습니다. *추상화된* 서비스라고도 AWS 서비스 하는 *관리*형 서비스는가 인프라 계층, 운영 체제 및 플랫폼을 AWS 운영하고 사용자가 엔드포인트에 액세스하여 데이터를 저장하고 검색할 수 있도록 합니다. 관리형 서비스의 예로 Amazon Simple Storage Service(Amazon S3) 및 Amazon DynamoDB가 있습니다. 자세한 내용은 이 설명서의 [테마 1: 관리형 서비스 사용](theme-1.md) 섹션을 참조하세요.
따라서 AWS의 워크로드에 적합한 Essential Eight 전략을 수립하려면 일부 재해석이 필요합니다. 이 가이드는 Essential Eight 전략을 AWS *테마*로 변환합니다.
## 테마 사용
이 가이드는 8가지 테마로 구분됩니다. 각 Essential Eight 전략은 다음 테마 중 하나 이상에 매핑되며, 각 테마는 AWS Well-Architected Framework의 하나 이상의 모범 사례에 매핑됩니다.
+ [테마 1: 관리형 서비스 사용](theme-1.md)
+ [테마 2: 보안 파이프라인을 통해 변경 불가능한 인프라 관리](theme-2.md)
+ [테마 3: 자동화를 통해 변경 가능한 인프라 관리](theme-3.md)
+ [테마 4: ID 관리](theme-4.md)
+ [테마 5: 데이터 경계 설정](theme-5.md)
+ [테마 6: 백업 자동화](theme-6.md)
+ [테마 7: 로깅 및 모니터링 중앙 집중화](theme-7.md)
+ [테마 8: 수동 프로세스에 대한 메커니즘 구현](theme-8.md)
각 테마에는 주제 개요, 관련 AWS Well-Architected Framework 모범 사례, Essential Eight 성숙도를 달성하고 규정 준수를 모니터링하는 방법에 대한 지침이 포함되어 있습니다. 이 지침은 수동 단계를 제공하거나 [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)을 사용하여 자동화를 구성하는 데 도움이 됩니다. 수동 단계에서는 조사 결과를 처리하기 위한 메커니즘이 필요합니다. 자세한 내용은 규정 미준수 리소스를 해결하기 위해 유사한 감독 또는 자동화가 필요한 [테마 8: 수동 프로세스에 대한 메커니즘 구현](theme-8.md). AWS Config rules를 참조하세요. [https://docs.aws.amazon.com/config/latest/developerguide/remediation.html](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 이러한 테마와 부합되는 지침을 따르면 클라우드 이점도 극대화하는 접근 방식을 통해 Essential Eight 성숙도에 도달할 수 있습니다.
## 클라우드에 대한 Essential Eight 전략의 재해석
Essential Eight 프레임워크는 클라우드 환경을 위해 설계되지 않았으므로 각 Essential Eight 전략의 기본 원칙을 처리할 때는 클라우드 네이티브 접근 방식을 취하는 것이 중요합니다. 접근 방식은 두 가지 주요 질문에 따라 달라집니다.
### 어떤 서비스를 사용하고 있나요?
[AWS 공동 책임 모델](australian-sec-compliance.md#shared-model)은 규정 준수 및 운영 부담을 완화하는 데 도움이 될 수 있습니다. 관리형 서비스는 배포된 서비스의 가용성, 성능 및 보안 최적화를 유지하는 데 AWS 더 많은 책임을 집니다. 또한 관리형 서비스를 사용하면 서비스를 유지 관리해야 하는 운영 및 관리 부담이 줄어들기 때문에 팀이 혁신에 더 많은 시간을 할애할 수 있습니다.
관리형 서비스로는 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html), [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)와 같은 서버리스 서비스가 포함됩니다. [Amazon Relational Database Service(Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)의 데이터베이스는 [Amazon Elastic Compute Cloud(Amazon EC2)](https://docs.aws.amazon.com/ec2/?icmpid=docs_homepage_compute)의 데이터베이스보다 운영 책임이 적습니다.
예를 들어 클라우드에 대한 *패치 운영 체제* Essential Eight 전략을 조정하는 경우 사용 중인 서비스와 해당 리소스에 패치를 적용할 책임이 있는지 고려해야 합니다. AWS 는 Lambda 및 DynamoDB와 같은 완전관리형 서비스 패치를 담당합니다. Amazon RDS 또는 [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html)와 같은 다른 서비스의 경우 유지 관리 기간에 패치를 관리해야 할 수 있습니다.
### 사용 중인 배포 모델은 무엇인가요?
조직에서 변경 가능 인프라 또는 변경 불가능 인프라 접근 방식을 사용하고 있나요?
*변경 가능한 인프라* 모델은 프로덕션 워크로드를 위해 기존 인프라를 업데이트하고 수정합니다.** ** 이는 서버 인프라를 교체하는 데 비용과 시간이 많이 드는 클라우드 이전의 표준 배포 방법으로, 프로덕션 환경에 이미 있는 서버에 변경 사항을 적용하는 것이 가장 실용적인 접근 방식이었습니다. 클라우드에서 변경 가능한 접근 방식의 예로, 수동으로 또는 [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) 또는 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)와 같은 소프트웨어 배포 서비스를 사용하여 실행 중인 EC2 인스턴스에 애플리케이션 변경 사항을 직접 배포하는 방법이 있습니다.
*변경 불가능한 인프라* 모델은 기존 인프라를 업데이트, 패치 또는 수정하는 대신 프로덕션 워크로드에 대한 새 인프라를 배포합니다. 변경할 수 없는 접근 방식의 예로, [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 또는 [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)에서 애플리케이션 스택을 정의하는 방법이 있습니다. 이러한 서비스를 사용하여 지속적 통합 및 지속적 전송(CI/CD) 파이프라인을 통해 애플리케이션 스택을 배포할 수 있습니다. 이 접근 방식은 *롤링* 또는 *블루/그린*과 같은 [배포 방법](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)을 사용합니다. 이 접근 방식에 대한 자세한 내용은 AWS Well-Architected Framework의 [변경 불가능한 인프라를 사용하여 배포](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_immutable_infrastructure.html) 모범 사례를 참조하세요.
예를 들어 클라우드에 대한 *운영 체제 패치* Essential Eight 전략을 조정하는 경우 패치 적용이 배포 모델에 어떻게 적용되는지 고려해야 합니다. 변경 가능한 인프라의 경우 리소스를 수동으로 패치하거나 자동화를 통해 운영 효율성을 개선할 수 있습니다. 변경 불가능한 인프라를 사용하는 경우 CI/CD 파이프라인을 사용하여 최신 버전의 운영 체제로 새 인프라를 배포합니다. 실제로 *패치 적용*이라는 용어는 이 모델에서 정확하진 않습니다. 패치가 아니라 인프라가 교체되기 때문입니다.