Zabezpečení MS SQL serveru – role a uživatelské skupiny

Při standardní instalaci se musíme poprat ještě s dalšími nástrahami, které z našeho serveru dělají cedník. Tentokrát si popíšeme zabezpečení rolí.

Role Public

Tato role je v seznamu rolí patrně největším nebezpečím. Problémem role Public je uživatelský účet Guest. Jak už z názvu vyplývá, tento uživatelský účet je vhodný pro uživatele bez vlastního loginu, ale z pohledu zabezpečení skrývá závažné riziko zneužití. Uživatel Guest je totiž použit i pro uživatele s platným loginem, ale bez oprávnění pro konkrétní databázi. Ačkoliv by se mohlo zdát, že uživatel bez oprávnění nebude mít žádný přístup k vaší databázi, realita může být odlišná. Jak se můžete přesvědčit ve vlastnostech role Public, má dost oprávnění na to, aby vám takový uživatel ztrpčil život:

Tato role má přístup k většině uložených procedur (jak vidíte na obrázku), k funkcím, k pohledům, k systémovým tabulkám nejen u databáze master, ale i u uživatelských databází. Kompletní přehled oprávnění můžete získat pomocí uložené procedury sp_helpprotect:

U uživatelských databází lze login „Guest“ odstranit:

Bohužel u databáze master a tempdb uživatele Guest odstranit nelze. Naštěstí tento login není součástí databáze model, není tedy u nově vytvářených databází. Role public je ale obsažena ve všech databázích a také nejde odstranit. Jelikož je členem této role standardně každý, nejdou do této role zařadit další uživatelé, ale skupina reprezentuje defaultní úroveň oprávnění. Pakliže se domníváte, že by defaultně uživatelé neměli mít přístup k určitým tabulkám nebo databázovým objektům, můžete jim oprávnění pomocí skriptu odebrat:

Popsal jsem teď obecný postup odstraňování oprávnění pro roli public – respektive pro uživatele guest. Bohužel neexistuje úplný seznam, kterých objektů v databázi by se měla tato operace týkat. Druhou stranou mince omezení oprávnění je možnost, že server poškodíme a určitou funkčnost přestane SQL server poskytovat.

Obecný postup, který mohu z praxe doporučit, je odstranit u vývojového serveru „všechna“ oprávnění pomocí skriptu, aby bylo možné oprávnění jednoduše odebrat i u produkčního serveru. V případě, že během vývoje nebo testování narazíte na problém, oprávnění opravte a změnu zaznamenejte do konfiguračního skriptu. Tento konfigurační skript můžete verzovat, může být součástí projektové dokumentace a předávaných materiálů. U produkčního serveru můžete konfiguraci provést za 5 minut, aniž byste riskovali, že v návalu práce na něco zapomenete.

Role db_ddladmin

Uživatelé zařazení do této role mohou měnit objekty, vytvářet nové a odstraňovat staré. DDL je zkratkou pro podmnožinu SQL příkazů: CREATE, ALTER, DROP.

Většinou jsou do této skupiny zařazeni vývojáři, kteří mohou s objekty libovolně pracovat, u produkčního serveru už ale nedochází k žádným modifikacím (ano, vím – sci-fi), neměla by proto obsahovat žádného uživatele. Ať už používáte tuto roli nebo oprávnění na úrovni uživatelských účtů, DDL příkazy jsou v případě zneužití jedny z nejnebezpečnějších. Poměrně jednoduchým skriptem za využití uložených procedur sp_MSforeachdb a sp_MSforeachtable lze napadený server během sekundy poslat na věčnost. Tato zadní vrátka vašeho serveru by měla zůstat důkladně uzamčená.

Přístup vlastníka databáze k provoznímu serveru

