Azure Private Link for Azure Synapse Analytics

Wskazówka

Microsoft Fabric Data Warehouse to magazyn relacyjny w skali przedsiębiorstwa na podstawie bazy danych data lake z architekturą gotową do użycia w przyszłości, wbudowaną sztuczną inteligencją i nowymi funkcjami. Jeśli dopiero zaczynasz korzystać z magazynowania danych, zacznij od Fabric Data Warehouse. Istniejące obciążenia dedykowanej puli SQL mogą zostać zaktualizowane do Fabric, aby uzyskać dostęp do nowych możliwości w zakresie nauki o danych, analizy w czasie rzeczywistym i raportowania.

Korzystając z Azure Private Link, możesz połączyć się z Synapse SQL przez prywatny endpoint. Prywatny endpoint to interfejs sieciowy z prywatnym adresem IP w twojej wirtualnej sieci i podsieci. Ruch pozostaje w sieci szkieletowej Microsoft, zamiast przechodzić przez publiczny internet.

Zawsze używaj w pełni kwalifikowanej nazwy domeny (FQDN) serwera (<server>.database.windows.net) w parametrach połączenia dla wszystkich sterowników i narzędzi klienta. Próby uwierzytelniania używające prywatnego adresu IP lub prywatnego linku FQDN (<server>.privatelink.database.windows.net) nie działają. To zachowanie jest zaplanowane, ponieważ prywatny punkt końcowy kieruje ruch do bramy SQL, która potrzebuje odpowiedniego FQDN, aby pomyślnie kierować żądania uwierzytelniania.

Proces tworzenia

Twórz prywatne endpointy, korzystając z portalu Azure, PowerShell lub Azure CLI:

Proces zatwierdzania

Po utworzeniu prywatnego punktu końcowego (PE) przez administratora sieci administrator SQL może zarządzać połączeniem prywatnego punktu końcowego (PEC) z usługą SQL Database.

  1. Przejdź do zasobu serwera w portalu Azure.

  2. Przejdź do strony zatwierdzenia prywatnego punktu końcowego. W zasobach serwera SQL Azure Synapse Analytics, w menu zasobów w sekcji Bezpieczeństwo wybierz Połączenia prywatnego punktu końcowego.

  3. Zobacz poniższe:

    • Lista wszystkich połączeń prywatnych punktów końcowych (PEC)
    • Utworzone prywatne endpointy (PE)

  4. Jeśli nie ma prywatnych punktów końcowych, utwórz jeden, wybierając Utwórz prywatny punkt końcowy. W przeciwnym razie wybierz pojedynczy PEC z listy.

  5. Administrator SQL może zatwierdzić lub odrzucić PEC i opcjonalnie dodać krótką odpowiedź tekstową.

  6. Po zatwierdzeniu lub odrzuceniu lista odzwierciedla odpowiedni stan wraz z tekstem odpowiedzi.

  7. Wybierz nazwę prywatnego punktu końcowego.

    Ta akcja przenosi Cię na stronę przeglądu Prywatny punkt końcowy. Wybierz link Interfejsy sieciowe, aby zobaczyć szczegóły interfejsu sieciowego dla prywatnego połączenia punktu końcowego.

    Strona Interfejsu sieciowego wyświetla prywatny adres IP dla połączenia z prywatnym punktem końcowym.

Important

Po dodaniu połączenia prywatnego punktu końcowego domyślnie nie blokuje się publiczny routing do serwera logicznego. W okienku Zapora i sieci wirtualne ustawienie Odmów dostępu do sieci publicznej nie jest domyślnie zaznaczone. Aby wyłączyć dostęp do sieci publicznej, upewnij się, że wybrano pozycję Odmów dostępu do sieci publicznej.

Wyłączanie publicznego dostępu do serwera logicznego

Na serwerze SQL server Azure Synapse Analytics możesz wyłączyć cały publiczny dostęp do serwera logicznego i zezwolić na połączenia wyłącznie z Twojej sieci wirtualnej.

Najpierw upewnij się, że połączenia prywatnego punktu końcowego są włączone i skonfigurowane. Następnie, aby wyłączyć publiczny dostęp do serwera logicznego:

  1. Przejdź do strony Sieć serwera logicznego.
  2. Zaznacz pole wyboru Odmów dostępu do sieci publicznej.

Testowanie łączności z usługą SQL Database z maszyny wirtualnej platformy Azure w tej samej sieci wirtualnej

W tym scenariuszu załóżmy, że utworzyłeś maszynę wirtualną Azure (VM) działającą na nowszej wersji Windows w tej samej sieci wirtualnej co prywatny endpoint.

  1. Uruchom sesję pulpitu zdalnego (RDP) i połącz się z maszyną wirtualną.

  2. Następnie możesz wykonać podstawowe kontrole łączności, aby upewnić się, że maszyna wirtualna łączy się z bazą danych SQL przez prywatny punkt końcowy, korzystając z następujących narzędzi:

