Zabezpieczanie dedykowanej puli SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics

Tip

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.

• Rozpocznij darmowy okres próbny Fabric.
• Asystent migracji dla Fabric Data Warehouse.

• Przegląd zabezpieczeń
• Authentication
• Szyfrowanie (portal)
• Szyfrowanie (T-SQL)

W tym artykule przedstawiono podstawy zabezpieczania dedykowanej puli SQL (dawniej SQL DW). W szczególności ten artykuł umożliwia rozpoczęcie pracy z zasobami dotyczącymi ograniczania dostępu, ochrony danych i monitorowania działań przy użyciu dedykowanej puli SQL (dawniej SQL DW).

Zabezpieczenia połączeń

Zabezpieczenia połączeń odnoszą się do sposobu ograniczania i zabezpieczania połączeń z bazą danych przy użyciu reguł zapory i szyfrowania połączeń.

Reguły zapory są używane zarówno przez logiczny serwer SQL , jak i jego bazy danych do odrzucania prób połączenia z adresów IP, które nie zostały jawnie zatwierdzone. Aby zezwolić na połączenia z publicznego adresu IP aplikacji lub komputera klienckiego, należy najpierw utworzyć regułę zapory na poziomie serwera przy użyciu witryny Azure Portal, interfejsu API REST lub programu PowerShell.

Najlepszym rozwiązaniem jest ograniczenie zakresów adresów IP dozwolonych przez zaporę na poziomie serwera, jak najwięcej. Aby uzyskać dostęp do dedykowanej puli SQL (dawniej SQL DW) z komputera lokalnego, upewnij się, że zapora w sieci i komputerze lokalnym zezwala na komunikację wychodzącą na porcie TCP 1433.

Dedykowana pula SQL (dawniej SQL DW) używa reguł zapory adresów IP na poziomie serwera. Nie obsługuje reguł zapory adresów IP na poziomie bazy danych. Aby uzyskać więcej informacji, zobacz Reguły zapory usługi Azure SQL Database

Połączenia z dedykowaną pulą SQL (dawniej SQL DW) są domyślnie szyfrowane. Modyfikowanie ustawień połączenia w celu wyłączenia szyfrowania jest ignorowane.

Uwierzytelnianie

Uwierzytelnianie odnosi się do sposobu potwierdzenia tożsamości podczas nawiązywania połączenia z bazą danych. Dedykowana pula SQL (dawniej SQL DW) obsługuje obecnie uwierzytelnianie programu SQL Server przy użyciu nazwy użytkownika i hasła oraz identyfikatora Entra firmy Microsoft.

Podczas tworzenia serwera dla bazy danych określono identyfikator logowania "administrator serwera" z nazwą użytkownika i hasłem. Korzystając z tych poświadczeń, można zalogować się do dowolnej bazy danych na tym serwerze jako właściciel bazy danych lub "dbo" za pomocą uwierzytelniania SQL Server.

Jednak zgodnie z najlepszymi rozwiązaniami użytkownicy organizacji powinni używać innego konta do uwierzytelniania. W ten sposób można ograniczyć uprawnienia przyznane aplikacji i zmniejszyć ryzyko złośliwego działania w przypadku, gdy kod aplikacji jest narażony na atak polegający na wstrzyknięciu kodu SQL.

Aby utworzyć użytkownika uwierzytelnionego programu SQL Server, połącz się z bazą danych master na serwerze przy użyciu identyfikatora logowania administratora serwera i utwórz nowy identyfikator logowania serwera. Dobrym pomysłem jest również utworzenie użytkownika w bazie danych master. Tworzenie użytkownika w bazie danych master umożliwia użytkownikowi logowanie się przy użyciu narzędzi takich jak SSMS bez określania nazwy bazy danych. Umożliwia również korzystanie z Eksploratora obiektów do wyświetlania wszystkich baz danych na serwerze.

