11Data Type 정의하기Data Type 정의하기

Data Owner는 자기가 책임지는 데이터의 종류를 알고 있어야 하며, 그중 어떤 데이터가 조직 밖으로 나가도 되고 어떤 데이터는 반드시 보호해야 하는지를 관리자에게 알려 줄 수 있어야 합니다. 예를 들어 개발팀 팀장은 소스 코드 줄이 조직 밖으로 나가면 안 된다 는 것을 알고 그 보호를 요구해야 하고, 병원 행정 담당자는 승인된 도메인으로 환자 기록을 보낼 때 쓰는 법원 명령서 같은 예시를 가지고 있어야 합니다.

작업 순서를 잡을 때 다음 세 가지를 기억하세요.

규칙을 만드는 구체적 절차는 규칙 만들기를 참고하세요. 이 장은 그 규칙에 넣을 재료, 곧 Data Type 자체를 다룹니다.

새 Data Type을 정의하는 가장 좋은 방법은 Data Type Wizard 입니다. 기본 절차는 다음과 같습니다.

마법사에서 고를 수 있는 식별 방식은 크게 여섯 가지(키워드·패턴·템플릿·지문·파일·복합형)이고, Advanced 드롭다운으로 네 가지 고급형(가중 키워드·사전·메시지 속성·CPcode)을 추가로 고를 수 있습니다. 아래에서 하나씩 봅니다.

Keywords — 키워드로 보호하기

키워드 목록을 만들어 데이터 전송과 대조 하는 방식입니다. 데이터 안에 이 목록의 단어들이 들어 있으면 매칭되며, ALL 이냐 ANY 냐로 매칭 방식을 지정합니다.

예를 들어 어떤 위원회 의원들의 이름이 들어간 이메일을 아무도 못 보내게 하려면 그 이름들을 키워드로 두고 Threshold 를 At least 1 로 둡니다. Threshold가 높을수록 결과가 정밀 해집니다. 반대로 의원 이름이 언급되는 것은 허용하되 한 이메일에 모든 이름이 다 들어 있으면 의심스럽다 고 본다면 Threshold를 All words must appear 로 둡니다.

Pattern — 정규식 패턴으로 보호하기

정규식(regular expression)을 데이터 전송 내용과 대조 하는 방식입니다. 패턴에 맞는 문자열이 들어 있으면 매칭됩니다.

예를 들어 다섯 개 제품의 전체 가격표가 든 이메일을 막으려면 패턴을 ^[0-9]+(\.[0-9]{2})?$ 로 두고 Number of occurrences 를 5로 둡니다.

Template — 사내 문서 템플릿으로 보호하기

기밀·민감 문서는 흔히 템플릿을 바탕 으로 만들어집니다. 템플릿은 관련 문서들의 헤더·푸터·직인(seal)·서식을 규정하며, 모든 법원 명령서가 비슷하게 생긴 것도 이 때문입니다. 특정 템플릿을 기준으로 문서를 보호하는 Data Type을 만들면, 그런 문서가 든 연결이 정책에 매칭됩니다.

추가 속성은 다음과 같습니다.

서로 다른 닮음 수준을 서로 다른 동작으로 잡고 싶다면, 슬라이더 하나로 테스트하는 대신 다음처럼 단계별 정책을 짭니다.

Fingerprint — 지문으로 보호하기

많은 Data Type은 키워드나 문서 형식·이름·크기 같은 파일 속성으로 데이터를 분류해 식별합니다 — 곧 데이터를 "묘사" 하는 방식입니다. Fingerprint Data Type 은 결이 다릅니다. 데이터의 묘사에 기대지 않고, 지문(fingerprint)이라는 고유한 서명 으로 데이터를 식별합니다. 지문은 기밀 파일 또는 기밀 파일의 일부 까지 정확히 가려냅니다.

고유 서명이 만들어지고 쓰이는 흐름은 다음과 같습니다.

Repository Scanning — 저장소 스캔

저장소의 파일은 계속 바뀝니다. 새 파일이 추가되고 기존 파일이 수정·삭제됩니다. 서명을 최신으로 유지하려면 저장소를 주기적으로 스캔 해야 합니다. 기본적으로 저장소는 매일 자동 스캔 됩니다. 스캔 이후에 파일이 추가·수정되면, 그 파일의 서명은 다음 예약 스캔 전까지 갱신되지 않습니다.

