

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

# AWS 프라이버시 참조 아키텍처
<a name="aws-privacy-reference-architecture"></a>

**설문 조사**  
여러분의 의견을 듣고 싶습니다. [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2) 조사에 참여하여 AWS PRA에 대한 피드백을 제공해 주십시오.

다음 다이어그램은 AWS 프라이버시 참조 아키텍처(AWS PRA)를 보여줍니다. 다음은 많은 개인 정보 보호 관련 AWS 서비스 및 기능을 연결하는 아키텍처의 예입니다. 이 아키텍처는 AWS Control Tower에서 규제하는 랜딩 존을 기반으로 합니다.

![\[AWS 프라이버시 참조 아키텍처에 배포된 AWS 서비스의 다이어그램\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/aws-pra-architecture.png)


 AWS PRA에는 개인 데이터(PD) 애플리케이션 계정에서 호스팅되는 서버리스 웹 아키텍처가 포함되어 있습니다. 이 계정의 아키텍처는 소비자로부터 직접 개인 데이터를 수집하는 워크로드에 대한 예제입니다. 이 워크로드에서 사용자는 웹 티어를 통해 연결됩니다. 웹 티어는 애플리케이션 티어와 상호 작용합니다. 이 계층은 웹 계층으로부터 입력을 수신하고, 데이터를 처리 및 저장하며, 승인된 내부 팀과 서드 파티가 데이터에 액세스할 수 있도록 허용하고, 결국 더 이상 필요하지 않을 때 데이터를 아카이브하고 삭제합니다. 이 아키텍처는 데이터 레이크, 컨테이너, 컴퓨팅 또는 사물 인터넷(IoT)과 같은 특정 사용 사례를 살펴보지 않고 많은 기본 프라이버시 엔지니어링 기술을 보여주기 위해 의도적으로 모듈화된 이벤트 중심 아키텍처입니다.

다음으로 이 가이드에서는 조직의 각 계정을 자세히 설명합니다. 다음 각 계정의 개인 정보 보호와 관련된 서비스 및 기능, 고려 사항 및 권장 사항, 다이어그램에 대해 설명합니다.
+ [조직 관리 계정](org-management-account.md)
+ [보안 OU - 보안 도구 계정](security-tooling-account.md)
+ [보안 OU - 로그 아카이브 계정](log-archive-account.md)
+ [인프라 OU - Network 계정](network-account.md)
+ [개인 데이터 OU - PD 애플리케이션 계정](personal-data-account.md)

# 조직 관리 계정
<a name="org-management-account"></a>

**설문 조사**  
여러분의 의견을 듣고 싶습니다. [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2) 조사에 참여하여 AWS PRA에 대한 피드백을 제공해 주십시오.

조직 관리 계정은 기본적으로 AWS Organizations에서 관리하는 조직의 모든 계정에서 기본 개인 정보 보호 제어를 위한 리소스 구성 드리프트를 관리하는 데 사용됩니다. 또한 이 계정에서는 동일한 보안 및 개인 정보 보호 제어를 통해 새 멤버 계정을 일관된 방식으로 배포할 수 있습니다. 이 계정에 대한 자세한 내용은 [AWS 보안 참조 아키텍처(AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/org-management.html)를 참조하세요. 다음 다이어그램은 조직 관리 계정에 구성된 AWS 보안 및 개인 정보 보호 서비스를 보여줍니다.

![\[AWS 조직 관리 계정에 배포된 서비스.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/Account-Org-Management.png)


**Topics**
+ [AWS Artifact](#aws-artifact)
+ [AWS Control Tower](#aws-control-tower)
+ [AWS Organizations](#aws-organizations)

## AWS Artifact
<a name="aws-artifact"></a>

[AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html)는 AWS 보안 및 규정 준수 문서의 온디맨드 다운로드를 제공하여 감사를 지원할 수 있습니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/org-management.html#mgmt-artifact)를 참조하세요.

이를 AWS 서비스 통해 상속 AWS 받은 제어를 이해하고 환경에서 구현할 수 있는 컨트롤을 결정할 수 있습니다.는 SOC(System and Organization Controls) 보고서 및 PCI(Payment Card Industry) 보고서와 같은 AWS 보안 및 규정 준수 보고서에 대한 액세스를 AWS Artifact 제공합니다. 또한 AWS 제어의 구현 및 운영 효율성을 검증하는 여러 지역 및 규정 준수 수직 부문의 인증 기관의 인증에 대한 액세스를 제공합니다. 를 사용하면 감사자 또는 규제 기관에 AWS 보안 및 개인 정보 보호 제어의 증거로 AWS 감사 아티팩트를 제공할 AWS Artifact 수 있습니다. 다음 보고서는 AWS 개인 정보 보호 제어의 효과를 입증하는 데 유용할 수 있습니다.
+ **SOC 2 유형 2 개인 정보 보호 보고서** -이 보고서는 개인 데이터가 수집, 사용, 보존, 공개 및 폐기되는 방식에 대한 AWS 제어의 효과를 보여줍니다. [SOC 3 개인 정보 보호 보고서](https://d1.awsstatic.com/whitepapers/compliance/AWS_SOC3.pdf)도 있는데, 이는 SOC 2 개인 정보 보호 제어에 대해 덜 상세한 설명을 제공합니다. 자세한 내용은 [SOC FAQ](https://aws.amazon.com/compliance/soc-faqs/)를 참조하세요.
+ **클라우드 컴퓨팅 규정 준수 제어 카탈로그(C5)** - 이 보고서는 독일의 국가 사이버 보안 기관인 Informationstechnik(BSI)의 Bundesamt für Sicherheit에서 작성했습니다. C5 요구 사항을 충족하기 위해 AWS 가 구현한 보안 제어를 자세히 설명합니다. 또한 데이터 위치, 서비스 프로비저닝, 관할 구역 및 정보 공개 의무와 관련된 개인 정보 보호에 대한 추가 제어 요구 사항도 포함됩니다.
+ **ISO/IEC 27701:2019 인증 보고서** – [ISO/IEC 27701:2019](https://aws.amazon.com/compliance/iso-27701-faqs/?refid=sl_card)에서는 개인 정보 보호 관리 시스템(PIMS)을 설정하고 지속적으로 개선하기 위한 요구 사항과 지침을 설명합니다. 이 보고서는이 인증의 범위를 자세히 설명하고 AWS 인증 증명 역할을 할 수 있습니다. 이 표준에 대한 자세한 내용은 [ISO/IEC 27701:2019](https://www.iso.org/standard/71670.html)(ISO 웹 사이트)를 참조하세요.

## AWS Control Tower
<a name="aws-control-tower"></a>

[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)는 규범적 보안 권장 사례를 따르는 AWS 다중 계정 환경을 설정하고 관리하는 데 도움이 됩니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/org-management.html#mgmt-tower)를 참조하세요.

에서는 데이터 프라이버시 요구 사항, 특히 데이터 레지던시 및 주권에 맞는 *가드레*일이라고도 하는 많은 선제적, 예방적 및 탐지 제어의 배포를 자동화 AWS Control Tower할 수도 있습니다. 예를 들어 데이터 전송을 승인된 AWS 리전으로만 제한하는 가드레일을 지정할 수 있습니다. 보다 세분화된 제어를 위해 Amazon *Virtual Private Network(VPN) 연결 허용 안 함, Amazon* *VPC 인스턴스에 대한 인터넷 액세스 허용 안 함*, 요청된에 따라에 대한 액세스 거부 등 데이터 레지던시를 제어하도록 설계된 17개 이상의 가드레일 중에서 선택할 수 있습니다. * AWS AWS 리전* 이러한 가드레일은 조직 전체에 균일하게 배포할 수 있는 여러 AWS CloudFormation 후크, 서비스 제어 정책 및 AWS Config 규칙으로 구성됩니다. 자세한 내용은 AWS Control Tower 설명서의 [데이터 레지던시 보호를 강화하는 제어를](https://docs.aws.amazon.com/controltower/latest/userguide/data-residency-controls.html) 참조하세요.

데이터 주권의 경우 AWS Control Tower 현재는 *연결된 Amazon EBS 볼륨이 유휴 데이터를 암호화하도록 구성되어 있어야 함*, * AWS KMS 권한 부여 생성을 제한하는 문이 있어야 AWS KMS 함 AWS 서비스*과 같은 예방 제어를 제공합니다. 주권 제어는 단순한 데이터 레지던시 제어보다 광범위합니다. 이를 통해 데이터 레지던시, 세분화된 액세스 제한, 암호화 및 복원력 요구 사항을 위반할 수 있는 작업을 방지할 수 있습니다. 자세한 내용은 AWS Control Tower 설명서의 [Preventive controls that assist with digital sovereignty](https://docs.aws.amazon.com/controltower/latest/controlreference/ds-preventive-controls.html)를 참조하세요.

데이터 레지던시 및 주권 제어를 넘어 프라이버시 가드레일을 배포해야 하는 경우 에는 여러 가지 [필수 제어](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html)가 AWS Control Tower 포함됩니다. 이러한 제어는 랜딩 존을 설정할 때 기본적으로 모든 OU에 배포됩니다. 이러한 대부분은 *로그 아카이브 삭제 허용 안 함* 및 * CloudTrail 로그 파일에 대한 무결성 검증 활성화*와 같이 로그를 보호하도록 설계된 예방적 제어입니다.

AWS Control Tower 또한는와 통합되어 탐지 제어를 AWS Security Hub CSPM 제공합니다. 이러한 제어를 [서비스 관리형 표준 AWS Control Tower](https://docs.aws.amazon.com/securityhub/latest/userguide/service-managed-standard-aws-control-tower.html)이라고 합니다. 이러한 제어를 사용하여 Amazon Relational Database Service(Amazon RDS) 데이터베이스 인스턴스에 대한 저장 데이터 암호화와 같은 개인 정보 보호 지원 제어의 구성 드리프트를 모니터링할 수 있습니다.

## AWS Organizations
<a name="aws-organizations"></a>

 AWS PRA는 AWS Organizations 를 사용하여 아키텍처 내의 모든 계정을 중앙에서 관리합니다. 자세한 내용은 이 안내서의 [AWS Organizations 및 전용 계정 구조](organization-account-structure.md) 섹션을 참조하세요. 에서는 서비스 제어 정책(SCPs) 및 [관리 정책을](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_management_policies.html) 사용하여 개인 데이터와 개인 정보를 보호할 AWS Organizations수 있습니다.

### 서비스 제어 정책(SCP)
<a name="aws-organizations-scps"></a>

[서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)은 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형입니다. 이를 통해 대상 계정, 조직 단위 AWS Identity and Access Management (OU) 또는 전체 조직의 (IAM) 역할 및 사용자에 대해 사용 가능한 최대 권한을 중앙 집중식으로 제어할 수 있습니다. 조직 관리 계정에서 SCP를 생성하고 적용할 수 있습니다.

 AWS Control Tower 를 사용하여 계정 전체에 SCPs 균일하게 배포할 수 있습니다. 적용할 수 있는 데이터 레지던시 제어에 대한 자세한 내용은이 가이드[AWS Control Tower](#aws-control-tower)의 섹션을 AWS Control Tower참조하세요. 예방 SCPs의 전체 보완을 AWS Control Tower 포함합니다. AWS Control Tower 가 현재 조직에서 사용되지 않는 경우 이러한 제어를 수동으로 배포할 수도 있습니다.

#### SCP를 사용하여 데이터 레지던시 요구 사항 해결
<a name="using-scps-to-address-data-residency-requirements"></a>

특정 지리적 리전 내에 데이터를 저장하고 처리하여 개인 데이터 레지던시 요구 사항을 관리하는 것이 일반적입니다. 관할 구역의 고유한 데이터 레지던시 요구 사항이 충족되는지 확인하려면 규제 팀과 긴밀히 협력하여 요구 사항을 확인하는 것이 좋습니다. 이러한 요구 사항이 결정되면 지원에 도움이 될 수 있는 여러 AWS 가지 기본 개인 정보 보호 제어가 있습니다. 예를 들어 SCPs 사용하여 데이터를 처리하고 저장하는 데 사용할 수 있는를 제한할 AWS 리전 수 있습니다. 정책 샘플은 이 가이드의 [간 데이터 전송 제한 AWS 리전](restrict-data-transfers-across-regions.md) 섹션을 참조하세요.

#### SCP를 사용하여 고위험 API 직접 호출 제한
<a name="using-scps-to-restrict-high-risk-api-calls"></a>

어떤 보안 및 개인 정보 보호 제어 AWS 에 책임이 있고 어떤 보안 및 개인 정보 보호 제어에 책임이 있는지 이해하는 것이 중요합니다. 예를 들어 사용하는 AWS 서비스 에 대해 발생할 수 있는 API 직접 호출 결과에 대한 책임은 사용자에게 있습니다. 또한 보안 또는 개인 정보 보호 태세를 변경할 수 있는 직접 호출을 파악하는 것도 사용자의 책임입니다. 특정 보안 및 개인 정보 보호 태세의 유지 관린와 관련해 우려 사항이 있는 경우 특정 API 직접 호출을 거부하는 SCP를 활성화할 수 있습니다. 이러한 API 직접 호출은 의도하지 않은 개인 데이터 공개 또는 특정 국가 간 데이터 전송 위반과 같은 영향을 미칠 수 있습니다. 예를 들어 다음 API 직접 호출을 금지할 수 있습니다.
+ Amazon Simple Storage Service(Amazon S3) 버킷에 대한 퍼블릭 액세스 활성화
+ Amazon GuardDuty 비활성화 또는 [Trojan:EC2/DNSDataExfiltration](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-ec2.html#trojan-ec2-dnsdataexfiltration) 조사 결과와 같은 데이터 유출 조사 결과에 대한 억제 규칙 생성
+  AWS WAF 데이터 유출 규칙 삭제
+ Amazon Elastic Block Store(Amazon EBS) 스냅샷 퍼블릭 공유
+ 조직에서 멤버 계정 제거
+ 리포지토리에서 Amazon CodeGuru Reviewer 연결 해제

### 관리 정책
<a name="aws-organizations-management-policies"></a>

의 [관리 정책은](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_management_policies.html) AWS 서비스 및 해당 기능을 중앙에서 구성하고 관리하는 데 도움이 될 AWS Organizations 수 있습니다. 선택한 관리 정책 유형에 따라 정책이 정책을 상속하는 OU 및 계정에 미치는 영향이 달라집니다. [태그 정책은](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) 개인 정보 보호와 AWS Organizations 직접 관련된의 관리 정책의 예입니다.

#### 태그 정책 사용
<a name="using-tag-policies"></a>

[태그](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)는 AWS 리소스를 관리, 식별, 구성, 검색 및 필터링하는 데 도움이 되는 키 값 페어입니다. 개인 데이터를 처리하는 조직의 리소스를 구별하는 태그를 적용하는 방법이 유용할 수 있습니다. 태그 사용은 이 가이드의 많은 개인 정보 보호 솔루션을 지원합니다. 예를 들어 리소스 내에서 처리되거나 저장되는 데이터의 일반적인 데이터 분류를 나타내는 태그를 적용할 수 있습니다. 특정 태그 또는 태그 세트가 있는 리소스에 대한 액세스를 제한하는 속성 기반 액세스 제어(ABAC) 정책을 작성할 수 있습니다. 예를 들어 정책에서 `SysAdmin` 역할이 `dataclassification:4` 태그가 있는 리소스에 액세스할 수 없도록 지정할 수 있습니다. 자세한 내용과 자습서는 IAM 설명서의 [태그를 기반으로 AWS 리소스에 액세스할 수 있는 권한 정의를](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 참조하세요. 또한 조직에서 [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)을 사용하여 여러 계정의 백업에 데이터 보존 정책을 광범위하게 적용하는 경우 해당 리소스를 해당 백업 정책의 범위 내에 배치하는 태그를 적용할 수 있습니다.

[태그 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)은 조직 전체에서 일관된 태그를 유지하는 데 도움이 됩니다. 태그 정책에서 리소스에 태그를 지정할 때 리소스에 적용할 규칙을 지정합니다. 예를 들어 리소스에 `DataClassification` 또는 `DataSteward`와 같은 특정 키로 태그를 지정하도록 요구할 수 있으며 키에 유효한 대소문자 처리 또는 값을 지정할 수 있습니다. 또한 [적용](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-enforcement.html)을 사용하여 규정 미준수 태그 지정 요청이 완료되지 않도록 할 수 있습니다.

태그를 개인 정보 보호 제어 전략의 핵심 구성 요소로 사용하는 경우 다음 사항을 고려합니다.
+ 태그 키 또는 값 내에 개인 데이터 또는 기타 유형의 민감한 데이터를 배치할 경우 관련 영향을 고려합니다. 기술 지원을 위해에 문의 AWS 하면 AWS 에서 태그 및 기타 리소스 식별자를 분석하여 문제를 해결할 수 있습니다. 태그 데이터는 암호화되지 않으며 AWS 서비스와 같이가 데이터를 읽을 AWS 결제 및 비용 관리수 있습니다. 따라서 태그에 개인 식별 정보를 포함하지 않는 IT 서비스 관리(ITSM) system. AWS recommds와 같이 제어하는 시스템을 사용하여 태그 값을 비식별화한 다음 다시 식별할 수 있습니다.
+ 태그에 의존하는 ABAC 조건과 같은 기술 제어의 우회를 방지하려면 일부 태그 값을 변경할 수 없는 항목(수정 불가)으로 설정해야 합니다.

# 보안 OU - 보안 도구 계정
<a name="security-tooling-account"></a>

**설문 조사**  
여러분의 의견을 듣고 싶습니다. [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2) 조사에 참여하여 AWS PRA에 대한 피드백을 제공해 주십시오.

Security Tooling 계정은 보안 및 개인 정보 보호 기본 서비스 운영, 보안 AWS 계정및 개인 정보 보호 알림 및 응답 모니터링 및 자동화를 전담합니다. 이 계정에 대한 자세한 내용은 [AWS 보안 참조 아키텍처(AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)를 참조하세요. 다음 다이어그램은 AWS Security Tooling 계정에 구성된 보안 및 개인 정보 보호 서비스를 보여줍니다.

![\[AWS 서비스 Security 조직 단위의 Security Tooling 계정에 배포됩니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/Account-Security-Tooling.png)


**Topics**
+ [AWS CloudTrail](#aws-cloudtrail)
+ [AWS Config](#aws-config)
+ [Amazon GuardDuty](#amazon-guardduty)
+ [IAM Access Analyzer](#iam-access-analyzer)
+ [Amazon Macie](#amazon-macie)

## AWS CloudTrail
<a name="aws-cloudtrail"></a>

[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)는의 전체 API 활동을 감사하는 데 도움이 됩니다 AWS 계정. 개인 데이터를 저장, 처리 또는 전송하는 모든 AWS 계정 및에서 CloudTrail을 활성화하면이 데이터의 사용 및 공개를 추적 AWS 리전 하는 데 도움이 될 수 있습니다. [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html#mgmt-cloudtrail)는 조직의 모든 계정에 대한 모든 이벤트를 로깅하는 단일 추적에 해당하는 조직 추적을 활성화할 것을 권장합니다. 그러나 이 조직 추적을 활성화하면 다중 리전 로그 데이터가 로그 아카이브 계정의 단일 Amazon Simple Storage Service(Amazon S3) 버킷으로 집계됩니다. 개인 데이터를 처리하는 계정의 경우 이로 인해 몇 가지 추가 설계 고려 사항이 발생할 수 있습니다. 로그 레코드에는 개인 데이터에 대한 일부 참조가 포함될 수 있습니다. 데이터 레지던시 및 데이터 전송 요구 사항을 충족하려면 교차 리전 로그 데이터를 S3 버킷이 위치한 단일 리전으로 집계하는 방식을 다시 고려해야 할 수 있습니다. 조직은 조직 추적에 포함하거나 제외해야 하는 리전별 워크로드를 고려할 수 있습니다. 조직 추적에서 제외하기로 결정한 워크로드의 경우 개인 데이터를 마스킹하는 리전별 추적을 구성하는 방법을 고려할 수 있습니다. 개인 데이터 마스킹에 대한 자세한 내용은 이 가이드의 [Amazon Data Firehose](personal-data-account.md#amazon-data-firehose) 섹션을 참조하세요. 궁극적으로 조직은 중앙 집중식 로그 아카이브 계정으로 집계되는 조직 추적과 리전 추적을 조합할 수 있습니다.

단일 리전 추적 구성에 대한 자세한 내용은 [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail-by-using-the-aws-cli-create-trail.html#cloudtrail-create-and-update-a-trail-by-using-the-aws-cli-examples-single) 또는 [콘솔](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html#creating-a-trail-in-the-console) 사용 지침을 참조하세요. 조직 추적을 생성하는 경우 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/configure-org-trails.html)에서 옵트인 설정을 사용하거나 [CloudTrail 콘솔](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-an-organizational-trail-in-the-console.html)에서 직접 추적을 생성할 수 있습니다.

전반적인 접근 방식과 로그 및 데이터 전송 요구 사항의 중앙 집중화를 관리하는 방법에 대한 자세한 내용은 이 가이드의 [중앙 집중식 로그 스토리지](log-archive-account.md#centralized-log-storage) 섹션을 참조하세요. 어떤 구성을 선택하든 AWS SRA에 따라 보안 도구 계정의 추적 관리를 로그 아카이브 계정의 로그 스토리지와 분리할 수 있습니다. 이 설계는 로그를 관리해야 하는 사용자와 로그 데이터를 사용해야 하는 사용자를 위한 최소 권한 액세스 정책을 생성하는 데 도움이 됩니다.

## AWS Config
<a name="aws-config"></a>

[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)에서는 AWS 계정 에 있는 리소스와 해당 구성 방식을 자세히 보여줍니다. 이 정보는 리소스가 서로 관련되는 방식과 리소스의 구성이 시간이 지남에 따라 변경된 방식을 식별하는 데 도움이 됩니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html#tool-config)를 참조하세요.

에서는 AWS Config 규칙 및 문제 해결 작업 세트인 [적합성 팩](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) AWS Config을 배포할 수 있습니다. 적합성 팩은 관리형 또는 사용자 지정 AWS Config 규칙을 사용하여 개인 정보 보호, 보안, 운영 및 비용 최적화 거버넌스 검사를 지원하도록 설계된 범용 프레임워크를 제공합니다. 이 도구를 더 큰 자동화 도구 세트의 일부로 사용하여 AWS 리소스 구성이 자체 제어 프레임워크 요구 사항을 준수하는지 여부를 추적할 수 있습니다.

[Operational Best Practices for NIST Privacy Framework v1.0](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-nist_privacy_framework.html) 적합성 팩은 NIST Privacy Framework의 여러 개인 정보 보호 관련 제어에 부합됩니다. 각 AWS Config 규칙은 특정 AWS 리소스 유형에 적용되며 하나 이상의 NIST 프라이버시 프레임워크 제어와 관련이 있습니다. 이 적합성 팩을 사용하여 계정의 리소스 전반에서 개인 정보 보호와 관련된 지속적 규정 준수를 추적할 수 있습니다. 다음은 이 적합성 팩에 포함된 몇 가지 규칙입니다.
+ `no-unrestricted-route-to-igw` - 이 규칙은 VPC 라우팅 테이블에서 인터넷 게이트웨이로의 기본 `0.0.0.0/0` 또는 `::/0` 송신 경로를 지속적으로 모니터링하여 데이터 플레인의 데이터 유출을 방지하는 데 도움이 됩니다. 이를 통해 특히 악의적인 것으로 알려진 CIDR 범위가 있는 경우 인터넷 바운드 트래픽을 전송할 수 있는 위치를 제한할 수 있습니다.
+ `encrypted-volumes` - 이 규칙은 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨이 암호화되었는지 확인합니다. 조직에 개인 데이터 보호를 위한 AWS Key Management Service (AWS KMS) 키 사용과 관련된 특정 제어 요구 사항이 있는 경우 규칙의 일부로 특정 키 IDs를 지정하여 볼륨이 특정 AWS KMS 키로 암호화되었는지 확인할 수 있습니다.
+ `restricted-common-ports` - 이 규칙은 Amazon EC2 보안 그룹이 지정된 포트에 대한 무제한 TCP 트래픽을 허용하는지 확인합니다. 보안 그룹은 AWS 리소스에 대한 수신 및 송신 네트워크 트래픽의 상태 저장 필터링을 제공하여 네트워크 액세스를 관리하는 데 도움이 될 수 있습니다. `0.0.0.0/0`에서 TCP 3389 및 TCP 21과 같은 공통 포트로의 수신 트래픽을 차단하면 원격 액세스를 제한하는 데 도움이 됩니다.

AWS Config 는 리소스의 사전 및 사후 규정 준수 검사에 모두 사용할 수 있습니다 AWS . 적합성 팩에 있는 규칙을 고려하는 것 외에도 이러한 규칙을 감지 및 선제적 평가 모드 모두에 통합할 수 있습니다. 이렇게 하면 애플리케이션 개발자가 배포 전 검사를 통합하기 시작할 수 있으므로 소프트웨어 개발 수명 주기 초기에 개인 정보 보호 검사를 구현하는 데 도움이 됩니다. 예를 들어 사전 예방적 모드가 활성화된 모든 개인 정보 보호 관련 AWS Config 규칙에 대해 AWS CloudFormation 템플릿에서 선언된 리소스를 확인하는 후크를 템플릿에 포함할 수 있습니다. 자세한 내용은 [AWS Config Rules Now Support Proactive Compliance](https://aws.amazon.com/blogs/aws/new-aws-config-rules-now-support-proactive-compliance/)(AWS 블로그 게시물)를 참조하세요.

## Amazon GuardDuty
<a name="amazon-guardduty"></a>

AWS 는 Amazon S3, Amazon Relational Database Service(RDS) 또는 Amazon EC2 with Kubernetes와 같이 개인 데이터를 저장하거나 처리하는 데 사용할 수 있는 여러 서비스를 제공합니다. [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html)는 지능형 가시성과 지속적인 모니터링을 결합하여 의도하지 않은 개인 데이터 공개와 관련되었을 수 있는 지표를 감지합니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html#tool-guardduty)를 참조하세요.

GuardDuty를 사용하면 공격 수명 주기 전반에 걸쳐 잠재적으로 악의적인 개인 정보 보호 관련 활동을 식별할 수 있습니다. 예를 들어 GuardDuty는 블랙리스트에 등록된 사이트에 대한 연결, 비정상적인 네트워크 포트 트래픽 또는 트래픽 볼륨, DNS 유출, 예상치 못한 EC2 인스턴스 시작 및 비정상적인 ISP 직접 호출자를 알릴 수 있습니다. *신뢰할 수 있는 IP 목록*에서 신뢰할 수 있는 IP에 대한 알림과 자체 *위협 목록*의 알려진 악성 IP의 알림을 중지하도록 GuardDuty를 구성할 수 있습니다.

 AWS SRA에서 권장하는 대로 조직의 모든 AWS 계정 에 대해 GuardDuty를 활성화하고 보안 도구 계정을 GuardDuty 위임된 관리자로 구성할 수 있습니다. GuardDuty는** **조직 전체의 조사 결과를 이 단일 계정으로 집계합니다. 자세한 내용은 로 [GuardDuty 계정 관리를 참조하세요 AWS Organizations](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html). 또한 감지 및 분석부터 격리 및 근절까지 인시던트 대응 프로세스에서 모든 개인 정보 보호 관련 이해관계자를 식별하고 데이터 유출과 관련되었을 수 있는 모든 인시던트에 참여시키는 방법을 고려할 수 있습니다.

## IAM Access Analyzer
<a name="iam-access-analyzer"></a>

많은 고객이 개인 데이터가 사전 승인되고 의도된 서드 파티 프로세서와 적절하게 공유되고 있으며 다른 엔터티와는 공유되지 않는다는 지속적인 보장을 원합니다. [데이터 경계](https://aws.amazon.com/identity/data-perimeters-on-aws/)는 AWS 환경의 신뢰할 수 있는 리소스에 예상되는 네트워크의 신뢰할 수 있는 ID만 액세스할 수 있도록 설계된 예방적 가드레일입니다. 개인 데이터의 의도하지 않은 공개 및 의도된 공개에 대한 제어를 정의할 때 신뢰할 수 있는 ID, 신뢰할 수 있는 리소스 및 예상되는 네트워크를 정의할 수 있습니다.

[AWS Identity and Access Management Access Analyzer (IAM Access Analyzer)](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 사용하면 조직은 신뢰 AWS 계정 영역을 정의하고 해당 신뢰 영역에 대한 위반에 대한 알림을 구성할 수 있습니다. IAM Access Analyzer는 IAM 정책을 분석하여 잠재적으로 민감한 리소스에 대한 의도하지 않은 퍼블릭 또는 교차 계정 액세스를 식별하고 해결하는 데 도움이 됩니다. IAM Access Analyzer는 수학 로직과 추론을 사용하여 AWS 계정외부에서 액세스할 수 있는 리소스에 대한 포괄적인 조사 결과를 생성합니다. 마지막으로 지나치게 허용적인 IAM 정책에 대응하고 관련 문제를 해결하려면 IAM Access Analyzer를 사용하여 IAM 권장 사례를 기준으로 기존 정책을 검증하고 제안을 제공할 수 있습니다. IAM Access Analyzer는 IAM 위탁자의 이전 액세스 활동을 기반으로 최소 권한 IAM 정책을 생성할 수 있습니다. CloudTrail 로그를 분석하고 해당 작업을 계속 수행하는 데 필요한 권한만 부여하는 정책을 생성합니다.

보안 컨텍스트에서 IAM Access Analyzer를 사용하는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html#tool-iam-analyzer)를 참조하세요.

## Amazon Macie
<a name="amazon-macie"></a>

[Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html)는 기계 학습과 패턴 일치를 사용하여 민감한 데이터를 검색하고, 데이터 보안 위험에 대한 가시성을 제공하며, 이러한 위험에 대한 보호를 자동화할 수 있는 서비스입니다. Macie는 Amazon S3 버킷의 보안 또는 개인 정보 보호와 관련하여 잠재적 정책 위반 또는 문제를 감지하면 조사 결과를 생성합니다. Macie는 조직이 규정 준수 노력을 지원하기 위해 자동화를 구현하는 데 사용할 수 있는 또 다른 도구입니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html#tool-macie)를 참조하세요.

Macie는 이름, 주소 및 신분을 식별할 수 있는 기타 속성과 같은 개인 식별 정보(PII)를 포함하여 점점 증가하는 대규모 민감한 데이터 유형 목록을 감지할 수 있습니다. 조직의 개인 데이터 정의를 반영하는 감지 기준을 정의하기 위해 [사용자 지정 데이터 식별자](https://docs.aws.amazon.com/macie/latest/user/custom-data-identifiers.html)를 생성할 수도 있습니다.

조직에서 개인 데이터가 포함된 Amazon S3 버킷에 대한 예방적 제어를 정의하면 Macie를 검증 메커니즘으로 사용하여 개인 데이터가 있는 위치를 지속적으로 재확인하고 개인 데이터를 보호하는 방법을 제공할 수 있습니다. 시작하려면 Macie를 활성화하고 [자동화된 민감한 데이터 검색](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd.html)을 구성합니다. Macie는 계정 및 간에 모든 S3 버킷의 객체를 지속적으로 분석합니다 AWS 리전. Macie는 개인 데이터가 상주하는 위치를 나타내는 대화형 히트 맵을 생성하고 유지 관리합니다. 자동화된 민감한 데이터 검색 기능은 비용을 절감하고 검색 작업을 수동으로 구성할 필요성을 최소화하도록 설계되었습니다. 자동화된 민감한 데이터 검색 기능을 기반으로 빌드하고 Macie를 사용하여 새 버킷 또는 기존 버킷의 새 데이터를 자동으로 감지한 다음 할당된 데이터 분류 태그와 비교하여 데이터를 검증할 수 있습니다. 적절한 개발 및 개인 정보 보호 팀에 잘못 분류되거나 분류되지 않은 버킷을 적시에 알리도록 이 아키텍처를 구성합니다.

를 사용하여 조직의 모든 계정에 대해 Macie를 활성화할 수 있습니다 AWS Organizations. 자세한 내용은 [Integrating and configuring an organization in Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/accounts-mgmt-ao-integrate.html)를 참조하세요.

# 보안 OU - 로그 아카이브 계정
<a name="log-archive-account"></a>

**설문 조사**  
여러분의 의견을 듣고 싶습니다. [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2) 조사에 참여하여 AWS PRA에 대한 피드백을 제공해 주십시오.

로그 아카이브 계정은 인프라, 서비스 및 애플리케이션 로그 유형을 중앙 집중화하는 위치입니다. 이 계정에 대한 자세한 내용은 [AWS 보안 참조 아키텍처(AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/log-archive.html)를 참조하세요. 로그 전용 계정을 사용하면 모든 로그 유형에서 일관된 알림을 적용하고 인시던트 대응 담당자가 한 곳에서 이러한 로그의 집계에 액세스할 수 있는지 확인할 수 있습니다. 한 곳에서 보안 제어 및 데이터 보존 정책도 설정할 수 있으므로 개인 정보 보호 운영 오버헤드를 단순화할 수 있습니다. 다음 다이어그램에서는 로그 아카이브 계정에 구성된 AWS 보안 및 개인 정보 보호 서비스를 보여줍니다.

![\[AWS 서비스 보안 조직 단위의 로그 아카이브 계정에 배포됩니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/Account-Log-Archive.png)


## 중앙 집중식 로그 스토리지
<a name="centralized-log-storage"></a>

로그 파일(예: AWS CloudTrail 로그)에는 개인 데이터로 간주될 수 있는 정보가 포함될 수 있습니다. 일부 조직은 가시성을 위해 조직 추적을 사용하여 계정 간 AWS 리전 및 계정 간 CloudTrail 로그를 하나의 중앙 위치로 집계하기로 선택합니다. 자세한 내용은 이 안내서의 [AWS CloudTrail](security-tooling-account.md#aws-cloudtrail) 섹션을 참조하세요. CloudTrail 로그의 중앙 집중화를 구현할 때 로그는 일반적으로 단일 리전의 Amazon Simple Storage Service(Amazon S3) 버킷에 저장됩니다.

조직의 개인 데이터 정의, 고객에 대한 계약 의무 및 관련 리전 개인 정보 보호 규정에 따라 로그 집계와 관련하여 국가 간 데이터 전송을 고려해야 할 수도 있습니다. 다양한 로그 유형 내 개인 데이터가 이러한 제한 사항에 부합되는지 확인합니다. 예를 들어 CloudTrail 로그에는 조직의 직원 데이터가 포함될 수 있지만 고객의 개인 데이터는 포함되지 않을 수 있습니다. 조직에서 제한된 데이터 전송 요구 사항을 준수해야 하는 경우 다음 옵션을 통해 지원할 수 있습니다.
+ 조직에서 여러 국가의 데이터 주체 AWS 클라우드 에게의 서비스를 제공하는 경우 가장 엄격한 데이터 레지던시 요구 사항이 있는 국가의 모든 로그를 집계하도록 선택할 수 있습니다. 예를 들어 독일에서 운영 중이고 요구 사항이 가장 엄격한 경우 독일에서 수집된 데이터가 독일 국경을 벗어나지 `eu-central-1` AWS 리전 않도록의 S3 버킷에 데이터를 집계할 수 있습니다. 이 옵션의 경우 모든 계정에서 대상 리전으로 로그를 집계하는 단일 조직 추적을 CloudTrail AWS 리전 에서 구성할 수 있습니다.
+ 데이터를 복사하여 다른 리전으로 집계하기 AWS 리전 전에에 유지해야 하는 개인 데이터를 수정합니다. 예를 들어 로그를 다른 리전으로 전송하기 전에 애플리케이션의 호스트 리전에 있는 개인 데이터를 마스킹할 수 있습니다. 개인 데이터 마스킹에 대한 자세한 내용은 이 가이드의 [Amazon Data Firehose](personal-data-account.md#amazon-data-firehose) 섹션을 참조하세요.
+ 엄격한 데이터 주권 문제가 있는 경우 이러한 요구 사항을 AWS 리전 적용하는에서 별도의 다중 계정 랜딩 존을 유지할 수 있습니다. 이 경우 중앙 집중식 로깅을 위해 리전의 랜딩 존 구성을 단순화할 수 있습니다. 또한 추가 인프라 분리 이점을 제공하고 로그를 자체 리전에 로컬로 유지하는 데 도움이 됩니다. 법률 고문과 협력하여 범위 내에 있는 개인 데이터와 허용되는 리전 간 전송을 결정합니다. 자세한 내용은 이 안내서의 [글로벌 확장을 위한 전략 수립](global-expansion.md) 섹션을 참조하세요.

[서비스 로그](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html), 애플리케이션 로그 및 운영 체제(OS) 로그를 통해 Amazon CloudWatch를 사용하여 기본적으로 해당 계정 및 리전의 AWS 서비스 또는 리소스를 모니터링할 수 있습니다. 많은 사용자가 여러 계정 및 리전의 이러한 로그와 지표를 단일 계정으로 중앙 집중화하기로 선택합니다. 기본적으로 이러한 로그는 해당 계정 및 로그가 시작된 리전에 유지됩니다. 중앙 집중화를 위해 [구독 필터](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)와 [Amazon S3 내보내기 태스크](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)를 사용하여 데이터를 중앙 위치로 공유할 수 있습니다. 국가 간 데이터 전송 요구 사항이 있는 워크로드에서 로그를 집계할 때 적절한 필터와 내보내기 태스크를 포함하는 것이 중요할 수 있습니다. 워크로드의 액세스 로그에 개인 데이터가 포함된 경우 이러한 데이터가 특정 계정 및 리전으로 전송되거나 보존되는지 확인해야 할 수도 있습니다.

## Amazon Security Lake
<a name="security-lake"></a>

 AWS SRA에서 권장하는 대로 로그 아카이브 계정을 [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)의 위임된 관리자 계정으로 사용할 수 있습니다. 이렇게 하면 Security Lake는 다른 SRA 권장 보안 로그와 동일한 계정의 전용 Amazon S3 버킷에서 지원되는 로그를 수집합니다.

개인 정보 보호 관점에서 인시던트 대응 담당자는 AWS 환경, SaaS 공급자, 온프레미스, 클라우드 소스 및 타사 소스의 로그에 액세스할 수 있어야 합니다. 그러면 개인 데이터에 대한 무단 액세스를 더 빠르게 차단하고 해결할 수 있습니다. Amazon Security Lake 내 로그 레지던시 및 리전 이동에도 로그 스토리지에 대한 동일한 고려 사항이 적용될 가능성이 큽니다. 이는 Security Lake가 서비스를 활성화한 AWS 리전 에서 보안 로그 및 이벤트를 수집하기 때문입니다. 데이터 레지던시 요구 사항을 준수하려면 [롤업 리전](https://docs.aws.amazon.com/security-lake/latest/userguide/add-rollup-region.html) 구성을 고려합니다. *롤업 리전*은 Security Lake가 선택한 하나 이상의 기여 리전의 데이터를 통합하는 리전으로, 사용자가 선택합니다. Security Lake 및 롤업 리전을 구성하기 전에 조직에서 데이터 레지던시에 대한 리전 규정 준수 요구 사항을 조정해야 할 수도 있습니다.

# 인프라 OU - Network 계정
<a name="network-account"></a>

**설문 조사**  
여러분의 의견을 듣고 싶습니다. [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2) 조사에 참여하여 AWS PRA에 대한 피드백을 제공해 주십시오.

네트워크 계정에서는 가상 프라이빗 클라우드(VPC) 및 더 광범위한 인터넷 사이에서 네트워킹을 관리합니다. 이 계정에서는를 사용하고 AWS WAF, AWS Resource Access Manager (AWS RAM)를 사용하여 VPC 서브넷 및 AWS Transit Gateway 연결을 공유하고, Amazon CloudFront를 사용하여 대상 서비스 사용을 지원하여 광범위한 공개 제어 메커니즘을 구현할 수 있습니다. 이 계정에 대한 자세한 내용은 [AWS 보안 참조 아키텍처(AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)를 참조하세요. 다음 다이어그램은 네트워크 계정에 구성된 AWS 보안 및 개인 정보 보호 서비스를 보여줍니다.

![\[AWS 서비스 인프라 조직 단위의 네트워크 계정에 배포됩니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/Account-Network.png)


**Topics**
+ [Amazon CloudFront](#cloudfront)
+ [AWS Resource Access Manager](#aws-ram-network)
+ [AWS Transit Gateway](#transit-gateway)
+ [AWS WAF](#aws-waf)

## Amazon CloudFront
<a name="cloudfront"></a>

[Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)는 프론트엔드 애플리케이션 및 파일 호스팅에 대한 지리적 제한을 지원합니다. CloudFront는 *엣지 로케이션*이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 전달할 수 있습니다. CloudFront를 통해 제공하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅됩니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html#network-cf)를 참조하세요.

개인 정보 보호 프로그램은 현재 특정 리전 법률 준수를 지원할 수 있습니다. 이러한 리전 내에만 상주하는 고객에게만 서비스를 제공하도록 워크로드 범위가 지정된 경우 다른 리전에서의 사용을 방지하는 기술적 조치를 구현할 수 있습니다. CloudFront 지리적 제한을 사용하여 특정 지리적 위치에 있는 사용자가 CloudFront 배포를 통해 배포한 콘텐츠에 액세스하는 것을 차단할 수 있습니다. 지리적 제한에 대한 구성 옵션과 자세한 내용은 CloudFront 설명서의 [콘텐츠의 지리적 배포 제한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html)을 참조하세요.

CloudFront에서 수신하는 모든 사용자 요청에 대한 세부 정보가 포함된 액세스 로그를 생성하도록 CloudFront를 구성할 수도 있습니다. 자세한 내용은 CloudFront 설명서의 [표준 로그(액세스 로그) 구성 및 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html)을 참조하세요. 마지막으로 CloudFront가 일련의 엣지 로케이션에서 콘텐츠를 캐싱하도록 구성된 경우 캐싱이 발생하는 위치를 고려할 수 있습니다. 일부 조직의 경우 교차 리전 캐싱에 국가 간 데이터 전송 요구 사항이 적용될 수 있습니다.

## AWS Resource Access Manager
<a name="aws-ram-network"></a>

[AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)를 사용하면에서 리소스를 안전하게 공유 AWS 계정 하여 운영 오버헤드를 줄이고 가시성 및 감사 가능성을 제공할 수 있습니다. AWS RAM를 사용하면 조직은 조직 AWS 계정 내 다른 나 타사 계정과 공유할 수 있는 AWS 리소스를 제한할 수 있습니다. 자세한 내용은 [공유 가능한 AWS 리소스를](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html) 참조하세요. 네트워크 계정에서 AWS RAM 를 사용하여 VPC 서브넷과 전송 게이트웨이 연결을 공유할 수 있습니다. AWS RAM 를 사용하여 다른와 데이터 영역 연결을 공유하는 경우 AWS 계정사전 승인 AWS 리전 되고 데이터 레지던시 요구 사항을 준수하는 연결인지 확인하는 프로세스를 설정하는 것이 좋습니다.

VPCs 및 전송 게이트웨이 연결을 공유하는 것 외에도를 사용하여 IAM 리소스 기반 정책을 지원하지 않는 리소스를 공유할 수 AWS RAM 있습니다. [개인 데이터 OU](personal-data-account.md)에서 호스팅되는 워크로드의 경우 AWS RAM 를 사용하여 별도의에 있는 개인 데이터에 액세스할 수 있습니다 AWS 계정. 자세한 내용은 *개인 데이터 OU – PD 애플리케이션 계정* 섹션의 [AWS Resource Access Manager](personal-data-account.md#aws-ram-pd-account)를 참조하세요.

## AWS Transit Gateway
<a name="transit-gateway"></a>

조직 데이터 레지던시 요구 사항에 AWS 리전 따라에서 개인 데이터를 수집, 저장 또는 처리하는 AWS 리소스를 배포하려는 경우 적절한 기술적 보호 조치가 있는 경우 가드레일을 구현하여 제어 및 데이터 영역에서 승인되지 않은 국가 간 데이터 흐름을 방지하는 것이 좋습니다. 컨트롤 플레인에서 IAM 및 서비스 제어 정책을 사용하여 리전 사용량을 제한하고 결과적으로 교차 리전 데이터 흐름을 제한할 수 있습니다.

데이터 플레인에서 교차 리전 데이터 흐름을 제어하는 여러 옵션이 있습니다. 예를 들어 라우팅 테이블, VPC 피어링 및 AWS Transit Gateway 연결을 사용할 수 있습니다. [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)는 가상 프라이빗 클라우드(VPC)와 온프레미스 네트워크를 연결하는 중앙 허브입니다. 더 큰 AWS 랜딩 존의 일부로 인터넷 게이트웨이, 직접 VPC-to-VPC 피어링, 리전 간 피어링을 AWS 리전통해 데이터를 탐색할 수 있는 다양한 방법을 고려할 수 있습니다 AWS Transit Gateway. 예를 들어 AWS Transit Gateway에서 다음을 수행할 수 있습니다.
+ VPC와 온프레미스 환경 간 동서 및 남북 연결이 개인 정보 보호 요구 사항에 부합하는지 확인합니다.
+ 개인 정보 보호 요구 사항에 따라 VPC 설정을 구성합니다.
+  AWS Organizations 및 IAM 정책에서 서비스 제어 정책을 사용하여 AWS Transit Gateway 및 Amazon Virtual Private Cloud(VPC) 구성의 수정을 방지할 수 있습니다. 서비스 제어 정책 샘플은 이 가이드의 [VPC 구성에 대한 변경 제한](restrict-changes-vpc-configurations.md) 섹션을 참조하세요.

## AWS WAF
<a name="aws-waf"></a>

개인 데이터의 의도하지 않은 공개를 방지하기 위해 웹 애플리케이션에 심층 방어 접근 방식을 배포할 수 있습니다. 애플리케이션에 입력 검증 및 속도 제한을 구축할 수 있지만 다른 방어선 역할을 할 AWS WAF 수 있습니다. [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)는 보호된 웹 애플리케이션 리소스로 전달되는 HTTP 및 HTTPS 요청을 모니터링하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html#network-waf)를 참조하세요.

를 사용하면 특정 기준을 검사하는 규칙을 정의하고 배포할 AWS WAF수 있습니다. 다음 활동은 의도하지 않은 개인 데이터 공개와 관련이 있을 수 있습니다.
+ 알 수 없거나 악의적인 IP 주소 또는 지리적 위치의 트래픽
+ SQL 주입과 같은 유출 관련 공격을 포함한 Open Worldwide Application Security Project(OWASP) [상위 10개 공격](https://owasp.org/www-project-top-ten/)
+ 높은 요청 속도
+ 일반 봇 트래픽
+ 콘텐츠 스크레이퍼

에서 관리하는 AWS WAF [규칙 그룹을](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-groups.html) 배포할 수 있습니다 AWS. 에 대한 일부 관리형 규칙 그룹을 사용하여 개인 정보 보호 및 개인 데이터에 대한 위협을 탐지할 AWS WAF 수 있습니다. 예를 들면 다음과 같습니다.
+ [SQL 데이터베이스](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-use-case.html#aws-managed-rule-groups-use-case-sql-db) - 이 규칙 그룹에는 SQL 인젝션 공격과 같은 SQL 데이터베이스 도용과 관련된 요청 패턴을 차단하도록 설계된 규칙이 포함되어 있습니다. 애플리케이션이 SQL 데이터베이스와 접속하는 경우 이 규칙 그룹을 고려합니다.
+ [알려진 잘못된 입력](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-known-bad-inputs) - 이 규칙 그룹에는 유효하지 않은 것으로 알려져 있으며 취약성의 도용 또는 발견과 관련된 요청 패턴을 차단하도록 설계된 규칙이 포함되어 있습니다.
+ [봇 컨트롤](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-bot.html) - 이 규칙 그룹에는 과도한 리소스를 소비하고, 비즈니스 지표를 왜곡하며, 가동 중지 시간을 유발하고, 악의적인 활동을 수행할 수 있는 봇의 요청을 관리하도록 설계된 규칙이 포함되어 있습니다.
+ [계정 탈취 방지(ATP)](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-atp.html) - 이 규칙 그룹에는 악의적인 계정 탈취 시도를 방지하도록 설계된 규칙이 포함되어 있습니다. 이 규칙 그룹은 애플리케이션의 로그인 엔드포인트로 전송된 로그인 시도를 검사합니다.

# 개인 데이터 OU - PD 애플리케이션 계정
<a name="personal-data-account"></a>

**설문 조사**  
여러분의 의견을 듣고 싶습니다. [간단한 설문](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2) 조사에 참여하여 AWS PRA에 대한 피드백을 제공해 주십시오.

개인 데이터(PD) 애플리케이션 계정은 조직에서 개인 데이터를 수집하고 처리하는 서비스를 호스팅하는 위치입니다. 특히 이 계정에서 개인 데이터로 정의한 내용을 저장할 수 있습니다. AWS PRA는 다중 계층 서버리스 웹 아키텍처를 통해 여러 예제 프라이버시 구성을 보여줍니다. AWS 랜딩 존에서 워크로드를 운영할 때 개인 정보 보호 구성을 one-size-fits-all 솔루션으로 간주해서는 안 됩니다. 예를 들어 기본 개념, 개인 정보 보호를 강화하는 방법, 조직에서 특정 사용 사례 및 아키텍처에 솔루션을 적용하는 방법을 이해하는 것이 목표일 수 있습니다.

개인 데이터를 수집, 저장 또는 처리하는 조직의 AWS 계정 에 AWS Organizations 및 AWS Control Tower 를 사용하여 기본적이고 반복 가능한 가드레일을 배포할 수 있습니다. 이러한 계정에 대한 전용 조직 단위(OU)를 설정하는 것이 중요합니다. 예를 들어 데이터 레지던시가 핵심 설계 고려 사항인 계정의 하위 세트에만 데이터 레지던시 가드레일을 적용할 수 있습니다. 많은 조직의 경우 개인 데이터를 저장하고 처리하는 계정이 이에 해당됩니다.

조직은 개인 데이터세트의 신뢰할 수 있는 소스를 저장하는 위치인 전용 데이터 계정을 지원하는 것을 고려할 수 있습니다. 신뢰할 수 있는 데이터 소스는 가장 신뢰할 수 있고 정확한 버전의 데이터로 간주될 수 있는 기본 버전의 데이터를 저장하는 위치입니다. 예를 들어 신뢰할 수 있는 데이터 소스의 데이터를 훈련 데이터, 고객 데이터의 하위 세트 및 수정된 데이터를 저장하는 데 사용되는 PD 애플리케이션 계정의 Amazon Simple Storage Service(Amazon S3) 버킷과 같은 다른 위치로 복사할 수 있습니다. 이 다중 계정 접근 방식을 사용하여 데이터 계정의 완전하고 확정적인 개인 데이터세트를 PD 애플리케이션 계정의 다운스트림 소비자 워크로드와 분리하면 계정에 대한 무단 액세스가 발생할 경우 영향 범위를 줄일 수 있습니다.

다음 다이어그램은 PD 애플리케이션 및 데이터 계정에 구성된 AWS 보안 및 개인 정보 보호 서비스를 보여줍니다.

![\[AWS 서비스 개인 데이터 애플리케이션 및 개인 데이터 OU의 데이터 계정에 배포됩니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/Account-PD-Application.png)


**Topics**
+ [Amazon Athena](#athena)
+ [Amazon Bedrock](#bedrock)
+ [AWS Clean Rooms](#clean-rooms)
+ [Amazon CloudWatch Logs](#cloudwatch-logs)
+ [Amazon CodeGuru Reviewer](#codeguru-reviewer)
+ [Amazon Comprehend](#comprehend)
+ [Amazon Data Firehose](#amazon-data-firehose)
+ [Amazon DataZone](#datazone)
+ [AWS Glue](#aws-glue)
+ [AWS Key Management Service](#aws-kms)
+ [AWS Lake Formation](#lake-formation)
+ [AWS 로컬 영역](#aws-local-zones)
+ [AWS Nitro Enclaves](#nitro-enclaves)
+ [AWS PrivateLink](#privatelink)
+ [AWS Resource Access Manager](#aws-ram-pd-account)
+ [Amazon SageMaker AI](#sagemaker)
+ [AWS 데이터 수명 주기를 관리하는 데 도움이 되는 기능](#manage-data-lifecycle)
+ [AWS 서비스 및 데이터를 세그먼트화하는 데 도움이 되는 기능](#segment-data)
+ [AWS 서비스 데이터 검색, 분류 또는 카탈로그 작성에 도움이 되는 및 기능](#discovery-classification)

## Amazon Athena
<a name="athena"></a>

개인 정보 보호 목표를 충족하기 위해 데이터 쿼리 제한 제어를 고려할 수 있습니다. [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html)는 표준 SQL을 사용하여 Amazon S3에 있는 데이터를 직접 분석할 수 있는 대화형 쿼리 서비스입니다. 데이터를 Athena에 로드할 필요가 없습니다. S3 버킷에 저장된 데이터를 직접 사용합니다.

Athena의 일반적인 사용 사례는 데이터 분석 팀에 맞춤형 데이터세트와 보안 삭제 처리된 데이터세트를 제공하는 것입니다. 데이터세트에 개인 데이터가 포함된 경우 데이터 분석 팀에 거의 가치를 제공하지 않는 개인 데이터의 전체 열을 마스킹하여 데이터세트를 보안 삭제 처리할 수 있습니다. 자세한 내용은 [ Amazon Athena를 사용하여 데이터 레이크의 데이터 익명화 및 관리를 참조하세요 AWS Lake Formation](https://aws.amazon.com/blogs/big-data/anonymize-and-manage-data-in-your-data-lake-with-amazon-athena-and-aws-lake-formation/)(AWS 블로그 게시물).

데이터 변환 접근 방식에 [Athena에서 지원되는 함수](https://docs.aws.amazon.com/athena/latest/ug/functions.html) 이외의 추가 유연성이 필요한 경우 [사용자 정의 함수(UDF)](https://docs.aws.amazon.com/athena/latest/ug/querying-udf.html)라고 하는 사용자 지정 함수를 정의할 수 있습니다. Athena에 제출된 SQL 쿼리에서 UDF를 간접 호출할 수 있으며 AWS Lambda에서 실행됩니다. `SELECT` 및 `FILTER SQL` 쿼리에서 UDF를 사용할 수 있으며 동일한 쿼리에서 여러 UDF를 간접 호출할 수 있습니다. 개인 정보 보호를 위해 열의 모든 값에서 마지막 4자만 표시하는 등 특정 유형의 데이터 마스킹을 수행하는 UDF를 생성할 수 있습니다.

## Amazon Bedrock
<a name="bedrock"></a>

[Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)은 AI21 Labs, Anthropic, Meta, Mistral AI, Amazon과 같은 선도적인 AI 회사의 파운데이션 모델에 대한 액세스를 제공하는 완전관리형 서비스입니다. 이를 통해 조직은 생성형 AI 애플리케이션을 빌드하고 규모를 조정할 수 있습니다. 어떤 플랫폼을 사용하든 생성형 AI를 사용하는 경우 조직은 개인 데이터의 잠재적 노출, 무단 데이터 액세스 및 기타 규정 준수 위반을 포함한 개인 정보 보호 위험에 직면할 수 있습니다.

[Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)는 Amazon Bedrock의 생성형 AI 워크로드에서 보안 및 규정 준수 모범 사례를 적용하여 이러한 위험을 완화하도록 설계되었습니다. AI 리소스의 배포 및 사용이 조직의 개인 정보 보호 및 규정 준수 요구 사항에 항상 부합되는 것은 아닙니다. 조직은 생성형 AI 모델을 사용하는 경우 데이터 개인 정보 보호를 유지 관리하는 데 어려움을 겪을 수 있습니다. 이러한 모델은 잠재적으로 민감한 정보를 기억하거나 재현할 수 있기 때문입니다. Amazon Bedrock Guardrails는 사용자 입력 및 모델 응답을 평가하여 개인 정보를 보호하는 데 도움이 됩니다. 전반적으로 입력 데이터에 개인 데이터가 포함된 경우 이 정보가 모델의 출력에 노출될 위험이 있습니다.

Amazon Bedrock Guardrails는 데이터 보호 정책을 적용하고 무단 데이터 노출을 방지하기 위한 메커니즘을 제공합니다. 여기에서는 입력에서 개인 데이터를 감지하고 차단하는 [콘텐츠 필터링 기능](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html), 부적절하거나 위험한 주제에 대한 액세스를 방지하는 데 도움이 되는 [주제 제한](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-denied-topics.html), 모델 프롬프트 및 응답에서 민감한 용어를 마스킹하거나 수정하는 [단어 필터](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-word-filters.html)를 제공합니다. 이러한 기능은 편향된 응답 또는 고객 신뢰 저하와 같이 개인 정보 보호 위반으로 이어질 수 있는 이벤트를 방지하는 데 도움이 됩니다. 이러한 기능을 사용하면 AI 모델에서 개인 데이터가 실수로 처리되거나 공개되지 않도록 할 수 있습니다. Amazon Bedrock Guardrails는 Amazon Bedrock 외부의 입력 및 응답 평가도 지원합니다. 자세한 내용은 [Implement model-independent safety measures with Amazon Bedrock Guardrails](https://aws.amazon.com/blogs/machine-learning/implement-model-independent-safety-measures-with-amazon-bedrock-guardrails/)(AWS 블로그 게시물)를 참조하세요.

Amazon Bedrock Guardrails를 사용하면 사실적 근거와 응답의 관련성을 평가하는 [컨텍스트 근거 검사](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html)를 사용하여 모델 할루시네이션의 위험을 제한할 수 있습니다. [검색 증강 생성(RAG)](https://aws.amazon.com/what-is/retrieval-augmented-generation/) 애플리케이션에서 서드 파티 데이터 소스를 사용하는 생성형 AI 고객 대면 애플리케이션을 배포하는 경우를 예로 들 수 있습니다. 컨텍스트 근거 검사를 사용하여 이러한 데이터 소스에 대한 모델 응답을 검증하고 부정확한 응답을 필터링할 수 있습니다. AWS PRA의 맥락에서는 워크로드 계정 전체에서 Amazon Bedrock 가드레일을 구현하여 각 워크로드의 요구 사항에 맞는 특정 프라이버시 가드레일을 적용할 수 있습니다.

## AWS Clean Rooms
<a name="clean-rooms"></a>

조직은 교차하거나 중첩되는 민감한 데이터세트를 분석하여 서로 협업할 방법을 찾고 있으므로 해당 공유 데이터의 보안 및 개인 정보 보호를 유지 관리하는 것이 중요합니다. [AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/userguide/what-is.html)는 조직이 원시 데이터 자체를 공유하지 않고 결합된 데이터세트를 분석할 수 있는 안전한 중립 환경인 *데이터 클린 룸*을 배포하는 데 도움이 됩니다. 또한 자신의 계정에서 데이터를 이동하거나 복사 AWS 하지 않고 기본 데이터 세트를 공개하지 않고도의 다른 조직에 대한 액세스를 제공하여 고유한 인사이트를 생성할 수 있습니다. 모든 데이터는 소스 위치에 남아 있습니다. 기본 제공 분석 규칙은 출력을 제한하고 SQL 쿼리를 제한합니다. 모든 쿼리가 로깅되고 협업 멤버는 데이터가 쿼리되는 방식을 볼 수 있습니다.

 AWS Clean Rooms 공동 작업을 생성하고 다른 AWS 고객을 해당 공동 작업의 구성원으로 초대할 수 있습니다. 한 멤버에게 멤버 데이터세트를 쿼리할 수 있는 권한을 부여하고 추가 멤버를 선택하여 해당 쿼리의 결과를 받도록 선택할 수 있습니다. 둘 이상의 멤버가 데이터세트를 쿼리해야 하는 경우 동일한 데이터 소스와 다른 멤버 설정으로 추가 협업을 생성할 수 있습니다. 각 멤버는 협업 멤버와 공유되는 데이터를 필터링할 수 있으며, 사용자 지정 분석 규칙을 사용하여 협업에 제공하는 데이터를 분석할 수 있는 방법에 대한 제한을 설정할 수 있습니다.

공동 작업에 제공되는 데이터와 다른 구성원이 데이터를 사용하는 방법을 제한하는 것 외에도는 프라이버시를 보호하는 데 도움이 되는 다음과 같은 기능을 AWS Clean Rooms 제공합니다.
+ *차등 프라이버시*는 데이터에 신중하게 보정된 양의 노이즈를 추가하여 사용자 개인 정보 보호를 개선하는 수학 기법입니다. 이를 통해 관심 값을 가리지 않고 데이터세트 내에서 개별 사용자 재식별 위험을 줄일 수 있습니다. [AWS Clean Rooms 차등 프라이버시](https://docs.aws.amazon.com/clean-rooms/latest/userguide/differential-privacy.html)를 사용하는 경우 차등 프라이버시에 대한 전문 지식은 필요하지 않습니다.
+ [AWS Clean Rooms ML](https://docs.aws.amazon.com/clean-rooms/latest/userguide/machine-learning.html)을 사용하면 둘 이상의 당사자가 데이터를 직접 서로 공유할 필요 없이 데이터에서 유사한 사용자를 식별할 수 있습니다. 이렇게 하면 협업 멤버가 다른 멤버의 데이터세트에서 개인을 식별할 수 있는 멤버십 추론 공격의 위험이 줄어듭니다. 유사 모델을 생성하고 유사 세그먼트를 생성하면 AWS Clean Rooms ML은 원본 데이터를 노출하지 않고 데이터 세트를 비교하는 데 도움이 됩니다. 이렇게 하면 멤버가 ML 전문 지식을 보유하거나 외부에서 작업을 수행할 필요가 없습니다 AWS Clean Rooms. 훈련된 모델의 전체 제어 및 소유권을 유지합니다.
+ [Cryptographic Computing for Clean Rooms(C3R)](https://docs.aws.amazon.com/clean-rooms/latest/userguide/crypto-computing.html)를 분석 규칙과 함께 사용하여 민감한 데이터에서 인사이트를 도출할 수 있습니다. 협업의 다른 당사자가 학습할 수 있는 내용을 암호화된 방식으로 제한합니다. C3R 암호화 클라이언트를 사용하면 데이터가 제공되기 전에 클라이언트에서 암호화됩니다 AWS Clean Rooms. 데이터 테이블은 Amazon S3에 업로드되기 전에 클라이언트 측 암호화 도구를 사용하여 암호화되므로 데이터는 암호화된 상태로 유지되며 처리 과정에서 해당 상태가 유지됩니다.

 AWS PRA에서는 데이터 계정에서 AWS Clean Rooms 공동 작업을 생성하는 것이 좋습니다. 이를 사용하여 암호화된 고객 데이터를 서드 파티와 공유할 수 있습니다. 제공된 데이터세트에 중복이 있는 경우에만 사용합니다. 중복을 확인하는 방법에 대한 자세한 내용은 AWS Clean Rooms 설명서의 [분석 규칙 나열](https://docs.aws.amazon.com/clean-rooms/latest/userguide/analysis-rules-list.html)을 참조하세요.

## Amazon CloudWatch Logs
<a name="cloudwatch-logs"></a>

[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)는 모든 시스템, 애플리케이션 및 AWS 서비스 의 로그를 중앙 집중화하여 모니터링하고 안전하게 보관할 수 있도록 도와줍니다. CloudWatch Logs에서는 신규 또는 기존 로그 그룹에 대한 [데이터 보호 정책](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-data-protection-policies.html)을 사용하여 개인 데이터의 공개 위험을 최소화할 수 있습니다. 데이터 보호 정책은 로그에서 개인 데이터와 같은 민감한 데이터를 감지할 수 있습니다. 데이터 보호 정책은 사용자가 AWS Management Console을 통해 로그에 액세스할 때 해당 데이터를 마스킹할 수 있습니다. 사용자가 워크로드의 전반적인 용도 사양에 따라 개인 데이터에 직접 액세스해야 하는 경우 해당 사용자에게 `logs:Unmask` 권한을 할당할 수 있습니다. 또한 계정 전체의 데이터 보호 정책을 생성하고 조직의 모든 계정에 이 정책을 일관되게 적용할 수 있습니다. 이 경우 CloudWatch Logs의 모든 현재 및 미래 로그 그룹에 대해 마스킹이 기본적으로 구성됩니다. 또한 감사 보고서를 활성화하고 다른 로그 그룹, Amazon S3 버킷 또는 Amazon Data Firehose로 전송하는 것이 좋습니다. 이러한 보고서에는 각 로그 그룹의 데이터 보호 조사 결과에 대한 자세한 레코드가 포함되어 있습니다.

## Amazon CodeGuru Reviewer
<a name="codeguru-reviewer"></a>

개인 정보 보호와 보안 모두의 차원에서 많은 조직이 배포 및 배포 후 단계 모두에서 지속적인 규정 준수를 지원하는 것이 중요합니다. AWS PRA에는 개인 데이터를 처리하는 애플리케이션의 배포 파이프라인에 선제적 제어가 포함되어 있습니다. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)는 Java, JavaScript 및 Python 코드에서 개인 데이터를 노출할 수 있는 잠재적 결함을 감지할 수 있습니다. 그리고 개발자에게 코드 개선을 위한 제안을 제공합니다. CodeGuru Reviewer는 광범위한 보안, 개인 정보 보호 및 일반적인 권장 사례에서 결함을 식별할 수 있습니다. 이 기능은 AWS CodeCommit, Bitbucket, GitHub 및 Amazon S3를 비롯한 여러 소스 제공업체와 함께 작동하도록 설계되었습니다. CodeGuru Reviewer가 감지할 수 있는 일부 개인 정보 보호 관련 결함은 다음과 같습니다.
+ SQL 인젝션
+ 보안되지 않은 쿠키
+ 누락된 권한 부여
+ 클라이언트 측 AWS KMS 재암호화

CodeGuru Reviewer가 감지할 수 있는 항목의 전체 목록은 [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/)를 참조하세요.

## Amazon Comprehend
<a name="comprehend"></a>

[Amazon Comprehend](https://docs.aws.amazon.com/comprehend/latest/dg/what-is.html)는 영어 텍스트 문서에서 인사이트 및 관계를 찾기 위해 기계 학습을 사용하는 자연어 처리(NLP) 서비스입니다. Amazon Comprehend는 정형, 반정형 또는 비정형 텍스트 문서에서 개인 데이터를 감지하고 수정할 수 있습니다. 자세한 내용은 Amazon Comprehend 설명서의 [Personally identifiable information (PII)](https://docs.aws.amazon.com/comprehend/latest/dg/pii.html)을 참조하세요.

Amazon Comprehend에는 AWS SDKs 통한 애플리케이션 통합을 위한 다양한 옵션이 있으므로 Amazon Comprehend를 사용하여 데이터를 수집, 저장 및 처리하는 다양한 위치에서 개인 데이터를 식별할 수 있습니다. Amazon Comprehend ML 기능을 사용하여 [애플리케이션 로그](https://aws.amazon.com/blogs/machine-learning/redacting-pii-from-application-log-output-with-amazon-comprehend/)(AWS 블로그 게시물), 고객 이메일, 지원 티켓 등의 개인 데이터를 감지하고 수정할 수 있습니다. PD 애플리케이션 계정의 아키텍처 다이어그램에서는 Amazon EC2의 애플리케이션 로그에 대해 이 함수를 수행하는 방법을 보여줍니다. Amazon Comprehend는 다음과 같은 두 가지 수정 모드를 제공합니다.
+ `REPLACE_WITH_PII_ENTITY_TYPE`은 각 PII 엔터티를 해당 유형으로 바꿉니다. 예를 들어 **Jane Doe**는 **NAME**으로 대체됩니다.
+ `MASK`는 PII 엔터티의 문자를 원하는 문자(\$1, \$1, \$1, %, &, *또는 @)로 바꿉니다. 예를 들어 ****Jane Doe****를 ***\$1\$1\$1\$1 \$1\$1\$1**로 바꿀 수 있습니다.

## Amazon Data Firehose
<a name="amazon-data-firehose"></a>

[Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)는 스트리밍 데이터를 캡처 및 변환하고 Amazon Managed Service for Apache Flink 또는 Amazon S3와 같은 다운스트림 서비스로 로드하는 데 사용할 수 있습니다. Firehose는 처음부터 처리 파이프라인을 빌드할 필요 없이 애플리케이션 로그와 같은 대량의 스트리밍 데이터를 전송하는 데 자주 사용됩니다.

Lambda 함수를 사용하여 데이터를 다운스트림으로 전송하기 전에 사용자 지정 또는 기본 제공 처리를 수행할 수 있습니다. 개인 정보 보호를 위해 이 기능은 데이터 최소화 및 국가 간 데이터 전송 요구 사항을 지원합니다. 예를 들어 Lambda 및 Firehose를 사용하여 로그 아카이브 계정에서 중앙 집중화하기 전에 다중 리전 로그 데이터를 변환할 수 있습니다. 자세한 내용은 [Biogen: Centralized Logging Solution for Multi Accounts](https://www.youtube.com/watch?v=m8xtR3-ZQs8)(YouTube 비디오)를 시청하세요. PD 애플리케이션 계정에서 Firehose 전송 스트림으로 로그를 푸시 AWS CloudTrail 하도록 Amazon CloudWatch 및를 구성합니다. Lambda 함수는 로그를 변환하여 로그 아카이브 계정의 중앙 S3 버킷으로 전송합니다. 개인 데이터가 포함된 특정 필드를 마스킹하도록 Lambda 함수를 구성할 수 있습니다. 그러면 AWS 리전에서 개인 데이터의 전송을 방지할 수 있습니다. 이 접근 방식을 사용하면 사후가 아니라 전송 및 중앙 집중화 이전에 개인 데이터가 마스킹됩니다. 국가 간 전송 요구 사항이 적용되지 않는 관할 구역의 애플리케이션의 경우 일반적으로 CloudTrail의 조직 추적을 통해 로그를 집계하는 것이 더 운영 효율적이고 비용 효율적입니다. 자세한 내용은 이 가이드의 *보안 OU - 보안 도구 계정* 섹션에서 [AWS CloudTrail](security-tooling-account.md#aws-cloudtrail)을 참조하세요.

## Amazon DataZone
<a name="datazone"></a>

조직은 AWS 서비스 와 같은를 통해 데이터를 공유하는 접근 방식을 확장함에 따라 데이터 소유자라는 데이터에 가장 익숙한 사람이 차등 액세스를 제어하도록 AWS Lake Formation하려고 합니다. 그러나 이러한 데이터 소유자는 동의 또는 국가 간 데이터 전송 고려 사항과 같은 개인 정보 보호 요구 사항을 알고 있을 수 있습니다. [Amazon DataZone](https://docs.aws.amazon.com/datazone/latest/userguide/what-is-datazone.html)은 데이터 소유자와 데이터 거버넌스 팀이 데이터 거버넌스 정책에 따라 조직 전체에서 데이터를 공유하고 소비할 수 있도록 지원합니다. Amazon DataZone에서 사업부(LOB)는 자체 데이터를 관리하며 카탈로그를 통해 이 소유권을 추적합니다. 이해 당사자는 비즈니스 작업의 일부로 데이터를 찾고 데이터에 대한 액세스를 요청할 수 있습니다. 데이터 게시자가 설정한 정책을 준수하는 한, 데이터 소유자는 관리자나 데이터 이동 없이 기본 테이블에 대한 액세스 권한을 부여할 수 있습니다.

개인 정보 보호 컨텍스트에서 Amazon DataZone은 다음 사용 사례 예제에서 유용할 수 있습니다.
+ 고객 대면 애플리케이션은 별도의 마케팅 LOB와 공유할 수 있는 사용량 데이터를 생성합니다. 마케팅을 옵트인한 고객의 데이터만 카탈로그에 게시되도록 해야 합니다.
+ 유럽 고객 데이터는 게시되지만 유럽 경제 지역(EEA)의 LOB에서만 이를 구독할 수 있습니다. 자세한 내용은 [Enhance data security with fine-grained access controls in Amazon DataZone](https://aws.amazon.com/blogs/big-data/enhance-data-security-with-fine-grained-access-controls-in-amazon-datazone/)을 참조하세요.

 AWS PRA에서는 공유 Amazon S3 버킷의 데이터를 데이터 생산자인 Amazon DataZone에 연결할 수 있습니다.

## AWS Glue
<a name="aws-glue"></a>

개인 데이터가 포함된 데이터세트를 유지 관리하는 작업은 개인 정보 보호 중심 설계의 주요 구성 요소입니다. 조직의 데이터는 정형, 반정형 또는 비정형 형태로 존재할 수 있습니다. 구조가 없는 개인 데이터세트에서는 데이터 최소화, 데이터 주체 요청의 일부로 단일 데이터 주체에 귀속된 데이터 추적, 일관된 데이터 품질 보장, 데이터세트의 전체 세분화 등 여러 개인 정보 보호 개선 작업을 수행하기 어려울 수 있습니다. [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html)는 완전관리형 추출, 전환, 적재(ETL) 서비스입니다. 데이터 스토어와 데이터 스트림 간에 데이터를 분류, 정리, 보강 및 이동하는 데 도움이 될 수 있습니다. AWS Glue 기능은 분석, 기계 학습 및 애플리케이션 개발을 위한 데이터 세트를 검색, 준비, 구조화 및 결합하는 데 도움이 되도록 설계되었습니다. AWS Glue 를 사용하여 기존 데이터 세트를 기반으로 예측 가능하고 일반적인 구조를 생성할 수 있습니다. AWS Glue Data Catalog AWS Glue DataBrew및 AWS Glue Data Quality는 조직의 개인 정보 보호 요구 사항을 지원하는 데 도움이 되는 AWS Glue 기능입니다.

### AWS Glue Data Catalog
<a name="aws-glue-data-catalog"></a>

[AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)는 유지 관리 가능한 데이터세트를 설정하는 데 도움이 됩니다. 데이터 카탈로그에는 추출, 변환 및 로드(ETL) 작업의 소스 및 대상으로 사용되는 데이터에 대한 참조가 포함되어 있습니다 AWS Glue. Data Catalog의 정보는 메타데이터 테이블로 저장되며, 각 테이블은 단일 데이터 저장소를 지정합니다. AWS Glue 크롤러를 실행하여 다양한 데이터 저장소 유형으로 데이터 인벤토리를 가져옵니다. [기본 제공 분류자와 사용자 지정 분류자](https://docs.aws.amazon.com/glue/latest/dg/add-classifier.html)를 크롤러에 추가합니다. 그러면 이러한 분류자가 개인 데이터의 데이터 형식과 스키마를 추론합니다. 크롤러는 메타데이터를 Data Catalog에 작성합니다. 중앙 집중식 메타데이터 테이블은 AWS 환경의 서로 다른 개인 데이터 소스에 구조와 예측 가능성을 추가하므로 데이터 주체 요청(예: 삭제 권한)에 더 쉽게 응답할 수 있습니다. Data Catalog를 사용하여 이러한 요청에 자동으로 응답하는 방법에 대한 포괄적인 예는 [ Amazon S3 Find and Forget을 사용하여 데이터 레이크에서 데이터 삭제 요청 처리(블로그 게시물)를 참조하세요](https://aws.amazon.com/blogs/big-data/handling-data-erasure-requests-in-your-data-lake-with-amazon-s3-find-and-forget/).AWS 마지막으로 조직에서 [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)을 사용하여 데이터베이스, 테이블, 행 및 셀에 대한 세분화된 액세스를 관리하고 제공하는 경우 Data Catalog는 주요 구성 요소입니다. 데이터 카탈로그는 교차 계정 데이터 공유를 제공하며 [태그 기반 액세스 제어를 사용하여 데이터 레이크를 대규모로 관리하는 데 도움이 됩니다](https://aws.amazon.com/blogs/big-data/easily-manage-your-data-lake-at-scale-using-tag-based-access-control-in-aws-lake-formation/)(AWS 블로그 게시물). 자세한 내용은 이 섹션의 [AWS Lake Formation](#lake-formation)을 참조하세요.

### AWS Glue DataBrew
<a name="aws-glue-databrew"></a>

[AWS Glue DataBrew](https://docs.aws.amazon.com/databrew/latest/dg/what-is.html)는 데이터를 정리하고 정규화하는 데 도움이 되며, 개인 식별 정보를 제거 또는 마스킹하고 데이터 파이프라인의 민감한 데이터 필드를 암호화하는 등 데이터에 대한 변환을 수행할 수 있습니다. 또한 데이터 리니지를 시각적으로 매핑하여 데이터가 거친 다양한 데이터 소스 및 변환 단계를 이해할 수 있습니다. 조직이 개인 데이터 출처를 더 잘 이해하고 추적하기 위해 노력함에 따라 이 기능은 점점 더 중요해지고 있습니다. DataBrew는 데이터 준비 중에 개인 데이터를 마스킹하는 데 도움이 됩니다. 데이터 프로파일링 작업 중에 개인 데이터를 감지하고 개인 데이터가 포함될 수 있는 열의 번호 및 잠재적 범주와 같은 통계를 수집할 수 있습니다. 그런 다음 코드를 작성하지 않고도 대체, 해싱, 암호화 및 암호 해독을 포함하여 기본 제공 가역 또는 비가역 데이터 변환 기술을 사용할 수 있습니다. 그런 다음 정리 및 마스킹 처리된 데이터세트를 분석, 보고 및 기계 학습 태스크에 대한 다운스트림으로 사용할 수 있습니다. DataBrew에서 사용할 수 있는 몇 가지 데이터 마스킹 기법은 다음과 같습니다.
+ **해싱** - 열 값에 해시 함수를 적용합니다.
+ **대체** - 개인 데이터를 다른 사실적인 값으로 바꿉니다.
+ **Null 처리 또는 삭제** - 특정 필드를 null 값으로 바꾸거나 열을 삭제합니다.
+ **마스킹** - 문자 스크램블링 기법을 사용하거나 열의 특정 부분을 마스킹합니다.

사용 가능한 암호화 기법은 다음과 같습니다.
+ **결정적 암호화** - 열 값에 결정적 암호화 알고리즘을 적용합니다. 결정적 암호화는 항상 값에 대해 동일한 사이퍼텍스트를 생성합니다.
+ **확률적 암호화** - 열 값에 확률적 암호화 알고리즘을 적용합니다. 확률적 암호화는 적용될 때마다 다른 사이퍼텍스트를 생성합니다.

DataBrew에서 제공된 개인 데이터 변환 레시피의 전체 목록은 [Personally identifiable information (PII) recipe steps](https://docs.aws.amazon.com/databrew/latest/dg/recipe-actions.pii.html)를 참조하세요.

### AWS Glue 데이터 품질
<a name="aws-glue-data-quality"></a>

[AWS Glue 데이터 품질](https://docs.aws.amazon.com/glue/latest/dg/glue-data-quality.html)은 데이터 파이프라인 간에 고품질 데이터를 데이터 소비자에게 전달하기 전에 사전에 데이터 파이프라인 간에 전송을 자동화하고 운영할 수 있도록 지원합니다. AWS Glue 데이터 품질은 데이터 파이프라인 전반의 데이터 품질 문제에 대한 통계 분석을 제공하고, [Amazon EventBridge에서 알림을 트리거](https://docs.aws.amazon.com/glue/latest/dg/data-quality-alerts.html)하고, 문제 해결을 위한 품질 규칙 권장 사항을 제공할 수 있습니다. AWS Glue 데이터 품질은 또한 [도메인별 언어로](https://docs.aws.amazon.com/glue/latest/dg/dqdl.html) 규칙 생성을 지원하므로 사용자 지정 데이터 품질 규칙을 생성할 수 있습니다.

## AWS Key Management Service
<a name="aws-kms"></a>

[AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)를 사용하면 암호화 키를 생성하고 제어하여 데이터를 보호할 수 있습니다.는 하드웨어 보안 모듈을 AWS KMS 사용하여 FIPS 140-2 암호화 모듈 검증 프로그램에 AWS KMS keys 따라 보호하고 검증합니다. 이 서비스가 보안 컨텍스트에서 사용되는 방법에 대한 자세한 내용은 [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html#tool-kms)를 참조하세요.

AWS KMS 는 암호화 AWS 서비스 를 제공하는 대부분의와 통합되며 개인 데이터를 처리하고 저장하는 애플리케이션에서 KMS 키를 사용할 수 있습니다. AWS KMS 를 사용하여 다음을 비롯해 다양한 개인 정보 보호 요구 사항을 지원하고 개인 데이터를 보호할 수 있습니다.
+ 강도, 교체, 만료 및 기타 옵션을 더 잘 제어하기 위해 [고객 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) 사용.
+ 전용 고객 관리형 키를 사용하여 개인 데이터 및 개인 데이터에 대한 액세스를 허용하는 보안 암호 보호.
+ 데이터 분류 수준을 정의하고 수준당 하나 이상의 전용 고객 관리형 키 지정. 예를 들어 운영 데이터를 암호화하는 키 하나와 개인 데이터를 암호화하는 다른 키 하나가 있을 수 있습니다.
+ KMS 키에 대한 의도하지 않은 교차 계정 액세스 방지.
+ 암호화할 리소스 AWS 계정 와 동일한 내에 KMS 키 저장.
+ KMS 키 관리 및 사용에 대한 업무 분리 구현. 자세한 내용은 [KMS 및 IAM을 사용하여 S3의 암호화된 데이터에 대한 독립적인 보안 제어를 활성화하는 방법](https://aws.amazon.com/blogs/security/how-to-use-kms-and-iam-to-enable-independent-security-controls-for-encrypted-data-in-s3/)(AWS 블로그 게시물)을 참조하세요.
+ 예방 및 사후 대응 가드레일을 통해 자동 키 교체 적용.

기본적으로 KMS 키는 저장되며 키가 생성된 리전에서만 사용할 수 있습니다. 조직에 데이터 레지던시 및 주권에 대한 특정 요구 사항이 있는 경우 [다중 리전 KMS 키](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)가 사용 사례에 적합한지 고려합니다. 다중 리전 키는 서로 바꿔서 사용할 수 AWS 리전 있는 다양한의 특수 목적 KMS 키입니다. 다중 리전 키를 생성하는 프로세스는 내 AWS 리전 경계를 넘어 키 구성 요소를 이동 AWS KMS하므로 이러한 리전 격리 부족은 조직의 주권 및 레지던시 목표와 호환되지 않을 수 있습니다. 이를 해결하는 한 가지 방법은 리전별 고객 관리형 키와 같은 서로 다른 유형의 KMS 키를 사용하는 것입니다.

### 외부 키 스토어
<a name="external-key-stores"></a>

많은 조직의 경우의 기본 AWS KMS 키 스토어는 데이터 주권 및 일반 규제 요구 사항을 충족할 AWS 클라우드 수 있습니다. 그러나 드물지만 암호화 키가 클라우드 환경 외부에서 생성 및 유지 관리되고 사용자에게 독립적인 권한 부여 및 감사 경로가 있어야 하는 경우가 있을 수 있습니다. 의 [외부 키 스토어](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html)를 사용하면 조직이 외부에서 소유하고 제어하는 키 구성 요소로 개인 데이터를 암호화 AWS KMS할 수 있습니다 AWS 클라우드. 여전히 평소와 같이 AWS KMS API와 상호 작용하지만는 사용자가 제공하는 [외부 키 스토어 프록시(XKS 프록시)](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html#concept-xks-proxy) 소프트웨어와만 AWS KMS 상호 작용합니다. 그러면 외부 키 스토어 프록시가 AWS KMS 와 외부 키 관리자 간의 모든 통신을 중재합니다.

데이터 암호화에 외부 키 저장소를 사용하는 경우 AWS KMS에서 키를 유지 관리하는 방식과 비교했을 때 추가 운영 오버헤드를 고려하는 것이 중요합니다. 외부 키 저장소를 사용하는 경우 사용자가 외부 키 저장소를 생성, 구성 및 유지 관리해야 합니다. 또한 XKS 프록시와 같이 유지 관리해야 하는 추가 인프라에 오류가 있고 연결이 끊어지면 사용자가 일시적으로 데이터를 해독하고 액세스하지 못할 수 있습니다. 규정 준수 및 규제 이해관계자와 긴밀히 협력하여 개인 데이터 암호화에 대한 법적 및 계약상의 의무와 가용성 및 복원력에 대한 서비스 수준 계약을 이해합니다.

## AWS Lake Formation
<a name="lake-formation"></a>

정형 메타데이터 카탈로그를 통해 데이터세트를 카탈로그화하고 분류하는 많은 조직이 조직 전체에서 해당 데이터세트를 공유하려고 합니다. AWS Identity and Access Management (IAM) 권한 정책을 사용하여 전체 데이터 세트에 대한 액세스를 제어할 수 있지만 민감도가 다양한 개인 데이터가 포함된 데이터 세트에는 더 세분화된 제어가 필요한 경우가 많습니다. 예를 들어 [용도 사양 및 사용 제한](https://www.fpc.gov/resources/fipps/)(FPC 웹 사이트)에서는 마케팅 팀이 고객 주소에 액세스해야 하지만 데이터 과학 팀은 액세스해서는 안 된다는 점을 표시할 수 있습니다.

[데이터 레이크](https://aws.amazon.com/big-data/datalakes-and-analytics/datalakes/)와 관련된 개인 정보 보호 문제도 있으며, 이는 원본 형식으로 대량의 민감한 데이터에 대한 액세스를 중앙 집중화합니다. 조직의 데이터 대부분은 한 곳에서 중앙 집중식으로 액세스할 수 있으므로 데이터세트, 특히 개인 데이터가 포함된 데이터세트의 논리적 분리가 가장 중요할 수 있습니다. [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)은 단일 소스에서든 데이터 레이크에 포함된 많은 소스에서든 데이터를 공유할 때 거버넌스 및 모니터링을 설정하는 데 도움이 될 수 있습니다. AWS PRA에서는 Lake Formation을 사용하여 데이터 계정의 공유 데이터 버킷에 있는 데이터에 대한 세분화된 액세스 제어를 제공할 수 있습니다.

Lake Formation에서 [태그 기반 액세스 제어](https://docs.aws.amazon.com/lake-formation/latest/dg/tag-based-access-control.html) 기능을 사용할 수 있습니다. *태그 기반 액세스 제어*는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. Lake Formation에서는 이러한 속성을 LF 태그라고 합니다.** LF 태그를 사용하면 이러한 태그를 데이터 카탈로그 데이터베이스, 테이블 및 열에 연결하고 IAM 위탁자에게 동일한 태그를 부여할 수 있습니다. 위탁자에게 리소스 태그 값과 일치하는 태그 값에 대한 액세스 권한이 부여되면 Lake Formation에서 해당 리소스에서의 작업을 허용합니다. 다음 이미지에서는 LF 태그 및 권한을 할당하여 개인 데이터에 대한 차별화된 액세스를 제공하는 방법을 보여줍니다.

![\[LF 태그는 팀이 액세스할 수 있는 테이블 열을 제어합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/lake-formation-tags.png)


이 예제에서는 태그의 계층 특성을 사용합니다. 두 데이터베이스 모두 개인 식별 정보(`PII:true`)를 포함하지만 열 수준의 태그는 특정 열을 서로 다른 팀으로 제한합니다. 이 예제에서는 `PII:true` LF 태그가 있는 IAM 보안 주체가이 태그가 있는 AWS Glue 데이터베이스 리소스에 액세스할 수 있습니다. `LOB:DataScience` LF 태그가 있는 위탁자는 이 태그가 있는 특정 열에 액세스할 수 있고, `LOB:Marketing` LF 태그가 있는 위탁자는 이 태그가 있는 열에만 액세스할 수 있습니다. 마케팅은 마케팅 사용 사례와 관련된 PII에만 액세스할 수 있으며 데이터 과학 팀은 사용 사례와 관련된 PII에만 액세스할 수 있습니다.

## AWS 로컬 영역
<a name="aws-local-zones"></a>

데이터 레지던시 요구 사항을 준수해야 하는 경우 이러한 요구 사항을 지원하기 AWS 리전 위해 특정에 개인 데이터를 저장하고 처리하는 리소스를 배포할 수 있습니다. 컴퓨팅, 스토리지[AWS 로컬 영역](https://docs.aws.amazon.com/local-zones/latest/ug/what-is-aws-local-zones.html), 데이터베이스 및 기타 일부 AWS 리소스를 대규모 인구 및 산업 센터와 가까운 곳에 배치하는 데 도움이 되는를 사용할 수도 있습니다. 로컬 영역은 대규모 대도시 지역과 지리적으로 가까운 AWS 리전 의 확장 기능입니다. 로컬 영역이 대응되는 리전 근처에서 로컬 영역 내에 특정 유형의 리소스를 배치할 수 있습니다. 로컬 영역은 동일한 법적 관할 구역 내에서 리전을 사용할 수 없는 경우 데이터 레지던시 요구 사항을 충족하는 데 도움이 될 수 있습니다. 로컬 영역을 사용하는 경우 조직 내에 배포된 데이터 레지던시 제어를 고려합니다. 예를 들어 특정 로컬 영역에서 다른 리전으로의 데이터 전송을 방지하기 위한 제어가 필요할 수 있습니다. SCPs를 사용하여 국가 간 데이터 전송 가드레일을 유지하는 방법에 대한 자세한 내용은 [랜딩 존 제어를 AWS 로컬 영역 사용하여에서 데이터 레지던시를 관리하는 모범 사례](https://aws.amazon.com/blogs/compute/best-practices-for-managing-data-residency-in-aws-local-zones-using-landing-zone-controls/)(AWS 블로그 게시물)를 참조하세요.

## AWS Nitro Enclaves
<a name="nitro-enclaves"></a>

Amazon Elastic Compute Cloud(Amazon EC2)와 같은 컴퓨팅 서비스를 사용하여 개인 데이터를 처리하는 등 처리 관점에서 데이터 세분화 전략을 고려합니다. 대규모 아키텍처 전략의 일환으로 기밀 컴퓨팅을 사용하면 격리되고 보호되며 신뢰할 수 있는 CPU 엔클레이브에서 개인 데이터 처리를 격리할 수 있습니다. 엔클레이브는 별도의 강화되고 고도로 제한된 가상 머신입니다. [AWS Nitro Enclaves](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html)는 이러한 격리된 컴퓨팅 환경을 생성하는 데 도움이 되는 Amazon EC2 기능입니다. 자세한 내용은 [AWS Nitro 시스템의 보안 설계](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html)(AWS 백서)를 참조하세요.

Nitro Enclaves는 상위 인스턴스의 커널과 분리된 커널을 배포합니다. 상위 인스턴스의 커널은 엔클레이브에 액세스할 수 없습니다. 사용자는 엔클레이브의 데이터 및 애플리케이션에 SSH 또는 원격으로 액세스할 수 없습니다. 개인 데이터를 처리하는 애플리케이션을 엔클레이브에 임베드하고 엔클레이브와 상위 인스턴스 간 통신을 용이하게 하는 소켓인 엔클레이브의 [Vsock](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave-concepts.html#term-socket)를 사용하도록 구성할 수 있습니다.

Nitro Enclaves가 유용할 수 있는 사용 사례 중 하나는 별도의에 AWS 리전 있고 서로 신뢰하지 않을 수 있는 두 데이터 프로세서 간의 공동 처리입니다. 다음 이미지에서는 중앙 처리에 엔클레이브를 사용하는 방법, 엔클레이브로 전송되기 전에 개인 데이터를 암호화하기 위한 KMS 키, 암호 해독을 요청하는 엔클레이브가 증명 문서에 고유한 측정값을 보유하는지를 확인하는 AWS KMS key 정책을 보여줍니다. 자세한 내용과 지침은 [에서 암호화 증명 사용을 참조하세요 AWS KMS](https://docs.aws.amazon.com/enclaves/latest/user/kms.html). 키 정책 샘플은 이 가이드의 [AWS KMS 키를 사용하려면 증명이 필요합니다.](require-attestation-for-kms-key.md) 섹션을 참조하세요.

![\[AWS Nitro Enclave를 사용하여 서로 다른 계정의 Amazon S3 버킷에서 암호화된 데이터를 처리합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/privacy-reference-architecture/images/nitro-enclave.png)


이 구현에서는 각 데이터 프로세서와 기본 엔클레이브만 일반 텍스트 개인 데이터에 액세스할 수 있습니다. 각 데이터 프로세서 환경 외부에서 데이터가 노출되는 유일한 위치는 액세스 및 변조를 방지하도록 설계된 엔클레이브 자체에 있습니다.

## AWS PrivateLink
<a name="privatelink"></a>

많은 조직이 신뢰할 수 없는 네트워크에 개인 데이터가 노출되지 않도록 제한하려고 합니다. 예를 들어 전체 애플리케이션 아키텍처 설계의 개인 정보 보호를 개선하려는 경우 데이터 민감도([AWS 서비스 및 데이터를 세그먼트화하는 데 도움이 되는 기능](#segment-data) 섹션에서 논의한 데이터세트의 논리적 및 물리적 분리와 유사)를 기반으로 네트워크를 세분화할 수 있습니다. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)는 가상 프라이빗 클라우드(VPC)에서 VPC 외부의 서비스에 대한 단방향 프라이빗 연결을 생성하는 데 도움이 됩니다. AWS PrivateLink를 사용하면 환경에서 개인 데이터를 저장하거나 처리하는 서비스에 대한 전용 프라이빗 연결을 설정할 수 있습니다. 이 경우 퍼블릭 엔드포인트에 연결하고 신뢰할 수 없는 퍼블릭 네트워크를 통해 이 데이터를 전송할 필요가 없습니다. 범위 내 서비스에 대해 AWS PrivateLink 서비스 엔드포인트를 활성화하면 통신하기 위해 인터넷 게이트웨이, NAT 디바이스, 퍼블릭 IP 주소, AWS Direct Connect 연결 또는 AWS Site-to-Site VPN 연결이 필요하지 않습니다. AWS PrivateLink 를 사용하여 개인 데이터에 대한 액세스를 제공하는 서비스에 연결하는 경우 조직의 [데이터 경계](https://aws.amazon.com/identity/data-perimeters-on-aws/) 정의에 따라 VPC 엔드포인트 정책 및 보안 그룹을 사용하여 액세스를 제어할 수 있습니다. 신뢰할 수 있는 조직의 IAM 원칙 및 AWS 리소스만 서비스 엔드포인트에 액세스할 수 있도록 허용하는 샘플 VPC 엔드포인트 정책은이 가이드[VPC 리소스에 액세스하려면 조직 멤버십 필요](require-organization-membership.md)의 섹션을 참조하세요.

## AWS Resource Access Manager
<a name="aws-ram-pd-account"></a>

[AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)를 사용하면에서 리소스를 안전하게 공유 AWS 계정 하여 운영 오버헤드를 줄이고 가시성 및 감사 가능성을 제공할 수 있습니다. 다중 계정 세분화 전략을 계획할 때는 AWS RAM 를 사용하여 별도의 격리된 계정에 저장하는 개인 데이터 스토어를 공유하는 것이 좋습니다. 처리를 목적으로 해당 개인 데이터를 신뢰할 수 있는 다른 계정과 공유할 수 있습니다. 에서는 공유 리소스에서 수행할 AWS RAM수 있는 작업을 정의하는 [권한을 관리할](https://docs.aws.amazon.com/ram/latest/userguide/security-ram-permissions.html) 수 있습니다. 에 대한 모든 API 호출 AWS RAM 은 CloudTrail에 로깅됩니다. 또한 리소스 공유가 변경되는 경우 AWS RAM와 같은의 특정 이벤트에 대해 자동으로 알리도록 Amazon CloudWatch Events를 구성할 수 있습니다.

IAM의 AWS 리소스 기반 정책 또는 Amazon S3의 버킷 정책을 AWS 계정 사용하여 다양한 유형의 리소스를 다른와 공유할 수 있지만,는 프라이버시에 대한 몇 가지 추가 이점을 AWS RAM 제공합니다.는 데이터 소유자에게 다음을 AWS 계정포함하여에서 데이터가 공유되는 방식과 대상에 대한 추가 가시성을 AWS 제공합니다.
+ 계정 ID 목록을 수동으로 업데이트하는 대신, 전체 OU와 리소스 공유 가능
+ 소비자 계정이 조직에 속하지 않은 경우 공유 시작을 위해 초대 프로세스 적용
+ 각 개별 리소스에 액세스할 수 있는 특정 IAM 위탁자에 대한 가시성

이전에 리소스 기반 정책을 사용하여 리소스 공유를 관리하고 AWS RAM 대신를 사용하려면 [PromoteResourceShareCreatedFromPolicy](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) API 작업을 사용합니다.

## Amazon SageMaker AI
<a name="sagemaker"></a>

[Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/implement-model-independent-safety-measures-with-amazon-bedrock-guardrails/)는 ML 모델을 빌드하고 훈련시킨 후 모델을 프로덕션 지원 호스팅 환경에 배포할 수 있는 관리형 기계 학습(ML) 서비스입니다. SageMaker AI는 훈련 데이터를 더 쉽게 준비하고 모델 기능을 생성할 수 있도록 설계되었습니다.

### Amazon SageMaker Model Monitor
<a name="sagemaker-model-monitor"></a>

많은 조직에서 ML 모델을 훈련할 때 데이터 드리프트를 고려합니다. 데이터 드리프트는 프로덕션 데이터와 ML 모델 학습에 사용된 데이터 간의 상당한 차이 또는 시간 경과에 따른 입력 데이터의 의미 있는 변화입니다. 데이터 드리프트는 ML 모델 예측의 전반적인 품질, 정확성 및 공정성을 저하시킬 수 있습니다. 프로덕션 환경에서 ML 모델이 수신하는 데이터의 통계적 속성이 훈련 받은 기준 데이터의 속성과 멀어지면 모델의 예측 정확도가 떨어질 수 있습니다. [Amazon SageMaker Model Monitor](https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html)는 프로덕션에서 Amazon SageMaker AI 기계 학습 모델의 품질을 지속적으로 모니터링하고 데이터 품질을 모니터링합니다. 데이터 드리프트를 조기에 선제적으로 감지하면 모델 재훈련, 업스트림 시스템 감사 또는 데이터 품질 문제 수정과 같은 수정 조치를 구현하는 데 도움이 될 수 있습니다. Model Monitor를 사용하면 모델을 수동으로 모니터링하거나 추가 도구를 빌드가 필요성이 줄어듭니다.

### Amazon SageMaker Clarify
<a name="sagemaker-clarify"></a>

[Amazon SageMaker Clarify](https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-configure-processing-jobs.html)는 모델 편향과 설명 가능성에 대한 인사이트를 제공합니다. SageMaker Clarify는 ML 모델 데이터 준비 및 전반적인 개발 단계에서 일반적으로 사용됩니다. 개발자는 성별이나 연령과 같은 관심 속성을 지정할 수 있으며, SageMaker Clarify는 알고리즘 세트를 실행하여 해당 속성에 편향이 있는지를 감지합니다. 알고리즘이 실행된 후 SageMaker Clarify는 잠재적 편향의 가능한 원인 및 관련 측정값에 대한 설명이 포함된 시각적 보고서를 제공해주므로 사용자는 편향을 해결하기 위한 단계를 식별할 수 있습니다. 다른 연령대에 비해 특정 연령대에 대해서는 사업자 대출 사례가 몇 건밖에 없는 금융 데이터세트를 예로 들면, SageMaker는 여기에 불균형 플래그를 지정하여 모델이 해당 연령대에 불리하게 작동하는 상황을 방지할 수 있도록 합니다. 예측을 검토하고 해당 ML 모델의 편향을 지속적으로 모니터링하여 이미 훈련된 모델의 편향을 확인할 수도 있습니다. 마지막으로 SageMaker Clarify는 [Amazon SageMaker AI Experiments](https://docs.aws.amazon.com/sagemaker/latest/dg/experiments.html)와 통합되어 모델의 전반적인 예측 생성 프로세스에 가장 많이 기여한 기능을 설명하는 그래프를 제공합니다. 이 정보는 설명 가능성 성과를 충족하는 데 유용할 수 있으며, 특정 모델 입력이 전반적인 모델 동작에서 원래보다 더 많은 영향을 주는지 확인하는 데 도움이 될 수 있습니다.

### Amazon SageMaker Model Card
<a name="sagemaker-model-card"></a>

[Amazon SageMaker Model Card](https://docs.aws.amazon.com/sagemaker/latest/dg/model-cards.html)를 사용하면 거버넌스 및 보고 목적으로 기계 학습(ML) 모델에 대한 중요한 세부 정보를 문서화할 수 있습니다. 이러한 세부 정보에는 모델 소유자, 범용, 의도한 사용 사례, 가정, 모델의 위험 등급, 훈련 세부 정보 및 지표, 평가 결과가 포함될 수 있습니다. 자세한 내용은 [AWS 인공 지능 및 Machine Learning 솔루션을 사용한 모델 설명 가능성](https://docs.aws.amazon.com/whitepapers/latest/model-explainability-aws-ai-ml/model-explainability-aws-ai-ml.html)(AWS 백서)을 참조하세요.

### Amazon SageMaker Data Wrangler
<a name="sagemaker-data-wrangler"></a>

[Amazon SageMaker Data Wrangler](https://aws.amazon.com/sagemaker/data-wrangler/)는 데이터 준비 및 특성 엔지니어링 프로세스를 간소화하는 데 도움이 되는 기계 학습 도구입니다. 데이터 과학자와 기계 학습 엔지니어가 기계 학습 모델에 사용할 데이터를 빠르고 쉽게 준비하고 변환할 수 있는 시각적 인터페이스를 제공합니다. Data Wrangler를 사용하면 Amazon S3, Amazon Redshift, Amazon Athena와 같은 다양한 소스에서 데이터를 가져올 수 있습니다. 그런 다음 코드를 작성하지 않고도 300개가 넘는 기본 제공 데이터 변환을 사용하여 기능을 정리, 정규화 및 결합할 수 있습니다.

Data Wrangler는 AWS PRA의 데이터 준비 및 기능 엔지니어링 프로세스의 일부로 사용할 수 있습니다. 를 사용하여 저장 및 전송 중 데이터 암호화 AWS KMS를 지원하고 IAM 역할 및 정책을 사용하여 데이터 및 리소스에 대한 액세스를 제어합니다. AWS Glue 또는 [Amazon SageMaker 특성 저장소](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)를 통한 데이터 마스킹을 지원합니다. Data Wrangler를와 통합하면 세분화된 데이터 액세스 제어 및 권한을 적용할 AWS Lake Formation수 있습니다. Amazon Comprehend와 함께 Data Wrangler를 사용하여 광범위한 ML Ops 워크플로의 일부로 테이블 형식 데이터에서 개인 데이터를 자동으로 수정할 수도 있습니다. 자세한 내용은 [ Amazon SageMaker Data Wrangler를 사용하여 기계 학습을 위한 PII 자동 수정](https://aws.amazon.com/blogs/machine-learning/automatically-redact-pii-for-machine-learning-using-amazon-sagemaker-data-wrangler/)(AWS 블로그 게시물)을 참조하세요.

Data Wrangler의 다재다능한 기능은 계정 번호, 신용 카드 번호, 주민등록번호, 환자 이름, 의료 및 군사 기록 등 많은 산업에 민감한 데이터를 마스킹하는 데 도움이 됩니다. 민감한 데이터에 대한 액세스를 제한하거나 수정하도록 선택할 수 있습니다.

## AWS 데이터 수명 주기를 관리하는 데 도움이 되는 기능
<a name="manage-data-lifecycle"></a>

개인 데이터가 더 이상 필요하지 않은 경우 많은 데이터 저장소의 데이터에 대해 수명 주기 및 유지 시간 정책을 사용할 수 있습니다. 데이터 보존 정책을 구성할 경우 개인 데이터가 포함될 수 있는 다음 위치를 고려합니다.
+ Amazon DynamoDB 및 Amazon Relational Database Service(Amazon RDS)와 같은 데이터베이스
+ Amazon S3 버킷
+ CloudWatch 및 CloudTrail의 로그
+  AWS Database Migration Service (AWS DMS) 및 AWS Glue DataBrew 프로젝트의 마이그레이션에서 캐시된 데이터
+ 백업 및 스냅샷

다음 AWS 서비스 및 기능은 AWS 환경에서 데이터 보존 정책을 구성하는 데 도움이 될 수 있습니다.
+ [Amazon S3 수명 주기](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) - Amazon S3가 객체 그룹에 적용하는 작업을 정의하는 일련의 규칙. Amazon S3 수명 주기 구성에서 사용자를 대신해 Amazon S3가 만료된 객체를 삭제하는 시점을 정의하는 만료 작업을 생성할 수 있습니다. 자세한 내용은 [스토리지 수명 주기 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)를 참조하세요.
+ [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) - Amazon EC2에서 Amazon Elastic Block Store(Amazon EBS) 스냅샷 및 EBS 지원 Amazon Machine Image(AMI)의 생성, 보존 및 삭제를 자동화하는 정책을 생성합니다.
+ [Amazon DynamoDB 유지 시간(TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) - 항목이 더 이상 필요하지 않은 시점을 결정하는 항목별 타임스탬프를 정의합니다. 지정된 타임스탬프 날짜 및 시간이 지나면 바로 DynamoDB는 테이블에서 항목을 삭제합니다.
+ [CloudWatch Logs의 로그 보존 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) - 각 로그 그룹의 보존 정책을 1일에서 10년 사이의 값으로 조정할 수 있습니다.
+ [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) - 데이터 보호 정책을 중앙에서 배포하여 S3 버킷, RDS 데이터베이스 인스턴스, DynamoDB 테이블, EBS 볼륨 등 다양한 AWS 리소스에서 백업 활동을 구성, 관리 및 관리합니다. AWS 리소스 유형을 지정하여 리소스에 백업 정책을 적용하거나 기존 리소스 태그를 기반으로를 적용하여 추가 세부 수준을 제공합니다. 중앙 집중식 콘솔에서 백업 활동을 감사하고 보고하여 백업 규정 준수 요구 사항을 충족할 수 있습니다.

## AWS 서비스 및 데이터를 세그먼트화하는 데 도움이 되는 기능
<a name="segment-data"></a>

데이터 세분화는 별도의 컨테이너에 데이터를 저장하는 프로세스입니다. 이를 통해 각 데이터세트에 차별화된 보안 및 인증 조치를 제공하고 전체 데이터세트에 대한 노출의 영향 범위를 줄일 수 있습니다. 예를 들어 모든 고객 데이터를 하나의 대규모 데이터베이스에 저장하는 대신 이 데이터를 더 작고 관리 가능한 그룹으로 세분화할 수 있습니다.

물리적 및 논리적 분리를 사용하여 개인 데이터를 세분화할 수 있습니다.
+ **물리적 분리** - 데이터를 별도의 데이터 저장소에 저장하거나 데이터를 별도의 AWS 리소스에 배포하는 작업. 데이터가 물리적으로 분리되어 있지만 동일한 위탁자가 두 리소스에 모두 액세스할 수 있습니다. 따라서 물리적 분리와 논리적 분리를 결합하는 것이 좋습니다.
+ **논리적 분리** - 액세스 제어를 사용하여 데이터를 격리하는 작업. 직무에 따라 개인 데이터의 하위 세트에 대한 다양한 수준의 액세스가 필요합니다. 논리적 분리를 구현하는 정책 샘플은 이 가이드의 [Amazon DynamoDB의 특정 속성에 대한 액세스 권한 부여](grant-access-dynamodb-attributes.md) 섹션을 참조하세요.

논리적 및 물리적 분리의 조합은 직무 전반의 차별화된 액세스를 지원하기 위해 ID 기반 및 리소스 기반 정책을 작성할 때 유연성, 단순성 및 세분성을 제공합니다. 예를 들어 단일 S3 버킷에서 서로 다른 데이터 분류를 논리적으로 분리하는 정책을 생성하는 방법은 운영상 복잡할 수 있습니다. 각 데이터 분류에 전용 S3 버킷을 사용하면 정책 구성 및 관리가 단순해집니다.

## AWS 서비스 데이터 검색, 분류 또는 카탈로그 작성에 도움이 되는 및 기능
<a name="discovery-classification"></a>

일부 조직에서는 환경에서 추출, 적재, 변환(ELT) 도구를 사용하여 데이터의 선제적 카탈로그 작성을 시작하지 않았습니다. 이러한 고객은 초기 데이터 검색 단계에 있을 수 있습니다.이 단계에서는 고객이 저장하고 처리하는 데이터와 그 구조 및 분류 AWS 방식을 더 잘 이해하고 싶을 수 있습니다. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/data-classification.html)를 사용하여 Amazon S3에서 PII 데이터를 더 잘 이해할 수 있습니다. 그러나 Amazon Macie는 Amazon Relational Database Service(Amazon RDS) 및 Amazon Redshift와 같은 다른 데이터 소스를 분석하는 데 도움을 줄 수 없습니다. 더 큰 [데이터 매핑 연습](https://securiti.ai/blog/evolve-your-data-mapping/)을 시작할 때 두 가지 접근 방식을 사용하여 초기 검색을 가속화할 수 있습니다.
+ **수동 접근 방식** - 두 개의 열과 필요한 만큼의 행으로 테이블을 만듭니다. 첫 번째 열에서는 네트워크 패킷의 헤더 또는 본문이나 사용자가 제공하는 서비스에 존재할 수 있는 데이터 특성(예: 사용자 이름, 주소 또는 성별)을 작성합니다. 규정 준수 팀에 두 번째 열을 작성하도록 요청합니다. 두 번째 열에서는 데이터가 개인 데이터로 간주되는 경우 '예'를 입력하고 그렇지 않은 경우 '아니요'를 입력합니다. 종파 또는 의료 데이터와 같이 특히 민감한 정보로 간주되는 모든 유형의 개인 데이터를 표시합니다.
+ **자동화된 접근 방식** - AWS Marketplace를 통해 제공되는 도구를 사용합니다. 이러한 도구 중 하나가 [Securiti](https://securiti.ai/)입니다. 이러한 솔루션은 다른 클라우드 서비스 플랫폼의 자산뿐만 아니라 여러 AWS 리소스 유형의 데이터를 스캔하고 검색할 수 있는 통합을 제공합니다. 이러한 동일한 솔루션 중 상당수는 중앙 집중식 데이터 카탈로그에서 데이터 자산 및 데이터 처리 활동의 인벤토리를 지속적으로 수집하고 유지 관리할 수 있습니다. 도구를 사용하여 자동화된 분류를 수행하는 경우 조직의 개인 데이터 정의에 맞게 검색 및 분류 규칙을 조정해야 할 수도 있습니다.