Jamf Connect ZTNA에 대한 네트워크 엔지니어 가이드

대상 및 목적

이 문서는 네트워킹 및 VPN 기술의 기본에 경험이 있는 네트워크 및 보안 IT 관리자를 대상으로 합니다.

차세대 보안 및 네트워킹 제품으로서 Jamf Connect ZTNA는 기존 VPN과 상당히 다르게 동작합니다. 이 가이드는 관리자가 제품의 설계 기본을 이해하여 계획, 배포, 유지보수 및 문제 해결에 도움이 되도록 하기 위한 것입니다.

이 가이드는 Jamf의 ZTNA 제품을 구성하는 방법을 설명하는 제품 문서가 아니라 제품이 작동하는 방식을 설명하여 환경에서 제품의 동작을 예측하고 이해할 수 있습니다. 문서를 찾으려면 Jamf Connect ZTNA 설명서에서 찾을 수 있거나, 제품의 기술 비디오 개요를 먼저 보려면 JNUC 2021 Jamf ZTNA Deep Dive 프레젠테이션을 시청하세요.

조직 내에서 프로덕션 용량으로 Jamf Connect ZTNA를 사용하는 경우 이 가이드를 읽고 북마크하기를 강력히 권장합니다.

개요

Jamf의 ZTNA 제품은 Cloud Security Alliance (CSA)의 Software Defined Perimeter (SDP) architecture를 준수하도록 처음부터 설계되었습니다. 이 아키텍처는 Zero Trust Network Access (ZTNA)의 더 넓은 산업 정의의 많은 테넌트를 구현하며, 여기에는 최소 권한 액세스, 역할 기반 액세스, 다중 요소 신원 확인, 기기 신뢰 등이 포함됩니다. 이 제품은 원래 Wandera에 의해 구축되었으며 2021년 7월에 Jamf 보안 플랫폼으로 인수되었습니다.

따라서 Jamf Connect ZTNA는 기존 VPN의 많은 결과 (예: VPN 인터페이스가 온라인 상태가 되면 원격 리소스가 이용 가능해짐)를 공유하지만, 이러한 결과를 지원하는 실제 메커니즘은 완전히 다릅니다. 이는 Connect ZTNA가 IP 주소 지정, DNS 및 클라우드 기술을 활용하여 기존 VPN 아키텍처와 비교하여 성능, 확장성 및 보안에서 단계적 변화인 클라이언트-서버 라우팅을 제공하는 방식의 결과입니다.

따라서 Jamf SDP와 기존 VPN 사이의 가장 중요하고 중요한 차이점 중 하나부터 시작하겠습니다: 연결 중개 대 라우팅.

연결 중개

시작해봅시다: VPN이 어떻게 작동하는지에 대해 알고 있고 가정하는 모든 것을 잠깐 옆으로 치워두세요. 최종 패킷 라우팅이 결국 기존 VPN처럼 보이지만 연결 프로세스에는 완전히 새로운 처리 요소가 있습니다.

기존 VPN

기기가 기존 VPN에 연결하면 온프레미스 또는 클라우드에 있을 수 있고 스스로 또는 서비스 공급자가 운영할 수 있는 VPN 집선장치와 보안 터널을 생성합니다.

Traditional VPN Traffic Flow

집선장치의 위치나 운영자와 관계없이 일반적인 동작은 동일합니다:

기기는 VPN 집선장치로 인증하고 보안 터널이 설정되어 엔드포인트에서 가상 네트워크 인터페이스를 생성합니다.
기기는 해당 터널의 수명 동안 유효한 집선장치에서 동적으로 IP 주소가 할당됩니다 (때로는 DHCP 바인딩에 의해 "정적으로" 재할당될 수 있습니다).
가상 네트워크 인터페이스에 대해 하나 이상의 경로가 구성되어 VPN을 통해 라우팅되어야 하는 조직이 소유한 네트워크 서브넷을 정의합니다. 완전 터널 VPN은 기기의 모든 트래픽을 집선장치로 라우팅하여 모든 로컬 네트워크 액세스를 제거합니다.
DNS 이름 서버가 기기에 구성되며, 일반적으로 VPN의 다른 쪽에 있는 고객 네트워크에 있습니다.
앱이 리소스에 요청을 할 때마다 DNS는 IP 주소로 확인되고 트래픽은 VPN의 가상 인터페이스의 경로 중 하나에 패킷의 IP 주소가 속하는 경우 VPN을 통해 라우팅됩니다.
VPN 집선장치는 패킷을 고객 네트워크로 라우팅합니다. 일부 경우에 방화벽 액세스 제어 목록이 네트워크 전체에 구현되어 액세스 제어를 제한합니다.

이것은 작동하지만, 이 아키텍처의 주요 보안 문제는 라우팅된 서브넷 내의 모든 리소스가 본질적으로 기기에서 사용 가능하다는 것입니다. 이를 통해 공격자가 엔드포인트를 악용하고 VPN 연결을 사용하여 방화벽 "뒤에" 있는 서버의 약점을 찾을 수 있습니다. 이러한 서버가 완전히 패치되지 않거나 다른 방식으로 잠겨 있지 않을 수 있습니다.

물론 네트워크 전체에 액세스 제어 규칙을 구현할 수 있지만 이는 어렵고 오류가 발생하기 쉽습니다. 일반적으로 이러한 규칙은 IP 주소 계층에서 관리해야 하므로 취약하고 변경하기 위험합니다. 이는 새로운 미션 크리티컬 애플리케이션의 필요한 변경 속도를 빠르게 앞지르는 네트워크 수준의 보안 정책을 초래합니다. 또한 사용자 신원과 연결을 긴밀하게 연결하는 방식으로 모니터링 및 감사 보고를 수행할 수 있는 좋은 방법이 없습니다. 그래서 대부분의 조직은 무엇을 합니까? 오픈 상태로 두고 인시던트가 발생했을 때 보고를 연결합니다.

