08Out of the Box — My Organization과 정책Out of the Box — My Organization과 정책

DLP 환경의 첫 단계는 기본 제공(Out of the Box) Data Loss Prevention 정책 을 그대로 쓰는 것입니다. 설치하자마자 의미 있는 검사가 돌기 시작하지만, 사용자를 방해하지 않으면서 우리 조직의 실제 필요를 파악하는 데 초점을 둡니다. 이 단계의 성격은 세 가지로 요약됩니다.

DLP의 상세 설정은 SmartConsole이 아니라 별도의 SmartDashboard 화면에 모여 있습니다. 여는 방법은 다음과 같습니다.

DLP 탭의 주요 페이지

DLP 탭에는 다음 페이지들이 있습니다. 각 페이지가 무엇을 다루는지 알아 두면 설정 위치를 헤매지 않습니다.

Additional Settings 안의 페이지

DLP 탭의 Additional Settings 를 펼치면 다음 보조 설정이 나옵니다.

Advanced 페이지에서는 다음과 같은 세부 동작을 다룹니다.

HTTPS Inspection (별도 탭)

마지막으로 HTTPS Inspection 은 별도 탭에 있으며, 기업 네트워크에서 외부 목적지로 나가는 HTTPS / SSL 트래픽 의 검사를 설정합니다(HTTPS 검사).

DLP의 모든 판단은 무엇이 내부이고 무엇이 외부인지 에서 출발합니다. My Organization 페이지가 바로 그 경계를 정합니다. 이 페이지는 DLP가 데이터 유출이 문제되지 않는 내부 네트워크의 데이터 이동 으로 인식하는 것과, 전송을 감시해야 하는 외부 를 보여 줍니다.

기본적으로 My Organization은 DLP Gateway의 내부 인터페이스 뒤에 있는 모든 호스트와 네트워크 를 포함합니다. 또한 Security Management Server에 정의된 특정 사용자, 사용자 그룹, 그리고 LDAP 그룹의 모든 사용자 도 포함합니다.

기본적인 추가 절차는 다음과 같습니다.

이메일 주소와 도메인 추가하기

My Organization에 포함될 DLP 내부 도메인과 특정 이메일 주소 를 지정합니다. 원격 사무실·지사를 My Organization의 일부로 넣으려면 그 도메인을 추가하면 됩니다. 또한 일반적인 데이터 공유에 안전한 이메일 주소를 추가할 수 있습니다.

직원이나 관리자의 개인 이메일 주소는 추가하지 마세요 . 기밀 데이터를 집으로 가져가는 것은 나쁜 관행이므로 권장하지 말고 결국에는 차단해야 합니다.

도메인·주소를 추가할 때 알아 둘 점이 있습니다.

도메인과 이메일 주소를 추가하는 전체 절차는 다음과 같습니다.

사용자 관리

대부분의 조직은 사용자·사용자 그룹을 외부 LDAP 서버(예: Active Directory)로 관리합니다. 하지만 LDAP를 쓰지 않거나 LDAP에 없는 사용자를 다뤄야 할 때를 위해 DLP는 내부에서 직접 사용자를 정의하는 길을 열어 둡니다.

내부 사용자 정의하기

다음과 같은 경우에는 규칙 베이스의 출발지(Source)나 목적지(Destination)로 쓸 내부 사용자 계정 을 직접 정의합니다.

개별 사용자 계정은 SmartConsole의 Data Loss Prevention 탭에서 추가합니다.

이렇게 추가한 사용자는 SmartConsole이 관리하는 다른 소프트웨어 블레이드에도 함께 추가됩니다.

내부 사용자 그룹 정의하기

DLP는 LDAP 서버의 그룹과는 다른 사용자 그룹이 필요할 때가 있습니다. 예를 들어 신규 입사자 는 조직 지침에 익숙해질 시간을 주려고 규칙을 Prevent 대신 Ask User 로 두는 그룹으로 묶을 수 있고, 임시 직원이나 퇴사 예정자 는 더 엄격한 규칙을 적용하는 그룹으로 묶을 수 있습니다.

My Organization에서 사용자 제외하기

Users 영역의 기본 옵션(Users, user groups and LDAP groups defined in the Security Management Server)이 선택돼 있으면, 이 정의에 예외(exclusion) 를 둘 수 있습니다. 예를 들어 CEO를 제외 하면 CEO는 검사 없이 어떤 데이터든 보낼 수 있습니다.

네트워크 관리

기본적으로 My Organization은 DLP Gateway의 내부 인터페이스 뒤에 있는 것으로 정의된 네트워크, 네트워크 그룹, 호스트를 포함합니다. 규모가 큰 사이트에서는 내부 환경을 하나하나 정의하기보다 내부 인터페이스에 대한 예외를 정의하는 편 이 더 효율적일 때가 많습니다.

