¿Puedo recuperar un certificado TDE restaurando la base de datos MASTER?
10
(Afortunadamente, actualmente no estamos en esta situación, solo estamos planeando con anticipación para ver cuáles serían nuestras opciones si alguna vez ocurriera).
Para una base de datos cifrada con Cifrado de fecha transparente (TDE), una copia de la copia de seguridad de la base de datos es irrecuperable a menos que tenga una copia de seguridad del certificado utilizado para cifrarla.
¿Qué pasa si no tienes eso? ¿Hay alguna opción adicional?
En caso de una falla total del servidor, ¿la restauración de una copia de seguridad de la base de datos MASTER en un nuevo hardware también restauraría el certificado?
Dado que TDE se basa en un certificado almacenado en el maestro (que se usa para cifrar la clave de cifrado de la base de datos), esto solo funcionaría si pudiera restaurar la base de datos maestra a otro servidor de tal manera que el certificado pudiera descifrarse.
Esta es la jerarquía de cifrado TDE:
Clave maestra de servicio (protegida por Windows; vinculada a las credenciales de la cuenta de servicio y una clave de máquina)
Clave maestra de la base de datos (en este caso, la de la base de datos maestra)
Certificado
Clave de cifrado TDE
Los primeros tres elementos se almacenan en la base de datos maestra y se pueden hacer copias de seguridad. El cuarto se almacena (encriptado por el certificado del # 3) en el encabezado de la base de datos encriptada.
Entonces, en un escenario de falla, tendría que restaurar suficiente jerarquía de cifrado para permitirle leer la clave TDE. SQL Server crea la clave maestra de servicio en la instalación; por lo tanto, mientras que la restauración de la base de datos maestra en una instancia diferente también restaurará los elementos 2 y 3, las claves necesarias para descifrarlos no estarán presentes. Resultado: datos ilegibles.
Las dos mejores opciones son restaurar el certificado (# 3) desde una copia de seguridad (una buena opción si el maestro no se puede restaurar por alguna razón), o restaurar su base de datos maestra y su clave maestra (# 2) desde una copia de seguridad. La restauración de la clave maestra puede ser una mejor opción si tiene una gran cantidad de certificados / claves protegidos por esta clave y necesita hacer que todos sean accesibles a la vez. Esto viene con las mismas precauciones normalmente asociadas con la restauración de la base de datos maestra (intercalaciones, inicios de sesión, nombres de bases de datos y rutas de archivos, etc.)
En general, solo recomendaría restaurar el maestro en un escenario de recuperación. Para un escenario de migración / escalamiento horizontal (como usar Grupos de disponibilidad / duplicación con una base de datos encriptada con TDE), es mejor hacer una copia de seguridad / restaurar el certificado (# 3) para que esté encriptado usando las claves maestras únicas para cada instancia en movimiento a. Deberá incluir la clave privada con la copia de seguridad del certificado.
En cualquier caso, tendrá que hacer copias de seguridad de claves / certificados, así que protéjalas bien y guárdelas en ubicaciones seguras y redundantes. Simplemente tener una copia de seguridad de master no lo sacará de un desastre de TDE; necesitará una copia de seguridad de al menos una clave o certificado.
Hmm, entonces, ¿cómo es que podemos restaurar el certificado en otro servidor sin restaurar también el SMK (1) o el master db DMK (2)? ¿Se "adjunta" a SMK / DMK desde ese nuevo servidor?
BradC
Ah, creo que lo entiendo: cuando exporta el certificado, está proporcionando explícitamente una clave para la exportación, que reemplaza la dependencia de SMK / DMK del servidor original. Al importar en el nuevo servidor, está transfiriendo la dependencia al SMK / DMK del nuevo servidor. ¿Eso suena bien?
BradC
Sí, eso es casi exactamente eso. Cuando exporta o importa un certificado, debe proporcionar una contraseña que se use para cifrar / descifrar la copia de seguridad. Cuando restaura la copia de seguridad, el certificado se importa y se vuelve a cifrar con el DMK del servidor de destino.
db2
5
1.Si desea restaurar una copia de seguridad cifrada a otro servidor como de costumbre, se encuentra con el siguiente error
Cannot find server certificate with thumbprint …...
2.Encuentre el nombre del certificado: en este ejemplo, vestacert
SELECT*FROM sys.certificates
3. respalde el certificado del servidor de origen (servidor cifrado de origen):
BACKUP CERTIFICATE vestacert
TOFILE='c:\Backup\certificate_TDE_Test_Certificate.cer'WITH PRIVATE KEY(FILE='c:\Backup\certificate_TDE_Test_Key.pvk',
ENCRYPTION BY PASSWORD ='Password12#')
4.Cree un nuevo Master Cert en el servidor UAT si aún no existe
USE master GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD ='D1ffPa$$w0rd'
5.Restaurar certificados de copia de seguridad en el servidor UAT (servidor UAT)
CREATE CERTIFICATE vestacert2
FROMFILE='C:\tmp\certificate_TDE_Test_Certificate.cer'WITH PRIVATE KEY(FILE='C:\tmp\LCMS\certificate_TDE_Test_Key.pvk',
DECRYPTION BY PASSWORD ='Passsword12#')
6. Después de este paso, la restauración de la copia de seguridad no tiene ningún error y todos los datos fueron legibles.
7. Pero lo curioso es que eliminar el cifrado simplemente y tomar una nueva copia de seguridad y restaurarlo en el servidor final (Servidor final) no funciona y da el siguiente error El archivo "mydb_log" no se pudo inicializar correctamente. Examine los registros de errores para obtener más detalles.
8. La forma correcta de eliminar el cifrado de UAT es eliminar todos los signos como se muestra a continuación paso a paso y de abajo hacia arriba
USE master
ALTERDATABASE mydb SET ENCRYPTION OFFUSE mydb
DROPDATABASE ENCRYPTION KEYUSE master
DROP CERTIFICATE vestacert2
DROP MASTER KEY
9. Ahora cree una nueva copia de seguridad desde el servidor UAT y restaure al servidor final
La restauración del registro falla porque el archivo de registro todavía tiene contenido cifrado. Después de deshabilitar, cambie al modo Simple, retroceda para truncar el registro y LUEGO haga una copia de seguridad nuevamente.
IDisposable
0
Si su sistema falla y queda inutilizable, entonces puede construir un nuevo sistema y restaurar la base de datos maestra sobre la existente para recuperar el certificado TDE siempre que use la misma cuenta de servicio en el nuevo sistema. Luego debe reiniciar el sistema para corregir el cifrado de la clave maestra de servicio mediante la clave de máquina local. Después de eso, debería poder hacer una copia de seguridad del certificado TDE o restaurar la base de datos del usuario y acceder a los datos. La clave maestra de servicio está protegida por la API de protección de datos del servidor de Windows de dos maneras, primero usando la clave de máquina local que es específica del sistema y segundo usando la cuenta de servicio del motor de la base de datos. Como ya no tendrá la clave de máquina local del sistema original debido a un bloqueo del sistema, debe usar la misma cuenta de servicio. El certificado TDE está respaldado con la base de datos, pero es inaccesible hasta que se complete la jerarquía de cifrado.
1.Si desea restaurar una copia de seguridad cifrada a otro servidor como de costumbre, se encuentra con el siguiente error
2.Encuentre el nombre del certificado: en este ejemplo, vestacert
3. respalde el certificado del servidor de origen (servidor cifrado de origen):
4.Cree un nuevo Master Cert en el servidor UAT si aún no existe
5.Restaurar certificados de copia de seguridad en el servidor UAT (servidor UAT)
6. Después de este paso, la restauración de la copia de seguridad no tiene ningún error y todos los datos fueron legibles.
7. Pero lo curioso es que eliminar el cifrado simplemente y tomar una nueva copia de seguridad y restaurarlo en el servidor final (Servidor final) no funciona y da el siguiente error El archivo "mydb_log" no se pudo inicializar correctamente. Examine los registros de errores para obtener más detalles.
8. La forma correcta de eliminar el cifrado de UAT es eliminar todos los signos como se muestra a continuación paso a paso y de abajo hacia arriba
9. Ahora cree una nueva copia de seguridad desde el servidor UAT y restaure al servidor final
buen artículo: http://sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/
fuente
Si su sistema falla y queda inutilizable, entonces puede construir un nuevo sistema y restaurar la base de datos maestra sobre la existente para recuperar el certificado TDE siempre que use la misma cuenta de servicio en el nuevo sistema. Luego debe reiniciar el sistema para corregir el cifrado de la clave maestra de servicio mediante la clave de máquina local. Después de eso, debería poder hacer una copia de seguridad del certificado TDE o restaurar la base de datos del usuario y acceder a los datos. La clave maestra de servicio está protegida por la API de protección de datos del servidor de Windows de dos maneras, primero usando la clave de máquina local que es específica del sistema y segundo usando la cuenta de servicio del motor de la base de datos. Como ya no tendrá la clave de máquina local del sistema original debido a un bloqueo del sistema, debe usar la misma cuenta de servicio. El certificado TDE está respaldado con la base de datos, pero es inaccesible hasta que se complete la jerarquía de cifrado.
fuente