직원이 업무 문서를 외부로 보냈다고 해서 모두 정보 유출인 것은 아닙니다. 거래처에 전달해야 할 자료도 있고, 회사 밖으로 나가면 안 되는 고객 명단이나 원가 자료도 있습니다. 기업이 구분해야 할 것은 외부 전송 자체보다 어떤 정보를 누가 어디로 보내는지, 그리고 허용된 업무인지입니다.
DLP(Data Loss Prevention)는 민감정보를 식별하고 사용·공유 행위에 정책을 적용해 부적절한 반출 위험을 줄이는 통제입니다. 이 글에서는 제품별 메뉴보다 정보 식별, 정책 판단, 경로별 집행, 예외 관리가 연결되는 구조를 살펴봅니다.
DLP는 정보와 행위를 함께 판단
방화벽이 통신의 출발지·목적지·프로토콜 등을 기준으로 접근을 통제한다면, DLP는 보호 대상 정보와 그 정보에 대한 행위를 중심으로 판단합니다. 두 기능은 제품에 따라 결합될 수 있지만, 통신이 허용됐다는 사실만으로 문서 반출까지 허용됐다고 볼 수는 없습니다.
DLP의 기본 판단은 ‘보호 대상 정보인가 → 어떤 사용·공유 행위인가 → 정책상 허용되는가 → 어떤 조치를 적용할 것인가’로 정리할 수 있습니다. Microsoft 공식 문서도 민감정보를 식별하고 활동을 감시하며, 정책 조건에 따라 경고나 공유 제한 등을 적용하는 구조를 설명합니다. (Microsoft Learn — Learn about data loss prevention)
예를 들어 회사 승인 저장소에는 문서를 보관할 수 있지만 개인 메일로는 전송할 수 없도록 설계할 수 있습니다. 이는 정책 설계 예시이며, 모든 내부 저장이나 외부 메일에 동일한 규칙을 적용해야 한다는 뜻은 아닙니다.
기본 구조는 식별·정책·집행·검토로 연결
첫째, 보호할 정보를 식별합니다. 문서 내용의 특정 패턴, 관련 키워드, 민감도 라벨 등을 활용할 수 있습니다. 파일 이름에 ‘기밀’이 있는지만 확인하는 방식은 보호 대상과 무관한 문서를 잡거나 이름이 다른 중요 문서를 놓칠 수 있어 보조 기준으로 다루는 편이 합리적입니다.
둘째, 정책 조건을 정합니다. 정보 유형, 사용자 범위, 수신자나 목적지, 수행 행위를 조합해 허용과 제한의 기준을 만듭니다. Microsoft Purview의 경우 적용 위치에 따라 사용할 수 있는 조건과 조치가 달라지므로, 한 경로에서 만든 정책이 다른 경로에도 그대로 작동한다고 가정해서는 안 됩니다. (Microsoft Learn — Data Loss Prevention policy reference)
셋째, 해당 경로에서 정책을 집행합니다. 넷째, 발생한 이벤트를 담당자가 검토하고 잘못된 분류나 과도한 제한을 조정합니다. 이 네 가지는 이해를 위한 기능 구분이며, 반드시 네 대의 장비나 네 개의 독립 제품이 필요하다는 뜻은 아닙니다.
이메일·PC·클라우드는 적용 지점을 따로 확인
DLP의 범위는 제품 이름만으로 판단하기 어렵습니다. 이메일 연동, 단말 기능, 클라우드 서비스 연동 등 실제 구성에 따라 통제 가능한 행위가 달라집니다. 다음은 도입 범위를 확인하기 위한 판단표입니다.
| 통제 지점 | 확인할 행위 | 도입 전 검증할 사항 |
|---|---|---|
| 이메일 | 외부 수신자에게 본문·첨부파일 전송 | 본문·첨부 검사 범위와 차단 시점 |
| 업무용 PC | 파일 복사·인쇄·웹 업로드 | 지원 OS·앱·브라우저, 단말과 사용자 적용 범위 |
| 클라우드 저장소 | 파일 공유·외부 접근 허용 | 지원 서비스·공유 방식과 정책 반영 시점 |
| 저장된 문서 | 민감정보 포함 파일의 위치 파악 | 검사 가능한 저장소·파일 형식과 후속 조치 |
예를 들어 Microsoft Endpoint DLP는 지원 환경에서 USB 복사, 인쇄, 제한된 서비스 도메인으로의 업로드 등을 감시하거나 제한합니다. 다만 운영체제와 활동별 지원 조건이 있으며, 단말 정책의 사용자와 장치 범위도 확인해야 합니다. 이 기능 목록을 모든 DLP 제품의 공통 사양으로 해석하면 안 됩니다. (Microsoft Learn — Learn about Endpoint data loss prevention)
USB 연결 자체를 금지하는 장치 제어와, 민감정보가 담긴 파일의 USB 복사를 제한하는 내용 기반 통제도 구분해야 합니다. 회사가 필요한 것이 전체 매체 금지인지, 정보 유형별 반출 제한인지에 따라 구성과 검증 항목이 달라집니다.
실제 사례: 같은 고객 명단도 전달 목적에 따라 다르다
다음은 실제 사고나 운영 실적이 아닌 가상 예시입니다. 제조기업의 영업 부서가 거래처 담당자 정보가 포함된 문서를 사용하고, 일부 자료를 승인된 협력사에 전달해야 한다고 가정하겠습니다.
개인 메일 전송은 제한하고, 협력사 전달은 필요한 항목만 남긴 문서를 승인된 경로로 보내도록 설계할 수 있습니다. 이때 DLP가 협력사와의 계약 관계나 업무 필요성을 스스로 확정한다고 가정하면 안 됩니다.
업무 부서가 필요성을 설명하고, 정보 소유 부서가 제공 범위를 판단하며, 보안 담당자가 기술적 통제와 기록을 연결하는 방식이 적절합니다.
예외에는 대상 사용자, 문서 범위, 수신처, 목적, 유효기간, 승인자를 남기는 것을 권합니다. 특정 부서를 통째로 영구 제외하면 그 부서의 다른 문서와 다른 목적지까지 제한이 풀릴 수 있으므로, 실제 업무에 필요한 범위로 좁혀야 합니다.
감사·경고·차단을 구분하고 오탐을 조정
감사는 행위를 기록하는 방식이고, 경고는 사용자가 정책을 이해하고 행동을 바꿀 기회를 주는 방식입니다. 차단은 해당 행위를 제한합니다. 사용자에게 사유를 입력받고 진행을 허용하는 기능이 있더라도, 그것이 관리자 사전 승인을 뜻하는지는 별도로 확인해야 합니다.
Microsoft는 정책을 제한적으로 적용하기 전에 시뮬레이션으로 영향을 평가하도록 안내합니다. 이를 참고한 실무 적용 방식은 보호 대상을 좁혀 시험하고, 정상 업무가 탐지되는 이유를 확인한 뒤, 검증된 규칙부터 제한을 강화하는 것입니다. 다만 이미 확인된 고위험 반출까지 반드시 감사만 해야 한다는 의미는 아닙니다. (Microsoft Learn — Learn about data loss prevention)
오탐과 정책 예외도 구분해야 합니다. 제품 코드가 개인정보 패턴으로 잘못 잡혔다면 식별 규칙을 조정할 문제입니다. 실제 개인정보가 들어 있지만 승인된 업무에 필요한 전송이라면 목적지·항목·기간을 제한한 예외 문제입니다. 두 상황을 모두 광범위한 허용 목록으로 해결하면 통제 범위가 불필요하게 줄어듭니다.
실무자 관점: 차단 건수보다 미적용 경로를 확인
DLP 이벤트가 없다는 사실만으로 반출이 없었다고 판단할 수는 없습니다. 정책 대상에서 빠진 장치, 지원하지 않는 앱, 검사하지 못한 파일이 있을 수 있기 때문입니다. Microsoft 정책 문서도 검사 불가와 검사 미완료 같은 조건을 별도로 다룹니다. 검사할 수 없었던 상태를 민감정보가 없는 상태와 구분해야 합니다. (Microsoft Learn — Data Loss Prevention policy reference)
도입 검증에는 실제 개인정보 대신 합성 시험 자료를 사용하고, 정상 업무 문서도 함께 포함하는 것을 권합니다. 허용돼야 할 행위와 막혀야 할 행위를 각각 실행해 결과·사용자 안내·이벤트 기록을 확인합니다. 정책 설계를 문서화하면 검토와 문제 해결, 후속 조정의 기준을 유지하는 데 도움이 됩니다. (Microsoft Learn — Design a data loss prevention policy)
- 적용 범위: 보호 대상 사용자·단말·서비스 중 빠진 곳이 있는가.
- 식별 결과: 정상 문서가 잘못 잡히거나 시험용 민감 문서가 누락되는가.
- 집행 결과: 감사·경고·차단이 의도한 시점과 경로에서 작동하는가.
- 예외 관리: 승인 범위와 만료일이 있으며 종료 후 제한이 복원되는가.
- 기록 관리: 이벤트 열람 권한과 수집 범위가 업무 목적에 맞게 제한되는가.
휴대전화로 화면을 촬영하는 것처럼 DLP가 관찰하지 못하는 경로도 별도로 평가해야 합니다. 접근권한 최소화, 승인된 전달 수단, 정보 분류와 사용자 교육을 함께 운영하는 이유입니다. DLP를 도입했다는 사실이 이러한 통제를 대신하지는 않습니다.
결론
DLP 도입의 출발점은 ‘무엇을 차단할 것인가’보다 ‘어떤 정보를 어떤 조건에서 전달할 수 있는가’를 정하는 일입니다. 보호 대상과 허용 업무를 먼저 문서화하고, 그 규칙을 집행할 수 있는 경로를 검증해야 합니다.
운영 단계에서는 검사 실패와 미적용 범위를 드러내고, 예외를 좁게 유지하는 것이 통제의 실효성을 높입니다.