Sdílet prostřednictvím

Osvědčené postupy zabezpečení s databázemi s omezením

  • Článek

platí pro:SQL Serverazure SQL Managed Instance

Databáze v kontejnerech mají určitá jedinečná rizika, kterým by správci databázového stroje SQL Serveru měli porozumět a zmírnit je. Většina hrozeb souvisí s procesem ověřování USER WITH PASSWORD, který přesune hranici ověřování z úrovně databázového stroje na úroveň databáze.

Uživatelé v samostatné databázi, kteří mají oprávnění ALTER ANY USER, jako jsou členové db_owner a db_accessadmin pevných databázových rolí, mohou udělit přístup k databázi bez vědomí nebo svolení správce SQL Serveru. Udělení přístupu uživatelů k databázi s omezením zvyšuje potenciální prostor pro útok na celou instanci SQL Serveru. Správci by měli porozumět tomuto delegování řízení přístupu a být opatrní při udělování uživatelů v obsažené databázi ALTER ANY USER oprávnění. Všichni vlastníci databáze mají oprávnění ALTER ANY USER. Správci SQL Serveru by měli pravidelně auditovat uživatele v obsažené databázi.

Přístup k jiným databázím pomocí účtu hosta

Vlastníci databází a uživatelé databáze s oprávněním ALTER ANY USER mohou vytvářet uživatele databáze s omezením. Po připojení k databázi s omezením na instanci SQL Serveru může uživatel databáze s omezením přistupovat k jiným databázím v databázovém stroji, pokud ostatní databáze povolili účet hosta.

Vytvoření duplicitního uživatele v jiné databázi

Některé aplikace můžou vyžadovat, aby měl uživatel přístup k více než jedné databázi. To lze provést vytvořením identických obsažených uživatelů databáze v každé databázi. Při vytváření druhého uživatele s heslem použijte možnost SID. Následující příklad vytvoří dva identické uživatele ve dvou databázích.

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

Chcete-li spustit dotaz mezi databázemi, musíte pro volající databázi nastavit možnost TRUSTWORTHY. Pokud je například uživatel (Carlo) definovaný výše v databázi DB1, aby bylo možné spustit SELECT * FROM db2.dbo.Table1;, musí být pro databázi DB1 zapnuté nastavení TRUSTWORTHY. Spuštěním následujícího kódu nastavte nastavení TRUSTWORTHY.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Vytvoření uživatele, který duplikuje přihlášení

Pokud je vytvořen uživatel databáze s omezením s heslem se stejným názvem jako přihlášení k SQL Serveru a pokud se přihlášení k SQL Serveru připojí k zadání databáze obsažené jako počátečního katalogu, přihlášení k SQL Serveru se nebude moct připojit. Připojení bude vyhodnoceno jako uživatel obsažené databáze s hlavním heslem na obsažené databázi místo jako uživatel na základě přihlášení k SQL Serveru. To může způsobit úmyslné nebo náhodné odepření služby pro přihlášení k SQL Serveru.

  • Osvědčeným postupem je, že členové správce systému pevnou roli serveru by měli zvážit vždy připojení bez použití počáteční možnosti katalogu. Tím se připojí přihlášení k hlavní databázi a zabráníte všem pokusům vlastníka databáze o zneužití pokusu o přihlášení. Správce pak může přejít na obsahovanou databázi pomocí příkazu USE<databáze>. Můžete také nastavit výchozí databázi přihlášení na obsaženou databázi, což dokončí přihlášení do mastera poté přenese přihlášení do obsažené databáze.

  • Osvědčeným postupem je nevytvádřovat uživatele databáze s hesly, která mají stejný název jako přihlášení k SQL Serveru.

  • Pokud existuje duplicitní přihlášení, připojte se k hlavní databázi bez zadání počátečního katalogu a potom spusťte příkaz USE k přepnutí na obsahovanou databázi.

  • Pokud existují obsažené databáze, uživatelé neobsahovaných databází by se měli připojit k databázovému serveru bez použití počátečního katalogu nebo zadáním názvu databáze, která není obsaženou, jako počátečního katalogu. Tím se zabrání připojení k obsažené databázi, která je pod méně přímou kontrolou správců databázového stroje.

Zvýšení přístupu změnou stavu zahrnutí databáze

Přihlášení, která mají oprávnění ALTER ANY DATABASE, jako jsou členové pevné serverové role dbcreator, a uživatelé v nedělené databázi, kteří mají oprávnění CONTROL DATABASE, jako jsou členové pevné databázové role db_owner, mohou změnit nastavení obsaženosti databáze. Pokud se nastavení izolace databáze změní z NONE na ČÁSTEČNÉ nebo ÚPLNÉ, uživatelský přístup lze udělit vytvořením uživatelů omezené databáze s hesly. To by mohlo poskytnout přístup bez znalosti nebo souhlasu správců SQL Serveru. Chcete-li zabránit, aby všechny databáze byly obsaženy, nastavte databázový strojobsažené ověřování databáze možnost 0. Pokud chcete zabránit připojení uživatelům databáze s omezením s hesly ve vybraných databázích, použijte triggery přihlášení ke zrušení pokusů o přihlášení uživatelů databáze s hesly.

Připojení obsažené databáze

Připojením obsažené databáze může správce udělit nežádoucím uživatelům přístup k instanci databázového stroje. Správce, který se obává tohoto rizika, může databázi online převést do režimu RESTRICTED_USER, což brání ověřování uživatelů obsažených databází s hesly. K databázovému systému budou mít přístup pouze uživatelé autorizovaní prostřednictvím přihlášení.

Uživatelé se vytvářejí podle aktuálních požadavků na heslo v době jejich vytvoření a hesla se při připojení databáze znovu nekontrolují. Připojením databáze s omezením, která umožňovala slabá hesla k systému s přísnějšími zásadami hesel, může správce povolit hesla, která nesplňují aktuální zásady hesel na připojovacím databázovém stroji. Správci se můžou vyhnout zachování slabých hesel tím, že vyžadují resetování všech hesel pro připojenou databázi.

Zásady hesel

Hesla v databázi mohou být nastavena tak, aby byla silná, ale nemohou být chráněna robustními zásadami hesel. Ověřování systému Windows používejte, kdykoli je to možné, abyste využili rozsáhlejších zásad hesel dostupných ve Windows.

Ověřování protokolem Kerberos

Užavření uživatelé databáze s hesly nemohou používat ověřování Kerberos. Pokud je to možné, použijte ověřování systému Windows k využití funkcí systému Windows, jako je Kerberos.

Útok na offline slovník

Hashované hodnoty hesel uživatelů obsahové databáze s hesly jsou uloženy v obsahové databázi. Každý, kdo má přístup k databázovým souborům, by mohl na uživatele databáze s omezením s hesly v neauditovém systému provádět slovníkový útok. Pokud chcete tuto hrozbu zmírnit, omezte přístup k databázovým souborům nebo povolte pouze připojení k databázím s omezením pomocí ověřování systému Windows.

Únik z omezené databáze

Pokud je databáze částečně obsažená, správci SQL Serveru by měli pravidelně auditovat možnosti uživatelů a modulů v obsažených databázích.

Odepření služby prostřednictvím AUTO_CLOSE

Nenakonfigurujte databáze s omezením tak, aby se automaticky zavřely. Pokud je databáze zavřená, otevření databáze pro ověření uživatele spotřebovává další prostředky a může přispět k útoku do odepření služby.

Viz také

zapouzdřené databáze
Přechod na částečně izolovanou databázi