Назад | Перейти на главную страницу

Шифрование / дешифрование SQL Server

В рамках тестирования аварийного восстановления я пытаюсь убедиться, что я могу воссоздать свою БД и по-прежнему иметь возможность расшифровывать ранее зашифрованные строки.

Итак, вот что я делаю в качестве теста ...

  1. Создание сертификата базы данных.
  2. Резервное копирование сертификата и закрытого ключа на диск.
  3. Создание симметричного ключа, зашифрованного сертификатом.
  4. Использование EncryptByKey для шифрования «Hello World» в шестнадцатеричную строку. Сохраните эту зашифрованную строку для использования ниже.
  5. Использование DecryptByKey для расшифровки шестнадцатеричной строки в «Hellow World».

Все это отлично работает, но потом я пробую это ...

  1. БРОСЬТЕ ключ и сертификат.
  2. Повторно создайте сертификат из резервного сертификата.
  3. Создайте новый симметричный ключ точно так же, как и раньше.
  4. Попробуйте расшифровать ранее зашифрованную строку, и это не сработает.

Единственный способ заставить его работать - это указать KEY_SOURCE и IDENTITY_VALUE при создании симметричного ключа, но MSDN говорит, что IDENTITY_VALUE предназначен для создания «временных ключей», поэтому не уверен в использовании этого.

Есть идеи по этому поводу?

Не может быть плана аварийного восстановления, который требует пользователь чтобы предоставить симметричный ключевой материал для восстановления данных. Симметричные ключи хранятся вместе с данными в базе данных, и план аварийного восстановления, который восстанавливает данные, также восстанавливает ключи в процессе.

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

Вы выбрали очень плохой и опасный путь использования известного ключевого материала (KEY_SOURCE) для шифрования ваших данных. Источники ваших ключей с большой вероятностью просочатся в скрипты и другие носители, на которых хранится ключевой материал (электронные письма, файлы конфигурации и т. Д.), Поэтому на практике вам лучше просто ничего не шифровать, поскольку ваши ключи известны слишком многим и поэтому бесполезны .