로그 스택에 숨어 있는 GDPR 리스크
2026년 업데이트
대부분의 팀은 개인정보를 위해 데이터베이스를 확인합니다. 로그 시스템에 대해 동일하게 하는 팀은 더 적습니다.
GDPR 제5조 제1항 (e)호는 개인정보를 보유할 수 있는 기간을 제한합니다. 데이터베이스의 경우 팀이 정책을 설정하고 삭제 작업을 실행합니다. 로그 파일의 경우 규칙은 더 단순합니다. 디버깅을 위해 90일 동안 모든 것을 유지합니다.
문제는 무엇일까요? 이 기록들에는 개인정보가 포함됩니다. 요청 항목에는 사용자 이메일이 있습니다. 오류 캡처에는 원시 입력 값이 있습니다. 액세스 항목에는 IP 주소가 있습니다. 이 각각은 GDPR 하에서 개인정보로 간주됩니다. 팀은 각각에 대해 합법적인 근거와 보존 계획이 필요합니다.
로그 파일에 무엇이 담기는가
표준 웹 앱 로깅은 광범위한 PII를 가져옵니다.
액세스 기록 (nginx/Apache):
- IP 주소 — EDPB 지침에 따라 개인정보
- 사용자 에이전트 문자열 — 기기 핑거프린팅을 가능하게 할 수 있음
- 세션 토큰 — 출력에 기록된 경우
앱 기록 (구조화된 JSON):
- 사용자 ID와 이메일 주소
- 입력 오류 — 종종 실제 사용자 정보일 수 있는 원시 유효하지 않은 값 포함
- 비즈니스 이벤트 — 고객 계정에 연결된 주문 ID
- 검색 쿼리 — 이름이나 주소 포함 가능
API 게이트웨이 기록:
- 인증 헤더 — 일부 설정에서 부분적으로 캡처
- 쿼리 파라미터 — 사용자 ID, 이름, 이메일 포함 가능
- 요청 및 응답 본문 — 디버그 레벨 설정에서 존재
데이터베이스 감사 항목:
email = 'user@example.com'과 같은 WHERE 절이 포함된 SQL 쿼리- 쿼리 파라미터의 리터럴 개인 값
이는 의도적으로 발생하지 않습니다. GDPR이 아닌 디버깅을 위해 구축된 로깅의 부작용입니다.
IP 주소에 관한 EDPB 지침
유럽 데이터 보호 이사회(EDPB)는 IP 주소가 개인정보라고 밝힙니다. 인터넷 서비스 제공업체는 이를 구독자와 연결할 수 있습니다. 조직 내에서는 특정 사용자를 식별할 수 있습니다.
영향은 직접적입니다. IP 주소가 포함된 액세스 기록은 개인 기록입니다. nginx 출력을 12개월 동안 유지하는 것은 개인정보를 12개월 동안 유지하는 것입니다. 이는 제6조에 따른 합법적인 근거가 필요합니다. 또한 보존 기간이 명시된 목적과 일치해야 합니다.
대부분의 팀은 이 단계를 건너뜁니다. "보안 팀이 90일이라고 해서 항목을 90일 동안 유지합니다"는 경험 법칙입니다. GDPR 제5조 제1항 (e)호 검토가 아닙니다. 이것이 더 넓은 프로그램에 어떻게 적합한지는 법적 컴플라이언스 개요를 참조하십시오.
컴플라이언스 달성 방법
대부분의 팀에서 실용적인 방법은 보존 기간을 줄이는 것이 아닙니다. 더 긴 보존 기간에 대한 운영 및 보안상의 이유는 실재합니다. 더 나은 방법은 장기 저장 전에 기록을 마스킹하는 것입니다.
계층적 모델이 효과적입니다.
0~7일: 활성 디버깅을 위한 전체 원시 기록. 7일은 대부분의 팀에 충분히 짧습니다.
7~90일: 트렌드 분석 및 보안 검토를 위한 마스킹된 기록. IP 주소가 교체됩니다. 사용자 이메일이 안정적인 토큰이 됩니다. 계정 번호가 마스킹됩니다. 타임스탬프, 오류 코드, 지연, 엔드포인트와 같은 주요 필드는 그대로 유지됩니다.
90일 이상 (필요한 경우): 집계된 출력만 유지. 이벤트 수, 오류율, 지연 범위. 사용자 수준 기록은 남아 있지 않습니다.
개인정보는 7일에 중단됩니다. 집계된 출력은 누구도 노출하지 않고 이후로 이어질 수 있습니다. 자세한 내용은 보안 및 컴플라이언스를 참조하십시오.
모니터링을 위한 구조 유지
효과적인 마스킹은 JSON 구조를 그대로 유지합니다. 내용만 교체합니다. 이렇게 하면 디버깅 및 알림에 출력을 계속 사용할 수 있습니다.
그대로 유지되는 것:
- JSON 키와 중첩 구조
- 타임스탬프와 시간 순서
- 오류 유형과 HTTP 상태 코드
- HTTP 메서드, 경로, 지연 값
- 비즈니스 이벤트 유형
교체되는 것:
- 이메일 주소 → 원본별 안정적 토큰 (예:
user1@example.com) - IP 주소 → RFC 5737 범위 (
192.0.2.x) - 계정 번호 →
ACCT_XXXXX - 전화번호 →
+XX XXX XXX XXXX - 오류 텍스트의 이름 →
[PERSON]
안정적 토큰은 추적을 유용하게 유지합니다. 40개 항목에 걸쳐 user1@example.com에 대한 추적은 원본과 동일하게 작동합니다. 집계된 지표 — 오류율, 지연, 처리량 — 는 개인정보가 전혀 필요하지 않습니다. 가명화와 익명화 용어에 대해서는 용어 사전을 참조하십시오.
세 가지 통합 방법
세 가지 패턴이 대부분의 엔지니어링 팀을 커버합니다.
옵션 1 — 파이프라인 마스킹: Fluentd 또는 Logstash가 각 줄을 전달하기 전에 인터셉트합니다. 마스킹 단계가 인라인으로 실행됩니다. Elastic 또는 Datadog은 정리된 기록만 받습니다. 앱 코드 변경이 필요하지 않습니다.
옵션 2 — 야간 배치: 원시 기록이 로컬 스토리지에 저장됩니다. 야간 작업이 전날의 출력을 마스킹하고 원시 버전을 삭제합니다. 마스킹된 기록이 장기 스토리지로 이동합니다. 원시 출력은 7일 동안만 유지됩니다.
옵션 3 — 공유 전 마스킹: 원시 기록은 엄격한 액세스 제어와 함께 내부에 유지됩니다. 침투 테스터나 외부 계약업체와 공유하기 전에 마스킹 처리를 실행합니다. 외부 당사자는 항상 정리된 버전을 받습니다.
GDPR 문서화를 위해 마스킹은 제32조에 따른 "기술적 조치"입니다. 도구, 설정, 보존 정책을 제30조에 따른 처리 활동 기록(RoPA)에 기록하십시오. 일반적인 RoPA 질문은 FAQ를 참조하십시오.
실제 사례가 궁금하신가요? 구체적인 구현 세부 사항은 사례 연구를 확인하십시오. 내장된 마스킹 파이프라인이 포함된 플랜은 가격 정책을 검토하십시오.