내부 네트워크 지정하기

특정 네트워크나 호스트에 이름을 지정해 My Organization을 정의하면, 이름을 지정하지 않은 내부 네트워크·호스트도 DLP가 내부로 간주 합니다.

My Organization에서 네트워크 제외하기

My Organization에서 기본 옵션(Anything behind the internal interfaces of my Security Gateways)이 선택돼 있으면, 내부 네트워크에 대한 예외를 정의할 수 있습니다. DLP는 예외로 지정한 네트워크·네트워크 그룹·호스트를 모두 Outside My Org(외부) 로 인식합니다. 따라서 이렇게 제외한 네트워크에서 보내는 데이터를 검사하려면, 규칙의 기본 출발지(Source)를 My Org에서 해당 네트워크 객체로 바꿔야 합니다.

VPN 관리

My Organization의 VPN에서 Remote Access 커뮤니티 는 Office Mode에서만 지원 됩니다. 내부 VPN을 정의해 My Organization에 포함하거나 제외할 수 있습니다.

Remote Access 커뮤니티 지원을 위한 Office Mode 설정

VPN 트래픽을 My Organization에 포함하기

DLP가 인식하는 VPN 확인하기

My Organization에서 VPN 제외하기

DLP 정책은 전송되지 않도록 보호할 데이터 를 정의합니다. 보호 대상에는 이메일 본문, 이메일 수신자, (압축돼 있더라도) 이메일 첨부, FTP 업로드, 웹 게시(web post), 웹 메일 등이 들어갑니다. 정책은 전송이 잡혔을 때 DLP가 취할 동작 까지 결정합니다. 규칙은 Data Loss Prevention > Policy 페이지에서 관리합니다.

지원하는 아카이브 형식

DLP 블레이드는 다음 압축 아카이브를 풀어서 안의 내용까지 검사합니다.

DLP 규칙의 구성 요소

하나의 Data Loss Prevention 규칙은 다음 요소들로 이루어집니다.

DLP 규칙 베이스는 Check Point 방화벽 규칙 베이스를 다뤄 본 사람에게 익숙해 보이겠지만, 다음과 같은 차이가 있습니다.

DLP와 Identity Awareness

Identity Awareness 가 켜져 있으면 Access Role 객체 를 만들어 DLP 정책에 쓸 수 있습니다. Identity Awareness가 켜지면 DLP에서 다음이 가능합니다.

FTP·HTTP 위반에 대한 이메일 알림

SMTP 위반 알림과 더불어 FTP·HTTP 위반에 대한 알림도 보낼 수 있습니다.

Email Notifications 영역에서 Web이나 FTP를 선택하면 Learn User Actions 영역에서도 Web·FTP 옵션이 함께 선택됩니다. 그러면 DLP가 사용자의 인시던트 처리 결정을 학습해 같은 스레드의 이후 메시지에 같은 결정을 적용합니다(학습 모드).

규칙 Source·Destination의 Access Role

Access Role 객체는 규칙의 Source나 Destination 열에 쓸 수 있으며, 이것이 있으면 DLP가 사용자 인식(user aware) 상태가 됩니다. Access Role 객체는 사용자, 컴퓨터, 네트워크 위치를 하나의 객체 로 식별합니다. 지정한 사용자, 사용자 그룹, 또는 사용자 브랜치(branch)를 객체로 고를 수 있습니다.

인증 Captive Portal로 리디렉션

Captive Portal 리디렉션은 HTTP·HTTPS 프로토콜에만 적용됩니다. 리디렉션은 보낸 사람이 미확인 상태(IP 주소가 AD의 어떤 사용자에도 매핑되지 않음)이고 DLP 규칙의 Action이 Identity Captive Portal 이며, 다음 조건 중 하나가 함께 충족될 때 일어납니다.

Captive Gaia Portal로 리디렉션하면 DLP는 미확인 사용자를 식별해 그들의 FTP·HTTP 활동을 기록 할 수 있고(그 뒤 식별된 사용자를 정책의 Access Role과 맞출 수 있습니다), FTP·HTTP 위반에 대한 알림 이메일도 보낼 수 있습니다.

HTTP 트래픽을 Captive Gaia Portal로 리디렉션하려면 다음과 같이 합니다.

프록시 뒤의 사용자 식별

조직이 Security Gateway 뒤에 HTTP 프록시 서버를 쓰는 경우, 다음을 설정하면 프록시 뒤 사용자의 신원이 드러납니다.

또한 나가는 트래픽에서 이 헤더를 제거하도록 설정할 수도 있습니다. 헤더가 없으면 인터넷 요청에 내부 IP 주소가 드러나지 않습니다.

Identity Awareness를 활용한 DLP 규칙 예시

