Podręcznik do rozwiązywania typowych wymagań dotyczących zabezpieczeń przy użyciu usług Azure SQL Database i Azure SQL Managed Instance

  • Artykuł

Dotyczy: Azure SQL DatabaseAzure SQL Managed Instance

Ten artykuł zawiera najlepsze rozwiązania dotyczące rozwiązywania typowych wymagań dotyczących zabezpieczeń. Nie wszystkie wymagania mają zastosowanie do wszystkich środowisk i należy skonsultować się z zespołem ds. bazy danych i zabezpieczeń, w którym mają być implementowane funkcje.

Uwaga

Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).

Rozwiązywanie typowych wymagań dotyczących zabezpieczeń

Ten dokument zawiera wskazówki dotyczące rozwiązywania typowych wymagań dotyczących zabezpieczeń dla nowych lub istniejących aplikacji przy użyciu usług Azure SQL Database i Azure SQL Managed Instance. Jest on zorganizowany przez obszary zabezpieczeń wysokiego poziomu. Aby rozwiązać problemy z określonymi zagrożeniami, zapoznaj się z sekcją Typowe zagrożenia bezpieczeństwa i potencjalne środki zaradcze . Chociaż niektóre przedstawione zalecenia mają zastosowanie podczas migrowania aplikacji ze środowiska lokalnego na platformę Azure, scenariusze migracji nie są głównym celem tego dokumentu.

Oferty wdrażania usługi Azure SQL Database omówione w tym przewodniku

Oferty wdrażania, które nie zostały omówione w tym przewodniku

  • Azure Synapse Analytics
  • Maszyny wirtualne usługi Azure SQL (IaaS)
  • SQL Server

Odbiorcy

Docelowi odbiorcy tego przewodnika mają do czynienia z pytaniami dotyczącymi zabezpieczania usługi Azure SQL Database. Role zainteresowane tym artykułem z najlepszymi rozwiązaniami obejmują, ale nie tylko:

  • Architekci zabezpieczeń
  • Menedżerowie zabezpieczeń
  • Oficerowie zgodności
  • Funkcjonariusze ochrony prywatności
  • Inżynierowie ds. zabezpieczeń

Jak korzystać z tego przewodnika

Ten dokument jest przeznaczony jako uzupełnienie istniejącej dokumentacji zabezpieczeń usługi Azure SQL Database.

Jeśli nie określono inaczej, zalecamy stosowanie wszystkich najlepszych rozwiązań wymienionych w każdej sekcji w celu osiągnięcia odpowiedniego celu lub wymagania. Aby spełnić określone standardy zgodności z zabezpieczeniami lub najlepsze rozwiązania, ważne mechanizmy kontroli zgodności z przepisami są wymienione w sekcji Wymagania lub cele wszędzie tam, gdzie ma to zastosowanie. Są to standardy i przepisy dotyczące zabezpieczeń, do których odwołuje się ten dokument:

Planujemy dalsze aktualizowanie zaleceń i najlepszych rozwiązań wymienionych tutaj. Podaj dane wejściowe lub wszelkie poprawki dla tego dokumentu, korzystając z linku Opinia w dolnej części tego artykułu.

Authentication

Uwierzytelnianie to proces potwierdzania, że użytkownik jest tym, za kogo się podaje. Usługi Azure SQL Database i SQL Managed Instance obsługują dwa typy uwierzytelniania:

  • Uwierzytelnianie SQL
  • Uwierzytelnianie Microsoft Entra

Uwaga

Uwierzytelnianie firmy Microsoft Entra może nie być obsługiwane dla wszystkich narzędzi i aplikacji innych firm.

Centralne zarządzanie tożsamościami

Centralne zarządzanie tożsamościami oferuje następujące korzyści:

  • Zarządzanie kontami grup i kontrolowanie uprawnień użytkowników bez duplikowania logowań między serwerami, bazami danych i wystąpieniami zarządzanymi.
  • Uproszczone i elastyczne zarządzanie uprawnieniami.
  • Zarządzanie aplikacjami na dużą skalę.

Jak zaimplementować

  • Użyj uwierzytelniania firmy Microsoft Entra do scentralizowanego zarządzania tożsamościami.

Najlepsze praktyki

Uwaga

  • Uwierzytelnianie entra firmy Microsoft jest rejestrowane w dziennikach inspekcji usługi Azure SQL, ale nie w dziennikach logowania firmy Microsoft Entra.
  • Uprawnienia RBAC platformy Azure przyznane na platformie Azure nie mają zastosowania do uprawnień usługi Azure SQL Database lub wystąpienia zarządzanego SQL. Takie uprawnienia należy utworzyć/zamapować ręcznie przy użyciu istniejących uprawnień SQL.
  • Po stronie klienta uwierzytelnianie firmy Microsoft Entra wymaga dostępu do Internetu lub za pośrednictwem trasy zdefiniowanej przez użytkownika (UDR) do sieci wirtualnej.
  • Token dostępu Firmy Microsoft Entra jest buforowany po stronie klienta, a jego okres istnienia zależy od konfiguracji tokenu. Zobacz artykuł Configurable token lifetimes in Microsoft Entra ID ( Konfigurowanie okresów istnienia tokenów w identyfikatorze Entra firmy Microsoft)
  • Aby uzyskać wskazówki dotyczące rozwiązywania problemów z uwierzytelnianiem w usłudze Microsoft Entra, zobacz następujący blog: Rozwiązywanie problemów z identyfikatorem entra firmy Microsoft.

Uwierzytelnianie wieloskładnikowe firmy Microsoft

Wymienione w: OSA Practice #2, ISO Access Control (AC)

Uwierzytelnianie wieloskładnikowe firmy Microsoft pomaga zapewnić dodatkowe zabezpieczenia, wymagając więcej niż jednej formy uwierzytelniania.

Jak zaimplementować

  • Włącz uwierzytelnianie wieloskładnikowe w usłudze Microsoft Entra ID przy użyciu dostępu warunkowego i użyj uwierzytelniania interakcyjnego.

  • Alternatywą jest włączenie uwierzytelniania wieloskładnikowego dla całej dzierżawy firmy Microsoft lub domeny usługi Active Directory.

Najlepsze praktyki

  • Aktywuj dostęp warunkowy w identyfikatorze Entra firmy Microsoft (wymaga subskrypcji Premium).

  • Utwórz grupy firmy Microsoft Entra i włącz zasady uwierzytelniania wieloskładnikowego dla wybranych grup przy użyciu dostępu warunkowego firmy Microsoft Entra.

  • Uwierzytelnianie wieloskładnikowe można włączyć dla całej dzierżawy usługi Microsoft Entra lub dla usługi Active Directory federacyjnej z identyfikatorem Entra firmy Microsoft.

  • Użyj trybu uwierzytelniania interakcyjnego firmy Microsoft dla usług Azure SQL Database i Azure SQL Managed Instance, w których wymagane jest interakcyjne hasło, a następnie uwierzytelnianie wieloskładnikowe:

  • Zaimplementuj aplikacje, aby nawiązać połączenie z usługą Azure SQL Database lub usługą Azure SQL Managed Instance przy użyciu uwierzytelniania interakcyjnego z obsługą uwierzytelniania wieloskładnikowego.

    Uwaga

    Ten tryb uwierzytelniania wymaga tożsamości opartych na użytkownikach. W przypadkach, gdy jest używany model zaufanej tożsamości, który pomija indywidualne uwierzytelnianie użytkownika firmy Microsoft Entra (na przykład przy użyciu tożsamości zarządzanej dla zasobów platformy Azure), uwierzytelnianie wieloskładnikowe nie ma zastosowania.

Minimalizowanie użycia uwierzytelniania opartego na hasłach dla użytkowników

Wymienione w: OSA Practice #4, ISO Access Control (AC)

