목차/02. DLP 소개 — 왜 필요한가

02DLP 소개 — 왜 필요한가DLP 소개 — 왜 필요한가

오늘날 데이터는 그 어느 때보다 쉽게 만들어지고, 쉽게 옮겨지며, 그 대부분이 어떤 수준으로든 민감 합니다. 이 장은 데이터 유출이 왜 위험한지, 그것을 막는 Data Loss Prevention(DLP) 이란 무엇인지, 사용자 프라이버시는 어떻게 다뤄야 하는지, Check Point는 이 어려운 문제를 어떤 기능으로 푸는지, 그리고 DLP 관리자가 실제로 무슨 일을 하는지 를 빠짐없이 풀어 둡니다. 본격적인 설정은 빠른 시작에서 시작하지만, 그 전에 이 그림을 먼저 잡아 두는 것이 좋습니다.

DLP가 필요한 이유

데이터가 민감한 이유는 한 가지가 아닙니다. 어떤 데이터는 그저 조직 내부의 것이고 외부에 공개할 의도가 없었기 때문에 기밀이고, 어떤 데이터는 회사 규정·국가 법률·국제 규제 때문에 지켜야 합니다. 특히 지식재산(intellectual property)이나 경쟁과 관련된 정보처럼, 그 가치가 "계속 비밀로 유지된다"는 사실 자체에 달린 데이터도 있습니다.

이런 데이터가 새어 나가면 단순한 망신으로 끝나지 않습니다. 산업적 우위(industrial edge)를 잃거나 거래처(accounts)를 잃을 수 있고, 조직이 프라이버시 관련 법규를 어기는 식으로 비준수(non-compliance) 상태가 되면 망신을 넘어 조직의 무결성(integrity) 자체가 위태로워질 수 있습니다.

문제를 더 복잡하게 만드는 것은, 정보 공유를 편하게 만든 도구들이 동시에 돌이킬 수 없는 실수도 쉽게 만든다 는 점입니다. 클라우드 서버, Google Docs 같은 협업 도구, 그리고 일을 집에 가져가는 직원처럼 회사 절차를 무심코 어기는 일들이 대표적입니다. 그리고 핵심은 이것입니다 — 데이터 유출의 대부분은 악의가 아니라 의도치 않은(unintentional) 실수에서 비롯됩니다.

그래서 가장 좋은 해법은 보호 대상 데이터가 조직을 떠나기 전에 자동으로 붙잡는 회사 정책(automated corporate policy) 을 두는 것이고, 이런 솔루션을 Data Loss Prevention(DLP) 이라고 부릅니다.

풀어 쓰면, DLP는 출발지(source)·목적지(destination)·데이터 객체(data object)·프로토콜(protocol) 같은 전송 파라미터를 분석하고 콘텐츠를 깊이 검사(deep content inspection)하면서, 중앙 관리 틀(centralized management framework) 아래에서 데이터의 이동을 식별·모니터링·보호합니다. 한마디로 기밀 정보의 무단 전송(unauthorized transmission)을 탐지하고 차단 합니다.

DLP와 프라이버시

DLP는 규칙에 걸린 전송의 원본 데이터(original data)를 그대로 보관 합니다. 여기에는 전송 본문(body)과 첨부 파일(attached files) 이 모두 포함됩니다. 즉 보안 담당자가 실제로 무엇이 새어 나가려 했는지 들여다볼 수 있다는 뜻인데, 이는 강력한 만큼 사용자 프라이버시와 직결 되므로 운영 전에 반드시 짚고 넘어가야 합니다.

