이벤트에서 민감한 데이터 수정

가장 안전한 민감한 값은 이벤트 파이프라인에 절대 들어가지 않는 값입니다. 요청, 예외, 모델 응답 또는 데이터베이스 객체를 직렬화하고 나중에 위험한 키를 제거하려고 시도하는 대신 명시적인 허용 목록에서 구조화된 이벤트를 빌드하세요.

기본적으로 제외할 데이터

API 키, 비밀번호, 세션 쿠키, 인증 헤더, 웹훅 서명, 결제 세부정보, 전체 요청 본문, 데이터베이스 연결 문자열 또는 원시 프롬프트 및 완료를 기록하지 마세요. 자유 형식 텍스트에는 필드 이름이 무해해 보이는 경우에도 개인 또는 기밀 데이터가 포함될 수 있습니다.

이메일 주소보다 내부 불투명 식별자를 선호하세요. 원시 예외를 제어된 error_type로 교체하고 적절한 액세스 및 보존을 통해 진단 시스템에서 전체 스택 추적을 유지합니다. 식별자나 쿼리 문자열이 포함된 URL을 안정적인 경로 템플릿으로 바꿉니다.

경계에 컨트롤 적용

필드별로 이벤트 개체 필드를 만듭니다.

const event = {
  route_template: request.routeOptions.url,
  method: request.method,
  status_code: response.statusCode,
  latency_ms: elapsedMs,
  account_id: account.internalId,
};

await telemetry.log("api_request_completed", event);

재사용 가능한 소독제가 필요한 경우 심층 방어 수단으로 활용하세요. 중첩된 개체, 배열, 대체 대문자 사용 및 예상치 못한 유형을 테스트합니다. 문자열 길이를 바인딩하고 계약 외부의 필드를 거부합니다. 원래 값에 작거나 추측 가능한 세트가 있는 경우 해싱은 익명화가 아닙니다.

검토 및 응답

모든 대규모 이벤트 계약에 소유자를 할당합니다. 프로덕션 방출을 활성화하기 전에 개발 중인 샘플 행을 검토하세요. 새로운 식별자가 추가되면 보존 및 액세스 요구 사항을 다시 검토하세요.

민감한 데이터가 발견되면 내보내기 경로를 중지하고, 영향을 받는 테이블과 시간 범위를 식별하고, 노출된 비밀을 교체하고, 적절한 경우 지원되는 삭제 워크플로를 사용하세요. 그런 다음 실제 이벤트 생성자를 실행하는 회귀 테스트를 추가합니다.

계약 관행은 이벤트 스키마 설계를, 수집 형태는 로그 API 참조를 읽어보세요.