파일 전송 감사 추적: 누가 무엇을 다운로드했는지 추적

파일 전송 감사 추적은 업로드부터 삭제까지 전송 생애 전체의 모든 의미 있는 이벤트를 추가 전용 로그에 기록합니다. 누가 어느 .pdf를 다운로드했는지, 언제, 어디서, 어떤 기기로 접근했는지를 즉시 확인할 수 있어야 합니다. GDPR 제30조, HIPAA 164.312(b), SOC 2 CC7.2, PCI DSS 4.0 요구사항 10이 이를 의무화하며, 한국 개인정보보호법(PIPA) 제29조도 접근 기록 관리를 명시적으로 요구합니다. 감사 추적 없이는 침해 사고가 발생했을 때 순전히 추측에 의존할 수밖에 없습니다.

로그에 담아야 할 이벤트

여섯 가지 이벤트가 대부분의 포렌식 시나리오를 커버합니다. 첫째, 업로드 완료: 발신자 IP, 파일 크기, 암호문의 SHA-256, 선언된 MIME 타입. 둘째, 링크 생성: 만료 시간, 최대 다운로드 횟수, 비밀번호 플래그, 2FA 플래그. 셋째, 접근 시도: 타임스탬프, IP /24, 비밀번호 정확성 여부, User-Agent 계열. 넷째, 다운로드 시작: 세션 ID, 첫 번째 바이트 제공. 다섯째, 다운로드 완료: 총 바이트, 소요 시간, HTTP 2xx/4xx 코드. 여섯째, 삭제: 트리거(만료, 최대 횟수 도달, 수동 취소), 타임스탬프, 제로화 확인. 이 중 하나라도 빠지면 감사관이 반드시 지적하는 공백이 생깁니다.

변조를 막는 추가 전용 스토리지

로그는 관리자조차 수정할 수 없어야 합니다. 대표적인 방법은 두 가지입니다. 하나는 AWS S3 버킷에 Object Lock을 Governance 모드(HIPAA라면 Compliance 모드)로 설정하고 90일 보존 기간을 적용하는 것입니다. 다른 하나는 ClickHouse MergeTree의 FINAL 보장과 함께 이벤트를 스트리밍하고, 일별 Merkle 루트를 공개 게시판에 게재하는 방식입니다. Bitcoin의 OpenTimestamps를 활용한 블록체인 앵커링은 하루 약 400원으로 이벤트 위조 불가 증명을 제공합니다. 대부분의 팀에는 S3 Object Lock과 IAM 권한 분리로 충분합니다.

감사관이 파싱할 수 있는 구조화 형식

JSON Lines도 유효하지만 감사관들은 SIEM 수집을 위해 RFC 5424 syslog 또는 OCSF(Open Cybersecurity Schema Framework)를 선호합니다. 각 이벤트는 activity_id, severity_id, time, actor.user.email_hash, src_endpoint.ip, file.hashes.sha256 같은 필드를 포함합니다. Splunk, Datadog, Elastic 모두 OCSF를 기본 지원합니다. 소규모 팀이라면 (timestamp_utc, event_type, transfer_id, ip_hash, outcome, bytes) 열로 구성된 CSV를 분기별로 공유 드라이브에 저장하는 것만으로도 SIEM 라이선스 없이 증거 요건을 충족할 수 있습니다.

GDPR·PIPA 하에서의 IP 주소 처리

IP 주소는 GDPR 하에서 개인정보입니다(2016년 Breyer v. Germany 판결로 확인). 한국 개인정보보호법 제3조 역시 IP 주소를 개인정보로 분류합니다. 따라서 IP를 영구적으로 그대로 기록해서는 안 됩니다. 일일 회전 키를 사용한 HMAC-SHA256 해싱으로 24시간 이후의 상관관계를 차단하면서도 당일 포렌식은 유지할 수 있습니다. 원본 IP는 Article 6(1)(f) 정당한 이익이 문서화된 활성 조사 기간에만 보관합니다. /24 프리픽스만 저장하는 방식은 지리적 위치는 유지하되 개인 식별을 제거하는 합리적 절충안입니다.

