.png)
제로 트러스트 운영 — 5단계: 정책 설계
이 블로그 시리즈는 제가 3월에 올린 글에서 소개한 아이디어를 확장한 것입니다.”제로 트러스트는 어렵지 않습니다... 실용적이라면.”
이 글에서는 제로 트러스트를 달성하기 위한 6가지 단계를 간략하게 설명했는데, 여기서는 그 중 하나인 정책 설계에 대해 자세히 설명하고자 합니다.이 단계가 조직의 규모에 관계없이 마이크로 세분화 실무자가 프로젝트를 더 성공적으로 수행하는 데 사용할 수 있는 견고한 프레임워크의 구현을 어떻게 지원할 수 있는지 보여 드리겠습니다.
시작하기 전에 6단계에 대해 다시 설명하겠습니다.
5단계: 정책 설계
에서 마지막 게시물 이 시리즈에서는 “필요한 데이터를 규정하는 방법”에 대해 살펴보았습니다.이 글에서 필자는 다음과 같은 점을 지적했습니다.
“제로 트러스트의 가장 중요한 측면 중 하나는 예상만큼 많은 적용 범위를 제공하지는 못한다는 것입니다. 제로 트러스트를 효과적으로 구현하려면 정책 수립에 도움이 되는 컨텍스트 정보 또는 메타데이터에 대한 액세스가 필요합니다. 따라서 워크로드 보호와 관련하여 마이크로 세그멘테이션에 대해 이야기할 때 필요한 표준 트래픽 보고서 이외의 최소 메타데이터는 데이터 센터 애플리케이션 및 환경 컨텍스트의 워크로드를 설명합니다.”
이 설명을 바탕으로 필요한 세 가지 주요 데이터 비트는 다음과 같습니다.
- 실시간 교통 이벤트 보호하려는 워크로드에 대해
- 각 워크로드 및 연결에 대한 컨텍스트 데이터 — 여기에는 CMDB와 같은 레코드 시스템에서 오는 워크로드와 관련된 메타데이터와 워크로드에서 직접 소싱되는 통신 프로세스의 세부 정보와 같은 정보가 포함됩니다.'
- An 애플리케이션 종속성 맵 (항목 1과 2에서 파생), 애플리케이션 소유자 또는 세그멘테이션 실무자가 특정 애플리케이션의 업스트림 및 다운스트림 종속성을 빠르게 시각화할 수 있습니다.
모든 것을 하나로 모으기
이제 정책을 수립할 준비가 거의 다 되었습니다. 이제 목표를 상기시켜 드리겠습니다.
- 워크로드를 보호하기 위한 마이크로 세분화 정책을 구축하고자 합니다.
- 이 정책이 제로 트러스트의 원칙을 따르기를 원합니다.
- 따라서 구성한 규칙은 비즈니스 기능을 수행하는 데 필요한 워크로드에 대한 액세스만 허용해야 합니다.
“필요”하다고 말한 데이터에 이어 아래에는 정책을 구축하는 데 사용할 수 있는 몇 가지 트래픽 로그 항목의 예가 나와 있습니다.
트래픽 로그 연결 1:
- 출처: 10.0.0.1, 10.0.0.2
- 소스 컨텍스트: 웹 서버, 결제 애플리케이션, 프로덕션, 영국
- 목적지: 192.168.0.1
- 대상: 컨텍스트: DNS 응답자, DNS 인프라, 프로덕션, UK o 대상 프로세스: 명명됨
- 포트: 53
- 프로토콜: UDP
- 조치: 허용
트래픽 로그 연결 2:
- 출처: 10.0.0.1,10.0.0.2
- 소스 컨텍스트: 웹 서버, 결제 애플리케이션, 프로덕션, 영국
- 목적지: 10.0.1.5,10.0.1.6,10.0.1.7
- 대상 컨텍스트: 앱 서버, 결제 애플리케이션, 프로덕션, 영국
- 대상 프로세스: 톰캣
- 포트: 8080
- 프로토콜: TCP
- 조치: 허용
트래픽 로그 연결 3:
- 출처: 10.0.1.5, 10.0.1.6,10.0.1.7
- 소스 컨텍스트: 앱 서버, 결제 애플리케이션, 프로덕션, 영국
- 목적지: 192.168.0.1
- 대상: 컨텍스트: DNS 응답자, DNS 인프라, 프로덕션, 영국
- 대상 프로세스: 이름이 지정됨
- 포트: 53
- 프로토콜: UDP
- 조치: 허용
트래픽 로그 연결 4:
- 출처: 10.1.0.1,10.1.0.2
- 소스 컨텍스트: 웹 서버, 결제 애플리케이션, 프로덕션, 독일
- 목적지: 10.0.1.5,10.0.1.6,10.0.1.7
- 대상 컨텍스트: 앱 서버, 결제 애플리케이션, 프로덕션, 영국
- 대상 프로세스: httpd
- 포트: 80
- 프로토콜: TCP
- 조치: 허용
트래픽 로그 연결 5:
- 출처: 10.1.2.1,10.1.2.2
- 소스 컨텍스트: 데이터베이스 서버, 결제 애플리케이션, 프로덕션, 독일
- 목적지: 10.0.1.5,10.0.1.6,10.0.1.7
- 대상 컨텍스트: 앱 서버, 결제 애플리케이션, 프로덕션, 영국
- 대상 프로세스: httpd
- 포트: 80
- 프로토콜: TCP
- 조치: 허용
이를 통해 애플리케이션 종속성 맵을 빠르게 도출할 수 있습니다.
지금까지는 너무 좋아요.
이제 애플리케이션 종속성 맵을 살펴보고 실제로 허용하려는 흐름을 결정할 수 있습니다.애플리케이션에 대한 지식을 바탕으로 볼 때 다음과 같은 필수 흐름이 있다는 것을 알 수 있습니다. 예를 들면 다음과 같습니다.
- 웹 서버, 결제, 프로덕션, 영국 -> DNS 응답자, DNS 인프라, 프로덕션, 영국 기반 53/udp
- 앱 서버, 결제, 프로덕션, 영국 -> DNS 응답자, DNS 인프라, 프로덕션, 영국 기반 53/udp
- 웹 서버, 결제, 프로덕션, 영국 -> 앱 서버, 결제, 프로덕션, 영국 (8080/tcp)
또한 다음 두 가지 흐름은 적절하지 않으므로 초기 규칙에 포함해서는 안 된다는 것도 알고 계실 것입니다.
- 웹 서버, 결제, 프로덕션, 독일 -> 앱 서버, 결제, 프로덕션, 영국 (80/tcp)
- 80/tcp의 DB 서버, 결제, 프로덕션, 독일 -> 앱 서버, 결제, 프로덕션, 영국
규칙을 작성하는 데 사용할 애플리케이션 종속성 맵은 다음과 같이 표시됩니다.
자, 이 규칙들을 실제로 어떻게 표현할까요? 기존 방화벽에서는 소스 및 대상 IP 주소를 사용하여 이러한 방화벽을 정의해야 했습니다.하지만 이 방법을 사용하면 이러한 흐름을 발견할 때 유용했던 풍부한 컨텍스트 정보가 완전히 제거되며, 더 나쁜 것은 규칙을 검토할 때 이 컨텍스트를 다시 삽입해야 한다는 뜻입니다.또한 결제 앱에 DNS Responder를 추가하거나 새 앱 서버 또는 웹 서버를 추가하면 어떻게 되나요?
제로 트러스트 원칙을 준수하는 정책, 즉 항상 최소 권한으로 유지하는 정책을 구축하려고 한다는 점을 명심하세요.백그라운드에서 마법처럼 작동하는 적응형 보안 엔진을 사용하는 컨텍스트 기반 접근 방식이 바로 이를 용이하게 합니다.따라서 새 서버를 기존 컨텍스트와 통합하도록 정책이 확장되는 것처럼 서버를 사용 중지할 때도 정책을 축소하는 것이 좋습니다.예를 들어 DNS Responder 중 하나를 사용 중지한 경우 이전에 DNS Responder에 대한 액세스/액세스를 허용했던 모든 규칙을 업데이트하여 이러한 액세스가 더 이상 가능하지 않도록 해야 합니다.이것이 바로 Illumio의 기능입니다. 정책 컴퓨팅 엔진 (PCE) 의 목적은 메타데이터를 사용하여 마이크로 세분화 정책을 정의하고, PCE는 특정 시점에 메타데이터와 일치하는 워크로드를 결정한 다음 제로 트러스트 보안 상태를 유지하기 위해 각 워크로드에 적용해야 하는 실제 규칙을 계산합니다.컨텍스트가 변경될 때마다 PCE는 정책을 조정하고 워크로드에 업데이트를 알립니다.
이를 염두에 두고 제로 트러스트 정책은 다음과 같은 규칙으로 요약됩니다.
규칙 1:
- 출처: 웹 서버, 결제, 프로덕션, 영국
- 대상: DNS 응답자, DNS 인프라, 프로덕션, 영국
- 데스티네이션 서비스: 53/udp
- 대상 프로세스: 이름이 지정됨
규칙 2:
- 출처: 앱 서버, 결제, 프로덕션, 영국
- 대상: DNS 응답자, DNS 인프라, 프로덕션, 영국
- 데스티네이션 서비스: 53/udp
- 대상 프로세스: 이름이 지정됨
규칙 3:
- 출처: 웹 서버, 결제, 프로덕션, 영국
- 대상: 앱 서버, 결제, 프로덕션, 영국
- 데스티네이션 서비스: 8080/tcp
- 대상 프로세스: 톰캣
그게 전부입니다.
제로 트러스트 여정의 다음 단계로 나아갈 준비가 되셨나요?방문하세요 우리 페이지 마이크로 세분화를 통해 제로 트러스트 전략을 운영하여 내부 정보를 파악하는 방법에 대해 알아보십시오.
