Implementar el cifrado en Azure Synapse Analytics

  • 3 minutos

En esta sección, analizaremos Cifrado de datos transparente y TokenLibrary para Apache Spark.

¿Qué es el cifrado de datos transparente?

El cifrado de datos transparente (TDE) es un mecanismo de cifrado que ayuda a proteger Azure Synapse Analytics. Este protegerá Azure Synapse Analytics contra las amenazas de actividad malintencionada sin conexión mediante el cifrado de datos en reposo. TDE realiza el 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. Para usar TDE en Azure Synapse Analytics, tendrá que habilitarlo manualmente.

TDE realiza el cifrado y descifrado de los datos en el nivel de página y en tiempo real. Cuando se lee una página en la memoria, se descifra. Se cifra antes de escribirla en el disco. 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 iniciar una base de datos, se descifra la clave de cifrado de base de datos cifrada. La DEK se utilizará después para descifrar y volver a cifrar los archivos de base de datos en el motor de base de datos de SQL Server. La DEK está protegida por el protector de Cifrado de datos transparente. Este protector puede ser un certificado administrado por el servicio, al que se hace referencia como cifrado de datos transparente administrado por el servicio, o una clave asimétrica que se almacena en Azure Key Vault (cifrado de datos transparente administrado por el cliente).

Lo que es importante entender es que, en Azure Synapse Analytics, este protector de TDE se establece en el nivel de servidor. Allí todas las bases de datos asociadas o alineadas con ese servidor heredan dicho protector. El término "servidor" hace referencia tanto al servidor como a la instancia.

Cifrado de datos transparente administrado por el servicio

Como se indicó anteriormente, la cadena DEK que está protegida por el protector de cifrado transparente puede constar de certificados administrados por el servicio al que llamamos "TDE administrado por el servicio". Si nos fijamos en Azure, esa configuración predeterminada significa que la DEK está protegida por un certificado integrado único para cada servidor con un algoritmo de cifrado AES 256. Cuando 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 AES 256 integrado. En Microsoft rotamos automáticamente los certificados de acuerdo con la directiva de seguridad interna. La clave raíz está protegida por un almacén de secretos interno 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 con Bring Your Own Key para el cifrado de datos transparente administrado por el cliente

Como se indicó anteriormente, la DEK protegida por el protector de Cifrado de datos transparente también puede administrarse por el cliente mediante la incorporación de una clave asimétrica que se almacena en Azure Key Vault (cifrado de datos transparente administrado por el cliente). Esto también se conoce como "compatibilidad con Bring Your Own Key (BYOK) para TDE". Cuando este es el escenario que le corresponde, el protector TDE que cifra la DEK es una clave asimétrica administrada por el cliente. Se almacena en su propia instancia de Azure Key Vault administrada. Azure Key Vault es el sistema de administración de claves externas basado en la nube de Azure. Esta clave administrada nunca abandona el almacén de claves. El protector de TDE se puede generar mediante el almacén de claves. Otra opción consiste en transferir el protector de TDE al almacén de claves desde, por ejemplo, un dispositivo del módulo de seguridad de hardware (HSM) local. Azure Synapse Analytics debe tener permisos para el almacén de claves propiedad del cliente para descifrar y cifrar el DEK. Si se revocan los permisos del servidor para el almacén de claves, no se podrá acceder a las bases de datos y se cifrarán todos los datos.

Al usar la integración de Azure Key Vault para TDE, tiene el control sobre las tareas de administración de claves, como las rotaciones, las copias de seguridad y los permisos de las claves. También permite realizar auditorías e informes de todos los protectores de TDE cuando se usa la funcionalidad de Azure Key Vault. La razón para usar Key Vault es que proporciona un sistema de administración central de claves donde se aprovechan los HSM con supervisión estricta. También permite separar las tareas de administración de claves y datos para cumplir con las directivas de seguridad.

Administre el cifrado de datos transparente en Azure Portal.

Para Azure Synapse Analytics, 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. La configuración de TDE se puede encontrar en la base de datos de usuario.

