Los grupos de disponibilidad son fantásticos para las soluciones de alta disponibilidad/recuperación ante desastres, y estoy seguro de que los demás administradores de bases de datos estarán de acuerdo conmigo. Sin embargo, habrá ocasiones en las que debamos tener en cuenta ciertas precauciones y pasos adicionales para evitar sorpresas no deseadas. Por ejemplo, cualquier Réplica secundaria se convierte en la Réplica principal actual por cualquier motivo, y nuestro objetivo es evitar que eso suceda.
Hay dos opciones de cifrado proporcionadas por SQL:sql tde vs siempre cifrado. En este artículo, voy a mostrar un escenario que requiere que el DBA preste especial atención a los detalles. Tal como dice el título, lo guiará a través de la forma adecuada de lidiar con el cifrado de datos dentro de las bases de datos que forman parte de la configuración del grupo de disponibilidad AlwaysOn.
Consideraciones iniciales
Usaré el Cifrado de datos transparente (TDE) como tecnología para desarrollar mi caso. Se aplica a todas las versiones compatibles de SQL Server. Es importante mencionar que esta función está disponible solo en las siguientes ediciones de SQL Server:
- Evaluación de SQL Server 2019, Estándar, Desarrollador, Empresa
- Evaluación de SQL Server 2017, Desarrollador, Empresa
- Evaluación de SQL Server 2016, Desarrollador, Empresa
- Evaluación de SQL Server 2014, Desarrollador, Empresa
- Evaluación de SQL Server 2012, desarrollador, empresa
- SQL Server 2008R2 Datacenter, evaluación, desarrollador, empresa
- Evaluación de SQL Server 2008, desarrollador, empresa
Veamos cómo podemos usar TDE (Cifrado de datos transparente) en SQL Server Standard Edition. En primer lugar, necesitamos crear una DMK (clave maestra de base de datos) para cifrar los datos. Luego, creamos un certificado y una clave para poder descifrar los datos mientras accedemos a ellos. No olvide hacer una copia de seguridad del certificado y, finalmente, habilitar el cifrado.
Nota: La característica TDE no es compatible con SQL Server Express Edition.
Esta publicación no cubrirá los pasos para crear un grupo de disponibilidad, y confío en el que ya se creó para fines de prueba. Puede obtener más información sobre cómo implementar grupos de disponibilidad de SQL Server AlwaysOn en Linux.
El entorno está basado en Windows, pero los principios serán muy similares si usa diferentes plataformas (por ejemplo, SQL Server en Linux o Azure SQL Managed Instances).
Qué es el cifrado de datos temporales
La razón principal por la que usamos TDE es la seguridad de los datos y archivos de registro para su base de datos SQL. Para evitar que sus datos personales sean robados, es una buena idea defenderlos, además este proceso de encriptación es muy fácil. Antes de que la página se escriba en el disco, los archivos se cifran a nivel de página. Cada vez que desea acceder a sus datos, se descifran. Después de la implementación de TDE, necesitará un certificado específico y una clave para restaurar o adjuntar la base de datos. Eso es lo que es un algoritmo de encriptación.
Microsoft Ejemplo de grupo de disponibilidad de SQL Server
Mi grupo de disponibilidad de prueba consta de 2 réplicas, cada una en su propia máquina virtual. Estas son las propiedades básicas:
Como puede ver, no hay nada especial, solo un par de réplicas que utilizan el modo de confirmación sincrónica y el modo de conmutación por error manual.
La siguiente captura de pantalla muestra una base de datos llamada "prueba". Se agrega al grupo de disponibilidad AlwaysOn de SQL Server y está en estado sincronizado.
Cómo habilitar TDE en SQL Server
Estos son los pasos para habilitar SQL Server TDE para la base de datos de "prueba". Nota :ejecutaremos los siguientes pasos en la réplica principal actual.
Cree una clave maestra en la base de datos maestra.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Paso 2
Cree un certificado protegido por la clave maestra.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Paso 3
Cree la clave de cifrado de la base de datos (DEK) y protéjala con el certificado creado en el paso 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Paso 4
Configure la base de datos de "prueba" para usar encriptación.
ALTER DATABASE test
SET ENCRYPTION ON;
¿Cómo verificar si TDE está habilitado?
Una vez que haya terminado, debe confirmar que el Cifrado de datos transparente en SQL Server está habilitado para la base de datos de "prueba".
En las Propiedades de la base de datos sección, vaya a Opciones página. Ahí, presta atención al Estado área en la parte inferior de la ventana. El Cifrado habilitado el valor debe ser Verdadero .
También puede ejecutar el siguiente código TSQL para confirmarlo:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Problema de gestión y certificación de claves
Nota: No se sorprenda si descubre que tempdb también está encriptado. Esto se debe a que tempdb es donde se realizan todo tipo de operaciones (por ejemplo, clasificación, combinaciones hash, etc.), utilizando los datos de todas las bases de datos. Por lo tanto, si al menos una base de datos de usuario está cifrada, las operaciones de esa base de datos en particular pueden ir a tempdb, que deberá devolver esos datos a la base de datos de usuario. Por lo tanto, enviar datos sin cifrar representaría el problema.
Puede leer más sobre el cifrado de copias de seguridad en SQL Server para mejorar la seguridad de su base de datos.
Puede usar el siguiente código TSQL para confirmar que hay una clave maestra de base de datos presente para la base de datos de "prueba" que está cifrada por el certificado (como se ejecuta en el Paso 3):
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Hasta ahora todo bien, al menos para la réplica principal. Pero, ¿qué sucede si consultamos las sys.databases? vista del sistema para confirmar el estado de cifrado de la base de datos de "prueba" en la réplica secundaria?
El grupo de disponibilidad replica todo lo relacionado con la base de datos de una réplica a otra. Sin embargo, la réplica secundaria indica claramente que no está cifrada.
Revisemos nuestra réplica secundaria en busca de pistas al respecto:
El estado de la base de datos es “No sincronizando / Sospechoso” – no se ve bien en absoluto. Sin embargo, después de inspeccionar el registro de errores de la réplica secundaria, puedo ver lo siguiente:
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
El principal problema es que el certificado utilizado para cifrar la clave de cifrado de la base de datos de la base de datos de "prueba" (Paso 3) no está presente en la réplica secundaria.
¿Por qué?
Porque los grupos de disponibilidad no replican datos de las bases de datos del sistema. El certificado del servidor que falta reside en la base de datos principal de la réplica principal.
Cómo verificar y configurar el certificado TDE en SQL Server
Generemos una copia de seguridad del certificado del servidor en la base de datos principal de la réplica principal. Luego vamos a restaurarlo en la base de datos maestra de la Réplica Secundaria.
Utilice el siguiente código TSQL para generar la copia de seguridad de la réplica principal actual que tiene la base de datos de "prueba" con TDE habilitado:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Antes de intentar restaurar el certificado en la réplica secundaria, primero verifique si la clave maestra de la base de datos existe dentro de la base de datos maestra. Si no, créelo exactamente como en el Paso 1.
Utilice el siguiente código TSQL para restaurar el certificado en la réplica secundaria. Nota :asegúrese de copiar primero los archivos .cer y .pvk en el directorio de destino.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Por lo tanto, incluso después de restaurar el certificado en la réplica secundaria, el estado de la base de datos de "prueba" sigue siendo el mismo:
Dado que el movimiento de datos para la base de datos de "prueba" está en pausa, reanudémoslo manualmente para ver si tenemos suerte esta vez:
¡Sí! La operación fue exitosa. La base de datos de "prueba" no solo está completamente sincronizada y en buen estado, sino que también está cifrada con TDE.
Además, después de la realización del failover manual para intercambiar los roles de las réplicas, todo sigue funcionando perfectamente bien.
Conclusión
La solución mostrada funcionó perfectamente bien. Sin embargo, puede que no sea ideal en todos los casos, especialmente si usted es un DBA al que le gusta planificar y hacer las cosas de la manera "correcta". Veo "correcto" de la siguiente manera:
- Eliminar la base de datos del grupo de disponibilidad
- Ejecute todos los pasos para habilitar el cifrado de datos transparente en la réplica donde se lee/escribe la base de datos.
- Haga una copia de seguridad del certificado del servidor de la réplica principal.
- Copie el archivo de copia de seguridad en las ubicaciones de las réplicas secundarias.
- Restaurar el certificado en la base de datos maestra.
- Vuelva a agregar la base de datos al grupo de disponibilidad.
- Asegúrese de que el estado operativo de la base de datos sea el correcto y el previsto (dependiendo de su configuración particular).
Estoy poniendo comillas dobles para "correcto" porque en la forma en que presenté la solución, obtuve la base de datos en la Réplica secundaria marcada como Sospechosa. Esto solo probablemente generaría muchas banderas/alertas/señalamientos no deseados. Es un ruido innecesario que puede evitar fácilmente si tiene en cuenta todas las consideraciones para planificar e implementar correctamente TDE en una configuración de grupo de disponibilidad siempre activo.
Para terminar esta publicación, los dejo con la jerarquía de cifrado oficial utilizada para TDE, que Microsoft ha publicado en su sitio web. Lo que me gustaría que tuviera en cuenta es dónde se crea cada elemento (ya sea en la base de datos principal o de usuario), para que pueda superar cualquier posible problema o sorpresa con los grupos de disponibilidad.
En caso de que no lo sepa, SQL Complete puede ayudarlo en gran medida a configurar Always Encrypted, que es otra tecnología útil para proteger datos confidenciales.
Tenga en cuenta que deberá tener en cuenta lo mismo que se analiza en este artículo si planea tratar con Always Encrypted en un escenario de grupo de disponibilidad Always On. Sin embargo, las características que introduce SQL Complete v6.7 están diseñadas para garantizar que tenga éxito desde el principio.
