Blog

03.08.2026

Azure Private Endpoints i architektura DNS: Jak bezpiecznie ukryć usługi PaaS przed światem?

Wdrażanie chmury publicznej często zaczyna się od złudnego poczucia bezpieczeństwa. Wystawienie bazy danych, konta storage czy aplikacji webowej na publicznych adresach IP – nawet przy restrykcyjnych regułach firewalla – to proszenie się o kłopoty i ryzyko udanego ataku.

Jak całkowicie odciąć usługi PaaS od publicznego internetu i zamknąć je we własnej sieci wirtualnej? Podczas meetupu SysOps/DevOps Polska Emil Wasilewski, ekspert z ponad 13-letnim doświadczeniem w ekosystemie Microsoft, rozłożył na czynniki pierwsze architekturę Azure Private Link oraz wyzwania związane z rozwiązywaniem nazw DNS w środowiskach hybrydowych.

Jak działa Azure Private Endpoint i po co ukrywać za nim usługi PaaS?

W tradycyjnym modelu usługi platformowe (PaaS) w Azure, takie jak Azure SQL, Cosmos DB, Storage Account czy Web Apps, są domyślnie dostępne z poziomu publicznych adresów IP. Azure Private Endpoint fundamentalnie zmienia ten paradygmat. Jest to wirtualny interfejs sieciowy (NIC), który zostaje wstrzyknięty bezpośrednio do Twojej sieci wirtualnej (VNet) i otrzymuje prywatny adres IP z puli DHCP (który pozostaje niezmienny przez cały cykl życia zasobu). Za komunikację odpowiada technologia Azure Private Link, tunelująca ruch wyłącznie przez prywatną sieć szkieletową Microsoftu.

Według Emila Wasilewskiego największą zaletą tego rozwiązania jest możliwość całkowitego zablokowania publicznego dostępu (Public Access: Disabled) do usługi pasowej. Co ciekawe, Private Link potrafi bezpiecznie łączyć zasoby nie tylko w obrębie jednego regionu, ale również między różnymi subskrypcjami, a nawet tenantami różnych organizacji. Pozwala to na bezpieczne odczytywanie danych z bazy klienta bez konieczności wystawiania jej na świat zewnętrzny lub zestawiania skomplikowanych tuneli VPN między firmami.

Dlaczego zamknięcie usług za Private Endpointem komplikuje rozwiązywanie nazw DNS?

Odcięcie publicznego dostępu do usługi PaaS rodzi natychmiastowy problem komunikacyjny: w Azure połączenia do usług pasowych muszą być realizowane po ich pełnej nazwie domenowej (FQDN), co jest wymuszone walidacją certyfikatów TLS/SSL. W konfiguracji domyślnej publiczny DNS zawsze zwróci publiczny adres IP usługi – a to przy zablokowanym dostępie publicznym natychmiast odrzuci połączenie klienta. Aby ruch trafił w prywatny interfejs sieciowy, musimy wdrożyć strefę prywatną (Private DNS Zone, np. privatelink.database.windows.net), która zmapuje nazwę FQDN na prywatny adres IP (np. 10.1.1.35).

Ekspert zwraca jednak uwagę na krytyczną pułapkę architektoniczną: brak centralnego zarządzania strefami DNS prowadzi do tzw. “DNS sprawlu”. Jeśli każdy deweloper tworzący Private Endpointa generuje własną strefę prywatną, organizacja kończy z kilkunastoma zduplikowanymi strefami w różnych regionach. Ponieważ do jednej sieci wirtualnej nie można podpiąć dwóch identycznych stref DNS, systemy tracą spójność, a rozwiązywanie nazw w środowiskach multi-region i hybrydowych (On-Premise <-> Cloud) całkowicie przestaje działać.

Jak zaprojektować niezawodną architekturę DNS Resolvera w sieci hybrydowej?

Aby połączyć lokalną serwerownię (On-Premises) lub środowiska wieloregionalne z prywatnymi endpointami w Azure, nie wystarczy klasyczne przekazywanie zapytań z kontrolerów domeny. Dobrej jakości architektura wymaga wdrożenia usługi Azure Private DNS Resolver – w pełni zarządzanego serwera DNS od Microsoftu, który potrafi odpowiadać na zapytania warunkowe (Conditional Forwarding) płynące z lokalnych serwerów DNS przez tunel VPN lub ExpressRoute. W tym modelu lokalny DNS widząc zapytanie o domenę *.privatelink.core.windows.net, przekierowuje je do Inbound Endpointu w Azure DNS Resolverze, który odpytuje centralną strefę prywatną i zwraca poprawny, wewnętrzny adres IP.

Emil Wasilewski podkreśla również ważną właściwość sieci chmurowych: peeringi sieci wirtualnych (VNet Peering) nie są przejściowe (nie wspierają tranzytu). Jeśli sieć A jest spięta z siecią B, a sieć B z siecią C (gdzie żyje Private Endpoint), maszyna z sieci A nie zobaczy endpointu w sieci C. Rozwiązaniem jest wdrożenie centralnego modelu Hub-and-Spoke z urządzeniem sieciowym (Network Virtual Appliance / Firewall) lub pełnej siatki połączeń (Full Mesh), co jednak wymaga uwzględnienia dodatkowych kosztów transferu danych.

Zadbaj o bezpieczeństwo swojej chmury z SysOps/DevOps Polska!

Architektura sieciowa i bezpieczne zarządzanie DNS-ami to fundament, na którym opiera się stabilność każdej infrastruktury chmurowej. Nie pozwól, by błędy konfiguracyjne wystawiły Twoje dane na ryzyko!

  • Obejrzyj pełną prelekcję: Chcesz zobaczyć konfigurację Private DNS Resolvera i VPN-ów na żywo? Pełne nagranie z wystąpienia Emila Wasilewskiego znajdziesz na naszym kanale YouTube: Obejrzyj wideo tutaj.
  • Wpadnij na MeetUpy SO/DO: Szukasz bezpośredniego kontaktu z ekspertami i architektami chmurowymi? Dołącz do największej niekodującej społeczności IT w Polsce podczas naszych stacjonarnych MeetUpów organizowanych w całej Polsce.
  • Webinary AI Now: Zobacz, jak sztuczna inteligencja rewolucjonizuje codzienną pracę inżynierów DevOps i automatyzację chmury. Zapisz się na darmowe webinary: https://www.ainowpolska.pl/.

Chcesz opanować Azure i architekturę chmurową w praktyce?

Jeśli czujesz, że czas uporządkować wiedzę z zakresu sieci, bezpieczeństwa i infrastruktury jako kodu (IaC), sprawdź nasze warsztaty pod okiem wybitnych praktyków. Wybierz szkolenia z zakresu Architektury i Bezpieczeństwa Microsoft Azure lub Kubernetes & Cloud Security na naszej stronie: https://www.sysopspolska.pl/szkolenia/ i nie daj się zaskoczyć na produkcji!

Pobierz raport