Есть ли лучшие рекомендации при настройке TDE в SQL Server 2008? Что касается SQLMag, в статье «Часто задаваемые вопросы о прозрачном шифровании данных» говорится, что ЦП может увеличить загрузку до 30%?
Помимо добавления мощности сервера, есть ли что-то еще, что обычно делают администраторы БД при включении TDE?
Ответы:
Некоторые дополнительные моменты, которые я заметил, это то, что если вы используете функцию сжатия резервной копии, эта функция вместе с TDE работает не так хорошо. Мы заметили очень минимальную степень сжатия, почти ничтожную. Поэтому рассмотрите эту точку сжатия резервной копии, если вы ее используете.
Я уверен, что вы будете в курсе, но просто добавьте, что TDE доступен для Enterprise Edition, поэтому учтите это также при настройке SQL-сервера для TDE.
TDE не обеспечивает такой же детальный контроль, специфичный для роли пользователя или базы данных, как предлагается шифрованием на уровне ячейки.
Убедитесь, что ключи шифрования надежно хранятся в безопасном месте, к которому можно получить доступ в случае сценария восстановления. Ознакомьтесь с восстановлением базы данных, которая была зашифрована на новом сервере. (первоначально комментарий Джонатана Файта ).
Во-первых, перед шифрованием базы данных сделайте резервную копию главного ключа и сертификата и сохраните их в автономном режиме. Не ждите, пока вы не примените 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