¿Existen algunas prácticas recomendadas al configurar TDE en SQL Server 2008? En SQLMag, el artículo "Preguntas frecuentes sobre cifrado de datos transparentes" dice que la CPU puede haber aumentado el uso hasta en un 30%.
Además de agregar la potencia del servidor, ¿hay algo más que los DBA suelen hacer al encender TDE?
Respuestas:
Algunos puntos adicionales que he notado es que en caso de que esté utilizando la función de compresión de respaldo, esta función junto con TDE no funciona tan bien. Hemos notado una tasa de compresión muy mínima, casi insignificante. Por lo tanto, considere este punto de compresión de respaldo si está utilizando uno.
Estoy seguro de que lo sabrá, pero solo para agregar, TDE está disponible para la edición Enterprise, por lo tanto, considere esto también durante la configuración del servidor SQL para TDE.
TDE no proporciona el mismo control granular, específico para un usuario o rol de base de datos, que ofrece el cifrado a nivel de celda.
Asegúrese de que las claves de cifrado se almacenen de forma segura en una ubicación segura a la que se pueda acceder en caso de un escenario de restauración. Familiarícese con la restauración de una base de datos que se ha cifrado en un nuevo servidor. (originalmente un comentario de Jonathan Fite ).
En primer lugar, antes de cifrar una base de datos, realice una copia de seguridad de la clave maestra y el certificado y almacénelos sin conexión. No espere hasta después de haber aplicado TDE para hacer esto. También almacene las contraseñas en una bóveda de contraseñas y deje en claro qué contraseñas se correlacionan con qué objeto; realmente no quieres perder la noción de estos.
El impacto que TDE tiene en la base de datos depende completamente de la carga de trabajo involucrada: recientemente apliqué TDE a un almacén de datos y el impacto en el rendimiento de la carga nocturna no fue nada, lo que sugiere que el proceso no estaba vinculado a la CPU. Sin embargo, eso puede no ser cierto para su base de datos. Entonces, si primero puede probar la carga de trabajo en un entorno de desarrollo, hágalo.
No solo se cifran los datos en los archivos: TDE también cifrará tempDB, por lo que si tiene otras bases de datos que usan TempDB en gran medida, puede notar un impacto en el rendimiento. Tanto las copias de seguridad como las instantáneas también están encriptadas.
Considere también si esta base de datos necesita restaurarse en otros entornos (por ejemplo, prueba o UAT). Deberá restaurar el certificado utilizado para cifrar la base de datos en estos otros servidores. Esto puede no parecer un gran problema, pero si no tiene una empresa o desarrollador en ninguno de estos entornos, esto puede ser costoso. Una alternativa a la aplicación de TDE en todo el entorno es restaurar la base de datos a una instancia intermedia que sea empresa / desarrollador y codificar los datos confidenciales o soltar el cifrado y crear una nueva copia de seguridad para restaurarla en otros entornos. Esta segunda opción probablemente no sea la más sensata, pero siempre es una opción ...
Al activar TDE, hay dos bloqueos que se aplican a la base de datos: un bloqueo compartido y un bloqueo de actualización. TechNet afirma esto completamente:
Cuando TDE está habilitado (o deshabilitado), la base de datos se marca como encriptada en la vista de catálogo sys.databases y el estado DEK se establece en Encriptación en curso. El servidor inicia un subproceso en segundo plano (llamado escaneo o escaneo de cifrado) que escanea todos los archivos de la base de datos y los cifra (o los descifra si está deshabilitando TDE). Mientras se ejecuta el DDL, se toma un bloqueo de actualización en la base de datos. El escaneo de cifrado, que se ejecuta de forma asíncrona al DDL, toma un bloqueo compartido. Todas las operaciones normales que no entren en conflicto con estos bloqueos pueden continuar. Las operaciones excluidas incluyen modificar la estructura del archivo y separar la base de datos. Si bien las escrituras normales de la base de datos en el disco desde el grupo de búferes están encriptadas, las escrituras del archivo de registro pueden no estarlo. El escaneo también obliga a un rollover para el archivo de registro virtual (VLF) para garantizar que las futuras escrituras en el registro estén encriptadas.
Mi experiencia fue en almacenes de datos que apenas se usaban durante el día y se usaban mucho durante la noche, por lo que pude aplicar TDE con una interrupción mínima durante el día. Si está encriptando un OLTP en producción, lo mejor es programar esto durante una ventana de mantenimiento para minimizar los problemas.
Editar: también en el punto de compresión; Si bien es cierto que TDE afecta la compresión de respaldo, no afecta la compresión de fila / página / almacén de columnas. Entonces, si desea equilibrar la pérdida de compresión de las copias de seguridad, puede comprimir objetos en la base de datos. Nuevamente, dependiendo de su carga de trabajo, es posible que no quiera implementar la compresión en su base de datos porque esto estresará aún más la CPU. Hay un excelente artículo de TechNet sobre implementación de compresión: https://technet.microsoft.com/en-us/library/dd894051%28v=sql.100%29.aspx