개인정보보호법(PIPA) + 시행령 + 「개인정보의 안전성 확보조치 기준」(PIPC 고시) 관점에서, 개인정보처리시스템 로그를 “어디까지/어떻게” 남겨야 감사에 견딜 수 있는지를 정리한 가이드입니다.
법에서 요구하는 “로그”의 핵심 취지
결론부터 말씀드리면, 법이 원하는 건 “SQL 원문을 다 남겨라”가 아니라 “누가(계정), 언제(시간), 어디서(IP/단말), 무엇을(조회/수정/삭제/다운로드), 누구의 개인정보를(대상 식별), 어떤 결과로(성공/실패) 처리했는지”를 사후에 입증 가능하게 하라는 것입니다.
- 개인정보보호법 제29조는 안전조치 의무에 ‘접속기록 보관 등’을 명시합니다.
- 시행령은 제29조를 구체화해 개인정보처리자가 취해야 할 안전조치(내부관리계획, 접근권한 관리 등)를 열거합니다.
- “개인정보처리시스템”은 DB 시스템 등 개인정보를 처리하도록 구성한 시스템(즉, 앱/WAS만이 아니라 DB 포함)으로 정의됩니다.
“어드민 로그만으로 충분?” vs “DB 쿼리까지 전부 기록?”
1. 어드민(웹/관리자 화면)에서 발생한 처리
대부분의 감사/사고조사에서 핵심은 ‘어드민 행위 로그(업무 로그)’입니다.
✅ 권장(감사에서 인정받기 쉬움)
- “관리자 계정 A가”
- “회원 B의 개인정보를”
- “조회/수정/삭제/다운로드 했다”
- “조회 조건/다운로드 사유/결과 건수/성공 여부”
❌ 비권장(오히려 리스크가 커질 수 있음)
- ORM/쿼리빌더가 만든 SQL 원문을 전부 남기기
- 로그 과다(저장·검색·검토 불가)
- SQL에 개인정보 값이 그대로 포함될 수 있어 로그가 ‘2차 개인정보 저장소’가 됨
- 운영자/개발자/외주가 로그만 봐도 개인정보를 재구성 가능
즉, 어드민 조작에 대해 “DB SQL까지 1:1로 전부 남길 의무”는 일반적으로 정답이 아닙니다.
감사 대응 관점에서는 “업무행위(비즈니스 이벤트) 로그”가 정답에 더 가깝습니다.
2. DB에 “직접” 접속해서 조회/수정하는 행위(개발자/DBA/운영자)
😮 이 경우는 성격이 달라집니다.
- 앱을 거치지 않으므로 어드민/애플리케이션 로그에 남지 않을 수 있음
- 내부자 오남용 사고에서 가장 자주 문제 되는 영역
그래서 DB 직접 접속은 ‘DB Audit(감사로그)’ 또는 DB 접근제어 로그로 보강하는 게 실무적으로 안전합니다.
이때는 “무엇을 했는지” 입증을 위해 SQL 텍스트(또는 최소한의 Statement 정보)가 필요해지는 경우가 많습니다.
다만 SQL 전체 원문을 남기더라도 “개인정보 값 마스킹/바인딩 처리”가 같이 가야 합니다(로그가 개인정보를 포함하면 역으로 취약점).
법/고시 기준으로 “반드시” 챙겨야 할 접속기록 요건
🧾「개인정보의 안전성 확보조치 기준」은 접속기록을 일정기간 보관하고 정기 점검하도록 요구합니다.
- 기본 1년 이상 보관, 특정 조건(예: 대량 처리 등)에 해당하면 2년 이상 보관 취지로 운영됩니다.
- 고시는 PIPA 제29조 및 시행령 조항에 근거한 “최소 기준”으로 제시됩니다.
⚠️ 실무 팁: “보관만” 해두면 끝이 아니라, 정기 점검(로그 리뷰) 증적이 함께 있어야 감사에서 방어가 됩니다.
감사에서 통과하기 쉬운 “모범 로그 설계”
1. 어드민/애플리케이션(업무행위) 로그 – 권장 포맷
😀 SQL 대신 아래처럼 업무 이벤트 중심으로 남기세요.
{
"ts": "2025-12-17T10:22:33+09:00",
"system": "privacy-admin",
"actor": { "id": "admin01", "role": "CS_MANAGER" },
"src": { "ip": "203.0.113.10", "ua": "Mozilla/5.0" },
"action": "READ",
"menu": "회원정보상세조회",
"target": { "subject_id": "user_12345" },
"scope": ["name","phone","email"],
"reason": "고객 본인확인 문의 대응",
"result": { "status": "SUCCESS", "count": 1 }
}✅ 감사 포인트
- 누가/언제/어디서/무엇을/누구의 개인정보를 처리했는지 즉시 재구성 가능
- 다운로드/대량조회는 별도 이벤트로 분리(사유 필수, 파일명/건수 포함)
- 로그 자체에 개인정보를 과다 저장하지 않기(필드 최소화/마스킹)
2. DB 직접접속(Audit) 로그 – 권장 포인트
🙂 DB 감사로그는 제품/DB종류마다 다르지만, 감사에서 자주 보는 핵심은 아래입니다.
- 계정(개인 식별 가능한 계정, 공용계정 지양)
- 시간 / 접속지(IP/호스트)
- 수행한 작업(SELECT/UPDATE/DELETE/DDL 등)
- 대상(스키마/테이블/오브젝트)
- (가능하면) SQL 텍스트 또는 Statement 요약
- 단, 값(개인정보)이 들어가는 부분은 마스킹/바인딩 기반 기록 권장
“DB 쿼리 로그를 완전하게 기록”의 현실적인 해석(권장 의사결정 표)
| 상황 | 무엇을 “필수로” 남기면 감사에 유리한가 | SQL 원문 |
|---|---|---|
| 어드민 화면에서 조회/수정/삭제 | 업무행위 로그(대상 식별 + 행위 + 사유 + 결과) | 보통 불필요/비권장 |
| API로 개인정보 제공/조회 | API 호출자/토큰 주체 + 대상 + 범위 + 결과 | 보통 불필요 |
| 배치/백오피스 자동처리 | 잡ID + 실행주체 + 대상범위 + 처리건수 + 결과 | 선택 |
| 개발자/DBA가 DB 직접 접속 | DB Audit/접근제어 로그(Statement 중심) | 필요성이 커짐 |
| 장애/성능 분석을 위해 DB general log 상시 ON | 개인정보 포함 위험 + 과다로그 | 보안 관점 비권장 |
“로그 자체가 또 다른 개인정보 저장소”가 되지 않게 하는 체크포인트
🛡️ 운영 기준(권장)
- 로그 접근권한 최소화(보안팀/감사담당/제한된 운영자)
- 로그 최소수집(대상 식별자는 내부 ID로, 원문 개인정보는 지양)
- 마스킹/토큰화(이메일/전화/주민번호 등)
- 무결성 확보(중앙집중 수집, WORM/Immutable 스토리지, 해시체인 등)
- 위변조/삭제 방지(로그 서버 분리, 관리자 권한 분리)
- 탐지 룰(야간 대량조회, 특정 계정의 반복 조회, 대량 다운로드 등)
감사 대응 “무엇을 어떻게 준비”해야 하나요?
1. 감사에서 흔히 요구되는 증적 세트
📌 아래 3개가 세트로 있어야 강합니다.
- 정책/절차
- 접속기록 관리 절차(보관기간, 접근권한, 점검주기, 이상징후 대응)
- 기술 구현 증적
- 어드민 로그 샘플, DB 감사로그 샘플
- 로그 필드 정의서(각 필드 의미/마스킹 기준)
- 운영 증적(가장 자주 빠짐)
- 월간/주간 점검 리포트(누가 언제 무엇을 점검했고 이슈를 어떻게 조치했는지)
- 이상징후 알림 발생/조치 티켓
✅ “로그가 있다”보다 “로그를 점검했고 조치했다”가 감사에서 훨씬 강한 방어 논리입니다.
바로 적용 가능한 최소 구현 예시(DB 직접접속 Audit)
아래는 “참고용” 예시입니다(운영환경/버전에 따라 달라질 수 있습니다).
PostgreSQL (pgaudit 사용 예시)
-- (개념 예시) pgaudit 확장 + log_statement 설정 조합
-- 실제 적용은 pgaudit 문서/버전 확인 후 진행 권장SQL Server (SQL Server Audit 개념)
- Server Audit 생성 → Database Audit Specification에서 SELECT/UPDATE/DELETE 등 감사
MySQL (일반 로그 상시 ON 대신 Audit Plugin/솔루션 권장)
- general_log 상시는 보안·성능 부담이 커서 보통 “감사 목적 상시”로는 비추
- 엔터프라이즈/서드파티 audit 플러그인 또는 접근제어로 대체가 흔함
어드민 조작으로 인해 내부적으로 DB 쿼리가 실행되더라도, “SQL 원문을 전부 기록”하는 것이 법의 본질적 요구라고 보기 어렵고, 감사 대응에는 “업무행위 로그(누가/언제/누구의/무엇을/왜/결과)”를 탄탄히 하는 것이 보통 더 적합합니다.
다만, 개발자/DBA 등 특권 사용자의 DB 직접접속은 앱 로그로 커버가 안 되므로 DB Audit/접근제어 로그로 보강(필요시 SQL 수준) 하는 구성이 가장 안전합니다.
댓글