Exam Prep Standard Course: AWS Certfied Data Engineer - Associate (4)

(4) 데이터 보안 및 거버넌스
4-1. Authentication(인증) 메커니즘 적용
Authentication 및 Authorization
- Authentication(인증): 귀하가 누구인지 식별하고 확인
- Authorization(권한 부여): 인증된 후 시스템 내에서 ID로서 액세스할 수 있는 항목 결정
AWS에서의 인증 방법
- AWS에서는 인증 방법을 통해 AWS 서비스 및 리소스에 대한 액세스 권한을 부여하기 전에 사용자 또는 리소스의 신원(identity) 확인
- AWS는 암호 기반, 인증서 기반, 역할 기반 인증을 포함한 다양한 인증 방법 지원
- 암호 기반 인증: 사용자가 설정한 비밀번호를 사용하여 로그인
- 인증서 기반 인증: SSL/TLS 인증서를 사용하여 신원(identity) 확인
- 역할 기반 인증: 역할을 가정하여 특정 권한을 부여받는 방식
AWS에서의 인증
- IAM은 AWS 리소스에 대한 접근을 안전하게 제어하는 데 도움이 되는 서비스
- IAM을 사용하여 누가 인증되고 리소스를 사용할 권한이 있는지 제어
- ID 페더레이션 지원
- IAM을 사용하면 데이터 엔지니어는 사용되는 각 사용자 및 AWS 서비스에 대해 최소 권한 원칙을 따르는 역할 설계 가능
AWS에서의 다양한 인증 방법
- AWS에서는 다음과 같은 다양한 방법으로 인증 가능
- AWS 계정 루트 사용자: 계정 생성 시 기본 제공, 모든 권한 보유
- IAM 사용자: 개별 사용자 계정, 특정 권한 보유
- IAM 역할: 특정 작업을 수행하기 위해 가정할 수 있는 임시 권한
- 연합된 ID: 외부 ID 공급자(SAML, OIDC)를 통해 제공된 자격 증명을 사용하여 로그인
AWS IAM Identity Center
- AWS IAM Identity Center를 사용하면 다중 계정 권한으로 직원 ID에 대한 로그인 보안 관리
- 직원 사용자에게 AWS 계정에 대한 액세스 권한을 할당하거나, 애플리케이션 할당으로 사용자에게 Single Sign-On 액세스 권한 할당
- SAML 2.0을 사용한 애플리케이션 또는 ID 센터로 자동 연결
AWS의 다양한 ID
- IAM 사용자: 단일 개인 또는 애플리케이션에 대한 특정 권한을 가진 AWS 계정 내의 자격 증명
- IAM 그룹: 동일한 권한이 필요한 사용자 그룹. 그룹으로 로그인할 수는 없지만 그룹을 사용하여 여러 사용자에 대한 권한 지정 가능
- 사용자와 역할의 차이: 사용자는 한 사람 또는 애플리케이션과 고유하게 연결되지만 역할은 필요한 사람이 누구나 맡을 수 있도록 설계됨
- 사용자는 영구 장기 자격 증명을 가지지만, 역할은 임시 자격 증명 제공
- 교차 계정 액세스: IAM 역할을 사용하여 다른 계정의 신뢰할 수 있는 보안 주체(trust principal)에게 계정 내 리소스에 액세스 권한 부여
AWS 서비스와 역할
- 일부 AWS 서비스는 다른 AWS 서비스의 기능 사용
- 예를 들어, 서비스를 호출하면 해당 서비스가 Amazon EC2에서 애플리케이션을 실행하거나 Amazon S3에 객체를 저장하는 것이 일반적
- 서비스는 호출 주체의 권한, 서비스 역할, 또는 서비스 연결 역할을 사용하여 작업 수행
- 서비스 역할: 특정 AWS 서비스가 다른 AWS 서비스에 접근하도록 허용
- 서비스 연결 역할: 특정 서비스에만 연결되는 사전 정의된 역할
IAM 역할 및 임시 자격 증명
- 시험에서는 임시 자격 증명으로 IAM 역할을 사용하기 위한 사용 사례와 시나리오 이해 필요
- 주체 권한, 서비스 역할, 서비스 연결 역할 간의 차이점 이해 필요
- 임시 자격 증명: AWS STS(Security Token Service)를 통해 제공, 특정 시간 동안 유효
인증서 기반 인증
- AWS 인증서 관리자(ACM)는 공개 및 비공개 SSL/TLS X.509 인증서와 키의 생성, 저장, 갱신 처리
- ACM에서 직접 발급하거나 타사 인증서를 ACM 관리 시스템으로 가져와 통합 AWS 서비스에 대한 인증서 제공 가능
- 내부 공개 키 인프라 어디에서나 사용할 수 있도록 AWS 사설 CA에서 서명한 ACM 인증서를 내보낼 수 있음
IAM 정책 관리
- IAM 정책: AWS의 리소스에 대해 수행할 수 있는 작업을 정의하는 문서
- 여러 유형의 정책이 있으며, IAM 신원(identity) 기반 정책, 신뢰(trust) 정책, 리소스 기반 정책 등이 포함
- 정책의 구조: 버전, 명령문, 효과, 작업, 리소스, 조건
정책의 유형
- IAM 신원(identity) 기반 정책: IAM 사용자, 그룹 또는 역할에 연결 가능
- 리소스 기반 정책: S3 버킷이나 AWS KMS 키와 같은 AWS 리소스에 직접 연결
- IAM 역할은 신뢰(trust) 정책과 신원(identity) 기반 정책 두 가지 정책 필요
- 신뢰(trust) 정책: 역할을 맡을 수 있는 주체 정의
- 신원(identity) 기반 정책: 주체가 수행할 수 있는 작업 정의
IAM 정책 적용
- IAM 정책을 역할, 엔드포인트 및 서비스에 적용하는 방법 이해 필요
- 예를 들어, S3 접근 포인트는 리소스 사용자나 기타 조건별로 접근 포인트 사용을 제어할 수 있는 기능 제공
- 정책 적용 예시: 특정 S3 버킷에 대한 읽기/쓰기 권한 부여
AWS PrivateLink
- AWS PrivateLink에 대한 IAM 정책 적용 방법 이해 필요
- 기본적으로 사용자는 엔드포인트 작업에 대한 권한 없음
- 예를 들어, 엔드포인트를 생성, 수정, 설명 및 삭제할 수 있는 권한을 부여하는 신원(identity) 기반 정책 생성 가능
- PrivateLink: VPC 간 또는 VPC와 온프레미스 간의 비공개 연결 제공
API Gateway와 IAM
- API Gateway와 IAM 권한으로 API 접근을 제어하는 방법 이해 필요
- API 개발자와 호출자에게 필요한 IAM 권한 정책 생성 필요
- 해당 정책을 사용자, 역할 또는 그룹에 연결 필요
- API 개발자 권한: API 생성, 업데이트, 배포, 보기, 삭제 권한
- API 호출자 권한: API 메서드 호출, API 캐싱 갱신 권한
Lambda와의 통합
- API Gateway가 Lambda와 통합된 경우 필요한 권한 설정
- API Gateway 유형의 IAM 역할을 생성하고, Lambda 함수를 호출할 수 있는 IAM 권한 정책 추가 필요
- Lambda 호출 권한: lambda:InvokeFunction
AWS Secrets Manager
- AWS Secrets Manager: 애플리케이션 서비스 및 리소스에 대한 접근을 보호하는 비밀 관리 서비스
- IAM 및 AWS Key Management Service와 통합하여 비밀 암호화 및 회전 지원
- 비밀의 수명 주기 관리: 생성, 저장, 사용, 삭제
- 비밀 회전: 주기적으로 비밀을 갱신하여 보안 강화
QuickSight와 교차 서비스 접근
- QuickSight를 S3 버킷에 접근할 수 있도록 권한 설정 방법 이해 필요
- QuickSight 콘솔에서 새 S3 버킷에 대한 권한 구성 필요
- QuickSight와 S3 통합: 데이터 시각화를 위한 접근 권한 설정
4-2. Authorization(권한 부여) 메커니즘 적용
최소 권한 원칙
- 목표: 최소한의 권한으로 대상 리소스에 액세스할 수 있는 권한이 있는 인증된 주체를 위한 것
- AWS에서는 보안 정책을 프로그래밍 방식으로 구축하고 파이프라인에서 코드로 관리 가능
- 애플리케이션 코드와 함께 소프트웨어 개발에서와 마찬가지로 파이프라인에서 정책 자동화를 테스트하여 정책이 예상대로 작동하는지 확인하고 검증 가능
정책 기반 인증 메커니즘
- 예: IAM Access Analyzer를 사용하여 고객의 AWS 계정 외부에서 액세스할 수 있는 리소스를 식별하기 위해 정책에 부여된 권한을 지속적으로 평가
- AWS Organizations를 사용하여 여러 계정에 정책 시행 가능
정책 유형
- 각 정책은 AWS 또는 귀하가 생성하고 관리
- 역할 기반 액세스 제어(Role-Based Access Control, RBAC), 속성 기반 액세스 제어(Attribute-Based Access Control, ABAC) 사용 가능
- ID를 인증하는 방법에 관계없이 계정 내 및 계정 간에 ID 전체에서 정책을 공유하거나 재사용 가능
역할 기반 액세스 제어(RBAC)
- 역할을 기반으로 리소스에 대한 액세스 결정
- 예: 개발자 역할은 사용자에게 데이터 파이프라인이나 애플리케이션 내에서 개발 수행 권한 부여
- 장점: 관리 용이
- 단점: 여러 역할에 걸쳐 권한이 필요한 사용자나 복잡한 비즈니스 논리가 있는 경우 어려움
속성 기반 액세스 제어(ABAC)
- 속성을 기반으로 권한 정의
- IAM 사용자 또는 역할을 포함한 IAM 리소스와 AWS 리소스, 환경 또는 애플리케이션 상태에 태그 연결
- 예: access-project 태그 키를 사용하여 세 가지 역할 생성
- 첫 번째 역할: 태그 값 하트
- 두 번째 역할: 태그 값 스타
- 세 번째 역할: 태그 값 볼트
- 역할과 리소스에 동일한 값으로 태그가 지정될 때 액세스 권한 부여
- 장점: 동적, 상황별, 세분화된 권한 부여
- 단점: 구현 초기 복잡
하이브리드 접근 방식
- RBAC와 ABAC 결합
- 사용자의 역할과 할당된 권한을 추가 속성과 결합하여 액세스 결정
데이터베이스 사용자, 그룹, 역할 액세스 및 권한
- 예: Amazon Redshift
- Amazon Redshift SQL 명령 create user 또는 alter user를 사용하여 데이터베이스 사용자 생성 및 관리
- 데이터베이스 슈퍼 사용자는 사용자 생성 및 삭제 가능
- 데이터베이스 객체에 대한 소유권 및 권한 부여
- 권한 부여 및 취소는 개별 데이터베이스 객체에 대한 권한을 업데이트할 필요 없이 역할 수준에서 수행
- 데이터 레이크의 데이터에 대한 액세스 제어를 관리할 수 있는 단일 장소 제공
- 데이터베이스 테이블, 열, 행 및 셀 수준에서 데이터에 대한 액세스 제한
- IAM 사용자 및 역할과 사용자 및 그룹에 적용
- LF 태그 기반 액세스 제어: 사용자 지정 레이블을 생성하여 수백 또는 수천 개의 데이터베이스 권한 관리
- LF 태그를 정의하고 데이터베이스, 테이블, 열에 연결
- 다양한 데이터 소스에 저장된 데이터 세트에 대한 권한 설정 가능
AWS Systems Manager Parameter Store
- 비밀번호, 데이터베이스 문자열, 라이센스 코드 등의 데이터를 매개변수 값으로 저장 가능
- 저장된 암호에 대한 자동 교체 서비스는 제공하지 않음
- Secrets Manager를 사용하여 Parameter Store 구성 가능
보안 이해 및 제어
- 무단 액세스를 방지하는 방법과 폭발 반경을 제한하는 방법 이해
- 암호화, 토큰화, 데이터 분해, 사이버 속임수 등 다양한 기술 설명
4-3. 데이터 암호화 및 마스킹 보장
- AWS는 확장 가능하고 효율적인 암호화 기능을 제공하면서 저장 데이터와 전송 중인 데이터에 보안 계층 추가 가능
데이터 보호 중요성
- 모든 데이터가 합법적이고 공정하며 투명한 방식으로 처리되도록 설계 및 기본적으로 데이터 보호가 중요
- 모든 AWS 서비스는 저장 데이터와 전송 중인 데이터를 암호화하는 기능 제공
- AWS KMS는 데이터를 보호하는 데 사용되는 암호화 키를 생성하고 제어하는 관리형 서비스
AWS KMS와의 통합
- AWS KMS는 데이터를 암호화하는 대부분의 다른 AWS 서비스와 통합됨
- 예: AWS KMS는 CloudTrail과 통합되어 감사, 규제 및 규정 준수를 위한 AWS KMS 키 사용 기록
- AWS KMS API를 사용하여 AWS KMS 키 및 사용자 지정 키 스토어와 같은 기능 생성 및 관리
AWS CloudHSM
- 암호화 키를 생성, 저장 및 사용하는 AWS CloudHSM 디바이스를 직접 관리해야 하는 경우
- CloudHSM은 AWS에서 하드웨어 보안 모델을 제공
- 하드웨어 프로비저닝, 소프트웨어 패치, 네트워크 라우팅 및 키 스토어의 암호화된 백업 생성을 자동화
- CloudHSM 환경을 확장하고 HSM 내에서 암호화 계정과 자격 증명을 관리하는 것은 고객의 책임
네트워크 암호화
- AWS 데이터 센터 간의 모든 네트워크 트래픽은 물리적 계층에서 투명하게 암호화
- Amazon VPC 내 및 여러 지역에 걸쳐 피어링된 Amazon VPC 간의 모든 트래픽은 네트워크 계층에서 투명하게 암호화
- 애플리케이션 계층에서는 전송 계층 보안(TLS)과 같은 프로토콜 사용 가능
- 모든 AWS 서비스 엔드포인트는 TLS를 지원하여 API 요청을 위한 보안 HTTPS 연결 생성
TLS 종료 옵션
- TLS를 종료해야 하는 AWS 내 고객 관리형 인프라의 경우 네트워크 로드 밸런서, 애플리케이션 로드 밸런서, CloudFront 및 API Gateway와 같은 서비스 제공
- TLS 연결을 구현하기 위해 각 엔드포인트 서비스는 암호화 ID를 엔드포인트에 바인딩하기 위해 자체 디지털 인증서 업로드 기능 제공
저장 데이터 및 전송 중인 데이터 암호화
- AWS KMS, CloudHSM 및 ACM과 같은 서비스를 사용하여 암호화 전략 구현
- 특정 분류의 모든 데이터가 동일한 보안 태세를 공유하도록 할 수 있음
저장 데이터 암호화 이해
- Amazon EBS, Amazon S3, Amazon RDS, Amazon Redshift, ElastiCache, Lambda, Amazon EMR, AWS Glue 및 SageMaker와 같은 AWS 서비스 사용
- Amazon SQS용 서버 측 암호화(SSE)를 사용하여 중요한 데이터를 전송하기 위한 암호화된 메시지 대기열도 있음
로컬 디스크 암호화
- Amazon EMR 클러스터를 생성하고 Amazon EBS 볼륨이 암호화된 경우 로컬 디스크도 암호화되지 않음
- 보안 구성에 로컬 디스크 암호화를 추가하도록 선택 가능
- 데이터는 네트워크를 통해 기본 Amazon EBS 볼륨으로 전송되기 전에 EC2 하이퍼바이저에 의해 암호화됨
클라이언트 측 암호화와 서버 측 암호화
- 클라이언트 측 암호화(Client-Side Encryption): 데이터가 클라이언트에 의해 암호화되고 서버에 전송되기 전에 암호화된 상태로 저장
- 장점:
- 데이터가 서버에 도착하기 전에 암호화되어 전송 중에 발생할 수 있는 공격으로부터 보호
- 암호화 키를 클라이언트 측에서 관리하므로 서버 운영자가 데이터에 접근할 수 없음
- 단점:
- 클라이언트 측에서 암호화 키를 관리해야 하므로 키 관리가 복잡해질 수 있음
- 데이터 암호화 및 복호화에 필요한 연산을 클라이언트가 수행하므로 클라이언트의 성능에 부담이 될 수 있음
- 사용 예:
- 애플리케이션에서 중요한 데이터를 처리할 때 클라이언트 측에서 암호화하여 서버에 전송
- 브라우저 기반 애플리케이션에서 사용자 데이터를 암호화하여 서버로 전송
- 서버 측 암호화(Server-Side Encryption): 데이터가 서버에 도착한 후 서버에서 암호화되고 저장
- 장점:
- 데이터 암호화 및 복호화를 서버에서 처리하므로 클라이언트의 성능에 영향을 미치지 않음
- 서버 측에서 중앙 집중식으로 키 관리를 수행하므로 키 관리가 용이
- 단점:
- 데이터가 서버에 도착하기 전까지는 암호화되지 않으므로 전송 중에 공격에 노출될 가능성 있음
- 서버 운영자가 데이터에 접근할 수 있는 잠재적 위험 존재
- 사용 예:
- AWS S3에서 제공하는 서버 측 암호화(SSE)를 사용하여 데이터를 암호화
- 데이터베이스 서비스에서 데이터를 저장하기 전에 암호화하여 저장
- 주요 차이점:
- 암호화 위치: 클라이언트 측 암호화는 데이터가 클라이언트에서 암호화된 후 서버로 전송되며, 서버 측 암호화는 데이터가 서버에 도착한 후 암호화
- 키 관리: 클라이언트 측 암호화는 클라이언트가 암호화 키를 관리하며, 서버 측 암호화는 서버가 암호화 키를 관리
- 보안 범위: 클라이언트 측 암호화는 전송 중 데이터를 보호하므로 전송 중에 발생할 수 있는 공격으로부터 보호, 서버 측 암호화는 저장된 데이터를 보호
- 성능 영향: 클라이언트 측 암호화는 클라이언트의 성능에 영향을 미칠 수 있으며, 서버 측 암호화는 서버의 성능에 영향을 미칠 수 있음
루트 디바이스 볼륨 암호화
- Amazon EMR 클러스터의 모든 노드에 루트 디바이스 볼륨 암호화 요구 사항
- 사용자 지정 Amazon 머신 이미지(AMI)를 사용하여 Amazon EMR 클러스터 생성 가능
- AWS KMS 키를 사용하여 AMI의 Amazon EBS 루트 볼륨 암호화 가능
데이터 익명화, 마스킹 및 키 솔팅
- 암호화와 토큰화 차이 이해
- 암호화: 알고리즘을 사용하여 일반 텍스트를 암호 텍스트로 변환
- 토큰화: 데이터 조각을 토큰이라는 임의의 문자열로 변환
- 데이터 익명화: 데이터 세트에서 기밀 정보, 개인 정보 또는 민감한 정보를 제거
- 데이터 마스킹: 변경된 값으로 기밀 데이터를 모호하게 만듦
- 솔트: 데이터, 비밀번호 또는 암호 문구를 해시하는 단방향 함수에 대한 추가 입력으로 제공되는 무작위 데이터
AWS의 토큰화
- Amazon VPC에 토큰 볼트를 구성하여 중요한 정보를 암호화된 형식으로 저장
- 토큰화 서비스 제공을 전문으로 하는 여러 AWS 파트너 존재
안전한 토큰화 솔루션 설계
- API Gateway, Lambda, Amazon Cognito, DynamoDB 및 AWS KMS를 사용하는 서버리스 애플리케이션 설계
- 클라이언트는 Amazon Cognito로 인증하고 인증 토큰을 받음
- Lambda 함수는 요청에 민감한 정보를 제공하는 토큰화 계층을 호출
- AWS KMS를 호출하여 암호화 키를 얻고, DynamoDB 클라이언트 측 암호화 라이브러리를 사용하여 원본 텍스트를 암호화
데이터 웨어하우스의 민감한 데이터 보호
- Amazon Redshift에서 DDM(Dynamic Data Masking) 사용
- 마스킹 표현식이 하나 이상의 해당 열에 적용
- 특정 사용자 또는 RBAC로 생성한 사용자 정의 역할에만 적용 가능
- 셀 수준에서 DDM을 적용하여 다양한 수준의 난독화로 여러 마스킹 정책을 테이블의 동일한 열에 적용
4-4. 감사를 위한 로그 준비
데이터 로깅 및 모니터링
- 특정 규정 (예: HIPAA, PCI)에서는 특정 기간 동안 데이터를 보관하고, 요청 시 사용할 수 있도록 데이터를 검색할 수 있는 저장 및 보관 데이터 프로세스 필요
CloudWatch Logs 설정
- CloudWatch Logs를 사용하여 애플리케이션 데이터를 로깅
- 로그 그룹 생성 후 로그 스트림의 컨테이너로 사용하며, 로그에 대한 액세스를 구성하고 제어
- 기본적으로 CloudWatch Logs의 로그 데이터는 무기한 보관되며, 로그 보존 정책을 구성하여 로그 데이터를 보관할 기간 지정 가능
CloudTrail 사용
- CloudTrail을 사용하여 API 호출 추적
- CloudTrail 로그는 Amazon S3 또는 CloudWatch Logs로 전송되어 규정 준수 및 감사 목적으로 알림을 설정하고 분석 및 보관 가능
- CloudTrail Lake를 사용하여 AWS 계정 및 리전 전체의 CloudTrail 이벤트에 대해 중앙 집중식 로깅 쿼리 수행 가능
CloudTrail Lake 통합
- CloudTrail Lake 통합을 통해 AWS 외부의 사용자 활동 데이터를 기록하고 저장 가능
- 이벤트 데이터 저장소를 생성할 때 포함할 이벤트 유형 선택
- 이벤트 카테고리마다 고유한 이벤트 스키마를 사용하여 SQL JOIN 키워드를 통해 여러 이벤트 데이터 저장소에서 SQL 쿼리 실행 가능
- 태그 기반 권한 부여를 사용하여 이벤트 데이터 저장소에 대한 작업에 대한 액세스 제어 가능
CloudWatch와의 통합
- AWS CloudTrail Lake는 지난 한 시간 동안 또는 보존 기간 동안 이벤트 데이터 스토어에 수집된 데이터 양에 대한 정보를 보는 데 사용할 수 있는 CloudWatch 지표를 지원
Amazon EMR 로깅 및 감사 고려 사항
- Amazon EMR에서 클러스터를 설계할 때 디버깅 지원 수준 고려
- Amazon EMR은 로그 파일을 Amazon S3에 보관 가능
- 각 클러스터는 기본적으로 기본 노드에 로그 파일 작성
- Amazon EMR은 CloudTrail과 통합되어 모든 API 호출을 이벤트로 캡처 가능
로그 분석을 위한 AWS 서비스
- CloudWatch Logs Insights를 사용하여 로그 데이터를 검색하고 분석 가능
- 운영 문제에 대응하기 위한 쿼리 수행 가능
- Amazon Athena CloudWatch 커넥터를 사용하여 SQL로 로그 데이터 쿼리 가능
- CloudWatch Log 구독을 통해 OpenSearch Service 클러스터로 데이터를 실시간 스트리밍 가능
CloudWatch Log 구독 및 통합
- CloudWatch의 도움으로 모든 시스템, 애플리케이션 및 AWS 서비스 로그를 확장성이 뛰어난 단일 서비스로 통합 가능
- CloudWatch 이벤트를 사용하여 특정 기간 동안 시작하려는 서비스를 예약 가능
4-5. 데이터 개인 정보 보호 및 거버넌스 이해
PII 데이터와 데이터 주권
- 개인 식별 정보(PII) 데이터는 이름, 주소, 이메일, 전화번호, 주민등록번호, 금융정보 등 개인을 식별할 수 있는 모든 정보를 포함
- 데이터 주권은 데이터가 저장되는 물리적 위치와 관련된 법적 및 규제 요구 사항을 의미하며, 데이터가 특정 국가 또는 지역의 법률에 따라 보호 및 관리되는지 여부를 결정
- PII 데이터는 엄격한 규제 요구 사항에 따라 보호되어야 하며, 예를 들어 유럽의 GDPR(General Data Protection Regulation), 미국의 CCPA(California Consumer Privacy Act) 등 다양한 법률이 존재
- 데이터 주권을 준수하려면 데이터를 저장하고 처리하는 위치를 주의 깊게 선택해야 하며, 이를 통해 특정 국가 또는 지역의 법률을 준수할 수 있도록 해야 함
- AWS는 여러 리전에 걸쳐 데이터 센터를 운영하므로, 사용자는 데이터 주권 요구 사항을 충족할 수 있도록 데이터 저장 위치를 선택할 수 있음
- GDPR은 유럽 연합 내에서 수집된 개인 데이터를 EU 외부로 전송하는 것을 엄격히 규제
- 이를 준수하기 위해 AWS는 유럽 내 데이터 센터를 통해 데이터 주권 요구 사항을 충족할 수 있도록 지원
데이터 보호를 위한 AWS 솔루션
- AWS의 전체 수명 주기 동안 민감한 데이터를 보호하도록 설계된 솔루션 사용
- 전송 계층 보안(TLS)을 사용하여 개별 통신 채널을 통해 전송 중인 데이터를 보호
- 볼륨 암호화, 광 암호화 또는 데이터베이스 테이블 암호화를 사용하여 개별 스토리지 솔루션에 저장된 데이터를 보호 가능
필드 수준 암호화
- 필드 수준 암호화는 애플리케이션 페이로드의 구조를 유지하면서 중요한 데이터 필드를 개별적으로 보호하는 데 사용
- 전체 페이로드 암호화는 전체 애플리케이션 페이로드를 바이너리 blob으로 암호화하여 전체가 해독될 때까지 사용할 수 없음
- 민감한 데이터를 보호하여 수명 주기 전반에 걸쳐 노출을 줄이는 것이 모범 사례
- 수집 시 가능한 한 빨리 데이터를 보호하고 승인된 사용자와 애플리케이션만 필요할 때만 데이터에 액세스할 수 있도록 보장
CloudFront와 Lambda@Edge 통합
- CloudFront를 Lambda@Edge와 결합하여 AWS에서 수집 시 민감한 데이터를 보호
- 다운스트림 시스템은 민감한 데이터에 액세스할 수 없으므로 데이터 노출이 줄어들어 감사 목적으로 규정 준수 공간 최소화
안전한 데이터 레이크 구축
- 데이터를 마스킹하고 암호화하고 Lake Formation을 통해 세분화된 액세스를 활성화하여 안전한 데이터 레이크 구축 가능
- 중요한 데이터를 Amazon S3에 안전하게 저장하기 전에 식별, 마스킹 및 암호화
- Lake Formation을 사용하여 세분화된 액세스 권한을 정의하고 시행하여 데이터 분석가와 데이터 과학자에게 보안 액세스 제공
메시지 대기열 원격 측정 전송
- MQTT 메시지를 AWS IoT Core 주제로 보내는 진단 장치용으로 설계 가능
- Kinesis Data Firehose를 사용하여 Amazon S3에서 원시 데이터를 사전 처리하고 준비 가능
- ETL용 AWS Glue를 사용하여 Amazon Comprehend를 호출하여 민감한 정보를 식별 후 데이터 추가 처리
- Lake Formation을 사용하여 Athena를 사용하여 데이터를 쿼리하는 비즈니스 분석가 및 데이터 과학자에 대한 액세스를 제한하는 세분화된 권한 정의
데이터 수집 및 처리
- 하루에 4번, 6시간마다 실행되는 애플리케이션에서 원시 데이터 S3 버킷에 추가된 데이터를 처리
- ETL을 매일 수행하고 크롤러 작업을 실행하여 데이터를 카탈로그화, 검증 및 데이터 수정 또는 토큰화 프로세스 완료
- 추가 검증으로 인해 파이프라인 실행에 최소한 5~10분 추가 소요
- 개체에서 중요한 데이터 발견 시 승인 결정을 요청하는 이메일이 관리자에게 전송
IAM 관리형 정책
- IAM 관리형 정책을 사용하여 Lambda 함수가 애플리케이션의 일부인 AWS 리소스에 액세스할 수 있는 권한 부여
- S3 버킷은 다양한 처리 단계에서 데이터를 저장
- Step Functions는 비즈니스 로직에 대한 Lambda 함수를 조정
- Macie 민감한 데이터 검색 작업은 스캔 단계 S3 버킷에서 민감한 데이터를 스캔
- EventBridge 규칙은 반복 일정에 따라 Step Functions 워크플로 실행 시작
- Amazon SNS는 파이프라인에서 발견된 민감한 데이터를 검토하라는 알림 전송
- Amazon API Gateway REST API는 매뉴얼의 일부로 민감한 데이터 검토자의 결정 수신
백업 및 재해 복구 계획
- 백업 계획, 재해 복구 계획, 데이터 개인 정보 보호 전략 계획 필요
- 데이터 주권과 연결되는 허용되지 않는 AWS 리전으로의 데이터 백업 또는 복제 방지
데이터 레이크 환경
- 데이터 레이크 관리자, 데이터 엔지니어, 스토리지 관리자, 백업 관리자 등 여러 사용자가 있는 일반적인 데이터 레이크 환경
- S3 버전 관리, 동일 리전 복제, 리전 간 복제, S3 객체 잠금 등 버킷에 있는 데이터를 보호하는 S3 기능 구성
데이터 백업 및 복구
- 다양한 소스와 다양한 개발 단계의 데이터를 포함하는 데이터 레이크
- PII 정보가 포함된 원시 데이터의 경우 식별되지 않은 데이터를 대신 백업
- 중요한 데이터를 보관하는 S3 버킷에는 필요한 데이터 보호 수준을 나타내는 키-값 쌍 스키마로 태그 지정
백업 빈도 및 보존 기간
- Amazon S3용 AWS Backups를 사용하여 연속, 정기 또는 두 가지 유형의 백업 모두 생성하는 백업 계획 정의
- 연속 백업은 특정 시점 복원(PITR)에 유용
- 정기 백업 규칙은 PITR 규칙과 동일한 대상 저장소를 사용하여 규정 준수 요구 사항에 필요한 빈도와 보존 정의
- 데이터를 추가로 격리하고 보호하려면 대상으로 복사 기능 사용
백업 암호화
- 백업은 백업 볼트와 연결된 AWS KMS 키를 사용하여 암호화
- AWS Backup Audit Manager를 사용하여 데이터 보호 정책 준수 여부를 감사하고 보고
데이터 공유 권한 부여
- Amazon Redshift 객체에 대한 데이터 공유 권한 부여
- 데이터 공유 객체의 수명 주기는 생성부터 삭제까지 Amazon Redshift 객체와 동일한 패턴 따름
기밀 데이터 보호
- Amazon Redshift에 기밀 데이터가 포함된 새 테이블이 있으면 특정 사용자만 기밀 데이터가 포함된 열을 읽을 수 있도록 테이블 보호
- Lake Formation과 Amazon Redshift Spectrum이 하나의 솔루션
- Amazon Redshift에는 열 수준 액세스 제어 기능 존재
구성 변경 관리
- AWS Config를 켜면 계정에 존재하는 지원되는 AWS 리소스를 검색하고 각 리소스에 대한 구성 항목 생성
- AWS Config는 계정의 각 리소스에 대해 설명 또는 목록 API 호출을 호출하여 리소스에 대한 모든 변경 사항 추적
- AWS Config 규칙을 사용하는 경우 각 규칙은 규칙에 대한 평가 논리가 포함된 Lambda 함수와 연결
- 구성 변경 사항 및 알림을 Amazon SNS 주제로 스트리밍하도록 AWS Config 구성
Reference