DLP 정책이 업무를 막지 않게 만드는 데이터 분류 기준
민감 정보 유출 방지를 위해 차단보다 분류, 라벨, 예외 승인 흐름을 먼저 설계해야 하는 이유를 설명한다. DLP·Data Classification·Privacy 관점에서 공격 경로를 쉬운 예로 풀고 예방, 탐지, 대응 순서로 확인할 항목을 제시한다.
핵심 요약
DLP를 처음부터 전면 차단으로 배포하면 오탐과 우회가 늘어난다. 먼저 데이터 등급과 정상 업무 흐름을 정의하고, 탐지·경고·사유 입력·승인·차단을 위험에 따라 단계화해야 한다. 예외에는 소유자와 만료일을 붙이고, 정책 품질은 차단 건수보다 실제 유출 경로와 반복 오탐을 얼마나 줄였는지로 평가한다.
DLP(Data Loss Prevention) 정책은 민감한 데이터가 이메일, 협업 도구, 브라우저, USB, 클라우드 저장소로 나가는 흐름을 탐지하거나 제한한다. 그러나 데이터 분류와 업무 맥락 없이 주민번호 패턴이나 “confidential” 문자열만 차단하면, 정상 계약서와 테스트 데이터까지 막히고 사용자는 압축 파일, 개인 메신저, 화면 캡처 같은 우회 경로를 찾는다.
DLP의 목표는 모든 이동을 막는 것이 아니라 어떤 데이터가 어떤 목적지로, 누가, 얼마나, 어떤 업무 이유로 이동할 수 있는지 반복해서 판단하는 것이다. 도구 설정 전에 분류 기준과 예외 흐름을 설계해야 한다.
네 등급이면 시작할 수 있다
초기에는 지나치게 많은 라벨보다 다음처럼 행동이 다른 네 등급이 실용적이다.
| 등급 | 예시 | 기본 공유 | 기본 보존·삭제 |
|---|---|---|---|
| 공개 | 보도자료, 공개 문서 | 외부 공유 허용 | 게시 정책에 따름 |
| 내부 | 내부 절차, 일반 회의 자료 | 인증된 구성원 | 업무 종료 후 정리 |
| 민감 | 고객 연락처, 계약, 소스 코드 | 승인된 팀·파트너 | 목적과 보존 기간 명시 |
| 제한 | 인증 비밀, 결제·건강·고위험 개인정보 | 지정 시스템과 최소 인원 | 강한 승인, 빠른 삭제·격리 |
분류는 문서 머리글만 의미하지 않는다. 등급별로 저장 위치, 외부 공유, 다운로드, 인쇄, 암호화, 로그, 보존, 삭제 행동이 달라야 한다. 자세한 운영 기준은 데이터 분류 체계와 연결한다.
정책은 데이터와 맥락을 함께 본다
단일 정규식은 오탐이 많고 변형된 데이터는 놓친다. 가능하면 다음 신호를 조합한다.
- 데이터 특징: 고유 식별자 패턴, 사전, 지문, 문서 라벨
- 소유·출처: CRM, 소스 저장소, 재무 시스템에서 생성됐는가
- 사용자·기기: 계약직, 관리자, 관리되지 않는 기기인가
- 목적지: 승인된 협력사, 개인 메일, 새 파일 공유 서비스인가
- 양과 속도: 한 건인지 수천 건의 내보내기인지
- 행동: 복사, 다운로드, 인쇄, 업로드, 공유 링크 생성인가
- 업무 맥락: 승인 티켓, 계약, 프로젝트와 연결되는가
예를 들어 고객지원 직원이 승인된 티켓에 고객 한 명의 주소를 붙이는 행위와, 퇴사 예정 직원이 수천 명의 고객 정보를 개인 드라이브로 올리는 행위는 같은 패턴이 있어도 위험이 다르다.
차단보다 단계적 통제를 설계한다
DLP 정책을 다음 순서로 배포하면 업무 충격을 줄일 수 있다.
1단계: 관찰
사용자에게 영향을 주지 않고 2~4주 동안 탐지한다. 어떤 데이터가 어디로 이동하는지, 어떤 팀에서 오탐이 많은지, 승인된 SaaS가 누락됐는지 확인한다. 이 단계의 로그 자체에 민감 정보가 과도하게 저장되지 않도록 관측성 데이터 개인정보 원칙을 적용한다.
2단계: 경고
낮거나 중간 위험에는 사용자에게 데이터 종류와 정책 이유를 보여 준다. 사용자가 취소하거나 안전한 경로로 전환할 수 있어야 한다. 막연한 “정책 위반” 대신 “제한 데이터는 개인 이메일로 보낼 수 없습니다”처럼 교정 행동을 안내한다.
3단계: 사유 입력 또는 관리자 승인
업무상 필요한 예외에는 프로젝트, 수신자, 기간, 데이터 범위, 승인자를 기록한다. 사유 입력만으로 무제한 허용하면 형식적인 클릭이 되므로, 위험이 높은 채널은 관리자 또는 데이터 소유자의 승인을 요구한다.
4단계: 자동 차단
다음과 같이 영향이 명확하고 우회 비용보다 위험이 큰 경우부터 차단한다.
- 비밀키·접근 토큰의 외부 업로드
- 제한 데이터의 개인 이메일 전송
- 관리되지 않는 기기로 대량 다운로드
- 공개 링크로 고객 데이터 공유
- 악성 또는 제재된 목적지로 전송
예외는 별도 제품처럼 운영한다
예외 레코드에는 최소한 다음 필드가 필요하다.
- 요청자와 데이터 소유자
- 데이터 등급과 예상 수량
- 수신자·도메인·애플리케이션
- 업무 목적과 계약 또는 티켓 링크
- 허용할 행동과 기술적 범위
- 시작일과 만료일
- 승인자와 재검토 결과
“재무팀 전체”, “협력사 도메인 전체”처럼 넓은 예외보다 특정 사용자·프로젝트·채널·기간으로 좁힌다. 만료 시 자동 회수하고, 계속 필요하면 재승인한다. 예외가 정책보다 많아지면 정책을 고치는 신호다.
탐지와 조사에 필요한 신호
- 평소보다 많은 파일 다운로드·복사·인쇄
- 퇴직 예정자나 권한 변경 직후의 대량 이동
- 새 개인 메일·파일 공유·생성형 AI 서비스로 업로드
- 문서 라벨 제거 또는 확장자·압축 방식 변경
- 짧은 시간에 반복되는 차단과 우회 시도
- 예외 승인 직후 범위를 넘어선 데이터 전송
- DLP 에이전트 비활성화, 로그 중단, 기기 등록 해제
- 동일 데이터가 여러 승인되지 않은 채널로 이동
조사 화면에는 원문 전체를 노출하기보다 이벤트 ID, 데이터 등급, 탐지 근거, 일부 마스킹된 샘플, 사용자·기기·목적지, 승인 정보를 제공한다. 조사자 권한도 최소화하고 조회 기록을 남긴다.
업무를 막는 DLP의 전형적인 실패
| 실패 | 현상 | 교정 |
|---|---|---|
| 패턴 하나로 즉시 차단 | 정상 문서까지 막혀 우회 증가 | 관찰 기간과 다중 신호 사용 |
| 데이터 소유자가 없음 | 예외 승인 책임이 보안팀에 몰림 | 저장소·업무별 데이터 소유자 지정 |
| 메시지가 모호함 | 사용자가 무엇을 고칠지 모름 | 데이터와 안전한 대체 경로 안내 |
| 예외가 무기한 | 정책 사각지대가 영구화 | 소유자·범위·만료일 자동화 |
| 차단 건수만 KPI로 사용 | 오탐이 많을수록 성과처럼 보임 | 실제 사고, 반복 오탐, 처리 시간 측정 |
| 로그에 원문을 저장 | DLP 시스템이 새 유출 저장소가 됨 | 수집 최소화와 마스킹 적용 |
정책 성과를 측정하는 지표
차단 수가 늘었다고 안전해진 것은 아니다. 다음 지표를 함께 본다.
- 정책별 정확한 탐지와 오탐 비율
- 사용자 경고 후 안전한 채널로 전환한 비율
- 예외 승인 평균 시간과 만료 후 회수율
- 동일 사용자·부서의 반복 위반률
- 대량 반출 이벤트의 조사 시작 시간
- 관리되지 않는 채널의 데이터 이동량 변화
- 민감 저장소 중 소유자와 분류가 있는 비율
오탐이 반복되는 팀에는 교육만 요구하지 말고, 승인된 업무 경로가 실제로 사용 가능한지 확인한다.
사고가 의심될 때
- 이벤트 원문을 과도하게 복제하지 말고 식별자와 증거 위치를 보존한다.
- 사용자 세션과 공유 링크를 제한하되 업무 영향 범위를 기록한다.
- 데이터 소유자와 개인정보·법률 담당자에게 데이터 종류와 지역을 전달한다.
- 목적지에서 회수·삭제가 가능한지 확인하고 증거를 남긴다.
- 같은 데이터가 다른 채널로 이동했는지 검색한다.
- 정책 오탐인지 실제 미승인 반출인지 업무 맥락으로 판단한다.
- 법적 신고나 고객 통지 여부는 관할 법률과 계약을 검토한 전문가가 결정한다.
운영 체크리스트
- 데이터 등급마다 공유·저장·보존·삭제 행동이 정의돼 있다.
- 고위험 저장소와 데이터 소유자가 식별돼 있다.
- 정책은 데이터 패턴 외에 사용자·기기·목적지·수량을 본다.
- 신규 정책은 관찰과 경고 단계를 거친다.
- 고위험 행동만 우선 자동 차단한다.
- 예외에는 데이터 범위, 소유자, 승인자, 만료일이 있다.
- 조사 로그와 샘플 데이터가 마스킹돼 있다.
- 오탐과 반복 위반을 정책별로 측정한다.
- 승인된 안전한 대체 전송 경로가 있다.
- 분기마다 오래된 예외와 사용하지 않는 정책을 정리한다.
참고 기준
결론
업무를 막지 않는 DLP는 느슨한 DLP가 아니다. 데이터 등급과 정상 업무 경로를 먼저 정의하고, 위험에 따라 관찰·경고·승인·차단을 구분하는 DLP다. 정책을 우회하는 사람을 탓하기 전에 안전한 업무 경로와 만료되는 예외가 설계돼 있는지 확인해야 한다.
전체 댓글 0개