다음 세 규칙은 Identity Awareness가 DLP와 어떻게 동작하는지를 보여 줍니다.

규칙 1

규칙 2

규칙 3

DLP 규칙 매칭

규칙 매칭 순서

DLP 규칙의 순서는 의미가 없습니다 . 이 규칙 베이스에서는 각 전송이 모든 규칙에 대해 하나씩 검사됩니다. 순서가 의미 없으므로 보기 편하게 표시를 바꿔도 됩니다.

예외가 있을 때의 매칭

데이터가 규칙에 매칭되고 그 규칙에 예외가 있으면, 규칙의 예외를 검사합니다. 데이터가 어떤 예외와 일치하면 DLP는 전송을 허용 합니다.

예를 들어 본문에 직원 이름이 15명 넘게 들어간 이메일을 잡는 규칙이 있다고 합시다. HR 부서 사용자가 직원 20명 목록을 외부 주소(예: 협력사)로 보내면, 같은 규칙에 HR 그룹이 직원 이름 목록을 밖으로 보내도록 허용하는 예외가 있기 때문에 그 이메일은 인시던트 기록이나 DLP 동작 없이 허용됩니다.

데이터가 여러 규칙에 매칭되는데 하나는 예외가 있고 하나는 없으면, 예외가 없는 규칙이 적용 됩니다.

여러 규칙에 매칭될 때

데이터가 여러 규칙에 매칭되면 가장 제한적인(most restrictive) 규칙 이 적용됩니다.

예를 들어 사용자가 암호화되지 않은 PDF를 첨부한 이메일을 보내면 두 규칙에 매칭될 수 있습니다. 하나는 Detect 규칙(외부 목적지로 가는, PDF가 든 이메일을 탐지)이고, 다른 하나는 Ask User 규칙(암호화되지 않은 PDF가 든 이메일을 사용자가 보내도 좋다고 할 때까지 지연하고, 더해서 마케팅·기술 커뮤니케이션 관리자에게 PDF가 외부로 나갔음을 통보)입니다. 이 경우 다음이 일어납니다.

DLP 규칙 동작(Action)

Data Type별로 만드는 각 DLP 규칙에는, 규칙이 전송에 매칭됐을 때 취할 동작을 정의합니다.

Detect 규칙 관리

Detect 동작은 동작 옵션 중 가장 덜 방해적 이라 기본값으로 설정됩니다. DLP가 보호 대상 데이터가 든 전송을 발견하면 Logs & Events > Logs 뷰에 인시던트가 기록되고, 설정된 다른 로깅 동작이 있으면 함께 수행됩니다.

처음에는 모든 규칙을 Detect로 두는 것이 좋습니다. 그런 다음 로그를 검토해 조직의 행동에 따라 어떤 규칙이 필요한지 정하면, 여러분과 사용자 모두의 시간을 아끼고 안내도 각자의 필요에 더 맞게 할 수 있습니다.

DLP 규칙 추적 설정

Data Loss Prevention 규칙을 만들 때 가장 먼저 고려할 것이 인시던트를 어떻게 감사할지 입니다. 규칙 베이스의 Track 열에는 다음 옵션이 있습니다.

Store Incident — 데이터를 어떻게 저장할까

Store Incident 옵션은 DLP 규칙에 매칭된 데이터를 어떻게 저장할지(또는 저장하지 않을지) 정합니다.

Store Incident 충돌 해결

검사된 메시지가 여러 DLP 규칙에 매칭되고 규칙마다 store 옵션이 다르면, 우선순위가 가장 높은 옵션 이 우선합니다. 예를 들어 한 이메일이 다음 규칙에 매칭됐다고 합시다.

이 경우 Rule_2 의 store 옵션(Yes)이 우선순위가 가장 높습니다. 따라서 이메일이 데이터를 삭제하도록 설정된 규칙(Rule_3)에 매칭됐더라도 DLP Gateway는 데이터를 저장 합니다.

우선순위 바꾸기

Only as Text store 옵션이 Yes 보다 높은 우선순위를 갖도록 설정할 수 있습니다.

각 메시지 프로토콜은 자기 섹션을 갖습니다. 예를 들어 FTP 섹션은 다음과 같습니다.

   :ftp (
       :enabled (1)
       :maximum_words_to_log (14)
       :maximum_chars_to_words_in_log (490)
       :cleanup_session_files (1)
       :save_incident_quota_percentage (85)
       :allow_append_cmd (0)
       :view_incident_dispute_option (yes)
   )
   

시간 제한 설정

DLP 규칙 표의 Time 열에는 시간 객체(time object) 또는 시간 객체 그룹 이 들어갑니다. 이 시간 객체는 방화벽 규칙 베이스에서 쓰는 것과 같은 객체입니다.

