Wykorzystaj punkty końcowe usługi sieci wirtualnej i reguły dla 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.

Dotyczy: dedykowane pule SQL usługi Azure Synapse Analytics

Reguły sieci wirtualnej to funkcja bezpieczeństwa zapory, która kontroluje, czy serwer logiczny dla Twojej dedykowanej puli SQL (dawniej SQL DW) baz danych w Azure Synapse Analytics akceptuje komunikację wysyłaną z określonych podsieci w sieciach wirtualnych. Ten artykuł wyjaśnia, dlaczego reguły sieci wirtualnej są czasem najlepszą opcją do bezpiecznego umożliwiania komunikacji z dedykowaną pulą SQL.

Aby utworzyć regułę sieci wirtualnej, najpierw musi istnieć punkt końcowy usługi sieci wirtualnej, do którego reguła może się odwoływać.

Tworzenie reguły sieci wirtualnej

Jeśli chcesz stworzyć tylko regułę sieci wirtualnej, możesz przejść od razu do kroków i wyjaśnień w dalszej części artykułu.

Szczegóły dotyczące zasad sieci wirtualnej

Ta sekcja opisuje kilka szczegółów dotyczących reguł sieci wirtualnej.

Tylko jeden region geograficzny

Każdy endpoint usługi sieci wirtualnej dotyczy tylko jednego regionu Azure. Punkt końcowy nie umożliwia innym regionom akceptowania komunikacji z podsieci.

Każda reguła sieci wirtualnej jest ograniczona do regionu, do którego odnosi się jej bazowy punkt końcowy.

Na poziomie serwera, a nie na poziomie bazy danych

Każda reguła sieci wirtualnej dotyczy całego serwera, a nie tylko jednej konkretnej bazy danych na serwerze. Innymi słowy, reguły sieci wirtualnej mają zastosowanie na poziomie serwera, a nie na poziomie bazy danych.

Role administracji zabezpieczeń

W administracji punktów końcowych usługi sieci wirtualnej występuje odrębność ról bezpieczeństwa. Od każdej z następujących ról wymagane jest działanie:

Alternatywa dla Azure RBAC

Role Network Admin i Database Admin mają więcej możliwości, niż jest to konieczne do zarządzania regułami sieci wirtualnych. Potrzebny jest tylko podzbiór ich możliwości.

Masz możliwość użycia kontroli dostępu opartej na rolach (RBAC) w Azure, aby stworzyć jedną niestandardową rolę, która zawiera tylko niezbędny podzbiór uprawnień. Rola niestandardowa może być używana zamiast angażowania administratora sieci lub administratora bazy danych. Zakres narażenia na zagrożenia bezpieczeństwa jest mniejszy, jeśli dodasz użytkownika do roli niestandardowej, zamiast dodać go do pozostałych dwóch głównych ról administratora.

Note

W niektórych przypadkach dedykowana pula SQL i podsieć sieci wirtualnej znajdują się w różnych subskrypcjach. W takich przypadkach należy zapewnić następujące konfiguracje:

  • Użytkownik posiada wymagane uprawnienia do inicjowania operacji, takie jak włączenie punktów końcowych usług oraz dodanie podsieci sieci wirtualnej do danego serwera.
  • Obie subskrypcje muszą mieć zarejestrowanego dostawcę Microsoft.Sql .

Limitations

Dla samodzielnych, dedykowanych pul SQL funkcja reguł sieci wirtualnej ma następujące ograniczenia:

  • W zaporze serwera logicznego każda reguła sieci wirtualnej odnosi się do podsieci. Wszystkie podsieci, do których istnieją odwołania, muszą być hostowane w tym samym regionie geograficznym co dedykowana pula SQL.
  • Każdy serwer może mieć do 128 wpisów ACL dla dowolnej sieci wirtualnej.
  • Reguły sieci wirtualnej dotyczą wyłącznie sieci wirtualnych Azure Resource Manager, a nie sieci modelu wdrażania klasycznego.
  • W zaporze zakresy adresów IP dotyczą następujących elementów sieciowych, ale reguły sieci wirtualnych nie:
  • Obie subskrypcje muszą być w tym samym dzierżawcy Microsoft Entra.

