Zero Trust, VPN, TLS 검사는 서로 다른 일을 한다

조달 문서는 제로 트러스트, VPN, TLS 검사를 마치 같은 구매인 것처럼 다루지만, 각각은 나머지가 답할 수 없는 질문에 답한다. 터널은 보호된 경로를 만들고, 검사 게이트웨이는 자신이 종료할 수 있는 트래픽을 읽으며, 정책은 이름이 붙은 주체가 이름이 붙은 자원에 대해 이름이 붙은 작업을 수행할 수 있는지 결정한다. 그중 인가 결정인 것은 마지막 하나뿐이다. 제품이 앞의 두 가지를 완벽히 해내고도 진짜 질문을 열어 둘 수 있다.

세 가지 메커니즘, 세 가지 질문

터널은 트래픽이 어떻게 네트워크에 도달하는지에 답한다. 검사 게이트웨이는 TLS를 종료할 권한이 있는 지점에서 중간 장비가 무엇을 보고 무엇을 할 수 있는지에 답한다. 정책 엔진은 누가 어느 자원에 무엇을 할 수 있는지에 답하고, 그다음 그 답을 적용할 수 있는 시행 지점이 필요하다. NIST의 제로 트러스트 아키텍처는 자원을 중심에 두고 패킷이 어디서 왔는지로 신뢰를 추론하기를 거부한다.

그 틀은 라벨보다 만족시키기 어렵고, 검토에서 위조하기는 훨씬 더 어렵다. 또한 어떤 제품이 배치되었는지라는 질문을 어떤 결정이 무엇에 의해 시행되는지라는 질문으로 옮긴다.

결정이 실제로 적용되는 곳

요청 하나를 보자: 지원 엔지니어가 서비스 콘솔을 열고, 같은 스위치에 연결된 개인 장비가 단지 가까이 있다는 이유로 그 권한을 물려받아서는 안 된다. 허용되는 작업, 장치 조건, 그리고 그것을 시행하는 구성 요소를 적어 두라. 위치가 모든 것을 결정한다: 애플리케이션 게이트웨이, 서비스 프록시, 호스트 제어, 또는 조직이 실제로 지원하는 다른 경계다. 그 구성 요소가 무엇이든, 원격 시도와 현장 시도 모두의 경로에 있어야 한다.

VPN 진입점을 결코 지나지 않는 트래픽은 그곳에서 수행되는 검사가 아무리 철저하더라도 그 검사로 통제되지 않는다. 바로 그 하나의 틈이 제로 트러스트 다이어그램과 실제로 작동하는 배포 사이의 거리 대부분을 설명한다. 아키텍처를 그리기 전에 요청 경로를 그려라.

복호화는 인가가 아니다

가로채기는 좁은 검사 목적에 봉사하며 인증서, 신뢰 루트, 개인정보 검토, 그리고 그 아래에서 깨지는 애플리케이션이라는 자체 부담을 진다. 그중 어느 것도 제로 트러스트의 의미가 아니며, 어느 것도 정책 결정을 대체하지 않는다. 패킷 하나도 복호화하지 않고 사람을 인증하고 서비스를 인가하는 것은 얼마든지 가능하다. 복호화된 흐름은 그 안에 실린 작업에 사용자가 자격이 있었는지에 대해 아무 것도 말하지 않는다.

정책에 필요한 증거는 한 종류이고, 복호화는 그것이 아니다. 장치 상태는 신원, 자원 민감도, 맥락과 나란한 하나의 입력이며, 한 번 통과했다고 해서 그 장비에 네트워크의 나머지를 넘겨주는 것은 아니다. 둘을 섞으면 인가 질문이 인증서 프로젝트로 바뀐다.

게이트웨이가 경로 어디에도 없을 때

원격 게이트웨이를 거치지 않고 이동하는 것을 목록화하라: 로컬 세그먼트의 장비 사이 연결, 한 워크로드에서 다른 워크로드로의 호출, 클라우드 계정 안에서 직접 도달하는 엔드포인트다. 각 경로마다 오늘 실제로 배포할 수 있는 시행 방법을 지목하라. 에이전트를 올릴 수 없는 장비에는 여전히 명시적으로 지원되는 다른 통제가 필요하며, 에이전트가 나중에 온다고 가정하는 것은 지금 아무것도 닫지 않는다. 서비스 간 접근은 보통 또 하나의 오버레이 네트워크보다 워크로드 신원과 자원에 맞춰 작성된 검사에 더 잘 맞는다.

설계를 다이어그램이 아니라 행동으로 받아들여라: 어떤 작업이 허용되고 어떤 것이 거부되며, 각 답이 어디에서 시행되는지다. 구체적인 허용·거부 작업을 승인하고, 게이트웨이에 결코 도달하지 않는 로컬 경로 하나를 포함하라. 정책의 소유자가 누구인지, 어떻게 바뀌는지, 철회가 어떻게 작동하는지 기록하라.

이름표를 바꾼 터널은 여전히 터널이다. 정책이 결정하고, 무언가가 그것을 시행해야 한다.