시간 객체 만들기

시간 그룹 객체 만들기

시간 객체가 둘 이상이면 그룹으로 묶을 수 있습니다. 그룹 안의 한 시간 객체의 조건만 충족돼도 DLP 규칙이 적용 됩니다.

DLP 선택적 구성

DLP 규칙은 특정 Enforcing Gateway 에서, 그리고 다양한 데이터 전송 프로토콜 별로 구성할 수 있습니다.

특정 게이트웨이에 규칙 적용

정책의 어떤 규칙이든 특정 Enforcing Gateway에만 구성할 수 있습니다.

프로토콜

Check Point Data Loss Prevention은 다양한 데이터 전송 프로토콜을 지원합니다. 필요에 따라 단계적으로 켜는 것 이 권장됩니다.

또한 Exchange Security Agent 이메일과 HTTPS 프로토콜에 대한 검사도 켤 수 있습니다(메일과 Exchange).

모든 Security Gateway에 대해 프로토콜을 고르는 절차는 다음과 같습니다.

Security Gateway별로 프로토콜을 고르는 절차는 다음과 같습니다.

Data Loss Prevention 과정에서 인시던트 분석은 필수 입니다. 시작하기 전에 정책 규칙의 심각도가 정확한지 먼저 확인하세요. Logs & Events 뷰에서 규칙을 감사하다가 미세 조정하고 싶거나 동작이 최선인지 의심스러운 인시던트(또는 인시던트 묶음)를 만나면, 해당 Data Type이나 규칙에 Follow Up 플래그 를 달아 둘 수 있습니다.

Logs & Events > Logs 뷰 사용

DLP Gateway는 여러 이벤트에 대해 로그를 발행합니다. 뷰는 다음 경로로 엽니다.

Logs & Events > Logs > Queries > DLP

Data Loss Prevention 로그는 필터링하기 좋게 분류 돼 있습니다. 더 자세히 보려면 다음과 같이 합니다.

SmartConsole의 이벤트 분석 뷰

R80부터 SmartEvent GUI의 이벤트 분석(Event Analysis) 뷰가 SmartConsole의 Logs & Events 뷰에 통합 됐습니다. 이 뷰는 켜진 Security Gateway를 통과하는 모든 이벤트에 대해 필터, 차트, 통계 라는 고급 분석 도구를 제공합니다.

DLP 동작(인시던트 관점)

인시던트 로그에 나타나는 DLP 동작은 다음과 같습니다.

DLP 일반 열(General Columns)

DLP 인시던트는 다음 열의 일부 또는 전부를 보일 수 있으며, 모든 관리자가 볼 수 있습니다.

Incident UID를 여러 로그의 연결 키로 쓰기

각 DLP 인시던트에는 로그에 포함되고 이메일 알림으로 사용자에게도 전달되는 고유 ID(Incident UID) 가 있습니다. 사용자 응답(Send, Do not Send)에는 최초 DLP 인시던트 로그와 같은 Incident UID 가 부여됩니다.

예를 들어 사용자/관리자가 DLP 위반이 있는 이메일을 보낸 뒤 버리기로 하면 로그가 두 개 생깁니다. 첫 번째는 Ask User 동작의 DLP 인시던트 로그로 Incident UID가 부여되고, 사용자가 행동하면 같은 UID에 Do not Send 동작을 가진 두 번째 로그가 생깁니다.

매칭된 Data Type마다 자기 로그 가 생깁니다. Security Gateway는 한 인시던트의 모든 Data Type 로그가 같은 Incident UID와 같은 규칙 동작(Prevent, Ask, Inform, Detect)을 보이도록 보장합니다. Data Type들이 서로 다른 규칙에서 매칭됐어도 마찬가지이며, 인시던트에 표시되는 동작은 가장 제한적인 것 입니다.

예를 들어 한 전송이 두 Data Type에 매칭되고 각 Data Type이 다른 규칙에 쓰였다고 합시다. 한 규칙의 동작은 Prevent, 다른 규칙은 Detect입니다. 생성된 두 로그는 모두 동작을 Prevent 로 보이고 실제 구현된 동작도 Prevent입니다. 이때 Detect 규칙의 로그는 DLP Action Reason 열에 Rule Base(다른 규칙이 설정한 동작) 라고 표시합니다.

DLP 제한 열(Restricted Columns)

다음 열은 권한이 있는 관리자에게만 보입니다.

Data Owner와 사용자 알림

Data Owner를 정의하고, 그들의 회사 지침을 준비하고, 사용자·Data Owner와 소통하고, Ask User 규칙을 설정·관리하고, DLP Portal과 UserCheck Client에서 인시던트를 처리하는 방법은 별도 장에서 다룹니다(Data Owner와 알림).