Ihr VPN macht Cosmos DB nicht von allein privat

Sie verbinden den Laptop über ein VPN mit dem VNet, öffnen die URL des Cosmos DB-Kontos, und die Anfrage verlässt trotzdem das öffentliche Internet. Der Tunnel hat seine Aufgabe erfüllt. Was er nicht getan hat, ist einen privaten Endpunkt zu erstellen, den privaten DNS-Eintrag zu veröffentlichen oder den öffentlichen Zugriff abzuschalten, denn das sind drei getrennte Änderungen am Konto und keine Eigenschaften Ihrer Netzwerkverbindung. Dieses Beispiel verwendet Azure Cosmos DB für NoSQL, einen privaten Endpunkt in einem VNet und einen per VPN mit diesem VNet verbundenen Laptop, und es lässt die Adresse der Anwendung unverändert.

Der Mythos: im VPN zu sein macht die Datenbank privat

Im VNet zu sein bedeutet nur, dass Ihre Pakete private Adressen in diesem VNet erreichen können. Es sagt nichts darüber aus, wo der Kontoname aufgelöst wird, und nichts darüber, ob das Konto noch öffentlichen Datenverkehr annimmt.

Ein privater Endpunkt ist eine separate Ressource mit eigener Adresse, eigenem Genehmigungsschritt und eigener DNS-Verdrahtung. Bis er existiert und genehmigt ist, wird der Name zum öffentlichen Endpunkt aufgelöst, und Ihr Datenverkehr geht dorthin, unabhängig vom Tunnel.

Was den Namen tatsächlich privat auflösen lässt

Behalten Sie den normalen Kontoendpunkt des SDK, etwa https://ACCOUNT.documents.azure.com. Privates DNS sollte diesen Namen über die Private-Link-Kette zu den privaten Adressen des Endpunkts auflösen. Ersetzen Sie ihn nicht durch eine numerische URL und deaktivieren Sie keine Zertifikatsprüfungen, denn das tauscht ein DNS-Problem gegen ein Sicherheitsproblem.

Diese Werte sind spezifisch für die NoSQL-API. Andere Cosmos-APIs sind im selben Beispiel keine austauschbaren Einträge, und das Kopieren des Subressourcennamens aus einer anderen API erzeugt einen Endpunkt, der nie aufgelöst wird.

Erstellen und genehmigen Sie den Endpunkt über den autorisierten Azure-Workflow und nutzen Sie dann dessen Integration in private DNS-Zonengruppen. Der Laptop benötigt einen Resolver, der diese Zone beantworten kann, entweder direkt oder über eine genehmigte Weiterleitung, und eine VPN-Client-Route zu jeder relevanten Endpunktadresse.

Ein privater Endpunkt kann mehr als eine Adresse haben, darunter globale und regionale Einträge. Pflegen Sie die DNS-Integration, wenn sich die Regionen des Kontos ändern, statt eine einzelne Adresse in einer hosts-Datei festzunageln, und denken Sie daran, dass eine Antwort von einem unabhängigen öffentlichen Resolver nichts über den privaten Pfad beweist. Wenn Sie DNS über einen Hub weiterleiten, bestätigen Sie, dass der Forwarder antwortet, bevor Sie den Client debuggen. Ein veralteter Forwarder liefert die öffentliche Antwort, die genau wie ein fehlender Endpunkt aussieht.

Gateway-Modus und Direct-Modus sind nicht austauschbar

Der Gateway-Modus sendet Dienstanfragen über HTTPS auf TCP 443. Deshalb funktioniert eine Firewallrichtlinie nur für 443 damit, und deshalb wählt dieses Beispiel ihn bewusst.

Der Direct-Modus über Private Link hat andere Konnektivitätsanforderungen, darunter einen breiteren TCP-Portbereich, den die Kontodokumentation auflistet. Eine für den Gateway-Modus geschriebene Richtlinie darf nicht stillschweigend für einen Client im Direct-Modus wiederverwendet werden, sonst verbindet sich das SDK und hängt dann beim ersten Datenvorgang.

Wählen Sie einen Modus, halten Sie ihn zusammen mit dem Konto schriftlich fest und passen Sie die Netzwerkrichtlinie daran an. Teams, die während der Fehlersuche den Modus wechseln, landen meist bei einem Firewall-Regelsatz, der keinen von beiden erfüllt.

Das Abschalten des öffentlichen Zugriffs ist ein separater Schalter

Wenn das Konto nur privat sein soll, deaktivieren Sie den öffentlichen Netzwerkzugriff über die unterstützte Einstellung des Kontos und überprüfen Sie das Ergebnis. Betrachten Sie die Existenz eines privaten Endpunkts nicht als vollständige Zugriffsentscheidung, denn ein Konto mit privatem Endpunkt und aktiviertem öffentlichem Zugriff antwortet weiterhin im Internet.

Prüfen Sie von außerhalb des VPNs sowie von innen. Eine Anfrage aus einem Netzwerk, das ausgeschlossen sein sollte, ist der Test, der beweist, dass die Einstellung wirksam wurde, und es ist der Test, den die meisten Änderungsfenster auslassen.

Erreichbarkeit ist keine Berechtigung

Ein erlaubter SDK-Vorgang vom VPN-Laptop ist der Abnahmetest, mit der normalen Konto-URL und der vorgesehenen Identität. VPN-Erreichbarkeit gewährt keine Cosmos-Datenberechtigungen; die Datenebene prüft ihre eigenen Rollen oder Schlüssel.

Führen Sie dann die Ablehnungen aus: eine andere Identität und einen Netzwerkpfad, der das Konto nicht mehr erreichen sollte. Wenn einer von beiden erfolgreich ist, ist die dokumentierte Grenze nicht die gebaute Grenze.

Notieren Sie vier Fakten, wenn Sie fertig sind: die privaten Adressen des Endpunkts, die DNS-Zone, die für den Kontonamen antwortet, den Verbindungsmodus mit seinen Portanforderungen und ob der öffentliche Zugriff deaktiviert ist. Diese vier erklären dem Nächsten die Einrichtung, und jede von ihnen kann unabhängig fehlschlagen.