신형 코로나 바이러스 감염증의 확대에 따라 많은 분들이 집에서의 원격 작업을 강요당하고, "ZTNA"와 같은 왠지 이해할 수 있지만 구체적으로 무언가는 잘 모르는 말이 미디어에서 산견된다 같이 왔습니다. 나 개인도 고객으로부터 "ZTNA"는 무슨 일입니까? 이 기사는 Zero Trust Network Access를 대표적인 두 모델로 크게 나누어 가능한 한 간단하게 정리하려고 시도한 실험 기사입니다.

공통 목표

Zero Trust Network Access를 검토하는 배경은 VPN의 대체나 M&A에 의한 조직 개편 등, 여러가지 배경이 있다고 생각합니다만 몇개의 공통하는 의도가 있을까 생각합니다.

사내에서 사용하는 기밀성이 높은 Data를 취급하는 Application을 Internet에 공개하고 싶지 않다

User의 "Context"(예/Identity, 이용하고 있는 Device, 액세스하고 와 있는 Location)에 근거해 최소한의 권한으로 Application/Data에 액세스 시키고 싶다

액세스하고있는 Location의 IP Address 및 Device의 Mac Address와 같은 물리적 정보는 무시하고 논리 정보 만 기반으로 액세스하고 싶습니다.

Layer 3,4 레벨 (Network) 액세스가 아닌 Layer 7 레벨 (Application) 액세스를 실현하고 싶습니다.

Endpoint ~ Application까지 EndtoEnd의 암호화를 실현하고 싶다

Application/Data와의 통신 내용은 항상 감시하고 부정이라고 생각되는 통신은 동적으로 차단하고 싶다.

사용자가 언제 어디서나 Application/Data에 액세스하더라도 일관된 경험을 제공하고 싶습니다.

모델 1 - Endpoint-initiated

Endpoint Device에서 플로우를 시작하는 모델로 Cloud Security Alliance가 제창하고 있는 "Software Defined Perimeter"가 이 모델에 해당합니다. Endpoint Device에 설치된 Agent가 ZTNA Controller에 인증 요청을 보내 흐름을 시작합니다.

이 모델은 Endpoint Device에 Agent가 설치되어 있다고 가정하므로 Endpoint Device Management Solution에서 항상 관리해야 합니다. 또한 ZTNA Gateway에서 Application으로의 통신은 인바운드가 되므로, 사이에 Firewall이 존재하는 경우에는 Firewall의 보안 정책으로 인바운드 통신을 허가할 필요가 있습니다.

모델 2 - Service-initiated

Application에서 플로우를 시작하는 모델로 Google사가 제창하고 있는 "BeyondCorp"가 이 모델에 해당합니다. ZTNA Connector는 Application과 동일한 데이터 센터에 있다고 가정하고, ZTNA Connector와 ZTNA Broker 간의 통신은 아웃 바운드 전용이므로 Endpoint-initiated 모델의 Firewall 보안 정책을 변경할 필요가 없습니다. 됩니다. 또한 Endpoint Device에 Agent를 설치할 필요가 없기 때문에 Endpoint Device Management Solution의 도입이나 운용도 불필요하고 Endpoint Device도 회사 지급뿐만 아니라 개인의 디바이스에도 적용할 수 있습니다.

이 모델은 Agent를 설치하지 않으므로 Http/Https 프로토콜로 액세스할 수 있는 Application이 전제가 됩니다. 터널형 Application(예/SSH Server, RDP Server)에는 적용할 수 없기 때문에 터널형 Application의 이용이 필요한 경우는 Endpoint-initiated 모델과의 병용이 됩니다.

참고

Market Guide for Zero Trust Network Access
Implementing a Zero Trust Architecture Project Description