외부 Route에서만 이메일 마스킹하기 목표: 내부 Destination에는 명시적인 Audit Only 정책을, 외부 Destination에는 Mask 정책을 적용합니다. 실습은 실제 개인정보가 아닌 가상 데이터 로 진행합니다.적용 순서 이 사례는 이미 구성된 Connector·Destination·Stream을 전제로 합니다. 아직 생성하지 않았다면 커넥터별 수집 가이드 에서 먼저 수집 Source를 설정하세요. 이후 이 페이지의 구체적인 단계를 수행하고 실제 Logs와 Destination/격리 기록 을 검증합니다. 화면 캡처는 기존 테스트 증빙으로, 실제 결과를 대신하지 않습니다.
사전 구성 두 Destination에 전송하기 가 성공한 상태에서 시작합니다. Sample에 user.email이 실제로 존재하는지 먼저 확인합니다.1. Stream 공통 정책 설정
Stream Edit (/streams/{id}/edit)의 Route Processing 으로 들어갑니다.Global Processing → Data Protection 을 엽니다.관찰된 Schema에서 실제 이메일 필드를 선택합니다. 예시 경로는 user.email입니다.
내부 실습 정책에서 허용된다면 기본 보호 동작을 Audit Only , 전송 동작을 Continue Delivery 로 설정합니다.
Save Rule 이 필요한 항목은 버튼을 눌러 명시적으로 저장하고 요약/경고를 확인합니다.
Audit Only는 원본 이메일 값을 보존 합니다. 조직의 정책이 허용하지 않는 실데이터에는 사용하면 안 됩니다.
2. 외부 Route만 Override
Lab External Route를 선택합니다.Protection의 Inherit Global 을 해제합니다.
동일한 이메일 필드를 선택하고 Mask (정책에 따라 Partial/Full)를 지정합니다.
Event의 Delivery Behavior 는 Continue Delivery 로 설정합니다.
완전한 Route Protection 설정을 저장하고 Effective Status = Overridden 인지 확인합니다. Intent only 라면 적용 완료가 아닙니다.
Route별 Preview를 확인하되 Mapping Preview만으로 마스킹 검증을 마치지 않습니다.
참고: Remove/Drop은 필드 제거 , Block은 이벤트 전체 전송 중지 이므로 구분합니다.3. 수신 결과 비교
pii-demo-001 가상 이벤트를 Webhook Receiver에 입력합니다.두 Destination의 수신 파일과 Route별 Logs를 비교합니다.
외부 수신 파일에는 원본 lab@example.invalid가 그대로 존재해서는 안 됩니다 . Mask 결과가 실제 정책과 일치하는지 확인합니다.
내부 수신 데이터는 실습 환경에서 Audit Only가 허용된 경우에만 확인합니다.
완료 조건: 외부 Route의 저장된 유효 정책, 성공한 전송 로그, 외부 수신 데이터의 마스킹 이 모두 확인됩니다.실패 시
이메일 필드 미표시: Sample, Event Root, Union Schema의 실제 Field Path 확인
외부 수신 데이터가 원본 그대로임: 실데이터 테스트를 중지하고 Inherit/Override, Effective Policy, 현재 Run 확인
저장 시 409 STREAM_STALE_WRITE: Control #413 에서 재현된 개발 문제입니다. 저장되지 않은 Draft를 적용 완료로 간주하지 말고, 실제로 성공하는 Route Edit 경로에서만 재검증합니다.
관련: Schema 변경 , Governance .
