Implementar cifrado de datos transparente

Completado

El Cifrado de datos transparente (TDE) ayuda a proteger Azure SQL Database, Azure SQL Managed Instance y Synapse SQL en Azure Synapse Analytics frente a la amenaza de actividades malintencionadas sin conexión, ya que cifra los datos en reposo. También realiza cifrado y descifrado de la base de datos en tiempo real, copias de seguridad asociadas y archivos de registro de transacciones en reposo sin necesidad de efectuar cambios en la aplicación. De forma predeterminada, TDE está habilitado para todas las bases de datos de Azure SQL recién implementadas y debe habilitarse manualmente para las bases de datos anteriores de Azure SQL Database, Azure SQL Managed Instance o Azure Synapse.

El TDE efectúa el cifrado y descifrado de E/S en tiempo real de los datos en el nivel de página. Todas las páginas se descifran cuando se leen en la memoria y después se cifran antes de escribirse en el disco. El TDE cifra el almacenamiento de una base de datos completa mediante una clave simétrica denominada Clave de cifrado de base de datos (DEK). Al iniciarse la base de datos, la DEK cifrada se descifra y luego se usa para descifrar y volver a cifrar los archivos de base de datos en el proceso del Motor de base de datos de SQL Server. DEK está protegida por el protector de TDE. El protector de TDE es un certificado administrado por el servicio (cifrado de datos transparentes administrado por el servicio) o una clave asimétrica almacenada en Azure Key Vault (cifrado de datos transparentes administrado por el cliente).

En el caso de Azure SQL Database y Azure Synapse, el protector de TDE se establece en el nivel de servidor SQL lógico y lo heredan todas las bases de datos asociadas a dicho servidor. En el caso de Azure SQL Managed Instance (la característica BYOK está en versión preliminar), el protector de TDE se establece en el nivel de instancia y lo heredan todas las bases de datos cifradas que se encuentran en esa instancia. El término servidor hace referencia tanto a servidor como a instancia a lo largo de este documento, a menos que se indique lo contrario.

Todas las bases de datos SQL recién creadas se cifran de forma predeterminada mediante el uso de cifrado de datos transparente administrado por el servicio. Cuando se cifra el origen de la base de datos, las bases de datos de destino creadas mediante restauración, replicación geográfica y copia de base de datos se cifran de manera predeterminada. Sin embargo, cuando no se cifra el origen de la base de datos, las bases de datos de destino creadas mediante restauración, replicación geográfica y copia de base de datos no se cifran de manera predeterminada. Las bases de datos de SQL creadas antes de mayo de 2017 y existentes en SQL Managed Instance, que se crearon antes de febrero de 2019, no se cifran de manera predeterminada. Las bases de datos de SQL Managed Instance que se crearon mediante restauración heredan el estado de cifrado del origen. Para restaurar una base de datos cifrada con TDE existente, primero se debe importar el certificado de TDE necesario en SQL Managed Instance. Para averiguar el estado de cifrado de una base de datos, ejecute una consulta select en la DMV de sys.dm_database_encryption_keys y compruebe el estado de la columna encryption_state_desc.

No se puede usar TDE para cifrar las bases de datos del sistema, como la base de datos master en Azure SQL Database y SQL Managed Instance. La base de datos maestra contiene objetos necesarios para realizar operaciones de TDE en bases de datos de usuario. Se recomienda que no almacene información confidencial en bases de datos del sistema. La excepción es tempdb, que siempre se cifra con TDE para proteger los datos almacenados allí.

Cifrado de datos transparente administrado por el servicio

En Azure, la configuración predeterminada de TDE es que la clave de cifrado está protegida mediante un certificado de servidor integrado. El certificado de servidor integrado es único para cada servidor y el algoritmo de cifrado que se usa es AES 256. Si una base de datos está en una relación de replicación geográfica, tanto la base de datos principal como la secundaria con replicación geográfica están protegidas por la clave de servidor principal de la base de datos principal. Si hay dos bases de datos conectadas al mismo servidor, también comparten el mismo certificado integrado. Microsoft rota automáticamente estos certificados en cumplimiento de la directiva de seguridad interna y se protege la clave raíz mediante un almacén secreto interno de Microsoft. Los clientes pueden verificar el cumplimiento de SQL Database con las directivas de seguridad internas en los informes de auditoría de terceros independientes disponibles en el Centro de confianza de Microsoft.

Microsoft también mueve y administra con total fluidez las claves según sea necesario para la replicación geográfica y las restauraciones.

Cifrado de datos transparente administrado por el cliente - Bring Your Own Key