Sprawdź łączność za pomocą Telnet

Telnet to funkcja Windows, którą możesz wykorzystać do testowania łączności. W zależności od wersji Windows, może być konieczne włączenie tej funkcji wprost.

Po zainstalowaniu Telnetu otwórz okno wiersza poleceń. Uruchom polecenie Telnet i określ adres IP i prywatny punkt końcowy bazy danych w usłudze SQL Database.

telnet 10.9.0.4 1433

Po pomyślnym połączeniu Telnet zwraca pusty ekran w oknie poleceń.

Sprawdź łączność za pomocą PowerShell

Użyj polecenia PowerShell, aby sprawdzić łączność:

Test-NetConnection -computer myserver.database.windows.net -port 1433

Sprawdź łączność za pomocą PsPing

Użyj PsPing w następujący sposób, aby sprawdzić, czy prywatny punkt końcowy nasłuchuje połączeń przychodzących na porcie 1433.

Uruchom PsPing , podając FQDN dla logicznego serwera SQL i portu 1433:

PsPing.exe mysqldbsrvr.database.windows.net:1433

Ten przykład pokazuje oczekiwany wynik:

TCP connect to 10.9.0.4:1433:
5 iterations (warmup 1) ping test:
Connecting to 10.9.0.4:1433 (warmup): from 10.6.0.4:49953: 2.83ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49954: 1.26ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49955: 1.98ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49956: 1.43ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49958: 2.28ms

Wynik pokazuje, że PsPing może pingować prywatny adres IP powiązany z prywatnym punktem końcowym.

Sprawdź łączność za pomocą Nmap

Nmap (Network Mapper) to bezpłatne i otwartoźródłowe narzędzie do wykrywania sieci oraz audytu bezpieczeństwa. Więcej informacji oraz link do pobrania znajdziesz na stronie https://Nmap.org. Użyj tego narzędzia, aby upewnić się, że prywatny punkt końcowy nasłuchuje połączeń na porcie 1433.

Uruchom Nmap, podając zakres adresów podsieci, w której znajduje się prywatny punkt końcowy.

Nmap -n -sP 10.9.0.0/24

Ten przykład pokazuje oczekiwany wynik:

Nmap scan report for 10.9.0.4
Host is up (0.00s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 207.00 seconds

Wynik pokazuje, że jeden adres IP jest aktywny, co odpowiada adresowi IP prywatnego punktu końcowego.

Sprawdź łączność, korzystając z SQL Server Management Studio (SSMS)

Użyj w pełni kwalifikowanej nazwy domeny (FQDN) serwera w ciągach połączeniowych dla klientów (<server>.database.windows.net). Każda próba logowania bezpośrednio na adres IP lub za pomocą prywatnego linku FQDN (<server>.privatelink.database.windows.net) kończy się niepowodzeniem. To zachowanie wynika z założeń projektowych, ponieważ prywatny punkt końcowy kieruje ruch do bramy SQL w regionie. Musisz podać właściwy FQDN, aby logowania się powiodły.

Wykonaj kroki opisane w Używanie programu SSMS do nawiązywania połączenia z bazą danych SQL. Po połączeniu za pomocą SSMS poniższe zapytanie zwraca client_net_address, które odpowiada prywatnemu adresowi IP maszyny wirtualnej Azure, z której się łączysz:

SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Łączność na miejscu poprzez prywatne peering

Gdy łączysz się z publicznym punktem końcowym z maszyn lokalnych, musisz dodać swój adres IP do zapory opartej na IP, korzystając z reguły zapory na poziomie serwera. Chociaż ten model dobrze sprawdza się w przypadku zezwalania na dostęp do poszczególnych maszyn w przypadku obciążeń deweloperskich lub testowych, trudno jest zarządzać w środowisku produkcyjnym.

Korzystając z Private Link, możesz umożliwić dostęp z sieci lokalnej do prywatnego punktu końcowego za pomocą ExpressRoute, private peeringu lub tunelowania VPN. Możesz wtedy wyłączyć wszelki dostęp przez publiczny punkt końcowy i nie używać zapory opartej na adresach IP do zezwalania na jakiekolwiek adresy IP.

Klienci mogą łączyć się z prywatnym punktem końcowym z tej samej sieci wirtualnej, sparowanej sieci wirtualnej w tym samym regionie lub przez połączenie sieć wirtualna-sieć wirtualna między regionami. Dodatkowo klienci mogą łączyć się z lokalnej sieci, korzystając z ExpressRoute, prywatnego peeringu lub tunelowania VPN. Poniższy uproszczony diagram przedstawia typowe przypadki użycia.

Ponadto usługi, które nie są uruchomione bezpośrednio w sieci wirtualnej, ale są zintegrowane z nią (na przykład aplikacje internetowe lub funkcje usługi App Service) mogą również uzyskiwać prywatną łączność z bazą danych.

Połącz z maszyny wirtualnej Azure VM w sparowanej sieci wirtualnej

Skonfiguruj peering sieci wirtualnych, aby nawiązać łączność z usługą SQL Database z maszyny wirtualnej na platformie Azure w połączonej równorzędnie sieci wirtualnej.

Łączenie się z maszyny wirtualnej na platformie Azure w sieci wirtualnej z inną siecią wirtualną

Skonfiguruj połączenie bramy VPN między siecią wirtualną a siecią wirtualną, aby ustanowić połączenie z bazą danych w usłudze SQL Database z maszyny wirtualnej platformy Azure znajdującej się w innym regionie lub subskrypcji.

Nawiązywanie połączenia ze środowiska lokalnego za pośrednictwem sieci VPN

Aby nawiązać łączność ze środowiska lokalnego, wybierz i zaimplementuj jedną z następujących opcji:

Rozważmy również scenariusze konfiguracji DNS, ponieważ nazwa FQDN usługi może być rozpoznawana jako publiczny adres IP.

Łączenie z usługi Azure Storage z poziomu Azure Synapse Analytics przy użyciu PolyBase i instrukcji COPY

Użyj PolyBase i instrukcji COPY, aby załadować dane do Azure Synapse Analytics z kont Azure Storage. Jeśli konto Azure Storage, z którego ładujesz dane, ogranicza dostęp tylko do zestawu podsieci sieci wirtualnej, korzystając z Private Endpoints, Service Endpoints lub zapór opartych na IP, łączność z kontem z poziomu PolyBase i instrukcji COPY zostanie przerwana. Aby umożliwić scenariusze importu i eksportu za pomocą usługi Azure Synapse Analytics, która łączy się z usługą Azure Storage zabezpieczoną w sieci wirtualnej, zobacz Wpływ używania punktów końcowych usługi sieci wirtualnej z usługą Azure Storage.

Zapobieganie eksfiltracji danych

Eksfiltracja danych następuje, gdy użytkownik, na przykład administrator bazy danych, pobiera dane z jednego systemu i przenosi je do innego miejsca lub systemu poza organizacją. Na przykład użytkownik przenosi dane na konto magazynowe danych nienależące do Microsoft.

Rozważmy scenariusz z użytkownikiem korzystającym z programem SQL Server Management Studio (SSMS) wewnątrz maszyny wirtualnej platformy Azure, łączącym się z bazą danych w usłudze Microsoft SQL Database. Ta baza danych znajduje się w centrum danych Zachodnie stany USA. Poniższy przykład pokazuje, jak ograniczyć dostęp przy użyciu publicznych punktów końcowych za pomocą kontroli dostępu w sieci.

  1. Wyłącz cały ruch usług Azure do SQL Database przez publiczny endpoint, ustawiając Allow Azure Services na OFF. Upewnij się, że reguły zapory na poziomie serwera i bazy danych nie zezwalają na żadne adresy IP. Więcej informacji można znaleźć w artykule Kontrola dostępu do sieci w usłudze Azure Synapse Analytics.
  2. Zezwalaj na ruch tylko do prywatnego adresu IP maszyny wirtualnej. Więcej informacji można znaleźć w zasadach zapory sieciowej wirtualnej.
  3. Na maszynie wirtualnej Azure zawęż zakres połączeń wychodzących, używając Grup Bezpieczeństwa Sieciowego (NSG) i Znaczników Usług w następujący sposób:
    • Określ regułę NSG, która zezwala na ruch dla Service Tag = SQL.WestUs - zezwala tylko na połączenie z bazą SQL w zachodnich Stanach Zjednoczonych.
    • Określ regułę NSG o wyższym priorytecie, aby odmówić ruchu dla Service Tag = Sql - odmawiać połączeń z bazą SQL we wszystkich regionach.

Na końcu tej konfiguracji maszyna wirtualna Azure może łączyć się tylko z zasobem w regionie Zachodnie stany USA. Jednak łączność nie jest ograniczona do jednej bazy danych. Maszyna wirtualna nadal może łączyć się z dowolną bazą danych w regionie zachodnich USA, w tym z tymi niebędącymi częścią subskrypcji. Chociaż w poprzednim scenariuszu ograniczasz zakres eksfiltracji danych do konkretnego regionu, nie eliminujesz go całkowicie.

Korzystając z Private Link, możesz ustawić kontrole dostępu do sieci, takie jak NSG, aby ograniczyć dostęp do prywatnego punktu końcowego. Możesz mapować poszczególne zasoby Azure PaaS na konkretne prywatne punkty końcowe dostępu. Złośliwy insider może uzyskać dostęp tylko do zmapowanego zasobu PaaS i żadnego innego zasobu.

Treści powiązane

  • Ostatnia aktualizacja o