10규칙 만들기 — 시나리오별 접근규칙 만들기 — 시나리오별 접근
Out of the Box 정책으로 시작했다면, 이제 사건을 관찰하며 우리 조직에 맞는 규칙으로 다듬어 갈 차례입니다. 이 장은 사용자 행동을 학습하는 Learning Mode, 휴리스틱 기반의 분석적 구성, 규칙을 실제로 짜는 새 규칙 만들기(시나리오별 예시 포함), MultiSpect 기능으로 정밀하게 다듬는 맞춤 구성, 규칙을 Prevent 로 올려 본격 차단하기, 그리고 Multi-Realm 인증 까지, DLP 정책을 무르익게 만드는 전 과정을 빠짐없이 정리합니다.
Learning Mode — 사용자 결정을 한 번으로 묶기
DLP가 위반을 잡아 사용자에게 묻는 상황(Ask User)에서, 같은 대화나 게시·업로드가 여러 메시지로 쪼개지면 사용자는 같은 결정을 몇 번이고 반복해야 합니다. Learning Mode(Learn User Actions)는 이런 번거로움을 줄여, 한 번의 결정을 같은 흐름의 나머지에도 그대로 적용 합니다.
이메일 스레드·HTTP 게시(post)·FTP 업로드에 대해 Learning Mode를 켜는 길은 이렇습니다.
- SmartConsole에서 Security Policies > Shared Policies > DLP 를 고르고 Open DLP Policy in SmartDashboard 를 클릭합니다. SmartDashboard 가 열리며 DLP 탭을 보여 줍니다.
- 탐색 트리에서 Additional Settings > Advanced 를 클릭합니다.
- Learn User Actions 섹션에서 해당하는 항목을 선택합니다.
세 가지 옵션이 각각 어떻게 동작하는지는 차이가 큽니다.
| 옵션 | 켰을 때 | 껐을 때 | 기본값 |
|---|---|---|---|
| 사용자가 스레드 전체에 대해 한 번 결정하면, 같은 스레드의 모든 메시지에 그 결정이 적용됩니다. | DLP 규칙에 매칭되는 모든 메시지를 사용자에게 알립니다. 예전 메시지에서 따라온(carried-over) 텍스트 때문에 매칭된 메시지까지 모두 알립니다. | 해제됨 | |
| Web | 한 사이트로의 게시(post)에 대해 한 번 결정 하면, 12시간 이내 에 그 전 게시의 내용을 포함한 모든 게시에 적용됩니다. | 매칭되는 모든 게시를 사용자에게 알립니다(예전 게시에서 따라온 텍스트로 매칭된 것까지). | 선택됨 |
| FTP | FTP 업로드에 대해 한 번 결정 하면, 12시간 이내 의 모든 업로드에 적용됩니다. | 매칭되는 모든 업로드를 사용자에게 알립니다(예전 업로드에서 따라온 내용으로 매칭된 것까지). | 해제됨 |
DLP가 Exchange 이메일을 검사할 때는 Learning Mode가 Exchange 트래픽에도 적용되고, HTTPS Inspection을 켜 두면 HTTPS 게시에도 적용됩니다.
분석적 구성 — 휴리스틱으로 필요를 읽어 내기
휴리스틱 기반 규칙이 잡은 사건들을 감사하다 보면, 우리 조직이 실제로 무엇을 지켜야 하는지 가 보입니다. 이 이해를 바탕으로 정책을 한 단계 끌어올리는 것이 Analytical Configuration 단계입니다.
이 단계의 핵심은 세 가지입니다.
- Check Point 휴리스틱에 기반한 자동 검사 — 데이터를 자동으로 검사합니다. 제공된 Data Type 을 조합해 정책을 더 엄격하게 만들거나, 특정 조건을 허용하는 Exceptions(예외)를 만들 수 있습니다.
- 규칙을 Ask User 로 — 이 단계의 규칙은 Ask User 로 둡니다. 그러면 사용자는 무엇이 허용되고 무엇이 안 되는지 배우 면서 정확도를 높이는 데 기여하고, 자가 처리(self-handling) 결정에 대한 설명 을 남깁니다.
- 로그로 검토 — 관리자는 Logs & Events > Logs 뷰에서 사용자의 자가 처리 행동과 그 설명을 검토해, 알려진 시나리오에 맞는 Data Type 을 정책에 더해 갑니다.
정리하면, 이 단계는 관찰 → 분석 → 차단 으로 무르익는 DLP 정책의 가운데 마디입니다. 충분히 이해가 쌓이면 핵심 규칙을 Prevent 로 옮겨 본격 차단에 들어갑니다.
DLP 규칙의 구성요소
DLP 규칙은 Firewall 규칙과 비슷해 보여도 결이 다릅니다. Firewall 규칙이 주로 밖에서 안으로 들어오는 트래픽을 보는 반면, DLP 규칙은 안에서 밖으로 나가는 데이터를 보 고, 프로토콜·사람보다 Data Type 이 규칙의 중심 입니다. 한 규칙은 보호할 Data Type, 전송 Source(기본 My Organization), Destination(기본 Outside My Org), Protocol(기본 Any), Exceptions, Action, Tracking, Severity, Install On, Time, Category, Comment 으로 이뤄집니다.
새 규칙 만들기 — 단계별 절차
DLP 정책을 이루는 규칙은 SmartDashboard에서 한 줄씩 만들어 갑니다. DLP 규칙은 순서가 중요하지 않 습니다 — 각 DLP 게이트웨이가 설치된 모든 규칙을 검사 하기 때문입니다.
규칙을 만드는 전체 절차는 이렇습니다.
- SmartConsole에서 Security Policies > Shared Policies > DLP 를 고르고 Open DLP Policy in SmartDashboard 를 클릭합니다. SmartDashboard 가 열리며 DLP 탭을 보여 줍니다.
- 탐색 트리에서 Policy 를 클릭합니다.
- New Rule 을 클릭합니다. 규칙 베이스 표에 새 줄이 열립니다.
- Data 열에서 더하기(
+)를 눌러 Data Type picker 를 열고, 검사 내용과 매칭할 Data Type 을 고릅니다. 한 규칙에 여러 Data Type을 넣으면 OR로 묶 여, 하나만 걸려도 규칙이 매칭됩니다(Data Type 정의하기). - Source 열에서 기본값 My Organization 을 두거나, 더하기를 눌러 Users·Emails·Networks 에서 특정 항목을 고릅니다.
- Destination 열에서 다음 중 하나를 고릅니다.
- 기본값 Outside My Org 를 두면 — My Organization에 정의되지 않은 목적지로 가는 데이터 전송을 검사합니다.
- 더하기를 눌러 Users·Emails·Networks 에서 특정 항목을 고릅니다.
- Source가 My Organization이 아니라면 Outside Source 를 고를 수 있습니다.
- Action 열에서 다음 중 하나를 합니다.
- Detect(기본) — 매칭된 사건을 로그로 남기되, 데이터 전송은 방해하지 않습니다.
- 오른쪽 클릭 후 Inform User — 전송은 통과시키되 사용자에게 알림을 보냅니다.
- 오른쪽 클릭 후 Ask User — 사용자가 통과·폐기를 결정할 때까지 기다립니다.
- 오른쪽 클릭 후 Prevent — 전송을 멈춥니다.
- Track 열에서 기본값 Log 를 두거나(사건을 로그로 남겨 Logs & Events > Logs 뷰에서 감사), 오른쪽 클릭으로 다른 추적 옵션을 고릅니다.
- (선택) 데이터 소유자(Data Owners)에게 알림 을 더하려면 — Email 옵션을 선택하고, 이 규칙이 매칭될 때 데이터 소유자가 보게 될 알림을 맞춤 작성합니다.
- Install On 열에서 DLP Blades 를 골라 모든 DLP 게이트웨이에 적용하거나,
[+]아이콘을 눌러 특정 DLP 게이트웨이를 고릅니다. - Time 열에서 이 정책이 적용될 날짜·시간을 정합니다. 시간 객체를 쓰는 규칙은 지정한 기간 안에 시작된 연결에만 적용됩니다. 연결이 그 시간대를 넘겨 계속되면 그대로 허용됩니다. 적용 기준 시간대는 규칙을 적용하는 Check Point Security Gateway 의 시간대입니다.
- Category 열에서 오른쪽 클릭 후 정의된 카테고리를 고릅니다.
- Comment 열에서 오른쪽 클릭 후 Edit 를 골라 규칙에 대한 설명을 입력합니다.
- Save 를 클릭합니다.
- SmartDashboard를 닫습니다.
- SmartConsole에서 정책을 설치합니다.
Outside Source 와 Outside My Org 의 차이
여기서 Outside Source 와 Outside My Org 의 차이 가 중요합니다. Outside Source 는 DLP 규칙의 목적지로, 그 규칙의 Source 바깥 전부 를 뜻합니다. 예컨대 규칙의 Source가 Network_A 이고 목적지가 Outside Source 라면, Network_A에서 Network_A 바깥의 어떤 주소로든 가는 전송을 검사합니다. 반면 목적지가 Outside My Org 라면 Network_A에서 조직 전체의 바깥으로만 가는 전송을 검사합니다. 즉 Outside Source 는 부서 간(inter-department) 규칙 을 만들 때 씁니다.
내부 DLP 정책 규칙 — 시나리오 예시
Exchange Security Agent로 구성한 환경에서, 언제 트래픽을 검사할지 를 정의하는 서로 다른 규칙을 만드는 예시입니다(Exchange Security Agent 구성은 별도 장 참조). 재무 부서의 Financial Reports 를 어떻게 다룰지 세 가지 시나리오로 살펴봅니다.
시나리오 1 — 재무 부서가 보내는 재무 보고서 검사
재무 부서 사용자가 보내는 재무 보고서를, 재무 부서를 제외한 모든 내부 사용자와 외부 사용자 에게 가는 경우 검사하고 싶을 때입니다. 규칙 하나를 이렇게 만듭니다.
| Data | Source | Destination | Exceptions | Action |
|---|---|---|---|---|
| Financial Reports | Finance_Dept | Outside Source | None | Ask User |
여기서 Outside Source 는 재무 부서가 아닌 모든 내부 사용자와 모든 외부 사용자 에 대해 매칭됩니다. 더 폭넓은 보호와 엄격한 정의가 필요하면 다음 시나리오로 Source를 넓힙니다.
시나리오 2 — 재무 부서 밖에서 보내는 재무 보고서 차단
재무 보고서가 재무 부서 밖의 사용자 에 의해 나가지 않게 하려면, 조직 전체 사용자(재무 부서 포함)가 어떤 목적지로 보내든 적용되는 규칙을 하나 더 만듭니다.
| Data | Source | Destination | Exceptions | Action |
|---|---|---|---|---|
| Financial Reports | Finance_Dept | Outside Source | None | Ask User |
| Financial Reports | My Organization | Any | 1 | Prevent |
여기서 Source = My Organization, Destination = Any(내부·외부 모든 목적지), Action = Prevent 입니다. 그런데 이대로 두면 재무 부서 사용자가 보낸 보고서가 첫 번째 규칙과 두 번째 규칙에 동시에 매칭 됩니다. 데이터가 둘 이상의 규칙에 걸리면 가장 제한적인 동작(most restrictive) 이 적용되고 로그도 여러 개 생깁니다. 즉 예외가 없으면 재무 부서 사용자가 보낸 보고서까지 두 번째 규칙의 Prevent 때문에 차단되고 중복 로그가 쌓입니다.
그래서 두 번째 규칙에 재무 부서 → 재무 부서 전송을 빼는 예외를 더합니다(예외 만들기는 아래 참조).
| Data | Source | Destination | Protocol |
|---|---|---|---|
| Financial Reports | Finance_Dept | Any | Any |
이 두 규칙의 결과를 정리하면 이렇습니다.
- 재무 부서 사용자가 재무 부서 외 내부 사용자 에게 보내는 재무 보고서 → Ask User.
- 재무 부서 사용자가 외부 사용자 에게 보내는 재무 보고서 → Ask User.
- 재무 부서가 아닌 사용자 가 내부·외부 누구에게든 보내는 재무 보고서 → Prevent.
시나리오 3 — 재무 보고서는 재무 부서 안에서만
재무 보고서를 재무 부서 안에서만 주고받게 하고, 재무 부서 밖에서 보내는 사용자에게는 알림을 띄워 어떻게 할지 결정하게 하려는 경우입니다. 규칙 하나를 만듭니다.
| Data | Source | Destination | Exceptions | Action |
|---|---|---|---|---|
| Financial Reports | My Organization | Any | 1 | Ask User |
그런 다음 재무 부서 → 재무 부서 로 보내는 보고서는 포함하지 않도록 예외를 더합니다.
| Data | Source | Destination | Protocol |
|---|---|---|---|
| Financial Reports | Finance_Dept | Finance_Dept | Any |
규칙에 대한 더 많은 옵션
규칙의 기본을 다 짠 뒤에는 이름·프로토콜 표시, 심각도 설정, 플래그 달기, 켜고 끄기 같은 일을 더 할 수 있습니다.
규칙 이름과 프로토콜 보기
DLP 규칙의 이름은 기본적으로 보이지 않지만, 필요하면 표시하거나 바꿀 수 있습니다. 예를 들어 어떤 규칙의 로그를 추적할 때, 로그의 이름을 정책의 이름과 맞춰 보면 편리합니다. 규칙 이름을 보려면 규칙 베이스 헤더에서 오른쪽 클릭 후 Name 을 고릅니다.
또 기본적으로 모든 DLP 규칙은 Security Gateway 속성에 정의된 프로토콜 으로 데이터를 검사하지만, 규칙이 지정한 프로토콜만 검사하게 둘 수도 있습니다. 규칙의 프로토콜을 보려면 규칙 베이스 헤더에서 오른쪽 클릭 후 Protocol 을 고릅니다.
규칙 심각도(Severity) 설정
규칙에 심각도 등급을 매기면 Logs & Events 뷰에서 결과를 필터링하고 더 적절한 보고서를 만들 수 있으며, 규칙 베이스를 심각도로 정렬·그룹화할 수도 있습니다. Severity 열로 가서 기본 등급(예: Medium)을 두거나, 오른쪽 클릭으로 다른 심각도를 고릅니다.
규칙에 플래그 달기
규칙에는 여러 알림용 플래그를 달 수 있습니다. 기대만큼 데이터를 잡지 못한 규칙에는 Improve Accuracy 를, 나중에 이 규칙이나 사용하는 Data Type을 바꾸고 싶다는 메모로는 Follow up 플래그를 답니다. 플래그를 단 규칙은 Overview 에서 바로 찾아갈 수 있고, Policy 에서 플래그로 규칙을 그룹화 할 수 있습니다.
예를 들어 내장 Data Type Employee Names 로 새 규칙을 만든다고 합시다. 이건 비어 있는 자리표시자(placeholder) 이므로 우리 조직의 직원 이름 목록을 채워야 합니다. 이 규칙에 Improve Accuracy 플래그를 달아 두면, 나중에 플래그나 Overview 링크로 그룹화해 쉽게 찾아 Data Type을 편집할 수 있습니다. 규칙에 플래그를 달려면 Flag 열에서 오른쪽 클릭 후 값을 고릅니다.
Follow up 플래그가 달린 규칙에서 생성된 로그·이벤트에도 Follow up 표시가 붙습니다. 로그를 확인한 뒤에는 플래그를 떼면 됩니다. Follow up 규칙이 만든 로그·이벤트를 보려면 Logs & Events > Logs 뷰를 열고, 열 머리글에서 오른쪽 클릭 후 Edit Profile 을 골라 Selected Fields 목록에 Follow up 을 더합니다.
규칙 켜고 끄기
앞으로 필요할 것 같은 규칙을 미리 정의해 두고, 실제로 트래픽에 매칭시키고 싶을 때까지 꺼 둘 수 있습니다.
- SmartConsole에서 Security Policies > Shared Policies > DLP 를 고르고 Open DLP Policy in SmartDashboard 를 클릭합니다.
- 탐색 트리에서 Policy 를 클릭합니다.
- 규칙을 끄려면 해당 규칙을 오른쪽 클릭 후 Disable Rule 을 고릅니다. 꺼진 규칙은 규칙 베이스에서 빨간 X 표시 가 붙습니다.
- 규칙을 다시 켜려면 꺼진 규칙을 오른쪽 클릭 후 Disable Rule 을 다시 클릭해 선택을 해제합니다.
- Save 를 클릭하고 SmartDashboard를 닫습니다.
- SmartConsole에서 정책을 설치합니다.
규칙 예외(Exceptions)
어떤 경우에는 DLP 정책의 규칙에 예외를 만들어야 합니다. 예를 들어 HIPAA 를 준수해야 하는 공공 보건 클리닉은 환자 기록이 폐쇄망을 떠나지 못하게 하지만, 환자를 위해 시청의 특정 사회복지사 는 그 기록을 갖고 있어야 합니다. 이때 관리자는 그 특정 이메일 주소로만 해당 Data Type을 보낼 수 있게 하는 예외를 만듭니다. 여기에 더해 예외에 보조 Data Type(예: 사회복지사 열람에 동의한 환자 이름 Dictionary)을 포함하면, 사회복지사 사무실은 허가된 기록만 받게 됩니다. DLP는 그 외 누구에게도 기록을 보내지 못하게 막아, 직원이 사적인 부탁을 받아 무단으로 기록을 보내는 일 자체를 불가능 하게 만듭니다.
예외 만들기
- SmartConsole에서 Policies > Shared Policies > DLP 를 고르고 Open DLP Policy in SmartDashboard 를 클릭합니다.
- 규칙의 Exceptions 열에서 오른쪽 클릭 후 Edit 를 고릅니다. Exceptions for Rule 창이 열립니다.
- New Exception 을 클릭합니다. 원래 규칙의 파라미터가 표에 나타납니다.
- 파라미터를 바꿔 예외를 정의합니다.
- Save 를 클릭하고 SmartDashboard를 닫습니다.
- SmartConsole에서 정책을 설치합니다.
Data Type 그룹으로 예외 만들기
예외에 Data Type 조합을 정의할 수 있습니다 — "이 데이터가 두 번째 종류의 데이터와 함께 오면 허용" 같은 식입니다.
- SmartConsole에서 Security Policies > Shared Policies > DLP 를 열어 SmartDashboard로 들어가 Policy 를 클릭합니다.
- 예외의 Data 열에서 더하기 버튼을 클릭합니다.
- 새 창에서 DLP 예외에 더할 Data Type들을 고릅니다.
- OK 를 클릭합니다.
사용자 기준 예외
특정 사용자·그룹·네트워크에서 오는 데이터에 적용되는 예외를 정의할 수 있습니다 — "이 사람에게서 오면 이 데이터를 허용".
- Source 열에서 더하기 버튼을 누르거나 오른쪽 클릭 후 Add 를 고릅니다. 발신자 목록에는 정의된 모든 사용자·사용자 그룹·네트워크·Security Gateway·노드가 들어 있습니다. 무엇이든 고르면 기본값 My Organization 은 제거 됩니다.
- 이 데이터를 허용할 출처를 정의하는 객체를 고릅니다. Source가 My Organization 이면 오른쪽 클릭 후 Edit 로 My Organization 창을 열어 내부 조직 정의를 바꿀 수 있는데, 이 정의는 DLP 전체에 적용됩니다.
목적지 기준 예외
특정 사용자·그룹·네트워크로 보내는 데이터에 적용되는 예외를 정의할 수 있습니다 — "이 사람에게 보내는 것이면 이 데이터를 허용".
- Destination 열에서 더하기 버튼을 클릭합니다. 수신자 목록에는 정의된 모든 사용자·사용자 그룹·네트워크·Security Gateway·노드가 들어 있습니다. 무엇이든 고르면 기본값 Outside My Org 는 제거 됩니다.
- 이 데이터를 허용할 목적지를 정의하는 객체를 고릅니다.
프로토콜 기준 예외
특정 프로토콜로 전송되는 데이터에 적용되는 예외를 정의할 수 있습니다 — "이 프로토콜로 보내는 것이면 이 데이터를 허용".
- Protocol 열에서 더하기 버튼을 클릭합니다. 프로토콜 목록에는 DLP가 지원하는 프로토콜이 들어 있습니다. 무엇이든 고르면 기본값 Any 는 제거 됩니다.
- 이 데이터를 허용할 프로토콜을 고릅니다.
맞춤 구성 — MultiSpect 로 정밀하게 다듬기
Check Point DLP는 MultiSpect 기능 묶음을 제공합니다. 이 기능들은 DLP 구성의 정확도를 모니터링하고 보장 하는 데 필요한 유연성을 줍니다. 예를 들어 사실은 지체 없이 통과시켰어야 할 전송에 동작이 걸렸다면, Data Type이나 규칙을 바꿔 다시는 그런 일이 없게 만들 수 있습니다. 이렇게 비교적 짧은 시간에 DLP를 미세 조정해 믿을 수 있는 구현 을 완성합니다.
여기에는 User Decisions(사용자 결정)도 활용할 수 있습니다. 이 정보가 얼마나 쓸모 있는지는 사용자와 얼마나 잘 소통하느냐 에 달려 있습니다. 사용자가 어떤 데이터를 지체 없이 보내고 싶고 그 이유를 설명할 수 있다는 걸 알게 해 주면, 기록된 그 결정을 근거로 규칙을 바꿀 수 있습니다.
MultiSpect에는 다음이 들어 있습니다.
- Compound Data Type — 여러 Data Type을 AND·NOT 검사로 결합 하는 데이터 타입입니다. 이를 쓰는 규칙은 AND 타입을 모두 가지면서 NOT 타입은 하나도 포함하지 않는 전송에 매칭됩니다.
- Data Type Groups — 어떤 카테고리든 여러 Data Type을 묶을 수 있습니다. 규칙에 쓰면 OR 검사 로 매칭됩니다.
- CPcode Data Type — CPcode 구문은 견줄 데 없는 유연성을 줍니다. 개방형 프로그래밍 언어의 모든 힘 으로 데이터 타입과 그 기능을 직접 만들고, 정확도를 높이거나 사용자 결정이 알려 준 대로 통과시켜야 할 메시지를 허용하도록 코드를 바꿀 수 있습니다.
- Flags for Data Types and Rules — Data Type을 관리하고 DLP 사용 로그·분석을 읽으면서, Data Type과 규칙에 플래그를 달아 정확도를 챙깁니다. 플래그가 달린 항목은 Overview 페이지에 모여 효율적으로 관리됩니다.
- Placeholder Data Types — 몇몇 제공 Data Type은 직접 목록을 채워야 할 사전·키워드 입니다. 예를 들어 비어 있는 자리표시자 Employee Names 는 우리 조직의 직원 목록으로 교체해야 합니다. 이 Data Type은 compound Data Type과 제공 규칙에 쓰이며, 출고 시 Improve Accuracy 플래그 가 달려 있습니다.
이 단계에서 일부 규칙을 Prevent 로 두기로 결정할 수 있습니다. DLP가 Prevent 사건을 잡으면 데이터 전송은 완전히 멈추 며, 사용자에게는 계속 보낼 선택지가 없 습니다.
규칙을 Prevent 로 설정하기
규칙을 Prevent 로 올려 본격 차단에 들어가는 절차는 간단합니다.
- SmartConsole에서 Security Policies > Shared Policies > DLP 를 고르고 Open DLP Policy in SmartDashboard 를 클릭합니다. SmartDashboard가 열리며 DLP 탭을 보여 줍니다.
- 탐색 트리에서 Policy 를 클릭합니다.
- 바꿀 규칙의 Action 열에서 오른쪽 클릭 후 Prevent 를 고릅니다.
- Save 를 클릭하고 SmartDashboard를 닫습니다.
- SmartConsole에서 정책을 설치합니다.
Multi-Realm 인증 지원
DLP가 사용자를 인증하는 방법 중 하나는 SmartConsole에 구성된 Active Directory 서버에 질의 하는 것입니다. 그런데 정상 사용자가 서로 다른 AD 서버에 여러 계정 을 갖고 각 계정이 다른 암호를 쓴다면, DLP는 가장 먼저 응답한 AD 서버의 자격 증명 으로 사용자를 검증하기 때문에 인증에 실패할 수 있습니다. 이 오류를 줄이고 모든 AD 서버를 끊임없이 질의하는 부하도 낮추려면, DLP가 다음 두 경우에 어떤 AD 서버를 질의할지 를 정의할 수 있습니다.
- 사용자가 DLP 포털이나 UserCheck 에이전트에 자격 증명을 입력할 때
- DLP가 SMTP 트래픽에서 뽑아낸 이메일 주소로 사용자를 식별할 때
Database Tool(GuiDBEdit Tool)로 AD 서버 정의하기
- Database Tool (GuiDBEdit Tool) 을 엽니다.
- Tables 탭에서 Other > authentication_objects 를 엽니다.
- Object Name 열에서 DLPSenderRealm 을 고릅니다.
- Field Name 열에서 ldap_au 컨테이너를 더블 클릭합니다. Add/Edit Element 창이 열립니다.
- Object 목록에서 인증을 위해 DLP가 질의해야 하는 서버만 고릅니다. 예컨대 AD 서버가 열 대인 네트워크에서 실제로 질의해야 할 서버가 두 대뿐이라면, 그 두 대만 포함하도록 목록을 편집합니다.
- OK 를 클릭합니다.
- 데이터베이스를 저장하고 Database Tool(GuiDBEdit Tool)을 닫습니다.
- DLP가 켜진 Security Gateway에 갱신된 정책을 설치합니다.
DLP 관련 인증 문제 해결
Database Tool(GuiDBEdit Tool)에는 기본 인증 값을 정하는 속성이 여러 개 있어, DLP 관련 인증 문제를 해결하는 데 쓸 수 있습니다. 이 객체들은 Database Tool (GuiDBEdit Tool) > Tables > Other > authentication_objects 아래에 있습니다.
| 객체 | 설명 |
|---|---|
| DLPSenderRealm | DLP 포털과 UserCheck 에이전트의 인증을 제어합니다. Fetch_options > do_internal_fetch 는 기본 True 로, DLP가 SmartConsole의 사용자 계정에 대해 이메일을 조회한다는 뜻입니다. Fetch_options > do_ldap_fetch 도 기본 True 로, SmartConsole의 사용자 계정으로 식별에 실패하면 ldap_au 컨테이너 객체에 정의된 AD 서버를 질의한다는 뜻입니다. ldap_au 컨테이너는 AD 서버를 나타내는 객체들을 담습니다. 인증 문제 해결에 이 객체를 씁니다. |
| dlp_ldap_auth_settings | DLP가 Active Directory의 이메일 주소 속성을 질의 해 사용자를 식별하는 방식을 제어합니다. AD 이메일 조회 문제를 해결할 때 씁니다. CustomLoginAttr 문자열에 지정한 이메일 주소로 맞춤 LDAP 질의를 입력할 수 있습니다. 기본 질의는 다음과 같으며, 지정한 이메일 주소를 가진 사용자를 찾습니다. 질의를 다듬으려면 다른 AD 속성을 더하거나 기존 것을 바꿉니다. |
| dlp_internal_auth_settings | DLP가 SmartConsole에 정의된 내부 사용자 데이터베이스의 이메일 주소 속성 을 질의해 사용자를 식별하는 방식을 제어합니다. |
dlp_ldap_auth_settings 의 기본 질의는 이렇습니다.
|(mail=<<>>)(proxyAddresses=smtp:<<>>)