Uwagi przy korzystaniu z punktów końcowych usługi

Korzystając z punktów końcowych usług dla dedykowanej puli SQL, przejrzyj następujące kwestie:

  • Wymagany jest dostęp wychodzący do publicznych adres IP Azure Synapse Analytics. Grupy bezpieczeństwa sieciowego (NSG) muszą umożliwiać łączność z adresami IP usług. Możesz użyć tagu Sql NSG usługi.

ExpressRoute

Jeśli używasz ExpressRoute z własnej lokalizacji, do peeringu publicznego lub peeringu firmy Microsoft, musisz zidentyfikować używane adresy IP NAT. W przypadku public peering, każdy obwód ExpressRoute domyślnie używa dwóch adresów IP NAT stosowanych do ruchu usług Azure, gdy ruch trafia do szkieletu sieci Microsoft Azure. W przypadku peeringu Microsoft adresy IP NAT, które są używane, są dostarczane przez klienta lub dostawcę usług. Aby umożliwić dostęp do zasobów usługi, musisz zezwolić na te publiczne adresy IP w ustawieniu zapory adresu IP zasobu. Aby znaleźć adresy IP obwodów ExpressRoute w publicznych peeringach, otwórz zgłoszenie wsparcia w ExpressRoute przez portal Azure. Aby dowiedzieć się więcej o NAT dla ExpressRoute public i Microsoft peering, zobacz wymagania NAT dla Azure public peering.

Aby umożliwić komunikację z twojego łącza do Azure Synapse Analytics, musisz utworzyć reguły sieci IP dla publicznych adresów IP swojego NAT.

Wpływ wykorzystania punktów końcowych usługi sieci wirtualnej z Azure Storage

Usługa Azure Storage zaimplementowała tę samą funkcję, która umożliwia ograniczenie łączności z kontem usługi Azure Storage. Jeśli korzystasz z tej funkcji z kontem Azure Storage, którego używa Azure Synapse Analytics, możesz napotkać problemy.

Poniższe sekcje omawiają dotknięte funkcje Azure Synapse Analytics.

Azure Synapse Analytics PolyBase i instrukcja COPY

PolyBase oraz instrukcja COPY są powszechnie używane do ładowania danych do Azure Synapse Analytics z kont Azure Storage dla importu danych o wysokiej przepustowości. Jeśli konto Azure Storage, z którego ładujesz dane, ogranicza dostęp tylko do zestawu podsieci sieci wirtualnej, łączność podczas korzystania z PolyBase i instrukcji COPY z kontem usługi Azure Storage zostanie przerwana. Aby umożliwić scenariusze importu i eksportu za pomocą COPY i PolyBase przy użyciu usługi Azure Synapse Analytics łączącej się z usługą Azure Storage zabezpieczoną za pomocą sieci wirtualnej, postępuj zgodnie z krokami w tej sekcji.

Prerequisites

  • Zainstaluj program Azure PowerShell. Aby uzyskać więcej informacji, zobacz Instalowanie modułu Azure Az PowerShell.
  • Jeśli masz konto magazynu ogólnego przeznaczenia v1 lub konto usługi Azure Blob Storage, musisz najpierw uaktualnić je do konta magazynu ogólnego przeznaczenia w wersji v2, wykonując kroki opisane w artykule Uaktualnianie do konta magazynu ogólnego przeznaczenia w wersji v2.
  • Musisz mieć włączone Zezwalaj zaufanym usługom Microsoft na dostęp do tego konta magazynu w menu ustawień konta usługi Azure Storage Firewalls and Virtual networks. Aktywowanie tej konfiguracji pozwoli rozwiązaniu PolyBase i poleceniu COPY połączyć się z kontem pamięci masowej przy użyciu silnego uwierzytelniania, gdzie ruch sieciowy pozostaje w sieci szkieletowej platformy Azure. Więcej informacji znajdziesz w tym przewodniku.

Important

