Имате две алтернативи:
-
Криптографски контрол. С това само потребителите, които знаят паролата, могат да дешифрират данните. Недостатъкът е, че потребителят трябва да влезе паролата за дешифриране всеки път, когато имат достъп до данните. Отчетът трябва да съдържа параметър за парола, който потребителят, изпълняващ отчета, попълва с паролата за достъп до данни. Приложението трябва да поиска паролата от потребителя. Уеб сайтовете трябва да изискват парола от посетителя. И така нататък и така нататък
-
Контрол на достъпа. Данните са шифровани с ключ, до който самият SQL Server има достъп (в крайна сметка веригата за шифроване стига до главния ключ на услугата и това е шифровано с помощта на DPAPI). Това не ви дава по-голяма защита от тази, която предоставянето и отказването на SELECT би ви осигурило:е достъп контрол, а не криптографски контрол. Такава схема предпазва единствено от случайна загуба на носител (някой намери диск с вашата база данни или вие загубите лаптоп с базата данни на него). Можете да постигнете същото, като използвате Прозрачно шифроване на данни или криптиране на ниво файл (BitLocker ).
Обичайният сценарий за шифроване на данни е да шифровате данните със симетричен ключ и след това да шифровате симетричния ключ с асиметричен ключ (обикновено частният ключ на сертификат). След това асиметричният ключ на свой ред се криптира с парола и тази парола трябва да бъде представена при опит за достъп до данни. Основната причина за тази двустепенна индиректност е промяната на паролата:когато парола или частен ключ е компрометиран, симетричният ключ се криптира повторно с различен асиметричен ключ или асиметричният ключ се криптира повторно с различна парола. По този начин паролата за достъп е променена без да се изисква повторно криптиране на всички данни . Ако достъпът ще бъде предоставен директно до симетричния ключ, тогава компромис с парола вероятно ще изисква повторно криптиране на всички данни , възможни терабайти данни.
Там, където двата сценария, които представих, се различават е дали асиметричният ключ също е кодиран с главния ключ на базата данни или не. Случай 1) не е, случай 2) е. Всичко това е обяснено в Йерархия на шифроване .
