Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Ten artykuł zawiera informacje o najlepszych rozwiązaniach i wytycznych, które ułatwiają ustanowienie zabezpieczeń dla programu SQL Server. Aby zapoznać się z kompleksowym przeglądem funkcji zabezpieczeń programu SQL Server, zobacz Zabezpieczanie programu SQL Server.
Aby zapoznać się z najlepszymi praktykami dotyczącymi zabezpieczeń produktów, zobacz Azure SQL Database i SQL Managed Instance oraz SQL Server na maszynach wirtualnych Azure.
Przegląd
Metodologia zabezpieczeń warstwowych zapewnia rozwiązanie do ochrony w głębi systemu, korzystając z wielu funkcji zabezpieczeń przeznaczonych dla różnych zakresów zabezpieczeń. Funkcje zabezpieczeń udostępnione w programie SQL Server 2016 i ulepszone w kolejnych wersjach ułatwiają zapobieganie zagrożeniom bezpieczeństwa i zapewniają dobrze zabezpieczone aplikacje bazy danych.
Platforma Azure jest zgodna z kilkoma branżowymi przepisami i standardami, które umożliwiają tworzenie zgodnego rozwiązania z programem SQL Server uruchomionym na maszynie wirtualnej. Aby uzyskać informacje na temat zgodności z przepisami na platformie Azure, zobacz Azure Trust Center.
Ochrona na poziomie kolumny
Organizacje często muszą chronić dane na poziomie kolumny, ponieważ dane dotyczące klientów, pracowników, tajemnic handlowych, danych produktów, opieki zdrowotnej, finansów i innych poufnych danych są często przechowywane w bazach danych programu SQL Server. Poufne kolumny często obejmują numery identyfikacyjne/numery ubezpieczenia społecznego, numery telefonów komórkowych, imię, nazwisko, nazwę rodziny, identyfikację konta finansowego i wszelkie inne dane, które można uznać za dane osobowe.
Metody i funkcje wymienione w tej sekcji zwiększają poziom ochrony na poziomie kolumny z minimalnym obciążeniem i bez konieczności wprowadzania rozbudowanych zmian w kodzie aplikacji.
Użyj Always Encrypted do szyfrowania danych w spoczynku i w trakcie transmisji. Zaszyfrowane dane są odszyfrowywane tylko przez biblioteki klienckie na poziomie klienta aplikacji. Użyj szyfrowania losowego zamiast deterministycznego, jeśli to możliwe. Always Encrypted z bezpiecznymi enklawami może zwiększyć wydajność operacji porównania, takich jak MIĘDZY, IN, LIKE, DISTINCT, Joins i nie tylko w przypadku scenariuszy szyfrowania losowego.
Użyj dynamicznego maskowania danych (DDM), aby zaciemnić dane na poziomie kolumny, gdy funkcja Always Encrypted nie jest dostępna. Dynamiczne maskowanie danych (DDM) nie jest zgodne z funkcją Always Encrypted. Używaj funkcji Always Encrypted za pośrednictwem dynamicznego maskowania danych, jeśli jest to możliwe.
Możesz również przyznać uprawnienia na poziomie kolumny do tabeli, widoku lub funkcji zwracającej tabelę. Rozważ następujące kwestie: — w kolumnie można udzielić tylko uprawnień SELECT
, REFERENCES
i UPDATE
.
— DENY
na poziomie tabeli nie ma pierwszeństwa przed GRANT
na poziomie kolumny.
Ochrona na poziomie wiersza
Row-Level Security (RLS) umożliwia wykorzystanie kontekstu wykonawczego użytkownika w celu kontrolowania dostępu do wierszy w tabeli bazy danych. Zabezpieczenia na poziomie wiersza zapewniają, że użytkownicy mogą zobaczyć tylko rekord, który ich dotyczy. Zapewnia to bezpieczeństwo aplikacji na poziomie rekordu bez konieczności wprowadzania znaczących zmian w aplikacji.
Logika biznesowa jest hermetyzowana w funkcjach zwracających wartości tabeli kontrolowanych przez zasady zabezpieczeń, które włączają i wyłączają funkcje RLS (ograniczenia na poziomie wiersza). Polityka bezpieczeństwa kontroluje również predykaty FILTER
i BLOCK
powiązane z tabelami, na które działa RLS (zabezpieczenie na poziomie wiersza). Użyj Row-Level Security (RLS), aby ograniczyć rekordy zwracane do użytkownika wykonującego wywołanie. Użyj SESSION_CONTEXT (T-SQL) dla użytkowników łączących się z bazą danych za pośrednictwem aplikacji warstwy środkowej, w której użytkownicy aplikacji współużytkujący to samo konto użytkownika programu SQL Server. Aby uzyskać optymalną wydajność i możliwości zarządzania, postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi zabezpieczeń Row-Level.
Napiwek
Użyj zabezpieczeń Row-Level (RLS) razem z funkcją Always Encrypted lub Dynamic Data Masking (DDM), aby zmaksymalizować poziom zabezpieczeń organizacji.
Szyfrowanie plików
funkcja Transparent Data Encryption (TDE) chroni dane na poziomie pliku, zapewniając szyfrowanie danych w stanie spoczynku dla plików bazy danych. Funkcja Transparent Data Encryption (TDE) zapewnia, że pliki bazy danych, pliki kopii zapasowej i pliki tempdb
nie mogą być dołączane i odczytywane bez odpowiednich certyfikatów odszyfrowywania plików bazy danych. Bez funkcji Transparent Data Encryption (TDE) osoba atakująca może pobrać nośnik fizyczny (dyski lub taśmy kopii zapasowej) i przywrócić lub dołączyć bazę danych do odczytu zawartości. Funkcja Transparent Data Encryption (TDE) jest obsługiwana do pracy ze wszystkimi innymi funkcjami zabezpieczeń w programie SQL Server. Funkcja Transparent Data Encryption (TDE) zapewnia szyfrowanie we/wy w czasie rzeczywistym i odszyfrowywanie plików danych i dzienników. Szyfrowanie TDE używa klucza szyfrowania bazy danych (DEK), który jest przechowywany w bazie danych użytkownika. Klucz szyfrowania bazy danych może być również chroniony przy użyciu certyfikatu, który jest zabezpieczony przez główny klucz bazy danych master
.
Użyj funkcji TDE, aby chronić dane nieaktywne, kopie zapasowe i tempdb
.
Inspekcja i raportowanie
Aby przeprowadzić inspekcjęprogramu SQL Server, utwórz zasady inspekcji na poziomie serwera lub bazy danych. Zasady serwera dotyczą wszystkich istniejących i nowo utworzonych baz danych na serwerze. Dla uproszczenia włącz inspekcję na poziomie serwera i zezwól inspekcji na poziomie bazy danych na dziedziczenie właściwości na poziomie serwera dla wszystkich baz danych.
Przeprowadź inspekcję tabel i kolumn zawierających dane poufne, na które zastosowano środki zabezpieczające. Jeśli tabela lub kolumna jest wystarczająco ważna, aby wymagać ochrony przez funkcję zabezpieczeń, należy uznać ją za wystarczająco ważną, aby przeprowadzić inspekcję. Szczególnie ważne jest, aby przeprowadzać inspekcję i regularnie przeglądać tabele zawierające poufne informacje, ale nie można zastosować żądanych środków zabezpieczeń z powodu pewnego rodzaju ograniczeń aplikacji lub architektury.
Tożsamości i uwierzytelnianie
Program SQL Server obsługuje dwa tryby uwierzytelniania , tryb uwierzytelniania systemu Windows i tryb "SQL Server i tryb uwierzytelniania systemu Windows" (tryb mieszany).
Loginy są oddzielone od użytkowników bazy danych. Najpierw mapuj loginy lub grupy systemu Windows na użytkowników bazy danych lub role osobno. Następnie przyznaj uprawnienia użytkownikom, rolom serwera ,i/lub rolom bazy danych , w celu uzyskania dostępu do obiektów bazy danych.
Program SQL Server obsługuje następujące typy logowań:
- Lokalne konto użytkownika systemu Windows lub konto domeny usługi Active Directory — program SQL Server korzysta z systemu Windows do uwierzytelniania kont użytkowników systemu Windows.
- Grupa systemu Windows — udzielanie dostępu do grupy systemu Windows udziela dostępu do wszystkich logowań użytkowników systemu Windows, które są członkami grupy. Usunięcie użytkownika z grupy spowoduje usunięcie praw użytkownika pochodzącego z grupy. Członkostwo w grupie jest preferowaną strategią.
- Logowanie do programu SQL Server — program SQL Server przechowuje nazwę użytkownika i skrót hasła w bazie danych
master
. -
Użytkownicy ograniczonej bazy danych uwierzytelniają połączenia z programem SQL Server na poziomie bazy danych. Zamknięta baza danych to baza danych, która jest odizolowana od innych baz danych oraz od wystąpienia programu SQL Server (a także bazy danych
master
), które hostują tę bazę danych. Program SQL Server obsługuje użytkowników zawartej bazy danych na potrzeby uwierzytelniania systemu Windows i programu SQL Server.
Poniższe zalecenia i najlepsze rozwiązania pomagają zabezpieczyć tożsamości i metody uwierzytelniania:
Użyj strategii zabezpieczeń opartych na rolach zgodnie z zasadą najmniejszych przywilejów, aby poprawić zarządzanie zabezpieczeniami.
- Standardowe jest umieszczenie użytkowników usługi Active Directory w grupach usługi AD, grupy usługi AD powinny istnieć w rolach programu SQL Server, a role programu SQL Server powinny mieć przyznane minimalne uprawnienia wymagane przez aplikację.
Na platformie Azure należy używać zabezpieczeń z najmniejszymi uprawnieniami przy użyciu kontroli dostępu opartego na rolach (RBAC)
Wybierz usługę Active Directory za pośrednictwem uwierzytelniania programu SQL Server, jeśli to możliwe, a zwłaszcza wybierz usługę Active Directory w celu przechowywania zabezpieczeń na poziomie aplikacji lub bazy danych.
- Jeśli użytkownik opuści firmę, możesz łatwo wyłączyć konto.
- Można również łatwo usunąć użytkowników z grup, gdy użytkownicy zmieniają role lub opuszczają organizację. Zabezpieczenia grupy są uważane za najlepsze rozwiązanie.
Użyj uwierzytelniania wieloskładnikowego dla kont z dostępem na poziomie komputera, w tym kont używających protokołu RDP do logowania się na maszynie. Pomaga to chronić przed kradzieżą lub wyciekami poświadczeń, ponieważ uwierzytelnianie oparte na hasłach jednoskładnikowych jest słabszą formą uwierzytelniania z poświadczeniami zagrożonymi naruszeniem lub błędnie rozdawanym.
Wymagaj silnych i złożonych haseł, których nie można łatwo odgadnąć i nie są używane do żadnych innych kont ani celów. Regularnie aktualizuj hasła i wymuszaj zasady usługi Active Directory.
Group-Managed Konta usług (gMSA) zapewniają automatyczne zarządzanie hasłami, uproszczone zarządzanie nazwą główną usługi (SPN) oraz delegowanie zarządzania do innych administratorów.
- W przypadku konta gMSA system operacyjny Windows zarządza hasłami dla konta zamiast polegać na administratorze w celu zarządzania hasłem.
- gMSA automatycznie aktualizuje hasła konta bez ponownego uruchamiania usług.
- gMSA zmniejsza poziom powierzchni administracyjnej i poprawia rozdzielenie obowiązków.
Zminimalizuj prawa przyznane kontu usługi AD administratora bazy danych; Rozważ rozdzielenie obowiązków, które ograniczają dostęp do maszyny wirtualnej, możliwość logowania się do systemu operacyjnego, możliwość modyfikowania dzienników błędów i inspekcji oraz możliwość instalowania aplikacji i/lub funkcji.
Rozważ usunięcie kont administratora bazy danych z roli administratora systemu i przyznanie CONTROL SERVER dla kont administratora bazy danych, zamiast czynić je członkami roli sysadmin. Rola administratora systemu nie uwzględnia
DENY
, natomiast CONTROL SERVER to robi.
Pochodzenie danych i integralność danych
Przechowywanie historycznych rekordów zmian danych w czasie może być korzystne dla rozwiązania przypadkowych zmian w danych. Może to być również przydatne w przypadku inspekcji zmian aplikacji i może odzyskiwać elementy danych, gdy nieprawidłowy aktor wprowadza zmiany danych, które nie zostały autoryzowane.
- Użyj tabel czasowych, aby zachować wersje rekordów w czasie i przeglądać dane w ich pierwotnej postaci na przestrzeni całego ich cyklu życia, co pozwala na zapewnienie historycznego widoku danych aplikacji.
- Tabele czasowe mogą służyć do dostarczania wersji bieżącej tabeli w dowolnym momencie.
Narzędzia do oceny zabezpieczeń i ocena
Poniższe narzędzia do konfiguracji i oceny dotyczą zabezpieczeń obszaru powierzchni, identyfikują możliwości zabezpieczeń danych i zapewniają najlepszą ocenę bezpieczeństwa środowiska programu SQL Server na poziomie wystąpienia.
- konfiguracja obszaru powierzchni — należy włączyć tylko te funkcje wymagane przez środowisko, aby zminimalizować liczbę funkcji, które mogą zostać zaatakowane przez złośliwego użytkownika.
- Ocena podatności programu SQL Server (SSMS) — Ocena podatności SQL to narzędzie w SSMS w wersji 17.4+, które pomaga wykrywać, śledzić i korygować potencjalne luki w zabezpieczeniach bazy danych. Ocena luk w zabezpieczeniach jest cennym narzędziem do poprawy bezpieczeństwa bazy danych i jest wykonywana na poziomie bazy danych na bazę danych.
- odkrywanie i klasyfikacja danych SQL (SSMS) — często administratorzy baz danych zarządzają serwerami i bazami danych, nie zdając sobie sprawy z wrażliwości danych zawartych w bazie danych. Odkrywanie danych & Classification umożliwia odkrywanie, klasyfikowanie, etykietowanie oraz raportowanie odnośnie stopnia poufności danych. Klasyfikacja & odkrywania danych jest obsługiwana począwszy od SSMS 17.5.
Typowe zagrożenia SQL
Pomaga to wiedzieć, jakie są niektóre typowe zagrożenia, które ryzykują program SQL Server:
-
iniekcja SQL – iniekcja SQL jest typem ataku, w którym złośliwy kod zostaje wstawiony do ciągów przekazywanych do instancji SQL Server w celu wykonania.
- Proces iniekcji działa przez zakończenie ciągu tekstowego i dołączenie nowego polecenia. Ponieważ wstawione polecenie może zawierać więcej ciągów dołączonych przed jego wykonaniem, atakujący przerywa wstrzyknięty ciąg znakiem komentarza
--
. - Program SQL Server wykonuje wszelkie otrzymane zapytanie składniowo prawidłowe.
- Proces iniekcji działa przez zakończenie ciągu tekstowego i dołączenie nowego polecenia. Ponieważ wstawione polecenie może zawierać więcej ciągów dołączonych przed jego wykonaniem, atakujący przerywa wstrzyknięty ciąg znakiem komentarza
- Należy pamiętać o atakach kanału bocznego, złośliwym oprogramowaniu & oraz innych zagrożeniach.
Ryzyko iniekcji kodu SQL
Aby zminimalizować ryzyko wstrzyknięcia kodu SQL, należy wziąć pod uwagę następujące elementy:
- Przejrzyj każdy proces SQL, który konstruuje instrukcje SQL pod kątem podatności na wstrzykiwanie.
- Konstruowanie dynamicznie generowanych instrukcji SQL w sposób sparametryzowany.
- Deweloperzy i administratorzy zabezpieczeń powinni przejrzeć cały kod, który wywołuje
EXECUTE
,EXEC
lubsp_executesql
. - Nie zezwalaj na następujące znaki wejściowe:
-
;
: ogranicznik zapytań -
'
: ogranicznik ciągu danych znaków -
--
: ogranicznik komentarza jednowierszowego. -
/* ... */
: ograniczniki komentarzy. -
xp_
: procedury składowane z rozszerzeniem katalogu, takie jakxp_cmdshell
.- Nie zaleca się używania
xp_cmdshell
w żadnym środowisku programu SQL Server. Zamiast tego użyj SQLCLR lub poszukaj innych rozwiązań ze względu na ryzyko, które może wprowadzićxp_cmdshell
.
- Nie zaleca się używania
-
- Zawsze walidować dane wejściowe użytkownika i zapobiegać wyciekowi oraz ujawnianiu danych wyjściowych błędów atakującemu.
Zagrożenia kanału bocznego
Aby zminimalizować ryzyko ataku kanału bocznego, rozważ następujące kwestie:
- Upewnij się, że zastosowano najnowsze poprawki aplikacji i systemu operacyjnego.
- W przypadku obciążeń hybrydowych upewnij się, że najnowsze poprawki oprogramowania układowego są stosowane dla dowolnego sprzętu lokalnego.
- Na platformie Azure, w przypadku wysoce wrażliwych aplikacji i obciążeń, można dodać dodatkową ochronę przed atakami kanału bocznego za pomocą izolowanych maszyn wirtualnych, dedykowanych hostów lub maszyn wirtualnych do obliczeń poufnych, takich jak maszyny wirtualne serii DC i , korzystające z procesorów EPYC 3. generacji.
Zagrożenia infrastruktury
Rozważ następujące typowe zagrożenia infrastruktury:
- wymuszanie dostępu — osoba atakująca próbuje uwierzytelnić się przy użyciu wielu haseł na różnych kontach do momentu znalezienia poprawnego hasła.
- Łamanie zabezpieczeń haseł /technika sprayu haseł — atakujący próbują użyć jednego starannie opracowanego hasła przeciwko wszystkim znanym kontom użytkowników (jedno hasło do wielu kont). Jeśli początkowe rozpylenie hasła zakończy się niepowodzeniem, spróbuje ponownie, używając innego starannie spreparowanego hasła, zwykle czekając na określony czas między próbami uniknięcia wykrycia.
- Ataki typu ransomware to rodzaj ataku ukierunkowanego, w którym ransomware używane jest do szyfrowania danych i plików, uniemożliwiając dostęp do ważnych treści. Następnie atakujący próbują wymusić pieniądze od ofiar, zwykle w postaci kryptowalut, w zamian za klucz odszyfrowywania. Większość infekcji ransomware zaczyna się od wiadomości e-mail z załącznikami, które próbują zainstalować ransomware. Albo od witryn internetowych hostujących zestawy exploitów, które próbują wykorzystać luki w zabezpieczeniach przeglądarek internetowych i innego oprogramowania, aby zainstalować ransomware.
Zagrożenia związane z hasłem
Ponieważ nie chcesz, aby osoby atakujące łatwo odgadły nazwy kont lub hasła, następujące kroki pomagają zmniejszyć ryzyko wykrycia haseł:
- Utwórz unikatowe konto administratora lokalnego, które nie ma nazwy Administrator.
- Używaj złożonych silnych haseł dla wszystkich kont. Aby uzyskać więcej informacji na temat tworzenia silnego hasła, zobacz artykuł Tworzenie silnego hasła.
- Domyślnie platforma Azure wybiera opcję Uwierzytelnianie systemu Windows podczas konfigurowania maszyny wirtualnej programu SQL Server. W związku z tym logowanie SA jest wyłączone, a hasło jest przypisywane przez konfigurację. Zalecamy, aby logowanie SA nie było używane ani włączone. Jeśli musisz mieć login SQL, użyj jednej z następujących strategii.
Utwórz konto SQL o unikatowej nazwie, które ma członkostwo sysadmin. Można to zrobić w portalu, włączając uwierzytelnianie SQL podczas konfigurowania.
Napiwek
Jeśli podczas aprowizacji nie włączysz uwierzytelniania SQL, musisz ręcznie zmienić tryb uwierzytelniania na programu SQL Server i trybu uwierzytelniania systemu Windows. Aby uzyskać więcej informacji, zobacz Zmienianie trybu uwierzytelniania serwera.
Jeśli musisz użyć logowania SA, włącz logowanie po jego skonfigurowaniu i przypisz nowe silne hasło.
Ryzyko związane z oprogramowaniem wymuszającym okup
Rozważ następujące kwestie, aby zminimalizować ryzyko związane z oprogramowaniem wymuszającym okup:
- Najlepszą strategią ochrony przed oprogramowaniem ransomware jest zwrócenie szczególnej uwagi na luki RDP i SSH. Ponadto należy wziąć pod uwagę następujące zalecenia:
- Używanie zapór i blokowanie portów
- Upewnij się, że zastosowano najnowsze aktualizacje zabezpieczeń systemu operacyjnego i aplikacji
- Użyj kont usług zarządzanych przez grupę (gMSA)
- Ograniczanie dostępu do maszyn wirtualnych
- Wymagaj dostępu just in time (JIT) i Azure Bastion
- Zwiększanie zabezpieczeń obszaru Surface Area dzięki unikaniu instalowania narzędzi, takich jak sysinternals i SSMS na komputerze lokalnym
- Unikaj instalowania funkcji systemu Windows, ról i włączania usług, które nie są wymagane
- Ponadto powinno istnieć regularne pełne tworzenie kopii zapasowej, które jest zabezpieczone oddzielnie od wspólnego konta administratora, dzięki czemu nie może usuwać kopii baz danych.