

# 데이터 보호
<a name="data-protection"></a>

워크로드를 설계하려면 먼저 보안과 관련된 기본적인 관행부터 마련해야 합니다. 예를 들어 데이터 분류는 민감도에 따라 데이터를 구분하는 하나의 방법이고 암호화는 무단 액세스 사용자가 데이터를 해석하지 못하게 만들어 데이터를 보호하는 방법입니다. 이러한 방법이 중요한 이유는, 조작 부주의 방지 또는 규제 의무 사항 준수와 같은 목표의 달성을 지원하기 때문입니다.

AWS에서는 데이터 보호를 수행할 때 사용할 수 있는 여러 가지 방식이 있습니다. 다음 섹션에서는 이러한 접근 방식을 사용하는 방법을 설명합니다.

**Topics**
+ [데이터 분류](data-classification.md)
+ [저장 데이터 보호](protecting-data-at-rest.md)
+ [전송 중 데이터 보호](protecting-data-in-transit.md)

# 데이터 분류
<a name="data-classification"></a>

데이터 분류는 적절한 보호 및 보존 제어를 결정하는 데 도움이 되도록 중요도를 기준으로 조직 데이터를 분류하는 방법을 제공합니다.

**Topics**
+ [SEC07-BP01 데이터 분류 체계 이해](sec_data_classification_identify_data.md)
+ [SEC07-BP02 데이터 민감도에 따라 데이터 보호 제어 적용](sec_data_classification_define_protection.md)
+ [SEC07-BP03 식별 및 분류 자동화](sec_data_classification_auto_classification.md)
+ [SEC07-BP04 확장 가능한 데이터 수명 주기 관리 정의](sec_data_classification_lifecycle_management.md)

# SEC07-BP01 데이터 분류 체계 이해
<a name="sec_data_classification_identify_data"></a>

 워크로드에서 처리 중인 데이터의 분류, 처리 요구 사항, 관련 비즈니스 프로세스, 데이터가 저장되는 위치, 데이터 소유자가 누구인지 이해하세요.  데이터 분류 및 처리 체계는 워크로드의 적용 가능한 법률 및 규정 준수 요구 사항과 필요한 데이터 제어 기능을 고려해야 합니다. 데이터를 이해해야 데이터 분류 여정을 시작할 수 있습니다.  

 **원하는 성과:** 워크로드에 있는 데이터 유형이 잘 이해되고 문서화되어 있습니다.  분류에 따라 민감한 데이터를 보호하기 위한 적절한 제어 조치가 마련되어 있습니다.  이러한 제어 기능은 누가 어떤 목적으로 데이터에 액세스할 수 있는지는 물론 데이터가 저장되는 위치, 해당 데이터에 대한 암호화 정책 및 암호화 키가 관리되는 방식, 데이터의 수명 주기 및 보존 요구 사항, 적절한 폐기 프로세스, 마련된 백업 및 복구 프로세스, 액세스 감사와 같은 고려 사항을 관리합니다.

 **일반적인 안티 패턴:** 
