DBA je strážcem dat a existují dva aspekty být strážcem. První z nich je integrita. Zahrnuje úkoly, jako je kontrola konzistence databáze, vytváření záloh, a pokud se objeví nějaké problémy, má dobře navržený a komplexní plán obnovy databáze.
Druhým aspektem je bezpečnost. Navrhuje zajistit, aby k datům měli přístup pouze oprávnění uživatelé a pouze k datům, která potřebují.
Na webu můžete najít četné zdroje věnované bezpečnosti. I když si myslím, že některým důležitým věcem chybí náležitá pozornost. V tomto článku bych se chtěl zaměřit na tyto možnosti a ukázat, proč je důležité si je uvědomovat a správně s nimi zacházet.
Mise ke kompromitaci serveru SQL
Pojďme si zahrát hru na hrdiny, ve které jste tajným agentem a vaším úkolem, pokud to přijmete, je ukrást velmi důležitá data z TargetDB databáze hostovaná SQL Serverem. Musíte získat tato data a smazat je.
Je možné získat přihlášení pro vás, ale každé přihlášení na server má explicitní DENIED oprávnění k cílové databázi a datům. Jedinou informací, kterou vám náš agent může poskytnout, je ta, která byla vygenerována pro ověření bezpečnostním protokolem při vytváření vašeho přihlášení.
Informace o databázi z cílového serveru.
Oprávnění serveru:
Oprávnění k databázi:
Jako každý slušný agent, pojďme udělat domácí úkol a zkontrolovat, s čím máte co do činění.
Nemůžete se jen přihlásit a připojit k TargetDB , protože každé jednotlivé oprávnění je pro vaše přihlášení a jeho namapovaného uživatele výslovně zakázáno. Musíte se dostat z jiné databáze.
Zamčené dveře
Akce napříč databázemi nejsou jednoduché věci. Považujte to za zavřené dveře se dvěma zámky. Nebudeme se zde soustředit na technické detaily, ale můžete si přečíst článek Rozšíření zosobnění databáze pomocí EXECUTE AS MSDN (vřele doporučuji).
První zámek je Důvěřovat autentizátorovi a druhý je Důvěřovat databázi .
Začněme prvním zámkem. Důvěřovat autentizátoru znamená, že pro přístup k jiné databázi B musí být vlastníkovi databáze A udělen (explicitně nebo implicitně) AUTHENTICATE oprávnění v databázi B.
Počkej chvíli! Autentizátor na úrovni databáze je vlastníkem samotné databáze (nezaměňujte ji s db_owner databázová role!).
Zkontrolujte vlastníky databáze:
I když dodržují docela dobrou praxi tím, že používají jeden účet na server, což není SA , tímto způsobem pro vás laskavě otevřeli první zámek.
Zaměřme se na druhý zámek.
Nějakým způsobem musíte mít na serveru vytvořenou databázi s DŮVĚRYHODNÝM vlastnost ZAPNUTO . Zde je osvědčeným postupem nastavit vlastnost databáze TRUSTTWORTHY na hodnotu OFF .
To je čas, kdy bychom si měli říci:co když už takovou databázi máte?
Je to databáze MSDB.
Druhý zámek je hotový. Dokonce jste ani nemuseli rozbít žádný ze zámků.
Význam role db_owner
Právě teď se musíte vypořádat s jednou výzvou. Nějakým způsobem se musíte dostat do databáze MSDB pomocí db_owner databázovou roli, protože má implicitní oprávnění k předstírání identity.
Protože MSDB není obvykle středem zájmu administrátorů databází, není tato mise již nemožná. Pojďme se podívat, co můžete dělat jen proto, že máte uživatele s db_owner databázová role v databázi MSDB:
Zkuste se připojit k TargetDB :
Toto je očekávaná chyba. Zapamatujte si bezpečnostní protokol použitý na poskytnutém přihlášení. Začněme.
Zkuste se připojit k TargetDB a vyberte cílová data:
Funguje to! Upravme jej a poté ověřte akci.
To je vše.
Mise splněna.
Jak jste viděli, zaměřil jsem se na konkrétní kombinaci konfigurace bezpečnostní databáze. Tito byli vlastníkem databáze a DŮVĚRYHODNÝM možnost databáze se zvláštní pozorností na MSDB. Prezentovaný scénář byl pouze jedním ze scénářů, ve kterých mohou být citlivá data ohrožena stejným způsobem. Podívejme se nyní na další možný scénář.
Vlastník databáze + DŮVĚRYHODNÝ
Podívejme se na podrobnosti o pozadí počínaje známým problémem:vlastnictví databáze. Jaké přihlašovací údaje by měl vlastník vaší databáze (databází) používat? Mnoho lidí říká, že SA je vhodnou volbou.
Rychle jsem prohledal Google a našel odpovědi jako jsou následující:
„Nepamatuji si, že by mě to někdy znepokojovalo. Kromě toho, že vypadáte otravně ve zprávách nebo že nemůžete odebrat uživatele, pokud vlastní databázi, ale nemyslím si, že to ovlivňuje operace serveru. Stačí vybrat sa pro konzistenci.“
Nebo
„Nemyslím si, že vlastnictví databáze SA nebo jiným uživatelem by mělo být znepokojující. Důležité je, kdo „co“ ve vaší databázi provádí. Je tedy dobré vytvořit uživatele s platnými oprávněními. Pro zjednodušení můžete určit vlastníka jako SA.“
Současná situace je taková, že používání účtu SA jako vlastníka databáze je NEJHORŠÍ praktika . Osobně si myslím, že by to mělo být zdůrazněno na každém blogu a v každé dokumentaci související s tímto tématem.
Pokud bychom vytvořili uživatele pouze s platnými oprávněními, stačilo by to, ale bohužel to tak většinou nefunguje. Musíte být připraveni na „nejhorší možné“ scénáře. Jen si představte, co bychom mohli dělat v našich dřívějších příkladech, kdyby výchozím vlastníkem databáze byl SA !
Pokračujme druhou možností, DŮVĚRYHODNÝ možnost databáze. Situace je o něco lepší, ale stále má společný problém. Jak se běžně považuje, nejlepším postupem je zde vypnout vlastnost databáze „Důvěryhodná“ . Právě jsme viděli, proč je tato možnost špatná .
Ale to není všechno. Pokud se pokusíte najít nějaké skripty pro kontrolu této vlastnosti, pravděpodobně najdete skript podobný tomuto:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'sp_Blitz skript, který kontroluje stav SQL Server, také kontroluje výchozí nastavení databází (včetně DŮVĚRYHODNÉ jako výchozí hodnota 0) a hlásí každou databázi, která má jiné než výchozí nastavení. Skript však přeskočí systémové databáze.
Dále je zde článek MS KB, který se tomuto tématu věnuje. Viz pokyny pro použití nastavení databáze DŮVĚRYHODNÉ v SQL Server:
V článku je ukázka kódu, která uvádí databáze, které mají zapnutý bit DŮVĚRYHODNÝ a jejichž vlastníci databáze patří do role sysadmin serveru:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Co je v těchto skriptech běžné? Každý skript neobsahuje MSDB, ale jak poznamenává článek MS KB, právě jste to viděli v naší „misi“:
Poznámka :Ve výchozím nastavení je nastavení DŮVĚRYHODNÉ pro databázi MSDB nastaveno na ZAPNUTO. Změna tohoto nastavení z jeho výchozí hodnoty může mít za následek neočekávané chování komponent SQL Server, které používají databázi MSDB.
Rád bych zdůraznil, že hlavní náplní této sekce není ani možnost DŮVĚRYHODNÉ databáze, ani samotná vlastnost vlastníka databáze, ale kombinace těchto dvou možností. Většinou jsem se soustředil na MSDB, protože nastavení DŮVĚRYHODNÉ je pro databázi MSDB ve výchozím nastavení nastaveno na ZAPNUTO.
Závěr
To je prozatím vše. Prošli jsme a zkontrolovali praktické scénáře, které se týkají zabezpečení SQL Serveru. Zkontrolovali jsme také důležité možnosti databáze, jako vlastníka databáze a nastavení databáze DŮVĚRYHODNÉ.
Chtěl jsem jen upozornit na tyto možnosti, protože – protože jsou kritické, zvláště když o nich mluvíme v kombinaci.