Šifrování dat na SQL Serveru

ALWAYS ENCRYPTED

SQL Server slouží jako úložiště mnoha informací a často i citlivých. Tyto informace je potřeba chránit a zobrazovat pouze odpovídajícím uživatelům. Jednou z možností jak zvýšit prvek ochrany informací na SQL Serveru je šifrování. Šifrování je dostupné v mnoha formách, kdy první podpora se objevila u SQL Serveru 2005. U této verze bylo možné šifrovat pomocí různých funkcí jednotlivé sloupce. U verze 2008 byla přidána nova funkcionalita – Transparent Data Encryption.

S novou verzí SQL Server 2016 je k dispozici zcela nový přístup – Always Encrypted. Always Encrypted je nová funkcionalita, vytvořená k ochraně citlivých dat (číslo kreditní karty, rodné číslo atd.), která jsou uložena v databázi SQL Serveru. Pomocí Always Encrypted je možné tyto informace zašifrovat v klientské aplikaci tak, že SQL Server nebude mít k dispozici šifrovací klíče. Tímto je možné oddělit přístup k datům pro správce databáze a aplikační team, který data vlastní. Oddělením přístupu získáme vyšší ochranu dat, ke kterým bez vlastnictví klíče nebude mít přístup ani samotný system administrator. Resp. bude, protože data jsou stále uložena na SQL serveru, pouze nebude možné bez vlastnictví klíčů tato data dešifrovat. To samozřejmě platí i pro dřívější možnosti šifrování dat na SQL Serveru, ale tentokráte můžeme klíče uložit mimo SQL server a pro aplikaci bude vše stále transparentní.

Obrázek 1 - Architektura Always Encrypted

NASTAVENÍ ŠIFROVÁNÍ

Samotné nastavení šifrování dat je poměrně jednoduché. V porovnání s TDE nebo šifrováním sloupců pomocí funkcí mnohem jednodušší. Vše je možné zvládnout pomocí SQL Management Studia. SQL Server Data Tools aktuálně nejsou pro konfiguraci šifrování podporované. V SQL Server Management Studiu je nejprve potřeba vytvořit dva klíče – column master key a column encryption key. Column master key chrání šifrovací klíč column encryption key, kterým jsou šifrována data v tabulce. Vytvoření column master key je možné přes jednoduchý dialog, kde si uživatel vybere úložiště pro master key – což může být certificate store uživatele nebo lokálního systému, služba Azure Key Vault nebo smart card.

Obrázek 2 - Column Master Key

Po vytvoření CMK je nutné vytvořit šifrovací klíč, který bude pomocí CMK chráněn. I tady je hierarchie klíčů a certifikátů mnohem jednodušší než například u Transparent Data Encryption.

Obrázek 3 - Vytvoření CEK

Máme-li dostupné oba klíče, je následně možné zašifrovat sloupce v tabulce.

Obrázek 4 - Šifrování sloupců

Při výběru šifrování je možné zvolit dva druhy a to deterministické a random šifrování. Pokud je zvolen typ deterministický, tak je hodnota zašifrována vždy se stejným výsledkem, což je velmi důležité pro vyhledávání v databázi, pro porovnávání pomocí operátorů atd, nelze však používat všechny operátory jako např. LIKE, který v aktuální verzi není podporován.

Jakmile jsou data zašifrována, tak jsou pro běžného uživatele v této zašifrované podobě čitelná. Chceme-li mít přístup k dešifrovaným informacím, je nutné do connection string přidat další parametr a to column encryption setting=enabled. Při tomto parametru jsou data dostupná v otevřené podobě v případě, že má aplikace a uživatel přístup k CMK klíči.

LIMITY ALWAYS ENCRYPTED

Jako mnohé další funkcionality serveru, i Always Encrypted má svá omezení. Předně je zde velké množství datových typů, pro které Always Encrypted není podporované.

Nepodporované typy jsou: xml, timestamp/rowversion, image, ntext, text, sql_variant, hierarchyid, geography, geometry, filestream

Tím by výčet nekončil, dále je zde mnoho dalších omezení, zejména na úrovni indexů a statistik, kdy šifrovaný sloupec nemůže být klíčem v indexu, ve statistikách, není možné použít tzv. default constraint, check constraint, nefunguje replikace, nelze šifrovat sloupec použitý pro table partitioning, šifrování není kompatibilní s change data capture atd. Dalším výrazným faktorem je přístupová knihovna – dnes (během dostupnosti verze SQL Server 2016 RC1) je podporováno pouze ADO.NET jako součást .NET Framework 4.6. Dostupná je sice knihovna JDBC, ale pouze v preview verzi, která má svá omezení – hlavním z nich je nemožnost přistupovat k datům zašifrovaným přes JDBC pomocí knihovny ADO.NET, tedy cross platform aplikace zatím nebudou fungovat. Dále ještě u této preview verze nefunguje bulk copy a jsou zde další drobné detaily. Více o využití knihovny JDBC najdete na tomto odkazu.

Dalším faktorem pro nasazení Always Encrypted je zátěž systému, nebo spíše prodleva při práci s daty. Při čtení šifrovaných dat a jejich dešifrování téměř nedochází ke zpomalení dotazů. Zcela jinak to však vypadá v případě ukládání dat, kdy operace trvají mnohem déle. Během testů docházelo až ke dvojnásobnému zpomalení dotazů pro vložení dat do databáze. Šifrováním není ovlivněna jen rychlost zpracování dat, ale také velikost dat uložených na disku (in memory tabulky také nejsou podporovány v aktuální testovací verzi SQL Serveru). Pro uložení šifrovaných dat je potřeba mnohem více úložného prostoru – počítejte s dvojnásobným až trojnásobným nárůstem velikosti tabulek obsahujících šifrované sloupce.

ZÁVĚREM

Always Encrypted nám přináší zcela nové možnosti šifrování dat v databázích SQL Serveru. Pomocí jednoduchého postupu je možné oddělit přístup správce data a správce databáze, což tradiční šifrovací možnosti nenabízely. V aktuální verzi SQL Serveru jsou sice značná omezení, nicméně se stále nejedná o finální verzi produktu. Některá z omezení nebo výkonnostních parametrů mohou být ve finální verzi odlišné.

- Marek Chmel, MVP: Data Platform, MCT Regional Lead, at&t