Najlepsze praktyki w zakresie zabezpieczeń z bazami danych w kontenerach

Dotyczy:programu SQL ServerAzure SQL Managed Instance

Zawarte bazy danych mają pewne unikatowe zagrożenia, które powinny być zrozumiałe i ograniczane przez administratorów aparatu bazy danych programu SQL Server. Większość zagrożeń jest związanych z procesem uwierzytelniania USER WITH PASSWORD, który przenosi granicę uwierzytelniania z poziomu silnika bazy danych do poziomu bazy danych.

Zagrożenia związane z użytkownikami

Użytkownicy w zawartej bazie danych z uprawnieniami ALTER ANY USER, takimi jak członkowie stałych ról bazy danych db_owner i db_accessadmin, mogą udzielić dostępu do bazy danych bez wiedzy lub zgody administratora programu SQL Server. Udzielanie użytkownikom dostępu do kontenerowej bazy danych zwiększa potencjalny obszar ataku względem całego wystąpienia SQL Server. Administratorzy powinni zrozumieć to delegowanie kontroli dostępu i zachować ostrożność przy udzielaniu użytkownikom w zawartej bazie danych uprawnienia ALTER ANY USER. Wszyscy właściciele baz danych mają uprawnienia ALTER ANY USER. Administratorzy programu SQL Server powinni okresowo przeprowadzać inspekcję użytkowników w zawartej bazie danych.

Uzyskiwanie dostępu do innych baz danych przy użyciu konta gościa

Właściciele bazy danych i użytkownicy bazy danych z uprawnieniami ALTER ANY USER mogą tworzyć użytkowników zawartej bazy danych. Po połączeniu z bazą danych kontenerową na instancji SQL Server użytkownik tej bazy danych może uzyskać dostęp do innych baz danych w aparacie bazy danych, o ile inne bazy danych mają włączone konto gościa .

Tworzenie zduplikowanego użytkownika w innej bazie danych

Niektóre aplikacje mogą wymagać, aby użytkownik miał dostęp do więcej niż jednej bazy danych. Można to zrobić, tworząc identycznych użytkowników zawartej bazy danych w każdej bazie danych. Użyj opcji SID podczas tworzenia drugiego użytkownika z hasłem. Poniższy przykład tworzy dwóch identycznych użytkowników w dwóch bazach danych.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO  

Aby wykonać zapytanie obejmujące wiele baz danych, należy ustawić opcję TRUSTWORTHY w wywołującej bazie danych. Jeśli na przykład użytkownik (Carlo) zdefiniowany powyżej znajduje się w bazie danych DB1, aby wykonać SELECT * FROM db2.dbo.Table1; to ustawienie TRUSTWORTHY musi być włączone dla bazy danych DB1. Wykonaj następujący kod, aby ustawić opcję TRUSTWORTHY na włączone.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;  

Tworzenie użytkownika powielającego login

Jeśli utworzony zostanie użytkownik bazy danych typu contained z hasłem, używając tej samej nazwy co login SQL Server, a login SQL Server łączy się, określając tę bazę danych jako katalog początkowy, to login SQL Server nie będzie mógł nawiązać połączenia. Połączenie zostanie ocenione jako użytkownik zawartej bazy danych z jednostką hasła w zawartej bazie danych zamiast jako użytkownik na podstawie nazwy logowania programu SQL Server. Może to spowodować celową lub przypadkową odmowę usługi logowania programu SQL Server.

• Najlepszym rozwiązaniem jest to, że członkowie sysadmin stałej roli serwera powinni rozważyć zawsze nawiązywanie połączenia bez korzystania z opcji katalogu początkowego. Spowoduje to połączenie logowania z bazą danych master i uniknięcie wszelkich prób nieprawidłowego użycia próby logowania przez właściciela bazy danych. Następnie administrator może przełączyć się na zawartą bazę danych, używając instrukcji USE<database>. Możesz również ustawić jako domyślną bazę danych logowania zawartą bazę danych, co kończy logowanie w master, a następnie przenosi logowanie do zawartej bazy danych.

• Najlepszym rozwiązaniem jest to, że nie należy tworzyć użytkowników zawartej bazy danych z hasłami, które mają taką samą nazwę jak identyfikatory logowania programu SQL Server.

• Jeśli istnieje zduplikowane logowanie, połącz się z bazą danych master bez określania katalogu początkowego, a następnie wykonaj polecenie USE, aby przełączyć się na zawartą bazę danych.