저장소로 지원되는 파일 공유는 다음과 같습니다.

Filtering the Repository — 효율을 위한 필터링

큰 저장소에는 기밀이 아니어서 스캔할 필요 없는 파일도 많습니다. 다음 두 가지로 스캔을 더 효율적으로 만들 수 있습니다.

Granularity — 부분 일치

파일 전체가 조직 밖으로 나가야만 데이터가 새는 것은 아닙니다. 저장소 파일의 일부 구간이 다른 파일로 복사되거나 이메일·웹에 올라가면 기밀 데이터가 샐 수 있습니다. 또 저장소 파일이 로컬에 저장된 뒤 고유 지문 서명과 더 이상 일치하지 않을 만큼 수정 될 수도 있습니다. 이런 사고를 잡으려면, DLP Gateway가 검사한 파일과 저장소 파일 사이의 부분 일치(partial match) 를 설정합니다. 부분 일치는 두 방식 중 하나입니다.

Scan Times — 스캔 시간 제한

큰 저장소는 스캔이 하루 종일 돌 수도 있습니다. 이를 막으려면 스캔을 특정 시간대로 제한합니다. 시간대가 끝날 때까지 스캔이 끝나지 않으면, 다음 예약 스캔 때 멈춘 지점부터 다시 시작 합니다.

Generating Logs — 스캔 로그

저장소 스캔은 Logs & Events 뷰에서 볼 수 있는 로그를 생성합니다. 이 뷰에서 Fingerprint 쿼리를 쓰면 스캔이 만든 모든 로그가 표시됩니다. 로그가 생성되는 경우는 다음과 같습니다.

로그 상세에 표시되는 파라미터는 다음과 같습니다.

Fingerprint Data Type 만들기

지문 속성 더 구성하기

Data Types 창이나 Repositories 창에서 지문 객체를 더블클릭하면 편집할 수 있습니다. 구성 가능한 속성은 다음과 같습니다.

Repository Scan Filter 페이지는 다음 스캔 기준을 추가로 제공합니다.

Data locations 트리로 저장소 하위 폴더를 포함/제외할 수 있습니다. 한 가지 문서 형식만 조직 밖으로 못 나가게 하려면, 그 문서를 다른 문서가 없는 폴더에 두고 그 폴더만 데이터 위치로 선택하세요.

지문 Data Type 사용하기

지문 Data Type을 쓰려면 다음을 해야 합니다.

정책에 포함된 뒤 예약 스캔이 일어나고, 스캔이 성공적으로 끝나야 지문 Data Type이 적용 됩니다. 저장소를 수동으로 스캔하려면, Repositories 창에서 지문 Data Type을 선택하고 요약 창(summary pane)에서 Start 를 클릭합니다.

NATed 환경에서의 NFS 저장소 스캔

NAT가 걸린 환경(예: 클러스터에서 각 멤버의 연결이 클러스터의 Virtual IP로 변환되는 경우)에서는 저장소가 NFS 서버에 있으면 스캔이 막힙니다. 스캔을 가능하게 하려면 모든 NFS 서비스에서 Hide NAT를 꺼야 합니다. 클러스터 멤버는 NFS 관련 트래픽을 패킷의 Source 필드에 클러스터 Virtual IP가 아니라 멤버 자신의 IP 로 보내도록 구성해야 합니다.

클러스터에서 NFS 서비스의 Hide NAT를 끄는 절차는 다음과 같습니다.

no_hide_services_ports

no_hide_services_ports = { <111, 17>, <111, 6>, <4046, 17>,
<4046, 6> }

Files — 파일 속성으로 보호하기

파일 형식·파일 이름·파일 크기를 기준으로 파일을 보호하는 Data Type입니다. 이 파라미터에 맞는 파일이 든 전송이 매칭됩니다.

Compound — 복합 Data Type 정의하기

여러 Data Type을 묶어 복잡한 표현을 만들 수 있습니다. Compound Data Type 은 여러 Data Type을 AND(여러 Data Type이 모두 매칭) 또는 NOT(꼭 없어야 할 Data Type이 없음), 또는 둘 다 로 조합합니다.

예를 들어 환자 기록이 든 파일·이메일을 찾는다고 합시다. 환자 기록 템플릿에 매칭되는 문서와, 동의서를 내지 않은 환자 이름이 든 사전(dictionary) Data Type을 결합하면, "동의서를 내지 않은 환자의 기록이 든 이메일·FTP"를 잡는 단일 Data Type이 됩니다.

