데이터 파이프라인에 문제가 생겼습니다. 누군가 실수로 중요한 데이터를 삭제했거나, 권한 없는 사람이 민감한 파일에 접근했거나, 규정 위반이 발생했을 수도 있습니다. 이럴 때 "언제, 누가, 무엇을 했는지" 추적할 수 있어야 합니다. 이것이 감사 로그(Audit Log)의 역할입니다. 그리고 개인정보를 다루는 데이터라면 프라이버시 거버넌스까지 필요합니다. 이 글에서는 AWS에서 감사 로그를 수집하고 분석하는 방법, 개인정보를 식별하고 보호하는 방법, 그리고 데이터 거버넌스 프레임워크를 구축하는 방법을 처음 배우는 분도 이해할 수 있도록 설명합니다.
감사 로그 (Audit Logs)
감사 로그란 시스템에서 발생하는 모든 중요한 활동을 기록하는 로그입니다. 누가 언제 어디서 무엇을 했는지 추적할 수 있습니다. 나중에 문제가 생겼을 때 원인을 파악하고, 규정 준수 감사에서 증거로 사용합니다.
AWS CloudTrail — AWS의 블랙박스
CloudTrail은 AWS 계정에서 발생하는 모든 API 호출을 기록하는 서비스입니다. 누가(어떤 사용자/역할/서비스가) 언제 어디서(어떤 리전에서 어떤 IP로) 무엇을 했는지(어떤 API를 호출했는지) 기록합니다. 비행기의 블랙박스처럼, 사고가 났을 때 CloudTrail 로그를 보면 정확히 무슨 일이 있었는지 재현할 수 있습니다.
CloudTrail은 크게 두 가지 이벤트 유형을 기록합니다.
관리 이벤트(Management Events)는 AWS 리소스를 생성, 수정, 삭제하는 작업입니다. EC2 인스턴스를 시작하거나 종료하기, S3 버킷을 생성하거나 삭제하기, IAM 사용자를 만들거나 권한을 변경하기, Glue 작업을 실행하거나 중지하기 등이 해당합니다. 기본적으로 활성화되어 있으며 추가 비용이 없습니다.
데이터 이벤트(Data Events)는 실제 데이터에 접근하는 작업입니다. S3 객체를 읽거나(GetObject) 쓰거나(PutObject) 삭제하기, Lambda 함수를 호출하기, DynamoDB 항목을 읽거나 쓰기 등이 해당합니다. 기본적으로 비활성화되어 있고, 별도로 활성화해야 하며 추가 비용이 발생합니다. 데이터 이벤트는 볼륨이 매우 크기 때문에 모든 버킷과 함수에 활성화하면 비용이 상당히 늘어납니다. 중요한 버킷이나 함수에만 선택적으로 활성화하는 것이 좋습니다.
CloudTrail Lake는 CloudTrail 이벤트를 S3 대신 CloudTrail 자체의 관리형 데이터 스토어에 저장하고, SQL로 쿼리할 수 있는 기능입니다. "지난 30일간 prod-data 버킷에 접근한 모든 API 호출을 보여줘" 같은 쿼리를 바로 실행할 수 있습니다. 로그를 S3에 저장하고 Athena로 분석하는 방식보다 설정이 간편합니다.
CloudTrail 로그를 활용하는 대표적인 시나리오: 보안 사고 조사: "이 S3 버킷에서 마지막으로 데이터를 다운로드한 사람은 누구인가?" 규정 준수 감사: "지난 분기 동안 민감 데이터에 접근한 모든 기록을 제출하라" 이상 탐지: "갑자기 대량의 데이터가 삭제되는 패턴이 있는가?"
Amazon CloudWatch Logs — 애플리케이션 로그의 중앙 수집소
CloudTrail이 AWS API 수준의 감사를 담당한다면, CloudWatch Logs는 애플리케이션과 서비스의 실행 로그를 중앙에서 수집하는 서비스입니다. "무슨 API가 호출됐는가"가 아니라 "서비스가 실행 중에 어떤 일이 일어났는가"를 기록합니다.
Glue ETL 작업이 실행될 때 발생하는 오류 메시지, EMR에서 Spark 작업이 실패한 이유, Lambda 함수가 처리한 이벤트 수와 실행 시간, Redshift 쿼리 실행 결과 — 이 모든 것이 CloudWatch Logs에 수집됩니다.
CloudWatch Logs의 주요 기능:
보존 기간 설정은 로그를 얼마나 오래 보관할지 정합니다. 1일부터 영구 보관까지 설정할 수 있습니다. 규정에서 7년 보관을 요구한다면 그에 맞게 설정합니다. 보관 기간을 짧게 하면 스토리지 비용이 절감됩니다.
CloudWatch Logs Insights는 로그 데이터를 SQL과 유사한 쿼리 언어로 분석하는 기능입니다. "지난 1시간 동안 ERROR 수준 로그가 가장 많이 발생한 Lambda 함수는 무엇인가?" 같은 분석을 인터랙티브하게 수행할 수 있습니다. 로그를 다른 곳으로 이동하지 않고 CloudWatch 안에서 바로 분석합니다.
메트릭 필터(Metric Filters)는 로그에서 특정 패턴을 찾아 CloudWatch 메트릭으로 변환하는 기능입니다. 예를 들어 Glue 로그에서 "ERROR" 패턴이 나타나면 error_count 메트릭을 1 증가시킵니다. 이 메트릭에 CloudWatch Alarm을 연결하면 에러가 일정 횟수를 초과할 때 SNS로 알림을 받을 수 있습니다.
멀티 서비스 로그 통합 — 여러 곳의 로그를 한 곳에서
대규모 데이터 플랫폼에서는 수십 개의 서비스에서 로그가 발생합니다. 이를 효율적으로 분석하기 위한 세 가지 패턴이 있습니다.
CloudWatch Logs 중앙 집중식 패턴은 모든 서비스의 로그를 CloudWatch Logs에 수집하고, Logs Insights로 통합 분석합니다. 설정이 간단하고 AWS 서비스와 자연스럽게 통합됩니다. 비용은 데이터 볼륨에 비례합니다.
S3 + Athena 패턴은 CloudTrail 로그, VPC 흐름 로그, ALB 접근 로그 등을 S3에 저장하고, Athena로 SQL 쿼리를 실행합니다. 대용량 로그를 저렴하게 장기 보관하고, 필요할 때만 쿼리 비용을 지불합니다. 데이터 엔지니어링에서 규정 준수 감사 목적으로 많이 사용합니다.
Amazon OpenSearch Service는 대규모 로그의 실시간 검색과 시각화에 최적화된 서비스입니다. Kibana 같은 대시보드로 로그를 시각화하고, 초당 수백만 건의 로그를 실시간으로 검색할 수 있습니다. 보안 운영 센터(SOC)나 실시간 이상 탐지에 적합합니다.
데이터 프라이버시 (Data Privacy)
감사 로그가 "무슨 일이 있었는가"를 기록한다면, 데이터 프라이버시는 "민감한 데이터를 어떻게 보호할 것인가"를 다룹니다.
PII 식별 — 어디에 민감한 데이터가 있는지 파악하기
PII(Personally Identifiable Information, 개인 식별 정보)는 특정 개인을 식별할 수 있는 데이터입니다. 이름, 이메일 주소, 전화번호, 주민등록번호, 신용카드번호, IP 주소 등이 해당합니다. 데이터 레이크에 수천 개의 파일이 있을 때, 어느 파일에 PII가 있는지 수동으로 파악하는 것은 거의 불가능합니다.
Amazon Macie는 S3 버킷에서 PII를 자동으로 탐지하는 완전 관리형 데이터 보안 서비스입니다. 머신러닝과 패턴 매칭을 결합해서 PII를 식별하고, 각 탐지 결과의 위험도를 평가합니다. Macie가 지원하는 탐지 유형:
금융 정보: 신용카드번호, 은행 계좌번호 의료 정보: 진단 코드, 처방 정보 개인 식별 정보: 이름, 주소, 이메일, 전화번호 자격 증명: API 키, 비밀번호, AWS 자격 증명 국가별 식별자: 주민등록번호(한국), 사회보장번호(미국), 여권번호 등
Macie를 활성화하면 S3 버킷을 스캔하고, PII가 있는 객체를 탐지하면 Security Hub나 EventBridge로 결과를 전송합니다. 이를 Lake Formation과 연동하면, Macie가 탐지한 PII가 있는 테이블에 자동으로 열 수준 접근 제어를 적용할 수 있습니다.
데이터 주권 (Data Sovereignty) — 데이터를 어디에 보관해야 하는가
데이터 주권은 데이터가 특정 국가나 지역의 법률 관할권 내에 있어야 한다는 개념입니다. 한국 기업이 한국 고객의 개인정보를 처리한다면, 일부 규정에서는 그 데이터를 한국 내 서버에 보관하도록 요구할 수 있습니다.
리전 선택은 데이터 주권의 첫 번째 단계입니다. AWS 리전은 지리적으로 분리된 데이터센터 그룹입니다. 서울 리전(ap-northeast-2)에 데이터를 저장하면 해당 데이터는 한국 내 데이터센터에만 존재합니다. 데이터 주권 요구사항에 맞는 리전을 선택하는 것이 중요합니다.
S3 크로스 리전 복제(CRR)는 주의가 필요합니다. 가용성이나 재해 복구를 위해 다른 리전으로 데이터를 복제할 때, 복제 대상 리전이 데이터 주권 요구사항을 충족하는지 확인해야 합니다. 독일 고객 데이터를 GDPR 준수를 위해 EU 리전에만 보관해야 한다면, 미국 리전으로 복제하면 안 됩니다.
백업과 스냅샷도 같은 리전에 보관해야 합니다. RDS 스냅샷이나 EBS 스냅샷을 다른 리전으로 복사하면 데이터 주권 위반이 될 수 있습니다.
거버넌스 프레임워크 (Governance Framework)
데이터 거버넌스는 데이터의 가용성, 사용성, 일관성, 보안을 관리하는 체계적인 접근 방식입니다. 규칙을 정하고, 그 규칙이 지켜지는지 자동으로 감시하는 것입니다.
AWS Config — 규정 준수 자동 감시
AWS Config는 AWS 리소스의 구성 변경을 추적하고, 미리 정의한 규칙을 준수하는지 자동으로 평가하는 서비스입니다. CloudTrail이 "무엇이 호출됐는가"를 기록한다면, AWS Config는 "리소스가 현재 어떤 상태인가"를 추적합니다.
예를 들어 이런 규칙을 설정할 수 있습니다: "모든 S3 버킷에 서버 측 암호화가 활성화되어야 한다" "퍼블릭 접근이 차단된 S3 버킷만 허용한다" "RDS 인스턴스는 모두 암호화되어야 한다" "모든 IAM 사용자는 MFA를 활성화해야 한다"
Config가 이 규칙에 위반된 리소스를 발견하면 "비준수(Non-compliant)" 상태로 표시하고, EventBridge나 SNS로 알림을 보냅니다. 또한 규칙 위반을 자동으로 수정하는 수정 작업(Remediation Action)도 설정할 수 있습니다.
Config 규칙은 크게 두 가지입니다. AWS 관리형 규칙은 AWS가 미리 만들어둔 규칙으로, 활성화만 하면 즉시 사용할 수 있습니다. 사용자 정의 규칙은 Lambda 함수를 작성해서 원하는 규칙을 직접 만드는 것입니다.
Lake Formation 거버넌스 — 데이터 레이크의 중앙 통제
Lake Formation은 데이터 레이크의 중앙 거버넌스 플랫폼입니다. 앞서 인증/권한 부여 편에서 자세히 다뤘지만, 거버넌스 관점에서 추가로 중요한 기능이 있습니다.
데이터 계보(Data Lineage)는 데이터가 어디서 왔고 어떤 변환을 거쳤는지 추적하는 기능입니다. "이 분석 결과 데이터는 원래 어떤 소스에서 왔고, 어떤 처리를 거쳤는가?" 라는 질문에 답합니다. Lake Formation은 AWS Glue와 연동해서 데이터 계보를 시각적으로 보여줍니다.
데이터 공유 시 프라이버시 보호는 Redshift 데이터 공유 시 적용됩니다. 다른 계정이나 클러스터와 데이터를 공유할 때, 공유 대상이 민감한 열에 접근하지 못하도록 Lake Formation 필터를 적용합니다. 데이터를 공유하면서도 프라이버시를 보호하는 방법입니다.
Redshift 데이터 공유와 프라이버시
Redshift 데이터 공유는 데이터를 복사하지 않고 다른 클러스터나 계정과 공유합니다. 이때 프라이버시 보호를 위해 Lake Formation과 연동하면, 공유 데이터에 열 수준이나 행 수준 필터를 적용할 수 있습니다. 예를 들어 파트너사와 매출 데이터를 공유할 때, 고객 이름과 연락처 열은 공유하지 않고 매출 금액과 지역 데이터만 공유할 수 있습니다.
시험 핵심 정리
| 시험 키워드 | 정답 서비스/개념 | |-----------|--------------| | 모든 AWS API 호출 기록 | AWS CloudTrail | | S3 객체 읽기/쓰기 기록 (별도 활성화) | CloudTrail 데이터 이벤트 | | CloudTrail 로그를 SQL로 쿼리 | CloudTrail Lake | | 애플리케이션 로그 중앙 수집 | Amazon CloudWatch Logs | | 로그를 SQL로 분석 | CloudWatch Logs Insights | | 로그 패턴 → 메트릭 변환 | CloudWatch 메트릭 필터 | | 대규모 로그 실시간 검색/시각화 | Amazon OpenSearch Service | | S3에서 PII 자동 탐지 (ML 기반) | Amazon Macie | | 리소스 구성 규칙 준수 자동 감시 | AWS Config | | 데이터를 특정 국가에만 보관 | 데이터 주권 (리전 선택) | | 데이터 레이크 중앙 거버넌스 | AWS Lake Formation | | CloudTrail vs CloudWatch Logs 차이 | CloudTrail=누가 API 호출, CloudWatch=서비스 실행 로그 |