Moduł PowerShell Azure Resource Manager (AzureRM) został wycofany 29 lutego 2024 r. Wszystkie przyszłe programowanie powinno używać modułu Az.Sql. Zaleca się migrowanie użytkowników z modułu AzureRM do modułu Az programu PowerShell w celu zapewnienia ciągłej obsługi i aktualizacji. Moduł AzureRM nie jest już utrzymywany ani obsługiwany. Argumenty poleceń w module Az programu PowerShell i modułach AzureRM są zasadniczo identyczne. Aby uzyskać więcej informacji na temat ich zgodności, zobacz Wprowadzenie nowego modułu Az PowerShell.

Steps

  1. Jeśli masz samodzielną, dedykowaną pulę SQL (dawniej SQL DW), zarejestruj swój serwer SQL w usłudze Microsoft Entra ID, używając programu PowerShell:

    Connect-AzAccount
Select-AzSubscription -SubscriptionId <subscriptionId>
Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity

    Ten krok nie jest wymagany dla dedykowanych pul SQL w przestrzeni roboczej Azure Synapse Analytics. Tożsamość zarządzana przypisana przez system (SA-MI) obszaru roboczego jest członkiem roli Administratora usługi Synapse i w związku z tym ma podwyższony poziom uprawnień w dedykowanych pulach SQL obszaru roboczego.

  2. Utwórz konto magazynu ogólnego przeznaczenia w wersji 2, wykonując czynności opisane w artykule Utwórz konto magazynu.

  3. Na stronie swojego konta pamięci masowej wybierz Kontrolę dostępu (IAM).

  4. Wybierz Dodaj>Dodaj przypisanie roli, aby otworzyć stronę Dodaj przypisanie roli.

  5. Przypisz następującą rolę. Aby uzyskać szczegółowe instrukcje, zobacz Przypisywanie ról platformy Azure za pomocą portalu Azure.

    Setting Value
    Rola Współautor danych w usłudze Storage Blob
    Przypisz dostęp do Użytkownik, grupa lub jednostka usługi
    Members Serwer lub przestrzeń robocza hostująca dedykowaną pulę SQL, które zarejestrowano w Microsoft Entra ID

    Zrzut ekranu przedstawiający stronę do dodawania przypisania roli w portalu Azure.

    Note

    Tylko członkowie posiadający uprawnieniem Owner na koncie magazynu mogą wykonać ten krok. W przypadku różnych wbudowanych ról Azure, zobacz wbudowane role Azure.

  6. Aby umożliwić łączność PolyBase z kontem Azure Storage:

    1. Utwórz klucz główny bazy danych, jeśli wcześniej go nie utworzono.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = '<password>'];

    2. Stwórz dane uwierzytelniające o zakresie bazy danych z IDENTITY = 'Managed Service Identity'.

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';

      • Nie ma potrzeby określania SECRET za pomocą klucza dostępu Azure Storage, ponieważ ten mechanizm wykorzystuje Managed Identity wewnętrznie. Ten krok nie jest wymagany dla dedykowanych pul SQL w przestrzeni roboczej Azure Synapse Analytics. Tożsamość zarządzana przypisana przez system (SA-MI) obszaru roboczego jest członkiem roli Administratora usługi Synapse i w związku z tym ma podwyższony poziom uprawnień w dedykowanych pulach SQL obszaru roboczego.

      • Nazwa IDENTITY musi brzmieć 'Managed Service Identity', aby łączność PolyBase mogła działać z kontem Azure Storage zabezpieczonym w sieci wirtualnej.

    3. Stwórz zewnętrzne źródło danych przy użyciu schematu abfss:// do łączenia się z Twoim kontem magazynu ogólnego przeznaczenia w wersji 2 za pomocą PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      • Jeśli masz już zewnętrzne tabele powiązane z kontem ogólnego przeznaczenia v1 lub Blob Storage, najpierw powinieneś usunąć te zewnętrzne tabele. Następnie usuń odpowiadające mu zewnętrzne źródło danych. Następnie utwórz zewnętrzne źródło danych z protokołem abfss://, połączone ze kontem magazynu ogólnego przeznaczenia w wersji 2, jak pokazano wcześniej. Następnie odtwórz wszystkie zewnętrzne tabele, korzystając z tego nowego zewnętrznego źródła danych. Możesz użyć kreatora Generowania i publikowania skryptów, aby wygenerować skrypty tworzenia dla wszystkich tabel zewnętrznych dla ułatwienia.
      • Więcej informacji o tym schemacie URI abfss:// można znaleźć w artykule Użyj identyfikatora URI Azure Data Lake Storage Gen2.
      • Więcej informacji o poleceniach T-SQL można znaleźć w artykule CREATE EXTERNAL DATA SOURCE.

    4. Zapytuj normalnie, używając zewnętrznych tabel.