Data Type Wizard에는 네 가지 고급 Data Type이 있습니다. 이들은 보통 Data Representation 페이지 아래쪽에서 Advanced 를 고른 뒤 드롭다운에서 선택합니다. SmartDashboard로 들어가는 경로는 공통입니다 — SmartConsole 왼쪽 패널에서 Manage & Settings → Blades → Data Loss Prevention 섹션의 Configure in SmartDashboard → DLP 탭 왼쪽 Data Types → 상단 New.

Weighted Keywords — 가중 키워드

키워드나 패턴 Data Type을 만들다 보면, ALL/ANY로 딱 떨어지지 않고 어떤 단어는 그 자체로 보호 데이터의 신호이지만 다른 단어는 여러 번 나와야만 의심스럽다 는 경우가 있습니다. 이럴 때 단순 키워드·패턴 대신 Weighted Keyword 로 정의합니다. 정의한 가중치 합(weight-sum)으로 데이터에 단어들이 나타나면, 그 Data Type을 쓰는 규칙의 동작에 따라 처리됩니다.

Words from a Dictionary — 정적 사전

보호 데이터를 표시하는 키워드 목록이 이미 있다면, 키워드 표현에 하나씩 입력할 필요 없이 목록을 static dictionary 로 업로드 하면 됩니다. 목록 항목 중 몇 개가 일치해야 DLP 규칙에 매칭할지를 정합니다.

절차는 다음과 같습니다.

Dynamic Dictionary — 동적 사전

Dynamic Dictionary 를 쓰면, 변경할 때마다 사전 파일을 Management Server에 수동 업로드하고 모든 DLP Gateway에 정책을 다시 설치할 필요 없이 DLP 사전을 자동 갱신 할 수 있습니다.

원리는 이렇습니다. 관리자가 DLP Gateway에서 접근 가능한 웹 서버에 동적 사전 파일을 두고, 그 파일의 전체 주소를 담은 사전 Data Type을 구성합니다. DLP Gateway는 기본 60분마다 이 파일을 내려받아 즉시 적용합니다. SmartConsole과 SmartView는 사전을 내려받을 때마다 로그를 남깁니다.

지원 항목:

절차는 다음과 같습니다.

http://192.168.22.33/public/customers.txt

serveruser
ServerP@ssword#

cp -v $DLPDIR/config/dlp.conf{,_BKP}

vi $DLPDIR/config/dlp.conf

:dynamic_dt (
...
:enable_dynamic_updates (1)
:update_interval_in_min (60)
:passwords_are_obscured (0)
...
)

파라미터의 의미는 다음과 같습니다.

Exact Data Match (EDM) — 동적 사전 확장

Exact Data Match(EDM) 는 Dynamic Dictionary 기능을 확장합니다. 관리자는 테이블 파일(CSV)을 데이터 원본 으로 쓰고, 각 레코드(행)에서 몇 개의 필드(열) 가, 그리고 이 테이블에서 몇 개의 레코드 가 일치해야 하는지로 매칭을 구성할 수 있습니다.

지원 항목:

알려진 제약:

절차는 동적 사전과 거의 같습니다. CSV 파일(예: customersInfo.csv)을 웹 서버에 올리고, 그 URL을 첫 줄에 담은 .dyn_dict 파일을 만든 뒤(인증이 필요하면 둘째·셋째 줄에 사용자 이름·암호), SmartDashboard에서 Words from a dictionary Data Type으로 그 .dyn_dict 를 업로드합니다. 그다음 게이트웨이에서 다음을 구성합니다.

DLP Gateway / 각 DLP Cluster Member의 Expert mode에서 $FWDIR/conf/dlpe_edm_config.C 파일을 다룹니다(기본적으로 없으므로 생성).

touch $FWDIR/conf/dlpe_edm_config.C
vi $FWDIR/conf/dlpe_edm_config.C

필요한 구문은 다음과 같습니다.

:edm (
:enabled (NUMBER)
:edm_columns_to_inspect ("Col_index_1,Col_index_2,...,Col_index_N")
:edm_column_threshold (NUMBER)
:edm_required_match_columns ("Col_index_1,Col_index_2,...,Col_index_N")
)
)

파라미터의 의미는 다음과 같습니다.