정보 공개(information disclosure)와 관련해 권장되는 사항은 다음과 같습니다.

  1. DLP를 구성하기 전에(BEFORE) 프라이버시 정책을 먼저 공개합니다.
  2. 가장 중요한 DLP 규칙들을 지침(guidelines)으로 번역 해, 무엇이 허용되지 않으며 어떤 전송이 캡처되는지를 사용자에게 알립니다.
  3. DLP는 조직 내부의 컴퓨터에서 시작된 전송만 검사 한다는 점을 설명합니다. 여기에는 Remote Access나 VPN 연결처럼 조직 자원을 사용하는 모든 출발지 가 포함됩니다.
  4. Ask User 위반을 어떻게 처리하는지 사용자에게 설명합니다.

DLP 사건 알림(incident notification)은 SMTP 트래픽이면 이메일로 보낼 수 있고, SMTP·HTTP·FTP 등에서는 UserCheck Client의 시스템 트레이 팝업 으로 보여 줄 수 있습니다. 사건이 Ask User 모드라면 사용자는 UserCheck Client 팝업에서 Send 또는 Discard 링크를 눌러 실시간으로 사건을 처리합니다.

이어서 사용자에게 알려 두어야 할 점이 더 있습니다.

  1. 캡처된 전송은 로그로 남고 저장되며, 일부는 관리자(Data Owner)에게 보고될 수 있다는 점을 설명합니다.
  2. 캡처된 이메일·첨부·웹 게시물 등은 보안 담당자가 검토용으로 열람할 수 있다는 점을 설명합니다.
  3. 원본 전송의 검토는 오직 조직의 데이터 보안만을 위한 것 이며 개인 정보를 수집하지 않는다는 점을 설명합니다. 따라서 사용자에게는 자기 전송의 검사를 막거나 비활성화할 선택권이 없습니다 .
  4. 지침을 반드시 유지하세요 — 원본 전송을 DLP 사건·규칙 검토 이외의 어떤 용도로도 보관하거나 사용하지 않습니다 .

Check Point DLP 솔루션

Check Point Data Loss Prevention Software Blade 의 강점은, 전문가 휴리스틱(expert heuristics)에 기반한 설치 첫날부터 현실적으로 쓸 만한 out-of-the-box 탐지 능력 을 빠르게 구성할 수 있다는 데 있습니다. 하지만 최적의 DLP는 시간이 필요 합니다. 무엇을 막을지 정하려면 전송마다 맥락이 다른 여러 변수를 따져야 하기 때문입니다.

  • 어떤 종류의 데이터(type) 인가?
  • 누가 소유(owns) 하는가?
  • 누가 보내는가?
  • 의도된 수신자(receiver) 는 누구인가?
  • 언제 보내지는가?
  • 정책이 필요 이상으로 엄격해서 업무가 중단되면 그 비용(cost) 은 얼마인가?

DLP 핵심 기능

Check Point는 이 복잡함을 고유한 기능들로 풉니다.

기능하는 일
UserCheck™자동 사용자 알림과 고유한 Ask User 모드로 사건을 빠르게 처리합니다. 사용자는 필요할 때마다 모범 사례를 익혀, DLP 사건의 대다수인 의도치 않은 유출을 앞으로 예방 하고 당면한 사건은 즉시 처리합니다. 처리는 DLP Self Incident Handling Portal 또는 UserCheck Client 를 통해 합니다.
MultiSpect™Compound Data Type 과 CPcode 로 커스터마이즈한 Data Type을 동원해 여러 파라미터를 상관 분석(multi-parameter correlation)하며, 타의 추종을 불허하는 정확도 로 사건을 식별·차단합니다.
Out of the Box Security보호해야 할 민감한 양식·템플릿·데이터를 알아보는 풍부한 사전 정의 Data Type 집합 입니다. 이 Data Type들이 효과적인 out-of-the-box 정책에 곧바로 적용됩니다.
Data Owner AuditingData Owner 는 회사에서 자기 영역의 정보·파일을 통제할 책임을 진 사람입니다. 자동 알림·리포트를 통해 자기 데이터가 어떻게 이동하는지를 적시에·관련성 있게 받아 봅니다.
CPcode완전히 맞춤화한 데이터 식별 을 지원합니다. DLP가 데이터를 어떻게 매칭할지를 직접 지정해, 가능한 최대의 유연성을 얻습니다(R77 버전의 CPcode DLP Reference Guide 참고).

