La tua VPN non rende Cosmos DB privato da sola
Una VPN porta il portatile sulla rete, non dentro il database. Scopri cosa devono fare l'endpoint privato, la zona DNS, la modalità di connessione e l'accesso all'account.
Colleghi il portatile alla VNet tramite una VPN, apri l'URL dell'account Cosmos DB, e la richiesta esce comunque su internet pubblico. Il tunnel ha fatto il suo lavoro. Quello che non ha fatto è creare un endpoint privato, pubblicare il record DNS privato o disattivare l'accesso pubblico, perché sono tre modifiche separate all'account e non proprietà della tua connessione di rete. Questo esempio usa Azure Cosmos DB per NoSQL, un endpoint privato in una VNet e un portatile connesso a quella VNet tramite VPN, e mantiene l'indirizzo dell'applicazione invariato.
Il mito: essere sulla VPN rende privato il database
Essere sulla VNet significa solo che i tuoi pacchetti possono raggiungere indirizzi privati in quella VNet. Non dice nulla su dove viene risolto il nome dell'account, e non dice nulla sul fatto che l'account accetti ancora traffico pubblico.
Un endpoint privato è una risorsa separata con il proprio indirizzo, il proprio passaggio di approvazione e il proprio cablaggio DNS. Finché non esiste ed è approvato, il nome viene risolto sull'endpoint pubblico e il tuo traffico va lì indipendentemente dal tunnel.
Cosa fa realmente risolvere il nome in modo privato
Mantieni l'endpoint account normale dell'SDK, qualcosa come https://ACCOUNT.documents.azure.com. Il DNS privato dovrebbe risolvere quel nome attraverso la catena Private Link agli indirizzi privati dell'endpoint. Non sostituirlo con un URL numerico e non disattivare i controlli dei certificati, perché ciò scambia un problema DNS con un problema di sicurezza.
| Example choice | Value |
|---|---|
| Cosmos API | NoSQL |
| Private endpoint subresource | Sql |
| Private DNS zone | privatelink.documents.azure.com |
| SDK connection mode | Gateway |
Quei valori sono specifici dell'API NoSQL. Le altre API Cosmos non sono voci intercambiabili nello stesso esempio, e copiare il nome della sottorisorsa da un'API diversa produce un endpoint che non si risolve mai.
Crea e approva l'endpoint tramite il flusso di lavoro Azure autorizzato, poi usa la sua integrazione con il gruppo di zone DNS private. Il portatile ha bisogno di un resolver che possa rispondere per quella zona, direttamente o tramite inoltro approvato, e di una route del client VPN verso ogni indirizzo dell'endpoint pertinente.
Un endpoint privato può avere più di un indirizzo, incluse voci globali e regionali. Mantieni l'integrazione DNS quando cambiano le regioni dell'account invece di fissare un singolo indirizzo in un file hosts, e ricorda che una risposta da un resolver pubblico non correlato non dimostra nulla sul percorso privato. Se inoltri il DNS tramite un hub, conferma che l'inoltro risponda prima di eseguire il debug del client. Un inoltro obsoleto restituisce la risposta pubblica, che appare esattamente come un endpoint mancante.
La modalità Gateway e la modalità Direct non sono intercambiabili
La modalità Gateway invia le richieste di servizio su HTTPS sulla TCP 443. Per questo una policy firewall solo per la 443 funziona con essa e per questo l'esempio la sceglie deliberatamente.
La modalità Direct su Private Link ha requisiti di connettività diversi, incluso un intervallo di porte TCP più ampio elencato nella documentazione dell'account. Una policy scritta per la modalità Gateway non deve essere riutilizzata silenziosamente per un client in modalità Direct, altrimenti l'SDK si connette e poi si blocca alla prima operazione sui dati.
Scegli una modalità, annotala con l'account e fai corrispondere la policy di rete. I team che cambiano modalità durante la risoluzione dei problemi finiscono di solito con un set di regole firewall che non soddisfa nessuna delle due.
Disattivare l'accesso pubblico è un interruttore separato
Se l'account deve essere solo privato, disattiva l'accesso alla rete pubblica tramite l'impostazione supportata dell'account e verifica il risultato. Non trattare l'esistenza di un endpoint privato come la decisione di accesso completa, perché un account con un endpoint privato e l'accesso pubblico abilitato risponde ancora su internet.
Verifica dall'esterno della VPN e anche dall'interno. Una richiesta da una rete che dovrebbe essere esclusa è il test che dimostra che l'impostazione ha avuto effetto, ed è il test che la maggior parte delle finestre di modifica salta.
La raggiungibilità non è un permesso
Un'operazione SDK consentita dal portatile della VPN è il test di accettazione, usando l'URL normale dell'account e l'identità prevista. La raggiungibilità VPN non concede autorizzazioni ai dati Cosmos; il piano dati controlla i propri ruoli o chiavi.
Poi esegui i rifiuti: un'identità diversa e un percorso di rete che non dovrebbe più raggiungere l'account. Se uno dei due riesce, il confine che hai documentato non è il confine che hai costruito.
Annota quattro fatti al termine: gli indirizzi privati dell'endpoint, la zona DNS che risponde per il nome dell'account, la modalità di connessione con i suoi requisiti di porte e se l'accesso pubblico è disattivato. Questi quattro spiegano la configurazione alla persona successiva, e ciascuno fallisce in modo indipendente.