제로 트러스트 운영 - 5단계: 정책 설계하기

이 블로그 시리즈는 3월에 올린 "제로 트러스트는 어렵지 않습니다... 실용적이라면"이라는 글에서 소개한 아이디어를 확장한 것입니다.

해당 게시물에서 제로 트러스트를 달성하기 위한 6가지 단계에 대해 설명했는데, 여기서는 그 중 하나인 정책 설계에 대해 자세히 설명하고자 합니다. 이 단계를 통해 조직의 규모에 관계없이 모든 마이크로세분화 실무자가 프로젝트를 더욱 성공적으로 수행하는 데 사용할 수 있는 견고한 프레임워크의 구현을 지원하는 방법을 보여드리겠습니다.

시작하기 전에 6단계에 대해 다시 한 번 정리해 보겠습니다:

5단계: 정책 설계

이 시리즈의 마지막 게시물에서는 "필요한 데이터 처방하기"에 대해 살펴보았습니다. 이 글에서 저는 다음과 같은 점을 지적했습니다:

"제로 트러스트의 가장 중요한 측면 중 하나이지만 충분히 다루어지지 않는 부분은 제로 트러스트를 효과적으로 구현하려면 정책을 수립하는 데 도움이 되는 컨텍스트 정보 또는 메타데이터에 대한 액세스에 의존한다는 점입니다. 따라서 워크로드 보호의 맥락에서 마이크로 세분화에 대해 이야기할 때 필요한 표준 트래픽 보고서 외부의 최소 메타데이터는 데이터센터 애플리케이션 및 환경의 맥락에서 워크로드를 설명합니다."

이 진술에 따라 우리에게 필요한 세 가지 핵심 데이터는 다음과 같습니다:

1. 보호하려는 워크로드에 대한 실시간 트래픽 이벤트.
2. 각 워크로드 및 연결에 대한 컨텍스트 데이터 - 여기에는 CMDB와 같은 기록 시스템에서 가져오는 워크로드와 관련된 메타데이터와 워크로드에서 직접 소싱되는 통신 프로세스의 세부 정보와 같은 정보도 포함됩니다. '
3. An 애플리케이션 종속성 맵 (항목 1과 2에서 파생됨)을 통해 애플리케이션 소유자나 세분화 실무자가 특정 애플리케이션의 업스트림 및 다운스트림 종속성을 빠르게 시각화할 수 있습니다.

모든 것을 종합하기

이제 정책을 구축할 준비가 거의 완료되었지만 목표를 다시 한 번 상기시켜 드리겠습니다:

• 워크로드를 보호하기 위해 마이크로 세분화 정책을 구축하려고 합니다.
• 이 정책은 제로 트러스트 원칙을 따라야 합니다.
• 따라서 구성하는 규칙은 비즈니스 기능을 수행하는 데 필요한 워크로드에 대한 액세스만 허용해야 합니다.

앞서 '필요'하다고 말씀드린 데이터에 이어서 정책을 구축하는 데 사용할 수 있는 몇 가지 트래픽 로그 항목의 예를 아래에서 확인할 수 있습니다:

트래픽 로그 연결 1:

• 출처: 10.0.0.1, 10.0.0.2
• 소스 컨텍스트: 웹 서버, 결제 애플리케이션, 프로덕션, 영국
• 목적지 192.168.0.1
• 목적지: 컨텍스트: DNS 응답자, DNS 인프라, 프로덕션, 영국 o 대상 프로세스: 명명됨
• 포트: 53
• 프로토콜: UDP
• 액션: 동작: 허용

트래픽 로그 연결 2:

• 출처: 10.0.0.1,10.0.0.2
• 소스 컨텍스트: 웹 서버, 결제 애플리케이션, 프로덕션, 영국
• 목적지 10.0.1.5,10.0.1.6,10.0.1.7
• 대상 컨텍스트: 앱 서버, 결제 애플리케이션, 프로덕션, 영국
• 대상 프로세스: tomcat
• 포트: 8080
• Protocol: 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
• Protocol: TCP
• 액션: 동작: 허용

트래픽 로그 연결 5:

• 출처: 10.1.2.1,10.1.2.2
• 소스 컨텍스트: 데이터베이스 서버, 결제 애플리케이션, 생산, 독일
• 목적지 10.0.1.5,10.0.1.6,10.0.1.7
• 대상 컨텍스트: 앱 서버, 결제 애플리케이션, 프로덕션, 영국
• 대상 프로세스: httpd
• 포트: 80
• Protocol: TCP
• 액션: 동작: 허용