+  데이터 민감도 수준과 처리 요구 사항을 정의하는 공식적인 데이터 분류 정책이 마련되어 있지 않습니다.
+  워크로드 내 데이터의 민감도 수준을 제대로 이해하지 못하고 아키텍처 및 운영 문서에 해당 정보를 포함하지 않습니다.
+  데이터 분류 및 처리 정책에 명시된 대로 데이터의 민감도 및 요구 사항을 기반으로 데이터에 적절한 제어 기능을 적용하지 않습니다.
+  정책 소유자에게 데이터 분류 및 처리 요구 사항에 대한 피드백을 제공하지 않습니다.

 **이 모범 사례 확립의 이점:** 이 방법을 사용하면 워크로드 내에서 데이터의 적절한 처리와 관련된 모호성이 사라집니다.  조직 내 데이터의 민감도 수준과 필수 보호 조치를 정의하는 공식 정책을 적용하면 법규와 기타 사이버 보안 증명 및 인증을 준수하는 데 도움이 될 수 있습니다.  워크로드 소유자는 민감한 데이터가 어디에 저장되고 어떤 보호 제어 기능이 적용되는지 알고 안심할 수 있습니다.  이러한 내용을 문서화하면 신입 팀원의 이해도를 높이고 업무를 배정받은 초반에도 제어 수준을 유지하도록 도울 수 있습니다. 그리고 각 데이터 유형에 대한 제어 규모를 적절하게 조정하여 비용을 절감하는 데도 도움이 될 수 있습니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드를 설계할 때 민감한 데이터를 직관적으로 보호하는 방법을 고려할 수 있습니다.  예를 들어, 다중 테넌트 애플리케이션에서는 직관적으로 각 테넌트의 데이터를 민감한 것으로 생각하고 한 테넌트가 다른 테넌트의 데이터에 액세스할 수 없도록 보호 기능을 적용합니다.  마찬가지로 관리자만 데이터를 수정할 수 있고 다른 사용자는 읽기 수준의 액세스 권한만 가지거나 전혀 액세스할 수 없도록 액세스 제어를 직관적으로 설계할 수 있습니다.

 이러한 데이터 민감도 수준을 데이터 보호 요구 사항과 함께 정의하고 정책에 포함하면 워크로드에 있는 데이터를 공식적으로 식별할 수 있습니다. 그런 다음 올바른 제어 기능이 있는지, 이를 감사할 수 있는지, 데이터가 잘못 처리되는 경우 어떻게 대응해야 적절한지 결정할 수 있습니다.

 워크로드 내에서 민감한 데이터가 있는 위치를 식별하는 데 도움이 되도록 데이터 카탈로그를 사용하는 것이 좋습니다. 데이터 카탈로그는 조직의 데이터, 위치, 민감도 수준 및 해당 데이터를 보호하기 위해 마련된 제어를 매핑하는 데이터베이스입니다. 또한 가능한 경우 [리소스 태그](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)를 사용하는 것도 고려해 보세요.  예를 들어, 보호 의료 정보(PHI)에서 `Classification`의 *태그 키*와 `PHI`의 *태그 값*이 있는 태그 그리고 `Sensitivity`의 *태그 키*와 `High`의 *태그 값*이 있는 다른 태그를 적용할 수 있습니다.  그런 다음 [AWS Config](https://aws.amazon.com/config/)와 같은 서비스를 사용하여 리소스에서 변경 여부를 모니터링하고 보호 요구 사항을 준수하지 못하게 하는 방식으로 수정된 경우(예: 암호화 설정 변경) 알림을 보낼 수 있습니다.  AWS Organizations의 기능인 [태그 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)을 사용하여 태그 키의 표준 정의와 허용 가능한 값을 캡처할 수 있습니다. 태그 키 또는 값에 개인 데이터나 민감한 데이터는 포함하지 않는 것이 좋습니다.

### 구현 단계
<a name="implementation-steps"></a>

1.  조직의 데이터 분류 체계 및 보호 요구 사항을 이해합니다.

1.  워크로드에서 처리하는 민감한 데이터의 유형을 식별합니다.

1.  조직에서 데이터가 있는 위치와 해당 데이터의 민감도 수준에 대한 단일 보기를 제공하는 데이터 카탈로그에서 데이터를 캡처합니다.

1.  가능한 경우 리소스 및 데이터 수준 태그 지정을 사용하여 민감도 수준과 모니터링 및 인시던트 대응에 도움이 될 수 있는 기타 운영 메타데이터로 데이터에 태그를 지정하는 것을 고려해 보세요.

   1.   AWS Organizations 태그 정책은 태그 지정 표준을 적용하는 데 사용할 수 있습니다.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [SUS04-BP01 데이터 분류 정책 구현](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_data_a2.html) 

 **관련 문서:** 
+  [Data Classification 백서](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-overview.html) 
+  [Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) 

 **관련 예제:** 
+  [AWS Organizations Tag Policy Syntax and Examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_example-tag-policies.html) 

 **관련 도구** 
+  [AWS Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) 

# SEC07-BP02 데이터 민감도에 따라 데이터 보호 제어 적용
<a name="sec_data_classification_define_protection"></a>

 분류 정책에 정의된 각 데이터 클래스에 대해 적절한 수준의 제어를 제공하는 데이터 보호 제어 기능을 적용합니다.  이렇게 하면 데이터의 가용성과 사용을 유지하면서 민감한 데이터를 무단 액세스 및 사용으로부터 보호할 수 있습니다.

 **원하는 성과:** 조직의 데이터에 대한 다양한 민감도 수준을 정의하는 분류 정책이 있습니다.  이러한 민감도 수준 각각에 대해 승인된 보관 및 취급 서비스, 위치 및 필수 구성과 관련하여 명확한 지침이 게시되어 있습니다.  필요한 보호 수준 및 관련 비용에 따라 각 수준에 대해 제어 기능을 구현합니다.  데이터가 승인되지 않은 위치에 존재하거나, 무허가 환경에서 처리되거나, 무단 행위자가 액세스하거나, 관련 서비스의 구성이 규정을 준수하지 않는 경우 등을 탐지할 수 있는 모니터링 및 알림 기능을 갖추고 있습니다.

 **일반적인 안티 패턴:** 
+  모든 데이터에 동일한 수준의 보호 제어 기능을 적용합니다. 이로 인해 민감도가 낮은 데이터에 대한 보안 제어가 과도하게 프로비저닝되거나 매우 민감한 데이터에 대한 보호가 불충분해질 수 있습니다.
+  데이터 보호 제어를 정의할 때 보안, 규정 준수 및 비즈니스 팀의 관련 이해관계자를 참여시키지 않습니다.
+  데이터 보호 제어의 구현 및 유지 관리와 관련된 운영 오버헤드 및 비용을 간과합니다.
+  분류 정책을 준수하기 위해 정기적인 데이터 보호 제어 검토를 수행하지 않습니다.
+  저장 상태일 때와 전송 중에 데이터의 위치에 대한 완전한 인벤토리가 없습니다.

 **이 모범 사례 확립의 이점:** 데이터 분류 수준에 맞게 제어를 조정하면 조직은 필요한 경우 더 높은 수준의 제어에 투자할 수 있습니다. 여기에는 보안, 모니터링, 측정, 문제 해결 및 보고에 대한 리소스 확충이 포함될 수 있습니다.  적절한 제어 수단이 적을수록 직원, 고객 또는 구성원을 위한 데이터의 접근성과 완전성을 개선할 수 있습니다.  이 접근 방식을 통해 조직은 데이터 보호 요구 사항을 준수하면서 데이터를 최대한 유연하게 사용할 수 있습니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 데이터 민감도 수준을 기반으로 데이터 보호 제어 기능을 구현하려면 몇 가지 주요 단계를 거쳐야 합니다. 먼저 워크로드 아키텍처 내의 다양한 데이터 민감도 수준(예: 공개, 내부, 기밀, 제한)을 식별하고 이 데이터를 저장하고 처리하는 위치를 평가합니다. 다음으로 민감도 수준에 따라 데이터 주변의 격리 경계를 정의합니다. [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCP)을 통해 데이터 민감도 수준별로 허용되는 서비스 및 작업을 제한하여 데이터를 서로 다른 AWS 계정 계정으로 분리하는 것이 좋습니다. 이렇게 하면 강력한 격리 경계를 만들고 최소 권한 원칙을 적용할 수 있습니다.

 격리 경계를 정의한 후 데이터 민감도 수준에 따라 적절한 보호 제어 기능을 구현합니다. 암호화, 액세스 제어 및 감사와 같은 관련 제어 기능을 구현하려면 [저장 데이터 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-data-at-rest.html) 및 [전송 중 데이터 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-data-in-transit.html)에 대한 모범 사례를 참조하세요. 토큰화나 익명화와 같은 기법을 고려하여 데이터의 민감도를 낮춥니다. 토큰화 및 탈토큰화를 위한 중앙 집중식 시스템을 통해 기업 전체에 일관된 데이터 정책을 간편하게 적용할 수 있습니다.

 구현된 제어 기능의 효과를 지속적으로 모니터링하고 테스트합니다. 진화하는 조직 데이터 환경과 위협에 발맞춰 데이터 분류 체계, 위험 평가 및 보호 제어 기능을 정기적으로 검토하고 업데이트하세요. 구현된 데이터 보호 제어 기능을 관련 산업 규제, 표준 및 법적 요구 사항에 맞게 조정합니다. 또한, 직원이 데이터 분류 체계와 민감한 데이터의 취급 및 보호에 대한 책임을 이해할 수 있도록 보안 인식 및 교육을 제공합니다.

### 구현 단계
<a name="implementation-steps"></a>

1.  워크로드 내 데이터의 분류 및 민감도 수준을 식별합니다.

1.  각 수준에 대한 격리 경계를 정의하고 시행 전략을 결정합니다.

1.  액세스, 암호화, 감사, 보존 및 데이터 분류 정책에 필요한 기타 사항을 관리하기 위해 정의한 제어 기능을 평가합니다.

1.  적절한 경우 토큰화 또는 익명화 사용 등 데이터의 민감도 수준을 낮추는 옵션을 평가합니다.

1.  구성된 리소스의 자동화된 테스트 및 모니터링을 사용하여 제어 기능을 확인합니다.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [PERF03-BP01 데이터 액세스 및 스토리지 요구 사항을 가장 잘 지원하는 목적별 데이터 스토어 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_data_use_purpose_built_data_store.html) 
+  [COST04-BP05 데이터 보존 정책 적용](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_decomissioning_resources_data_retention.html) 

 **관련 문서:** 
+  [Data Classification 백서](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [보안, 자격 증명 및 규정 준수를 위한 모범 사례](https://aws.amazon.com/architecture/security-identity-compliance/?cards-all.sort-by=item.additionalFields.sortDate&cards-all.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all) 
+  [AWS KMS 모범 사례](https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html) 
+  [Encryption best practices and features for AWS services](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/welcome.html) 

 **관련 예제:** 
+  [Building a serverless tokenization solution to mask sensitive data](https://aws.amazon.com/blogs/compute/building-a-serverless-tokenization-solution-to-mask-sensitive-data/) 
+  [How to use tokenization to improve data security and reduce audit scope](https://aws.amazon.com/blogs/security/how-to-use-tokenization-to-improve-data-security-and-reduce-audit-scope/) 

 **관련 도구:** 
+  [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) 
+  [AWS CloudHSM](https://aws.amazon.com/cloudhsm/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 

# SEC07-BP03 식별 및 분류 자동화
<a name="sec_data_classification_auto_classification"></a>

 데이터 식별 및 분류를 자동화하면 올바른 제어를 구현하는 데 도움이 될 수 있습니다. 자동화를 사용하여 수동 결정을 보강하면 인적 오류 및 노출의 위험을 줄일 수 있습니다.

 **원하는 성과:** 분류 및 취급 정책에 따라 적절한 통제가 마련되어 있는지 확인할 수 있습니다. 자동화된 도구 및 서비스는 데이터의 민감도 수준을 식별하고 분류하는 데 도움이 됩니다.  나아가 자동화를 통해 환경을 지속적으로 모니터링하여 데이터가 무단으로 저장되거나 처리되는 경우 이를 감지하고 알림을 보내 시정 조치를 신속하게 취할 수 있습니다.

 **일반적인 안티 패턴:** 
+  데이터 식별 및 분류를 위한 수동 프로세스에만 의존하므로, 오류가 발생하기 쉽고 시간이 많이 걸릴 수 있습니다.  이로 인해 특히 데이터 볼륨이 증가하면 데이터 분류의 효율성과 일관성이 떨어질 수 있습니다.
+  조직 전체에 걸쳐 데이터 자산을 추적하고 관리하는 메커니즘이 없습니다.
+  조직 내에서 이동하고 변화하는 데이터를 지속적으로 모니터링하고 분류해야 할 필요성을 간과합니다.

 **이 모범 사례 확립의 이점:** 데이터 식별 및 분류를 자동화하면 데이터 보호 제어를 보다 일관되고 정확하게 적용하여 인적 오류의 위험을 줄일 수 있습니다.  자동화는 또한 민감한 데이터 액세스 및 이동에 대한 가시성을 제공하여 무단 처리를 탐지하고 시정 조치를 취하는 데 도움이 됩니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드의 초기 설계 단계에서 데이터를 분류할 때는 사람이 판단하는 경우가 많지만, 예방 차원에서 테스트 데이터의 식별 및 분류를 자동화하는 시스템을 마련하는 것을 고려해 보세요. 예를 들어, 개발자에게 대표 데이터를 스캔하여 민감도를 결정하는 도구나 서비스를 제공할 수 있습니다.  AWS에서 [Amazon S3](https://aws.amazon.com/s3/)에 데이터세트를 업로드하고 [Amazon Macie](https://aws.amazon.com/macie/), [Amazon Comprehend](https://aws.amazon.com/comprehend/) 또는 [Amazon Comprehend Medical](https://aws.amazon.com/comprehend/medical/)을 사용하여 스캔할 수 있습니다.   마찬가지로 단위 및 통합 테스트의 일환으로 데이터를 스캔하여 민감한 데이터가 예상되지 않는 부분을 찾아내는 것도 고려해 보세요. 이 단계에서 민감한 데이터에 대한 알림을 통해 프로덕션에 배포하기 전에 보호의 허점을 강조할 수 있습니다. [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/detect-PII.html), [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-message-data-protection-managed-data-identifiers.htm), [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)에서 민감한 데이터 탐지와 같은 기타 기능을 사용하여 PII를 탐지하고 완화 조치를 수행할 수도 있습니다. 자동화된 도구 또는 서비스의 경우, 민감한 데이터를 정의하는 방법을 이해하고 필요에 따라 다른 사람이나 자동화된 솔루션으로 이를 보강하여 허점을 메우세요.

 탐지 제어 기능으로 환경을 지속적으로 모니터링하여 민감한 데이터가 규정을 준수하지 않는 방식으로 저장되고 있는지 탐지하세요.  이를 통해 민감한 데이터가 로그 파일로 내보내지거나, 적절히 식별되지 않거나 수정되지 않고 데이터 분석 환경으로 복사되는 등의 상황을 탐지할 수 있습니다.  Amazon S3에 저장된 데이터는 Amazon Macie를 사용하여 민감한 데이터가 있는지 지속적으로 모니터링할 수 있습니다.  

### 구현 단계
<a name="implementation-steps"></a>

1.  [SEC07-BP01](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_data_classification_identify_data.html)에 설명된 조직 내 데이터 분류 체계를 검토합니다.

   1.  조직의 데이터 분류 체계를 이해하면 회사 정책에 맞는 자동 식별 및 분류를 위한 정확한 프로세스를 수립할 수 있습니다.

1.  자동 식별 및 분류를 위해 환경에 대한 초기 스캔을 수행합니다.

   1.  초기에 데이터를 전체적으로 스캔하면 민감한 데이터가 사용자 환경의 어디에 있는지 포괄적으로 이해하는 데 도움이 될 수 있습니다. 처음에 전체 스캔이 필요하지 않거나 비용 때문에 미리 완료할 수 없다면 데이터 샘플링 기술이 성과를 달성하는 데 적합한지 평가하세요. 예를 들어, Amazon Macie를 사용하여 S3 버킷에서 광범위하고 자동화된 민감한 데이터 검색 작업을 수행하도록 구성할 수 있습니다.  이 기능은 샘플링 기술을 사용하여 민감한 데이터가 있는 위치에 대한 예비 분석을 비용 효율적으로 수행합니다.  그런 다음 민감한 데이터 검색 작업을 사용하여 S3 버킷에 대한 심층 분석을 수행할 수 있습니다. 다른 데이터 스토어를 S3로 내보내 Macie에서 스캔할 수도 있습니다.

   1.  스캔으로 식별된 데이터 스토리지 리소스에 대해 [SEC07-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_data_classification_define_protection.html)에 정의된 액세스 제어를 설정합니다.

1.  환경에 대한 지속적인 스캔을 구성합니다.

   1.  Macie의 자동화된 중요 데이터 검색 기능을 사용하여 환경을 지속적으로 스캔할 수 있습니다.  민감한 데이터를 저장할 권한이 있는 알려진 S3 버킷은 Macie의 허용 목록을 사용하여 제외할 수 있습니다.

1.  식별 및 분류를 구축 및 테스트 프로세스에 통합합니다.

   1.  워크로드가 개발 중인 동안 개발자가 데이터의 민감도를 스캔하는 데 사용할 수 있는 도구를 식별합니다.  이러한 도구를 통합 테스트의 일부로 사용하여 민감한 데이터가 예상되지 않는 경우 이를 알리고 추가 배포를 방지할 수 있습니다.

1.  승인되지 않은 위치에서 민감한 데이터가 발견될 경우 조치를 취할 수 있는 시스템 또는 런북을 구현합니다.

   1.  자동 수정을 사용하여 데이터에 대한 액세스를 제한합니다. 예를 들어, 속성 기반 액세스 제어(ABAC)를 사용하는 경우 이 데이터를 액세스가 제한된 S3 버킷으로 이동하거나 객체에 태그를 지정할 수 있습니다. 또한 데이터가 감지될 때 마스킹하는 것도 고려해 보세요.

   1.  데이터 보호 및 인시던트 대응 팀에 알려 인시던트의 근본 원인을 조사합니다. 이들이 찾아내는 모든 교훈은 향후 인시던트를 방지하는 데 도움이 될 수 있습니다.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Glue: Detect and process sensitive data](https://docs.aws.amazon.com/glue/latest/dg/detect-PII.html) 
+  [Using managed data identifiers in Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-message-data-protection-managed-data-identifiers.html) 
+  [Amazon CloudWatch Logs: Help protect sensitive log data with masking](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html) 

 **관련 예제:** 
+  [Enabling data classification for Amazon RDS database with Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/) 
+  [Detecting sensitive data in DynamoDB with Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) 

 **관련 도구:** 
+  [Amazon Macie](https://aws.amazon.com/macie/) 
+  [Amazon Comprehend](https://aws.amazon.com/comprehend/) 
+  [Amazon Comprehend Medical](https://aws.amazon.com/comprehend/medical/) 
+  [AWS Glue](https://aws.amazon.com/glue/) 

# SEC07-BP04 확장 가능한 데이터 수명 주기 관리 정의
<a name="sec_data_classification_lifecycle_management"></a>

 다양한 수준의 데이터 분류 및 처리와 관련된 데이터 수명 주기 요구 사항을 파악하세요.  여기에는 데이터가 환경에 처음 유입되었을 때 데이터를 처리하는 방법, 데이터가 변환되는 방식, 데이터 폐기 규칙이 포함될 수 있습니다. 보존 기간, 액세스, 감사, 출처 추적과 같은 요소를 고려하세요.

 **원하는 성과:** 데이터를 수집 시점 및 시간에 최대한 가깝게 분류합니다. 데이터 분류에 마스킹, 토큰화 또는 민감도 수준을 낮추는 기타 프로세스가 필요한 경우 수집 시점과 시간에 최대한 가깝게 작업을 수행하세요.

 더 이상 보관하기에 적절하지 않은 경우 정책에 따라 분류를 기반으로 데이터를 삭제합니다.

 **일반적인 안티 패턴:** 
+  다양한 민감도 수준과 액세스 요구 사항을 고려하지 않고 데이터 수명 주기 관리에 대한 획일적인 접근 방식을 구현합니다.
+  사용 가능한 데이터 또는 백업된 데이터의 관점에서만 수명 주기 관리를 고려하고, 모두 고려하지 않습니다.
+  가치나 출처를 확인하지 않고 워크로드에 입력된 데이터가 유효하다고 가정합니다.
+  데이터 백업 및 보호 대신 데이터 내구성에 의존합니다.
+  유용성 및 필수 보존 기간을 초과하여 데이터를 보존합니다.

 **이 모범 사례 확립의 이점:** 잘 정의되고 확장 가능한 데이터 수명 주기 관리 전략은 적절한 제어를 유지하면서 규제를 계속해서 준수하고, 데이터 보안을 개선하며, 스토리지 비용을 최적화하는 데 도움을 줄 수 있습니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드 내의 데이터는 동적인 경우가 많습니다.  워크로드 환경에 유입될 때 취하는 형태는 비즈니스 로직, 보고, 분석 또는 기계 학습에 저장되거나 사용될 때와 다를 수 있습니다.  또한, 데이터의 가치는 시간이 지남에 따라 변할 수 있습니다. 일부 데이터는 본질적으로 일시적이며, 오래될수록 가치를 잃습니다.  데이터에 대한 이러한 변경이 데이터 분류 체계 및 관련 제어에 따른 평가에 어떤 영향을 미치는지 생각해 보세요.  가능한 경우 [Amazon S3 수명 주기 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) 및 [Amazon Data Lifecycle Manager](https://aws.amazon.com/ebs/data-lifecycle-manager/)와 같은 자동화된 수명 주기 메커니즘을 사용하여 데이터 보존, 아카이빙 및 만료 프로세스를 구성합니다. DynamoDB에 저장된 데이터의 경우 [Time To Live(TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) 기능을 사용하여 항목별 만료 타임스탬프를 정의할 수 있습니다.  

 사용할 수 있는 데이터와 백업으로 저장된 데이터를 구분합니다.  AWS 서비스 전반의 데이터 백업을 자동화하기 위해 [AWS Backup](https://aws.amazon.com/backup/) 사용을 고려하세요.  [Amazon EBS 스냅샷](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html)은 수명 주기, 데이터 보호, 보호 메커니즘에 대한 액세스를 비롯한 S3 기능을 사용하여 EBS 볼륨을 복사하고 저장하는 방법을 제공합니다. 이 두 가지 메커니즘은 [S3 객체 잠금](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) 및 [AWS Backup 볼트 잠금](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)으로, 이를 통해 백업에 대한 추가적인 보안 및 제어를 제공할 수 있습니다. 백업에 대한 업무와 액세스 권한을 명확하게 구분하여 관리합니다. 계정 수준에서 백업을 격리하여 이벤트 발생 시 영향을 받는 환경으로부터 분리할 수 있습니다.

 수명 주기 관리의 또 다른 측면은 워크로드가 진행되는 동안 데이터 내역을 기록하는 것입니다. 이를 *데이터 출처 추적*이라고 합니다. 따라서 데이터의 출처, 수행한 변환, 변경한 소유자 또는 프로세스, 변경 시기를 확실하게 알 수 있습니다.  이 기록이 있으면 잠재적 보안 이벤트 발생 시 문제 해결 및 조사에 도움이 됩니다.  예를 들어 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 테이블에 변환에 대한 메타데이터를 로깅할 수 있습니다.  데이터 레이크 내에서 각 데이터 파이프라인 단계의 서로 다른 S3 버킷에 변환된 데이터의 복사본을 보관할 수 있습니다. [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)에 스키마와 타임스탬프 정보를 저장합니다.  그리고 솔루션에 관계없이 최종 사용자의 요구 사항을 고려하여 데이터 출처를 보고하는 데 필요한 적절한 도구를 결정하세요.  이렇게 하면 출처를 가장 잘 추적하는 방법을 결정하는 데 도움이 됩니다.

### 구현 단계
<a name="implementation-steps"></a>

1.  워크로드의 데이터 유형, 민감도 수준 및 액세스 요구 사항을 분석하여 데이터를 분류하고 적절한 수명 주기 관리 전략을 정의합니다.

1.  법률, 규제 및 조직 요구 사항에 맞는 데이터 보존 정책 및 자동 폐기 프로세스를 설계하고 구현합니다.

1.  변화하는 워크로드 요구 사항 및 규제 변화에 맞춰 데이터 수명 주기 관리 전략, 제어, 정책을 지속적으로 모니터링, 감사 및 조정하기 위한 프로세스와 자동화를 수립합니다.

   1.  [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/s3-lifecycle-policy-check.html)를 사용하여 자동 수명 주기 관리가 활성화되지 않은 리소스 감지 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [COST04-BP05 데이터 보존 정책 적용](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_decomissioning_resources_data_retention.html) 
+  [SUS04-BP03 정책을 사용하여 데이터세트의 수명 주기 관리](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_data_a4.html) 

 **관련 문서:** 
+  [Data Classification 백서](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-overview.html) 
+  [AWS Blueprint for Ransomware Defense](https://d1.awsstatic.com/whitepapers/compliance/AWS-Blueprint-for-Ransomware-Defense.pdf) 
+  [DevOps Guidance: Improve traceability with data provenance tracking](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/ag.dlm.8-improve-traceability-with-data-provenance-tracking.html) 

 **관련 예제:** 
+  [How to protect sensitive data for its entire lifecycle in AWS](https://aws.amazon.com/blogs/security/how-to-protect-sensitive-data-for-its-entire-lifecycle-in-aws/) 
+  [Build data lineage for data lakes using AWS Glue, Amazon Neptune, and Spline](https://aws.amazon.com/blogs/big-data/build-data-lineage-for-data-lakes-using-aws-glue-amazon-neptune-and-spline/) 

 **관련 도구:** 
+  [AWS Backup](https://aws.amazon.com/backup/) 
+  [Amazon Data Lifecycle Manager](https://aws.amazon.com/ebs/data-lifecycle-manager/) 
+  [AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/access-analyzer/) 

# 저장 데이터 보호
<a name="protecting-data-at-rest"></a>

*저장 데이터*란 워크로드의 어느 기간에서든지 비휘발성 스토리지에 지속되는 모든 데이터를 의미합니다. 여기에는 블록 스토리지, 객체 스토리지, 데이터베이스, 아카이브, IoT 디바이스 그리고 데이터가 지속되는 모든 기타 스토리지 미디어가 포함됩니다. 저장 데이터를 보호하여 암호화 및 적절한 액세스 제어가 구현될 경우 무단 액세스 위험이 감소합니다.

암호화와 토큰화는 둘 모두 중요한 데이터 보호 체계이나 별개의 개념입니다.

*토큰화*는 사용자 신용 카드 정보와 같이 중요한 정보를 나타내는 토큰을 정의할 수 있는 프로세스입니다. 토큰 자체는 아무 의미가 없어야 하며, 토큰화하는 데이터에서 파생되어서는 안 됩니다. 따라서 암호화 다이제스트를 토큰으로 사용할 수 없습니다. 토큰화 방식을 신중하게 계획하면 콘텐츠를 추가로 보호할 수 있으며 규정 준수 요구 사항을 충족할 수 있습니다. 예를 들어 신용 카드 번호 대신 토큰을 활용하는 경우 신용 카드 처리 시스템의 규정 준수 범위를 줄일 수 있습니다.

*암호화*는 콘텐츠를 다시 일반 텍스트로 해독하는 데 필요한 비밀 키가 없으면 읽을 수 없는 방식으로 콘텐츠를 변환하는 방식입니다. 토큰화 및 암호화를 사용하면 정보를 효과적으로 보호할 수 있습니다. 또한 마스킹은 중요하지 않은 것으로 간주되는 데이터만 남을 때까지 데이터의 일부를 수정할 수 있는 기술입니다. 예를 들어 PCI-DSS를 사용하면 카드 번호의 마지막 네 자리가 인덱싱을 위한 규정 준수 범위 경계를 벗어나도록 할 수 있습니다.

**암호화 키 사용 감사:** 암호화 키 사용을 이해하고 감사하여 키에 대한 액세스 제어 메커니즘이 적절하게 구현되었는지 검증합니다. 예를 들어 AWS KMS 키를 사용하는 AWS 서비스는 AWS CloudTrail에서 모든 사용 사례를 로깅합니다. Amazon CloudWatch 로그 인사이트와 같은 도구를 사용하여 AWS CloudTrail을 쿼리함으로써 모든 키 사용이 유효한지 확인할 수 있습니다.

**Topics**
+ [SEC08-BP01 보안 키 관리 구현](sec_protect_data_rest_key_mgmt.md)
+ [SEC08-BP02 저장 시 암호화 적용](sec_protect_data_rest_encrypt.md)
+ [SEC08-BP03 저장 데이터 보호 자동화](sec_protect_data_rest_automate_protection.md)
+ [SEC08-BP04 액세스 제어 적용](sec_protect_data_rest_access_control.md)

# SEC08-BP01 보안 키 관리 구현
<a name="sec_protect_data_rest_key_mgmt"></a>

 보안 키 관리에는 워크로드의 저장 데이터를 보호하는 데 필요한 키 구성 요소의 저장, 순환, 액세스 제어 및 모니터링이 포함됩니다.

 **원하는 성과:** 확장 가능하고 반복 가능하며 자동화된 키 관리 메커니즘이 있습니다. 메커니즘이 키 구성 요소에 대한 액세스 권한을 최소한으로 제한하고 키 가용성, 기밀성 및 무결성 간에 적절한 균형을 유지합니다. 키에 대한 액세스를 모니터링하고 키 구성 요소의 교체가 필요한 경우 자동화된 프로세스를 사용하여 키를 교체합니다. 인간 작업자가 키 구성 요소에 액세스하도록 허용하지 않습니다.

**일반적인 안티 패턴:** 
+  암호화되지 않은 키 구성 요소에 대한 인적 접근이 가능합니다.
+  사용자 지정 암호화 알고리즘을 생성합니다.
+  키 구성 요소에 액세스할 수 있는 권한이 지나치게 광범위합니다.

 **이 모범 사례 확립의 이점:** 워크로드에 대한 보안 키 관리 메커니즘을 구축하면 무단 액세스로부터 콘텐츠를 보호하는 데 도움이 될 수 있습니다. 또한 데이터를 암호화하기 위한 규제 요구 사항이 적용될 수 있습니다. 효과적인 키 관리 솔루션은 키 구성 요소를 보호하기 위해 해당 규정에 맞는 기술적 메커니즘을 제공할 수 있습니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 지침
<a name="implementation-guidance"></a>

 저장 데이터의 암호화는 기본적인 보안 제어입니다. 이러한 제어를 구현하려면 워크로드에 저장 데이터를 암호화하는 데 사용되는 키 구성 요소를 안전하게 저장하고 관리하는 메커니즘이 필요합니다.

 AWS는 AWS Key Management Service(AWS KMS)를 제공하여 내구성이 뛰어나고 안전하며 중복된 AWS KMS 키 스토리지를 제공합니다. [많은 AWS 서비스가 AWS KMS](https://aws.amazon.com/kms/features/#integration)에 통합되어 데이터 암호화를 지원합니다. AWS KMS에서는 FIPS 140-3 레벨 3 검증 하드웨어 보안 모듈을 사용하여 키를 보호합니다. AWS KMS 키를 일반 텍스트로 내보내는 메커니즘은 없습니다.

 다중 계정 전략을 사용하여 워크로드를 배포할 때 AWS KMS 키를 사용하는 워크로드와 동일한 계정에 키를 유지해야 합니다. [이 분산 모델](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/application.html#app-kms)에서는 AWS KMS 키 관리에 대한 책임이 사용자의 팀에 있습니다. 다른 사용 사례에서는 조직에서 AWS KMS 키를 중앙 집중식 계정에 저장하도록 선택할 수 있습니다. 이 중앙 집중식 구조에는 워크로드 계정이 중앙 집중식 계정에 저장된 키에 액세스하는 데 필요한 크로스 계정 액세스를 가능하게 하는 추가 정책이 필요하지만 단일 키를 여러 AWS 계정에서 공유하는 사용 사례에서는 더 적합할 수 있습니다.

 키 구성 요소의 보관 위치와 관계없이 [키 정책](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) 및 IAM 정책을 사용하여 키에 대한 액세스를 엄격하게 제어해야 합니다. 키 정책은 AWS KMS 키에 대한 액세스를 제어하는 기본 방법입니다. 또한 AWS KMS 키 부여는 사용자를 대신하여 데이터를 암호화 및 복호화하는 AWS 서비스에 대한 액세스를 제공할 수 있습니다. [AWS KMS 키에 대한 액세스 제어 지침](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html)을 검토합니다.

 암호화 키 사용을 모니터링하여 비정상적인 액세스 패턴을 탐지해야 합니다. AWS KMS에 저장된 고객 관리형 키와 AWS 관리형 키를 사용하여 수행한 작업은 AWS CloudTrail에 로그인할 수 있으며 정기적으로 검토해야 합니다. 키 폐기 이벤트를 모니터링하는 데 특히 주의를 기울이세요. 키 구성 요소의 우발적 또는 악의적 폐기를 방지하기 위해 키 폐기 이벤트는 키 구성 요소를 즉시 삭제하지 않습니다. AWS KMS에서 키 삭제 시도에는 [대기 시간](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html#deleting-keys-how-it-works)이 적용됩니다. 기본값은 30일, 최솟값은 7일이므로 관리자는 이러한 작업을 검토하고 필요한 경우 요청을 롤백할 시간을 확보할 수 있습니다.

 대부분의 AWS 서비스는 사용자에게 투명한 방식으로 AWS KMS를 사용합니다. AWS 관리형 키를 사용할지 아니면 고객 관리형 키를 사용할지 결정하는 것만이 유일한 요구 사항입니다. 워크로드에서 데이터를 암호화하거나 복호화하는 데 AWS KMS를 직접 사용해야 하는 경우 [봉투 암호화](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)를 사용하여 데이터를 보호해야 합니다. [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html)에서는 애플리케이션에 클라이언트측 암호화 기본 요소를 제공하여 봉투 암호화를 구현하고 AWS KMS와 통합할 수 있습니다.

### 구현 단계
<a name="implementation-steps"></a>

1.  키에 적합한 [키 관리 옵션](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt)(AWS 관리형 또는 고객 관리형)을 결정합니다.

   1.  사용 편의성을 위해 AWS에서는 대부분의 서비스에 대해 AWS 소유 및 AWS 관리형 키를 제공하며, 키 구성 요소나 키 정책을 관리할 필요 없이 저장 시 암호화 기능을 제공합니다.

   1.  고객 관리형 키를 사용할 때는 민첩성, 보안, 데이터 주권, 가용성 사이에서 최상의 균형을 유지할 수 있도록 기본 키 스토어를 고려하세요. 다른 사용 사례에서는 [AWS CloudHSM](https://aws.amazon.com/cloudhsm/) 또는 [외부 키 저장소](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html)와 함께 사용자 지정 키 저장소를 사용해야 할 수도 있습니다.

1.  워크로드에 사용 중인 서비스 목록을 검토하여 서비스와의 AWS KMS 통합 방식을 파악하세요. 예를 들어, EC2 인스턴스는 암호화된 EBS 볼륨을 사용하여 해당 볼륨에서 생성된 Amazon EBS 스냅샷도 고객 관리형 키를 사용하여 암호화되는지 확인하고 암호화되지 않은 스냅샷 데이터가 우발적으로 공개되는 것을 방지할 수 있습니다.

   1.  [How AWS services use AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/service-integration.html) 

   1.  AWS 서비스에서 제공하는 암호화 옵션에 대한 자세한 내용은 해당 서비스 사용 설명서 또는 개발자 안내서의 저장 데이터 암호화 주제를 참조하세요.

1.  AWS KMS 구현: AWS KMS는 다양한 AWS 서비스와 애플리케이션에서 간단하게 키를 생성 및 관리하고 암호화 사용을 제어할 수 있습니다.

   1.  [Getting started: AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) 

   1.  [AWS KMS 키에 대한 액세스 제어 모범 사례](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html)를 검토합니다.

1.  AWS Encryption SDK 고려: 애플리케이션이 클라이언트 측 데이터를 암호화해야 하는 경우 AWS Encryption SDK를 AWS KMS와 통합하세요.

   1.  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

1.  AWS KMS 키 정책이 지나치게 광범위한지 자동으로 검토하고 알리도록 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 활성화합니다.

   1.  [사용자 지정 정책 확인](https://docs.aws.amazon.com/access-analyzer/latest/APIReference/API_CheckNoPublicAccess.html)을 사용하여 리소스 정책 업데이트가 KMS 키에 대한 퍼블릭 액세스 권한을 부여하지 않는지 확인하는 것이 좋습니다.

1.  [Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html)을 활성화하여 잘못 구성된 키 정책, 삭제 예정 키 또는 자동 교체가 활성화되지 않은 키가 있는 경우 알림을 받습니다.

1.  AWS KMS 키에 적합한 로깅 수준을 결정하세요. 읽기 전용 이벤트를 포함하여 AWS KMS에 대한 직접 호출이 로깅되므로 AWS KMS에 연결된 CloudTrail 로그의 양이 많아질 수 있습니다.

   1.  일부 조직에서는 AWS KMS 로깅 활동을 별도의 트레일로 분리하는 것을 선호합니다. 자세한 내용은 AWS KMS 개발자 안내서의 [Logging AWS KMS API calls with CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html) 섹션을 참조하세요.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 
+  [AWS cryptographic services and tools](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) 
+  [암호화로 Amazon S3 데이터 보호](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [봉투 암호화](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) 
+  [Digital sovereignty pledge](https://aws.amazon.com/blogs/security/aws-digital-sovereignty-pledge-control-without-compromise/) 
+  [Demystifying AWS KMS key operations, bring your own key, custom key store, and ciphertext portability](https://aws.amazon.com/blogs/security/demystifying-kms-keys-operations-bring-your-own-key-byok-custom-key-store-and-ciphertext-portability/) 
+  [AWS Key Management Service cryptographic details](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **관련 비디오:** 
+  [How Encryption Works in AWS](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) 
+  [AWS data protection: Using locks, keys, signatures, and certificates](https://www.youtube.com/watch?v=lD34wbc7KNA) 

 **관련 예제:** 
+  [Implement advanced access control mechanisms using AWS KMS](https://catalog.workshops.aws/advkmsaccess/en-US/introduction) 

# SEC08-BP02 저장 시 암호화 적용
<a name="sec_protect_data_rest_encrypt"></a>

 저장 상태의 프라이빗 데이터를 암호화하여 기밀성을 유지하고 의도하지 않은 데이터 공개 또는 유출에 대한 추가 보호 계층을 제공합니다. 암호화는 먼저 복호화되지 않고는 데이터를 읽거나 액세스할 수 없도록 하여 데이터를 보호합니다. 암호화되지 않은 데이터의 인벤토리를 만들고 제어하여 데이터 노출과 관련된 위험을 완화합니다.

 **원하는 성과:** 저장 시 기본적으로 프라이빗 데이터를 암호화하는 메커니즘이 있습니다. 이러한 메커니즘은 데이터의 기밀성을 유지하는 데 도움이 되며 의도치 않은 데이터 공개 또는 유출에 대한 추가 보호 계층을 제공합니다. 암호화되지 않은 데이터의 인벤토리를 유지하고 이를 보호하기 위해 마련된 제어를 이해합니다.

 **일반적인 안티 패턴:** 
+  기본적으로 암호화 구성을 사용하지 않습니다.
+  복호화 키에 지나치게 관대한 액세스를 제공합니다.
+  암호화 및 복호화 키의 사용을 모니터링하지 않습니다.
+  데이터를 암호화되지 않은 상태로 저장합니다.
+  데이터 용도, 유형 및 분류에 관계없이 모든 데이터에 동일한 암호화 키를 사용합니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 지침
<a name="implementation-guidance"></a>

 워크로드 내의 데이터 분류에 암호화 키를 매핑합니다. 이 접근 방식은 데이터에 단일 또는 매우 적은 수의 암호화 키를 사용할 때 지나치게 허용적인 액세스 권한을 방지하는 데 도움이 됩니다([SEC07-BP01 데이터 분류 체계 이해](sec_data_classification_identify_data.md) 참조).

 AWS Key Management Service(AWS KMS)는 많은 AWS 서비스와 통합되어 저장 데이터를 보다 쉽게 암호화할 수 있습니다. 예를 들어 Amazon Elastic Compute Cloud(Amazon EC2)에서 새 EBS 볼륨이 자동으로 암호화되도록 계정에 [기본 암호화](https://docs.aws.amazon.com/ebs/latest/userguide/work-with-ebs-encr.html#encryption-by-default)를 설정할 수 있습니다. AWS KMS를 사용할 때 데이터를 얼마나 엄격하게 제한해야 하는지 고려합니다. 기본 및 서비스 제어 AWS KMS 키는 사용자를 대신하여 AWS에서 관리하고 사용합니다. 기본 암호화 키에 대한 세분화된 액세스 권한이 필요한 민감한 데이터의 경우 고객 관리형 키(CMK)를 고려합니다. 키 정책을 사용하여 교체 및 액세스 관리를 포함하여 CMK를 완전히 제어할 수 있습니다.

 또한 Amazon Simple Storage Service([Amazon S3](https://aws.amazon.com/blogs/aws/amazon-s3-encrypts-new-objects-by-default/))와 같은 서비스는 이제 기본적으로 모든 새 객체를 암호화합니다. 이 구현은 성능에 영향을 주지 않으면서 향상된 보안을 제공합니다.

 [Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)(Amazon EC2) 또는 [Amazon Elastic File System](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/efs.html)(Amazon EFS)과 같은 기타 서비스는 기본 암호화 설정을 지원합니다. [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)을 사용하여 [Amazon Elastic Block Store(Amazon EBS) 볼륨](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), [Amazon Relational Database Service(Amazon RDS) 인스턴스](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html) 및 [Amazon S3 버킷](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html)에 암호화를 사용하고 있는지 자동으로 확인할 수 있습니다.

 AWS는 또한 클라이언트측 암호화 옵션을 제공하므로 데이터를 클라우드에 업로드하기 전에 암호화할 수 있습니다. AWS Encryption SDK에서는 [봉투 암호화](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)를 사용하여 데이터를 암호화하는 방법을 제공합니다. 래핑 키를 제공하면 AWS Encryption SDK가 암호화하는 각 데이터 객체에 대해 고유한 데이터 키를 생성합니다. 관리형 단일 테넌트 하드웨어 보안 모듈(HSM)이 필요한 경우 AWS CloudHSM을 고려합니다. AWS CloudHSM을 사용하면 FIPS 140-2 레벨 3 검증 HSM에서 암호화 키를 생성, 가져오기 및 관리할 수 있습니다. AWS CloudHSM의 일부 사용 사례에는 인증 기관(CA) 발급을 위한 프라이빗 키 보호와 Oracle 데이터베이스용 투명한 데이터 암호화(TDE) 활성화가 포함됩니다. AWS CloudHSM 클라이언트 SDK는 데이터를 AWS에 업로드하기 전에 AWS CloudHSM에 저장된 키를 사용하여 데이터 클라이언트측을 암호화할 수 있는 소프트웨어를 제공합니다. Amazon DynamoDB Encryption Client를 사용하면 DynamoDB 테이블에 업로드하기 전에 항목을 암호화하고 서명할 수도 있습니다.

### 구현 단계
<a name="implementation-steps"></a>
+  ****[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)** 구성:** AWS에서 제공하는 기본 키 또는 사용자가 생성한 키를 사용하는 옵션을 통해, 새로 생성되는 모든 Amazon EBS 볼륨이 암호화된 형식으로 생성되도록 지정합니다.
+  **암호화된 Amazon Machine Image(AMI) 구성:** 암호화가 구성된 상태에서 기존 AMI를 복사하면 루트 볼륨 및 스냅샷을 자동으로 암호화합니다.
+  ****[https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html)** 구성:** 암호화 옵션을 사용하여 Amazon RDS 데이터베이스 클러스터 및 저장된 스냅샷에 대한 암호화를 구성합니다.
+  **각 데이터 분류를 위해 적절한 보안 주체에 대한 액세스를 제한하는 정책으로 AWS KMS 키 생성 및 구성:** 예를 들어 프로덕션 데이터 암호화를 위해 하나의 AWS KMS 키를 생성하고 개발 또는 테스트 데이터 암호화를 위해 다른 키를 생성합니다. 다른 AWS 계정에 키 액세스를 제공할 수도 있습니다. 개발 및 프로덕션 환경에 대해 서로 다른 계정을 사용하는 것이 좋습니다. 프로덕션 환경에서 개발 계정의 아티팩트를 복호화해야 하는 경우 개발 아티팩트를 암호화하는 데 사용되는 CMK 정책을 편집하여 프로덕션 계정에 해당 아티팩트를 복호화할 수 있는 기능을 제공할 수 있습니다. 그러면 프로덕션 환경에서 프로덕션에 사용하기 위해 복호화된 데이터를 수집할 수 있습니다.
+  **추가 AWS 서비스에서 암호화 구성:** 사용하는 다른 AWS 서비스의 경우 해당 서비스의 [보안 설명서](https://docs.aws.amazon.com/security/)를 검토하여 서비스의 암호화 옵션을 결정합니다.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 암호화 도구](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 
+  [AWS KMS Cryptographic Details 백서](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 
+  [AWS Key Management Service](https://aws.amazon.com/kms) 
+  [AWS cryptographic services and tools](https://docs.aws.amazon.com/aws-crypto-tools/) 
+  [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Default encryption for Amazon EBS volumes](https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-volumes/) 
+  [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [How do I enable default encryption for an Amazon S3 bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html)
+  [암호화로 Amazon S3 데이터 보호](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 

 **관련 비디오:** 
+  [How Encryption Works in AWS](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP03 저장 데이터 보호 자동화
<a name="sec_protect_data_rest_automate_protection"></a>

 자동화를 사용하여 저장된 데이터 제어를 검증하고 적용하세요.  자동 스캐닝을 사용하여 데이터 스토리지 솔루션의 잘못된 구성을 탐지하고, 가능하다면 자동화된 프로그래밍 방식 응답을 통해 수정을 수행합니다.  CI/CD 프로세스에 자동화를 통합하여 프로덕션 환경에 배포하기 전에 데이터 스토리지 구성 오류를 감지할 수 있습니다.

 **원하는 성과:** 자동화된 시스템이 데이터 스토리지 위치를 스캔하고 모니터링하여 제어 기능의 잘못된 구성, 무단 액세스 및 예상치 못한 사용이 있는지 확인합니다.  잘못 구성된 스토리지 위치를 탐지하면 자동 수정이 시작됩니다.  자동화된 프로세스는 데이터 백업을 생성하고 원본 환경 외부에 변경 불가능한 사본을 저장합니다.

 **일반적인 안티 패턴:** 
+  지원되는 경우에 기본 설정으로 암호화를 활성화하는 옵션을 고려하고 있지 않습니다.
+  자동 백업 및 복구 전략을 수립할 때 운영 이벤트 외에 보안 이벤트는 고려하지 않습니다.
+  스토리지 서비스에 대한 공개 액세스 설정을 적용하지 않습니다.
+  저장 데이터를 보호하기 위한 제어 기능을 모니터링하고 감사하지 않습니다.

 **이 모범 사례 확립의 이점:** 자동화는 데이터 스토리지 위치를 잘못 구성할 위험을 방지하는 데 도움이 됩니다. 프로덕션 환경에 잘못된 구성이 유입되는 것을 방지하는 데 도움이 됩니다. 이 모범 사례는 잘못된 구성이 발생할 경우 이를 탐지하고 수정하는 데도 도움이 됩니다.  

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간 

## 구현 가이드 
<a name="implementation-guidance"></a>

 자동화는 저장 데이터를 보호하기 위한 관행 전반에 적용되는 주제입니다. [SEC01-BP06 표준 보안 제어의 배포 자동화](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html)에서는 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)과 같이 *코드형 인프라*(IaC) 템플릿을 사용하여 리소스 구성을 캡처하는 방법을 설명합니다.  이러한 템플릿은 버전 제어 시스템에 적용되며 CI/CD 파이프라인을 통해 AWS에 리소스를 배포하는 데 사용됩니다.  이러한 기술은 Amazon S3 버킷의 암호화 설정과 같은 데이터 스토리지 솔루션의 구성을 자동화하는 데도 동일하게 적용됩니다.  

 [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)의 규칙을 사용하여 IaC 템플릿에서 정의한 설정에 CI/CD 파이프라인의 잘못된 구성이 있는지 확인할 수 있습니다.  [AWS Config](https://aws.amazon.com/config/)를 통해 CloudFormation 또는 기타 IaC 도구에서 아직 사용할 수 없는 설정에 잘못된 구성이 있는지 모니터링할 수 있습니다.  Config가 잘못된 구성에 대해 생성하는 알림은 [SEC04-BP04 비준수 리소스에 대한 문제 해결 시작](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html)에서 설명한 대로 자동으로 수정할 수 있습니다.

 권한 관리 전략의 일부로 자동화를 사용하는 것도 자동화된 데이터 보호의 필수 구성 요소입니다. [SEC03-BP02 최소 권한 액세스 부여](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) 및 [SEC03-BP04 지속적으로 권한 축소](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_continuous_reduction.html)에서는 최소 권한 액세스 정책을 구성하는 방법을 설명합니다. [AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/access-analyzer/)에서는 이 정책을 지속적으로 모니터링하여 권한을 축소할 수 있는 경우 조사 결과를 생성합니다.  권한 모니터링에 대한 자동화 외에도 [EBS 볼륨](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-ec2.html)(EC2 인스턴스를 통해), [S3 버킷](https://docs.aws.amazon.com/guardduty/latest/ug/s3-protection.html) 및 지원되는 [Amazon Relational Database Service 데이터베이스](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html)에 대한 비정상적인 데이터 액세스 동작을 감시하도록 [Amazon GuardDuty](https://aws.amazon.com/guardduty/)를 구성할 수 있습니다.

 자동화는 민감한 데이터가 승인되지 않은 위치에 저장되는 시점을 탐지하는 역할도 합니다. [SEC07-BP03 식별 및 분류 자동화](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_auto_classification.html)에서는 [Amazon Macie](https://aws.amazon.com/macie/)가 S3 버킷에서 예기치 못한 민감한 데이터를 모니터링하고 자동화된 응답을 시작할 수 있는 알림을 생성하는 방법에 대해 설명합니다.

 [REL09 데이터 백업](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html)의 관행에 따라 자동화된 데이터 백업 및 복구 전략을 개발합니다. 데이터 백업 및 복구는 운영 이벤트와 마찬가지로 보안 이벤트 복구에도 중요합니다.

### 구현 단계
<a name="implementation-steps"></a>

1.  IaC 템플릿에서 데이터 스토리지 구성을 캡처합니다.  CI/CD 파이프라인의 자동 검사를 사용하여 구성 오류를 감지합니다.

   1.  [CloudFormation](https://aws.amazon.com/cloudformation/)을 IaC 템플릿에 사용할 수 있으며, [CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)를 사용하여 템플릿에 잘못된 구성이 있는지 확인할 수 있습니다.

   1.  [AWS Config](https://aws.amazon.com/config/)를 사용하여 사전 평가 모드에서 규칙을 실행합니다. 이 설정을 사용하면 리소스를 생성하기 전에 CI/CD 파이프라인의 한 단계로 리소스의 규정 준수를 확인할 수 있습니다.

1.  리소스에서 데이터 스토리지 구성 오류를 모니터링합니다.

   1.  데이터 스토리지 리소스에서 제어 구성의 변경 사항을 모니터링하고 잘못된 구성이 감지되면 수정 조치를 간접 호출하는 알림을 생성하도록 [AWS Config](https://aws.amazon.com/config/)를 설정합니다.

   1.  자동 수정에 대한 자세한 지침은 [SEC04-BP04 비준수 리소스에 대한 수정 시작](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html)을 참조하세요.

1.  자동화를 통해 데이터 액세스 권한을 지속적으로 모니터링하고 줄입니다.

   1.  [IAM Access Analyzer](https://aws.amazon.com/iam/access-analyzer/)를 지속적으로 실행하여 권한이 축소될 가능성이 있는 경우 알림을 생성할 수 있습니다.

1.  비정상적인 데이터 액세스 동작을 모니터링하고 알림을 보냅니다.

   1.  [GuardDuty](https://aws.amazon.com/guardduty/)는 EBS 볼륨, S3 버킷, RDS 데이터베이스와 같은 데이터 스토리지 리소스에 대한 기본 액세스 동작과의 편차와 알려진 위협 서명을 모두 감시합니다.

1.  예상치 못한 위치에 저장되는 민감한 데이터를 모니터링하고 알림을 보냅니다.

   1.  [Amazon Macie](https://aws.amazon.com/macie/)를 사용하여 S3 버킷에서 민감한 데이터를 지속적으로 스캔합니다.

1.  안전하고 암호화된 데이터 백업을 자동화합니다.

   1.  [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)은 AWS에서 다양한 데이터 소스의 암호화되고 안전한 백업을 생성하는 관리형 서비스입니다.  [Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)를 사용하면 전체 서버 워크로드를 복사하고 초 단위로 측정된 Recovery Point Objective(RPO)로 지속적인 데이터 보호를 유지 관리할 수 있습니다.  두 서비스가 함께 작동하도록 구성하여 데이터 백업 생성 및 장애 조치 위치에 복사하는 작업을 자동화할 수 있습니다.  이렇게 하면 운영 또는 보안 이벤트의 영향을 받는 경우에도 데이터를 계속 사용할 수 있습니다.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [SEC01-BP06 표준 보안 제어의 배포 자동화](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html) 
+  [SEC03-BP02 최소 권한 액세스 부여](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) 
+  [SEC03-BP04 지속적으로 권한 축소](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_continuous_reduction.html) 
+  [SEC04-BP04 규정 미준수 리소스 관련 문제 해결 시작](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html) 
+  [SEC07-BP03 식별 및 분류 자동화](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_auto_classification.html) 
+  [REL09-BP02 백업 보안 및 암호화](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_secured_backups_data.html) 
+  [REL09-BP03 자동으로 데이터 백업 수행](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html) 

 **관련 문서:** 
+  [AWS Prescriptive Guidance: Automatically encrypt existing and new Amazon EBS volumes](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automatically-encrypt-existing-and-new-amazon-ebs-volumes.html) 
+  [Ransomware Risk Management on AWS Using the NIST Cyber Security Framework (CSF)](https://docs.aws.amazon.com/whitepapers/latest/ransomware-risk-management-on-aws-using-nist-csf/ransomware-risk-management-on-aws-using-nist-csf.html) 

 **관련 예제:** 
+  [How to use AWS Config proactive rules and AWS CloudFormation Hooks to prevent creation of noncompliant cloud resources](https://aws.amazon.com/blogs/mt/how-to-use-aws-config-proactive-rules-and-aws-cloudformation-hooks-to-prevent-creation-of-non-complaint-cloud-resources/) 
+  [Automate and centrally manage data protection for Amazon S3 with AWS Backup](https://aws.amazon.com/blogs/storage/automate-and-centrally-manage-data-protection-for-amazon-s3-with-aws-backup/) 
+  [AWS re:Invent 2023 - Implement proactive data protection using Amazon EBS snapshots](https://www.youtube.com/watch?v=d7C6XsUnmHc) 
+  [AWS re:Invent 2022 - Build and automate for resilience with modern data protection](https://www.youtube.com/watch?v=OkaGvr3xYNk) 

 **관련 도구:** 
+  [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 
+  [AWS CloudFormation Guard Rules Registry](https://github.com/aws-cloudformation/aws-guard-rules-registry) 
+  [IAM 액세스 분석기](https://aws.amazon.com/iam/access-analyzer/) 
+  [Amazon Macie](https://aws.amazon.com/macie/) 
+  [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 

# SEC08-BP04 액세스 제어 적용
<a name="sec_protect_data_rest_access_control"></a>

 저장 데이터를 보호하려면 격리 및 버전 관리와 같은 메커니즘을 사용하여 액세스 제어를 적용합니다. 최소 권한 및 조건부 액세스 제어를 적용합니다. 데이터에 대한 퍼블릭 액세스 권한 부여를 방지합니다.

 **원하는 성과:** 인증된 사용자만 알아야 할 데이터에 액세스할 수 있는지 확인합니다. 정기적인 백업 및 버전 관리를 통해 데이터를 보호하여 의도적이거나 우발적인 데이터 수정 또는 삭제를 방지합니다. 중요한 데이터를 다른 데이터와 분리하여 기밀성과 데이터 무결성을 보호합니다.

**일반적인 안티 패턴:**
+  민감도 요구 사항이 다르거나 분류가 다른 데이터를 함께 저장합니다.
+  복호화 키에 지나치게 관대한 권한을 사용합니다.
+  데이터를 잘못 분류합니다.
+  중요한 데이터의 자세한 백업을 유지하지 않습니다.
+  프로덕션 데이터에 대한 지속적인 액세스를 제공합니다.
+  데이터 액세스를 감사하거나 정기적으로 권한을 검토하지 않습니다.

**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 지침
<a name="implementation-guidance"></a>

 저장 데이터를 보호하는 것은 데이터 무결성, 기밀성 및 규제 요구 사항 준수를 유지하는 데 중요합니다. 액세스 제어, 격리, 조건부 액세스 및 버전 관리를 포함하여 이를 달성하는 데 도움이 되는 여러 제어를 구현할 수 있습니다.

 최소 권한 원칙에 따라 액세스 제어를 적용할 수 있습니다. 이 원칙은 사용자와 서비스가 작업을 수행하는 데 필요한 권한만 제공합니다. 여기에는 암호화 키에 대한 액세스가 포함됩니다. [AWS Key Management Service(AWS KMS) 정책](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)을 검토하여 부여하는 액세스 수준이 적절하고 관련 조건이 적용되는지 확인합니다.

 각 수준에 대해 고유한 AWS 계정을 사용하여 다양한 분류 수준에 따라 데이터를 분리하고 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)을 사용하여 이러한 계정을 관리할 수 있습니다. 이러한 격리는 무단 액세스를 방지하고 데이터 노출 위험을 최소화하는 데 도움이 될 수 있습니다.

 Amazon S3 버킷 정책에 부여된 액세스 수준을 정기적으로 검토합니다. 절대적으로 필요한 경우가 아니면 공개적으로 읽을 수 있거나 쓸 수 있는 버킷을 사용하지 마세요. 또한 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)를 사용하여 공개적으로 사용 가능한 버킷을 감지하고 Amazon CloudFront를 사용하여 Amazon S3에서 콘텐츠를 제공하는 것이 좋습니다. 퍼블릭 액세스를 허용하면 안 되는 버킷은 퍼블릭 액세스가 되지 않도록 적절히 구성되어 있는지 확인합니다.

 Amazon S3에 저장된 중요 데이터에 대한 버전 관리 및 객체 잠금 메커니즘을 구현합니다. [Amazon S3 버전 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)는 이전 버전의 객체를 보존하여 우발적 삭제 또는 덮어쓰기를 했을 때 데이터를 복구합니다. 잠금이 만료될 때까지 루트 사용자라도 객체를 삭제하거나 덮어쓰지 못하게 하는 [Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)은 객체에 대한 필수 액세스 제어를 제공합니다. 또한 [Amazon Glacier Vault Lock](https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html)은 Amazon Glacier에 저장된 아카이브에 대해 유사한 기능을 제공합니다.

### 구현 단계
<a name="implementation-steps"></a>

1.  **최소 권한 원칙에 따라 액세스 제어 적용:** 
   +  사용자 및 서비스에 부여된 액세스 권한을 검토하고 작업을 수행하는 데 필요한 권한만 있는지 확인합니다.
   +  [AWS Key Management Service(AWS KMS) 정책](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)을 확인하여 암호화 키에 대한 액세스를 검토합니다.

1.  **다양한 분류 수준에 따라 데이터 분리:** 
   +  각 데이터 분류 수준에 대해 고유한 AWS 계정을 사용합니다.
   +  [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)을 사용하여 이러한 계정을 관리합니다.

1.  **Amazon S3 버킷 및 객체 권한 검토:** 
   +  Amazon S3 버킷 정책에 부여된 액세스 수준을 정기적으로 검토합니다.
   +  절대적으로 필요한 경우가 아니면 공개적으로 읽을 수 있거나 쓸 수 있는 버킷을 사용하지 마세요.
   +  [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)를 사용하여 공개적으로 사용 가능한 버킷을 감지하는 것을 고려하세요.
   +  Amazon CloudFront를 사용하여 Amazon S3의 콘텐츠를 제공합니다.
   +  퍼블릭 액세스를 허용하면 안 되는 버킷은 퍼블릭 액세스가 되지 않도록 적절히 구성되어 있는지 확인합니다.
   +  SQS 또는 서드파티 데이터 스토어와 같이 IAM 인증을 사용하는 데이터베이스 및 기타 데이터 소스에 동일한 검토 프로세스를 적용할 수 있습니다.

1.  **AWS IAM Access Analyzer 사용:** 
   +  Amazon S3 버킷을 분석하고 S3 정책이 외부 엔터티에 대한 액세스 권한을 부여할 때 조사 결과를 생성하도록 [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 구성할 수 있습니다.

1.  **버전 관리 및 객체 잠금 메커니즘 구현**: 
   +  [Amazon S3 버전 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)를 사용하여 이전 버전의 객체를 보존하여 실수로 삭제하거나 덮어쓰는 것을 방지합니다.
   +  잠금이 만료될 때까지 루트 사용자라도 객체를 삭제하거나 덮어쓰지 못하게 하는 [Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)을 사용하여 객체에 대한 필수 액세스 제어를 제공합니다.
   +  Amazon Glacier에 저장된 아카이브에 [Amazon Glacier Vault Lock](https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html)을 사용합니다.

1.  **Amazon S3 Inventory 사용**: 
   +  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html)를 사용하여 S3 객체의 복제 및 암호화 상태를 감사하고 보고할 수 있습니다.

1.  **Amazon EBS 및 AMI 공유 권한 검토**: 
   +  [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) 및 [AMI 공유](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html)에 대한 권한을 검토하여 워크로드 외부에 존재하는 AWS 계정과 이미지 및 볼륨이 공유되지 않는다는 것을 확인합니다.

1.  **AWS Resource Access Manager Shares 정기적으로 검토:** 
   +  [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)를 사용하여 Amazon VPC 내에서 AWS Network Firewall 정책, Amazon Route 53 Resolver 규칙, 서브넷과 같은 리소스를 공유할 수 있습니다.
   +  공유 리소스를 정기적으로 감사하고 더 이상 공유할 필요가 없는 리소스 공유를 중지합니다.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+ [SEC03-BP01 액세스 요구 사항 정의](sec_permissions_define.md) 
+  [SEC03-BP02 최소 권한 액세스 부여](sec_permissions_least_privileges.md) 

 **관련 문서:** 
+  [AWS KMS Cryptographic Details 백서](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 
+  [Amazon S3 리소스에 대한 액세스 권한 관리 소개](https://docs.aws.amazon.com/AmazonS3/latest/dev/intro-managing-access-s3-resources.html) 
+  [Overview of managing access to your AWS KMS resources](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) 
+  [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) 
+  [Amazon S3 \$1 Amazon CloudFront: A Match Made in the Cloud](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/) 
+  [버전 관리 사용](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) 
+  [Amazon S3 객체 잠금을 사용하여 객체 잠금](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html) 
+  [Sharing an Amazon EBS Snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) 
+  [공유 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html) 
+  [Hosting a single-page application on Amazon S3](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) 
+  [AWS 글로벌 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 
+  [Building a Data Perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) 

 **관련 비디오:** 
+  [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) 

# 전송 중 데이터 보호
<a name="protecting-data-in-transit"></a>

 *전송 중 데이터*는 시스템 간에 전송되는 모든 데이터를 의미합니다. 여기에는 워크로드 내 리소스 간의 통신과 다른 서비스 및 최종 사용자 간의 통신이 포함됩니다. 전송 중 데이터를 적절한 수준으로 보호하면 워크로드 데이터의 기밀성과 무결성을 보호할 수 있습니다.

**VPC 또는 온프레미스 위치 사이에서 데이터 보호:** Amazon Virtual Private Cloud(VPC) 또는 AWS에 호스팅된 서비스에 대한 온프레미스 연결 사이에서 안전한 프라이빗 네트워크 연결을 생성하는 데 [AWS PrivateLink](https://aws.amazon.com/privatelink/)를 사용할 수 있습니다. 프라이빗 네트워크에서와 같이 AWS 서비스, 서드파티 서비스 및 기타 AWS 계정의 서비스에 액세스할 수 있습니다. AWS PrivateLink를 사용하면 인터넷 게이트웨이 또는 NAT 없이도 IP CIDR이 중복되는 계정에서 서비스에 액세스할 수 있습니다. 또한 방화벽 규칙, 경로 정의 또는 라우팅 테이블을 구성하지 않아도 됩니다. 트래픽은 Amazon 백본에 머무르며 인터넷을 통과하지 않으므로 데이터가 보호됩니다. HIPAA 및 EU/US Privacy Shield와 같은 업계별 규정 준수 규제를 계속 준수할 수 있습니다. AWS PrivateLink는 서드파티 솔루션과 원활하게 연동하여 간소화된 글로벌 네트워크를 구축하므로 클라우드로의 마이그레이션을 가속화하고 사용 가능한 AWS 서비스를 활용할 수 있습니다.

**Topics**
+ [SEC09-BP01 보안 키 및 인증서 관리 구현](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 전송 중 암호화 적용](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 네트워크 통신 인증](sec_protect_data_transit_authentication.md)

# SEC09-BP01 보안 키 및 인증서 관리 구현
<a name="sec_protect_data_transit_key_cert_mgmt"></a>

 전송 계층 보안(TLS) 인증서는 인터넷과 프라이빗 네트워크에서 네트워크 통신을 보호하고 웹 사이트, 리소스 및 워크로드의 ID를 설정하는 데 사용됩니다.

 **원하는 성과:** 퍼블릭 키 인프라(PKI)에서 인증서를 프로비저닝, 배포, 저장 및 갱신할 수 있는 보안 인증서 관리 시스템. 보안 키 및 인증서 관리 메커니즘은 인증서 개인 키 구성 요소가 공개되는 것을 방지하고 정기적으로 인증서를 자동 갱신합니다. 또한 다른 서비스와 통합하여 워크로드 내부의 머신 리소스에 대한 보안 네트워크 통신 및 ID를 제공합니다. 키 구성 요소는 인적 자격 증명이 절대 접근할 수 없어야 합니다.

 **일반적인 안티 패턴:** 
+  인증서 배포 또는 갱신 프로세스 중에 수동 단계를 수행합니다.
+  프라이빗 CA를 설계할 때 인증 기관(CA) 계층 구조에 충분히 주의를 기울이지 않습니다.
+  퍼블릭 리소스에 자체 서명된 인증서를 사용합니다.

 **이 모범 사례 확립의 이점: **
+  자동 배포 및 갱신을 통해 인증서 관리 간소화 
+  TLS 인증서를 사용하여 전송 중 데이터의 암호화 장려 
+  인증 기관이 취한 인증서 작업의 보안 및 감사 가능성 향상 
+  CA 계층 구조의 여러 계층에서 관리 업무 구성 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음

## 구현 지침
<a name="implementation-guidance"></a>

 최신 워크로드는 TLS와 같은 PKI 프로토콜을 사용하는 암호화된 네트워크 통신을 광범위하게 사용합니다. PKI 인증서 관리는 복잡할 수 있지만 자동화된 인증서 프로비저닝, 배포 및 갱신을 통해 인증서 관리와 관련된 마찰을 줄일 수 있습니다.

 AWS에서는 범용 PKI 인증서를 관리하기 위해 [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) 및 [AWS Private Certificate Authority(AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)와 같은 두 가지 서비스를 제공합니다. ACM은 고객이 퍼블릭 워크로드와 프라이빗 AWS 워크로드 모두에서 사용할 인증서를 프로비저닝, 관리 및 배포하는 데 사용하는 기본 서비스입니다. ACM은 AWS Private CA를 사용하여 프라이빗 인증서를 발급하고 다른 많은 AWS관리형 서비스와 [통합](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)하여 워크로드에 보안 TLS 인증서를 제공합니다. ACM은 [Amazon Trust Services](https://www.amazontrust.com/repository/) 에서 공개적으로 신뢰할 수 있는 인증서를 발급할 수도 있습니다. ACM의 퍼블릭 인증서는 퍼블릭 워크로드에 사용할 수 있습니다. 최신 브라우저와 운영 체제는 기본적으로 이러한 인증서를 신뢰하기 때문입니다.

 AWS Private CA를 사용하면 자체 루트의 CA 또는 하위 CA를 설정하고 API를 통해 TLS 인증서를 발급할 수 있습니다. 이러한 종류의 인증서는 TLS 연결의 클라이언트 측에서 신뢰 체인을 제어하고 관리하는 시나리오에서 사용할 수 있습니다. TLS 사용 사례 외에도 AWS Private CA를 사용하면 [사용자 지정 템플릿](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html)으로 Kubernetes 포드, Matter 디바이스 제품 증명, 코드 서명 및 기타 사용 사례에 인증서를 발급할 수 있습니다. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하여 프라이빗 CA에서 서명한 X.509 인증서를 발급한 온프레미스 워크로드에 임시 IAM 자격 증명을 제공할 수 있습니다.

 ACM 및 AWS Private CA 외에도 [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html)는 PKI 인증서를 IoT 디바이스에 프로비저닝, 관리 및 배포하기 위한 전문 지원을 제공합니다. AWS IoT Core는 대규모 퍼블릭 키 인프라에 적용할 수 있는 [IoT 디바이스 온보딩](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html)용 전문 메커니즘을 제공합니다.

 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) 및 [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)과 같은 일부 AWS 서비스는 인증서를 사용하여 애플리케이션 연결을 보호하는 자체 기능을 제공합니다. 예를 들어 API Gateway와 Application Load Balancer(ALB)는 모두 AWS Management Console, CLI 또는 API를 사용하여 생성하고 내보내는 클라이언트 인증서를 사용하여 상호 TLS(mTLS)를 지원합니다.

**프라이빗 CA 계층 구조 설정 시 고려 사항**

 프라이빗 CA를 설정해야 하는 경우 CA 계층 구조를 미리 적절하게 설계할 수 있도록 특별히 주의를 기울이는 것이 중요합니다. 프라이빗 CA 계층 구조를 만들 때는 CA 계층 구조의 각 수준을 별도의 AWS 계정에 배포하는 것이 좋습니다. 이 의도적인 단계는 CA 계층 구조의 각 수준에 대한 노출 영역을 줄여 CloudTrail 로그 데이터에서 이상 징후를 더 쉽게 발견하고 계정 중 하나에 대한 무단 액세스가 발생할 경우 액세스 또는 영향 범위를 줄일 수 있습니다. 루트 CA는 별도의 계정에 있어야 하며 하나 이상의 중간 CA 인증서를 발급하는 데만 사용해야 합니다.

 그런 다음 루트 CA 계정과 분리된 계정에 하나 이상의 중간 CA를 생성하여 최종 사용자, 디바이스 또는 기타 워크로드에 대한 인증서를 발급합니다. 마지막으로 루트 CA에서 중간 CA로 인증서를 발급합니다. 그러면 중간 CA가 최종 사용자나 디바이스에 인증서를 발급합니다. 복원력 계획, 크로스 리전 복제, 조직 전반의 CA 공유 등을 포함하여 CA 배포 계획 및 CA 계층 설계에 대한 자세한 내용은 [Planning your AWS Private CA deployment](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html)를 참조하세요.

### 구현 단계
<a name="implementation-steps"></a>

1.  사용 사례에 필요한 관련 AWS 서비스 확인: 
   +  많은 사용 사례에서 [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)를 사용하여 기존 AWS 퍼블릭 키 인프라를 활용할 수 있습니다. ACM은 웹 서버나 로드 밸런서용 또는 공개적으로 신뢰할 수 있는 인증서를 위한 기타 용도로 TLS 인증서를 배포하는 데 사용할 수 있습니다.
   +  자체 프라이빗 인증 기관 계층 구조를 설정해야 하거나 내보낼 수 있는 인증서에 액세스해야 하는 경우 [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)를 고려하세요. 그런 다음 ACM에서는 AWS Private CA를 사용하여 [다양한 유형의 최종 엔터티 인증서](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html)를 발급할 수 있습니다.
   +  내장된 사물 인터넷(IoT) 디바이스에 대규모로 인증서를 프로비저닝해야 하는 사용 사례의 경우에는 [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html)를 고려하세요.
   +  [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) 또는 [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)와 같은 서비스에서 네이티브 mTLS 기능을 사용하는 것을 고려하세요.

1.  가능한 경우 자동 인증서 갱신 구현: 
   +  통합된 AWS 관리형 서비스와 함께 ACM에서 발급한 인증서에 대해 [ACM 관리형 갱신](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html)을 사용합니다.

1.  로깅 및 감사 트레일 설정: 
   +  [CloudTrail 로그](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html)를 활성화하여 인증 기관이 있는 계정에 대한 액세스를 추적합니다. CloudTrail에서 로그 파일 무결성 검증을 구성하여 로그 데이터의 신뢰성을 확인하는 것이 좋습니다.
   +  프라이빗 CA가 발급 또는 취소한 인증서를 나열하는 [감사 보고서](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html)를 정기적으로 생성하고 검토합니다. 이러한 보고서는 S3 버킷으로 내보낼 수 있습니다.
   +  프라이빗 CA를 배포할 때는 인증서 폐기 목록(CRL)을 저장할 S3 버킷도 설정해야 합니다. 워크로드 요구 사항에 따라 이 S3 버킷을 구성하는 방법에 대한 지침은 [Planning a certificate revocation list (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)를 참조하세요.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [SEC02-BP02 임시 자격 증명 사용](sec_identities_unique.md) 
+ [SEC08-BP01 보안 키 관리 구현](sec_protect_data_rest_key_mgmt.md)
+  [SEC09-BP03 네트워크 통신 인증](sec_protect_data_transit_authentication.md) 

 **관련 문서:** 
+  [How to host and manage an entire private certificate infrastructure in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/) 
+  [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/) 
+  [Private CA best practices](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html) 
+  [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) 

 **관련 비디오:** 
+  [Activating AWS Certificate Manager Private CA(워크숍)](https://www.youtube.com/watch?v=XrrdyplT3PE) 

 **관련 예제:** 
+  [Private CA 워크숍](https://catalog.workshops.aws/certificatemanager/en-US/introduction) 
+  [IOT Device Management 워크숍](https://iot-device-management.workshop.aws/en/)(디바이스 프로비저닝 포함) 

 **관련 도구:** 
+  [Plugin to Kubernetes cert-manager to use AWS Private CA](https://github.com/cert-manager/aws-privateca-issuer) 

# SEC09-BP02 전송 중 암호화 적용
<a name="sec_protect_data_transit_encrypt"></a>

조직, 법률 및 규정 준수 요구 사항을 충족할 수 있도록 조직의 정책, 규제 의무 및 표준에 따라 정의된 암호화 요구 사항을 적용합니다. 민감한 데이터를 Virtual Private Cloud(VPC) 외부로 전송할 때 암호화된 프로토콜만 사용합니다. 암호화는 데이터가 신뢰할 수 없는 네트워크로 전송되는 경우에도 데이터 기밀성을 유지하는 데 도움이 됩니다.

 **원하는 성과:** 데이터에 대한 무단 액세스를 완화하기 위해 리소스와 인터넷 간의 네트워크 트래픽을 암호화합니다. 보안 요구 사항에 따라 내부 AWS 환경 내에서 네트워크 트래픽을 암호화합니다. 보안 TLS 프로토콜 및 암호 세트를 사용하여 전송 중 데이터를 암호화합니다.

 **일반적인 안티 패턴:** 
+  사용 중단된 버전의 SSL, TLS 및 암호 그룹 구성 요소(예: SSL v3.0, 1024비트 RSA 키 및 RC4 암호)를 사용합니다.
+  퍼블릭 리소스에서 암호화되지 않은(HTTP) 트래픽을 허용합니다.
+  만료되기 전에 X.509 인증서를 모니터링하고 교체하지 않습니다.
+  TLS에 자체 서명된 X.509 인증서를 사용합니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 AWS 서비스는 통신에 TLS를 사용하는 HTTPS 엔드포인트를 제공하여 AWS API와 통신할 때 전송 중 암호화 기능을 제공합니다. 안전하지 않은 HTTP 프로토콜은 보안 그룹을 사용하여 가상 프라이빗 클라우드(VPC)에서 감사 및 차단할 수 있습니다. HTTP 요청은 [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)의 HTTPS로나 [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions)에서 자동으로 리디렉션될 수도 있습니다. [Amazon Simple Storage Service(Amazon S3) 버킷 정책](https://aws.amazon.com/blogs/storage/enforcing-encryption-in-transit-with-tls1-2-or-higher-with-amazon-s3/)을 사용하여 HTTP를 통해 객체를 업로드하는 기능을 제한하여 객체를 버킷에 업로드하는 데 HTTPS 사용을 효과적으로 적용할 수 있습니다. 컴퓨팅 리소스를 완전하게 제어하여 서비스 간에 전송 중 암호화를 구현할 수 있습니다. 외부 네트워크 또는 [AWS Direct Connect](https://aws.amazon.com/directconnect/)로부터 특정 VPC로의 VPN 연결을 사용하여 트래픽을 쉽게 암호화할 수도 있습니다. [AWS가 2024년 2월부터 이전 버전의 TLS 사용을 중단했으므로](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) 클라이언트가 최소 TLS 1.2를 사용하여 AWS API를 직접 호출하는지 확인합니다. TLS 1.3을 사용할 것을 권장합니다. 전송 중 암호화에 대한 특별한 요구 사항이 있는 경우 AWS Marketplace에서 서드파티 솔루션을 찾을 수 있습니다.

### 구현 단계
<a name="implementation-steps"></a>
+  **전송 중 암호화 적용:** 정의된 암호화 요구 사항은 최신 표준 및 모범 사례를 토대로 하고 보안 프로토콜만 허용해야 합니다. 예를 들어 Application Load Balancer 또는 Amazon EC2 인스턴스로의 HTTPS 프로토콜을 허용하는 보안 그룹만 구성합니다.
+  **엣지 서비스에서 보안 프로토콜 구성:** [Amazon CloudFront로 HTTPS를 구성](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)하고 [보안 태세 및 사용 사례에 적합한 보안 프로파일](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers)을 사용합니다.
+  **[외부 연결을 위해 VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) 사용:** 데이터 프라이버시와 무결성을 모두 지원할 수 있도록 지점 간 또는 네트워크 간 연결에 IPsec VPN 사용을 고려합니다.
+  **로드 밸런서에서 보안 프로토콜 구성:** 리스너에 연결할 클라이언트가 지원하는 가장 강력한 암호 그룹을 제공하는 보안 정책을 선택합니다. [Application Load Balancer에 대한 HTTPS 리스너를 생성합니다](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html).
+  **Amazon Redshift에서 보안 프로토콜 구성:** 클러스터가 [보안 소켓 계층(SSL) 또는 전송 계층 보안(TLS) 연결](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)을 요구하도록 구성합니다.
+  **보안 프로토콜 구성:** AWS 서비스 설명서를 검토하여 전송 중 암호화 기능을 확인합니다.
+  **Amazon S3 버킷에 업로드할 때 보안 액세스 구성:** Amazon S3 버킷 정책 제어를 사용하여 데이터에 대한 [보안 액세스를 적용합니다](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).
+  **[AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) 사용 고려:** ACM에서는 AWS 서비스에서 사용하도록 퍼블릭 TLS 인증서를 프로비저닝, 관리 및 배포할 수 있습니다.
+  **프라이빗 PKI 요구 사항에 [AWS Private Certificate Authority](https://aws.amazon.com/private-ca/) 사용 고려:** AWS Private CA를 사용하면 프라이빗 인증 기관(CA) 계층 구조를 생성하여 암호화된 TLS 채널을 생성하는 데 사용할 수 있는 최종 엔터티 X.509 인증서를 발급할 수 있습니다.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+ [ CloudFront에서 HTTPS 사용 ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [AWS Virtual Private Network를 사용하여 VPC를 원격 네트워크에 연결 ](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Create an HTTPS listener for your Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [ Tutorial: Configure SSL/TLS on Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [ SSL/TLS를 사용하여 DB 인스턴스 연결 암호화 ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [ 연결을 위한 보안 옵션 구성 ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)

# SEC09-BP03 네트워크 통신 인증
<a name="sec_protect_data_transit_authentication"></a>

 전송 계층 보안(TLS) 또는 IPsec과 같은 인증을 지원하는 프로토콜을 사용하여 통신의 자격 증명을 확인합니다.

 서비스, 애플리케이션 또는 사용자 간에 통신할 때마다 안전하고 인증된 네트워크 프로토콜을 사용하도록 워크로드를 설계합니다. 인증 및 권한 부여를 지원하는 네트워크 프로토콜을 사용하면 네트워크 흐름을 더 강력하게 제어할 수 있고 무단 액세스의 영향을 줄일 수 있습니다.

 **원하는 성과:** 서비스 간 트래픽 흐름이 잘 정의된 데이터 영역 및 컨트롤 플레인 트래픽 흐름을 보유한 워크로드. 트래픽 흐름은 기술적으로 가능한 경우 인증되고 암호화된 네트워크 프로토콜을 사용합니다.

 **일반적인 안티 패턴:** 
+  암호화되지 않았거나 인증되지 않은 트래픽이 워크로드 내에 흐릅니다.
+  여러 사용자 또는 엔터티가 인증 자격 증명을 재사용합니다.
+  액세스 제어 메커니즘으로 네트워크 제어에만 의존합니다.
+  업계 표준 인증 메커니즘에 의존하지 않고 사용자 지정 인증 메커니즘을 구축합니다.
+  서비스 구성 요소 또는 VPC의 다른 리소스 간에 지나치게 허용적인 트래픽이 흐릅니다.

 **이 모범 사례 확립의 이점:** 
+  무단 액세스의 영향 범위를 워크로드의 한 부분으로 제한합니다.
+  작업이 인증된 엔터티에 의해서만 수행되도록 더 높은 수준의 보장을 제공합니다.
+  의도된 데이터 전송 인터페이스를 명확하게 정의하고 적용함으로써 서비스의 분리를 개선합니다.
+  요청 어트리뷰션 및 잘 정의된 통신 인터페이스를 통해 모니터링, 로깅 및 인시던트 대응을 개선합니다.
+  네트워크 제어와 인증 및 권한 제어를 결합하여 워크로드에 대한 심층 방어를 제공합니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드의 네트워크 트래픽 패턴은 두 가지 범주로 분류할 수 있습니다.
+  *동서 트래픽*은 워크로드를 구성하는 서비스 간의 트래픽 흐름을 나타냅니다.
+  *남북 트래픽*은 워크로드와 소비자 간의 트래픽 흐름을 나타냅니다.

 남북 트래픽을 암호화하는 것이 일반적이지만 인증된 프로토콜을 사용하여 동서 트래픽을 보호하는 것은 흔하지 않습니다. 최신 보안 관행에서는 네트워크 설계만으로는 두 엔터티 간에 신뢰할 수 있는 관계를 부여하지 않을 것을 권장합니다. 두 서비스가 공통 네트워크 경계 내에 있을 수 있는 경우에도 이러한 서비스 간의 통신을 암호화 및 인증하고 권한을 부여하는 것이 가장 좋습니다.

 예를 들어, AWS 서비스 API는 요청이 시작된 네트워크와 상관없이 [AWS Signature Version 4(SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) 서명 프로토콜을 사용하여 호출자를 인증합니다. 이 인증을 통해 AWS API는 작업을 요청한 자격 증명을 확인할 수 있으며, 그런 다음 해당 자격 증명을 정책과 결합하여 권한 부여 결정을 내려 작업의 허용 여부를 결정할 수 있습니다.

 [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) 및 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)와 같은 서비스를 사용하면 동일한 SigV4 서명 프로토콜을 사용하여 자체 워크로드의 동서 트래픽에 인증 및 권한 부여를 추가할 수 있습니다. AWS 환경 외부의 리소스가 SigV4 기반 인증 및 권한 부여가 필요한 서비스와 통신해야 하는 경우 AWS 이외 리소스에서 [AWS Identity and Access Management(IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하여 임시 AWS 자격 증명을 얻을 수 있습니다. 이러한 자격 증명을 사용하여 액세스 권한 부여에 SigV4를 사용하는 서비스에 대한 요청에 서명할 수 있습니다.

 동서 트래픽을 인증하는 또 다른 일반적인 메커니즘은 TLS 상호 인증(mTLS)입니다. 많은 사물 인터넷(IoT), B2B 애플리케이션 및 마이크로서비스는 mTLS를 사용하여 클라이언트 및 서버 측 X.509 인증서를 모두 사용하여 TLS 통신 양측의 자격 증명을 확인합니다. 이러한 인증서는 AWS Private Certificate Authority(AWS Private CA)에서 발급할 수 있습니다. [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)와 같은 서비스를 사용하여 워크로드 간 또는 워크로드 내부 통신을 위한 mTLS 인증을 제공할 수 있습니다. [Application Load Balancer는 내부 또는 외부 대상 워크로드에 대한 mTLS도 지원합니다](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html). mTLS는 TLS 통신 양쪽에 대한 인증 정보를 제공하지만 권한 부여 메커니즘을 제공하지는 않습니다.

 마지막으로 OAuth 2.0 및 OIDC(OpenID Connect)는 일반적으로 사용자의 서비스 액세스를 제어하는 데 사용되는 프로토콜이지만 이제는 서비스 간 트래픽에서도 널리 사용되고 있습니다. API Gateway는 [JSON 웹 토큰(JWT) 권한 부여자](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)를 제공하여 워크로드가 OIDC 또는 OAuth 2.0 ID 제공업체에서 발급한 JWT를 사용하여 API 경로에 대한 액세스를 제한할 수 있도록 합니다. OAuth2 범위는 기본 권한 부여 결정을 위한 소스로 사용될 수 있지만, 애플리케이션 계층에서 여전히 권한 부여 검사를 구현해야 하며, OAuth2 범위만으로는 더 복잡한 권한 부여 요구 사항을 지원할 수 없습니다.

### 구현 단계
<a name="implementation-steps"></a>
+  **워크로드 네트워크 흐름 정의 및 문서화:** 심층 방어 전략을 구현하기 위한 첫 번째 단계는 워크로드의 트래픽 흐름을 정의하는 것입니다.
  +  워크로드를 구성하는 여러 서비스 간에 데이터가 전송되는 방식을 명확하게 정의하는 데이터 흐름도를 만듭니다. 이 다이어그램은 인증된 네트워크 채널을 통해 이러한 흐름을 적용하는 첫 번째 단계입니다.
  +  개발 및 테스트 단계에서 워크로드를 계측하여 데이터 흐름도가 런타임 시 워크로드의 동작을 정확하게 반영하는지 확인합니다.
  +  데이터 흐름도는 [SEC01-BP07 위협 모델을 사용하여 위협 식별 및 완화 조치의 우선순위 지정](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)에서 설명한 대로 위협 모델링 연습을 수행할 때도 유용할 수 있습니다.
+  **네트워크 제어 설정:** 데이터 흐름에 맞게 네트워크 제어를 설정할 수 있는 AWS 기능을 고려합니다. 네트워크 경계가 유일한 보안 제어가 되어서는 안 되지만, 네트워크 경계는 워크로드를 보호하기 위한 심층 방어 전략의 한 계층을 제공합니다.
  +  [보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html)을 사용하여 리소스 간 데이터 흐름을 설정, 정의 및 제한합니다.
  +  AWS 및 AWS PrivateLink를 지원하는 서드파티 서비스 모두와 통신하기 위해 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) 사용을 고려하세요. AWS PrivateLink 인터페이스 엔드포인트를 통해 전송된 데이터는 AWS 네트워크 백본 내에 머물며 퍼블릭 인터넷을 통과하지 않습니다.
+  **워크로드의 서비스 전반에 인증 및 권한 부여 구현:** 워크로드에서 인증되고 암호화된 트래픽 흐름을 제공하는 데 가장 적합한 AWS 서비스 세트를 선택합니다.
  +  서비스 간 통신을 보호하려면 [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html)를 고려하세요. VPC Lattice는 [인증 정책과 결합된 SigV4 인증](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html)을 사용하여 서비스 간 액세스를 제어할 수 있습니다.
  +  mTLS를 사용한 서비스 간 통신의 경우 [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html), [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html)를 고려해 보세요. [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)는 mTLS와 함께 사용할 인증서를 발급할 수 있는 프라이빗 CA 계층 구조를 설정하는 데 사용할 수 있습니다.
  +  OAuth 2.0 또는 OIDC를 사용하여 서비스와 통합할 때는 [JWT 권한 부여자를 사용하여 API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)를 사용하는 것을 고려하세요.
  +  워크로드와 IoT 디바이스 간 통신의 경우 네트워크 트래픽 암호화 및 인증을 위한 여러 옵션을 제공하는 [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html)를 고려해 보세요.
+  **무단 액세스 모니터링:** 의도하지 않은 통신 채널, 보호된 리소스에 대한 무단 액세스 시도 및 기타 부적절한 액세스 패턴을 지속적으로 모니터링합니다.
  +  VPC Lattice를 사용하여 서비스에 대한 액세스를 관리하는 경우 [VPC Lattice 액세스 로그](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html)를 활성화하고 모니터링하는 방법을 고려해 보세요. 이러한 액세스 로그에는 요청 엔티티에 대한 정보, 소스 및 대상 VPC를 비롯한 네트워크 정보, 요청 메타데이터가 포함됩니다.
  +  [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)를 사용하여 네트워크 흐름의 메타데이터를 캡처하고 주기적으로 이상 징후를 검토하는 방법을 고려해 보세요.
  +  보안 인시던트 계획, 시뮬레이션 및 대응에 대한 자세한 지침은 [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) 및 AWS Well-Architected Framework 보안 원칙의 [인시던트 대응 섹션](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)을 참조하세요.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+ [ SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석 ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [ SEC02-BP02 임시 자격 증명 사용 ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [ SEC01-BP07 위협 모델을 사용하여 위협 식별 및 완화 조치의 우선순위 지정 ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)

 **관련 문서:** 
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ REST API에 대한 상호 TLS 인증 구성 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [AWS Security Incident Response Guide ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)

 **관련 비디오:** 
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)

 **관련 예제:** 
+ [ Amazon VPC Lattice 워크숍 ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ 제로 트러스트 에피소드 1 - The Phantom Service Perimeter 워크숍 ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)