-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Następnie połącz się z dedykowaną pulą SQL (dawniej SQL DW) przy użyciu identyfikatora logowania administratora serwera i utwórz użytkownika bazy danych na podstawie utworzonego identyfikatora logowania serwera.

-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Aby nadać użytkownikowi uprawnienia do wykonywania dodatkowych operacji, takich jak tworzenie identyfikatorów logowania lub tworzenie nowych baz danych, przypisz użytkownika do ról Loginmanager i dbmanager w bazie danych master.

Aby uzyskać więcej informacji na temat tych dodatkowych ról i uwierzytelniania w usłudze SQL Database, zobacz Zarządzanie bazami danych i identyfikatorami logowania w usłudze Azure SQL Database. Aby uzyskać więcej informacji na temat nawiązywania połączenia przy użyciu identyfikatora Entra firmy Microsoft, zobacz Connecting by using Microsoft Entra authentication (Łączenie przy użyciu uwierzytelniania firmy Microsoft Entra).

Autoryzacja

Autoryzacja odnosi się do tego, co można zrobić w bazie danych po uwierzytelnieniu i nawiązaniu połączenia. Uprawnienia autoryzacji są określane przez przynależność do ról i przywileje. Najlepszym rozwiązaniem jest przyznanie użytkownikom najmniejszych niezbędnych uprawnień. Do zarządzania rolami można użyć następujących procedur składowanych:

EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data

Konto administratora serwera, z którym nawiązujesz połączenie, jest członkiem db_owner, który ma uprawnienia do wykonywania dowolnych czynności w bazie danych. Zapisz to konto na potrzeby wdrażania uaktualnień schematu i innych operacji zarządzania. Użyj konta "ApplicationUser" z bardziej ograniczonymi uprawnieniami, aby połączyć się z bazą danych z poziomu aplikacji, korzystając z najmniejszych niezbędnych uprawnień.

Istnieją sposoby dalszego ograniczania możliwości użytkownika w bazie danych:

• Szczegółowe uprawnienia umożliwiają kontrolowanie operacji, które można wykonywać w poszczególnych kolumnach, tabelach, widokach, schematach, procedurach i innych obiektach w bazie danych. Użyj szczegółowych uprawnień, aby mieć największą kontrolę i przyznać minimalne uprawnienia niezbędne.
• Role bazy danych inne niż db_datareader i db_datawriter mogą służyć do tworzenia bardziej zaawansowanych kont użytkowników aplikacji lub mniej zaawansowanych kont zarządzania. Wbudowane stałe role bazy danych zapewniają łatwy sposób udzielania uprawnień, ale może spowodować przyznanie większej liczby uprawnień, niż jest to konieczne.
• Procedury składowane mogą służyć do ograniczania akcji, które można wykonać w bazie danych.

Poniższy przykład zapewnia dostęp do odczytu do schematu zdefiniowanego przez użytkownika.

--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser

Zarządzanie bazami danych i serwerami w portalu Azure lub za pomocą interfejsu API usługi Azure Resource Manager jest kontrolowane przez przypisania ról przypisane do konta użytkownika w portalu. Aby uzyskać więcej informacji, zobacz przypisywanie ról Azure za pomocą portalu Azure.

Zabezpieczenia na poziomie wiersza

Zabezpieczenia na poziomie wiersza umożliwiają kontrolę dostępu do wierszy w tabeli bazy danych w oparciu o cechy użytkownika, który wykonuje zapytanie (na przykład członkostwo w grupie lub kontekst wykonywania zapytania). Użyj Row-Level Security, aby zaimplementować niestandardowe pojęcia zabezpieczeń oparte na etykietach. Aby uzyskać więcej informacji, zapoznaj się z Zabezpieczenia na poziomie wierszy.

Szyfrowanie

