Guides

Audience et objectif

Ce document est destiné aux administrateurs informatiques responsables de la sécurité et des réseaux qui possèdent une expérience solide des principes fondamentaux des technologies de réseau et VPN.

En tant que produit de sécurité et de réseau de nouvelle génération, Jamf Connect ZTNA fonctionne de manière considérablement différente d'un VPN traditionnel. Ce guide est conçu pour aider les administrateurs à comprendre les principes fondamentaux de la conception du produit afin de faciliter la planification, le déploiement, la maintenance et la résolution des problèmes.

Ce guide n'est pas une documentation produit décrivant comment configurer le produit ZTNA de Jamf, mais explique plutôt son fonctionnement afin que vous puissiez prévoir et comprendre le comportement du produit dans votre environnement. Si vous recherchez une documentation, vous pouvez la consulter dans notre Documentation Jamf Connect ZTNA, ou si vous souhaitez d'abord regarder une présentation technique vidéo du produit, consultez la présentation JNUC 2021 Jamf ZTNA Deep Dive.

Nous vous recommandons vivement de consulter (et de mettre en signet !) ce guide si vous utilisez Jamf Connect ZTNA en capacité production au sein de votre organisation.

Aperçu

Le produit ZTNA de Jamf a été conçu dès le départ pour adhérer à l'architecture Software Defined Perimeter (SDP) de la Cloud Security Alliance. Cette architecture incarne de nombreux principes de la définition plus large du secteur de Zero Trust Network Access (ZTNA), notamment l'accès à droits minimaux, l'accès basé sur les rôles, la vérification d'identité multifacteurs, la confiance des appareils, et bien d'autres. Le produit a été initialement créé par Wandera et acquis par la plateforme de sécurité Jamf en juillet 2021.

Ainsi, bien que Jamf Connect ZTNA partage de nombreux résultats identiques avec un VPN traditionnel – comme quand l'interface VPN se met en ligne, les ressources distantes deviennent disponibles – les mécanismes réels pour soutenir ces résultats sont complètement différents. Ceci est dû à la façon dont Connect ZTNA utilise l'adressage IP, le DNS et les technologies cloud pour offrir un routage client-serveur qui représente un changement significatif en termes de performance, d'évolutivité et de sécurité par rapport aux architectures VPN traditionnelles.

Cela dit, commençons par l'une des différences les plus importantes et significatives entre le SDP de Jamf et un VPN traditionnel : le courtage de connexion par rapport au routage.

Courtage de connexion

Commençons par ceci : mettez de côté tout ce que vous savez et supposez sur le fonctionnement d'un VPN. Bien que le routage final des paquets ressemble finalement beaucoup à un VPN traditionnel, il existe un élément de traitement entièrement nouveau dans le processus de connexion.

VPN traditionnel

Lorsqu'un appareil se connecte à un VPN traditionnel, il crée un tunnel sécurisé avec un concentrateur VPN, qui peut exister en local ou dans le cloud, et être exploité par vous-même ou un prestataire de services.

Indépendamment de l'emplacement du concentrateur ou de qui l'exploite, le comportement général est le même :

1. L'appareil s'authentifie auprès du concentrateur VPN et un tunnel sécurisé est établi, créant une interface réseau virtuelle sur le point de terminaison.
2. L'appareil reçoit dynamiquement une adresse IP assignée par le concentrateur valide pour la durée de vie de ce tunnel (parfois elle peut être « statiquement » réaffectée par liaison DHCP).
3. Une ou plusieurs routes sont configurées pour l'interface réseau virtuelle, définissant les sous-réseaux réseau appartenant à l'organisation qui doivent être routés via le VPN. Un VPN à tunnel complet route tout le trafic de l'appareil vers le concentrateur, éliminant tout accès réseau local.
4. Un serveur de noms DNS est configuré sur l'appareil, qui réside généralement de l'autre côté du VPN dans le réseau du client.
5. Chaque fois qu'une application fait une demande vers une ressource, le DNS est résolu en adresse IP et le trafic est routé via le VPN si l'adresse IP du paquet se situe dans l'une des routes de l'interface virtuelle VPN.
6. Le concentrateur VPN route le paquet dans le réseau du client. Dans certains cas, des listes de contrôle d'accès pare-feu sont implémentées dans tout le réseau pour restreindre le contrôle d'accès.

Bien que cela fonctionne certainement, le problème de sécurité fondamental de cette architecture est que toutes les ressources au sein des sous-réseaux routés deviennent essentiellement disponibles pour l'appareil. Cela permet la connectivité à des services informatiques et à des serveurs que la plupart des points de terminaison n'ont aucune raison de connecter. Si vous êtes un acteur malveillant et parvenez à exploiter le point de terminaison, vous pouvez utiliser cette connexion VPN pour trouver des failles sur les serveurs qui sont « sûrs » derrière le pare-feu et qui ne sont peut-être pas complètement corrigés ou autrement verrouillés correctement.

Bien sûr, vous pouvez implémenter des règles de contrôle d'accès dans le réseau, mais c'est difficile et sujet aux erreurs. Habituellement, ces règles doivent être gérées au niveau de l'adresse IP, donc elles ont tendance à être fragiles et dangereuses à modifier. Cela se traduit par des politiques de sécurité au niveau réseau qui sont rapidement dépassées par le taux de changement requis pour les applications nouvelles et évolutives qui sont critiques pour la mission sur le réseau. Vous n'avez pas non plus une très bonne façon de surveiller et d'auditer les rapports de manière à coupler étroitement l'identité d'un utilisateur avec ses connexions. Alors que font la plupart des organisations ? La laisser ouverte et assembler les rapports en cas d'incident.

Comment résoudre ces défis ? Entrez SDP et les connexions réseau « courtisées ».

SDP : Courtage de connexion

Lorsque Jamf's ZTNA est connecté sur un appareil de point de terminaison, il existe des différences significatives dès le départ :

1. Une interface réseau Wireguard sans état est créée sur le point de terminaison suite à une poignée de main initiale très légère. Remarque : selon votre déploiement ZTNA, les appareils Apple peuvent utiliser HTTP/3 à la place de Wireguard.
2. Un ensemble simple de routes IPv6 – négociées hors bande de l'établissement d'interface – sont configurées pour l'interface réseau VPN. Par défaut, ces routes n'appartiennent pas au client, mais sont des plages IPv6 réservées gérées par Jamf (fd53:1c5a::/32, fddd:dddd::/128). L'interface réseau VPN reçoit également une adresse IPv6 statique qui a également été négociée hors bande. Aucune adresse IPv4 ou route n'est assignée à l'interface réseau VPN par défaut !
3. Un serveur de noms DNS géré par Jamf fddd:dddd:: est configuré sur l'appareil.

Quoi. C'est quoi ? Oui, vous avez bien lu : aucune adresse IP côté entreprise, sous-réseaux ou serveurs de noms DNS ne sont publiés à la table de routage de l'appareil de l'utilisateur final. Pas même aucune adresse IPv4 ! C'est un élément constitutif clé du courtage de connexion SDP de sorte que le point de terminaison et l'utilisateur n'ont aucune connaissance de la topologie du réseau interne et ne peuvent pas se connecter aux IP du réseau interne même s'ils l'essayaient.

Comment une application sur l'appareil se connecte-t-elle à une application sur un serveur qui vit sur l'un de ces sous-réseaux IPv4 internes ? C'est là que le courtage de connexion intervient, facilité par la magie du DNS, du NAT et des technologies de routage Jamf.

Info : Remarque sur l'accès IP direct et au sous-réseau

Au-delà des avantages de sécurité de ne pas publier les sous-réseaux internes aux points de terminaison – et encore moins des adresses IPv4 – cela aide également à éviter les chevauchements de segments réseau que les utilisateurs pourraient rencontrer sur des réseaux gérés non-corporatifs (par exemple, à domicile, café, etc.). C'est critique pour permettre le travail à distance transparent de n'importe où.

Cependant, il y a certains cas d'utilisation spécifiques où une adresse IPv4 ou un sous-réseau doit être utilisable directement et ne peut pas s'appuyer sur le courtage de connexion basé sur DNS. Pour ces situations, Connect ZTNA prend en charge la configuration de l'accès « IP direct ». Consultez la section « Exceptions aux connexions courtisées » de ce guide pour plus de détails.

Supposons que l'utilisateur essaie de se connecter à App, qui se trouve à app.acmeinc.com, et a une adresse IP interne de 10.0.1.22. Voici ce qui se passe pour faciliter cette connexion depuis un appareil activé par Jamf ZTNA (l'exemple ci-dessous montre une connexion TCP vers l'application de destination, mais un flux similaire est utilisé pour les connexions UDP) :

1. L'utilisateur initie une connexion à app.acmeinc.com depuis son navigateur de choix ou toute application native.
2. L'application demande au système d'exploitation de résoudre ce nom d'hôte pour obtenir une adresse IP pour se connecter. Avec Jamf Connect ZTNA actif, le serveur de noms DNS à utiliser est fddd:dddd::, une adresse IPv6 virtuelle liée au moteur de politique Jamf Connect ZTNA.
3. Le système d'exploitation fait une série de requêtes DNS à fddd:dddd:: pour app.acmeinc.com, incluant les types A, AAAA, et HTTPS.
4. Le serveur de noms DNS Jamf Connect ZTNA effectue une recherche en amont du FQDN, cherchant d'abord à voir si une Custom DNS Zone a été configurée pour le domaine (*.acmeinc.com avec 10.0.1.10 en tant que serveur de noms faisant autorité dans cet exemple). Si une Custom DNS Zone n'est pas trouvée, le service utilise une série de serveurs DNS publics en amont.
   1. Remarque : Le service demande seulement un enregistrement A en amont, les enregistrements AAAA et HTTPS étant ignorés pour le moment. C'est seulement un problème potentiel pour les serveurs qui ne sont accessibles que via IPv6, ce qui est extrêmement rare aujourd'hui sur la plupart des réseaux publics et privés.
5. Après avoir reçu les réponses DNS A d'un serveur faisant autorité (dans ce cas A 10.0.1.22 du serveur de noms interne du client via une configuration Custom DNS Zone), le serveur de noms DNS Jamf Connect ZTNA identifie l'utilisateur et l'appareil demandant la ressource et recherche une Access Policy correspondante qui définit app.acmeinc.com comme critère de correspondance du trafic.
   1. Cette politique d'accès évalue l'appartenance au groupe de l'utilisateur et la santé de l'appareil pour déterminer si l'accès à la ressource doit être accordé.
   2. Également défini dans la politique est la façon dont le trafic doit être routé via le cloud Jamf. Dans ce cas, nous supposons que le client a configuré une passerelle d'interconnexion IPSec pour servir de route privée pour accéder à cette application interne.
6. En supposant que la politique d'accès soit trouvée et que l'appareil et l'utilisateur réussissent tous les critères requis pour se connecter à la ressource, l'infrastructure de routage Jamf Connect ZTNA crée un « mappage de flux cloud » qui assigne une adresse IPv6 éphémère dans la plage IPv6 réservée publiée au point de terminaison (par exemple fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22).
   1. Ce flux est unique par connexion et utilisateur, et il ne peut pas être réutilisé au-delà de sa durée de vie ou par aucun autre appareil.
7. Cette adresse IPv6 fd53:1c5a::aaaa:bbbb est retournée au point de terminaison comme réponse DNS AAAA.
   1. Le service ne retourne pas de réponse A ou HTTPS par défaut ! C'est très important à retenir lors du dépannage des réponses DNS à l'aide d'utilitaires comme dig !
8. Un nouveau socket vers fd53:1c5a::aaaa:bbbb est créé, et puisque cette adresse IP existe au sein du sous-réseau attribué à l'interface réseau VPN de Jamf Connect ZTNA, ce socket et tous les paquets suivants sont transmis d'avant en arrière via un tunnel Wireguard vers le Jamf Security Cloud.
9. À la réception du paquet, l'infrastructure de routage Jamf Connect ZTNA effectue des contrôles de sécurité supplémentaires, puis localise le mappage de flux cloud pour l'adresse IPv6 de destination.
10. L'infrastructure de routage Jamf Connect ZTNA achemine les paquets via l'épine dorsale cloud mondiale, atteignant finalement la passerelle d'interconnexion IPSec définie par la politique d'accès. Avant que le paquet ne soit acheminé via le tunnel IPSec, une traduction NAT64 se produit conformément au mappage de flux cloud, ce qui entraîne un paquet avec l'adresse IPv4 d'origine (10.0.1.22) en tant que son adresse IP de destination.
    1. L'adresse IP source du paquet est définie sur une adresse IP dans le sous-réseau défini par le « Jamf Security Cloud Side » dans la configuration IPSec. Tout le trafic envoyé au réseau client semblera provenir d'une adresse IP pseudo-aléatoire au sein de ce sous-réseau.
    2. Si vous utilisez un centre de données régional pour l'égress NAT basé sur le cloud, l'adresse IP source sera équilibrée dynamiquement entre les adresses IP globales de ce centre de données.
11. Tous les connexions courtisées correspondantes sont consignées par rapport à l'utilisateur, l'appareil et l'application, et sont disponibles pour examen dans le journal des événements d'accès dans RADAR, entre autres rapports.

Comme vous pouvez le voir, il existe un couplage étroit du DNS, du routage IP et du NAT qui n'existe simplement pas nativement dans les configurations VPN traditionnelles.

Bien que malgré ces différences, Jamf Connect ZTNA traite les paquets extrêmement efficacement car tout le routage se produit nativement à la couche 3, prenant facilement en charge les applications en temps réel telles que VoIP et vidéo. Puisque tout l'encapsulation se produit en utilisant le protocole d'encapsulation UDP Wireguard ultra-rapide et efficace ou HTTP/3, il n'y a pas les « défaillances » des protocoles de transmission courantes lors du routage des connexions TCP au sein d'un tunnel basé sur TCP/mTLS sur des réseaux instables.

Info : SDP, VPN et chiffrement d'application de bout en bout

Jamf Connect ZTNA a été conçu pour fournir des capacités de réseau défini par logiciel rapides et dynamiques utilisant des technologies modernes d'encapsulation et de chiffrement des paquets pour vous permettre de rediriger facilement et d'appliquer une politique au trafic des points de terminaison vers pratiquement n'importe quelle destination en cliquant sur quelques boutons dans une interface web.

Cependant, comme toute technologie VPN qui chiffre le trafic une fois qu'il est déjà en cours de transit, il est impossible pour Jamf de fournir un véritable chiffrement de bout en bout des données depuis l'application client vers l'application serveur.

Par conséquent, pour toute application contenant un certain niveau de données sensibles, vous devez TOUJOURS configurer ces applications pour utiliser les technologies de chiffrement au niveau de l'application telles que HTTPS ou TLS. C'est maintenant une pratique standard pour toutes les applications. C'est le seul moyen d'assurer qu'un tiers non autorisé ne puisse pas accéder à tout moment tout au long du réseau Jamf ou client.

Cette technique de courtage de connexion s'est avérée fonctionner à la performance et à l'échelle de niveau entreprise sur la plateforme Jamf ZTNA. Tous les systèmes d'exploitation modernes prennent nativement en charge IPv6 (même si l'appareil a une connexion réseau IPv4 uniquement), et la grande majorité des applications et des utilisateurs prennent en charge IPv6 et utilisent DNS pour toutes leurs connexions.

C'est sauf pour ceux qui ne le font pas… auquel cas vous devrez définir une configuration spéciale pour que ces cas aberrants fonctionnent via Connect ZTNA.

Disponibilité et basculement

Jamf ZTNA est architecturé en tenant compte du partitionnement réseau et des appareils incapables de se connecter au Jamf Security Cloud. Il le fait en utilisant une variété de méthodes qui se chevauchent :

Détection de passerelle morte

Jamf Trust peut détecter les connexions dangereuses ou instables qui résultent souvent de portails captifs non sécurisés. Ces portails captifs peuvent intercepter le trafic ce qui crée des problèmes de connectivité.

Avec la détection de passerelle morte (DGD), l'application Jamf Trust peut fournir des notifications sur les appareils des utilisateurs finaux concernant l'état actuel de leur connexion. DGD utilise des vérifications de connectivité générales, telles que les vérifications de portail captif et de connectivité web, tout en utilisant les résolutions de points de terminaison Zero Trust Network Access (ZTNA) pour détecter une passerelle morte. Pour soutenir directement DGD, le mode de contournement dans Jamf Trust empêche le trafic dangereux de passer par le tunnel VPN. Cela permet aux utilisateurs finaux de naviguer sur Internet en toute sécurité sans leur VPN ou applications de travail.

Emplacements d'entrée équilibrés en charge et régionaux

Après avoir détecté une connexion active, Jamf Trust demande les points de terminaison IP locaux déterminés à partir du fournisseur DNS du réseau local (généralement fourni par DHCP). La durée de vie (TTL) pour ces points de terminaison est de 60 secondes. Si l'un de ces points de terminaison devient indisponible, il est supprimé du pool dans les 60 secondes. Cela conduit à un objectif de temps de récupération (RTO) pouvant aller jusqu'à 60 secondes, mais lorsqu'il est associé à la détection de passerelle morte, la récupération à partir d'une défaillance d'un seul point de terminaison est immédiate.

Mise en cache de politique locale

Comme décrit dans SDP : Courtage de connexion, Jamf utilise des substituts DNS locaux pour rediriger le trafic de l'appareil vers la ressource appropriée. Ces enregistrements DNS locaux ont également une TTL de 60 secondes. Si une modification de politique est promulguée (soit automatiquement en raison d'une politique basée sur le risque, soit en raison d'une modification administrative), la période la plus longue avant la mise à jour de la politique localement sur l'appareil est de 60 secondes. Remarque : la politique n'existe pas localement sur l'appareil, mais en raison de la mise en cache DNS, il se peut que la mise à jour de la politique soit poussée toutes les 60 secondes.

Exceptions aux connexions courtisées

Bien que la plupart des applications et services fonctionnent nativement et sans considération particulière via le service Jamf ZTNA, il existe certains cas d'utilisation et classes d'applications spécifiques qui nécessitent une connectivité non prise en charge par l'approche de connexion courtisée.

Applications/services qui n'utilisent pas DNS

Comme vous l'avez appris ci-dessus, si une application ou un utilisateur n'utilise pas un FQDN pour se connecter à une ressource, eh bien, cela ne va tout simplement pas fonctionner.

C'est parce que sans une demande DNS pour lancer la connexion, une adresse IPv6 courtisée ne sera jamais émise. Et puisque l'adresse IPv4 de destination n'est pas ajoutée à la table de routage de l'appareil, ce paquet ira simplement sur Internet et ne reviendra jamais.

Bien qu'exceptionnels en agrégat, les scénarios de connexion qui n'impliquent pas les FQDN/DNS sont courants pour :

• Les administrateurs informatiques essayant de se connecter directement à l'équipement réseau
• Les développeurs se connectant à de nouvelles instances d'instances virtuelles qui ne sont pas enregistrées auprès du DNS
• Les applications héritées qui se connectent via une adresse IPv4, et non un FQDN

C'est pour cette raison que Jamf Connect ZTNA prend en charge la définition optionnelle des « IP directs et sous-réseaux » dans une Access Policy d'une application.

Error : Sécurité et exceptions IP directs et sous-réseaux

Nous recommandons uniquement de configurer l'accès basé sur IP pour les utilisateurs et applications qui doivent absolument avoir accès aux ressources de cette manière. Et si vous le faites, les sous-réseaux que vous définissez sont délimités aussi étroitement que possible (par exemple, 10.0.1.0/29) par rapport à (10.0.0.0/16).

C'est parce qu'en établissant le routage à un tel niveau large, vous négliez effectivement de nombreux avantages de sécurité d'un modèle de connectivité basé sur le courtage, en revenant au comportement d'un VPN traditionnel. Cela laisse votre organisation vulnérable aux mêmes types d'attaques qui impactent les VPN traditionnels causés par l'activation d'un accès excessif aux ressources réseau.

Lors de la configuration d'une ou plusieurs adresses IP de cette façon, les sous-réseaux CIDR définis seront publiés à la table de routage des appareils assignés à cette politique. Cela signifie qu'en addition au sous-réseau IPv6 fd53 par défaut, l'interface réseau VPN contiendra également tous les sous-réseaux IPv4 définis dans toutes les politiques d'accès applicables.

Lors de l'enregistrement d'une politique d'accès avec ces adresses IP définies, il peut prendre jusqu'à 30 minutes pour que ces modifications se propagent à tous les appareils. L'activation et la désactivation de Jamf Connect ZTNA déclencheront une mise à jour immédiate de ces politiques.

Maintenant, en supposant qu'un 10.0.1.22 a été ajouté à la même politique d'accès App, un utilisateur final Jamf ZTNA serait capable de se connecter via http://10.0.1.22 ou ping 10.0.1.22.

Il est à noter que même si la connexion n'est pas courtisée via DNS, la capacité à se connecter à la ressource est toujours soumise à toutes les conditions définies dans la Access Policy.

Applications qui utilisent FQDN, mais ne prennent pas en charge IPv6

Il y a un sous-ensemble d'applications pour lesquelles pour un certain nombre de raisons n'aiment tout simplement pas IPv6 :

• Certaines applications modernes ont des piles réseau complexes/personnalisées qui ne sont simplement pas compatibles avec IPv6 (par exemple, Docker pour macOS)
• Les applications héritées qui ne savent pas que IPv6 existe, et ne peuvent pas utiliser une réponse AAAA et échouent à fonctionner quand il n'y a pas de réponse A.

Pour ces applications, vous pouvez configurer une politique d'accès pour utiliser un routage « Compatible » au lieu de « Optimisé ». Cela entraînera les éléments suivants :

• Les appareils soumis à la politique d'accès recevront un sous-réseau IPv4 unique du Jamf Cloud qui fonctionne de manière identique à la plage IPv6 pour le courtage de connexion
  • Cette même plage est utilisée pour une ou plusieurs politiques d'accès configurées de cette manière.
  • Il peut prendre jusqu'à 10 minutes pour que cette nouvelle route soit publiée à tous les appareils, ou le VPN peut être redémarré pour déclencher la mise à jour immédiatement.
• Les appareils soumis à la politique d'accès recevront une adresse IPv4 sur l'interface réseau VPN.
• Lorsqu'une demande DNS reçue correspond à une Access Policy définie au mode « Compatible », la réponse AAAA sera vide, mais une réponse A sera retournée en utilisant un mappage de flux cloud IPv4 au lieu d'une IPv6 comme utilisé quand « Optimisé » est sélectionné.
• L'application incompatible avec IPv6 / héritée utilisera l'adresse IPv4 retournée dans la réponse de l'enregistrement A, et établira un socket vers cette adresse qui sera routée via l'interface VPN de Jamf ZTNA grâce aux routes IPv4 publiées.

Le résultat est une expérience utilisateur pratiquement identique au routage optimisé, moins certaines efficacités mineures inhérentes à l'utilisation d'IPv6 par rapport à IPv4 sur la pile réseau.

Fractionnement du tunnel dynamique

Pour toutes les connexions qui ne correspondent pas à une politique d'accès – qu'il s'agisse d'une connexion DNS courtisée ou d'une IP directe – la réponse DNS A/AAAA/HTTPS est retournée exactement comme retournée par le serveur DNS en amont. En d'autres termes, le résultat serait équivalent à essayer de se connecter à l'application comme si Jamf ZTNA était désactivé sur l'appareil.

Dans ce cas, aucun mappage de flux cloud n'est créé pour ces requêtes, ni journalisation effectuée (l'exception à cela est si vous avez également configuré le filtrage de contenu de Jamf et/ou la protection contre les menaces web grâce auxquelles les requêtes peuvent être enregistrées ou bloquées en fonction des politiques Internet ou Sécurité).

Cela entraîne un comportement de « fractionnement du tunnel dynamique » car contrairement à un fractionnement du tunnel traditionnel construit à l'aide de plages CIDR statiques, le trafic encapsulé (ou non) par le tunnel peut être modifié en temps réel. Ceci est réalisé grâce à la méthode de courtage de connexion comme décrit ci-dessus, où un mappage de flux cloud est retourné, ou la réponse DNS publique est utilisée, entièrement basée sur la configuration active et le contexte instantané de l'appareil.

Réseau local

Bonne nouvelle ! À moins que vous n'ayez ajouté des IP directs/sous-réseaux qui chevauchent le sous-réseau du réseau local d'un utilisateur, la plupart de la connectivité du réseau local pour l'appareil fonctionne très bien ! C'est important pour les appareils locaux comme les imprimantes, mais particulièrement pour les appareils mobiles où beaucoup d'utilisateurs s'attendent à pouvoir utiliser de manière transparente leurs applications de maison intelligente ou