Metody uwierzytelniania opartego na hasłach są słabszą formą uwierzytelniania. Poświadczenia mogą zostać naruszone lub błędnie przekazane.

Jak zaimplementować

  • Użyj zintegrowanego uwierzytelniania firmy Microsoft Entra, które eliminuje użycie haseł.

Najlepsze praktyki

  • Użyj uwierzytelniania logowania jednokrotnego przy użyciu poświadczeń systemu Windows. Sfederuj domenę lokalna usługa Active Directory z identyfikatorem Entra firmy Microsoft i użyj zintegrowanego uwierzytelniania systemu Windows (w przypadku maszyn przyłączonych do domeny z identyfikatorem Entra firmy Microsoft).

Minimalizowanie użycia uwierzytelniania opartego na hasłach dla aplikacji

Wymienione w: OSA Practice #4, ISO Access Control (AC)

Jak zaimplementować

  • Włącz tożsamość zarządzaną platformy Azure. Można również użyć zintegrowanego lub opartego na certyfikatach uwierzytelniania.

Najlepsze praktyki

Ochrona haseł i wpisów tajnych

W przypadku, gdy hasła nie są możliwe do uniknięcia, upewnij się, że są one zabezpieczone.

Jak zaimplementować

  • Usługa Azure Key Vault umożliwia przechowywanie haseł i wpisów tajnych. Zawsze, gdy ma to zastosowanie, użyj uwierzytelniania wieloskładnikowego dla usługi Azure SQL Database z użytkownikami firmy Microsoft Entra.

Najlepsze praktyki

  • Jeśli nie można uniknąć haseł lub wpisów tajnych, zapisz hasła użytkowników i wpisy tajne aplikacji w usłudze Azure Key Vault oraz zarządzaj dostępem za pomocą zasad dostępu usługi Key Vault.

  • Różne struktury programowania aplikacji mogą również oferować mechanizmy specyficzne dla struktury do ochrony wpisów tajnych w aplikacji. Na przykład: ASP.NET aplikacja podstawowa.

Używanie uwierzytelniania SQL dla starszych aplikacji

Uwierzytelnianie SQL odnosi się do uwierzytelniania użytkownika podczas nawiązywania połączenia z usługą Azure SQL Database lub wystąpieniem zarządzanym SQL przy użyciu nazwy użytkownika i hasła. W każdym serwerze lub wystąpieniu zarządzanym należy utworzyć dane logowania, a użytkownik utworzony w każdej bazie danych.

Jak zaimplementować

  • Użyj uwierzytelniania SQL.

Najlepsze praktyki

Zarządzanie dostępem

Zarządzanie dostępem (nazywane również autoryzacją) to proces kontrolowania dostępu i uprawnień autoryzowanych użytkowników oraz zarządzania nimi w usłudze Azure SQL Database lub SQL Managed Instance.

Implementowanie zasady najniższych uprawnień

Wymienione w: FedRamp controls AC-06, NIST: AC-6, OSA Practice #3

Zasada najniższych uprawnień określa, że użytkownicy nie powinni mieć większej liczby uprawnień niż wymagane do wykonania swoich zadań. Aby uzyskać więcej informacji, zobacz artykuł Just enough administration (Wystarczy administrować).

Jak zaimplementować

Przypisz tylko niezbędne uprawnienia do wykonywania wymaganych zadań:

Najlepsze praktyki

Poniższe najlepsze rozwiązania są opcjonalne, ale zapewnią lepszą możliwość zarządzania i obsługę strategii zabezpieczeń:

  • Jeśli to możliwe, zacznij od najmniejszego możliwego zestawu uprawnień i zacznij dodawać uprawnienia jeden po drugim, jeśli istnieje rzeczywista konieczność (i uzasadnienie) — w przeciwieństwie do przeciwnego podejścia: pobieranie uprawnień krok po kroku.

  • Powstrzymaj się od przypisywania uprawnień poszczególnym użytkownikom. Zamiast tego używaj ról (ról bazy danych lub serwera). Role ułatwiają znacznie raportowanie i rozwiązywanie problemów z uprawnieniami. (Kontrola dostępu oparta na rolach platformy Azure obsługuje tylko przypisywanie uprawnień za pośrednictwem ról).

  • Tworzenie i używanie ról niestandardowych z dokładnymi wymaganymi uprawnieniami. Typowe role, które są używane w praktyce:

    • Wdrażanie zabezpieczeń
    • Administratorzy
    • Deweloperzy
    • Personel pomocy technicznej
    • Audytor
    • Zautomatyzowane procesy
    • Użytkownik końcowy

  • Używaj wbudowanych ról tylko wtedy, gdy uprawnienia ról są zgodne dokładnie z wymaganymi uprawnieniami użytkownika. Możesz przypisać użytkowników do wielu ról.

  • Należy pamiętać, że uprawnienia w a aparatze bazy danych można stosować w następujących zakresach (im mniejszy zakres, tym mniejszy wpływ przyznanych uprawnień):

    • Serwer (role specjalne w bazie danych) na master platformie Azure
    • baza danych
    • Schematu
      • Najlepszym rozwiązaniem jest użycie schematów w celu udzielenia uprawnień w bazie danych.
    • Obiekt (tabela, widok, procedura itd.)

    Uwaga

    Nie zaleca się stosowania uprawnień na poziomie obiektu, ponieważ ten poziom zwiększa złożoność do ogólnej implementacji. Jeśli zdecydujesz się używać uprawnień na poziomie obiektu, powinny one być jasno udokumentowane. To samo dotyczy uprawnień na poziomie kolumny, które są jeszcze mniej zalecane z tych samych powodów. Należy również pamiętać, że domyślnie odmowa na poziomie tabeli nie zastępuje grantu na poziomie kolumny. Wymagałoby to aktywowania konfiguracji serwera zgodności typowych kryteriów.

  • Przeprowadzaj regularne kontrole przy użyciu oceny luk w zabezpieczeniach w celu przetestowania zbyt wielu uprawnień.

Implementowanie rozdzielenia obowiązków

Wymienione w: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Separacja obowiązków, nazywana również podziałem obowiązków, opisuje wymóg dzielenia poufnych zadań na wiele zadań przydzielonych różnym użytkownikom. Rozdzielenie obowiązków pomaga zapobiegać naruszeniom danych.

Jak zaimplementować

  • Zidentyfikuj wymagany poziom rozdzielania obowiązków. Przykłady:

    • Między środowiskami projektowymi/testowymi i produkcyjnymi
    • Zadania wrażliwe na zabezpieczenia vs zadania na poziomie zarządzania Administracja istrator bazy danych (DBA) a zadania deweloperskie.
      • Przykłady: Audytor, tworzenie zasad zabezpieczeń dla zabezpieczeń na poziomie roli (RLS), implementowanie obiektów usługi SQL Database z uprawnieniami DDL.

  • Zidentyfikuj kompleksową hierarchię użytkowników (i zautomatyzowanych procesów), które uzyskują dostęp do systemu.

  • Utwórz role zgodnie z wymaganymi grupami użytkowników i przypisz uprawnienia do ról.

    • W przypadku zadań na poziomie zarządzania w witrynie Azure Portal lub za pośrednictwem automatyzacji programu PowerShell użyj ról platformy Azure. Znajdź wbudowaną rolę zgodną z wymaganiami lub utwórz rolę niestandardową platformy Azure przy użyciu dostępnych uprawnień
    • Utwórz role serwera dla zadań obejmujących cały serwer (tworzenie nowych nazw logowania, baz danych) w wystąpieniu zarządzanym.
    • Utwórz role bazy danych dla zadań na poziomie bazy danych.

  • W przypadku niektórych poufnych zadań należy rozważyć utworzenie specjalnych procedur składowanych podpisanych przez certyfikat w celu wykonywania zadań w imieniu użytkowników. Jedną z ważnych zalet procedur składowanych podpisanych cyfrowo jest to, że jeśli procedura zostanie zmieniona, uprawnienia przyznane poprzedniej wersji procedury zostaną natychmiast usunięte.

  • Zaimplementuj funkcję Transparent Data Encryption (TDE) przy użyciu kluczy zarządzanych przez klienta w usłudze Azure Key Vault, aby umożliwić rozdzielenie obowiązków między właścicielem danych a właścicielem zabezpieczeń.

  • Aby upewnić się, że administrator bazy danych nie może zobaczyć danych, które są uważane za wysoce poufne i nadal może wykonywać zadania administratora bazy danych, można użyć funkcji Always Encrypted z separacją ról.

  • W przypadkach, gdy użycie funkcji Always Encrypted nie jest możliwe lub przynajmniej nie bez większych kosztów i wysiłków, które mogą nawet spowodować, że system jest niemal bezużyteczny, można wprowadzić i ograniczyć zabezpieczenia za pomocą mechanizmów kontroli wyrównywujących, takich jak:

    • Interwencja człowieka w procesach.
    • Dzienniki inspekcji — aby uzyskać więcej informacji na temat inspekcji, zobacz Inspekcja krytycznych zdarzeń zabezpieczeń.

