Twoja VPN sama nie czyni Cosmos DB prywatnym

Łączysz laptop z siecią VNet przez VPN, otwierasz adres URL konta Cosmos DB, a żądanie nadal wychodzi przez publiczny internet. Tunel wykonał swoją pracę. Czego nie zrobił, to utworzenie prywatnego punktu końcowego, opublikowanie prywatnego rekordu DNS lub wyłączenie dostępu publicznego, ponieważ to trzy odrębne zmiany na koncie, a nie właściwości twojego połączenia sieciowego. Ten przykład używa Azure Cosmos DB dla NoSQL, prywatnego punktu końcowego w sieci VNet i laptopa połączonego z tą siecią przez VPN, i zachowuje adres aplikacji bez zmian.

Mit: bycie w VPN czyni bazę danych prywatną

Bycie w sieci VNet oznacza tylko, że twoje pakiety mogą dotrzeć do prywatnych adresów w tej sieci. Nie mówi nic o tym, gdzie rozwiązywana jest nazwa konta, ani nic o tym, czy konto nadal akceptuje ruch publiczny.

Prywatny punkt końcowy to osobny zasób z własnym adresem, własnym krokiem zatwierdzania i własnym okablowaniem DNS. Dopóki nie istnieje i nie zostanie zatwierdzony, nazwa jest rozwiązywana na publiczny punkt końcowy, a ruch trafia tam niezależnie od tunelu.

Co faktycznie sprawia, że nazwa jest rozwiązywana prywatnie

Zachowaj zwykły punkt końcowy konta z SDK, coś w rodzaju https://ACCOUNT.documents.azure.com. Prywatny DNS powinien rozwiązywać tę nazwę przez łańcuch Private Link na prywatne adresy punktu końcowego. Nie zastępuj go adresem URL z liczbami i nie wyłączaj sprawdzania certyfikatów, ponieważ to zamienia problem DNS na problem bezpieczeństwa.

Te wartości są specyficzne dla interfejsu API NoSQL. Inne interfejsy API Cosmos nie są wymiennymi wpisami w tym samym przykładzie, a skopiowanie nazwy zasobu podrzędnego z innego interfejsu API tworzy punkt końcowy, który nigdy się nie rozwiązuje.

Utwórz i zatwierdź punkt końcowy przez autoryzowany przepływ pracy Azure, a następnie użyj jego integracji z grupą stref prywatnego DNS. Laptop potrzebuje resolvera, który może odpowiadać dla tej strefy, bezpośrednio lub przez zatwierdzone przekazywanie, oraz trasy klienta VPN do każdego odpowiedniego adresu punktu końcowego.

Prywatny punkt końcowy może mieć więcej niż jeden adres, w tym wpisy globalne i regionalne. Utrzymuj integrację DNS, gdy zmieniają się regiony konta, zamiast przypinać jeden adres w pliku hosts, i pamiętaj, że odpowiedź niepowiązanego publicznego resolvera niczego nie dowodzi o ścieżce prywatnej. Jeśli przekazujesz DNS przez koncentrator, potwierdź, że przekazujący odpowiada, zanim zaczniesz debugować klienta. Nieaktualny przekazujący zwraca odpowiedź publiczną, która wygląda dokładnie jak brakujący punkt końcowy.

Tryb Gateway i tryb Direct nie są wymienne

Tryb Gateway wysyła żądania usługi przez HTTPS na porcie TCP 443. Dlatego działa z nim polityka firewalla tylko dla 443 i dlatego ten przykład wybiera go celowo.

Tryb Direct przez Private Link ma inne wymagania dotyczące łączności, w tym szerszy zakres portów TCP wymieniony w dokumentacji konta. Polityka napisana dla trybu Gateway nie może być po cichu ponownie użyta dla klienta w trybie Direct, bo SDK połączy się i zawiesi na pierwszej operacji na danych.

Wybierz jeden tryb, zapisz go razem z kontem i dopasuj do niego politykę sieciową. Zespoły, które podczas rozwiązywania problemów zmieniają tryb, zwykle kończą z zestawem reguł firewalla, który nie spełnia żadnego z nich.

Wyłączenie dostępu publicznego to osobny przełącznik

Jeśli konto ma być tylko prywatne, wyłącz dostęp do sieci publicznej przez obsługiwane ustawienie konta i zweryfikuj wynik. Nie traktuj istnienia prywatnego punktu końcowego jako pełnej decyzji o dostępie, ponieważ konto z prywatnym punktem końcowym i włączonym dostępem publicznym nadal odpowiada w internecie.

Zweryfikuj spoza VPN, a także od wewnątrz. Żądanie z sieci, która powinna być wykluczona, jest testem dowodzącym, że ustawienie weszło w życie, i to jest test, który większość okien zmian pomija.

Osiągalność nie jest uprawnieniem

Dozwolona operacja SDK z laptopa w VPN jest testem akceptacyjnym, z użyciem zwykłego adresu URL konta i zamierzonej tożsamości. Osiągalność przez VPN nie przyznaje uprawnień do danych Cosmos; warstwa danych sprawdza własne role lub klucze.

Następnie wykonaj odmowy: inną tożsamość i ścieżkę sieciową, która nie powinna już docierać do konta. Jeśli którakolwiek się powiedzie, granica, którą udokumentowałeś, nie jest granicą, którą zbudowałeś.

Na koniec zapisz cztery fakty: prywatne adresy punktu końcowego, strefę DNS odpowiadającą za nazwę konta, tryb połączenia z jego wymaganiami dotyczącymi portów oraz to, czy dostęp publiczny jest wyłączony. Te cztery wyjaśniają konfigurację następnej osobie, a każdy z nich zawodzi niezależnie.