Jedním z dalších bezpečnostních nedostatků je častý přístup k provoznímu serveru jako uživatel s oprávněním vlastníka databáze, nejčastěji jako „sa“. U provozního serveru už musí být provedeny všechny změny struktury (viz výše), stejně tak i nastavení zálohování, auditování a podobně. Server už by ale měl být tak zabezpečen, že NIKDO nepotřebuje přístup k produkčnímu serveru na úrovni vlastníka databáze. O tom se nediskutuje, vývojáři s tím mohou nesouhlasit, ale to je asi tak jediné co mohou dělat.

Bohužel na mnoha serverech je „sa“ heslo napsané v connection stringu přímo v jednotlivých stránkách nebo v souboru global.asa. Možná si vývojář neuvědomuje, že přenos pomocí HTTP protokolu (Frontpage Extensions), ale i přenos pomocí FTP protokolu je většinou nešifrovaný a záškodník s přístupem k přenosové trase může velice jednoduše zjistit přístupové kódy k vašemu databázovému serveru.

Přistupujete-li k provoznímu serveru pomocí Enterprise Manageru, používejte režim integrovaného zabezpečení. V opačném případě může heslo cestovat po internetu opět v nezabezpečené podobě. Navíc předchozí verze SQL serveru měly heslo z EM uloženo přímo v registry jako plaintext. V současné době je heslo sice uloženo v registry také, ale naštěstí už v zašifrované podobě, jak se můžete přesvědčit:

Bohužel ne všechny aplikace jsou dobře napsané. I mnoho komerčních produktů používá nebezpečný způsob pro ukládání hesel, proto se přesvědčete, že instalované produkty nemají heslo uložené v registry nebo přímo v konfiguračních souborech. U zakoupeného produktu většinou nebudete mít možnost to změnit, budete si však alespoň vědomi příslušného rizika. Pakliže lze ovlivnit ukládání hesla nastavením, nastavte alespoň ukládání hesla na nestandardní umístění. U rozšířených produktů velmi často útočník zná umístění jména a hesla, tímto způsobem mu můžete útok znesnadnit nebo úplně znemožnit. Ideální je nastavit ukládání hesla v zašifrované podobě, ale pozor, někdy je klíč potřebný k rozšifrování uložen na stejném místě!

Audit

Nestačí server pouze zabezpečit, tím naše služba nekončí. Velmi často je to začátek veškerého dalšího trápení. Tak jako postupem času eroduje tvrdá skála, stejně tak erodují přísná bezpečnostní nastavení. Výjimka sem, výjimka tam, a za chvíli se může stát, že z původního nastavení zůstaly jen cáry. Pocit falešného bezpečí, které většinou správce systému v takovém momentu cítí, je většinou předzvěstí velké katastrofy.

Abychom si byli jisti, že server je stále dobře zabezpečen, v pravidelných intervalech bychom měli znovu prověřovat původní nastavení. Důslednost tohoto kroku je skutečně namístě, protože na disciplíně správce systému stojí a padá zabezpečení celého serveru. Okřídlené přísloví, kterým bych obecný výklad nutností auditů ukončil, nabádá: „Řetěz je tak silný jako neslabší jeho článek.“ Pravidelnost vykonávání auditu lze zajistit pomocí SQL server agenta nebo časováním skriptu na úrovni OS. Pro audit lze použít například následující proceduru:

Procedura projde všechny databáze a vypíše členy jednotlivých rolí. Výsledek je možno uložit do textového souboru a pokaždé porovnávat s předchozím výsledkem. Můžete si také vyrobit komplexnější uloženou proceduru, která bude auditovat i další změny v nastavení databáze.

Po těchto třech krocích máme server slušně zabezpečen a zbývá poslední riziko – uložené procedury, ale o těch až příště.

Poznámka autora: Ačkoliv jsem měl pocit, že téma zabezpečení SQL serveru je poměrně konfliktní – každý má jiné postupy, zkušenosti, potřeby a pod předchozími články neprobíhala vůbec žádná diskuse. Jaké jsou vaše názory?

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.