이를 통해 애플리케이션 종속성 맵을 빠르게 도출할 수 있습니다.

지금까지는 괜찮습니다.

이제 애플리케이션 종속성 맵을 보고 실제로 어떤 플로우를 허용할지 결정할 수 있습니다. 예를 들어 애플리케이션에 대한 지식을 바탕으로 다음과 같은 흐름이 필요하다는 것을 알고 있습니다:

1. 웹 서버, 결제, 프로덕션, 영국 -> DNS 응답자, DNS 인프라, 프로덕션, 영국(53/udp)
2. 앱 서버, 결제, 프로덕션, 영국 -> DNS 응답자, DNS 인프라, 프로덕션, 영국(53/udp)
3. 웹 서버, 결제, 프로덕션, 영국 -> 앱 서버, 결제, 프로덕션, 영국(8080/tcp)

또한 다음 두 가지 흐름은 적절하지 않으므로 초기 규칙에 포함해서는 안 된다는 것을 알고 있습니다:

1. 웹 서버, 결제, 프로덕션, 독일 -> 앱 서버, 결제, 프로덕션, 영국(80/tcp)
2. DB 서버, 결제, 프로덕션, 독일 -> 앱 서버, 결제, 프로덕션, 영국 on 80/tcp

규칙을 작성하는 데 사용할 애플리케이션 종속성 맵은 다음과 같은 모양이 됩니다:

그렇다면 이러한 규칙을 실제로 어떻게 표현할 수 있을까요? 기존 방화벽에서는 소스 및 대상 IP 주소를 사용하여 이를 정의해야 했습니다. 하지만 이런 식으로 하면 이러한 흐름을 발견할 때 유용했던 풍부한 컨텍스트 정보가 완전히 제거되며, 더 나쁜 것은 규칙을 검토할 때 이 컨텍스트를 다시 삽입해야 한다는 것입니다. 또한 결제 앱에 추가 DNS 응답자 또는 새 앱 서버 또는 웹 서버를 추가하면 어떻게 되나요?

제로 트러스트 원칙, 즉 항상 최소 권한이 보장되는 정책을 구축하려고 한다는 점을 명심하세요. 적응형 보안 엔진이 백그라운드에서 마법처럼 작동하는 컨텍스트 기반 접근 방식은 바로 이 작업을 용이하게 합니다. 따라서 새 서버를 기존 컨텍스트에 통합하기 위해 정책이 확장되는 것처럼, 서버를 폐기할 때 정책도 축소되기를 원할 것입니다. 예를 들어 DNS 응답자 중 하나를 폐기하는 경우, 이전에 해당 응답자에 대한 액세스를 허용했던 모든 규칙을 업데이트하여 해당 액세스가 더 이상 불가능하도록 해야 합니다. 메타데이터를 사용하여 마이크로 세분화 정책을 정의한 다음, PCE가 특정 시점에 어떤 워크로드가 메타데이터와 일치하는지 파악하여 제로 트러스트 보안 상태를 유지하기 위해 각 워크로드에 적용해야 하는 실제 규칙을 계산하는 것이 바로 일루미오의 정책 컴퓨팅 엔진 (PCE)이 하는 일입니다. 컨텍스트가 변경될 때마다 PCE는 정책을 조정하고 워크로드에 업데이트를 알립니다.

이를 염두에 두고 제로 트러스트 정책은 다음 규칙으로 요약됩니다:

규칙 1:

• 출처: 웹 서버, 결제, 프로덕션, 영국
• 대상: 대상: DNS 응답자, DNS 인프라, 프로덕션, 영국
• 대상 서비스: 53/udp
• 대상 프로세스: 명명된

규칙 2:

• 출처: 앱 서버, 결제, 프로덕션, 영국
• 대상: 대상: DNS 응답자, DNS 인프라, 프로덕션, 영국
• 대상 서비스: 53/udp
• 대상 프로세스: 명명된

규칙 3:

• 출처: 웹 서버, 결제, 프로덕션, 영국
• 목적지 대상: 앱 서버, 결제, 프로덕션, 영국
• 대상 서비스: 8080/tcp
• 대상 프로세스: tomcat

여기까지입니다.

제로 트러스트 여정의 다음 단계로 나아갈 준비가 되셨나요? 마이크로 세분화를 통해 제로 트러스트 전략을 운영하는 방법에 대한 페이지를 방문하여 자세한 내용을 알아보세요.