Day 5 - Week 9 종합: 보안·거버넌스 복습

요청 한 건이 지나는 관문

이번 주는 접근 제어, 암호화, 민감 데이터 보호, 거버넌스를 하루씩 봤다. 네 주제는 따로 노는 기능이 아니라, 분석가의 쿼리 한 건이 데이터에 닿기까지 차례로 지나는 관문이다.

분석가의 Athena 쿼리
   │
   ▼ ① 전송: TLS 인가?              (aws:SecureTransport, require_ssl)        Day 2
   ▼ ② IAM: 이 API 를 부를 수 있나?   (athena, glue, lakeformation:GetDataAccess) Day 1
   ▼ ③ Lake Formation: 이 테이블을 볼 수 있나?  (SELECT, LF-Tags)              Day 1
   ▼ ④ KMS: 복호화할 수 있나?         (키 정책, kms:Decrypt)                   Day 2
   ▼ ⑤ 무엇을 돌려주나?               (데이터 필터, 마스킹, 토큰)               Day 1·3
   ▼ ⑥ 기록: 누가 무엇을 읽었나?       (CloudTrail 데이터 이벤트)               Day 4
 결과

• ①~④는 통과 여부를, ⑤는 보이는 범위를, ⑥은 사후 입증을 정한다. 문제의 요구가 셋 중 어디에 있는지 보면 보기가 줄어든다.
• 관문은 서로를 대신하지 못한다. 암호화(④)는 권한 있는 사용자가 PII 를 보는 것을 막지 못하고, 권한(③)은 누가 봤는지를 남기지 못한다.

"어디서 막혔나" 판별표

• 교차 계정 문제는 세 겹이다. 신뢰 정책(누가 역할을 맡을 수 있나) + 권한 정책(그 역할이 무엇을 할 수 있나) + KMS 키 정책. 지문에서 둘이 갖춰졌다고 말하면 남은 하나가 답이다.

닮은 것끼리 구분하기

"민감 데이터를 못 보게" 하는 네 수단

• Macie 는 이 표에서 성격이 다르다. 나머지 셋은 통제, Macie 는 발견이다. "보이지 않게 하라"는 요구에 Macie 를 고르면 틀린다.

S3 암호화: 키를 누가 쥐는가

공유: 상대가 무엇을 손에 넣는가

감사 로그

설정은 어디에 하나: 서비스별 한 장

• 원본을 SSE-KMS 로 암호화해도 Athena 쿼리 결과와 Glue 잡의 임시·로그 데이터는 각자의 설정을 따른다. 민감 데이터가 결과 버킷이나 로그로 새는 경로가 여기다.

Week 9 숫자·기본값 한 장

• 최근 바뀐 값이 셋 있다. AWS 관리형 키의 교체 주기(3년 → 1년), SSE-C 의 기본 차단, Redshift 의 기본 암호화다. 시험 자료에는 옛 값으로 나올 수 있다.

통합 시나리오: 규제 대상 고객 데이터 플랫폼

요구사항: 결제 데이터를 데이터 레이크에 적재하되, PII 는 탐지·보호하고, 분석가에게는 가려진 데이터만, 파트너와는 원본 노출 없이 협업하고, 모든 접근을 감사하며, GDPR 삭제에 대응한다.

[결제 소스] --Glue ETL(KMS 암호화, 토큰화)--> s3://lake-clean/payments/ (Iceberg)
   --Macie 스캔--> [PII 발견] --EventBridge--> [Lambda: 접근 제한/알림]
   --Lake Formation(데이터 필터, LF-Tags)--> [분석가: PII 제외 뷰]
   --Clean Rooms--> [파트너: 합의된 집계만]
   모든 활동 --> CloudTrail(데이터 이벤트) --> 감사 계정 버킷

-- GDPR 삭제 (Iceberg on Athena): 논리 삭제 후 스냅샷까지 정리
DELETE FROM lake_clean.payments WHERE customer_id = 'GDPR-REQ-2026-042';
VACUUM lake_clean.payments;