Inspekcja Azure Synapse Analytics w usłudze blob storage

Audyt Azure Synapse Analytics może zapisywać logi audytowe SQL na Twoje własne konto magazynu. Jeśli to konto magazynu wykorzystuje funkcję punktów końcowych usługi sieci wirtualnej, sprawdź, jak zapisywać dzienniki inspekcji na koncie magazynu za siecią VNet i zaporą.

Dodaj regułę zapory sieci wirtualnej do serwera SQL dedykowanej puli SQL

Dawno temu, zanim ta funkcja została ulepszona, trzeba było włączyć punkty końcowe usługi sieci wirtualnej, zanim można było wdrożyć aktywną regułę sieci wirtualnej w zaporze. punkty końcowe łączą daną podsieć sieci wirtualnej z dedykowaną pulą SQL. Od stycznia 2018 roku można obejść ten wymóg, ustawiając flagę IgnoreMissingVNetServiceEndpoint . Teraz możesz dodać regułę zapory w sieci wirtualnej na swoim serwerze bez włączania punktów końcowych usług sieci wirtualnej.

Samo ustawienie reguły zapory nie pomaga zabezpieczyć serwera. Musisz także włączyć punkty końcowe usług sieci wirtualnej, aby zabezpieczenia zaczęły działać. Gdy włączasz punkty końcowe usługi, w podsieci sieci wirtualnej występuje przestój, dopóki nie zakończy się przejście ze stanu wyłączonego do włączonego. Ten okres przestojów jest szczególnie widoczny w kontekście dużych sieci wirtualnych. Możesz użyć flagi IgnoreMissingVNetServiceEndpoint , aby zmniejszyć lub wyeliminować przestoj podczas przejścia.

Możesz ustawić flagę IgnoreMissingVNetServiceEndpoint za pomocą PowerShell. Więcej informacji można znaleźć w New-AzSqlServerVirtualNetworkRule.

Użyj portalu Azure do stworzenia reguły sieci wirtualnej

Note

Te instrukcje reguł sieci wirtualnej dotyczą samodzielnych dedykowanych pul SQL. Aby uzyskać konfigurację sieci workspace, zobacz Azure Synapse Analytics IP firewall rules.

W tej sekcji dowiesz się, jak możesz użyć portalu Azure do stworzenia reguły sieci wirtualnej dla samodzielnej, dedykowanej puli SQL. Reguła nakazuje serwerowi logicznemu zaakceptować komunikację z konkretnej podsieci, która została oznaczona jako punkt końcowy usługi sieci wirtualnej.

Note

Jeśli zamierzasz dodać punkt końcowy usługi do reguł zapory w sieci wirtualnej na serwerze, najpierw upewnij się, że punkty końcowe usług są włączone dla podsieci.

Jeśli punkty końcowe usług nie są włączone dla podsieci, portal prosi o ich włączenie. Wybierz przycisk Włącz na tym samym panelu, w którym dodajesz regułę.

Prerequisites

Musisz już mieć podsieć oznaczoną endpointem usługi sieci wirtualnej nazwa typu, używaną przez Azure Synapse Analytics.

