Day 3 - 민감 데이터 보호: Macie와 마스킹

Macie 가 하는 일은 두 가지다

데이터 레이크에는 의도하지 않은 PII(개인식별정보)가 섞여 들어온다. 자유 입력 필드에 적힌 주민번호, 로그에 찍힌 카드번호 같은 것들이다. 이를 찾아내는 서비스가 Amazon Macie 다. Macie 가 만드는 발견(finding)은 두 범주다.

• 정책 발견은 Macie 를 켜기 전부터 열려 있던 설정에는 생기지 않는다. "이미 공개된 버킷을 찾아라"는 버킷 인벤토리를 직접 보거나 다른 도구(Config 등)의 영역이다.
• 발견은 90일간 보관된다. 더 오래 남기려면 EventBridge·Security Hub 로 내보내거나, 탐색 결과를 S3 로 저장하도록 설정한다.
• Macie 의 분석 대상은 S3 다. Redshift 테이블이나 RDS 안의 PII 는 Macie 가 직접 보지 않는다.

탐색 방식 둘: 자동 탐색과 탐색 작업

• 자동 탐색은 버킷마다 대표 객체를 골라 본다. 그렇게 고른 객체는 실제로 가져와 내용을 검사한다. 전체를 훑지 않는다는 것이지 내용을 안 본다는 뜻이 아니다.
• 둘은 순서대로 쓴다. 자동 탐색으로 위험한 버킷을 좁히고, 그 버킷에 탐색 작업을 돌려 전수 확인한다.

식별자: 무엇을 민감하다고 볼 것인가

• 관리형 데이터 식별자: 신용카드 번호, 각국의 신분증·여권 번호, AWS 비밀 키 같은 자격 증명 등 AWS 가 만들어 둔 탐지 기준.
• 맞춤 데이터 식별자: 조직 고유의 패턴(사번, 고객 계정 번호)을 정규식과 보조 조건으로 정의.
• 허용 목록(allow list): 탐지에서 빼고 싶은 값. 공개된 대표 전화번호 같은 것을 넣어 오탐을 줄인다.

{
  "name": "internal-employee-id",
  "regex": "EMP-[0-9]{6}",
  "keywords": ["employee", "사번"],
  "ignoreWords": ["EMP-000000"],
  "maximumMatchDistance": 50
}

• 키워드는 오탐을 줄이는 장치다. 여섯 자리 숫자는 어디에나 있지만, "사번"이라는 단어 뒤 50자 안의 여섯 자리 숫자는 사번일 가능성이 높다. CSV 처럼 열이 있는 데이터에서는 열 이름에 키워드가 있어도 인정된다.
• 맞춤 데이터 식별자는 만든 뒤 수정할 수 없다. 과거 발견의 기준이 바뀌지 않도록 하기 위해서다. 고치려면 새로 만든다. 그래서 만들기 전에 샘플 데이터로 시험한다.

암호화된 객체는 어디까지 볼 수 있나

• "Macie 를 돌렸는데 발견이 없다"가 곧 "민감 데이터가 없다"는 아니다. 고객 관리형 키의 키 정책에 Macie 를 넣지 않았다면 내용을 열어 보지 못한 것이다. 키가 다른 계정 소유라면 키 정책 허용에 더해 grant 를 만들어야 한다.

💡 관련 이론: Macie 는 탐지 도구다. 결과는 "어디에 무엇이 있는지"까지이고, 마스킹·격리·삭제는 하지 않는다. 시험 보기에서 "Macie 로 마스킹한다", "Macie 로 삭제한다"는 오답이다. 탐지 뒤의 조치는 EventBridge 로 이어 붙인 다른 서비스가 한다.

탐지에서 대응까지 자동으로 잇기

[Macie 발견] → [EventBridge 규칙] → [Lambda]
   → 버킷 정책으로 접근 제한 / 객체 태깅 / SNS 알림 / Security Hub 기록

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "type": [{ "prefix": "SensitiveData:S3Object/" }] }
}

• 자동 대응으로 객체를 삭제하지 않는다. 증거가 사라지고, 오탐이었을 때 되돌릴 수 없다. 접근을 좁히고 태그를 달아 사람이 판단하게 한다.
• 발견을 Security Hub 로 모으면 다른 보안 서비스의 발견과 한 화면에서 우선순위를 매길 수 있다.

노출을 줄이는 기법 비교

• 지문에 "조인은 유지" + "원본 복원 가능"이 함께 나오면 토큰화다. "복원할 필요 없음"이면 마스킹이나 해싱이다.
• 값의 가짓수가 적은 컬럼(성별, 우편번호)을 해싱하면 가능한 값을 전부 해싱해 맞춰 보는 식으로 역추적된다. 해싱은 만능 익명화가 아니다.

💡 관련 이론: 토큰화는 조인·분석을 유지하면서 원본을 숨길 수 있어 PCI-DSS 같은 결제 규정에서 선호된다. 원본과 토큰의 매핑이 담긴 볼트가 새로운 보호 대상이 된다는 점이 비용이다. 볼트에 접근할 수 있는 시스템을 최소로 줄이는 것이 설계의 핵심이다.

어디에서 가릴 것인가: 구현 위치