Najlepsze praktyki

  • Upewnij się, że w środowiskach deweloperskich/testowych i produkcyjnych są używane różne konta. Różne konta pomagają zapewnić zgodność z separacją systemów testowych i produkcyjnych.

  • Powstrzymaj się od przypisywania uprawnień poszczególnym użytkownikom. Zamiast tego używaj ról (ról bazy danych lub serwera). Posiadanie ról znacznie ułatwia raportowanie i rozwiązywanie problemów z uprawnieniami.

  • Użyj ról wbudowanych, gdy uprawnienia są dokładnie zgodne z wymaganymi uprawnieniami — jeśli związek wszystkich uprawnień z wielu wbudowanych ról prowadzi do dopasowania w 100%, można również przypisać wiele ról jednocześnie.

  • Tworzenie i używanie ról zdefiniowanych przez użytkownika, gdy wbudowane role udzielają zbyt wielu uprawnień lub niewystarczających uprawnień.

  • Przypisania ról mogą być również wykonywane tymczasowo, nazywane również dynamicznym rozdzieleniem obowiązków (DSD) w krokach zadania agenta SQL w języku T-SQL lub przy użyciu usługi Azure PIM dla ról platformy Azure.

  • Upewnij się, że administratorzy baz danych nie mają dostępu do kluczy szyfrowania lub magazynów kluczy, a administratorzy zabezpieczeń Administracja istratorzy z dostępem do kluczy nie mają dostępu do bazy danych z kolei. Użycie rozszerzonego zarządzania kluczami (EKM) może ułatwić osiągnięcie tego rozdzielenia. Usługa Azure Key Vault może służyć do implementowania EKM.

  • Zawsze upewnij się, że masz dziennik inspekcji dla akcji związanych z zabezpieczeniami.

  • Możesz pobrać definicję wbudowanych ról platformy Azure, aby wyświetlić używane uprawnienia i utworzyć rolę niestandardową na podstawie fragmentów i kumulacji tych ról za pomocą programu PowerShell.

  • Ponieważ każdy członek roli bazy danych db_owner może zmienić ustawienia zabezpieczeń, takie jak Transparent Data Encryption (TDE) lub zmienić cel slo, to członkostwo powinno być przyznane z ostrożnością. Istnieje jednak wiele zadań, które wymagają db_owner uprawnień. Zadanie takie jak zmiana dowolnego ustawienia bazy danych, takie jak zmiana opcji bazy danych. Inspekcja odgrywa kluczową rolę w każdym rozwiązaniu.

  • Nie można ograniczyć uprawnień db_owner i w związku z tym uniemożliwić kontu administracyjnemu wyświetlanie danych użytkownika. Jeśli w bazie danych znajdują się wysoce poufne dane, funkcja Always Encrypted może służyć do bezpiecznego zapobiegania wyświetlaniu db_owners lub innych administratorów baz danych.

Uwaga

Osiągnięcie separacji obowiązków (SoD) jest trudne w przypadku zadań związanych z zabezpieczeniami lub rozwiązywania problemów. Inne obszary, takie jak role deweloperów i użytkowników końcowych, są łatwiejsze do segregowania. Większość mechanizmów kontroli związanych ze zgodnością umożliwia korzystanie z funkcji kontroli alternatywnej, takich jak Inspekcja, gdy inne rozwiązania nie są praktyczne.

W przypadku czytelników, którzy chcą dokładniej zapoznać się z usługą SoD, zalecamy następujące zasoby:

Regularne przeglądy kodu

Wymienione w: PCI: 6.3.2, SOC: SDL-3

Rozdzielenie obowiązków nie jest ograniczone do danych w bazie danych, ale zawiera kod aplikacji. Złośliwy kod może potencjalnie obejść mechanizmy kontroli zabezpieczeń. Przed wdrożeniem kodu niestandardowego w środowisku produkcyjnym należy zapoznać się z tym, co jest wdrażane.

Jak zaimplementować

  • Użyj narzędzia bazy danych, takiego jak Azure Data Studio, które obsługuje kontrolę źródła.

  • Zaimplementuj segregowany proces wdrażania kodu.

  • Przed zatwierdzeniem gałęzi głównej osoba (inna niż autor samego kodu) musi sprawdzić kod pod kątem potencjalnego podniesienia uprawnień, a także złośliwych modyfikacji danych w celu ochrony przed oszustwem i nieautoryzowaniem dostępu. Można to zrobić przy użyciu mechanizmów kontroli źródła.

Najlepsze praktyki

  • Standaryzacja: pomaga zaimplementować standardową procedurę, która ma być przestrzegana dla wszystkich aktualizacji kodu.

  • Ocena luk w zabezpieczeniach zawiera reguły sprawdzające nadmierne uprawnienia, użycie starych algorytmów szyfrowania i inne problemy z zabezpieczeniami w schemacie bazy danych.

  • Dalsze kontrole można przeprowadzić w środowisku kontroli jakości lub środowisku testowym przy użyciu usługi Advanced Threat Protection, która skanuje pod kątem kodu podatnego na wstrzyknięcie kodu SQL.

  • Przykłady tego, co należy zwrócić uwagę na:

    • Tworzenie użytkownika lub zmienianie ustawień zabezpieczeń z poziomu zautomatyzowanego wdrożenia aktualizacji kodu SQL.
    • Procedura składowana, która w zależności od podanych parametrów aktualizuje wartość pieniężną w komórce w sposób niezgodny.

  • Upewnij się, że osoba przeprowadzająca przegląd jest osobą inną niż autor kodu źródłowego i z możliwością znajomości w przeglądach kodu i bezpiecznym kodowaniu.

  • Pamiętaj, aby znać wszystkie źródła zmian kodu. Kod może znajdować się w skryptach języka T-SQL. Polecenia ad hoc mogą być wykonywane lub wdrażane w postaci widoków, funkcji, wyzwalaczy i procedur składowanych. Może to być część definicji zadań agenta SQL (kroki). Można go również wykonać z poziomu pakietów usług SSIS, usługi Azure Data Factory i innych usług.

Ochrona danych

Ochrona danych to zestaw możliwości ochrony ważnych informacji przed naruszeniem przez szyfrowanie lub zaciemnianie.

Uwaga