UserCheck 의 의미를 좀 더 풀어 두는 것이 좋습니다. UserCheck가 없다면 보안 관리자(또는 보안 팀)가 모든 이메일과 데이터 이동을 실시간으로 일일이 검토하고 승인·거부 해야 합니다. 그래서 다른 제품들은 보통 의심스러운 사건의 "탐지(detection)"까지만 제공합니다. 반면 UserCheck는 의사 결정을 사용자에게 분산 시킵니다. 사용자는 데이터가 왜 캡처됐는지 이유를 보고, (알림을 보고도 마음이 바뀌지 않았다면) 그대로 보낼 사유를 직접 적어야 합니다. 사용자의 결정(send/discard)과 보낼 사유가 모두 로그로 남으므로 , 원본 메시지와 함께 이 기록을 활용하면 실제 사용에 기반한 효과적인 차단 정책 을 만들 수 있습니다.

Data Owner Auditing 도 마찬가지로 운영의 균형을 잡아 줍니다. Data Owner의 통제가 없으면 보안 관리자가 관리자와 직원 사이에 끼인 곤란한 위치 에 놓이기 쉬운데, Check Point DLP는 Data Owner가 자기 책임 영역과 직접 관련된 사용 문제를 다룰 수 있도록 필요한 정보를 줍니다.

DLP가 주는 이점

Check Point DLP는 시간을 아끼고 ROI를 크게 높입니다 . 길고 비싼 분석이나 사건 처리 전담 팀이 필요 없도록 자동화를 제공하기 때문에, 외부 컨설턴트나 보안 팀을 새로 들이지 않고도 탐지 전용 정책에서 정확하고 효과적인 차단 정책으로 옮겨 갈 수 있습니다.

이 모든 기능은 다른 Software Blade와 비슷한 인터페이스로 SmartConsole 에서 쉽게 관리합니다. 구성 첫날부터 DLP 전문가일 필요는 없습니다 . Check Point DLP는 예컨대 Improve Accuracy 플래그로 정책을 어떻게 다듬고 개선할지 안내해 줍니다. DLP Software Blade에는 기본 정책으로 곧바로 적용할 수 있는 다수의 내장 Data Type 이 들어 있어, out-of-the-box 정책을 미세 조정해 조직의 기밀성·무결성 지침을 자동 규칙으로 손쉽게 옮길 수 있고, 나중에는 직접 Data Type을 만들 수도 있습니다. 정책을 갱신하며 탐지 정책에서 차단 정책으로 옮겨 가는 이 순환은 Check Point Logs & Events 도구와 맞물려 돌아갑니다.

DLP가 동작하는 방식

DLP가 데이터를 잡는 흐름을 따라가 봅니다. 먼저 등장인물(구성 요소)은 다음과 같습니다.

번호구성 요소
1내부 네트워크(Internal network)
2DLP Software Blade를 켠 Security Gateway
3Security Management Server
4HTTP proxy
5메일 서버(Mail server)
6Active Directory 또는 LDAP 서버
7Logs & Events view