{
  "Name": "analyst_payments_filter",
  "ColumnNames": ["txn_id", "region", "amount_token", "dt"],
  "RowFilter": { "FilterExpression": "region = 'ap-northeast-2'" }
}

• Macie 가 이 버킷을 읽으려면 고객 관리형 키의 키 정책이 Macie 를 허용해야 한다. 암호화 결정(Day 2)이 탐지 결정(Day 3)의 전제 조건이 된다.
• 토큰화했는데도 Macie 를 두는 이유는 설계가 놓친 경로 때문이다. 통제는 "있어야 할 곳"을 막고, 탐지는 "있으면 안 될 곳"을 찾는다.

운영에서 실제로 들어오는 요청 세 가지

💡 관련 이론: 보안·거버넌스는 단일 통제가 아니라 다층 방어다. 암호화(기밀성) + 접근 제어(권한) + 탐지(가시성) + 감사(책임 추적)가 함께 작동해야 규제와 신뢰 요건을 충족한다. 어느 하나가 강하다고 다른 하나를 생략할 수 없다.

자주 틀리는 함정

• Lake Formation 을 켰다고 통제가 걸리는 것은 아니다. IAMAllowedPrincipals 가 남아 있으면 IAM 만으로 읽힌다.
• Lake Formation 은 S3 직접 접근을 막지 않는다. 필터를 걸어도 사용자에게 s3:GetObject 가 있으면 원본 파일이 열린다.
• KMS 권한은 IAM 정책만으로 끝나지 않는다. 키 정책이 IAM 위임을 허용하거나 직접 허용해야 한다.
• 키를 교체해도 기존 데이터는 다시 암호화되지 않는다. 기본 암호화를 바꿔도 기존 객체는 그대로다.
• 버킷 키는 키 통제를 포기하는 것이 아니다. 다만 KMS 이벤트에는 객체가 아니라 버킷 ARN 이 찍힌다.
• Macie 는 가리지도 지우지도 않는다. S3 밖(Redshift 테이블)도 보지 않는다.
• DELETE 는 물리 삭제가 아니다. 스냅샷을 만료시키기 전에는 시간 여행으로 읽힌다.
• datashare·Data Exchange 는 "원본 비노출"이 아니다. 복사를 안 할 뿐 상대는 행을 읽는다.
• 감사 로깅을 켜도 쿼리 문이 안 남을 수 있다. Redshift 는 enable_user_activity_logging 이 따로다.

지문 단서 → 정답 판별표

다음 주는 마지막 주다. 도메인 1·2(수집·변환과 스토어 관리)를 통합 복습하는 것으로 시작한다.

📖 용어

• 다층 방어 : 하나의 통제가 뚫려도 다음 통제가 막도록 여러 겹으로 보호하는 설계.
• 관문(control point) : 요청이 통과 여부를 판정받는 지점. 전송, IAM, Lake Formation, KMS 가 각각 하나다.
• 제자리 접근 : 데이터를 복사해 받지 않고 제공자의 저장소를 직접 읽는 공유 방식.
• 원본 비노출 분석 : 상대의 행 데이터를 보지 못한 채 합의된 집계 결과만 얻는 협업 방식.
• 논리 삭제 / 물리 삭제 : 삭제됐다고 표시만 하는 것과 저장소에서 실제로 없애는 것. Iceberg 의 DELETE 는 전자다.
• 감사 계정 : 운영 계정과 분리해 로그를 모아 두는 계정. 운영자가 자기 기록을 고치지 못하게 한다.
• 책임 추적성 : 어떤 행위를 누가 했는지 사후에 입증할 수 있는 성질.
• 잊힐 권리 : 개인이 자신의 데이터 삭제를 요구할 수 있는 권리. GDPR 의 삭제 요청이 대표적이다.