제로 트러스트 정책을 배포하는 데 필요한 것

이 시리즈에서는 다음과 같이 논의했습니다. 정책 디스커버리 과 정책 작성 지금까지.구현할 정책이 있으면 이를 계산하여 규칙으로 전환하고 집행 지점에 배포해야 합니다.결국, 제로 트러스트 정책은 도달한 곳에서만 작동할 수 있습니다!이 정책을 가능한 한 많은 곳에서 효과적으로 적용할 수 있도록 합시다.

정책을 규칙으로 자동화

사람이 읽을 수 있는 정책 (레이블 또는 메타데이터 기반) 을 시행된 제로 트러스트 세그멘테이션 정책으로 전환하는 첫 번째 단계는 이를 인프라가 이해할 수 있는 규칙으로 변환하는 것입니다.지금까지 IP 주소를 사용하지 않고 정책을 지정하는 것이 사람에게 얼마나 중요한지 논의했지만, 모든 적용 지점에서는 IP 주소를 필요로 합니다!정책 계산 기능은 중요한 역할을 합니다.

라벨에 제로 트러스트 세그멘테이션 정책을 적용한다는 것은 애플리케이션 인스턴스를 구동하는 동일한 자동화가 세그멘테이션 정책을 주도할 수 있다는 것을 의미합니다.IP 주소나 유사한 애플리케이션 서비스의 수를 알 필요 없이 애플리케이션 자동화는 “이름을 명시하는 것”만으로 올바른 정책을 얻을 수 있습니다.사람이 읽을 수 있는 정책을 실행 가능한 규칙으로 자동 전환할 수 있게 되면 애플리케이션 구성 요소 자체와 마찬가지로 세그멘테이션도 하나의 서비스가 됩니다.

역동적이고 연속적으로 만드세요

정책 계산은 동적이고 연속적이어야 합니다.최신 데이터 센터 또는 클라우드 배포에서는 자동화가 애플리케이션을 지속적으로 조정합니다.즉, IP 주소가 변경되고, 인스턴스가 생성되고, 작업을 수행하고, 제거됩니다.SaaS 서비스 컨트롤러는 크기를 알 수 없는 클러스터의 새 IP 주소로 부하를 원활하게 이동합니다.즉, 모든 규칙 세트에 사용되는 IP 주소는 인프라가 발전함에 따라 업데이트되어야 합니다.정의된 정책을 모든 적용 지점에서 정확하게 유지하려면 정책 계산 및 배포가 지속적이고 거의 즉각적으로 이루어져야 합니다.

기존 단속 지점 사용

제로 트러스트 세그멘테이션 정책은 운영 장소의 수에 따라 결정됩니다.다행스럽게도 필요한 단속 포인트는 이미 모두 보유하고 있습니다!현대의 모든 운영 체제에는 완벽하게 유용한 스테이트풀 방화벽이 내장되어 있습니다.Linux 기반 시스템인 경우 IP 테이블 또는 NetFilter이고 Windows 기반 인스턴스인 경우 Windows 필터링 플랫폼입니다.AIX, 솔라리스, 심지어 IBM System Z 메인프레임에도 비슷한 OS 기반 방화벽이 존재합니다!Cisco와 Arista의 네트워크 스위치는 F5 네트웍스의 로드 밸런서와 마찬가지로 ACL을 사용합니다.거의 모든 네트워크 연결 장치가 세그멘테이션 명령을 수행할 수 있다고 해도 과언이 아닙니다.

따라서 좋은 마이크로 세분화 솔루션이라면 이러한 적용 지점을 최대한 많이 사용해야 합니다.결국 커널 방화벽이 현존하는 코드 중 가장 안정적이고 성능이 뛰어난 코드인데 왜 벤더 에이전트를 통해 조치를 취해야 할까요?기존 네트워크와 클라우드 네트워크 및 방화벽 인스턴스를 프로그래밍할 수 있는 솔루션을 찾으십시오.임베디드 시스템과 OT 디바이스에는 방화벽이 내장되어 있지 않으며 벤더 에이전트가 필요하지 않으므로 사용 가능한 모든 적용 지점을 사용하는 솔루션이 필요합니다.

성능 및 규모 고려 사항

평가 시 성능 및 규모를 고려해야 합니다. 제로 트러스트 세그멘테이션 솔루션.스위치나 라우터와 같은 하드웨어 포워딩 디바이스와 마찬가지로 아키텍처 선택도 중요합니다.개념 증명 과정에서 단일 정책을 계산하는 것은 그리 어렵지 않습니다.

하지만 40,000개의 컴퓨팅 인스턴스가 15분 간격으로 제거되고 교체되는 완전 자동화된 데이터 센터가 있으면 어떻게 될까요? 전 세계 데이터 센터 단지를 휩쓸고 지나가는 파도 속에서 말이죠.갑자기 계산 시간이 중요해집니다.

자동화된 애플리케이션 환경에서 올바른 정책을 유지하는 유일한 방법은 자동화를 따라잡는 것입니다.하지만 계산이 완료된 다음에도 정책을 배포한 다음 적용해야 합니다.이 컨버전스 이벤트는 라우팅 테이블을 통합하는 하드웨어 라우터와 다르지 않습니다.

고려 중인 솔루션의 정책 배포 아키텍처는 얼마나 효과적입니까? 데이터 센터의 절반에 장애가 발생하여 대규모 재해 복구 트래픽 경로가 변경되는 경우 애플리케이션 가용성을 유지하기 위해 정책 업데이트를 적시에 배포하는 것이 갑자기 매우 중요해질 것입니다.

주요 공급업체는 최대 500,000개의 객체에 대해 완전한 제로 트러스트 정책을 통합한 경험이 있습니다.고려 중인 공급업체가 다중 위치 장애 조치 및 동시 정책 통합에 대한 주장을 입증할 수 있는지 확인하십시오.

정의된 정책을 계산하여 배포하는 것은 마이크로 세그멘테이션 솔루션에 가장 큰 성능 부담을 안겨줍니다.어떤 솔루션이든 단순한 평가 환경에서 작동할 수 있습니다.그러나 까다로운 애플리케이션 자동화 재구성은 말할 것도 없고 네트워크 파티션 이벤트, 장애 복구 및 재해 복구 시나리오를 견딜 수 있는 기능을 갖춘 솔루션은 엔터프라이즈급 솔루션뿐입니다.

효과적인 정책 배포 기능을 갖추려면 공급업체 솔루션이 사람이 읽을 수 있는 정책을 규칙으로 자동화하는 방법을 완전히 이해해야 합니다.정책은 가능한 한 많은 기존 적용 지점에 배포해야 하며, 독점 공급업체 솔루션보다 성숙하고 안정적인 커널 방화벽을 선호하여 가능하면 많이 배포해야 합니다.지속적이고 동적인 정책 계산 및 배포를 배포하면 제로 트러스트 세그멘테이션이 사용 가능한 애플리케이션 서비스가 되며 기존 애플리케이션 자동화를 통해 완전히 자동화할 수 있습니다.

다음 주에는 제로 트러스트 세그멘테이션 정책을 시행하기 위해 무엇이 필요한지 알아보는 마지막 기사에 참여하세요.