예를 들어 다음 테이블 데이터를 봅시다.

요구 사항이 (i) 인덱스 1~4 열만 검사, (ii) 각 레코드에서 두 개 열 검사(threshold 2 → 가능한 두 열 조합은 1+2, 1+3, 1+4, 2+3, 2+4, 3+4), (iii) 선택적으로 인덱스 3 열은 각 레코드에서 반드시 일치(→ 조합이 1+3, 2+3, 4+3 으로 좁혀짐)라면, 필요한 구문은 다음과 같습니다.

:edm (
:enabled (1)
:edm_columns_to_inspect ("1,2,3,4")
:edm_column_threshold (2)
:edm_required_match_columns ("3")
)
)

이 구문을 파일에 붙여 넣고 저장한 뒤, SmartConsole에서 Access Control Policy 를 설치합니다.

Message Attributes — 메시지 속성

메시지 속성이란 메시지의 다음 성질을 말합니다 — 총 메시지 크기(KB), 첨부 파일 개수, 메시지의 총 단어 수. 공통 경로로 마법사를 띄워 Advanced → Message Attributes 를 고른 뒤, Specify Message Attributes 페이지에서 구성합니다.

Message Size — 메시지가 가질 수 있는 크기를 정합니다.

Number of Attachments — 메시지가 가질 수 있는 첨부 개수를 정합니다.

Total Number of Words in the Message — 의미 있는 양의 텍스트 가 있는지 스캔합니다. 예컨대 큰 이진 파일(그래픽)이 첨부되고 본문이 "your picture"뿐이라면, 크기 속성에는 걸려도 스캔할 만한 텍스트는 없습니다. 데이터 손실로 이어질 만큼 충분한 텍스트가 있을 때만 규칙에 매칭되게 하려는 것입니다.

구성 후 마법사를 마치고, 저장·닫기 후 SmartConsole에서 Access Control Policy 를 설치합니다.

CPCode — 직접 짜는 매칭 로직

CPCode 는 C나 Perl과 비슷한, 침입 방지 시스템(IPS)용 스크립트 언어 입니다. 이 언어에 익숙하다면 직접 복잡한 규칙을 만들 수 있습니다. CPCode Data Type으로 보호 대상의 동적 정의 를 만들거나 맞춤 파라미터가 든 표현 을 만들 수 있습니다.

예를 들어 공개 출시 이전 날짜를 검사하는 CPCode 를 만들면, 그 날짜 이전에는 가격표 출시를 막고 이후에는 통과시키는 규칙을 짤 수 있습니다. 그 밖에도 규칙 파라미터 간의 관계 — 수신자(너무 많은 도메인으로 보내면 매칭), 프로토콜(웹 메일처럼 보이면 HTTP에 매칭) 등 — 에 흔히 씁니다.

CPcode 함수 예시:

func rule_1 {
foreach $recipient inside global:DESTS {
foreach $comp inside CPMPETITORS_DOMAIN {
if( casesuffix( $recipient , $comp ) ) {
set_message_to_user(cat("The mail is sent to " ,
$recipient ,
"which is a competitor's mail address."));
set_track(TRACK_LOG);
return quarantine();
}
}
}
}

만드는 절차는 다음과 같습니다.

신용카드 번호 같은 일부 Data Type은 General Properties 페이지에 Enhance accuracy through statistical analysis 옵션이 있습니다. Visa·Mastercard 같은 신용카드는 16자리를 4자리씩 네 그룹 으로 나눈 번호이고, 이 Data Type을 스캔할 때 데이터의 모든 16자리 숫자 중 Luhn 알고리즘에 맞는 것을 신용카드 번호 로 식별합니다. 하지만 16자리 숫자가 부품 번호나 주문·판매 코드일 수도 있습니다. 이 옵션은 통계 분석으로 식별 정확도를 높입니다.

Data Type을 만들었으면 규칙에 넣어야 정책으로 강제됩니다. 전체 흐름은 (1) Compliance Data Type 지정 → (2) 조직별 복잡한 Data Type 생성 → (3) 만든 Data Type을 규칙에 추가 → (4) DLP Gateway에 정책 설치입니다.

1단계 — Compliance Data Type 지정

