02DLP 소개 — 왜 필요한가DLP 소개 — 왜 필요한가
오늘날 데이터는 그 어느 때보다 쉽게 옮겨지고, 그 대부분이 어떤 수준으로든 민감 합니다. 이 장은 DLP가 왜 필요한지, Check Point가 이를 어떻게 푸는지, 그리고 관리자가 무슨 일을 하는지를 잡습니다.
데이터 유출이라는 위험
지식재산처럼 가치가 기밀 유지에 달린 데이터 도 있고, 법·규제 때문에 지켜야 하는 데이터도 있습니다. 유출되면 단순한 망신을 넘어 경쟁력 상실, 고객 이탈, 법적 책임 으로 이어질 수 있습니다. 문제를 키우는 것은 정작 유출 대부분이 악의가 아니라 실수에서 비롯된다는 점입니다 — 클라우드 서버, 공유 문서, 일을 집에 가져가는 직원처럼, 정보 공유를 편하게 만든 도구들이 동시에 돌이킬 수 없는 실수도 쉽게 만듭니다.
그래서 가장 좋은 해법은 보호 대상 데이터가 조직을 떠나기 전에 자동으로 붙잡는 정책 을 두는 것이고, 이것이 바로 Data Loss Prevention(DLP)입니다.
즉 DLP는 출발지·목적지·데이터 객체·프로토콜 을 함께 보고 콘텐츠를 깊이 검사해, 기밀 정보의 무단 전송을 탐지·차단합니다. 이메일 본문과 수신자, 첨부 파일(압축돼 있어도), FTP 업로드, 웹 게시, 웹메일 등이 모두 검사 대상입니다.
Check Point가 DLP를 푸는 방식
Check Point DLP의 강점은 설치 첫날부터 쓸 만한 정책이 준비돼 있고, 거기서부터 다듬어 간다는 데 있습니다. 이를 떠받치는 핵심 기능이 셋입니다. 첫째 UserCheck 는 사용자에게 실시간으로 위반을 알리고 처리를 맡깁니다 . UserCheck가 없으면 관리자가 모든 이메일과 데이터 이동을 일일이 검토·승인해야 하므로 다른 제품들은 탐지에만 머무는데, UserCheck는 결정을 사용자에게 분산 시킵니다. 사용자는 왜 걸렸는지를 보고 보낼 사유를 적어야 하며, 그 결정과 사유가 로그로 남아 실제 사용에 기반한 정책을 만들게 해 줍니다. 둘째 MultiSpect 는 여러 파라미터를 상관 분석 하고 Compound Data Type·CPcode까지 동원해 정확도를 높입니다. 셋째 Out of the Box Security 는 미리 정의된 풍부한 Data Type 으로 곧바로 효과적인 정책을 돌립니다. 여기에 데이터 책임자에게 자동 리포트를 주는 Data Owner Auditing 이 더해집니다.
DLP가 데이터를 잡는 흐름은 이렇습니다 — Security Gateway에 DLP Blade를 켜면 DLP Gateway가 되고, SmartConsole로 정책을 설치합니다. 게이트웨이는 지원 프로토콜로 흐르는 데이터를 모두 가로채 HTTP proxy나 메일 서버로 나가기 전에 검사하며, 필요하면 Active Directory/LDAP로 내부 조직 구성원을 식별합니다. Microsoft Exchange 클라이언트 간 내부 메일까지 검사하려면 Exchange 서버에 Exchange Security Agent 를 설치해 내부 메일을 게이트웨이로 넘깁니다(메일 서버와 Exchange 연동). 어느 규칙에도 안 걸리면 트래픽은 그냥 통과합니다.
두 가지 배치 — Integrated vs Dedicated
DLP Gateway는 두 가지로 둘 수 있습니다. Integrated 는 기존 Security Gateway에 DLP Blade를 함께 켜는 방식으로, Firewall 등 다른 블레이드와 한 장비에서 같이 돕니다. 둘레(perimeter)에 있으면 SMTP 서버가 외부 목적지 전송만 DLP로 넘깁니다. Dedicated 는 보호용 게이트웨이 뒤에 DLP 전용 게이트웨이를 따로 두는 방식입니다.
부서 간 데이터 이동까지 검사하고 싶다면 게이트웨이를 둘레가 아니라 사용자망과 서버 사이에 두는 대안 배치도 있습니다. 예컨대 출발지는 특정 네트워크, 목적지는 그 바깥(Outside Source)으로 둔 규칙은 이 배치에서만 동작합니다.
규칙에 걸리면 무슨 일이 일어나나
게이트웨이가 트래픽을 잡아 정책과 대조해 규칙에 걸리면, 먼저 사건(incident)이 로그로 남고 원본 데이터가 안전한 저장소에 보관 됩니다. 그다음 규칙의 Action이 실행됩니다 — Detect 는 사용자에게 알리지 않고 로그만, Inform User 는 위반을 알리되 통과, Ask User 는 메시지를 붙들고 DLP Portal 링크를 보내 사용자가 보낼지 버릴지 결정하게, Prevent 는 차단 합니다. 필요하면 Data Owner를 비롯한 관계자에게 알림이 갑니다. 동작별 세부는 UserCheck에서 다룹니다.
DLP 관리자의 일
관리자의 작업은 한 번에 끝나는 게 아니라 돌고 도는 다듬기의 순환 입니다. Data Type을 정의하고 → Out of the Box 정책으로 강한 탐지를 첫날부터 켠 뒤 → 사전 정의 Data Type을 우리 조직 데이터에 맞게 손보고 → 필요한 규칙을 켜고 끄고 → 우리만의 Data Type을 만들고 → 사건을 모니터링하며 Data Owner와 소통하고 → 정책을 정밀 조정 합니다. 이 순환이 탐지(Detect)만 하던 정책을 점차 차단(Prevent) 정책으로 옮겨 가게 합니다(규칙 만들기).
관리자 권한은 통째로 줄 수도, 일부만 줄 수도 있습니다. 전체 권한이면 로그의 모든 필드, 잡힌 원본 데이터(실제 이메일·FTP 파일·HTTP 게시), 격리 메일의 전송/폐기 까지 다룰 수 있습니다. 권한은 Manage & Settings > Permissions & Administrators 에서 권한 프로파일로 나누는데, Monitoring and Logging 의 DLP logs including confidential fields (이게 없으면 기밀 필드가 ** Confidential ** 로 가려짐)와 View/Release/Discard DLP messages 옵션으로 세밀하게 조정합니다. 본격적인 설정은 빠른 시작에서 시작합니다.