데이터 보안에서 암호화는 자물쇠와 같습니다. 데이터를 읽을 수 없는 형태로 변환해서, 올바른 열쇠(키)가 없으면 내용을 알 수 없게 만듭니다. 클라우드에 데이터를 저장하거나 전송할 때 암호화는 선택이 아니라 필수입니다. 고객의 개인정보, 금융 데이터, 의료 기록 등을 다루는 데이터 파이프라인이라면 더욱 그렇습니다. 이 글에서는 AWS에서 데이터를 어떻게 암호화하고, 민감한 데이터를 어떻게 마스킹하며, 규정 준수를 어떻게 달성하는지 처음 배우는 분도 이해할 수 있도록 설명합니다.
저장 중 암호화 (Encryption at Rest)
저장 중 암호화는 데이터가 디스크나 스토리지에 보관될 때 암호화하는 것입니다. 누군가 물리적으로 하드드라이브를 훔쳐가도 암호화 키 없이는 데이터를 읽을 수 없습니다.
Amazon S3의 암호화 옵션
S3는 세 가지 서버 측 암호화(SSE, Server-Side Encryption) 방식을 제공합니다.
SSE-S3는 S3가 자체적으로 관리하는 키로 암호화하는 방식입니다. 추가 설정 없이 기본으로 활성화되며 추가 비용이 없습니다. 그러나 키를 AWS가 전적으로 관리하기 때문에 누가 어떤 키로 암호화했는지 감사 추적이 어렵습니다. 보안 요구사항이 높지 않은 일반 데이터에 적합합니다.
SSE-KMS는 AWS Key Management Service(KMS)의 고객 관리형 키(CMK)로 암호화하는 방식입니다. KMS 키를 직접 만들고 관리합니다. 가장 큰 장점은 감사 추적입니다. 누가 언제 어떤 키로 데이터에 접근했는지 CloudTrail에서 확인할 수 있습니다. 규정 준수가 필요한 금융, 의료, 정부 데이터에 적합합니다. 추가 비용이 발생하지만 보안성이 크게 높아집니다.
SSE-C는 고객이 직접 키를 관리하는 방식입니다. 데이터를 업로드할 때마다 암호화 키를 HTTP 헤더로 전달합니다. S3는 암호화/복호화만 수행하고 키를 저장하지 않습니다. 매우 높은 보안 요구사항에서 사용하지만, 키 관리를 직접 해야 하므로 운영 부담이 큽니다.
| 방식 | 키 관리 주체 | 감사 추적 | 추가 비용 | 사용 시나리오 | |-----|-----------|---------|---------|------------| | SSE-S3 | AWS 완전 관리 | 어려움 | 없음 | 일반 데이터 | | SSE-KMS | 고객 관리 (KMS) | CloudTrail 통해 가능 | KMS 요청당 비용 | 규정 준수 필요 데이터 | | SSE-C | 고객 직접 관리 | 없음 | 없음 | 극히 높은 보안 요구사항 |
!S3 서버 측 암호화 옵션 비교
Amazon Redshift의 암호화
Redshift는 클러스터 전체를 암호화하는 방식을 사용합니다. 클러스터를 생성할 때 암호화를 활성화하면 해당 클러스터의 모든 데이터, 백업, 스냅샷이 암호화됩니다. 나중에 암호화를 추가하거나 변경하려면 클러스터를 재시작해야 합니다.
KMS(Key Management Service)를 사용하면 AWS가 키 인프라를 관리하고 고객은 키 정책을 통해 누가 키를 사용할 수 있는지 제어합니다.
CloudHSM(Hardware Security Module)은 더 높은 수준의 보안이 필요할 때 사용합니다. 물리적 하드웨어 보안 모듈에서 키를 생성하고 관리합니다. 금융 규정이나 정부 규제에서 HSM이 요구되는 경우에 사용합니다. KMS보다 비용이 높지만 키가 절대로 하드웨어를 떠나지 않는다는 보장을 제공합니다.
DynamoDB와 EMR의 암호화
DynamoDB는 기본적으로 AWS 소유 키로 암호화됩니다. 추가 비용 없이 저장된 모든 데이터를 암호화합니다. 더 세밀한 제어가 필요하면 고객 관리형 키(CMK)로 전환할 수 있습니다.
EMR(Elastic MapReduce)은 여러 EC2 인스턴스로 이루어진 클러스터입니다. 각 인스턴스의 EBS 볼륨을 암호화하기 위해 LUKS(Linux Unified Key Setup)를 사용합니다. LUKS는 리눅스 수준의 디스크 암호화 표준으로, EMR 보안 구성에서 활성화합니다.
전송 중 암호화 (Encryption in Transit)
전송 중 암호화는 데이터가 네트워크를 통해 이동할 때 암호화하는 것입니다. 누군가 네트워크 트래픽을 가로채더라도 내용을 읽을 수 없게 합니다. 현대 인터넷에서 HTTPS를 사용하는 것이 대표적인 전송 중 암호화입니다.
TLS(Transport Layer Security)는 전송 중 암호화의 표준 프로토콜입니다. SSL의 후속 버전으로, 실무에서는 TLS와 SSL을 혼용해서 부르기도 합니다.
AWS 서비스별 전송 중 암호화 적용 방법:
S3의 경우, S3 버킷 정책에 aws:SecureTransport 조건을 추가하면 HTTP(암호화되지 않은) 연결을 거부하고 HTTPS만 허용합니다. 이 정책 없이는 누군가 HTTP로 S3에 접근해서 데이터를 가로챌 수 있습니다.
Redshift는 클러스터 파라미터 그룹에서 SSL 연결을 강제할 수 있습니다. require_ssl 파라미터를 true로 설정하면 SSL 없이 연결하려는 모든 시도가 거부됩니다.
EMR은 노드 간 통신(클러스터 내부)과 S3 등 외부 서비스와의 통신 모두에 전송 중 암호화를 활성화할 수 있습니다. EMR 보안 구성에서 설정합니다.
봉투 암호화 (Envelope Encryption)
봉투 암호화는 AWS KMS의 실제 동작 방식을 이해하는 데 핵심적인 개념입니다. 처음 들으면 복잡해 보이지만, 현실의 봉투 속 봉투 개념으로 이해하면 쉽습니다.
왜 봉투 암호화가 필요한가? AWS KMS는 직접 암호화할 수 있는 데이터 크기가 4KB로 제한됩니다. 하지만 실제 데이터는 수 GB에서 수 TB에 달합니다. 이 문제를 해결하기 위해 봉투 암호화를 사용합니다.
봉투 암호화의 동작 방식:
1단계: KMS에 GenerateDataKey를 요청합니다. KMS는 두 가지를 반환합니다. 하나는 평문(plaintext) 데이터 키이고, 다른 하나는 KMS 마스터 키로 암호화된 데이터 키(암호화된 버전)입니다.
2단계: 평문 데이터 키를 사용해서 실제 데이터를 로컬에서 암호화합니다. 이 과정은 KMS를 거치지 않으므로 데이터 크기에 제한이 없습니다.
3단계: 암호화된 데이터 키를 암호화된 데이터와 함께 저장합니다. 평문 데이터 키는 메모리에서 즉시 삭제합니다.
복호화할 때는 역순으로 진행합니다. 저장된 암호화된 데이터 키를 KMS에 보내면, KMS가 마스터 키로 복호화해서 평문 데이터 키를 반환합니다. 그 데이터 키로 암호화된 데이터를 복호화합니다.
이 방식의 장점은 마스터 키가 KMS 밖으로 절대 나오지 않는다는 점입니다. 데이터 키만 이동하고, 마스터 키는 KMS 안에 안전하게 보관됩니다. 누군가 암호화된 데이터를 훔쳐가더라도 KMS 마스터 키에 대한 접근 권한이 없으면 복호화할 수 없습니다.
크로스 계정 암호화
여러 AWS 계정이 협업하는 환경에서는 한 계정의 KMS 키로 암호화된 데이터를 다른 계정에서 복호화해야 할 때가 있습니다. 이를 허용하려면 KMS 키 정책에서 다른 계정을 명시적으로 허용해야 합니다. 계정 A의 KMS 키 정책에 계정 B의 IAM 역할을 추가하면, 계정 B가 그 키를 사용해서 복호화할 수 있습니다.
데이터 마스킹과 익명화
데이터를 분석에 활용하면서도 민감한 정보를 보호해야 하는 상황이 많습니다. 개발팀에 운영 데이터를 제공하거나, 분석팀에 고객 데이터를 제공할 때 원본 데이터 그대로 주면 안 됩니다. 이때 마스킹과 익명화를 사용합니다.
마스킹(Masking)은 원본 데이터의 일부를 가려서 표시하는 방법입니다. 전화번호 010-1234-5678을 010-****-5678로 표시하는 것이 마스킹입니다. 원본 데이터는 그대로 있지만 보여주는 형태를 바꿉니다. 고객 서비스 화면에서 전체 카드번호 대신 마지막 4자리만 보여주는 것도 마스킹입니다.
익명화(Anonymization)는 개인을 식별할 수 없도록 데이터를 변환하는 방법입니다. 이름, 주민등록번호, 연락처 등 식별 정보를 제거하거나 변환합니다. 완전히 익명화된 데이터는 특정 개인과 연결할 수 없습니다. 연구나 통계 목적으로 데이터를 사용할 때 적합합니다.
가명화(Pseudonymization)는 식별 정보를 가명(별명)으로 대체하는 방법입니다. 실제 이름 "김철수"를 임의의 ID "USER_4729"로 대체합니다. 익명화와 달리 별도의 매핑 테이블이 있으면 원본 데이터로 복원이 가능합니다. GDPR에서 가명화는 개인정보 보호 조치로 인정받습니다.
AWS에서 마스킹과 익명화를 구현하는 도구:
AWS Glue DataBrew는 코드 없이 데이터 변환 규칙을 만들 수 있는 시각적 데이터 준비 도구입니다. DataBrew에서 마스킹 변환 규칙을 정의하면, 파이프라인이 실행될 때 자동으로 민감한 데이터를 마스킹합니다.
Lake Formation 열 수준 접근 제어는 마스킹의 한 형태로 볼 수 있습니다. 특정 사용자에게 민감한 열이 아예 보이지 않도록 설정합니다. 데이터를 물리적으로 변환하는 것이 아니라, 쿼리 시점에 접근을 차단합니다.
Amazon Macie는 S3 버킷에서 PII(개인 식별 정보)를 자동으로 탐지하는 서비스입니다. 머신러닝을 사용해서 이름, 이메일, 신용카드번호, 주민등록번호 등을 식별하고 위험도를 평가합니다. "어디에 민감한 데이터가 있는지" 파악하는 첫 단계로 사용합니다.
규정 준수 (Compliance)
데이터를 암호화하고 마스킹하는 이유 중 하나는 법적 규정을 준수하기 위해서입니다.
GDPR(General Data Protection Regulation)은 EU의 개인정보 보호 규정입니다. EU 시민의 개인 데이터를 처리하는 모든 기업에 적용됩니다. 주요 요구사항으로는 데이터 수집 시 명시적 동의, 잊힐 권리(데이터 삭제 요청 대응), 데이터 침해 발생 시 72시간 내 신고 등이 있습니다. 위반 시 전 세계 연간 매출의 최대 4%에 달하는 벌금이 부과됩니다.
HIPAA(Health Insurance Portability and Accountability Act)는 미국의 의료 정보 보호법입니다. PHI(Protected Health Information, 보호 대상 건강 정보)를 다루는 모든 기관에 적용됩니다. PHI의 암호화가 필수이며, 접근 로그를 유지해야 합니다. AWS는 HIPAA BAA(Business Associate Agreement)를 제공해서 HIPAA 준수 환경 구축을 지원합니다.
AWS Artifact는 AWS의 규정 준수 보고서와 인증서를 다운로드할 수 있는 서비스입니다. SOC 1/2/3, ISO 27001, PCI DSS, HIPAA 등 다양한 규정 준수 보고서를 받아서 감사자에게 제출할 수 있습니다. AWS가 규정 준수 요구사항을 충족하는 인프라를 제공한다는 것을 증명합니다.
시험 핵심 정리
| 시험 키워드 | 정답 서비스/개념 | |-----------|--------------| | S3 기본 암호화 (추가 설정 없음) | SSE-S3 | | S3 암호화 + 감사 추적 필요 | SSE-KMS | | 고객이 직접 키를 S3에 제공 | SSE-C | | Redshift 클러스터 암호화 | KMS 또는 CloudHSM | | EMR EBS 볼륨 암호화 | LUKS | | 4KB 이상 대용량 데이터 KMS 암호화 | 봉투 암호화 (Envelope Encryption) | | 다른 계정에서 KMS 키 사용 | KMS 키 정책에서 계정 허용 | | S3에서 HTTPS 강제 | aws:SecureTransport 버킷 정책 | | 원본 데이터 일부를 가려서 표시 | 마스킹 (Masking) | | 개인 식별 불가능하게 데이터 변환 | 익명화 (Anonymization) | | S3에서 PII 자동 탐지 (ML 기반) | Amazon Macie | | 코드 없이 데이터 마스킹 변환 | AWS Glue DataBrew | | EU 개인정보 보호 규정 | GDPR | | 미국 의료 정보 보호법 | HIPAA | | AWS 규정 준수 보고서 다운로드 | AWS Artifact |