• Gdy istnieją zawarte bazy danych, użytkownicy baz danych niezawartych powinni łączyć się z aparatem bazy danych bez użycia początkowego katalogu lub określając nazwę niezawartej bazy danych jako katalogu początkowego. Pozwala to uniknąć nawiązywania połączenia z zawartą bazą danych, która jest mniej bezpośrednio kontrolowana przez administratorów silnika bazy danych.

Zwiększanie dostępu przez zmianę stanu zawierania bazy danych

Identyfikatory logowania, które mają uprawnienia ALTER ANY DATABASE, takie jak członkowie stałej roli serwera dbcreator, oraz użytkownicy w nieuwzwiązanej bazie danych z uprawnieniami CONTROL DATABASE, takich jak członkowie db_owner stałej roli bazy danych, mogą zmienić ustawienie zawierania bazy danych. Jeśli ustawienie zawierania bazy danych zostanie zmienione z NONE na PARTIAL lub FULL, dostęp użytkowników można przyznać poprzez utworzenie użytkowników zawartych w bazie danych z hasłami. Może to zapewnić dostęp bez wiedzy lub zgody administratorów programu SQL Server. Aby zapobiec przechodzeniu baz danych w tryb zawartości, ustaw opcję uwierzytelniania bazy danych 'Aparat bazy danych', 'zawarta baza danych' na wartość 0. Aby zapobiec nawiązywaniu połączeń przez użytkowników zawartej bazy danych z hasłami w wybranych zawartych bazach danych, użyj wyzwalaczy logowania, aby anulować próby logowania użytkowników zawartej bazy danych z hasłami.

Dołączanie zawartej bazy danych

Dołączając kontenerową bazę danych, administrator może przyznać niechcianym użytkownikom dostęp do instancji aparatu bazy danych. Administrator zaniepokojony tym ryzykiem może przełączyć bazę danych w tryb RESTRICTED_USER, co uniemożliwia uwierzytelnianie użytkownikom zawartej bazy danych przy użyciu haseł. Tylko użytkownicy autoryzowani za pośrednictwem logowania będą mieli dostęp do bazy danych.

Użytkownicy są tworzeni przy użyciu wymagań dotyczących haseł w czasie ich tworzenia, a hasła nie są ponownie sprawdzanie po dołączeniu bazy danych. Załączając bazę danych, która zezwalała na słabe hasła, do systemu, który ma bardziej rygorystyczną politykę haseł, administrator może zezwolić na hasła, które nie spełniają obecnej polityki haseł w silniku bazy danych podczas dołączania. Administratorzy mogą uniknąć zachowywania słabych haseł, wymagając zresetowania wszystkich haseł dla dołączonej bazy danych.

Zasady haseł

Hasła w bazie danych mogą być wymagane jako silne, ale nie mogą być chronione przez surowe zasady zarządzania hasłami. Użyj uwierzytelniania systemu Windows, jeśli to możliwe, aby skorzystać z bardziej rozbudowanych zasad haseł dostępnych w systemie Windows.

Uwierzytelnianie Kerberos

Użytkownicy zawartej bazy danych z hasłami nie mogą używać uwierzytelniania Kerberos. Jeśli to możliwe, użyj uwierzytelniania systemu Windows, aby korzystać z funkcji systemu Windows, takich jak Kerberos.

Atak słownikowy offline

Skróty haseł użytkowników bazy danych, którzy posiadają hasła, są przechowywane w bazie danych. Każda osoba mająca dostęp do plików bazy danych może przeprowadzić atak słownikowy na użytkowników zawartej bazy danych z hasłami w niezaudiowanym systemie. Aby wyeliminować to zagrożenie, ogranicz dostęp do plików bazy danych lub zezwalaj tylko na połączenia z zawartymi bazami danych przy użyciu uwierzytelniania systemu Windows.

Ucieczka z zamkniętej bazy danych

Jeśli baza danych jest częściowo zawarta, administratorzy programu SQL Server powinni okresowo przeprowadzać inspekcję możliwości użytkowników i modułów w zawartych bazach danych.

Odmowa usługi za pośrednictwem AUTO_CLOSE

Nie należy konfigurować zawartych baz danych do automatycznego zamykania. Jeśli baza danych zostanie zamknięta, otwarcie bazy danych w celu uwierzytelnienia użytkownika zużywa dodatkowe zasoby i może przyczynić się do ataku typu "odmowa usługi".

Zobacz też

zawarte bazy danych
migrowanie do częściowo zawartej bazy danych