Usługa Azure Private Link dla usług Azure SQL Database i Azure Synapse Analytics
Dotyczy: 
Azure SQL Database Azure Synapse Analytics (tylko dedykowane pule SQL)
Usługa Azure Private Link umożliwia łączenie się z różnymi usługami PaaS na platformie Azure za pośrednictwem prywatnego punktu końcowego. Aby uzyskać listę usług PaaS, które obsługują funkcje usługi Private Link, przejdź do strony Dokumentacja usługi Private Link. Prywatny punkt końcowy to prywatny adres IP w określonej sieci wirtualnej i podsieci.
Ważne
Ten artykuł dotyczy zarówno usługi Azure SQL Database, jak i dedykowanej puli SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics. Te ustawienia dotyczą wszystkich baz danych usługi SQL Database i dedykowanej puli SQL (dawniej SQL DW) skojarzonych z serwerem. Dla uproszczenia termin "baza danych" odnosi się do obu baz danych w usługach Azure SQL Database i Azure Synapse Analytics. Podobnie wszystkie odwołania do "serwera" odwołują się do serwera logicznego, który hostuje usługę Azure SQL Database i dedykowaną pulę SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics. Ten artykuł nie dotyczy usługi Azure SQL Managed Instance ani dedykowanych pul SQL w obszarach roboczych usługi Azure Synapse Analytics.
Jak skonfigurować usługę Private Link
Proces tworzenia
Prywatne punkty końcowe można tworzyć przy użyciu witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure:
Proces zatwierdzania
Gdy administrator sieci utworzy prywatny punkt końcowy (PE), administrator SQL może zarządzać połączeniem prywatnego punktu końcowego (PEC) z usługą SQL Database.
Przejdź do zasobu serwera w witrynie Azure Portal.
Przejdź do strony zatwierdzania prywatnego punktu końcowego:
- W zasobie programu SQL Server w obszarze Zabezpieczenia wybierz pozycję Sieć. Wybierz kartę Dostęp prywatny.
- W obszarze roboczym usługi Synapse w obszarze Zabezpieczenia w menu zasobów wybierz pozycję Połączenia prywatnego punktu końcowego.
Na stronie przedstawiono następujące elementy:
- Lista wszystkich połączeń prywatnego punktu końcowego (PECs)
- Utworzone prywatne punkty końcowe (PE)
Jeśli nie ma prywatnych punktów końcowych, utwórz je przy użyciu przycisku Utwórz prywatny punkt końcowy . W przeciwnym razie wybierz pojedynczy pec z listy, wybierając go.
Administrator SQL może zatwierdzić lub odrzucić pec i opcjonalnie dodać krótką odpowiedź tekstową.
Po zatwierdzeniu lub odrzuceniu lista będzie odzwierciedlać odpowiedni stan wraz z tekstem odpowiedzi.
Na koniec wybierz nazwę prywatnego punktu końcowego
Spowoduje to przejście do strony Przegląd prywatnego punktu końcowego . Wybierz link Interfejsy sieciowe, aby uzyskać szczegóły interfejsu sieciowego dla połączenia prywatnego punktu końcowego.
Na stronie Interfejs sieciowy jest wyświetlany prywatny adres IP dla połączenia prywatnego punktu końcowego.
Ważne
Po dodaniu połączenia prywatnego punktu końcowego publiczny routing do serwera logicznego nie jest domyślnie blokowany. 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
W logicznym serwerze SQL usługi Azure SQL Database przyjęto założenie, że chcesz wyłączyć cały publiczny dostęp do serwera logicznego i zezwolić na połączenia tylko z 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:
Przejdź do strony Sieć serwera logicznego.
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 przyjęto założenie, że utworzono maszynę wirtualną platformy Azure z uruchomioną najnowszą wersją systemu Windows w tej samej sieci wirtualnej co prywatny punkt końcowy.
Uruchom sesję pulpitu zdalnego (RDP) i połącz się z maszyną wirtualną.
Następnie możesz wykonać kilka podstawowych kontroli łączności, aby upewnić się, że maszyna wirtualna łączy się z usługą SQL Database za pośrednictwem prywatnego punktu końcowego przy użyciu następujących narzędzi:
- Telnet
- PsPing
- Nmap
- SQL Server Management Studio (SSMS)
Sprawdzanie łączności przy użyciu usługi Telnet
Klient Telnet to funkcja systemu Windows, która może służyć do testowania łączności. W zależności od wersji systemu operacyjnego Windows może być konieczne jawne włączenie tej funkcji.
Otwórz okno wiersza polecenia po zainstalowaniu programu Telnet. 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 nawiązaniu połączenia program Telnet wyświetli pusty ekran w oknie polecenia, jak pokazano na poniższej ilustracji:
Użyj polecenia programu PowerShell, aby sprawdzić łączność:
Test-NetConnection -computer myserver.database.windows.net -port 1433
Sprawdzanie łączności przy użyciu narzędzia PsPing
Polecenia PsPing można użyć w następujący sposób, aby sprawdzić, czy prywatny punkt końcowy nasłuchuje połączeń na porcie 1433.
Uruchom polecenie PsPing w następujący sposób, podając nazwę FQDN dla serwera logicznego SQL i portu 1433:
PsPing.exe mysqldbsrvr.database.windows.net:1433
Jest to przykład oczekiwanych danych wyjściowych:
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
Dane wyjściowe pokazują, że narzędzie PsPing może wysłać polecenie ping do prywatnego adresu IP skojarzonego z prywatnym punktem końcowym.
Sprawdzanie łączności przy użyciu narzędzia Nmap
Nmap (Network Mapper) to bezpłatne narzędzie typu open source używane do odnajdywania sieci i inspekcji zabezpieczeń. Aby uzyskać więcej informacji i link pobierania, odwiedź stronę https://Nmap.org. Tego narzędzia można użyć, aby upewnić się, że prywatny punkt końcowy nasłuchuje połączeń na porcie 1433.
Uruchom polecenie Nmap w następujący sposób, podając zakres adresów podsieci, która hostuje prywatny punkt końcowy.
Nmap -n -sP 10.9.0.0/24
Jest to przykład oczekiwanych danych wyjściowych:
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 uruchomiony; odpowiada adresowi IP prywatnego punktu końcowego.
Sprawdzanie łączności przy użyciu programu SQL Server Management Studio (SSMS)
Uwaga
Użyj w pełni kwalifikowanej nazwy domeny (FQDN) serwera w parametry połączenia dla klientów (<server>.database.windows.net). Wszelkie próby logowania dokonane bezpośrednio na adres IP lub przy użyciu nazwy FQDN łącza prywatnego (<server>.privatelink.database.windows.net) kończą się niepowodzeniem. Takie zachowanie jest zgodne z projektem, ponieważ prywatny punkt końcowy kieruje ruch do bramy SQL w regionie, a poprawna nazwa FQDN musi być określona, aby logowanie powiodło się.
Wykonaj kroki opisane tutaj, aby nawiązać połączenie z usługą SQL Database przy użyciu programu SSMS. Po nawiązaniu połączenia z usługą SQL Database przy użyciu programu SSMS następujące zapytanie będzie odzwierciedlać client_net_address zgodne z prywatnym adresem IP maszyny wirtualnej platformy Azure, z której nawiązujesz połączenie:
SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Używanie zasad połączenia przekierowania z prywatnymi punktami końcowymi
Zalecamy, aby klienci używali łącza prywatnego z zasadami połączenia przekierowania w celu zmniejszenia opóźnienia i zwiększenia przepływności. Aby połączenia używały tego trybu, klienci muszą spełnić następujące wymagania wstępne:
Zezwalaj na komunikację przychodzącą z siecią wirtualną hostująca prywatny punkt końcowy do zakresu portów od 1433 do 65535.
Zezwalaj na komunikację wychodzącą z sieci wirtualnej obsługującej klienta do zakresu portów od 1433 do 65535.
Użyj najnowszej wersji sterowników z wbudowaną obsługą przekierowania. Obsługa przekierowania jest uwzględniana w sterownikach ODBC, OLEDB, NET SqlClient Dostawca danych, Core .NET SqlClient Dostawca danych i JDBC (wersja 9.4 lub nowsza). Połączenia pochodzące ze wszystkich innych sterowników są przekierowywane przez serwer proxy.
Po spełnieniu wymagań wstępnych klienci muszą jawnie wybrać zasady przekierowywania połączeń.
Jeśli nie można zmodyfikować ustawień zapory, aby zezwolić na dostęp wychodzący w zakresie portów 1433-65535, alternatywnym rozwiązaniem jest zmiana zasad połączenia na serwer proxy.
Istniejące prywatne punkty końcowe używające domyślnych zasad połączenia będą używać zasad połączenia serwera proxy z portem 1433. Powodem tego jest uniknięcie zakłóceń w ruchu klienta z dotarcia do usługi SQL Database z powodu wymaganych zakresów portów dla przekierowania, które nie są otwarte.
Uwaga
W przypadku dedykowanych pul SQL zasady połączenia w przypadku korzystania z prywatnych punktów końcowych są zawsze serwerem proxy. Zmiana ustawienia nie będzie mieć wpływu na dedykowane pule SQL podczas korzystania z prywatnych punktów końcowych.
Łączność lokalna za pośrednictwem prywatnej komunikacji równorzędnej
Gdy klienci łączą się z publicznym punktem końcowym z maszyn lokalnych, ich adres IP musi zostać dodany do zapory opartej na adresie IP przy użyciu 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.
Dzięki usłudze Private Link klienci mogą włączyć dostęp między lokalizacjami do prywatnego punktu końcowego przy użyciu usługi ExpressRoute, prywatnej komunikacji równorzędnej lub tunelowania sieci VPN. Klienci mogą następnie wyłączyć cały dostęp za pośrednictwem publicznego punktu końcowego i nie używać zapory opartej na adresach IP, aby zezwolić na wszystkie adresy IP.
Przypadki użycia usługi Private Link dla usługi Azure SQL Database
Klienci mogą łączyć się z prywatnym punktem końcowym z tej samej sieci wirtualnej, równorzędnej sieci wirtualnej w tym samym regionie lub za pośrednictwem sieci wirtualnej do połączenia sieci wirtualnej w różnych regionach. Ponadto klienci mogą łączyć się ze środowiska lokalnego przy użyciu usługi ExpressRoute, prywatnej komunikacji równorzędnej lub tunelowania sieci 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. Aby uzyskać więcej informacji na temat tego konkretnego przypadku użycia, zobacz scenariusz dotyczący aplikacji internetowej z prywatną łącznością z architekturą bazy danych Azure SQL Database .
Nawiązywanie połączenia z maszyny wirtualnej platformy Azure w równorzędnej sieci wirtualnej
Skonfiguruj komunikację równorzędną sieci wirtualnych, aby nawiązać łączność z usługą SQL Database z maszyny wirtualnej platformy Azure w równorzędnej sieci wirtualnej.
Nawiązywanie połączenia z maszyny wirtualnej platformy Azure w sieci wirtualnej ze środowiskiem sieci wirtualnej
Skonfiguruj połączenie bramy sieci VPN sieci wirtualnej z siecią wirtualną w celu nawiązania łączności z bazą danych w usłudze SQL Database z maszyny wirtualnej platformy Azure w innym regionie lub subskrypcji.
Nawiązywanie połączenia ze środowiska lokalnego za pośrednictwem sieci VPN
Aby ustanowić łączność ze środowiska lokalnego do bazy danych w usłudze SQL Database, wybierz i zaimplementuj jedną z opcji:
Rozważmy również scenariusze konfiguracji DNS, ponieważ nazwa FQDN usługi może być rozpoznawana jako publiczny adres IP.
Nawiązywanie połączenia z usługi Azure Synapse Analytics z usługą Azure Storage przy użyciu technologii PolyBase i instrukcji COPY
Program PolyBase i instrukcja COPY są często używane do ładowania danych do usługi Azure Synapse Analytics z kont usługi Azure Storage. Jeśli konto usługi Azure Storage, z którego są ładowane dane, ogranicza dostęp tylko do zestawu podsieci sieci wirtualnej za pośrednictwem prywatnych punktów końcowych, punktów końcowych usługi lub zapór opartych na adresach IP, łączność z programu PolyBase i instrukcji COPY do konta zostanie przerwana. Aby włączyć scenariusze importowania i eksportowania za pomocą usługi Azure Synapse Analytics łączącej się z usługą Azure Storage, która jest zabezpieczona z siecią wirtualną, wykonaj kroki podane tutaj.
Data exfiltration prevention (Zapobieganie eksfiltracji danych)
Eksfiltracja danych w usłudze Azure SQL Database jest taka, gdy użytkownik, taki jak administrator bazy danych, może wyodrębniać dane z jednego systemu i przenosić je do innej lokalizacji lub systemu poza organizacją. Na przykład użytkownik przenosi dane na konto magazynu należące do jednostki innej niż Microsoft.
Rozważmy scenariusz z użytkownikiem z programem SQL Server Management Studio (SSMS) wewnątrz maszyny wirtualnej platformy Azure łączącej się z bazą danych w usłudze SQL Database. Ta baza danych znajduje się w centrum danych Zachodnie stany USA. W poniższym przykładzie pokazano, jak ograniczyć dostęp do publicznych punktów końcowych w usłudze SQL Database przy użyciu kontroli dostępu do sieci.
- Wyłącz cały ruch usługi platformy Azure do usługi SQL Database za pośrednictwem publicznego punktu końcowego, ustawiając ustawienie Zezwalaj usługom platformy Azure na wyłączone. Upewnij się, że w regułach zapory na poziomie serwera i bazy danych nie są dozwolone żadne adresy IP. Aby uzyskać więcej informacji, zobacz Azure SQL Database i Azure Synapse Analytics network access controls (Mechanizmy kontroli dostępu do sieci w usłudze Azure SYNApse Analytics).
- Zezwalaj tylko na ruch do bazy danych w usłudze SQL Database przy użyciu prywatnego adresu IP maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz artykuły dotyczące punktu końcowego usługi i reguł zapory sieci wirtualnej.
- Na maszynie wirtualnej platformy Azure zawęź zakres połączenia wychodzącego przy użyciu sieciowych grup zabezpieczeń i tagów usługi w następujący sposób.
- Określ regułę sieciowej grupy zabezpieczeń, aby zezwolić na ruch dla tagu usługi = SQL. Zachodnie jednostki — zezwalanie tylko na nawiązywanie połączenia z usługą SQL Database w regionie Zachodnie stany USA.
- Określ regułę sieciowej grupy zabezpieczeń (z wyższym priorytetem), aby blokować ruch dla tagu usługi = SQL — odmawianie połączeń z usługą SQL Database we wszystkich regionach.
Po zakończeniu tej konfiguracji maszyna wirtualna platformy Azure może łączyć się tylko z bazą danych w usłudze SQL Database w regionie Zachodnie stany USA. Jednak łączność nie jest ograniczona do pojedynczej bazy danych w usłudze SQL Database. Maszyna wirtualna nadal może łączyć się z dowolną bazą danych w regionie Zachodnie stany USA, w tym z bazami danych, które nie są częścią subskrypcji. Chociaż ograniczyliśmy zakres eksfiltracji danych w powyższym scenariuszu do określonego regionu, nie wyeliminowaliśmy ich całkowicie.
Dzięki usłudze Private Link klienci mogą teraz skonfigurować mechanizmy kontroli dostępu do sieci, takie jak sieciowe grupy zabezpieczeń, aby ograniczyć dostęp do prywatnego punktu końcowego. Poszczególne zasoby usługi Azure PaaS są następnie mapowane na określone prywatne punkty końcowe. Złośliwy tester może uzyskać dostęp tylko do zamapowanego zasobu PaaS (na przykład bazy danych w usłudze SQL Database) i żadnego innego zasobu.