Kroki w portalu Azure

  1. Zaloguj się do portalu Azure.

  2. Wyszukaj i wybierz serwery SQL, a następnie wybierz swój serwer. W obszarze Zabezpieczenia wybierz pozycję Sieć.

  3. W zakładce Dostęp publiczny upewnij się, że dostęp do sieci publicznej jest ustawiony na Wybrane sieci, w przeciwnym razie ustawienia sieci wirtualnych są ukryte. Wybierz + Dodaj istniejącą sieć wirtualną w sekcji Sieci wirtualne .

  4. W nowym panelu Create/Update wpisz w pola nazwy swoich zasobów Azure.

    Wskazówka

    Musisz podać poprawny prefiks adresu dla swojej podsieci. Wartość prefiks Adres znajdziesz w portalu. Przejdź do Wszystkie zasoby>Wszystkie typy>sieci wirtualnych. Filtr wyświetla twoje wirtualne sieci. Wybierz swoją sieć wirtualną, a następnie wybierz Podsieci. Kolumna ZAKRES ADRESÓW zawiera potrzebny prefiks adresu.

  5. Zobacz powstałą regułę sieci wirtualnej na panelu Firewall .

  6. Ustaw opcję Zezwalaj usługom i zasobom Azure na dostęp do tego serwera na Nie.

    Important

    Jeśli zostawisz zaznaczone opcję Zezwalaj usługom i zasobom Azure na dostęp do tego serwera, Twój serwer akceptuje komunikację z dowolnej podsieci wewnątrz granicy Azure. To komunikacja pochodząca z jednego z adresów IP rozpoznawanych jako te w zakresach zdefiniowanych dla centrów danych Azure. Pozostawienie włączonego elementu sterującego może stanowić nadmierny dostęp z punktu widzenia bezpieczeństwa. Funkcja punktów końcowych usług Microsoft Azure Virtual Network, wraz z regułami sieci wirtualnej Azure Synapse Analytics, może zmniejszyć powierzchnię ataku.

  7. Wybierz przycisk OK blisko dołu panelu.

Note

Do tych zasad mają zastosowanie następujące statusy lub stany:

  • Gotowy: Oznacza, że operacja, którą zainiestowałeś, zakończyła się sukcesem.
  • Niepowodzenie: Oznacza, że operacja, którą zainicjowałeś, zakończyła się niepowodzeniem.
  • Usunięto: Dotyczy Delete tylko operacji i oznacza, że reguła została usunięta i już nie obowiązuje.
  • W trakcie: Wskazuje, że operacja jest w toku. Stara zasada obowiązuje, gdy operacja znajduje się w tym stanie.

Użyj PowerShell do stworzenia reguły sieci wirtualnej

Skrypt może również tworzyć reguły sieci wirtualnych, korzystając z polecenia cmdlet programu PowerShell New-AzSqlServerVirtualNetworkRule lub az network vnet create. Więcej informacji można znaleźć w New-AzSqlServerVirtualNetworkRule.

Użyj REST API do stworzenia reguły sieci wirtualnej

Wewnętrznie polecenia cmdlet programu PowerShell dla akcji sieci wirtualnej usługi Synapse SQL wywołują interfejsy API REST. Możesz bezpośrednio wywołać API REST. Więcej informacji można znaleźć w artykule Reguły sieci wirtualnej: Operacje.

Diagnostyka błędów 40914 i 40615

Błąd połączenia 40914 dotyczy reguł sieci wirtualnej, określonych w panelu Firewall w portalu Azure.
Błąd 40615 jest podobny, z tą różnicą, że dotyczy reguł adresów IP na zaporze.

Błąd 40914

Tekst wiadomości: "Nie można otworzyć serwera '[server-name]' żądanego przez logowanie. Klient nie może uzyskać dostępu do serwera”.

Opis błędu: Klient znajduje się w podsieci, która ma punkty końcowe serwera sieci wirtualnej. Jednak serwer nie posiada reguły sieci wirtualnej, która przyznawałaby podsieci prawo do komunikacji z bazą danych.

Rozwiązywanie błędów: Na panelu Firewall portalu Azure użyj kontroli reguł sieci wirtualnej, aby dodać regułę sieci wirtualnej dla podsieci.

Błąd 40615

Tekst wiadomości: "Nie można otworzyć serwera „{0}” żądanego przez logowanie. Klient o adresie IP „{1}” nie może uzyskać dostępu do serwera”.

Opis błędu: Klient próbuje połączyć się z adresu IP, który nie jest autoryzowany do połączenia z serwerem. Zapora serwera nie posiada reguły adresów IP, która pozwala klientowi z podanego adresu IP komunikować się z bazą danych.

Rozwiązywanie błędów: Wprowadź adres IP klienta jako regułę IP. Użyj panelu Firewall w portalu Azure, aby wykonać ten krok.

Treści powiązane

  • Ostatnia aktualizacja o