Firma Microsoft zaświadcza o zgodności ze standardem FIPS 140-2 Level 1 w usługach Azure SQL Database i SQL Managed Instance. Odbywa się to po zweryfikowaniu ścisłego użycia algorytmów FIPS 140-2 poziom 1 akceptowalnych i fiPS 140-2 poziom 1 zweryfikowanych wystąpień tych algorytmów, w tym spójności z wymaganymi długościami kluczy, zarządzaniem kluczami, generowaniem kluczy i magazynem kluczy. To zaświadczenie ma na celu umożliwienie naszym klientom reagowania na potrzebę lub wymaganie korzystania z zweryfikowanych wystąpień fiPS 140-2 poziom 1 w przetwarzaniu danych lub dostarczania systemów lub aplikacji. Definiujemy terminy "Zgodność ze standardem FIPS 140-2 poziom 1" i "Zgodność ze standardem FIPS 140-2 poziom 1" używane w powyższej instrukcji, aby zademonstrować ich zamierzone zastosowanie do amerykańskich i kanadyjskich instytucji rządowych, używając innego terminu "FIPS 140-2 Poziom 1 zweryfikowany".

Szyfrowanie danych podczas przesyłania

Wspomniano w: OSA Practice #6, rodzina kontroli ISO: kryptografia

Chroni dane, gdy dane są przemieszczane między klientem a serwerem. Zapoznaj się z tematem Zabezpieczenia sieci.

Szyfrowanie danych magazynowanych

Wspomniano w: OSA Practice #6, rodzina kontroli ISO: kryptografia

Szyfrowanie magazynowane to kryptograficzna ochrona danych, gdy są utrwalane w plikach bazy danych, dziennika i kopii zapasowych.

Jak zaimplementować

  • Funkcja Transparent Data Encryption (TDE) z kluczami zarządzanymi przez usługę jest domyślnie włączona dla wszystkich baz danych utworzonych po 2017 r. w usługach Azure SQL Database i SQL Managed Instance.
  • W wystąpieniu zarządzanym, jeśli baza danych jest tworzona na podstawie operacji przywracania przy użyciu serwera lokalnego, ustawienie TDE oryginalnej bazy danych zostanie uznane. Jeśli oryginalna baza danych nie ma włączonej funkcji TDE, zalecamy ręczne włączenie funkcji TDE dla wystąpienia zarządzanego.

Najlepsze praktyki

  • Nie przechowuj danych, które wymagają szyfrowania magazynowanych w master bazie danych. Nie master można zaszyfrować bazy danych za pomocą funkcji TDE.

  • Użyj kluczy zarządzanych przez klienta w usłudze Azure Key Vault, jeśli potrzebujesz większej przejrzystości i szczegółowej kontroli nad ochroną TDE. Usługa Azure Key Vault umożliwia w dowolnym momencie odwoływanie uprawnień w celu renderowania bazy danych niedostępnej. Możesz centralnie zarządzać funkcjami ochrony TDE wraz z innymi kluczami lub obracać funkcję ochrony TDE we własnym harmonogramie przy użyciu usługi Azure Key Vault.

  • Jeśli używasz kluczy zarządzanych przez klienta w usłudze Azure Key Vault, postępuj zgodnie z artykułami Wskazówki dotyczące konfigurowania funkcji TDE za pomocą usługi Azure Key Vault i Jak skonfigurować funkcję geo-dr za pomocą usługi Azure Key Vault.

Uwaga

Niektóre elementy uważane za zawartość klienta, takie jak nazwy tabel, nazwy obiektów i nazwy indeksów, mogą być przesyłane w plikach dziennika w celu uzyskania pomocy technicznej i rozwiązywania problemów przez firmę Microsoft.

Ochrona poufnych danych używanych przed wysoce uprzywilejowanymi, nieautoryzowanymi użytkownikami

Dane używane to dane przechowywane w pamięci systemu bazy danych podczas wykonywania zapytań SQL. Jeśli baza danych przechowuje poufne dane, organizacja może być wymagana, aby zapewnić, że użytkownicy z wysokimi uprawnieniami nie będą mogli wyświetlać poufnych danych w bazie danych. Użytkownicy z wysokimi uprawnieniami, tacy jak operatorzy firmy Microsoft lub administratorzy baz danych w organizacji, powinni mieć możliwość zarządzania bazą danych, ale uniemożliwili wyświetlanie i potencjalnie eksfiltrowanie poufnych danych z pamięci procesu SQL lub wykonywanie zapytań względem bazy danych.

Zasady określające, które dane są poufne i czy poufne dane muszą być szyfrowane w pamięci i nie są dostępne dla administratorów w postaci zwykłego tekstu, są specyficzne dla organizacji i przepisów dotyczących zgodności, które należy przestrzegać. Zobacz powiązane wymaganie: Identyfikowanie i tagowanie poufnych danych.

Jak zaimplementować

  • Użyj funkcji Always Encrypted , aby zapewnić, że poufne dane nie są widoczne w postaci zwykłego tekstu w usłudze Azure SQL Database lub usłudze SQL Managed Instance, nawet w pamięci/w użyciu. Funkcja Always Encrypted chroni dane przed administratorami bazy danych Administracja istratorami (DBA) i administratorami chmury (lub złymi aktorami, którzy mogą personifikować użytkowników z wysokimi uprawnieniami, ale nieautoryzowanymi) i zapewnia większą kontrolę nad tym, kto może uzyskiwać dostęp do danych.

