Zadania i funkcje zabezpieczeń
Program SQL Server i usługa Azure SQL słyną z nacisku, jaki jest w nich kładziony na zabezpieczenia, szczególnie z tego, że są to rozwiązania korporacyjne. W tej lekcji dowiesz się więcej o różnych funkcjach zabezpieczeń związanych z zabezpieczeniami sieci i zarządzaniem dostępem. W kolejnych lekcjach uzyskasz praktyczne doświadczenie z niektórymi z tych funkcji.
Bezpieczeństwo sieci
Pierwsza warstwa zabezpieczeń obejmuje sieć. Możliwości i zadania sieciowe różnią się między usługą Azure SQL Database i usługą Azure SQL Managed Instance. Aby uzyskać informacje na temat możliwości sieciowych usługi Azure SQL Managed Instance, zobacz Połączenie ivity architecture for Azure SQL Managed Instance (Architektura Połączenie ivity dla usługi Azure SQL Managed Instance).
Zabezpieczenia sieciowe usługi Azure SQL Database
W przypadku zabezpieczania sieci dla usługi Azure SQL Database są dostępne cztery główne opcje:
- Zezwalanie na dostęp usługom platformy Azure
- Korzystanie z reguł zapory
- Używanie reguł sieci wirtualnej
- Używanie usługi Azure Private Link
Oprócz tych głównych opcji możesz zablokować cały dostęp publiczny (tylko za pomocą usługi Azure Private Link) i opcję wymuszenia minimalnej wersji protokołu Transport Layer Security (TLS). Metoda najmniej bezpieczna, ale najłatwiejsza do skonfigurowania, umożliwia dostęp do usług platformy Azure. Najbezpieczniejsza metoda polega na użyciu usługi Private Link. Poniższe sekcje zawierają informacje na temat możliwości poszczególnych opcji, a także sposobów konfigurowania i obsługi tych opcji.
Zezwalanie na dostęp usługom platformy Azure
Podczas wdrażania usługi Azure SQL Database możesz ustawić opcję Zezwalaj usługom i zasobom platformy Azure na dostęp do tego serwera na wartość Tak. W przypadku wybrania tej opcji zapewniasz dowolnym zasobom z dowolnego regionu lub subskrypcji możliwość uzyskiwania dostępu do Twojego zasobu. Ta opcja ułatwia rozpoczęcie pracy i zapewnienie usłudze Azure SQL Database połączenia z innymi usługami, takimi jak Azure Virtual Machines, Azure App Service albo nawet usługa Azure Cloud Shell, ponieważ zezwala się na nawiązywanie połączenia dowolnym obiektom, które korzystają z pośrednictwa platformy Azure.
Zezwolenie na dostęp usługom platformy Azure nie zezwala jednak na dostęp niczemu spoza platformy Azure (jak na przykład środowisko lokalne).
Najbezpieczniejsza konfiguracja polega na ustawieniu opcji Zezwalaj usługom i zasobom platformy Azure na ten serwer na wartość Nie, co blokuje wszystkie połączenia i sieci oprócz tych, które zostały jawnie dodane z różnymi opcjami, które są dostępne w następnych sekcjach.
Reguły zapory
Kolejną opcją jest zastosowanie reguł zapory. Wyniki mogą być podobne do tych z zezwalania usługom i zasobom platformy Azure na dostęp do tego serwera , z tą różnicą, że dla każdej usługi (na poniższej ilustracji maszyna wirtualna) należy dodać unikatową regułę zapory, aby zezwolić na nawiązywanie połączenia. Reguły zapory umożliwiają również środowisko lokalne nawiązywanie połączenia z zasobem usługi Azure SQL Database, ponieważ można dodać reguły dla maszyn i aplikacji w środowisku lokalnym.
Aby uzyskać łączność na platformie Azure, możesz również zezwolić na dostęp usługom platformy Azure, a następnie dodać reguły zapory tylko w celu obsługi łączności dla środowiska lokalnego. Jak wspomniano wcześniej, pozycja Zezwalaj usługom i zasobom platformy Azure na dostęp do tego serwera nie jest tak bezpieczna, ponieważ zezwala na cały ruch platformy Azure. Zalecamy używanie reguł zapory wyłącznie.
Przyjrzyjmy się poprzedniego przykładowi ze skonfigurowanymi regułami zapory. Za pomocą narzędzia obsługującego język Transact-SQL (T-SQL), takiego jak SQL Server Management Studio (SSMS), możesz uruchomić następujące zapytanie z maszyny wirtualnej platformy Azure w sieci wirtualnej SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Wynik będzie następujący: 174.17.218.16. Jest to publiczny adres IP maszyny wirtualnej platformy Azure. Mimo że są używane reguły zapory, wszystkie nawiązywane połączenia są publiczne.
Reguły sieci wirtualnej
Jeśli chcesz używać tylko reguł zapory, konfigurowanie może być skomplikowane. Użycie tylko reguł zapory oznacza, że należy określić zakres adresów IP dla wszystkich połączeń, które czasami mogą mieć dynamiczne adresy IP. Znacznie łatwiejszą alternatywą jest użycie reguł sieci wirtualnej w celu ustanowienia dostępu z określonych sieci zawierających maszyny wirtualne lub inne usługi, które muszą uzyskiwać dostęp do danych i zarządzać nimi.
W przypadku skonfigurowania dostępu z sieci wirtualnej przy użyciu reguły sieci wirtualnej wszystkie zasoby w tej sieci wirtualnej mogą uzyskiwać dostęp do serwera logicznego usługi Azure SQL Database. Może to uprościć wyzwanie związane z konfigurowaniem dostępu do wszystkich statycznych i dynamicznych adresów IP, które muszą uzyskiwać dostęp do danych. Używając reguł sieci wirtualnej, można określić jedną lub wiele sieci wirtualnych z uwzględnieniem wszystkich zawartych w nich zasobów. Można też zacząć stosować technologie sieci wirtualnych, aby łączyć sieci w różnych regionach zarówno na platformie Azure, jak i lokalnie.
W tym przykładzie, tak jak w poprzedniej sekcji, można wykonać to samo zapytanie co z maszyny wirtualnej platformy Azure w sieci wirtualnej SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Teraz wynik będzie następujący: 10.0.0.2. Jest to prywatny adres IP maszyny wirtualnej platformy Azure. Ten wynik przybliża nas o krok do nawiązywania połączeń prywatnych z serwerem logicznym usługi Azure SQL Database, ponieważ zasoby nawiązują teraz połączenie za pomocą sieci wirtualnej.
Inną typową strategią analizowania połączenia jest przeanalizowanie hierarchii systemu nazw domen (DNS, Domain Name System). Na tej samej maszynie wirtualnej platformy Azure w wierszu polecenia można uruchomić następujące polecenie:
nslookup aw-server.database.windows.net
Używając tego polecenia, można uzyskać szczegółowe informacje dotyczące infrastruktury DNS. Wyniki będą podobne do następujących:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
W odpowiedzi nieautorytatywnej należy przyjrzeć się kilku ważnym elementom:
- Nazwa: punkt końcowy rozpoczynający się od
cr2jest częścią publicznej hierarchii DNS. Bez zbyt dużej ilości danych w hierarchii załóżmy, żecr2jest to pierścień kontrolny 2 i że poniżej znajduje się wiele wycinków danych. - Adres: zwrócony tutaj adres IP powinien być zgodny z publicznym adresem IP maszyny wirtualnej platformy Azure. Chociaż ostatni przeskok programu SSMS może dotyczyć prywatnego adresu IP maszyny wirtualnej, publiczny adres IP maszyny wirtualnej jest nadal używany do łączenia się w pewnej pojemności.
- Aliasy: Aliasy są różnymi punktami w hierarchii DNS. W tym przypadku określone dane "slice" i punkt końcowy, z którymi nawiązujesz połączenie.
Uwaga
W poprzednim bloku danych wyjściowych adres: 168.63.129.16 jest wirtualnym publicznym adresem IP używanym do ułatwienia kanału komunikacji z zasobami platformy Azure. Ma on zastosowanie do wszystkich regionów oraz wszystkich chmur narodowych i nie ulegnie to zmianie.
Mimo że połączenie za pośrednictwem programu SSMS przechodzi przez prywatny adres IP maszyny wirtualnej platformy Azure, nadal łączysz się za pośrednictwem publicznego punktu końcowego.
Usługa Private Link dla usługi Azure SQL Database
Pokazano, jak skonfigurować najbezpieczniejszą sieć przy użyciu bazy danych w usłudze Azure SQL Database z publicznym punktem końcowym. Tej metody zabezpieczania bazy danych w usłudze SQL Database używa się od lat. Jednak w 2019 roku na platformie Azure rozpoczęło się przechodzenie w kierunku koncepcji łącza prywatnego, Private Link, co bardziej przypomina sposób wdrażania usługi Azure SQL Managed Instance. Za pomocą usługi Azure Private Link możesz nawiązać połączenie z bazą danych w usłudze SQL Database i kilkoma innymi ofertami typu "platforma jako usługa" (PaaS) przy użyciu prywatnego punktu końcowego. Oznacza to, że ma on prywatny adres IP w ramach konkretnej sieci wirtualnej.
W poprzednim przykładzie zauważysz, że ogólna infrastruktura sieciowa nie uległa zmianie i nadal można zastosować strategie łączności sieci wirtualnej z reguł sieci wirtualnej. Nie trzeba jednak tworzyć reguł sieci wirtualnej. Zasoby, które muszą łączyć się z serwerem bazy danych, muszą mieć dostęp do sieci wirtualnej, w której znajduje się ten punkt końcowy. W tym przykładzie punkt końcowy to SQLDBVNet-EUS. Dostęp mają tylko połączenia przechodzące przez prywatny punkt końcowy — wszystkie inne połączenia (na przykład z Internetu) są odrzucane.
W miarę kontynuowania pracy z tym przykładem na maszynie wirtualnej platformy Azure w sieci SQLDBVNet-EUSwirtualnej można ponownie uruchomić następujące polecenie języka T-SQL:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Wynikiem będzie teraz 10.0.0.2, czyli prywatny adres IP maszyny wirtualnej platformy Azure w tym przykładzie. Dodanie dostępu z sieci wirtualnej spowoduje wyświetlenie połączeń z usługą Azure SQL Database z maszyny wirtualnej za pośrednictwem prywatnego adresu IP maszyny wirtualnej. Jest to ten sam wynik, z którym mieliśmy do czynienia w przypadku reguł sieci wirtualnej.
Można jednak przyjrzeć się hierarchii DNS, używając następującego polecenia w wierszu polecenia:
nslookup aw-server.database.windows.net
Jeśli użyjesz poprzedniego polecenia, wyniki uzyskane ze skonfigurowanym prywatnym punktem końcowym będą nieco inne:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
W odpowiedzi nieautorytatywnej należy przyjrzeć się kilku ważnym elementom:
- Nazwa: Pamiętaj, że nie wskazujesz już publicznej hierarchii DNS tylko na dns usługi Private Link. Oznacza to, że ujawnianych jest mniej informacji o serwerze bazy danych.
- Adresy: w przypadku reguł sieci wirtualnej zwracany adres to publiczny adres IP maszyny wirtualnej, ale powinien być teraz co najmniej jednym prywatnym adresem IP w hierarchii usługi Private Link (jest to prywatny punkt końcowy usługi Azure SQL Database).
- Aliasy: podobnie jak w polu Nazwa nic nie jest powiązane z hierarchią DNS, z tą różnicą, że nadal można nawiązać połączenie z nazwą serwera (na przykład
aw-server.database.windows.net).
Jedną z rzeczy, które można zastanawiać się, czy łączysz się z prywatnym punktem końcowym, jest to , dlaczego nadal używasz tej samej nazwy serwera? W zapleczu, gdy używasz tylko metody usługi Private Link podczas nawiązywania połączenia z usługą Azure SQL Database (czyli bez reguł zapory ani sieci wirtualnej), informacje są przetwarzane w następujący sposób:
aw-server.database.windows.net- Usługa rozpoznaje to jako
aw-server.privatelink.database.net- Usługa rozpoznaje to jako
10.0.0.5(adres IP prywatnego punktu końcowego)
- Usługa rozpoznaje to jako
- Usługa rozpoznaje to jako
Ponadto usługa zablokuje możliwość bezpośredniego łączenia się przy użyciu czegokolwiek innego niż aw-server.database.windows.net.
Zarządzanie dostępem
Po wypracowaniu dostępu do sieci kolejna warstwa do rozważenia to zarządzanie dostępem.
Kontrola dostępu oparta na rolach
Wszystkie typy operacji platformy Azure dla usługi Azure SQL Database są kontrolowane za pomocą kontroli dostępu opartej na rolach (RBAC). Kontrola dostępu oparta na rolach jest obecnie oddzielona od zabezpieczeń usługi Azure SQL, ale można traktować ją jako prawa zabezpieczeń spoza bazy danych w usłudze SQL Database z zakresem obejmującym subskrypcję, grupę zasobów i zasób. Prawa dotyczą operacji w witrynie Azure Portal, interfejsie wiersza polecenia platformy Azure i programie Azure PowerShell. Kontrola dostępu na podstawie ról umożliwia rozdzielenie obowiązków między kategorie wdrażania, zarządzania i używania.
Role wbudowane są dostępne, aby zmniejszyć potrzebę korzystania z ról RBAC wyższego poziomu, takich jak właściciel lub współautor. W rzeczywistości możesz użyć tych ról, aby mieć określone osoby wdrażające zasoby usługi Azure SQL (lub zarządzać zasadami zabezpieczeń), ale przyznać innym użytkownikom rzeczywisty dostęp do używania bazy danych lub zarządzania nią. Na przykład współautor programu SQL Server może wdrożyć serwer i przypisać użytkownika jako administratora serwera i baz danych. Wbudowane role usługi Azure SQL Database obejmują:
- Współautor bazy danych SQL: Może tworzyć bazy danych i zarządzać nimi, ale nie może uzyskać dostępu do bazy danych (na przykład nie można nawiązać połączenia i odczytywać danych)
- Menedżer zabezpieczeń SQL: może zarządzać zasadami zabezpieczeń dla baz danych i wystąpień (takich jak inspekcja), ale nie może uzyskać do nich dostępu
- Współautor programu SQL Server: może zarządzać serwerami i bazami danych, ale nie może uzyskać do nich dostępu.
Uwierzytelnianie
Podczas wdrażania serwera logicznego usługi Azure SQL Database można określić następującą metodę uwierzytelniania:
- Używanie tylko uwierzytelniania firmy Microsoft Entra
- Korzystanie zarówno z uwierzytelniania SQL, jak i Microsoft Entra
- Korzystanie z uwierzytelniania SQL
Administrator serwera musi zostać ustawiony podczas wdrażania. W przypadku baz danych w usłudze Azure SQL Database administrator serwera jest podmiotem zabezpieczeń na poziomie serwera dla serwera logicznego usługi Azure SQL Database.
Jeśli migrujesz obciążenie wymagające uwierzytelniania systemu Windows lub twoja organizacja korzysta z identyfikatora Microsoft Entra ID, możesz użyć identyfikatora Entra firmy Microsoft. Administrator serwera Entra firmy Microsoft można przypisać przy użyciu portalu lub narzędzi wiersza polecenia.
Uwierzytelnianie tylko firmy Microsoft jest opcją domyślną podczas konfigurowania nowego serwera. Wprowadzono identyfikatory logowania serwera, aby umożliwić podmiotom zabezpieczeń serwera Firmy Microsoft, które są identyfikatorami logowania w wirtualnej master bazie danych usługi SQL Database. Możesz utworzyć identyfikatory logowania entra firmy Microsoft na podstawie użytkowników, grup i jednostek usługi firmy Microsoft. W przypadku korzystania z uwierzytelniania tylko firmy Microsoft można utworzyć identyfikatory logowania uwierzytelniania SQL, a istniejące identyfikatory logowania pozostaną. Jednak tylko identyfikatory logowania uwierzytelniania entra firmy Microsoft i użytkownicy mogą łączyć się z serwerem logicznym. Aby dowiedzieć się więcej na temat uwierzytelniania tylko w usłudze Microsoft Entra, zobacz Microsoft Entra-only authentication with Azure SQL (Uwierzytelnianie tylko firmy Microsoft w usłudze Azure SQL).
W zależności od tego, jak organizacja skonfigurowała wystąpienie firmy Microsoft Entra, możesz nawiązać z nim połączenie przy użyciu dowolnej z następujących trzech metod (na przykład w programie SSMS):
Microsoft Entra ID — zintegrowana: metoda nieinterakcyjna, której można użyć, jeśli logujesz się do systemu Windows przy użyciu poświadczeń usługi Microsoft Entra z domeny federacyjnej.
Microsoft Entra ID — hasło: metoda nieinterakcyjny, która umożliwia nawiązanie połączenia z główną nazwą firmy Microsoft Entra przy użyciu domeny zarządzanej przez identyfikator firmy Microsoft. Według dokumentacji:
Może to dotyczyć użytkowników natywnych lub federacyjnych firmy Microsoft Entra. Użytkownik natywny jest jawnie utworzony w identyfikatorze Entra firmy Microsoft i uwierzytelniany przy użyciu nazwy użytkownika i hasła, podczas gdy użytkownik federacyjny jest użytkownikiem systemu Windows, którego domena jest sfederowana z identyfikatorem Entra firmy Microsoft. Ta ostatnia metoda (przy użyciu nazwy użytkownika i hasła) może być używana, gdy użytkownik chce użyć poświadczeń systemu Windows, ale komputer lokalny nie jest przyłączony do domeny (na przykład przy użyciu dostępu zdalnego). W takim przypadku użytkownik systemu Windows może wskazać swoje konto domeny i hasło oraz uwierzytelnić się w usłudze SQL Database lub Azure Synapse Analytics (dawniej SQL DW) przy użyciu poświadczeń federacyjnych.
Microsoft Entra ID — uniwersalny z uwierzytelnianiem wieloskładnikowym (MFA): interaktywna metoda, która chroni dostęp do danych, spełniając wymagania organizacji dotyczące procesu logowania jednokrotnego za pomocą uwierzytelniania wieloskładnikowego firmy Microsoft.
W przypadku usługi Azure SQL Database istnieje kilka niuansów. Możesz mieć identyfikatory logowania istniejące w wirtualnej bazie danych, użytkownikach master bazy danych, a nawet użytkownikach zawartej bazy danych dla kont Microsoft Entra (zalecane). Mimo że administrator serwera usługi Azure SQL Database ma sysadmin zasadniczo uprawnienia, można utworzyć bardziej ograniczonych administratorów przy użyciu ról na poziomie serwera lub bazy danych. Dla usługi SQL Database dostępne są dwie role na poziomie bazy danych, które istnieją tylko w wirtualnej master bazie danych:
- loginmanager: rola na poziomie bazy danych, która umożliwia członkom tworzenie identyfikatorów logowania dla serwera bazy danych
- dbmanager: rola na poziomie bazy danych, która umożliwia członkom tworzenie i usuwanie baz danych dla serwera bazy danych
Oto lista ról na poziomie serwera w usłudze Azure SQL Database:
- ##MS_DatabasePołączenie or##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Podczas konfigurowania uwierzytelniania i autoryzacji należy także przestrzegać czterech wytycznych:
- Wdróż przy użyciu administratora serwera
- W razie potrzeby utwórz innych administratorów
- Administratorzy mogą tworzyć użytkowników
- Udziel dostępu tak samo jak w programie SQL Server
Inne możliwości
Po zdobyciu doświadczenia praktycznego w zakresie niektórych funkcji sieci i uwierzytelniania w dalszej części modułu przeanalizujesz inne możliwości i funkcje (oraz powiązane z nimi zadania) dotyczące ochrony danych, monitorowania, rejestrowania i inspekcji.