Как контролировать то, что пользователи могут расшифровать шифрование симметричного ключа SQL Server - PullRequest
8 голосов
/ 24 февраля 2010

Я пытаюсь зашифровать некоторые конфиденциальные данные в SQL Server, такие как номера банковских счетов и номера социального страхования, чтобы соответствовать новым законам штата. Я использую SQL Server 2008 в качестве базы данных с кодом .NET. Я использовал .NET для шифрования паролей, но для этого я думаю об использовании встроенного шифрования Microsoft, просто зашифровав несколько столбцов данных, которые мне нужны, с помощью простого Symmetric Key Encryption. Если я использую шифрование SQL Server, я могу расшифровать данные из сторонних инструментов отчетности, а не только из моего приложения .NET. Вот пример, который я использую: http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/

Он использует сертификат, созданный SQL Server, а затем функцию DecryptByKey для расшифровки данных, но я пытаюсь определить, насколько это безопасно на самом деле? Как я могу контролировать, какие пользователи могут дешифровать данные, или кто-нибудь может сделать это, если они открывают симметричный ключ и используют функцию дешифрования?

1 Ответ

12 голосов
/ 24 февраля 2010

У вас есть две альтернативы:

  1. Криптографический контроль. При этом только пользователи, которые знают пароль, могут расшифровать данные. Недостатком является то, что пользователь должен вводить пароль расшифровки при каждом доступе к данным. Отчет должен содержать параметр Password, который пользователь, запустивший отчет, заполняет паролем доступа к данным. Приложение должно запросить пароль у пользователя. Веб-сайты должны запрашивать пароль у посетителя. И так далее и тому подобное

  2. Контроль доступа. Данные зашифрованы ключом, к которому имеет доступ сам SQL Server (в конечном итоге цепочка шифрования проходит вплоть до мастер-ключа службы, который шифруется с использованием DPAPI). Это не дает вам большей защиты, чем предоставление и отказ SELECT: это доступ контроль, а не криптографический контроль. Такая схема защищает исключительно от случайной потери носителя (кто-то находит диск с вашей базой данных, или вы теряете ноутбук с базой данных на нем). Вы можете достичь того же самого, используя Прозрачное шифрование данных или шифрование на уровне файлов ( BitLocker ).

Распространенным сценарием шифрования данных является шифрование данных с помощью симметричного ключа, а затем шифрование симметричного ключа с помощью асимметричного ключа (обычно это закрытый ключ сертификата). Асимметричный ключ, в свою очередь, шифруется паролем, и этот пароль должен быть представлен при попытке доступа к данным. Основной причиной этого косвенного обращения является изменение пароля: когда скомпрометирован пароль или закрытый ключ, симметричный ключ повторно шифруется другим асимметричным ключом, или асимметричный ключ повторно шифруется другим паролем. Таким образом, пароль доступа изменился без необходимости повторного шифрования всех данных . Если доступ будет предоставлен непосредственно к симметричному ключу, то для компрометации пароля, возможно, потребуется перешифровать все данные , возможные терабайты данных.

Если два представленных мною сценария отличаются друг от друга, это то, зашифрован ли асимметричный ключ с главным ключом базы данных или нет. Случай 1) это не так, случай 2) это так. Это все объясняется в Иерархия шифрования .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...