• Glue Detect PII 변환은 두 가지 방식으로 스캔한다. 모든 셀을 검사하는 방식과, 행을 표본 추출해 "PII 가 들어 있는 컬럼"만 찾아내는 방식이다. 후자는 비용이 적게 든다. 찾은 값에는 고정 문자열로 대체, 부분 대체, SHA-256 해시 적용 같은 조치를 고른다.
• Macie 와 역할이 다르다. Macie 는 이미 S3 에 쌓인 객체를 조사하고, Glue 변환은 파이프라인을 흐르는 데이터를 그 자리에서 처리한다.

-- Redshift 동적 데이터 마스킹
CREATE MASKING POLICY mask_card_full
WITH (card_number VARCHAR(20))
USING ('****-****-****-****'::TEXT);
 
CREATE MASKING POLICY mask_card_last4
WITH (card_number VARCHAR(20))
USING ('****-****-****-' || RIGHT(card_number, 4));
 
-- 전체 사용자는 완전 마스킹, 분석가 역할은 뒤 4자리(우선순위가 높은 쪽이 적용)
ATTACH MASKING POLICY mask_card_full
ON payments(card_number) TO PUBLIC;
 
ATTACH MASKING POLICY mask_card_last4
ON payments(card_number) TO ROLE analyst_role PRIORITY 10;

• DDM 은 데이터를 변형해 저장하지 않고 쿼리 시점에 표현만 바꾼다. 개인정보 요건이 바뀌어도 원본과 SQL 을 손대지 않고 정책만 고친다.
• 정책을 만들고 붙이는 것은 슈퍼유저나 sys:secadmin 역할을 가진 주체만 할 수 있다.
• 한 컬럼에 여러 정책이 걸리면 우선순위(PRIORITY)가 높은 정책이 적용된다. 우선순위를 생략하면 0 이다. PUBLIC 에 건 정책보다 특정 역할의 정책이 적용되게 하려면 더 높은 우선순위를 준다.
• 마스킹 표현식에는 SQL 뿐 아니라 사용자 정의 함수도 쓸 수 있다. 해시로 가리면 원본을 보지 않고도 조인할 수 있다.
• 마스킹이 "가린 값을 보여 준다"면 데이터 필터는 "값을 반환하지 않는다". 둘을 겹치면 다층 방어가 된다.

GDPR 삭제는 DELETE 한 줄로 끝나지 않는다

• 일반 Parquet 테이블에서 한 사람의 행을 지우려면 그 행이 든 파일을 통째로 다시 써야 한다. Iceberg·Hudi 같은 오픈 테이블 포맷은 행 수준 DELETE 를 지원해 이 작업을 테이블 연산으로 만든다.
• 그러나 Iceberg 의 DELETE 는 "이 행은 삭제됨"이라는 표시(삭제 파일)를 추가하는 것이다. 원래 데이터 파일과, 삭제 이전 시점을 가리키는 스냅샷은 남아 있고 시간 여행 쿼리로 다시 읽을 수 있다.

-- 1) 논리 삭제
DELETE FROM lake_clean.payments WHERE customer_id = 'GDPR-REQ-2026-042';
 
-- 2) 삭제 표시를 데이터 파일에 합쳐 다시 쓰기
OPTIMIZE lake_clean.payments REWRITE DATA USING BIN_PACK;
 
-- 3) 오래된 스냅샷 만료 + 어디에도 속하지 않는 파일 제거
VACUUM lake_clean.payments;

• "버전 관리를 켠다"는 삭제 요건에 역행한다. 사본을 더 남긴다.

규정과 도구 매핑

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["ap-northeast-2"] }
  }
}

• 위와 같은 SCP 는 허용한 리전 밖에서의 작업을 계정 전체에서 막는다. 실제로는 IAM 처럼 리전이 없는 전역 서비스를 예외로 빼야 한다. 리전 제한과 함께 교차 리전 복제·스냅샷 복사 설정도 점검해야 데이터가 밖으로 나가지 않는다.

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 데이터를 찾고(카탈로그), 믿고(계보), 나누고(공유), 추적하는(감사) 거버넌스를 다룬다.

📖 용어

• PII : 개인을 식별할 수 있는 정보. 이름, 주민번호, 카드번호, 이메일 등.
• 관리형 데이터 식별자 : Macie 가 기본으로 제공하는 민감 데이터 탐지 기준.
• 맞춤 데이터 식별자 : 정규식과 키워드로 직접 정의하는 탐지 기준. 만든 뒤에는 수정할 수 없다.
• 발견(finding) : Macie 가 찾은 문제 한 건에 대한 보고. 버킷 설정 문제와 민감 데이터 두 범주가 있다.
• 마스킹 : 값을 가리거나 일부만 보여 주는 것. 보통 원본으로 되돌릴 수 없다.
• 토큰화 : 민감한 값을 의미 없는 토큰으로 바꾸고 원본과의 매핑을 따로 보관하는 것.
• 볼트(vault) : 토큰과 원본의 매핑을 보관하는 보호된 저장소.
• 동적 데이터 마스킹 : 저장된 값은 두고 조회하는 순간에 역할에 따라 가려서 보여 주는 Redshift 기능.
• 스냅샷(Iceberg) : 특정 시점의 테이블 상태. 지운 데이터도 옛 스냅샷이 남아 있으면 다시 읽힌다.
• 데이터 거주 : 데이터를 정해진 국가·리전 안에만 두어야 한다는 요건.