타임스탬프 동기화와 부인 방지

타임스탬프가 정확해야만 감사 추적이 신뢰를 얻습니다. NIST 또는 Cloudflare의 time.cloudflare.com에 대해 chrony나 systemd-timesyncd를 운용하고, 각 이벤트에 clock_skew_ms 필드를 포함시켜 포렌식 분석가가 신뢰 구간을 파악할 수 있게 합니다. 부인 방지를 위해서는 AWS KMS 또는 YubiHSM에 저장된 키로 각 로그 파일에 Ed25519 서명을 적용합니다. 이 서명은 로그가 사후 변조되지 않았음을 증명하며, HSM을 침해하지 않고는 위조할 수 없다는 점에서 법원에서도 수용 가능한 수준의 증거력을 제공합니다.

규정별 보존 기간

각 프레임워크는 서로 다른 보존 기간을 요구합니다. HIPAA는 생성일 또는 마지막 사용일 중 늦은 날부터 6년(45 CFR 164.316(b)(2)). PCI DSS 4.0은 12개월 즉시 접근 가능 보존과 추가 12개월 콜드 스토리지를 의무화합니다. SOC 2는 자체 정책에 위임하되 감사관들은 1년 미만을 문제로 봅니다. 개인정보보호법 제21조는 수집 목적 달성 후 파기를 원칙으로 하므로, 로그 보존 기간은 해당 로그가 뒷받침하는 비즈니스 기록의 보존 기간에 맞추어야 합니다. 데이터베이스 스키마에 테넌트별 보존 정책을 설정하고, 남은 세그먼트를 재서명하는 월별 정리 작업을 실행하십시오.

사람이 읽을 수 있는 보고서 생성

원시 로그는 규제 기관의 요청을 충족하지 못합니다. 전송 ID, 날짜 범위, 또는 수신자 이메일 해시로 필터링하고 회사 로고, 이벤트 표, Ed25519 서명이 포함된 타임스탬프 PDF를 생성하는 보고서 생성기를 구축하십시오. 보고서 자체의 SHA-256 해시를 표지에 포함하면 수신자가 변조를 감지할 수 있습니다. WeasyPrint나 Typst를 Jinja2 템플릿과 함께 사용하면 깔끔하게 렌더링됩니다. HexaTransfer는 PDF와 CSV 두 형식으로 보고서를 내보냅니다. 감사관들은 대개 두 가지 모두 요청합니다.

이상 징후 경보 설정

추적 로그는 아무도 읽지 않으면 무용지물입니다. 경보를 트리거하는 규칙을 정의하십시오: 10분 내 비밀번호 5회 이상 실패, 발신자 국가와 일치하지 않는 IP 범위에서의 다운로드, 의료 파일에 대한 업무 시간 외 접근, 단일 링크에 대한 4xx 급증. SOC 팀에는 PagerDuty로, 개인 운영자라면 Slack 웹훅으로 경보를 라우팅하십시오. 임계값은 분기별로 조정해야 합니다. 소음이 많은 경보는 무시되어 목적 자체를 훼손합니다. 규칙 집합을 문서화하면 감사관에게 단순 로깅이 아닌 탐지까지 고민했음을 증명할 수 있습니다.

삭제도 로그 이벤트다

전송의 마지막 기록은 삭제입니다. 트리거(만료 타이머, 최대 다운로드 횟수, 수동 취소), 제로화 방법(패스 횟수, 디바이스 유형), 삭제 후 디스크 영역의 SHA-256을 기록하여 식별 가능한 데이터가 남아 있지 않음을 증명하십시오. 이는 GDPR 제17조의 삭제권 확인과 HIPAA 침해 통지 임계값 산정에서 중요합니다. 삭제 로그는 파일 자체보다 오래 살아남습니다. 때로는 수년씩. 그것이 바로 준수 시스템이 작동하는 방식입니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.