DLP 워크플로는 이렇게 흐릅니다.

  1. Security Gateway(또는 ClusterXL Security Cluster)에 DLP Software Blade 를 켜면 그 장비가 DLP Gateway(또는 DLP security cluster)가 됩니다. 또는 보호용 Security Gateway 뒤에 전용(dedicated) DLP Gateway를 따로 설치 할 수도 있습니다.
  2. SmartConsole 과 Security Management Server 로 DLP Policy를 DLP Gateway에 설치 합니다.
  3. DLP Gateway는 내장 Data Type·규칙으로 out-of-the-box DLP를 제공하고, 필요하면 Active Directory/LDAP 서버로 내부 조직을 식별 합니다. 게이트웨이는 지원 프로토콜로 흐르며 데이터를 담은 트래픽을 모두 가로채 , 사용자가 HTTP proxy나 메일 서버로 데이터를 보낼 때 조직 밖으로 나가기 전에 붙잡습니다. 그리고 이메일 첨부까지 포함해 트래픽을 검사하며, 프로토콜·출발지·목적지·복합 Data Type 표현 으로 내보내면 안 되는 데이터를 알아봅니다. 또한 조직 내 Microsoft Exchange 클라이언트 사이의 내부 트래픽 도 검사할 수 있습니다. 이를 위해서는 Microsoft Exchange 서버에 Exchange Security Agent 를 설치 해야 하며, 이 에이전트가 내부 이메일을 DLP Gateway로 넘겨 검사받게 합니다. 만약 조직이 내·외부 메일 관리를 모두 Exchange 서버로만 한다면, 이 구성으로 조직 밖으로 나가는 이메일까지 검사할 수 있습니다. 어느 규칙에도 안 걸리면 트래픽은 그냥 통과합니다.
  4. Logs & Events view 로 DLP Gateway가 캡처한 사건을 효과적으로 로그·추적·분석하고 리포트 합니다.

Integrated DLP Security Gateway 구성

Integrated 구성에서는 기존 Security Gateway(또는 클러스터)에 DLP Software Blade를 함께 켜 그 장비가 DLP Gateway(또는 DLP Security Cluster)가 됩니다. 이 게이트웨이에는 Firewall Software Blade 가, 선택적으로 다른 Network Security Software Blade들도 함께 켜져 있습니다.

DLP Gateway가 둘레(perimeter) 에 있으면 SMTP 서버는 목적지가 조직 밖인 전송만 DLP로 넘깁니다. 내부·외부 전송을 모두 검사하고 싶다면 Exchange 서버의 Exchange Security Agent가 그 전송을 DLP로 넘겨 야 합니다. 이때 외부 전송을 Exchange Security Agent로 처리하려면, Exchange 서버가 DLP Gateway에서 접근 가능한 IP 주소 를 가져야 합니다.

Dedicated DLP Gateway 구성

Dedicated 구성에서는 보호용 Security Gateway(3, 또는 클러스터)에 더해 별도의 Security Gateway(2)를 따로 설치 하고, 그 별도 게이트웨이에만 DLP Software Blade를 켭니다. 전용 DLP Gateway는 보호용 Security Gateway 뒤에 두어 자기 자신도 보호 받게 합니다. 하드웨어 자원을 최대한 활용하려면 DLP Software Blade만 켜는 것 을 권장합니다.

① 내부 네트워크 ② DLP Blade를 켠 Security Gateway ③ Security Gateway ④ Security Management Server ⑤ HTTP proxy ⑥ 메일 서버 — Dedicated DLP Gateway 배치
① 내부 네트워크 ② DLP Blade를 켠 Security Gateway ③ Security Gateway ④ Security Management Server ⑤ HTTP proxy ⑥ 메일 서버 — Dedicated DLP Gateway 배치

대안(Alternative) 게이트웨이 구성

DLP Gateway를 네트워크 둘레에 두는 대신, 사용자망(user networks)과 서버 사이에 두어 트래픽이 서버로 가기 전에 검사하게 할 수도 있습니다. 이 배치는 부서 간(between departments) 데이터 전송을 검사하는 DLP 규칙 을 쓰려면 반드시 필요합니다. 예를 들어 출발지(Source)는 특정 네트워크, 목적지(Destination)는 그 출발지 바깥 전체(Outside Source) 로 둔 규칙은 오직 이 구성에서만 동작합니다. 또한 DLP Gateway를 사용자와 스위치 사이 에 두어 특정 서브넷을 직접 보호할 수도 있습니다.

