Máte dvě možnosti:
-
Kryptografické ovládání. Díky tomu mohou data dešifrovat pouze uživatelé, kteří znají heslo. Nevýhodou je, že uživatel musí zadat dešifrovací heslo při každém přístupu k datům. Zpráva by měla obsahovat parametr Password, který uživatel spouštějící zprávu vyplní heslem pro přístup k datům. Aplikace si musí vyžádat heslo od uživatele. Webové stránky musí od návštěvníka vyžadovat heslo. A tak dále a tak dále
-
Řízení přístupu. Data jsou šifrována klíčem, ke kterému má přístup samotný SQL Server (v konečném důsledku jde řetězec šifrování až po hlavní klíč služby a ten je šifrován pomocí DPAPI). To vám neposkytuje žádnou větší ochranu, než jakou by vám poskytlo udělení a zamítnutí SELECT:je přístup kontrola, nikoli kryptografická kontrola. Takové schéma chrání pouze před náhodnou ztrátou média (někdo najde disk s vaší databází nebo ztratíte notebook s databází). Toho můžete dosáhnout pomocí Transparent Data Encryption nebo šifrování na úrovni souboru (BitLocker ).
Běžným scénářem šifrování dat je zašifrovat data pomocí symetrického klíče a poté zašifrovat symetrický klíč pomocí asymetrického klíče (obvykle soukromý klíč certifikátu). Asymetrický klíč je následně zašifrován heslem a toto heslo je nutné předložit při pokusu o přístup k datům. Primárním důvodem tohoto dvouúrovňového zprostředkování je změna hesla:když je prolomeno heslo nebo soukromý klíč, symetrický klíč je znovu zašifrován jiným asymetrickým klíčem nebo je asymetrický klíč znovu zašifrován jiným heslem. Tímto způsobem se změnilo přístupové heslo bez nutnosti opětovného šifrování všech dat . Pokud by byl přístup udělen přímo symetrickému klíči, pak by kompromitace hesla možná vyžadovala opětovné zašifrování všech dat , možné terabajty dat.
Kde se dva scénáře, které jsem uvedl, liší, je to, zda je asymetrický klíč také šifrován hlavním klíčem databáze nebo ne. Případ 1) není, případ 2) ano. To vše je vysvětleno v Hierarchie šifrování .