들어가며: PII 탐지, 왜 자동화해야 할까?
금융, 보험, 의료, 정부 기관 등 규제 산업에서는 고객의 개인정보(PII)를 다루는 일이 일상입니다. 이름, 주소, 주민등록번호 같은 표준 PII부터 정책 번호, 회원 ID, 의료 기록 번호 같은 도메인 특화 식별자까지, 다양한 형태의 민감 데이터가 파일로 쏟아집니다.
문제는 수동 분류로는 절대 확장이 불가능하다는 점입니다. GDPR, HIPAA, CCPA, PCI DSS 같은 규제는 PII가 어디에 있는지, 누가 접근하는지, 어떻게 보호되는지 명확히 문서화하도록 요구합니다. Amazon Macie가 기본 제공하는 관리형 데이터 식별자로도 충분하지 않은 경우가 많아요. 조직만의 고유한 데이터 포맷(예: 특정 형식의 보험 증권 번호)은 기본 탐지 엔진이 인식하지 못하기 때문입니다.
이 글에서는 Amazon S3에 파일이 도착하는 순간 자동으로 PII를 탐지하는 이벤트 기반 파이프라인을 구축하는 방법을 단계별로 다룹니다. Macie의 내장 식별자에 더해 커스텀 데이터 식별자를 결합해, 조직 특화 민감 정보까지 놓치지 않고 탐지하는 것이 핵심입니다. Amazon Macie와 Step Functions를 활용한 공식 가이드를 기반으로 실무 적용 관점에서 재구성했습니다.
솔루션 아키텍처: 3버킷 패턴의 힘
이 파이프라인은 이벤트 기반 아키텍처를 사용합니다. 파일이 S3에 업로드되면 EventBridge가 이를 감지하고 Step Functions 워크플로우를 트리거하죠. Step Functions는 Macie 분류 작업을 오케스트레이션하고, 보고서를 생성하며, 고위험 발견 시 SNS로 알림을 보냅니다.
핵심 구성 요소
| 서비스 | 역할 |
|---|---|
| Amazon S3 | raw, staged, scanned 3개 버킷으로 데이터 상태 분리 |
| Amazon EventBridge | 새 객체 업로드 감지, 폴링 없이 자동 트리거 |
| AWS Step Functions | 전체 스캔 라이프사이클 오케스트레이션 |
| Amazon Macie | 내장 + 커스텀 식별자로 PII 탐지 |
| AWS Lambda | 작업 생성, 상태 폴링, 결과 파싱, 보고서 생성, 객체 이동 |
| Amazon SNS | 고위험 발견 시 실시간 알림 |
3버킷 패턴 설계 이유
- raw 버킷: 미처리 데이터. 스캔 완료 후 객체를 이동(버전 관리 활성화).
- staged 버킷: 스캔 대기 중인 데이터. 7일 후 자동 만료.
- scanned 버킷: 검증된 데이터와 보고서 보관.
이렇게 하면 미처리 데이터와 검증된 데이터가 절대 섞이지 않아 데이터 계보(data lineage)가 명확해집니다.
Step Functions 상태 머신 구성
워크플로우는 5개의 순차 상태로 구성됩니다:
- TriggerScan: raw 버킷의 새 객체를 staged로 복사하고 Macie 분류 작업 생성
- WaitForMacie: 60초 대기 (Macie 작업 처리 시간 확보)
- CheckStatus:
DescribeClassificationJobAPI로 작업 완료 여부 폴링 - GetFindings: 분류 결과 조회, CSV/JSON 보고서 생성, SNS 알림 발송
- MoveFiles: raw 버킷의 원본을 scanned로 이동, staged 정리
핵심 코드: CloudFormation 배포
아래는 AWS CLI로 CloudFormation 스택을 배포하는 명령어입니다. CustomIdentifierPatterns 파라미터에 조직 고유의 정규식 패턴을 넣으면 Macie 커스텀 식별자가 자동 생성됩니다.
# AWS CLI로 CloudFormation 스택 배포
aws cloudformation create-stack \
--stack-name pii-detection-pipeline \
--template-body file://template.yaml \
--parameters \
ParameterKey=BucketNamePrefix,ParameterValue=my-pii \
ParameterKey=CustomIdentifierPatterns,ParameterValue='"\\b(?:POL|MEM)-[0-9]{6}\\b"' \
ParameterKey=KmsKeyArn,ParameterValue='' \
ParameterKey=NotificationEmail,ParameterValue='security@example.com'
참고: 위 명령은 예시입니다. 실제 배포는 GitHub 저장소에서 CloudFormation 템플릿을 다운로드해 진행하세요.
주의사항: 프로덕션 적용 전 하드닝 필수
이 솔루션은 샘플 코드이므로, 그대로 프로덕션에 쓰면 위험합니다. 아래 하드닝 조치를 반드시 적용하세요.
보안 강화
- 멀티 테넌트 환경: 테넌트별로 별도 스택을 배포하고
BucketNamePrefix를 다르게 설정해 데이터 격리를 유지하세요. - S3 기본 암호화: SSE-S3 또는 KMS 키를 설정하세요.
KmsKeyArn파라미터로 전달 가능합니다. - SNS 암호화: SSE-KMS를 활성화하세요.
- CloudTrail: S3 데이터 이벤트 로깅을 활성화해 전체 감사 추적을 남기세요.
Macie 한도 및 성능 고려
- 커스텀 데이터 식별자: 계정당 최대 10,000개, 분류 작업당 최대 30개. 더 필요하면 여러 작업으로 분할하세요.
- API 스로틀:
CreateClassificationJob은 초당 0.1회(10초에 1회) 제한. 대용량 워크로드는 객체를 배치로 묶어 처리하세요. - 스캔 시간: 데이터량, 압축 방식, 식별자 수에 따라 15~20분 이상 걸릴 수 있습니다.
한국 개발 생태계에서의 적용 맥락
국내 금융권이나 공공기관에서는 개인정보보호법과 신용정보법이 GDPR 못지않게 엄격합니다. 특히 주민등록번호, 운전면허번호 같은 고유 식별자는 커스텀 식별자로 반드시 등록해야 합니다. 또한, 국내 클라우드 전환 사업에서 3버킷 패턴은 데이터 상태를 명확히 구분해 감사에 유리하므로, 제안서에 자주 등장하는 아키텍처입니다. 다만, Macie가 지원하는 리전이 제한적이므로, 한국 리전(ap-northeast-2)에서 사용 가능한지 먼저 확인하세요.
비판적 시각: 이 솔루션의 한계
- 객체 단위 스캔은 비용이 큼: 파일 하나마다 Macie 작업을 생성하면 대용량 환경에서 비용이 급증할 수 있습니다. 배치 처리로 전환하는 방안을 검토하세요.
- Macie의 탐지 한계: 정규식 기반 커스텀 식별자는 패턴이 변조되면 놓칠 수 있습니다. 기계학습 기반 탐지와 병행하는 것이 좋습니다.
- 단일 실패 지점: Step Functions의 오류 처리가 충분하지 않으면 파이프라인이 중단될 수 있습니다.
Catch절과 재시도 정책을 강화하세요.
결론: 실무 적용을 위한 다음 단계
이 파이프라인은 S3에 업로드되는 모든 파일을 실시간으로 스캔하고, 표준 PII와 조직 고유의 민감 정보를 모두 탐지합니다. CSV/JSON 보고서는 규제 감사에 바로 사용할 수 있고, 고위험 발견 시 SNS 알림으로 즉시 대응할 수 있습니다.
확장 아이디어
- 데이터 레이크 통합: JSON 결과를 Athena나 Glue로 보내 추세 분석, QuickSight 대시보드 구축
- 치료 워크플로우: 고위험 PII 발견 시 파일 격리 또는 접근 권한 철회하는 분기 추가
- 멀티 계정 환경: Organizations와 EventBridge 크로스 계정 규칙으로 중앙 보안 계정에서 통합 스캔
- 보안 허브 연동: Security Hub에 결과를 게시해 통합 보안 관리
함께 보면 좋은 글
이제 직접 배포해보세요. CloudFormation 템플릿을 다운로드하고, 커스텀 식별자를 등록한 뒤, 샘플 파일을 업로드하면 몇 초 안에 Step Functions 실행이 시작되는 것을 확인할 수 있습니다. 궁금한 점은 댓글로 남겨주세요. 😊