Grupo de SQL de Cifrado de datos transparente en Azure Synapse Analytics

De forma predeterminada, se usa TDE administrado por el servicio y, por tanto, se genera automáticamente un certificado TDE para el servidor que contiene esa base de datos.

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

En algunos casos de uso, debe trasladar una base de datos protegida con TDE. En Azure, no es necesario descifrar las bases de datos. La configuración de TDE de la base de datos de origen o la base de datos principal se heredará en el destino. Estas son algunas de las operaciones de Azure que hereda TDE:

  • Geo-restore
  • 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 de archivo de copia de seguridad a la Instancia administrada de Azure SQL Database

Si exporta una base de datos protegida por TDE, el contenido exportado no se cifra. Esto se almacenará en un archivo BACPAC no cifrado. Debe asegurarse de proteger este archivo BACPAC y de habilitar TDE en cuanto se complete la importación del archivo BACPAC en la nueva base de datos.

Protección de las credenciales mediante servicios vinculados con TokenLibrary para Apache Spark

Se trata de un patrón bastante común para acceder a los datos de orígenes externos. Salvo que el origen de datos externo permita el acceso anónimo, lo más probable es que tenga que proteger la conexión con una credencial, un secreto o una cadena de conexión.

En Azure Synapse Analytics, el proceso de integración se simplifica proporcionando servicios vinculados. De este modo, los detalles de la conexión se pueden almacenar en el servicio vinculado o en una instancia de Azure Key Vault. Si el servicio vinculado se ha creado, Apache Spark puede hacer referencia a este para aplicar la información de conexión en el código. Cuando quiera acceder a los archivos desde Azure Data Lake Storage Gen2 en el área de trabajo de Azure Synapse Analytics, usará el método de paso a través de AAD para realizar la autenticación. Por lo tanto, no es necesario usar TokenLibrary. Sin embargo, para conectarse a otros servicios vinculados, puede realizar una llamada directa a TokenLibrary.

A continuación, se muestra un ejemplo: para conectarse a otros servicios vinculados, se puede hacer una llamada directa a TokenLibrary recuperando la cadena de conexión. Para recuperar la cadena de conexión, use la función getConnectionString y pase el nombre del servicio vinculado.

// Scala
// retrieve connectionstring from TokenLibrary

import com.microsoft.azure.synapse.tokenlibrary.TokenLibrary

val connectionString: String = TokenLibrary.getConnectionString("<LINKED SERVICE NAME>")
println(connectionString)

# Python
# retrieve connectionstring from TokenLibrary

from pyspark.sql import SparkSession

sc = SparkSession.builder.getOrCreate()
token_library = sc._jvm.com.microsoft.azure.synapse.tokenlibrary.TokenLibrary
connection_string = token_library.getConnectionString("<LINKED SERVICE NAME>")
print(connection_string)

Si quiere obtener la cadena de conexión como asignación y analizar valores específicos de una clave en la cadena de conexión, puede encontrar un ejemplo a continuación:

Para analizar determinados valores de un par clave=valor de la cadena de conexión, como

DefaultEndpointsProtocol=https;NombreDeCuenta=<NombreDeCuenta>;ClaveDeCuenta=<ClaveDeCuenta>

use la función getConnectionStringAsMap y pase la clave para devolver el valor.

// Linked services can be used for storing and retreiving credentials (e.g, account key)
// Example connection string (for storage): "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
import com.microsoft.azure.synapse.tokenlibrary.TokenLibrary

val accountKey: String = TokenLibrary.getConnectionStringAsMap("<LINKED SERVICE NAME">).get("<KEY NAME>")
println(accountKey)

# Linked services can be used for storing and retreiving credentials (e.g, account key)
# Example connection string (for storage): "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
from pyspark.sql import SparkSession

sc = SparkSession.builder.getOrCreate()
token_library = sc._jvm.com.microsoft.azure.synapse.tokenlibrary.TokenLibrary
accountKey = token_library.getConnectionStringAsMap("<LINKED SERVICE NAME>").get("<KEY NAME>")
print(accountKey)