Compliance(준수) 카테고리에는 받아들여진 표준과 규제 요구사항을 나타내는 기본 제공 Data Type 이 들어 있습니다. 예컨대 PCI(Payment Card Industry) 준수 기준상 고객 신용카드 번호를 평문으로 외부에 보내면 안 됩니다. Data Types 창에서 Data Type은 카테고리별로 정렬되며, 그중 Compliance가 중요한 카테고리입니다.

Data Loss Prevention Overview 창의 DLP Featured Data types 도구상자는 다음 카테고리별 Data Type을 나열합니다 — Compliance(버튼을 누르면 이 카테고리의 Data Type과 활성화 개수가 보임), Business information, Personally identifiable information, Best Practice, Intellectual Property, Human Resources, Financial. Featured Data Types 영역에서 가능한 동작은 두 가지입니다.

Data Types 창 도구 막대에서 Compliance 를 클릭하면 Compliance 카테고리에 속하지 않는 Data Type이 걸러집니다. Check Point는 기본 제공 Data Type을 꾸준히 늘리지만, 맞는 것이 없으면 새 Data Type을 만들어 Compliance 카테고리에 추가 할 수 있습니다. 기본 제공 Data Type은 다음 기준에 대해 존재합니다.

새 Data Type을 Compliance 카테고리에 추가하려면:

Data Type 편집하기

마법사로 Data Type을 만든 뒤 필요하면 미세 조정할 수 있습니다. General Properties 창은 현재 선택한 Data Type에 해당하는 필드만 보여 줍니다.

편집 창의 섹션별 필드는 다음과 같습니다.

추가로 임계값(Threshold) 관련 섹션이 데이터 종류별로 나뉩니다.

Data Type Group — Data Type 그룹 만들기

기존 Data Type들을 묶은 그룹을 Data Type으로 만들 수 있습니다.

2단계 — 조직별 복잡한 Data Type 만들기

Data Owner와 상의한 뒤, 조직의 기밀·무결성 절차에 맞춰 키워드 Data Type에 Advanced Matching 을 지정할 수 있습니다. 키워드·패턴·가중 키워드·사전이 매칭된 뒤에 추가 매칭 기준을 적용하는 CPcode 스크립트 를 더해 정확도를 높이는 식입니다. CPcode 스크립트에 대응하는 value 파일(상수 값)이나 CSV 파일이 있으면 여기서 함께 추가합니다.

Advanced Matching CPcode 스크립트를 추가하려면:

3단계 — 만든 Data Type을 규칙에 추가하기

모든 Data Type 표현에 대해, Data Type이 매칭된 뒤 실행되는 CPcode 스크립트(Post Match) 를 추가할 수 있습니다. 절차는 2단계와 같되, Advanced Matching 노드에서 Run these CPcode scripts after this Data Type is matched to apply additional match criteria 에 스크립트를 추가합니다(Add/View/Remove, 기본 형식 CPC). 추가 후 OK → Save → 닫기 → 정책 설치.

Data Type 테스트하기(권장)

새 Data Type이 든 정책을 설치하기 전에 랩 환경에서 테스트 하기를 권장합니다.

Data Type 내보내기·가져오기

만든 Data Type이나 기본 제공 Data Type을 파일로 내보낼(export) 수 있습니다. 서로 다른 Security Management Server가 관리하는 DLP Gateway 간에 Data Type을 공유할 때 유용합니다.

내보내기: DLP 탭 → Data Types → 내보낼 Data Type 선택 → Actions > Export → dlp_dt 확장자 파일로 저장 → Save 후 닫기.

가져오기로는 다른 Management Server와 공유하거나, 내보낸 뒤 삭제한 Data Type을 복구하거나, 리셀러·Check Point에서 받은 새 Data Type을 추가할 수 있습니다.

가져오기: DLP 탭 → Data Types → Actions > Import → 원하는 dlp_dt 파일 선택 → Save → 닫기 → SmartConsole에서 정책 설치.

4단계 — DLP Gateway에 정책 설치

위 단계를 마쳤으면 마지막으로 DLP Gateway에 정책을 설치 합니다.

Repository 는 문서 저장에 쓰이는 네트워크 위치 입니다. DLP에는 두 종류가 있습니다.

Fingerprint Repository 만들기

Whitelist Repository 만들기

DLP rule base가 절대 매칭하지 않을 파일 목록 을 만드는 방법은 두 가지입니다.

화이트리스트에 파일을 추가하려면:

규칙에서 쓸 이메일 주소와 도메인을 정의하려면: