Votre VPN ne rend pas Cosmos DB privé à lui seul

Vous connectez l'ordinateur portable au VNet via un VPN, vous ouvrez l'URL du compte Cosmos DB, et la requête sort toujours par l'internet public. Le tunnel a fait son travail. Ce qu'il n'a pas fait, c'est créer un point de terminaison privé, publier l'enregistrement DNS privé ou désactiver l'accès public, car ce sont trois modifications distinctes du compte et non des propriétés de votre connexion réseau. Cet exemple utilise Azure Cosmos DB pour NoSQL, un point de terminaison privé dans un VNet et un ordinateur portable connecté à ce VNet par VPN, et il conserve l'adresse de l'application inchangée.

Le mythe : être sur le VPN rend la base de données privée

Être sur le VNet signifie seulement que vos paquets peuvent atteindre des adresses privées dans ce VNet. Cela ne dit rien sur l'endroit où le nom du compte se résout, ni sur le fait que le compte accepte encore du trafic public.

Un point de terminaison privé est une ressource distincte avec sa propre adresse, sa propre étape d'approbation et son propre câblage DNS. Tant qu'il n'existe pas et n'est pas approuvé, le nom se résout vers le point de terminaison public et votre trafic y va quel que soit le tunnel.

Ce qui fait réellement résoudre le nom en privé

Conservez le point de terminaison de compte normal du SDK, quelque chose comme https://ACCOUNT.documents.azure.com. Le DNS privé doit résoudre ce nom via la chaîne Private Link vers les adresses privées du point de terminaison. Ne le remplacez pas par une URL numérique et ne désactivez pas les vérifications de certificat, car cela échange un problème DNS contre un problème de sécurité.

Ces valeurs sont spécifiques à l'API NoSQL. Les autres API Cosmos ne sont pas des entrées interchangeables dans le même exemple, et copier le nom de la sous-ressource depuis une autre API produit un point de terminaison qui ne se résout jamais.

Créez et approuvez le point de terminaison via le flux de travail Azure autorisé, puis utilisez son intégration au groupe de zones DNS privées. L'ordinateur portable a besoin de un résolveur capable de répondre pour cette zone, directement ou via un transfert approuvé, et d'une route de client VPN vers chaque adresse de point de terminaison pertinente.

Un point de terminaison privé peut avoir plus d'une adresse, y compris des entrées globales et régionales. Maintenez l'intégration DNS lorsque les régions du compte changent au lieu d'épingler une seule adresse dans un fichier hosts, et rappelez-vous qu'une réponse d'un résolveur public non lié ne prouve rien sur le chemin privé. Si vous transférez le DNS via un hub, confirmez que le redirecteur répond avant de déboguer le client. Un redirecteur obsolète renvoie la réponse publique, ce qui ressemble exactement à un point de terminaison manquant.

Le mode Gateway et le mode Direct ne sont pas interchangeables

Le mode Gateway envoie les requêtes de service via HTTPS sur TCP 443. C'est pourquoi une politique de pare-feu limitée au 443 fonctionne pour lui et pourquoi cet exemple le choisit délibérément.

Le mode Direct sur Private Link a des exigences de connectivité différentes, notamment une plage de ports TCP plus large que la documentation du compte énumère. Une politique écrite pour le mode Gateway ne doit pas être réutilisée silencieusement pour un client en mode Direct, sinon le SDK se connectera puis se bloquera à la première opération de données.

Choisissez un mode, notez-le avec le compte et faites correspondre la politique réseau. Les équipes qui changent de mode pendant le dépannage finissent généralement avec un ensemble de règles de pare-feu qui ne satisfait ni l'un ni l'autre.

Désactiver l'accès public est un interrupteur distinct

Si le compte doit être uniquement privé, désactivez l'accès au réseau public via le paramètre pris en charge du compte et vérifiez le résultat. Ne traitez pas l'existence d'un point de terminaison privé comme la décision d'accès complète, car un compte avec un point de terminaison privé et l'accès public activé répond encore sur internet.

Vérifiez depuis l'extérieur du VPN ainsi que depuis l'intérieur. Une requête provenant d'un réseau qui devrait être exclu est le test qui prouve que le paramètre a pris effet, et c'est le test que la plupart des fenêtres de changement sautent.

L'accessibilité n'est pas une autorisation

Une opération SDK autorisée depuis l'ordinateur portable du VPN est le test d'acceptation, en utilisant l'URL de compte normale et l'identité prévue. L'accessibilité par VPN n'accorde pas les autorisations de données Cosmos ; le plan de données vérifie ses propres rôles ou clés.

Exécutez ensuite les refus : une autre identité et un chemin réseau qui ne devrait plus atteindre le compte. Si l'un ou l'autre réussit, la frontière que vous avez documentée n'est pas celle que vous avez construite.

Notez quatre faits en terminant : les adresses privées du point de terminaison, la zone DNS qui répond pour le nom du compte, le mode de connexion avec ses exigences de ports et si l'accès public est désactivé. Ces quatre expliquent la configuration à la personne suivante, et chacun échoue indépendamment.