Najlepsze praktyki

  • Funkcja Always Encrypted nie zastępuje szyfrowania danych magazynowanych (TDE) ani podczas przesyłania (SSL/TLS). Funkcja Always Encrypted nie powinna być używana w przypadku danych niewrażliwych w celu zminimalizowania wpływu na wydajność i funkcjonalność. Używanie funkcji Always Encrypted w połączeniu z protokołami TDE i Transport Layer Security (TLS) jest zalecane w celu kompleksowej ochrony danych magazynowanych, przesyłanych i używanych.

  • Oceń wpływ szyfrowania zidentyfikowanych kolumn danych poufnych przed wdrożeniem funkcji Always Encrypted w produkcyjnej bazie danych. Ogólnie rzecz biorąc, funkcja Always Encrypted zmniejsza funkcjonalność zapytań dotyczących zaszyfrowanych kolumn i ma inne ograniczenia wymienione w artykule Always Encrypted — Szczegóły funkcji. W związku z tym może być konieczne zmiana architektury aplikacji w celu ponownego zaimplementowania funkcji, zapytanie nie obsługuje, po stronie klienta lub/i refaktoryzację schematu bazy danych, w tym definicje procedur składowanych, funkcji, widoków i wyzwalaczy. Istniejące aplikacje mogą nie działać z zaszyfrowanymi kolumnami, jeśli nie są zgodne z ograniczeniami i ograniczeniami funkcji Always Encrypted. Chociaż ekosystem narzędzi firmy Microsoft, produktów i usług obsługujących funkcję Always Encrypted rośnie, wiele z nich nie działa z zaszyfrowanymi kolumnami. Szyfrowanie kolumny może również mieć wpływ na wydajność zapytań, w zależności od właściwości obciążenia.

  • Zarządzanie kluczami Always Encrypted z separacją ról, jeśli używasz funkcji Always Encrypted do ochrony danych przed złośliwymi bazami danych. W przypadku separacji ról administrator zabezpieczeń tworzy klucze fizyczne. Administrator bazy danych tworzy obiekty metadanych klucza szyfrowania kolumny i klucza szyfrowania kolumny opisujące klucze fizyczne w bazie danych. W trakcie tego procesu administrator zabezpieczeń nie potrzebuje dostępu do bazy danych, a administrator bazy danych nie potrzebuje dostępu do kluczy fizycznych w postaci zwykłego tekstu.

  • Przechowywanie kluczy głównych kolumn w usłudze Azure Key Vault w celu ułatwienia zarządzania. Unikaj używania magazynu certyfikatów systemu Windows (i ogólnie rozproszonych rozwiązań magazynu kluczy, w przeciwieństwie do centralnych rozwiązań do zarządzania kluczami), które utrudniają zarządzanie kluczami.

  • Należy dokładnie przemyśleć kompromisy dotyczące używania wielu kluczy (klucza głównego kolumny lub kluczy szyfrowania kolumny). Zachowaj małą liczbę kluczy, aby zmniejszyć koszty zarządzania kluczami. Jeden klucz główny kolumny i jeden klucz szyfrowania kolumny na bazę danych jest zwykle wystarczający w środowiskach stałego stanu (nie w środku rotacji kluczy). Może być konieczne dodatkowe klucze, jeśli masz różne grupy użytkowników, z których każda korzysta z różnych kluczy i uzyskuje dostęp do różnych danych.

  • Obracanie kluczy głównych kolumn zgodnie z wymaganiami dotyczącymi zgodności. Jeśli musisz również obrócić klucze szyfrowania kolumn, rozważ użycie szyfrowania online w celu zminimalizowania przestojów aplikacji.

    • Zapoznaj się z artykułem Zagadnienia dotyczące wydajności i dostępności.

  • Użyj szyfrowania deterministycznego, jeśli obliczenia (równość) na danych muszą być obsługiwane. W przeciwnym razie użyj szyfrowania losowego. Unikaj używania szyfrowania deterministycznego w przypadku zestawów danych o niskiej entropii lub zestawów danych z publicznie znaną dystrybucją.

  • Jeśli obawiasz się, że osoby trzecie uzyskują dostęp do danych legalnie bez zgody, upewnij się, że wszystkie aplikacje i narzędzia, które mają dostęp do kluczy i danych w postaci zwykłego tekstu, działają poza usługą Microsoft Azure Cloud. Bez dostępu do kluczy inna firma nie będzie mogła odszyfrować danych, chyba że pomija szyfrowanie.

  • Funkcja Always Encrypted nie obsługuje łatwego udzielania tymczasowego dostępu do kluczy (i chronionych danych). Jeśli na przykład musisz udostępnić klucze administratorowi bazy danych, aby umożliwić administratorowi bazy danych wykonywanie niektórych operacji czyszczenia na poufnych i zaszyfrowanych danych. Jedynym sposobem niezawodnego odwołania dostępu do danych z bazy danych będzie rotacja zarówno kluczy szyfrowania kolumny, jak i kluczy głównych kolumn chroniących dane, co jest kosztowną operacją.

  • Aby uzyskać dostęp do wartości w postaci zwykłego tekstu w zaszyfrowanych kolumnach, użytkownik musi mieć dostęp do klucza głównego kolumny (CMK), który chroni kolumny skonfigurowane w magazynie kluczy przechowującym klucz cmK. Użytkownik musi również mieć uprawnienia BAZY danych VIEW ANY COLUMN MASTER KEY DEFINITION (WYŚWIETL DOWOLNĄ DEFINICJĘ KLUCZA GŁÓWNEGO KOLUMNY) i VIEW ANY COLUMN ENCRYPTION KEY DEFINITION database (WYŚWIETL DOWOLNĄ DEFINICJĘ KLUCZA SZYFROWANIA KOLUMNY).

Kontrolowanie dostępu użytkowników aplikacji do poufnych danych za pomocą szyfrowania

Szyfrowanie może służyć jako sposób zapewnienia, że tylko konkretni użytkownicy aplikacji, którzy mają dostęp do kluczy kryptograficznych, mogą wyświetlać lub aktualizować dane.

Jak zaimplementować

  • Użyj szyfrowania na poziomie komórki (CLE). Aby uzyskać szczegółowe informacje, zobacz artykuł Szyfrowanie kolumny danych .
  • Używaj funkcji Always Encrypted, ale pamiętaj o jego ograniczeniu. Poniżej wymieniono ograniczenia.

Najlepsze rozwiązania:

W przypadku korzystania z funkcji CLE:

  • Kontrolowanie dostępu do kluczy za pomocą uprawnień i ról SQL.

  • Użyj AES (zalecane AES 256) do szyfrowania danych. Algorytmy, takie jak RC4, DES i TripleDES, są przestarzałe i nie powinny być używane z powodu znanych luk w zabezpieczeniach.

  • Ochrona kluczy symetrycznych za pomocą kluczy asymetrycznych/certyfikatów (nie haseł), aby uniknąć używania formatu 3DES.

  • Należy zachować ostrożność podczas migrowania bazy danych przy użyciu szyfrowania na poziomie komórki za pośrednictwem eksportu/importu (plików bacpac).

Należy pamiętać, że funkcja Always Encrypted jest przeznaczona głównie do ochrony poufnych danych używanych przez użytkowników usługi Azure SQL Database (operatorów w chmurze, DBA) — zobacz Ochrona poufnych danych używanych przez użytkowników z wysokimi uprawnieniami i nieautoryzowanych użytkowników. Podczas używania funkcji Always Encrypted do ochrony danych przed użytkownikami aplikacji należy pamiętać o następujących wyzwaniach:

  • Domyślnie wszystkie sterowniki klienta firmy Microsoft obsługujące funkcję Always Encrypted obsługują globalną (jedną na aplikację) pamięć podręczną kluczy szyfrowania kolumn. Gdy sterownik klienta uzyska klucz szyfrowania kolumny w postaci zwykłego tekstu, kontaktując się z magazynem kluczy przechowującym klucz główny kolumny, klucz szyfrowania kolumny w postaci zwykłego tekstu jest buforowany. To sprawia, że izolowanie danych od użytkowników aplikacji z wieloma użytkownikami jest trudne. Jeśli aplikacja personifikuje użytkowników końcowych podczas interakcji z magazynem kluczy (takim jak usługa Azure Key Vault), po wypełnieniu pamięci podręcznej za pomocą klucza szyfrowania kolumny kolejne zapytanie, które wymaga tego samego klucza, ale zostanie wyzwolone przez innego użytkownika, użyje buforowanego klucza. Sterownik nie wywoła magazynu kluczy i nie sprawdzi, czy drugi użytkownik ma uprawnienia dostępu do klucza szyfrowania kolumny. W związku z tym użytkownik może zobaczyć zaszyfrowane dane, nawet jeśli użytkownik nie ma dostępu do kluczy. Aby zapewnić izolację użytkowników w aplikacji z wieloma użytkownikami, można wyłączyć buforowanie klucza szyfrowania kolumny. Wyłączenie buforowania spowoduje dodatkowe obciążenie związane z wydajnością, ponieważ sterownik będzie musiał skontaktować się z magazynem kluczy dla każdej operacji szyfrowania lub odszyfrowywania danych.

Ochrona danych przed nieautoryzowanym wyświetlaniem przez użytkowników aplikacji przy zachowaniu formatu danych

Inną techniką zapobiegania nieautoryzowanym użytkownikom wyświetlania danych jest zaciemnianie lub maskowanie danych przy zachowaniu typów danych i formatów w celu zapewnienia, że aplikacje użytkowników mogą nadal obsługiwać i wyświetlać dane.

Jak zaimplementować

Uwaga

Funkcja Always Encrypted nie działa z dynamicznym maskowaniem danych. Nie można zaszyfrować i zamaskować tej samej kolumny, co oznacza, że należy określić priorytety ochrony danych w użyciu, a maskowanie danych dla użytkowników aplikacji za pośrednictwem dynamicznego maskowania danych.

Najlepsze praktyki

Uwaga