그럼 이런 문제들을 어떻게 해결할까요? SDP와 "중개된" 네트워크 연결을 입력하세요.

SDP: 연결 중개

Jamf의 ZTNA가 엔드포인트 기기에 연결되면 몇 가지 중요한 차이점이 즉시 나타납니다:

상태 없는 Wireguard 네트워크 인터페이스는 매우 가벼운 초기 핸드셰이크 후에 엔드포인트에 생성됩니다. 참고: ZTNA 배포에 따라 Apple 기기는 Wireguard 대신 HTTP/3을 사용할 수 있습니다.
간단한 IPv6 경로 세트는 인터페이스 설정 대역 외에서 협상되고 VPN 네트워크 인터페이스에 구성됩니다. 기본적으로 이러한 경로는 고객에게 속하지 않지만 Jamf (fd53:1c5a::/32, fddd:dddd::/128)가 관리하는 예약된 IPv6 범위입니다. VPN 네트워크 인터페이스도 대역 외에서 협상된 정적 IPv6 주소가 할당됩니다. 기본적으로 VPN 네트워크 인터페이스에 할당된 IPv4 주소 또는 경로가 없습니다!
Jamf 관리 DNS 이름 서버 fddd:dddd::가 기기에 구성됩니다.

어라. 뭐라고? 네, 맞습니다: 엔터프라이즈측 IP 주소, 서브넷 또는 DNS 이름 서버가 최종 사용자 기기의 라우팅 테이블에 게시되지 않습니다. IPv4 주소도 *없습니다! 이는 SDP 연결 중개의 핵심 구성 요소이므로 엔드포인트 및 사용자는 내부 네트워크 토폴로지를 인식하지 못하고 시도해도 내부 네트워크 IP에 연결할 수 없습니다.

그렇다면 기기의 앱이 내부 IPv4 서브넷 중 하나에 있는 서버의 앱에 연결하려면 어떻게 됩니까? 연결 중개가 들어오고 DNS, NAT 및 Jamf 라우팅 기술의 마법이 용이하게 합니다.

정보: Direct IP 및 서브넷 액세스에 대한 참고

엔드포인트에 내부 서브넷을 게시하지 않는 보안 이점 외에도 IPv4 주소도 마찬가지로 사용자가 회사 관리 비 네트워크 (예: 집, 커피숍 등)에서 경험할 수 있는 네트워크 세그먼트 오버랩을 피하는 데 도움이 됩니다. 이는 어디서나 쉽게 원격으로 작업할 수 있도록 하는 데 중요합니다.

그러나 IPv4 주소 또는 서브넷을 직접 사용할 수 있어야 하고 DNS 기반 연결 중개에 의존할 수 없는 특정 사용 사례가 있습니다. 이러한 상황의 경우 Connect ZTNA는 "Direct IP" 액세스 구성을 지원합니다. 자세한 내용은 이 가이드의 "중개된 연결 예외" 섹션을 참조하세요.

사용자가 app.acmeinc.com에 연결하려고 하고 내부 IP 주소 10.0.1.22에 있다고 가정해봅시다. 다음은 Jamf ZTNA 사용 기기에서 해당 연결을 용이하게 하기 위해 발생하는 일입니다 (아래 예는 대상 앱으로의 TCP 연결을 보여 주지만 UDP 연결에도 유사한 흐름이 사용됩니다):

Jamf Private Access Brokered Traffic Flow

사용자는 선택한 브라우저 또는 기본 앱에서 app.acmeinc.com로의 연결을 시작합니다.
앱은 OS에 해당 호스트 이름을 IP 주소로 확인하도록 요청합니다. Jamf Connect ZTNA가 활성화되면 사용할 DNS 이름 서버는 fddd:dddd::이며, Jamf Connect ZTNA 정책 엔진에 연결된 가상 IPv6 주소입니다.
OS는 app.acmeinc.com에 대해 fddd:dddd::에 대한 일련의 DNS 요청을 수행합니다. 여기에는 A, AAAA 및 HTTPS 유형이 포함됩니다.
Jamf Connect ZTNA DNS 이름 서버는 FQDN의 업스트림 조회를 수행하고, 먼저 Custom DNS Zone이 도메인에 대해 구성되었는지 확인합니다 (이 예에서 *.acmeinc.com은 10.0.1.10를 권위 있는 이름 서버로). Custom DNS Zone을 찾을 수 없으면 서비스는 공개 업스트림 DNS 리졸버의 일련을 사용합니다.
1. 참고: 서비스는 업스트림 A 레코드만 요청하며 이때 AAAA 및 HTTPS는 무시됩니다. 이는 IPv6을 통해서만 도달 가능한 서버에 대해서만 잠재적 문제이며, 이는 오늘날 대부분의 공용 및 프라이빗 네트워크에서 매우 드뭅니다.
권위 있는 서버에서 A DNS 응답을 받으면 (이 경우 Custom DNS Zone 구성을 통해 고객의 내부 이름 서버에서 A 10.0.1.22), Jamf Connect ZTNA DNS 이름 서버는 리소스를 요청하는 사용자 및 기기를 식별하고 app.acmeinc.com을 트래픽 일치 기준으로 정의하는 일치 액세스 정책을 찾습니다.
1. 이 액세스 정책은 사용자의 그룹 멤버십 및 기기 상태를 평가하여 리소스에 대한 액세스를 부여할지 여부를 결정합니다.
2. 정책에 정의된 것도 Jamf 클라우드를 통해 트래픽을 라우팅하는 방법입니다. 이 경우 고객이 IPSec 인터커넥트 게이트웨이를 구성하여 이 내부 앱에 도달하기 위한 프라이빗 경로 역할을 한다고 가정합니다.
액세스 정책을 찾았고 기기 및 사용자가 리소스에 연결하는 데 필요한 모든 기준을 통과하면, Jamf Connect ZTNA 라우팅 구조가 임시 IPv6 주소를 예약된 IPv6 서브넷에 할당하는 "클라우드 흐름 매핑"을 생성합니다 (예: fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22).
1. 이 흐름은 연결당 고유하며 사용자이며 수명을 벗어나거나 다른 기기에서 재사용할 수 없습니다.
이 IPv6 주소 fd53:1c5a::aaaa:bbbb는 엔드포인트에 AAAA DNS 응답으로 반환됩니다.
1. 서비스는 기본적으로 A 또는 HTTPS 응답을 반환하지 않습니다! 이는 dig과 같은 유틸리티를 사용하여 DNS 응답을 문제 해결할 때 유념해야 할 매우 중요합니다!
fd53:1c5a::aaaa:bbbb에 대한 새 소켓이 생성되고, 해당 IP가 Jamf Connect ZTNA의 VPN 네트워크 인터페이스에 할당된 서브넷 내에 있기 때문에 해당 소켓 및 모든 후속 패킷이 Wireguard 터널을 통해 Jamf Security Cloud로 전달됩니다.
패킷을 받으면 Jamf Connect ZTNA 라우팅 구조는 추가 보안 검사를 수행한 다음 대상 IPv6 주소에 대한 클라우드 흐름 매핑을 찾습니다.
Jamf Connect ZTNA 라우팅 구조는 글로벌 클라우드 백본을 통해 패킷을 라우팅하여 최종적으로 액세스 정책에 의해 정의된 IPSec 인터커넥트에 도달합니다. 패킷이 IPSec 터널을 통해 전달되기 전에 클라우드 흐름 매핑에 따라 NAT64 변환이 발생하여 원래 IPv4 주소 (10.0.1.22)를 대상 IP로 하는 패킷을 생성합니다.
1. 패킷의 소스 IP는 IPSec 구성의 "Jamf Security Cloud Side"에서 정의한 서브넷 내의 IP 주소로 설정됩니다. 고객 네트워크로 전송된 모든 트래픽은 이 서브넷 내의 가상 임의 IP에서 나타납니다.
2. 클라우드 기반 NAT 출력에 지역 데이터 센터를 사용하는 경우 소스 IP는 해당 데이터 센터의 글로벌 IP 주소에 걸쳐 동적으로 로드 밸런싱됩니다.
일치하는 모든 중개된 연결이 사용자, 기기 및 애플리케이션에 대해 기록되며 RADAR의 Access Event Log 및 기타 보고서에서 검토할 수 있습니다.

보시다시피 DNS, IP 라우팅 및 NAT의 긴밀한 연결이 있으며 기존 VPN 구성에서 기본적으로 존재하지 않습니다.

그럼에도 불구하고 Jamf Connect ZTNA는 모든 라우팅이 계층 3에서 기본적으로 발생하므로 매우 효율적으로 패킷을 처리하여 VoIP 및 비디오와 같은 실시간 애플리케이션을 쉽게 지원합니다. 모든 캡슐화가 초고속의 효율적인 Wireguard 또는 HTTP/3 UDP 캡슐화 프로토콜을 사용하므로 손실이 많은 네트워크의 TCP/mTLS 기반 터널 내에서 라우팅되는 TCP 연결에서 발생하는 일반적인 전송 프로토콜 "중단"이 없습니다.

정보: SDP, VPN 및 엔드-투-엔드 앱 암호화

Jamf Connect ZTNA는 최신 패킷 캡슐화 및 암호화 기술을 사용하여 빠르고 동적인 소프트웨어 정의 네트워킹 기능을 제공하도록 엔지니어링되어 이미 전송 중인 트래픽을 암호화할 수 있습니다.

그러나 이미 전송 중인 트래픽을 암호화하는 모든 VPN 기술과 마찬가지로 Jamf가 클라이언트 애플리케이션에서 서버 애플리케이션으로의 진정한 엔드-투-엔드 암호화를 제공할 수 없습니다.

따라서 민감한 데이터를 포함하는 모든 앱의 경우 항상 HTTPS 또는 TLS와 같은 앱 수준 암호화 기술을 사용하도록 이러한 애플리케이션을 구성해야 합니다. 이는 이제 모든 애플리케이션의 표준 사례입니다. 이는 Jamf 또는 고객 네트워크 전체의 모든 지점에서 권한이 없는 중개자가 액세스할 수 없도록 하는 유일한 방법입니다.

이 연결 중개 기술은 Jamf ZTNA 플랫폼에서 엔터프라이즈급 성능 및 확장으로 작동하는 것으로 입증되었습니다. 모든 최신 운영 체제는 기본적으로 IPv6를 지원합니다 (기기에 IPv4 전용 네트워크 연결이 있더라도) 및 대부분의 애플리케이션과 사용자가 IPv6를 지원하고 모든 연결에 DNS를 사용합니다.

그렇지 않은 경우를 제외하고는... 다른 경우에 Connect ZTNA를 통해 작동하도록 특수 구성을 정의해야 할 것입니다.

가용성 및 장애 조치

Jamf ZTNA는 네트워크 분할과 기기가 Jamf Security Cloud에 연결할 수 없음을 고려하여 아키텍처되어 있습니다. 다양한 중복 방법을 사용하여 수행합니다:

Dead Gateway Detection

Jamf Trust는 보안되지 않은 캡티브 포털로 인해 발생하는 위험하거나 불안정한 연결을 감지할 수 있습니다. 이러한 캡티브 포털은 트래픽을 가로채 연결 문제를 생성할 수 있습니다.

Dead Gateway Detection (DGD)을 사용하면 Jamf Trust 앱은 최종 사용자 기기에서 현재 연결 상태에 대한 알림을 제공할 수 있습니다. DGD는 캡티브 포털 및 웹 연결 확인과 같은 일반 연결 확인을 사용하고 Dead Gateway를 감지하기 위해 Zero Trust Network Access (ZTNA) 엔드포인트 해상도를 사용합니다. DGD를 직접 지원하기 위해 Jamf Trust의 바이패스 모드는 VPN 터널을 통해 전달되는 위험한 트래픽을 방지합니다. 이를 통해 최종 사용자는 VPN이나 작업 애플리케이션 없이 인터넷을 안전하게 검색할 수 있습니다.

로드 밸런싱 및 지역 입구 위치

라이브 연결을 감지한 후 Jamf Trust는 로컬 네트워크의 DNS 공급자 (일반적으로 DHCP에서 제공)에서 결정한 로컬 IP 엔드포인트를 요청합니다. 이러한 엔드포인트에 대한 TTL (Time-to-Live)은 60초입니다. 이러한 엔드포인트 중 하나가 사용 불가능해지면 60초 내에 풀에서 제거됩니다. 이는 최대 60초의 RTO (Recovery Time Objective)로 이어지지만 Dead Gateway Detection과 쌍을 이루면 단일 엔드포인트 장애로부터의 복구는 즉각적입니다.

로컬 정책 캐싱

SDP: 연결 중개에 설명된 대로 Jamf는 로컬 DNS 대체를 사용하여 기기 트래픽을 적절한 리소스로 다시 라우팅합니다. 이러한 로컬 DNS 레코드도 60초의 TTL을 가집니다. 정책 변경이 시행되면 (위험 기반 정책으로 인해 자동으로 또는 관리 변경으로부터) 정책 업데이트가 기기에서 로컬로 표시되는 최대 기간은 60초입니다. 참고: 정책은 기기에 로컬로 지속되지 않지만 DNS 캐싱으로 인해 정책 업데이트가 60초마다 푸시되는 것처럼 보일 수 있습니다.

중개된 연결 예외

대부분의 앱 및 서비스는 중개된 연결 접근 방식을 통해 기본적으로 및 특별한 고려 없이 작동하지만 중개된 연결 접근 방식으로 지원되지 않는 연결이 필요한 특정 사용 사례 및 애플리케이션 클래스가 있습니다.

DNS를 사용하지 않는 앱/서비스

위에서 배웠듯이 앱이나 사용자가 FQDN을 사용하여 리소스에 연결하지 않으면 그냥 작동하지 않습니다.

DNS 요청 없이는 중개된 IPv6 주소가 발급되지 않기 때문입니다. 기기의 라우팅 테이블에 대상의 IPv4 주소가 추가되지 않기 때문에 해당 패킷은 단순히 인터넷으로 이동하여 다시 돌아오지 않습니다.

집계 측면에서는 드물지만 FQDN/DNS를 포함하지 않는 연결 시나리오는 다음의 경우가 일반적입니다:

IT 관리자가 네트워크 장비에 직접 연결하려고 시도
개발자가 DNS에 등록되지 않은 가상 인스턴스의 새 인스턴스에 연결
FQDN이 아닌 IPv4 주소를 통해 연결하는 기존 애플리케이션

이러한 이유로 Jamf Connect ZTNA는 앱의 액세스 정책에서 "Direct IPs and Subnets"의 선택적 정의를 지원합니다.

오류: Direct IP 및 서브넷 예외의 보안

절대적으로 리소스에 액세스해야 하는 사용자 및 앱에만 IP 기반 액세스를 구성하는 것을 권장합니다. 그리고 구성하는 경우 정의하는 서브넷은 최대한 좁게 범위가 지정됩니다 (예: 10.0.1.0/29 vs 10.0.0.0/16).

이는 이러한 광범위한 수준에서 라우팅을 설정하면 브로커 기반 연결 모델의 많은 보안 이점을 효과적으로 무효화하고 기존 VPN의 동작으로 되돌아가기 때문입니다. 이는 기존 VPN에 영향을 미치는 동일한 유형의 공격으로 인해 조직을 취약하게 만듭니다.

이러한 방식으로 하나 이상의 IP 주소를 구성할 때 정의된 CIDR 서브넷은 해당 정책에 할당된 기기의 경로 테이블에 게시됩니다. 이는 기본 fd53 IPv6 서브넷 외에도 VPN 네트워크 인터페이스가 모든 적용 가능한 액세스 정책에 정의된 모든 IPv4 서브넷을 포함한다는 의미입니다.

이러한 IP 주소를 정의하여 액세스 정책을 저장한 후 이러한 변경 사항이 모든 기기에 전파되는 데 최대 30분이 소요될 수 있습니다. Jamf Connect ZTNA를 사용 및 사용 중지하면 이러한 정책의 즉시 업데이트가 트리거됩니다.

이제 App 액세스 정책에 10.0.1.22가 추가되었다고 가정하면 Jamf ZTNA 최종 사용자는 http://10.0.1.22 또는 ping 10.0.1.22를 통해 연결할 수 있습니다.

연결이 DNS를 통해 중개되지 않더라도 리소스에 대한 액세스 기능은 여전히 액세스 정책에 정의된 모든 조건을 따릅니다.

IPv6을 지원하지 않지만 FQDN을 사용하는 앱

어떤 이유로든 IPv6을 좋아하지 않는 애플리케이션의 부분집합이 있습니다:

일부 최신 애플리케이션에는 IPv6과 호환되지 않는 복잡한/사용자 정의 네트워킹 스택이 있습니다 (예: macOS용 Docker).
IPv6이 존재한다는 것을 모르고 AAAA 응답을 활용할 수 없으며 A 응답이 없으면 실패하는 기존 애플리케이션.

이러한 애플리케이션의 경우 액세스 정책을 "Optimized" 대신 "Compatible" 라우팅을 사용하도록 구성할 수 있습니다. 이렇게 하면 다음이 발생합니다:

액세스 정책이 적용되는 엔드포인트는 이런 방식으로 구성된 하나 이상의 액세스 정책에서 사용되는 Jamf Cloud 고유 IPv4 서브넷이 푸시됩니다.
- 이 동일한 범위는 하나 이상의 액세스 정책에서 사용됩니다.
- 이 새로운 경로가 모든 기기에 게시되거나 VPN이 다시 부팅되어 즉시 업데이트가 트리거되는 데 최대 10분이 소요될 수 있습니다.
액세스 정책이 적용되는 엔드포인트는 VPN 네트워크 인터페이스에 IPv4 주소가 할당됩니다.
액세스 정책이 일치하는 DNS 요청을 받으면 "Compatible" 모드로 설정하면 AAAA 응답이 비어 있지만 "Optimized"를 선택할 때 사용되는 IPv6 대신 IPv4 클라우드 흐름 매핑을 사용하는 A 응답이 반환됩니다.
IPv6 비호환/기존 앱은 A 레코드 응답에서 반환된 IPv4 주소를 사용하고 해당 주소에 대한 소켓을 설정합니다. 푸시된 IPv4 경로로 인해 Jamf ZTNA의 VPN 인터페이스를 통해 라우팅됩니다.

결과는 IPv6 vs IPv4를 사용하는 것과 함께 약간의 효율성 손실을 제외한 거의 동일한 사용자 경험입니다.

동적 분할 터널링

액세스 정책과 일치하지 않는 모든 연결의 경우 - 중개된 DNS 연결 또는 직접 IP를 통해 - A/AAAA/HTTPS DNS 응답이 업스트림 DNS 리졸버에서 반환한 것과 정확히 동일하게 반환됩니다. 즉, 결과는 Jamf ZTNA가 기기에서 비활성화된 것처럼 애플리케이션에 연결하려는 것과 동일합니다.

이 경우 이러한 요청에 대해 클라우드 흐름 매핑이 생성되거나 로깅이 수행되지 않습니다 (예외는 Jamf의 Content Filtering 및/또는 Web Threat Protection을 구성한 경우로, Internet 또는 Security 정책을 기반으로 요청이 로깅되거나 차단될 수 있습니다).

이는 정적 CIDR 범위를 사용하여 구축된 기존 분할 터널과 달리 터널에 의해 캡슐화되는 (또는 아님) 트래픽이 실시간으로 변경될 수 있기 때문에 "동적" 분할 터널 동작을 초래합니다. 이는 위에 설명된 중개된 연결 방법을 통해 달성되며, 활성 구성 및 기기의 순간 컨텍스트를 기반으로 클라우드 흐름 매핑이 반환되거나 공개 DNS 응답이 사용됩니다.

로컬 네트워킹

좋은 소식입니다! Direct IPs/Subnets을 사용자의 로컬 네트워크의 서브넷과 겹치도록 추가하지 않았다면 대부분의 로컬 네트워크 연결이 잘 작동합니다! 이는 프린터와 같은 로컬 기기에 중요하지만 특히 많은 사용자가 홈 네트워크에서 스마트 홈 또는 엔터테인먼트 지향 앱을 원활하게 사용할 수 있기를 기대하는 모바일 기기에 중요합니다.

대부분의 로컬 네트워크에는 권위 있는 DNS 영역이 없으므로 기기는 대신 mDNS에 의존하여 다른 로컬 기기를 발견하고 연결합니다. VPN 네트워크 인터페이스에 Jamf ZTNA DNS 서버가 설정되면 mDNS는 영향을 받지 않으므로 이 동작은 정상적으로 계속 작동합니다.

Wildcard / Not-Quite-ZTNA 액세스 정책

ZTNA의 보안 약속은 강력하지만 넓게 열린 기존 VPN 배포에서 세분화된 앱 수준의 ZTNA 환경으로의 이동은 시간이 걸릴 것입니다. 대부분의 조직이 엄청난 양의 사전 테스트 및/또는 최종 사용자 통증 없이 ZTNA 기반 VPN (Jamf의 경우처럼)으로 전환할 수 있을 것으로 예상하는 것은 현실적이지 않습니다.

따라서 Jamf Connect ZTNA는 이 현실에 적응하여 여러 중요한 방식으로 기존 VPN처럼 작동하도록 할 수 있습니다.

FQDN Wildcards

가장 세분화되고 최상의 보안 구성은 앱만큼 많은 액세스 정책을 구성하는 것이며, 각 앱에 대해 사용되는 특정 FQDN 및 호스트 이름을 지정하는 것입니다. 예를 들어, 애플리케이션 App의 경우 app.acmeinc.com 및 images.app.acmeinc.com을 가질 수 있습니다.

그러나 이러한 호스트 이름을 모두 발견하는 것은 물론 액세스 정책에서 구성하는 것도 상당한 시간이 걸릴 수 있습니다.

따라서 특히 Jamf Connect ZTNA를 시도하거나 방금 시작하는 경우 "Acme Inc Wildcard Default"와 같은 이름의 액세스 정책을 생성하고 *.acmeinc.com과 같은 호스트 이름을 구성하는 것을 권장합니다. 이 단일 규칙은 acmeinc.com을 도메인으로 사용하는 모든 FQDN에 대한 요청을 "잡을" 것입니다.

이는 테스트 인프라를 시작하고 실행하여 내부 애플리케이션으로 트래픽을 흐르게 할 수 있는 좋은 방법입니다 (물론 적절한 Custom DNS Zones 및 Interconnect Gateways를 구성했다고 가정).

그러나 Access Event Logs의 보고서에서 발견한 특히 민감한 애플리케이션 또는 기타 애플리케이션에 대한 액세스 정책을 생성하기를 원할 것입니다.

이를 용이하게 하기 위해 Jamf Security Cloud는 다른 액세스 정책에서 정의된 와일드카드 "내에" 있는 호스트 이름을 가진 액세스 정책을 생성할 수 있게 합니다. 예를 들어 app.acmeinc.com 및 images.app.acmeinc.com이 중요한 애플리케이션이고 특정 액세스 정책을 생성하려면 와일드카드를 조정할 필요 없이 그렇게 할 수 있습니다. 새로운 액세스 정책을 생성한 후 트래픽 흐름은 해당 새로운 앱 액세스 정책과 일치하기 시작하고 와일드카드 정책과는 일치하지 않습니다.

간단히 말해서 Connect ZTNA 와일드카드 매핑 규칙은 가장 세분화된 호스트 이름을 먼저 일치시킵니다. 두 개의 중첩된 와일드카드 정책이 있다고 가정하면 images.app.acmeinc.com은 *.acmeinc.com 앞에 .app.acmeinc.com과 일치합니다. 물론 images.app.acmeinc.com을 사용한 세 번째 액세스 정책을 정의한 경우 모든 와일드카드 규칙을 우회합니다.

대규모 IP 기반 CIDR 서브넷

호스트 이름과 마찬가지로 Direct IP 주소 연결을 사용하여 작동하는 앱이 발견하는 데 시간이 걸릴 수 있습니다.

광범위한 네트워크 세그먼트를 정의하는 것 (예: 10.0.0.0/8)을 강력히 권장하지 않지만 공격자가 VPN 연결을 통해 측면 이동 (데이터 센터 내) 및 수직 이동 (데이터 센터 간)을 수행할 수 있게 하기 때문에, 기존 VPN의 라우팅 구성과 일치하는 구성으로 시작해야 하는 경우가 많습니다. 기술 전환을 보장합니다.

노출을 줄이기 위해 다음을 권장합니다:

IP 기반 액세스를 절대적으로 필요로 하는 사용자 또는 앱에만 정의
CIDR 서브넷을 /32 주소에 최대한 가깝게 유지
광범위한 IP 기반 액세스 정책을 좁은 파일럿 사용자 그룹에 할당한 다음 이벤트 로그를 모니터링하여
- 사용되는 IP를 발견하고 이러한 IP에 대한 더 좁은 액세스 정책 생성
- 단기 또는 중기에 이러한 사용자/앱이 FQDN으로 전환할 수 있는지 평가하여 장기 지원을 위해 IP 기반 액세스 필요성을 제거할 수 있습니다.

엔드포인트-Jamf Cloud 연결

Jamf Trust 클라이언트는 최종 사용자를 인증하고 엔드포인트와 적절한 Jamf Security Cloud 테넌트 사이의 보안 연결을 설정하는 데 사용되지만 네트워킹 관점에서는 상당히 "둔합니다".

광범위한 처리는 클라우드에서 수행되며 에이전트는 Jamf 라우팅 구조에 대한 연결 관리를 처리하고 그렇지 않으면 기기의 네트워크 스택과 Wireguard 또는 HTTP/3 터널 사이의 패킷을 캡슐화 및 캡슐화 해제합니다.

여기서 호출할 만한 네트워킹 세부사항은 기업 LAN 사용 시 엔드포인트와 Jamf Security Cloud 사이의 모든 필요한 트래픽을 허용하도록 방화벽을 구성되어 있는지 확인하기 위해 엔드포인트 에이전트 트래픽 요구사항을 검토하는 것입니다.

Jamf Cloud-to-Customer/Data 연결

엔드포인트의 트래픽이 Jamf Cloud에 도달하면 모든 패킷은 암호 검증 및 해당 테넌트 및 기기에 대해 정의된 액세스 정책을 따릅니다. 각 액세스 정책은 정책에 의해 정의된 애플리케이션에 도달하기 위한 "다음 홉" 경로를 정의하며, 이는 다음 중 하나일 수 있습니다:

프라이빗 인터커넥트 (예: 사이트-사이트 IPSec 터널)
인터넷 NAT 출력 게이트웨이 (예: 선택한 데이터 센터의 로드 밸런싱된 IP 세트 또는 사용자의 위치에 따라 자동으로 선택됨)
Jamf Security Cloud를 통해 라우팅하지 않고 기기 자체에서 직접 공개 경로를 사용

위의 모든 다음 홉 경로는 정의된 액세스 정책에 따라 기기가 리소스에 액세스할 수 있는 권한이 있는 경우에만 기기에 허용된다는 점을 호출하는 것이 중요합니다. 기기가 정책에 따라 리소스에 도달할 수 있는 권한이 없으면:

기기의 위험 수준이 너무 높은 경우 연결이 적극적으로 차단/블랙홀
기기가 액세스에 권한이 있는 그룹에 속하지 않는 경우 Jamf Connect ZTNA가 없는 것처럼 처리됨

리소스에 액세스할 수 있는 권한이 있는 기기는 액세스 정책에 의해 정의된 경로를 활용합니다. 이 경로는 일반적으로 많은 기기 간에 "공유"되지만 패킷의 최종 대상인 반면 Jamf ZTNA 정책 엔진은 준수 컨텍스트에서만 명시적으로 권한이 있는 기기, 사용자 및 연결을 허용합니다. 그렇지 않으면 라우팅 구조의 기본 특성 때문에 이러한 경로는 완전히 보이지 않고 엔드포인트에서 사용할 수 없습니다.

서버/인프라-클라이언트 연결

기존 VPN을 사용하면 VPN 발급 IP 주소에서 수신 대기하는 서비스에 기술적으로 연결할 수 있습니다. 이는 원격 데스크톱/지원 기능 및 기타 기존 애플리케이션에 사용되었습니다.

그러나 이 액세스 모델은 더 이상 모범 사례로 간주되지 않습니다. 이는 엔드포인트에 애플리케이션 서비스를 활성화하는 것이 소프트웨어 취약성, 오구성 및 패싱 관리로 인한 상당한 위험을 야기하기 때문입니다. 이러한 위험은 공격자가 엔드포인트에 액세스하고 궁극적으로 VPN 연결을 통해 엔드포인트의 게이트웨이로서 엔드포인트 로컬 데이터뿐 아니라 회사 데이터 및 인프라에 액세스할 수 있게 할 수 있습니다.

대신 이러한 많은 도구는 유사한 "중개된 연결" 아키텍처를 활용하도록 현대화되었으므로 엔드포인트는 서비스로 아웃바운드 소켓을 생성하고 서비스는 요청 시 다른 연결 당사자와 연결을 연결합니다. 이를 통해 엔드포인트는 효과적으로 "아웃바운드 전용" 모드에서 작동할 수 있으므로 거의 모든 인바운드 포트 및 프로토콜을 기기에서 차단할 수 있습니다.

이러한 이유로 Jamf는 인프라-엔드포인트 연결을 지원하지 않습니다. 이는 엔드포인트의 공격 표면을 크게 줄이면서 엔드포인트는 여전히 사용자가 생산적일 필요한 모든 애플리케이션에 완전히 액세스할 수 있습니다.

연결 검증 및 테스트

아래 섹션은 Jamf Connect ZTNA 데이터 흐름을 더 잘 테스트, 진단 및 문제 해결하는 데 도움이 되도록 설계되었습니다.

Jamf Trust 애플리케이션 로깅

Jamf Trust 앱의 macOS 및 Windows 버전 모두 기기에서 로컬 아카이브로 로그 데이터를 내보낼 수 있는 기능을 포함합니다. 이 파일은 모든 비밀이 제거되지만 기기의 구성 상태에 대한 유용한 정보와 문제 해결 목적으로 클라이언트와 서버 간의 대역 외 통신 로그를 포함합니다.

Netcheck Connectivity로 테스트

NetCheck Connectivity 앱은 iOS 및 macOS (범용 앱)용 유용한 제3자 도구로, 기기의 네트워크 스택 상태를 진단하고 특정 엔드포인트를 프로브하여 Jamf ZTNA를 통해 라우팅할지 여부를 테스트할 수 있는 기능을 제공합니다.

이 도구는 다른 방식으로 기기에 손으로 얻을 수 없는 최종 사용자가 보고한 문제를 검증하는 데 매우 유용합니다. 사용자는 두 플랫폼 모두에 대해 App Store에서 쉽게 앱을 얻을 수 있으며, 테스트를 열고 (테스트를 자동으로 시작) 공유 시트를 사용하여 결과를 공유할 수 있습니다. 이는 결과를 JSON 파일로 패키지합니다.

Sample Netcheck Results Diagnostic UI

ping으로 테스트

가장 일반적으로 발생하는 첫 번째 실수는 Jamf Security Cloud에서 모든 것을 올바르게 구성한 후 (Direct IP 주소를 정의하거나 IPv4 호환 라우팅을 선택하지 않음) 테스터가 다음 명령을 명령줄 도구에 발급합니다:

ping app.acmeinc.com

그러면 다음과 유사한 것이 반환됩니다:

ping: cannot resolve app.acmeinc.com: Unknown host

"뭐?! 모든 것이 깨졌다!"

여기서의 문제는 유틸리티로서의 ping이 기본적으로 IPv6을 인식하지 못한다는 것입니다. 구체적으로 ping은 입력된 FQDN에 대해서만 A 레코드 쿼리를 발급하며 즉시 실패합니다. 이는 OS에 조회를 수행하도록 하는 다른 모든 앱 및 브라우저와 달리 동시에 A/AAAA/HTTPS DNS 쿼리를 보낼 것입니다.

따라서 해결책은 쉽습니다. ping6을 사용하여 IPv6의 사용을 강제 합니다:

#ping6 app.acmeinc.com
PING6(56=40+8+8 bytes) fddd:dddd:1000:0:0:444:555:2222 --> fd53:1c5a:1000:111:222:333
16 bytes from fd53:1c5a:1000:111:222:333, icmp_seq=0 hlim=58 time=31.824 ms
16 bytes from fd53:1c5a:1000:111:222:333, icmp_seq=1 hlim=58 time=29.947 ms

app.acmeinc.com이 ICMP ping 요청에 응답할 수 있는 한 위의 응답이 수신됩니다. 참고: 서버의 내부 IP 주소 10.0.1.22의 표시는 없습니다.

dig/nslookup으로 테스트

ping으로 테스트하는 것과 유사하게 dig 및 nslookup은 명령줄에서 사용할 때 기본적으로 A 레코드 조회를 수행합니다:

# dig app.acmeinc.com           
    
; <<>> DiG 9.10.6 <<>> app.acmeinc.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30788
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

ping과 유사하게 AAAA 쿼리를 사용하여 호스트 이름을 조회하려면 명시적으로 표시해야 합니다:

# dig AAAA app.acmeinc.com
; <<>> DiG 9.10.6 <<>> AAAA app.acmeinc.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58465
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;app.acmeinc.com.                IN        AAAA
    
;; ANSWER SECTION:
app.acmeinc.com.        60        IN        AAAA        fd53:1c5a:1000:111:222:333
...

그리고 재미있기 위해 nslookup은 다른 명령줄 스위치와 구문을 가집니다 (소문자 aaaa).

# nslookup -type=aaaa app.acmeinc.com
Server: fddd:dddd::
Address: fddd:dddd::#53
    
app.acmeinc.com has AAAA address fd53:1c5a:1000:111:222:333

정보: 재미있는 사실: ping과 ping6이 왜 별도 명령일까요?

ping6 맨 페이지에 따르면:

ping6 유틸리티는 ping(8)과 의도적으로 별개입니다.

ping6과 ping(8)을 분리하는 이유에 대한 많은 토론이 있었습니다. IPv4와 IPv6 모두에 대해 ping 명령을 통합하는 것이 더 편리할 것이라고 주장한 사람들이 있습니다. 다음은 요청에 대한 답변입니다.

개발자 관점에서: 기본 원시 소켓 API가 IPv4와 IPv6 사이에서 완전히 다르기 때문에 우리는 두 가지 유형의 코드 베이스로 끝날 것입니다. 개발자 입장에서 두 명령을 하나의 명령으로 통합하는 이점이 실제로 덜할 것입니다.

운영자 관점에서: 원격 로그인 도구와는 달리 네트워크 관리 도구를 사용할 때는 일반적으로 주소 패밀리에 대해 인식하고 있습니다. 우리는 단순히 호스트에 도달 가능한지 알고 싶지 않으며 IPv6과 같은 특정 네트워크 프로토콜을 통해 호스트에 도달 가능한지 알고 싶습니다. 따라서 IPv4와 IPv6 모두에 대해 통합 ping (8) 명령을 가지고 있더라도 일반적으로 -6 또는 -4 옵션 (또는 이와 같은 것)을 입력하여 특정 주소 패밀리를 지정합니다. 이는 본질적으로 두 개의 다른 명령이 있다는 것을 의미합니다.

Microsoft 및 nslookup 작성자는 달리 생각했습니다!

FAQ

Q: 내 앱이나 데이터 리소스에 연결할 수 없는 이유는?!

다음 단계를 따르는 것을 제안합니다:

이런 방식으로 테스트하는 경우 올바른 버전의 ping을 사용하고 있는지 확인하세요.
Netcheck를 사용하여 클라이언트 측의 문제를 제거하세요.
1. Netcheck가 작동했으면 DNS 캐싱 문제가 발생할 가능성이 있습니다. 브라우저/앱을 다시 시작하거나 다음 macOS 명령을 발급하세요: sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache. 캐싱 문제를 줄이기 위해 Jamf Connect ZTNA를 활성화 상태로 유지하는 것이 좋습니다.
Jamf Security Cloud / RADAR에서 액세스 > 이벤트 로그를 확인하여 오류 또는 활동을 확인합니다.
1. 이벤트 로그에 항목이 표시되면 DNS가 올바르게 확인되고 있으며 라우팅 또는 네트워크/방화벽 ACL 문제가 있을 가능성이 있습니다.
2. 항목이 없으면 아웃바운드 Jamf 클라이언트 네트워크 트래픽이 엔드포인트 에이전트 트래픽 가이드에 따라 네트워크에서 차단되지 않는지 확인합니다.
대상 앱이 IPSec 터널을 통해 도달 가능한 것으로 예상되면:
1. 터널이 Jamf Security Cloud / RADAR 및 방화벽 연결의 다른 쪽에 따라 "위로" 있는지 확인합니다. 아래로 이동하면 이러한 가이드가 구성 검증에 도움이 될 수 있습니다.
2. Jamf Security Cloud / RADAR for the IPSec 연결에 제공된 "Jamf Side" 테스트 IP 주소를 터널을 종료하는 기기에서 ping할 수 있음을 확인하세요.
  1. 이것이 작동하지만 네트워크 내 다른 기기에서 동일한 IP를 ping할 수 없으면 내부 라우팅 구성이 누락되었을 가능성이 있습니다. Jamf IP Subnet이 터널의 다른 쪽을 처리하는 기기/어플라이언스로 라우팅되도록 해야 합니다.

추가 지원이 필요하면 Jamf 기술 지원에 문의하세요.

Q: 특정 그룹이 액세스 정책을 사용하도록 구성된 앱 액세스 정책이 있습니다. 해당 그룹에 속하지 않는 사용자/기기의 트래픽은 어떻게 됩니까?

권한이 없는 기기의 트래픽은 앱 액세스 정책이 존재하지 않는 것처럼 처리됩니다. 즉, 임시 IPv6 주소가 아닌 공개 DNS 응답 (있는 경우)이 기기에 반환됩니다.

Q: Cisco Meraki WiFi 장비가 있고 Jamf ZTNA 연결이 산발적으로 중지됩니다. 무엇이 잘못되었습니까?

Meraki의 "Layer 7 Statistical AI" 차단 기능은 Jamf의 Wireguard 트래픽을 P2P로 오류가 발생하고 간헐적으로 차단합니다. 환경에 영향을 미치는 경우 이 설정 관리에 대해 Meraki 지원에 문의하세요.

Guides