① 내부 네트워크 ② DLP Blade를 켠 Security Gateway ③ HTTP proxy ④ 메일 서버 ⑤ Active Directory 또는 LDAP 서버 — 대안 배치
① 내부 네트워크 ② DLP Blade를 켠 Security Gateway ③ HTTP proxy ④ 메일 서버 ⑤ Active Directory 또는 LDAP 서버 — 대안 배치

규칙에 걸리면 무슨 일이 일어나나

DLP Gateway는 트래픽을 캡처해 DLP 정책과 대조합니다. 트래픽 안의 데이터가 정책의 규칙에 걸리면 다음 순서로 처리됩니다.

  1. 사건이 로그로 남습니다.
    • 원본 데이터가 DLP 로그를 저장하는 로그 서버 또는 Security Management Server의 안전한 저장소(safe repository) 에 보관됩니다.
    • DLP Gateway가 Logs & Events view 에 사건을 기록합니다.
  2. 규칙의 Action이 실행됩니다. 동작은 네 가지입니다.
Action동작
Detect사용자에게 알리지 않습니다 . DLP 로그 사건이 만들어지고, 실제 데이터가 저장됩니다.
Inform User캡처된 트래픽이 DLP 규칙을 위반했음을 사용자에게 알립니다. 트래픽은 통과 합니다.
Ask User메시지를 붙들어 둔 채(held) , DLP Portal 링크를 보내 사용자가 전송 여부(통과/폐기)를 결정 하게 합니다. 사용자의 결정과 보낼 사유가 분석용으로 로그에 남습니다.
Prevent트래픽을 차단 합니다. 사용자와 Data Owner에게 알릴 수 있습니다.
  1. 선택적으로, Data Owner를 비롯해 알림 대상으로 구성된 사용자들 이 그 사건에 대한 알림을 받습니다.

동작별 세부 흐름은 UserCheck에서 더 다룹니다.

규칙 매칭 시 처리 흐름
규칙 매칭 시 처리 흐름

DLP 관리자의 역할

DLP는 풍부한 감사(auditing) 도구를 제공합니다.

  • 보호 대상 데이터의 전송이 시도되면 Data Owner에게 자동 알림 을 보냅니다.
  • 사용자 알림과 자가 처리 포털(self-handling portal) 을 제공합니다.
  • Logs & Events view 에서 사건 상세·차트·그래프·필터 목록·리포트 를 추적·로그할 수 있습니다.

감사를 시작하기 전에 먼저 DLP 정책을 구성해야 합니다. 관리자의 작업은 한 번에 끝나는 게 아니라 돌고 도는 다듬기의 순환 입니다.

  1. Data Type을 정의 합니다.
  2. 기본 정책으로 out-of-the-box DLP를 구성 합니다. 이 정책은 첫날(Day-1)부터 강력한 탐지 능력 을 제공합니다.
  3. 사전 정의 Data Type을 우리 조직에 맞게 손봐 정책 정확도를 높입니다. 일부 제공 Data Type은 고유 정보(사전, dictionary)의 자리표시자(placeholder) 이며 관심을 두라고 플래그가 달려 있습니다. 우리 조직 데이터를 정책에 통합해 우리 환경에 더 정확하게 만듭니다.
  4. Data Type을 선택 합니다. 제공되는 폭넓은 Data Type에 익숙해진 뒤, 우리에게 맞는 규칙을 켜고 끕 니다.
  5. 쉬운 마법사(wizard)로 우리만의 Data Type을 만듭 니다. 조직의 기밀성 지침을 강제하고, Data Owner에게 속한 정보가 그들의 통제 안에 머물도록 하며, DLP 규칙에서 우리 Data Type을 써서 데이터 보호를 강제합니다.
  6. 사건을 모니터링하고 Data Owner와 소통 합니다. DLP Gateway가 시도된 전송을 잡아 사건을 로그하면 Logs & Events Logs view에서 볼 수 있습니다. 관리자와 Data Owner가 어떤 사건을 Data Owner에게 알릴지 정하고, 사건을 모니터링하며 DLP 정책을 미세 조정할 지침 을 만듭니다.
  7. 정책을 정밀 조정(Refine) 합니다.
  8. 정책을 시간에 걸쳐 유지 합니다. Data Owner 리포트를 생성하고 사용자 행동을 감사하며, Logs & Events Logs view의 로그를 살펴 정책이 매끄럽게 돌아가 보호 대상 데이터의 전송을 막는지 확인합니다.