Funkcja Transparent Data Encryption (TDE) pomaga chronić przed zagrożeniem złośliwym działaniem poprzez szyfrowanie i odszyfrowywanie danych w spoczynku. Podczas szyfrowania bazy danych skojarzone kopie zapasowe i pliki dziennika transakcji są szyfrowane bez konieczności wprowadzania żadnych zmian w aplikacjach. Funkcja TDE szyfruje magazyn całej bazy danych przy użyciu klucza symetrycznego nazywanego kluczem szyfrowania bazy danych.

W usłudze SQL Database klucz szyfrowania bazy danych jest chroniony przez wbudowany certyfikat serwera. Wbudowany certyfikat serwera jest unikatowy dla każdego serwera. Firma Microsoft automatycznie wymienia te certyfikaty co najmniej co 90 dni. Używany algorytm szyfrowania to AES-256. Aby uzyskać ogólny opis funkcji TDE, zobacz Transparent Data Encryption.

Bazę danych można zaszyfrować przy użyciu witryny Azure Portal lub języka T-SQL.

Przezroczyste szyfrowanie danych (szyfrowanie danych w spoczynku) przy użyciu kluczy zarządzanych przez klienta

Jeśli potrzebujesz większej kontroli nad kluczami szyfrującymi, Transparent Data Encryption dla Azure Synapse Analytics obsługuje klucze zarządzane przez klienta (CMK). Ten klucz cmK jest skojarzony z serwerem logicznym i opakowuje klucze szyfrowania bazy danych dla wszystkich baz danych na tym serwerze. Zarządzając kluczem cmK, można kontrolować rotację, odwoływanie i inspekcję kluczy, co jest często konieczne w przypadku zgodności lub rygorystycznych zasad zabezpieczeń.

Transport Layer Security (szyfrowanie podczas przesyłania)

Azure Synapse Analytics zabezpiecza dane klientów poprzez szyfrowanie danych w ruchu za pomocą Transport Layer Security (TLS). Azure Synapse Analytics zawsze wymusza szyfrowanie połączeń TLS, aby zapewnić, że wszystkie dane są szyfrowane podczas przesyłania między klientem a serwerem.

Konkretnie, Azure Synapse Analytics ustawia flagę konfiguracyjną ForceEncryption na Yes. Klienci i kierowcy muszą obsługiwać szyfrowane połączenia, aby połączyć się z tą usługą. Najniższa wersja protokołu TDS, który może się połączyć, to TDS 7.1.

Najlepszym rozwiązaniem jest użycie ścisłego szyfrowania połączeń w przypadku sterowników SQL obsługujących usługę TDS 8.0.

Jeśli sterowniki nie obsługują TDS 8.0, użyj obowiązkowego szyfrowania i nie ufaj certyfikatowi serwera. Na przykład w przypadku używania sterownika ADO.NET użyj Encrypt=True i TrustServerCertificate=False w parametrach połączenia, aby to osiągnąć. Parametry połączenia uzyskiwane z witryny Azure Portal są już skonfigurowane przy użyciu tych wartości.

Unikaj ustawiania parametru TrustServerCertificate na True wartość w środowisku produkcyjnym. TrustServerCertificate=True jest zbyt permissive i nie chroni przed atakami man-in-the-middle. Zamiast tego, jeśli klient oczekuje innej nazwy domeny w certyfikacie serwera, użyj parametru HostNameInCertificate , aby podać poprawną nazwę domeny do weryfikacji.

Important

Niektóre sterowniki innych niż Microsoft mogą domyślnie nie używać protokołu TLS lub mogą polegać na starszej wersji protokołu TLS (starszej niż 1.2) do działania. W takim przypadku serwer nadal umożliwia nawiązanie połączenia z bazą danych. Jednak oceń ryzyko bezpieczeństwa związane z dopuszczeniem takich sterowników i aplikacji na łączenie się, zwłaszcza jeśli przechowujesz wrażliwe dane.

Następne kroki

Aby uzyskać szczegółowe informacje i przykłady dotyczące nawiązywania połączenia z magazynem przy użyciu różnych protokołów, zobacz Nawiązywanie połączenia z dedykowaną pulą SQL (dawniej SQL DW).