Прозрачное шифрование данных

Есть ли лучшие рекомендации при настройке TDE в SQL Server 2008? Что касается SQLMag, в статье «Часто задаваемые вопросы о прозрачном шифровании данных» говорится, что ЦП может увеличить загрузку до 30%?

Помимо добавления мощности сервера, есть ли что-то еще, что обычно делают администраторы БД при включении TDE?

1. Некоторые дополнительные моменты, которые я заметил, это то, что если вы используете функцию сжатия резервной копии, эта функция вместе с TDE работает не так хорошо. Мы заметили очень минимальную степень сжатия, почти ничтожную. Поэтому рассмотрите эту точку сжатия резервной копии, если вы ее используете.

2. Я уверен, что вы будете в курсе, но просто добавьте, что TDE доступен для Enterprise Edition, поэтому учтите это также при настройке SQL-сервера для TDE.

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

4. Убедитесь, что ключи шифрования надежно хранятся в безопасном месте, к которому можно получить доступ в случае сценария восстановления. Ознакомьтесь с восстановлением базы данных, которая была зашифрована на новом сервере. (первоначально комментарий Джонатана Файта ).

Во-первых, перед шифрованием базы данных сделайте резервную копию главного ключа и сертификата и сохраните их в автономном режиме. Не ждите, пока вы не примените TDE, чтобы сделать это. Также сохраните пароли в хранилище паролей и проясните, какие пароли соотносятся с каким объектом; Вы действительно не хотите потерять след из этого.

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

Зашифрованы не только данные в файлах: TDE также зашифрует tempDB, поэтому, если у вас есть другие базы данных, которые интенсивно используют TempDB, вы можете заметить снижение производительности. И резервные копии, и снимки также зашифрованы.

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

При включении TDE к базе данных применяются две блокировки: общая блокировка и блокировка обновления. TechNet заявляет это полностью:

Когда TDE включен (или отключен), база данных помечается как зашифрованная в представлении каталога sys.databases, а состояние DEK установлено равным Encryption In Progress. Сервер запускает фоновый поток (называемый сканированием или сканированием шифрования), который сканирует все файлы базы данных и шифрует их (или расшифровывает их, если вы отключаете TDE). Во время выполнения DDL блокировка обновления выполняется для базы данных. Сканирование шифрования, которое выполняется асинхронно с DDL, принимает общую блокировку. Все обычные операции, которые не конфликтуют с этими блокировками, могут продолжаться. Исключенные операции включают изменение структуры файла и отключение базы данных. В то время как обычные записи в базу данных на диск из пула буферов зашифрованы, записи в файл журнала могут отсутствовать. Сканирование также вызывает переключение для файла виртуального журнала (VLF), чтобы обеспечить шифрование будущих записей в журнал.

Мой опыт был на хранилищах данных, которые почти не использовались в течение дня и интенсивно использовались в течение ночи, поэтому я смог применить TDE с минимальными перебоями в течение дня. Если вы шифруете OLTP в производственном процессе, то лучше запланировать это в течение периода обслуживания, чтобы минимизировать проблемы.

Редактировать: также в точке сжатия; Хотя верно, что TDE влияет на сжатие резервных копий, это не влияет на сжатие строк / страниц / columnstore. Поэтому, если вы хотите сбалансировать потерю сжатия из резервных копий, вы можете сжать объекты в базе данных. Опять же, в зависимости от вашей рабочей нагрузки, вы можете / не можете использовать сжатие в вашей базе данных, потому что это будет дополнительно нагружать процессор. Есть отличная статья TechNet по реализации сжатия: https://technet.microsoft.com/en-us/library/dd894051%28v=sql.100%29.aspx