Dynamiczne maskowanie danych nie może służyć do ochrony danych przed użytkownikami z wysokimi uprawnieniami. Zasady maskowania nie mają zastosowania do użytkowników z dostępem administracyjnym, takimi jak db_owner.

  • Nie zezwalaj użytkownikom aplikacji na uruchamianie zapytań ad hoc (ponieważ mogą być w stanie obejść dynamiczne maskowanie danych).

  • Użyj odpowiednich zasad kontroli dostępu (za pośrednictwem uprawnień SQL, ról, zabezpieczeń na poziomie wiersza), aby ograniczyć uprawnienia użytkowników do wprowadzania aktualizacji w maskowanych kolumnach. Utworzenie maski w kolumnie nie uniemożliwia aktualizacji tej kolumny. Użytkownicy, którzy otrzymują maskowane dane podczas wykonywania zapytań względem maskowanej kolumny, mogą aktualizować dane, jeśli mają uprawnienia do zapisu.

  • Dynamiczne maskowanie danych nie zachowuje właściwości statystycznych maskowanych wartości. Może to mieć wpływ na wyniki zapytania (na przykład zapytania zawierające predykaty filtrowania lub sprzężenia na maskowanych danych).

Bezpieczeństwo sieci

Zabezpieczenia sieci odnoszą się do mechanizmów kontroli dostępu i najlepszych rozwiązań w celu zabezpieczenia danych przesyłanych do usługi Azure SQL Database.

Konfigurowanie klienta w celu bezpiecznego nawiązywania połączenia z usługą SQL Database/wystąpieniem zarządzanym SQL

Najlepsze rozwiązania dotyczące zapobiegania nawiązywaniu połączeń z usługami Azure SQL Database i SQL Managed Instance na maszynach klienckich i aplikacjach z dobrze znanymi lukami w zabezpieczeniach (na przykład przy użyciu starszych protokołów TLS i zestawów szyfrowania).

Jak zaimplementować

Najlepsze praktyki

  • Wymusić minimalną wersję protokołu TLS na poziomie serwera usługi SQL Database lub wystąpienia zarządzanego SQL przy użyciu minimalnego ustawienia wersji protokołu TLS. Zalecamy ustawienie minimalnej wersji protokołu TLS na 1.2 po przetestowaniu, aby potwierdzić, że aplikacje go obsługują. Protokół TLS 1.2 zawiera poprawki luk w zabezpieczeniach znalezionych w poprzednich wersjach.

  • Konfigurowanie wszystkich aplikacji i narzędzi w celu nawiązania połączenia z usługą SQL Database z włączonym szyfrowaniem

    • Encrypt = On, TrustServerCertificate = Off (lub odpowiednik ze sterownikami innych niż Microsoft).

  • Jeśli aplikacja używa sterownika, który nie obsługuje protokołu TLS lub obsługuje starszą wersję protokołu TLS, zastąp sterownik, jeśli to możliwe. Jeśli nie jest to możliwe, należy dokładnie ocenić zagrożenia bezpieczeństwa.

Minimalizowanie obszaru podatnego na ataki

Zminimalizuj liczbę funkcji, które mogą zostać zaatakowane przez złośliwego użytkownika. Zaimplementuj mechanizmy kontroli dostępu do sieci dla usługi Azure SQL Database.

Wymienione w: OSA Practice #5

Jak zaimplementować

W usłudze SQL Database:

  • Ustaw opcję Zezwalaj na dostęp do usług platformy Azure na wartość WYŁ. na poziomie serwera
  • Użyj punktów końcowych usługi sieci wirtualnej i reguł zapory sieci wirtualnej.
  • Użyj usługi Private Link.

W usłudze SQL Managed Instance:

Najlepsze praktyki

  • Ograniczanie dostępu do usług Azure SQL Database i SQL Managed Instance przez nawiązanie połączenia w prywatnym punkcie końcowym (na przykład przy użyciu prywatnej ścieżki danych):

    • Wystąpienie zarządzane można odizolować wewnątrz sieci wirtualnej, aby zapobiec dostępowi zewnętrznemu. Aplikacje i narzędzia, które znajdują się w tej samej lub równorzędnej sieci wirtualnej w tym samym regionie, mogą uzyskiwać do niej bezpośredni dostęp. Aplikacje i narzędzia, które znajdują się w innym regionie, mogą używać połączenia między sieciami wirtualnymi lub komunikacji równorzędnej obwodu usługi ExpressRoute w celu nawiązania połączenia. Klient powinien używać sieciowych grup zabezpieczeń w celu ograniczenia dostępu przez port 1433 tylko do zasobów, które wymagają dostępu do wystąpienia zarządzanego.
    • W przypadku usługi SQL Database użyj funkcji Private Link , która udostępnia dedykowany prywatny adres IP dla serwera w sieci wirtualnej. Możesz również użyć punktów końcowych usługi sieci wirtualnej z regułami zapory sieci wirtualnej, aby ograniczyć dostęp do serwerów.
    • Użytkownicy mobilni powinni używać połączeń sieci VPN typu punkt-lokacja do łączenia się za pośrednictwem ścieżki danych.
    • Użytkownicy połączeni z siecią lokalną powinni używać połączenia sieci VPN typu lokacja-lokacja lub usługi ExpressRoute, aby nawiązać połączenie za pośrednictwem ścieżki danych.

  • Dostęp do usług Azure SQL Database i SQL Managed Instance można uzyskać, łącząc się z publicznym punktem końcowym (na przykład przy użyciu publicznej ścieżki danych). Należy wziąć pod uwagę następujące najlepsze rozwiązania:

    Uwaga

    Publiczny punkt końcowy usługi SQL Managed Instance nie jest domyślnie włączony i musi być jawnie włączony. Jeśli zasady firmy nie zezwalają na korzystanie z publicznych punktów końcowych, użyj usługi Azure Policy , aby zapobiec włączeniu publicznych punktów końcowych w pierwszej kolejności.

  • Konfigurowanie składników sieci platformy Azure:

Konfigurowanie usługi Power BI pod kątem bezpiecznych połączeń z usługą SQL Database/wystąpieniem zarządzanym SQL

Najlepsze praktyki

Konfigurowanie usługi App Service pod kątem bezpiecznych połączeń z usługą SQL Database/wystąpieniem zarządzanym SQL

Najlepsze praktyki

Konfigurowanie hostingu maszyny wirtualnej platformy Azure pod kątem bezpiecznych połączeń z usługą SQL Database/wystąpieniem zarządzanym SQL

Najlepsze praktyki

  • Użyj kombinacji reguł Zezwalaj i Odmów w sieciowych grupach zabezpieczeń maszyn wirtualnych platformy Azure, aby kontrolować, do których regionów można uzyskać dostęp z maszyny wirtualnej.

  • Upewnij się, że maszyna wirtualna jest skonfigurowana zgodnie z artykułem Najlepsze rozwiązania w zakresie zabezpieczeń obciążeń IaaS na platformie Azure.

  • Upewnij się, że wszystkie maszyny wirtualne są skojarzone z określoną siecią wirtualną i podsiecią.

  • Sprawdź, czy potrzebujesz trasy domyślnej 0.0.0.0/Internet zgodnie ze wskazówkami dotyczącymi wymuszonego tunelowania.

    • Jeśli tak — na przykład podsieć frontonu — zachowaj trasę domyślną.
    • Jeśli nie — na przykład warstwa środkowa lub podsieć zaplecza — włącz tunelowanie wymuszone, aby żaden ruch nie przechodził przez Internet, aby uzyskać dostęp do środowiska lokalnego (np. między środowiskiem lokalnym).

  • Zaimplementuj opcjonalne trasy domyślne, jeśli używasz komunikacji równorzędnej lub łączysz się ze środowiskiem lokalnym.

  • Zaimplementuj trasy zdefiniowane przez użytkownika, jeśli chcesz wysłać cały ruch w sieci wirtualnej do wirtualnego urządzenia sieciowego na potrzeby inspekcji pakietów.

  • Użyj punktów końcowych usługi sieci wirtualnej, aby zapewnić bezpieczny dostęp do usług PaaS, takich jak Azure Storage za pośrednictwem sieci szkieletowej platformy Azure.

Ochrona przed atakami DDoS (Distributed Denial of Service)

