View a markdown version of this page

클라우드에 대한 Essential Eight 전략의 재해석 - AWS 권장 가이드

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

클라우드에 대한 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: 관리형 서비스 사용 섹션을 참조하세요.

따라서 AWS의 워크로드에 적합한 Essential Eight 전략을 수립하려면 일부 재해석이 필요합니다. 이 가이드는 Essential Eight 전략을 AWS 테마로 변환합니다.

테마 사용

이 가이드는 8가지 테마로 구분됩니다. 각 Essential Eight 전략은 다음 테마 중 하나 이상에 매핑되며, 각 테마는 AWS Well-Architected Framework의 하나 이상의 모범 사례에 매핑됩니다.

각 테마에는 주제 개요, 관련 AWS Well-Architected Framework 모범 사례, Essential Eight 성숙도를 달성하고 규정 준수를 모니터링하는 방법에 대한 지침이 포함되어 있습니다. 이 지침은 수동 단계를 제공하거나 AWS Config 규칙을 사용하여 자동화를 구성하는 데 도움이 됩니다. 수동 단계에서는 조사 결과를 처리하기 위한 메커니즘이 필요합니다. 자세한 내용은 규정 미준수 리소스를 해결하기 위해 유사한 감독 또는 자동화가 필요한 테마 8: 수동 프로세스에 대한 메커니즘 구현. AWS Config rules를 참조하세요. https://docs.aws.amazon.com/config/latest/developerguide/remediation.html 이러한 테마와 부합되는 지침을 따르면 클라우드 이점도 극대화하는 접근 방식을 통해 Essential Eight 성숙도에 도달할 수 있습니다.

클라우드에 대한 Essential Eight 전략의 재해석

Essential Eight 프레임워크는 클라우드 환경을 위해 설계되지 않았으므로 각 Essential Eight 전략의 기본 원칙을 처리할 때는 클라우드 네이티브 접근 방식을 취하는 것이 중요합니다. 접근 방식은 두 가지 주요 질문에 따라 달라집니다.

어떤 서비스를 사용하고 있나요?

AWS 공동 책임 모델은 규정 준수 및 운영 부담을 완화하는 데 도움이 될 수 있습니다. 관리형 서비스는 배포된 서비스의 가용성, 성능 및 보안 최적화를 유지하는 데 AWS 더 많은 책임을 집니다. 또한 관리형 서비스를 사용하면 서비스를 유지 관리해야 하는 운영 및 관리 부담이 줄어들기 때문에 팀이 혁신에 더 많은 시간을 할애할 수 있습니다.

관리형 서비스로는 Amazon API Gateway, AWS Lambda, DynamoDB와 같은 서버리스 서비스가 포함됩니다. Amazon Relational Database Service(Amazon RDS)의 데이터베이스는 Amazon Elastic Compute Cloud(Amazon EC2)의 데이터베이스보다 운영 책임이 적습니다.

예를 들어 클라우드에 대한 패치 운영 체제 Essential Eight 전략을 조정하는 경우 사용 중인 서비스와 해당 리소스에 패치를 적용할 책임이 있는지 고려해야 합니다. AWS 는 Lambda 및 DynamoDB와 같은 완전관리형 서비스 패치를 담당합니다. Amazon RDS 또는 Amazon Redshift와 같은 다른 서비스의 경우 유지 관리 기간에 패치를 관리해야 할 수 있습니다.

사용 중인 배포 모델은 무엇인가요?

조직에서 변경 가능 인프라 또는 변경 불가능 인프라 접근 방식을 사용하고 있나요?

변경 가능한 인프라 모델은 프로덕션 워크로드를 위해 기존 인프라를 업데이트하고 수정합니다. 이는 서버 인프라를 교체하는 데 비용과 시간이 많이 드는 클라우드 이전의 표준 배포 방법으로, 프로덕션 환경에 이미 있는 서버에 변경 사항을 적용하는 것이 가장 실용적인 접근 방식이었습니다. 클라우드에서 변경 가능한 접근 방식의 예로, 수동으로 또는 AWS Systems Manager Run Command 또는 AWS CodeDeploy와 같은 소프트웨어 배포 서비스를 사용하여 실행 중인 EC2 인스턴스에 애플리케이션 변경 사항을 직접 배포하는 방법이 있습니다.

변경 불가능한 인프라 모델은 기존 인프라를 업데이트, 패치 또는 수정하는 대신 프로덕션 워크로드에 대한 새 인프라를 배포합니다. 변경할 수 없는 접근 방식의 예로, AWS CloudFormation 또는 AWS Cloud Development Kit (AWS CDK)에서 애플리케이션 스택을 정의하는 방법이 있습니다. 이러한 서비스를 사용하여 지속적 통합 및 지속적 전송(CI/CD) 파이프라인을 통해 애플리케이션 스택을 배포할 수 있습니다. 이 접근 방식은 롤링 또는 블루/그린과 같은 배포 방법을 사용합니다. 이 접근 방식에 대한 자세한 내용은 AWS Well-Architected Framework의 변경 불가능한 인프라를 사용하여 배포 모범 사례를 참조하세요.

예를 들어 클라우드에 대한 운영 체제 패치 Essential Eight 전략을 조정하는 경우 패치 적용이 배포 모델에 어떻게 적용되는지 고려해야 합니다. 변경 가능한 인프라의 경우 리소스를 수동으로 패치하거나 자동화를 통해 운영 효율성을 개선할 수 있습니다. 변경 불가능한 인프라를 사용하는 경우 CI/CD 파이프라인을 사용하여 최신 버전의 운영 체제로 새 인프라를 배포합니다. 실제로 패치 적용이라는 용어는 이 모델에서 정확하진 않습니다. 패치가 아니라 인프라가 교체되기 때문입니다.