이 순환이 탐지(Detect)만 하던 정책을 점차 차단(Prevent) 정책으로 옮겨 가게 합니다(규칙 만들기).

관리자 계정의 DLP 권한

DLP 관리자에게는 전체(full) 권한 을 줄 수도, 일부(subset) 권한 만 줄 수도 있습니다. 전체 권한이면 관리자는 다음을 할 수 있습니다.

  • Logs & Events Logs view에서 로그의 모든 필드 를 봅니다.
  • 캡처된 데이터(실제 이메일·FTP 파일·HTTP 게시물) 를 봅니다.
  • 격리된(quarantined) 사용자 이메일을 보내거나(send) 폐기(discard) 합니다.

전체 권한 대신 일부만 주면, 예컨대 로그의 필드는 보되 캡처된 데이터는 못 보고, 격리 이메일을 보내거나 폐기하지도 못하게 하는 식으로 유연하게 나눌 수 있습니다.

전체 DLP 권한 구성하기

  1. SmartConsole에서 Manage & Settings > Permissions & Administrators 를 엽니다.
  2. 관리자 계정을 더블클릭하거나 New 로 새 관리자 사용자 계정을 만듭니다. Administrator Properties 창이 열리고 General 페이지가 보입니다.
  3. Permission Profile 의 드롭다운에서 New 를 클릭합니다. Permissions Profile Properties 창이 열립니다.
  4. Enter Object Name 에 DLP 관리자 프로파일 이름을 입력합니다.
  5. Read/Write All 이 선택돼 있는지 확인합니다.
  6. 탐색 트리에서 Monitoring and Logging 을 클릭합니다.
  7. 다음 옵션을 선택합니다.
    • DLP logs including confidential fields
    • View/Release/Discard DLP messages
  8. OK 를 클릭합니다.
  9. 관리자 창을 닫습니다.
  10. SmartConsole 세션을 Publish 합니다.

일부 DLP 권한 구성하기

  1. SmartConsole에서 Manage & Settings > Permissions & Administrators 를 엽니다.
  2. 관리자 계정을 더블클릭하거나 New 로 새 계정을 만듭니다. Administrator Properties 창이 열립니다.
  3. Permission Profile 의 드롭다운에서 New 를 클릭합니다.
  4. Enter Object Name 에 프로파일 이름을 입력합니다.
  5. Customized 를 선택하고 Edit 를 클릭합니다.
  6. 탐색 트리에서 Access Control 을 클릭합니다.
  7. Additional Policies 영역에서 Data Loss Prevention 의 Read 또는 Write 권한을 구성합니다.
  8. 탐색 트리에서 Monitoring and Logging 을 클릭합니다.
  9. 다음 중 하나 이상을 선택합니다.
    • DLP Logs including confidential fields — Logs & Events Logs view에서 DLP 로그의 모든 필드를 볼 권한입니다. 이 체크박스를 비우면 관리자는 기밀로 정의된 필드의 실제 내용 대신 * Confidential * 텍스트만 보게 됩니다.
    • View/Release/Discard DLP messages — Logs & Events Logs view 안에서 이메일과 관련 사건을 볼 권한이며, 이 권한이 있으면 격리된 이메일을 그 안에서 release(send)하거나 discard 할 수도 있습니다.
  10. OK 를 클릭합니다.
  11. 관리자 창을 닫습니다.
  12. SmartConsole 세션을 Publish 합니다.

본격적인 설정은 빠른 시작에서 시작합니다.