Šifrování dat na SQL Serveru

Šifrování dat na SQL Serveru

  • Comments 3
  • Likes

Zabezpečení dat na SQL Serveru se dá uchopit mnoha různými způsoby. Ve verzi 2008 byla u SQL Serveru Enterprise představena nová možnost ochrany dat, označována jako Transparent Data Encryption (TDE).

Styl práce TDE je poněkud odlišný od tradičního šifrování dat na úrovni jednotlivých sloupců. Při využití TDE je celá databáze šifrována zcela automaticky bez zásahu uživatele a hlavně bez změny programového kódu užívaného pro databázové aplikace. Velké využití získává TDE v případech fyzického zabezpečení datových nosičů a záloh jednotlivých databází. Ano! I samotné databázové zálohy jsou stále pod ochranou TDE a tedy již není běžně možné vzít si backup databáze a bez problémů jej obnovit na jiný server.

Proces šifrování a dešifrování probíhá na úrovni načítání datových stránek do paměťového bufferu. V paměti se poté již nachází data v rozšifrované podobě. Cílem TDE je tedy chránit data ve fyzických souborech určených pro ukládání dat (mdf), transakčním logu (ldf) a záloze (bak). K šifrování dat dochází při jejich uložení na disk z paměťového bufferu zcela automaticky bez jakéhokoli zásahu uživatele. Celý proces vyžaduje určitý výpočetní výkon, obě operace – šifrování i dešifrování – potřebují pro svou práci systémové prostředky serveru. Tyto nároky jsou však mnohem nižší než u klasického šifrování sloupců, které bylo dostupné na dřívějších verzích SQL Serveru. Microsoft udává, že dochází ke zpomalení v řádu cca 3 – 5 %, což může být vzhledem k vyšší bezpečnosti dat přijatelná hodnota. Velkou výhodou TDE je také zachování možností indexace dat a bezproblémového využití cizích klíčů.

Implementace Transparent Data Encryption

Samotná implementace TDE spočívá ve 4 krocích, které je nutné provést

  • Vytvoření master key
  • Vytvoření nebo instalace certifikátu, chráněného master key
  • Vytvoření databázového šifrovacího klíče a jeho ochrana certifikátem
  • Konfigurace TDE v databázi.

Jednotlivé kroky jsou mezi sebou provázány a reflektují hierarchii klíčů a šifrování užívanou v SQL Serveru. Prvním krokem musí být vytvořen master klíč, tento klíč je uložen v systémové databázi master. Při jeho vytváření se využívá ochrana heslem, které je předáno jako parametr dotazu pro vytvoření master klíče. Zajímavou novinkou SQL Server 2011 je šifrování tohoto klíče pomocí AES algoritmu namísto stávajícího 3DES.

sql01

Dále je nutné v databázi master vytvořit certifikát, který bude použit pro ochranu šifrovacího databázového klíče. Syntaxe pro vytvoření certifikátu je opět velmi jednoduchá.

sql02

Dále je potřeba v databázi vytvořit samotný šifrovací klíč pro ochranu dat. Tuto operaci můžeme opět provést pomocí T-SQL příkazu, nebo již můžeme zvolit rozhraní SQL Server Management Studia, ve kterém máme pro šifrování samotné databáze přehledný dialog.

sql04

V rámci tohoto dialogu je potřeba vybrat šifrovací algoritmus, kterým bude celá databáze chráněna. Máme zde na výběr 4 možnosti – AES algoritmus s různou délkou klíče a algoritmus 3DES. Dále vybíráme již vytvořený certifikát. Je zde možnost použít i asymetrický klíč. Této volby se dá velmi dobře využít v kombinaci s tzv. Hardware Security Module, což je externí zařízení určené pro kryptografické operace a ukládání klíčů. Tímto způsobem můžeme oddělit klíče od administrátorů databázového serveru, a dosáhnout tak mnohem vyšší bezpečnosti uložení dat. Dále již stačí vybrat volbu Set Encryption On pro zapnutí šifrování. Pokud se podíváme následně na výstup dalšího dotazu, zjistíme, že databáze je v přechodném stavu – je šifrována. Zároveň však v tomto seznamu vidíme ještě jednu databázi a to databázi tempdb. Tato databáze je šifrována automaticky s první databází, na které zapneme TDE. Jsou tedy chráněna i data v databázi tempdb, jakmile jsou uložena na disk. Jedná se zejména o dočasné tabulky, data pro triggery (tabulky inserted, deleted) atd.

sql03

Záloha databází chráněných pomocí TDE

Zálohování databáze, která je šifrována pomocí TDE probíhá zcela standardně, např. pomocí System Center Data Protection Manager 2010. Velmi důležitou součástí zálohy je však záloha certifikátu, který je použit pro ochranu databázového šifrovacího klíče. Pokud přijdeme o tento certifikát, nebude možná obnova samotné databáze a data jsou nenávratně ztracena. Samotné dialogové okno pro šifrování i T-SQL nás varují při využití tohoto certifikátu, že ještě nebyla provedena jeho záloha. Samotná záloha klíče a certifikátu je poměrně jednoduchá. Pro obnovu certifikátu se jen musí využít možná trochu nezvyklý příkaz CREATE.

sql05

Omezení TDE

Transparentní šifrování dat není tak granulární jako předchozí mechanismy. Je nutné si uvědomit, že je šifrována opravdu celá databáze, což může být pro úvodní zašifrování v závislosti na velikosti dat časově náročná úloha. Je také nutné si uvědomit, že TDE nerozlišuje mezi uživateli, je tedy nutné stále využívat zabezpečení dat pomocí oprávnění, TDE jen doplňuje bezpečnost uložených dat.

Velkou nevýhodou je absence podpory pro funkci FILESTREAM, která dovoluje ukládat velké binární objekty mimo hlavní databázový soubor do NTFS filesystému. Další důležitou nevýhodou je nemožnost kombinovat TDE a novou kompresi zálohování, která byla uvedena stejně jako TDE v SQL Serveru 2008. Díky nové kompresi záloh je možné vytvářet zálohy mnohem rychleji a tyto zabírají méně diskového prostoru. Záleží vždy na povaze dat jaké zrychlení a úspora místa budou dosaženy. Nejsou nereálné případy 2x rychlejšího provedení zálohy, která je 3 – 5x menší než záloha nekomprimovaná. Stejně tak je nutné dbát možných dopadů na výkon, které mohou být způsobeny u vysoce zatížených systémů tím, že při šifrování databáze je vždy šifrována i databáze tempdb.

Marek Chmel, WBI Systems a.s.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Nějak nechápu výhody tohoto - ten certifikát je někde uložen v nezaheslované podobě v master databázi? Co mi pak, jako útočníkovi s admin přístupem, brání to celé dešifrovat a přečíst? Jako hlavní výhodu šifrování oproti pouhému ACL (třeba v ntfs) totiž vidím to, že data si nepřečte ani admin, ani fyzický zloděj. A to tady nevidím ...

  • V takovém případě by bylo potřeba zvolit Hardware Security Module a využít propojení TDE a Extensible Key Management. Poté by tyto informace nebyly v master databázi.

  • No sysadmin to samozrejme precte, to je z povahy veci jasne. Jak pise autor - k tomu je HSM.