Ataki typu "rozproszona odmowa usługi" (DDoS) są próbami złośliwego użytkownika w celu wysłania powodzi ruchu sieciowego do usługi Azure SQL Database w celu przeciążenia infrastruktury platformy Azure i spowodowania odrzucenia prawidłowych identyfikatorów logowania i obciążenia.

Wymienione w: OSA Practice #9

Jak zaimplementować

Ochrona przed atakami DDoS jest automatycznie włączona w ramach platformy Azure. Obejmuje ona monitorowanie ruchu zawsze włączone i ograniczanie ryzyka ataków na poziomie sieci na publiczne punkty końcowe.

Najlepsze praktyki

  • Postępuj zgodnie z praktykami opisanymi w artykule Minimalizuj obszar ataków, aby zminimalizować zagrożenia ataków DDoS.

  • Alert o atakach siłowych SQL usługi Advanced Threat Protection pomaga wykrywać ataki siłowe. W niektórych przypadkach alert może nawet odróżnić obciążenia testów penetracyjnych.

  • W przypadku maszyn wirtualnych platformy Azure hostujących aplikacje łączące się z usługą SQL Database:

    • Postępuj zgodnie z zaleceniem, aby ograniczyć dostęp za pośrednictwem punktów końcowych z Internetu w Microsoft Defender dla Chmury.
    • Użyj zestawów skalowania maszyn wirtualnych, aby uruchomić wiele wystąpień aplikacji na maszynach wirtualnych platformy Azure.
    • Wyłącz protokół RDP i SSH z Internetu, aby zapobiec atakowi siłowemu.

Monitorowanie, rejestrowanie i inspekcje

W tej sekcji opisano możliwości, które ułatwiają wykrywanie nietypowych działań wskazujących na nietypowe i potencjalnie szkodliwe próby uzyskania dostępu do baz danych lub wykorzystania ich. Opisano również najlepsze rozwiązania dotyczące konfigurowania inspekcji bazy danych w celu śledzenia i przechwytywania zdarzeń bazy danych.

Ochrona baz danych przed atakami

Zaawansowana ochrona przed zagrożeniami umożliwia wykrywanie potencjalnych zagrożeń i reagowanie na nie, zapewniając alerty zabezpieczeń dotyczące nietypowych działań.

Jak zaimplementować

  • Usługa Advanced Threat Protection dla programu SQL umożliwia wykrywanie nietypowych i potencjalnie szkodliwych prób uzyskania dostępu do baz danych lub wykorzystania ich, w tym:
    • Atak polegający na wstrzyknięciu kodu SQL.
    • Kradzież/wyciek poświadczeń.
    • Nadużycie przywilejów.
    • Eksfiltracja danych.

Najlepsze praktyki

  • Skonfiguruj usługę Microsoft Defender dla programu SQL dla określonego serwera lub wystąpienia zarządzanego. Usługę Microsoft Defender for SQL można również skonfigurować dla wszystkich serwerów i wystąpień zarządzanych w ramach subskrypcji, włączając Microsoft Defender dla Chmury.

  • W przypadku pełnego środowiska badania zaleca się włączenie inspekcji usługi SQL Database. Inspekcja umożliwia śledzenie zdarzeń bazy danych i zapisywanie ich w dzienniku inspekcji na koncie usługi Azure Storage lub w obszarze roboczym usługi Azure Log Analytics.

Inspekcja krytycznych zdarzeń zabezpieczeń

Śledzenie zdarzeń bazy danych pomaga zrozumieć aktywność bazy danych. Możesz uzyskać wgląd w rozbieżności i anomalie, które mogą wskazywać na problemy biznesowe lub podejrzane naruszenia zabezpieczeń. Umożliwia również i ułatwia przestrzeganie standardów zgodności.

Jak zaimplementować

  • Włącz inspekcję usługi SQL Database lub inspekcję wystąpienia zarządzanego, aby śledzić zdarzenia bazy danych i zapisywać je w dzienniku inspekcji na koncie usługi Azure Storage, w obszarze roboczym usługi Log Analytics (wersja zapoznawcza) lub Event Hubs (wersja zapoznawcza).

  • Dzienniki inspekcji można zapisywać na koncie usługi Azure Storage, w obszarze roboczym usługi Log Analytics na potrzeby użycia przez dzienniki usługi Azure Monitor lub do centrum zdarzeń do użycia przy użyciu centrum zdarzeń. Można skonfigurować dowolną kombinację tych opcji, a dzienniki inspekcji zostaną zapisane w każdej z nich.

Najlepsze praktyki

  • Konfigurując inspekcję usługi SQL Database na serwerze lub inspekcji wystąpienia zarządzanego w celu inspekcji zdarzeń, wszystkie istniejące i nowo utworzone bazy danych na tym serwerze zostaną poddane inspekcji.
  • Domyślnie zasady inspekcji obejmują wszystkie akcje (zapytania, procedury składowane i pomyślne i nieudane logowania) względem baz danych, co może spowodować dużą liczbę dzienników inspekcji. Zaleca się, aby klienci konfigurowali inspekcję dla różnych typów akcji i grup akcji przy użyciu programu PowerShell. Skonfigurowanie tej funkcji pomoże kontrolować liczbę akcji inspekcji i zminimalizować ryzyko utraty zdarzeń. Niestandardowe konfiguracje inspekcji umożliwiają klientom przechwytywanie tylko potrzebnych danych inspekcji.
  • Dzienniki inspekcji można używać bezpośrednio w witrynie Azure Portal lub w skonfigurowanej lokalizacji magazynu.

Uwaga

Włączenie inspekcji w usłudze Log Analytics spowoduje naliczenie kosztów na podstawie stawek pozyskiwania. Należy pamiętać o skojarzonym koszcie z użyciem tej opcji lub rozważyć przechowywanie dzienników inspekcji na koncie usługi Azure Storage.

Dodatkowe zasoby

Zabezpieczanie dzienników inspekcji

Ogranicz dostęp do konta magazynu, aby obsługiwać rozdzielenie obowiązków i oddzielać administratorów baz danych od audytorów.

Jak zaimplementować

  • Podczas zapisywania dzienników inspekcji w usłudze Azure Storage upewnij się, że dostęp do konta magazynu jest ograniczony do minimalnych zasad zabezpieczeń. Kontroluj, kto ma dostęp do konta magazynu.
  • Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu do usługi Azure Storage.

Najlepsze praktyki

Zarządzanie zabezpieczeniami

W tej sekcji opisano różne aspekty i najlepsze rozwiązania dotyczące zarządzania stanem zabezpieczeń baz danych. Zawiera najlepsze rozwiązania dotyczące zapewniania, że bazy danych są skonfigurowane do spełnienia standardów zabezpieczeń, odnajdywania i klasyfikowania i śledzenia dostępu do potencjalnie poufnych danych w bazach danych.

Upewnij się, że bazy danych są skonfigurowane tak, aby spełniały najlepsze rozwiązania w zakresie zabezpieczeń

Proaktywne ulepszanie zabezpieczeń bazy danych przez odnajdywanie i korygowanie potencjalnych luk w zabezpieczeniach bazy danych.

Jak zaimplementować

  • Włącz ocenę luk w zabezpieczeniach SQL w celu skanowania bazy danych pod kątem problemów z zabezpieczeniami i automatycznego uruchamiania okresowo w bazach danych.