La TDE administrada por el cliente también se conoce como compatibilidad de Bring Your Own Key (BYOK) con TDE. En este escenario, el protector de TDE que cifra la clave de cifrado es una clave asimétrica administrada por el cliente, que se almacena en una instancia de Azure Key Vault que es propiedad del cliente y que este administra (un sistema de administración de claves externas basado en la nube de Azure), y que nunca sale del almacén de claves. El protector de TDE lo puede generar el almacén de claves, o bien se puede transferir a él desde un dispositivo del módulo de seguridad de hardware (HSM) local. Para cifrar y descifrar la clave de cifrado es preciso que SQL Database tenga los permisos necesarios para el almacén de claves que posee el cliente. Si se revocan los permisos del servidor con SQL lógico para el almacén de claves, no se podrá acceder a las bases de datos y se cifrarán todos los datos

Gracias al TDE con integración de Azure Key Vault, los usuarios pueden controlar las tareas de administración de claves, entre las que se incluyen las rotaciones de claves, los permisos del almacén de claves y la copia de seguridad de claves, así como la opción de llevar a cabo auditorías o crear informes sobre todos los protectores de TDE mediante la funcionalidad de Azure Key Vault. Key Vault ofrece una administración centralizada de claves, aprovecha los módulos de seguridad de hardware estrechamente supervisados, y permite la separación de obligaciones entre la administración de las claves y de los datos, lo que ayuda a cumplir las directivas de seguridad.

Captura de pantalla del formulario de configuración del cifrado de datos transparente.

Traslado de una base de datos protegida por cifrado de datos transparente

No es necesario descifrar las bases de datos para las operaciones dentro de Azure. La configuración de TDE en la base de datos de origen o la base de datos principal se hereda de forma transparente en el destino. Entre las operaciones incluidas están las siguientes:

  • Restauración geográfica
  • Restauración a un momento específico de autoservicio
  • Restauración de una base de datos eliminada
  • Replicación geográfica activa
  • Creación de una copia de base de datos
  • Restauración del archivo de copia de seguridad en Azure SQL Managed Instance

En Azure SQL Managed Instance no se permite realizar copias de seguridad manuales de SOLO COPIA de una base de datos cifrada por TDE administrada por el servicio, ya que el certificado que se usa para el cifrado no es accesible. Use la característica de restauración a un momento dado para mover este tipo de base de datos a otra instancia de SQL Managed Instance o cambie a una clave administrada por el cliente.

Si exporta una base de datos protegida mediante TDE, el contenido exportado de la base de datos no se cifra. Este contenido exportado se almacena en archivos BACPAC no cifrados. Asegúrese de proteger adecuadamente los archivos BACPAC y de habilitar el TDE cuando haya finalizado la importación de la nueva base de datos.

Por ejemplo, si el archivo BACPAC se exporta desde una instancia de SQL Server, el contenido importado de la nueva base de datos no se cifra automáticamente. Del mismo modo, si el archivo BACPAC se importa a una instancia de SQL Server, la base de datos nueva tampoco se cifra automáticamente.

La única excepción es cuando se exporta una base de datos con una instancia de SQL Database como origen y destino. El TDE se habilita en la nueva base de datos, pero el propio archivo BACPAC sigue sin estar cifrado.

Administrar cifrado de datos transparente

Administre el TDE en Azure Portal.

Para configurar el TDE desde Azure Portal, es preciso estar conectado como propietario de Azure, colaborador o administrador de seguridad de SQL.

Habilite y deshabilite el TDE en el nivel de base de datos. En el caso de Azure SQL Managed Instance, use Transact-SQL (T-SQL) para activar y desactivar el TDE en las bases de datos. Para Azure SQL Database y Azure Synapse, puede administrar TDE para la base de datos en Azure Portal después de haber iniciado sesión con la cuenta de administrador o colaborador de Azure. Busque la configuración del TDE en la base de datos de usuario. De manera predeterminada, se usa la clave de cifrado de nivel de servidor. Se genera automáticamente un certificado de cifrado de datos transparente para el servidor que contiene la base de datos.

Captura de pantalla que muestra cómo habilitar y deshabilitar el cifrado de datos transparente en el nivel de base de datos.

Establezca la clave maestra de TDE, conocida como protector del TDE, en el nivel de instancia o de servidor. Para usar el cifrado de datos transparente con compatibilidad con Bring Your Own Key y proteger las bases de datos con una clave de Azure Key Vault, abra la configuración de TDE en el servidor o instancia administrada.

Captura de pantalla que muestra cómo usar el cifrado de datos transparente con compatibilidad con Bring Your Own Key.

También puede usar una clave administrada por el cliente para TDE en un nivel de base de datos para Azure SQL Database.