Consideraciones de seguridad para el movimiento de datos en Azure Data Factory
SE APLICA A:
Azure Data Factory Azure Synapse Analytics
Sugerencia
Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.
En este artículo se describe la infraestructura de seguridad básica que utilizan los servicios de movimiento de datos en Azure Data Factory para ayudar a proteger los datos. Los recursos de administración de Data Factory están integrados en la infraestructura de seguridad de Azure y aplican todas las medidas de seguridad que ofrece Azure.
En una solución de Data Factory, se crean una o varias canalizacionesde datos. Una canalización es una agrupación lógica de actividades que realizan una tarea. Estas canalizaciones residen en la región donde se creó la factoría de datos.
Aunque Data Factory solo está disponible en algunas regiones, el servicio de movimiento de datos está disponible globalmente para garantizar el cumplimiento de datos, la eficiencia y menores costos de salida de la red.
Azure Data Factory, que incluye Azure Integration Runtime y el entorno de ejecución de integración autohospedado, no almacena ningún dato temporal, datos de caché ni registro, excepto las credenciales de servicio vinculadas de los almacenes de datos en la nube, que se cifran mediante certificados. Con Data Factory, puede crear flujos de trabajo controlados por datos para orquestar el movimiento de los datos entre los almacenes de datos admitidos y organizar el procesamiento de los datos mediante servicios de proceso en otras regiones o en entornos locales. También puede supervisar y administrar flujos de trabajo mediante SDK y Azure Monitor.
Data Factory tiene certificación para:
| Certificación CSA STAR |
|---|
| ISO 20000-1:2011 |
| ISO 22301:2012 |
| ISO 27001:2013 |
| ISO 27017:2015 |
| ISO 27018:2014 |
| ISO 9001:2015 |
| SOC 1, 2, 3 |
| HIPAA BAA |
| HITRUST |
Si está interesado en el cumplimiento de Azure y en cómo Azure protege su propia infraestructura, visite el Centro de confianza de Microsoft. Para consultar la lista más reciente con todas las ofertas de cumplimiento normativo de Azure, visite https://aka.ms/AzureCompliance.
En este artículo, revisamos las consideraciones de seguridad en los dos escenarios de movimiento de datos siguientes:
- Escenario de nube: en este escenario, el origen y el destino son públicamente accesibles a través de Internet. Por ejemplo, los servicios de almacenamiento administrado en la nube, como Azure Storage, Azure Synapse Analytics, Azure SQL Database, Azure Data Lake Store, Amazon S3, Amazon Redshift, los servicios SaaS como Salesforce y los protocolos web, como FTP y OData. Encuentre una lista completa de orígenes de datos admitidos en Almacenes de datos y formatos que se admiten.
- Escenario híbrido: en este escenario, el origen o el destino están detrás de un firewall o dentro de una red corporativa local. O bien el almacén de datos está en una red privada o en una red virtual (que suele ser el origen) y no se puede acceder a él públicamente. Los servidores de base de datos hospedados en máquinas virtuales también se incluyen en este escenario.
Nota:
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Consulte Instalación de Azure PowerShell para empezar. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.
Escenarios de nube
Protección de las credenciales del almacén de datos
- Almacenamiento de credenciales cifradas en un almacén administrado de Azure Data Factory. Data Factory ayuda a proteger las credenciales del almacén de datos cifrándolas con certificados administrados por Microsoft. Estos certificados se alternan cada dos años (esto incluye la renovación del certificado y la migración de las credenciales). Para más información sobre la seguridad de Azure Storage, consulte Introducción a la seguridad de Azure Storage.
- Almacenamiento de credenciales en Azure Key Vault También puede almacenar la credencial del almacén de datos en Azure Key Vault. Data Factory recupera la credencial durante la ejecución de una actividad. Para obtener más información, consulte el artículo Almacenamiento de credenciales en Azure Key Vault.
La centralización del almacenamiento de los secretos de aplicación le permite controlar su distribución. Key Vault reduce en gran medida las posibilidades de que se puedan filtrar por accidente los secretos. En lugar de almacenar la cadena de conexión en el código de la aplicación, puede almacenarla de forma segura en Key Vault. Las aplicaciones pueden acceder de manera protegida a la información que necesitan a través de URI. Estos URI permiten que las aplicaciones recuperen versiones específicas de un secreto. No es necesario escribir código personalizado para proteger la información de secretos almacenada en Key Vault.
Cifrado de datos en tránsito
Si el almacén de datos en la nube es compatible con HTTPS o TLS, todas las transferencias de datos entre los servicios de movimiento de datos de Data Factory y un almacén de datos en la nube se realizan a través del canal seguro HTTPS o TLS.
Nota
Todas las conexiones a Azure SQL Database y Azure Synapse Analytics requieren cifrado (SSL/TLS) que haya datos en tránsito hacia y desde la base de datos. Al crear una canalización con JSON, agregue la propiedad encryption y establézcala en true en la cadena de conexión. Para Azure Storage, puede usar HTTPS en la cadena de conexión.
Nota
Para habilitar el cifrado en tránsito al mover los datos desde Oracle, aplique alguna de las opciones siguientes:
- En el servidor de Oracle, vaya a Oracle Advanced Security (OAS) y realice la configuración de cifrado, que admite el cifrado Triple-DES (3DES) y el Estándar de cifrado avanzado (AES); consulte aquí los detalles. ADF negocia automáticamente el método de cifrado para usar el que configura en OAS al establecer la conexión con Oracle.
- En ADF, puede agregar EncryptionMethod=1 en la cadena de conexión (en el servicio vinculado). En este caso, se usará SSL/TLS como método de cifrado. Para usarlo, debe deshabilitar la configuración de cifrado no SSL en OAS en el lado servidor de Oracle para evitar conflictos de cifrado.
Nota
La versión de TLS usada es la 1.2.
Cifrado de datos en reposo
Algunos almacenes de datos admiten el cifrado de datos en reposo. Se recomienda habilitar el mecanismo de cifrado de datos para estos almacenes.
Azure Synapse Analytics
El Cifrado de datos transparente (TDE) de Azure Synapse Analytics ayuda a protegerse frente a la amenaza de actividad malintencionada al realizar el cifrado y descifrado en tiempo real de los datos en reposo. Este comportamiento es transparente para el cliente. Para obtener más información, consulte Protección de una base de datos en Azure Synapse Analytics.
Azure SQL Database
Azure SQL Database admite también el Cifrado de datos transparente (TDE), que ayuda a proteger frente a la amenaza de actividad malintencionada al realizar el cifrado y descifrado en tiempo real de los datos sin que haya que efectuar cambios en la aplicación. Este comportamiento es transparente para el cliente. Para más información, consulte Cifrado de datos transparente para SQL Database y Data Warehouse.
Azure Data Lake Store
Azure Data Lake Store también ofrece el cifrado de los datos que se almacenan en la cuenta. Cuando se habilita, Data Lake Store cifrará automáticamente los datos antes de la persistencia y los descifrará antes de la recuperación, por lo que resulta un proceso completamente transparente para el cliente que accede a los datos. Para más información, consulte Seguridad en Azure Data Lake Store.
Azure Blob Storage y Azure Table Storage
Azure Blob Storage y Azure Table Storage admiten el cifrado del servicio Storage (SSE), que cifra automáticamente los datos antes de su persistencia en el almacenamiento y los descifra antes de su recuperación. Para más información, consulte Cifrado del servicio Azure Storage para datos en reposo.
Amazon S3
Amazon S3 admite el cifrado de cliente y servidor para datos en reposo. Para más información, consulte Protección de datos del cliente mediante cifrado.
Amazon Redshift
Amazon Redshift admite cifrado de clúster para datos en reposo. Para más información, consulte Amazon Redshift Database Encryption (Cifrado de base de datos de Amazon Redshift).
Salesforce
Salesforce admite Shield Platform Encryption, que permite el cifrado de todos los archivos, datos adjuntos y campos personalizados. Para más información, consulte Understanding the Web Server OAuth Authentication Flow (Descripción del flujo de autenticación OAuth de servidor web).
Escenarios híbridos
Los escenarios híbridos necesitan que el entorno de ejecución de integración autohospedado se instale en una red local o en una virtual (Azure), o bien dentro de una nube privada virtual (Amazon). El entorno de ejecución de integración autohospedado debe poder tener acceso a los almacenes de datos locales. Para más información acerca del entorno de ejecución de integración autohospedado, consulte Creación y configuración de una instancia de Integration Runtime autohospedado.
El canal del comandos permite la comunicación entre los servicios de movimiento de datos de Data Factory y el entorno de ejecución de integración autohospedado. La comunicación contiene información relacionada con la actividad. El canal de datos se usa para transferir datos entre los almacenes de datos locales y los almacenes de datos en la nube.
Credenciales de los almacenes de datos locales
Las credenciales se pueden almacenar en Data Factory o Data Factory puede hacer referencia a ellas durante el tiempo de ejecución desde Azure Key Vault. Si almacena las credenciales en Data Factory, siempre se almacenan cifrada en entorno de ejecución de integración autohospedado.
Almacenar credenciales localmente. Si usa directamente el cmdlet Set-AzDataFactoryV2LinkedService con las cadenas de conexión y las credenciales insertadas en JSON, el servicio vinculado se cifra y almacena en el entorno de ejecución de integración autohospedado. En este caso, las credenciales atraviesan el servicio de back-end de Azure, que es muy seguro, hasta la máquina de integración autohospedada, donde finalmente se cifran y se almacenan. El entorno de ejecución de integración autohospedado utiliza Windows DPAPI para cifrar los datos confidenciales y la información de credenciales.
Almacenamiento de credenciales en Azure Key Vault También puede almacenar la credencial del almacén de datos en Azure Key Vault. Data Factory recupera la credencial durante la ejecución de una actividad. Para obtener más información, consulte el artículo Almacenamiento de credenciales en Azure Key Vault.
Almacene las credenciales localmente sin transferirlas mediante el back-end de Azure al entorno de ejecución de integración autohospedado. Si desea cifrar las credenciales y almacenarlas localmente en el entorno de ejecución de integración autohospedado sin hacer que fluyan en el back-end de Data Factory, siga los pasos descritos en Cifrado de credenciales de almacenes de datos locales en Azure Data Factory. Todos los conectores admiten esta opción. El entorno de ejecución de integración autohospedado utiliza Windows DPAPI para cifrar los datos confidenciales y la información de credenciales.
Use el cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential para cifrar las credenciales del servicio vinculado e información confidencial en el servicio vinculado. Después, puede usar el código JSON devuelto (con el elemento EncryptedCredential en la cadena de conexión) para crear un servicio vinculado mediante el cmdlet Set-AzDataFactoryV2LinkedService.
Puertos utilizados durante el cifrado del servicio vinculado en Integration Runtime autohospedado
De manera predeterminada, cuando el acceso remoto desde la intranet está habilitado, PowerShell usa el puerto 8060 en la máquina con el entorno de ejecución de integración autohospedado para una comunicación segura. Si es necesario, este puerto se puede cambiar desde el administrador de configuración de Integration Runtime en la pestaña Configuración:
Cifrado en tránsito
Todas las transferencias de datos se realizan a través del canal seguro HTTPS y TLS sobre TCP para evitar ataques tipo "Man in the middle" durante la comunicación con los servicios de Azure.
También puede usar una conexión VPN de IPSec o Azure ExpressRoute para proteger aún más el canal de comunicación entre la red local y Azure.
Azure Virtual Network es una representación lógica de la red en la nube. Puede conectar una red local a la red virtual mediante la configuración de una conexión VPN de IPSec (de sitio a sitio) o ExpressRoute (Emparejamiento privado)
En la tabla siguiente, se resumen las recomendaciones de configuración de red y del entorno de ejecución de integración autohospedado en función de diferentes combinaciones de ubicaciones de origen y de destino para el movimiento de datos híbridos.
| Source | Destination | Configuración de la red | Configuración de Integration Runtime |
|---|---|---|---|
| Local | Máquinas virtuales y servicios en la nube implementados en redes virtuales | VPN de IPSec (de punto a sitio o de sitio a sitio) | El entorno de ejecución de integración autohospedado se debe instalar en una máquina virtual de Azure en una red virtual. |
| Local | Máquinas virtuales y servicios en la nube implementados en redes virtuales | ExpressRoute (Emparejamiento privado) | El entorno de ejecución de integración autohospedado se debe instalar en una máquina virtual de Azure en una red virtual. |
| Local | Servicios basados en Azure que tienen un punto de conexión público | ExpressRoute (emparejamiento de Microsoft) | El entorno de ejecución de integración autohospedado se puede instalar de forma local o en una máquina virtual de Azure. |
Las siguientes imágenes muestran el uso del entorno de ejecución de integración autohospedado para mover datos entre una base de datos local y servicios de Azure mediante ExpressRoute e IPSec VPN (con Azure Virtual Network):
ExpressRoute
VPN de IPSec
Configuraciones de firewall y configuración de direcciones IP permitidas
Nota
Puede que tenga que administrar puertos o configurar la lista de admitidos en los dominios a nivel del firewall corporativo, en función de lo que requiera cada origen de datos. En esta tabla, Azure SQL Database, Azure Synapse Analytics y Azure Data Lake Store solo se usan a modo de ejemplo.
Nota
Para obtener detalles sobre las estrategias de acceso a datos a través de Azure Data Factory, consulte este artículo.
Requisitos de firewall para redes locales o privadas
En una empresa, se ejecuta un firewall corporativo en el enrutador central de la organización. El Firewall de Windows se ejecuta como demonio en la máquina local con Integration Runtime autohospedado instalado.
En la tabla siguiente se proporcionan el puerto de salida y los requisitos de dominio para el firewall corporativo:
| Nombres de dominio | Puertos de salida | Descripción |
|---|---|---|
*.servicebus.windows.net |
443 | Lo necesita el entorno de ejecución de integración autohospedado para la creación interactiva. |
{datafactory}.{region}.datafactory.azure.neto bien *.frontend.clouddatahub.net |
443 | El entorno de ejecución de integración autohospedado lo necesita para conectarse al servicio Data Factory. En el caso de los nuevos Data Factory creados, busque el nombre de dominio completo de la clave del entorno de ejecución de integración autohospedado que se encuentra en el formato {datafactory}.{region}.datafactory.azure.net. En el caso de Data Factory anterior, si no ve el FQDN en la clave del entorno de ejecución de integración autohospedado, use *.frontend.clouddatahub.net en su lugar. |
download.microsoft.com |
443 | Lo necesita el entorno de ejecución de integración autohospedado para descargar las actualizaciones. Si ha deshabilitado la actualización automática, puede omitir la configuración de este dominio. |
*.core.windows.net |
443 | Lo usa el entorno de ejecución de integración autohospedado para conectarse a la cuenta de Azure Storage cuando se utiliza la característica Copia almacenada provisionalmente. |
*.database.windows.net |
1433 | Solo es obligatorio cuando se copia desde o en Azure SQL Database o Azure Synapse Analytics. En caso contrario, es opcional. Use la característica de copia almacenada provisionalmente para copiar datos en SQL Database o Azure Synapse Analytics sin abrir el puerto 1433. |
*.azuredatalakestore.netlogin.microsoftonline.com/<tenant>/oauth2/token |
443 | Solo es necesario cuando se copia desde o en Azure Data Lake Store, sino es opcional. |
Nota
Puede que tenga que administrar puertos o configurar la lista de admitidos en los dominios a nivel del firewall corporativo, en función de lo que requiera cada origen de datos. En esta tabla, Azure SQL Database, Azure Synapse Analytics y Azure Data Lake Store solo se usan a modo de ejemplo.
En la tabla siguiente, se proporcionan los requisitos del puerto de entrada para el Firewall de Windows.
| Puertos de entrada | Descripción |
|---|---|
| 8060 (TCP) | Requerido por el cmdlet de cifrado de PowerShell como se describe en el Cifrado de credenciales de almacenes de datos locales en Azure Data Factory o en la aplicación de administrador de credenciales para establecer de forma segura credenciales para almacenes de datos locales en el entorno de ejecución de integración. |
Configuraciones de IP y configuración de lista de permitidos en almacenes de datos
Algunos almacenes de datos de la nube también requieren que permita la dirección IP de la máquina que accede a ellos. Asegúrese de que la dirección IP de la máquina con el entorno de ejecución de integración autohospedado tiene permiso en o está configurada en el firewall correctamente.
Los siguientes almacenes de datos en la nube requieren que permita la dirección IP de la máquina el entorno de ejecución de integración autohospedado. De forma predeterminada, es posible que algunos de estos almacenes de datos no necesiten lista de admitidas.
Preguntas más frecuentes
¿El entorno de ejecución de integración autohospedado puede compartirse entre diferentes factorías de datos?
Sí. Más detalles aquí.
¿Cuáles son los requisitos de puerto para que el entorno de ejecución de integración autohospedado funcione?
Integration Runtime autohospedado establece conexiones basadas en HTTP para acceder a Internet. El puerto de salida 443 debe estar abierto para que el entorno de ejecución de integración autohospedado establezca la conexión. Abra el puerto de entrada 8060 solo en la máquina (no en el firewall corporativo) para la aplicación de administración de credenciales. Si se utiliza Azure SQL Database o Azure Synapse Analytics como origen o destino, tendrá que abrir también el puerto 1433. Para más información, consulte la sección Configuraciones de firewall y configuración de la lista de permitidos para direcciones IP.
Contenido relacionado
Para información sobre el rendimiento de la actividad de copia de Azure Data Factory, consulte la Guía de optimización y rendimiento de la actividad de copia.