Najlepsze praktyki

  • Początkowo uruchom narzędzie do oceny luk w zabezpieczeniach w bazach danych i iteruj, korygując testy zakończone niepowodzeniem, które sprzeciwiają się najlepszym rozwiązaniom w zakresie zabezpieczeń. Skonfiguruj punkty odniesienia dla akceptowalnych konfiguracji, dopóki skanowanie nie zostanie wyczyszczone lub wszystkie kontrole zostaną pomyślnie przeprowadzone.

  • Skonfiguruj okresowe skanowania cykliczne do uruchomienia raz w tygodniu i skonfiguruj odpowiednią osobę do odbierania wiadomości e-mail z podsumowaniem.

  • Zapoznaj się z podsumowaniem oceny luk w zdarze po każdym cotygodniowym skanowaniu. W przypadku znalezionych luk w zabezpieczeniach oceń dryf z poprzedniego wyniku skanowania i ustal, czy sprawdzanie powinno zostać rozwiązane. Sprawdź, czy istnieje uzasadniony powód zmiany konfiguracji.

  • Rozwiązywanie problemów z sprawdzaniem i aktualizowaniem punktów odniesienia tam, gdzie jest to istotne. Utwórz elementy biletu do rozwiązywania akcji i śledź je do momentu ich rozwiązania.

Dodatkowe zasoby

Identyfikowanie i tagowanie poufnych danych

Odnajdź kolumny, które potencjalnie zawierają poufne dane. To, co jest uważane za poufne dane, zależy od klienta, regulacji zgodności itp., i musi być oceniane przez użytkowników zależnych od tych danych. Klasyfikuj kolumny, aby używać zaawansowanych scenariuszy inspekcji i ochrony opartej na poufności.

Jak zaimplementować

  • Odnajdywanie i klasyfikacja danych SQL służy do odnajdywania, klasyfikowania, etykietowania i ochrony poufnych danych w bazach danych.
    • Wyświetl zalecenia dotyczące klasyfikacji tworzone przez automatyczne odnajdywanie na pulpicie nawigacyjnym odnajdywania i klasyfikacji danych SQL. Zaakceptuj odpowiednie klasyfikacje, tak aby poufne dane zostały trwale oznaczone etykietami klasyfikacji.
    • Ręcznie dodaj klasyfikacje dla dodatkowych pól danych poufnych, które nie zostały odnalezione przez mechanizm zautomatyzowany.
  • Aby uzyskać więcej informacji, zobacz Odnajdywanie i klasyfikacja danych SQL.

Najlepsze praktyki

  • Regularnie monitoruj pulpit nawigacyjny klasyfikacji, aby uzyskać dokładną ocenę stanu klasyfikacji bazy danych. Raport o stanie klasyfikacji bazy danych można wyeksportować lub wydrukować, aby udostępnić go w celach zgodności i inspekcji.

  • Stale monitoruj stan zalecanych poufnych danych w ocenie luk w zabezpieczeniach SQL. Śledź regułę odnajdywania danych poufnych i zidentyfikuj wszelkie dryfy w zalecanych kolumnach klasyfikacji.

  • Użyj klasyfikacji w sposób dostosowany do konkretnych potrzeb organizacji. Dostosuj zasady usługi Information Protection (etykiety poufności, typy informacji, logika odnajdywania) w zasadach usługi SQL Information Protection w Microsoft Defender dla Chmury.

Śledzenie dostępu do poufnych danych

Monitoruj, kto uzyskuje dostęp do poufnych danych i przechwytuje zapytania dotyczące poufnych danych w dziennikach inspekcji.

Jak zaimplementować

  • Należy użyć kombinacji usług SQL Audit i Data Classification.

Najlepsze praktyki

Wizualizowanie stanu zabezpieczeń i zgodności

Użyj ujednoliconego systemu zarządzania zabezpieczeniami infrastruktury, który wzmacnia poziom zabezpieczeń centrów danych (w tym baz danych w usłudze SQL Database). Wyświetl listę zaleceń dotyczących zabezpieczeń baz danych i stanu zgodności.

Jak zaimplementować

Typowe zagrożenia bezpieczeństwa i potencjalne środki zaradcze

Ta sekcja ułatwia znalezienie środków zabezpieczeń w celu ochrony przed określonymi wektorami ataków. Oczekuje się, że większość środków zaradczych można osiągnąć, postępując zgodnie z co najmniej jednym z powyższych wytycznych dotyczących zabezpieczeń.

Zagrożenie bezpieczeństwa: eksfiltracja danych

Eksfiltracja danych to nieautoryzowane kopiowanie, przesyłanie lub pobieranie danych z komputera lub serwera. Zobacz definicję eksfiltracji danych w Wikipedii.

Połączenie do serwera za pośrednictwem publicznego punktu końcowego powoduje ryzyko eksfiltracji danych, ponieważ wymaga to od klientów otwarcia zapór dla publicznych adresów IP.

Scenariusz 1. Aplikacja na maszynie wirtualnej platformy Azure łączy się z bazą danych w usłudze Azure SQL Database. Nieuczciwy aktor uzyskuje dostęp do maszyny wirtualnej i narusza go. W tym scenariuszu eksfiltracja danych oznacza, że zewnętrzna jednostka korzystająca z nieautoryzowanych maszyn wirtualnych łączy się z bazą danych, kopiuje dane osobowe i przechowuje je w magazynie obiektów blob lub innej usłudze SQL Database w innej subskrypcji.

Scenariusz 2. Nieautoryzna baza danych. Ten scenariusz jest często zgłaszany przez klientów wrażliwych na zabezpieczenia z regulowanych branż. W tym scenariuszu użytkownik o wysokim poziomie uprawnień może kopiować dane z usługi Azure SQL Database do innej subskrypcji, która nie jest kontrolowana przez właściciela danych.

Potencjalne środki zaradcze

Obecnie usługi Azure SQL Database i SQL Managed Instance oferują następujące techniki ograniczania zagrożeń eksfiltracji danych:

  • Użyj kombinacji reguł Zezwalaj i Odmów w sieciowych grupach zabezpieczeń maszyn wirtualnych platformy Azure, aby kontrolować, do których regionów można uzyskać dostęp z maszyny wirtualnej.
  • W przypadku korzystania z serwera w usłudze SQL Database ustaw następujące opcje:
    • Zezwalaj usługom platformy Azure na wyłączenie.
    • Zezwalaj tylko na ruch z podsieci zawierającej maszynę wirtualną platformy Azure, konfigurując regułę zapory sieci wirtualnej.
    • Korzystanie z usługi Private Link
  • W przypadku usługi SQL Managed Instance domyślnie przy użyciu prywatnego dostępu ip adresuje pierwsze obawy dotyczące eksfiltracji danych nieautoryzowanych maszyn wirtualnych. Włącz funkcję delegowania podsieci w podsieci, aby automatycznie ustawić najbardziej restrykcyjne zasady w podsieci usługi SQL Managed Instance.
  • Problem rogue DBA jest bardziej uwidaczniony w usłudze SQL Managed Instance, ponieważ ma większy obszar powierzchni, a wymagania dotyczące sieci są widoczne dla klientów. Najlepszym ograniczeniem ryzyka jest zastosowanie wszystkich praktyk w tym przewodniku zabezpieczeń, aby zapobiec scenariuszowi rogue DBA w pierwszej kolejności (nie tylko w przypadku eksfiltracji danych). Funkcja Always Encrypted to jedna z metod ochrony poufnych danych przez ich szyfrowanie i przechowywanie klucza niedostępnego dla administratora bazy danych.

Aspekty zabezpieczeń ciągłości działania i dostępności

Większość standardów zabezpieczeń dotyczy dostępności danych w zakresie ciągłości działania, osiąganej przez zaimplementowanie nadmiarowości i możliwości przełączania w tryb failover w celu uniknięcia pojedynczych punktów awarii. W przypadku scenariuszy awarii typowym rozwiązaniem jest przechowywanie kopii zapasowych plików danych i dzienników. W poniższej sekcji przedstawiono ogólne omówienie możliwości wbudowanych na platformie Azure. Udostępnia również dodatkowe opcje, które można skonfigurować pod kątem określonych potrzeb:

Następne kroki