Je VPN maakt Cosmos DB niet vanzelf privé

Je verbindt de laptop via een VPN met het VNet, opent de URL van het Cosmos DB-account, en het verzoek verlaat nog steeds het openbare internet. De tunnel deed zijn werk. Wat hij niet deed, is een privé-eindpunt maken, het privé-DNS-record publiceren of openbare toegang uitschakelen, want dat zijn drie afzonderlijke wijzigingen aan het account en geen eigenschappen van je netwerkverbinding. Dit voorbeeld gebruikt Azure Cosmos DB voor NoSQL, een privé-eindpunt in een VNet en een laptop die via VPN met dat VNet is verbonden, en het houdt het adres van de applicatie ongewijzigd.

De mythe: op de VPN zitten maakt de database privé

Op het VNet zitten betekent alleen dat je pakketten privéadressen in dat VNet kunnen bereiken. Het zegt niets over waar de accountnaam wordt omgezet, en het zegt niets over of het account nog openbaar verkeer accepteert.

Een privé-eindpunt is een aparte resource met een eigen adres, een eigen goedkeuringsstap en eigen DNS-bekabeling. Totdat het bestaat en is goedgekeurd, wordt de naam omgezet naar het openbare eindpunt en gaat je verkeer daarheen, ongeacht de tunnel.

Wat de naam echt privé laat omzetten

Behoud het normale account-eindpunt van de SDK, zoiets als https://ACCOUNT.documents.azure.com. Privé-DNS moet die naam via de Private Link-keten omzetten naar de privéadressen van het eindpunt. Vervang het niet door een numerieke URL en schakel geen certificaatcontroles uit, want dat ruilt een DNS-probleem in voor een beveiligingsprobleem.

Die waarden zijn specifiek voor de NoSQL-API. Andere Cosmos-API's zijn in hetzelfde voorbeeld geen uitwisselbare vermeldingen, en het kopiëren van de subresourcenaam uit een andere API levert een eindpunt op dat nooit wordt omgezet.

Maak het eindpunt aan en keur het goed via de geautoriseerde Azure-werkstroom en gebruik daarna de integratie met de privé-DNS-zonegroep. De laptop heeft een resolver nodig die voor die zone kan antwoorden, rechtstreeks of via goedgekeurde doorsturing, en een VPN-clientroute naar elk relevant eindpuntadres.

Een privé-eindpunt kan meer dan één adres hebben, inclusief globale en regionale vermeldingen. Onderhoud de DNS-integratie wanneer de regio's van het account veranderen, in plaats van één adres in een hosts-bestand vast te zetten, en onthoud dat een antwoord van een niet-gerelateerde openbare resolver niets bewijst over het privépad. Als je DNS via een hub doorstuurt, bevestig dan dat de doorstuurder antwoordt voordat je de client debugt. Een verouderde doorstuurder geeft het openbare antwoord terug, dat er precies uitziet als een ontbrekend eindpunt.

Gateway-modus en Direct-modus zijn niet uitwisselbaar

Gateway-modus verstuurt serviceverzoeken via HTTPS op TCP 443. Daarom werkt een firewallbeleid alleen voor 443 ermee en daarom kiest dit voorbeeld het bewust.

Direct-modus via Private Link heeft andere connectiviteitsvereisten, waaronder een breder TCP-poortbereik dat de accountdocumentatie vermeldt. Een beleid dat voor Gateway-modus is geschreven, mag niet stilzwijgend opnieuw worden gebruikt voor een client in Direct-modus, anders maakt de SDK verbinding en blijft hij daarna hangen bij de eerste gegevensbewerking.

Kies één modus, leg hem samen met het account vast en laat het netwerkbeleid ermee overeenkomen. Teams die tijdens het oplossen van problemen van modus wisselen, eindigen meestal met een firewallregelset die geen van beide bevredigt.

Openbare toegang uitschakelen is een aparte schakelaar

Als het account alleen privé moet zijn, schakel je openbare netwerktoegang uit via de ondersteunde instelling van het account en verifieer je het resultaat. Behandel het bestaan van een privé-eindpunt niet als de volledige toegangsbeslissing, want een account met een privé-eindpunt en ingeschakelde openbare toegang antwoordt nog steeds op internet.

Verifieer van buiten de VPN en ook van binnen. Een verzoek van een netwerk dat zou moeten worden uitgesloten, is de test die bewijst dat de instelling van kracht is geworden, en het is de test die de meeste wijzigingsvensters overslaan.

Bereikbaarheid is geen toestemming

Een toegestane SDK-bewerking vanaf de VPN-laptop is de acceptatietest, met de normale account-URL en de bedoelde identiteit. VPN-bereikbaarheid verleent geen Cosmos-gegevenstoestemmingen; het gegevensvlak controleert zijn eigen rollen of sleutels.

Voer daarna de weigeringen uit: een andere identiteit en een netwerkpad dat het account niet meer zou moeten bereiken. Als een van beide slaagt, is de grens die je hebt gedocumenteerd niet de grens die je hebt gebouwd.

Noteer vier feiten wanneer je klaar bent: de privéadressen van het eindpunt, de DNS-zone die voor de accountnaam antwoordt, de verbindingsmodus met zijn poortvereisten en of openbare toegang is uitgeschakeld. Die vier leggen de opzet uit aan de volgende persoon, en elk ervan faalt onafhankelijk.