Entorno aislado

La arquitectura del entorno aislado hereda la línea de base de conectividad protegida y agrega dos requisitos: acceso al área de trabajo privada y un firewall externo necesario. El acceso al espacio de trabajo está restringido por VPN o por vínculo privado de entrada, nunca a través de Internet pública. Todas las salidas de proceso clásicas fluyen a través del firewall para la inspección y el cumplimiento de directivas.

Esta arquitectura tiene:

• Aislamiento de red completo: todo el tráfico fluye a través de conexiones privadas.
• Acceso al espacio de trabajo privado: solo mediante VPN o Private Link de entrada. El área de trabajo no es accesible desde la red pública de Internet.
• Inspección obligatoria del tráfico de salida: inspección del firewall de todo el tráfico de salida del proceso clásico.
• Prevención de filtración de datos: los controles de capa de red bloquean la transferencia de datos no autorizada.

Use esta arquitectura cuando:

• El acceso al espacio de trabajo debe ser privado, por ejemplo, a través de una VPN o de Private Link de entrada.
• Control de datos en sectores altamente regulados, por ejemplo, servicios financieros, atención sanitaria, gobierno.
• Los marcos de cumplimiento requieren controles de salida (por ejemplo, SOC 2, HIPAA, PCI DSS y FedRAMP).
• Implementación de marcos de seguridad de confianza cero empresarial.
• La prevención de filtración de datos es un requisito.

Prerequisites

• Nivel Premium de Azure Databricks de Azure con un área de trabajo insertada en la red virtual.

• Infraestructura de VPN existente o conectividad entrante mediante Private Link.
• Firewall o aplicación virtual de red (NVA).

Información general sobre la arquitectura

La arquitectura del entorno aislado enruta todo el tráfico a través de conexiones privadas con la inspección del firewall:

Componentes necesarios

Inbound

El área de trabajo solo es accesible a través de conexiones privadas: VPN, Private Link entrantes o ambas en función de la infraestructura existente. Los clientes suelen seleccionar uno en lugar de apilarlos.

Configuración de acceso privado (deshabilitar el acceso público)

Este es el control de acceso que realmente bloquea la entrada pública. Sin él, el área de trabajo sigue aceptando tráfico de Internet incluso con Private Link configurado. Private Link se convierte en una ruta de acceso adicional, no la única ruta de acceso.

Configure Acceso a redes públicas del área de trabajo como Deshabilitado en el portal de Azure. Esto bloquea la entrada pública a la interfaz de usuario y las API del área de trabajo.

Controles de entrada del área de trabajo

Configure el ingreso al espacio de trabajo mediante la entrada basada en contexto (CBI), el marco recomendado de políticas de ingreso. Las reglas de CBI combinan el origen de red (intervalos IP), la identidad, el mecanismo de autenticación y el ámbito de acceso en un único modelo de permiso o denegación, por lo que el atributo de origen de red realiza el mismo trabajo que la característica de lista de acceso IP independiente, además de más.

Las listas de acceso IP siguen siendo compatibles y se pueden configurar junto con CBI. Cuando ambos están configurados, ambos controles deben permitir una solicitud.

Niveles de configuración:

• Políticas de CBI a nivel de cuenta: se aplican a todos los espacios de trabajo de la cuenta. Consulte Administración de directivas de entrada basadas en contexto.
• Listas de acceso IP a nivel de espacio de trabajo: Se aplican a un solo espacio de trabajo. Consulte Configurar listas de acceso IP para áreas de trabajo.
• Listas de acceso IP a nivel de cuenta: se aplican a la consola de la cuenta. Consulte Configurar listas de acceso de IP para la consola de la cuenta.

Procedimiento recomendado:

• Empiece de forma general y refine en función del uso real.
• Documente intervalos IP con fechas de propósito y expiración.
• Mantenga el acceso de administrador a través de un intervalo IP correcto conocido.
• Revise trimestralmente y quite intervalos obsoletos.

Advertencia

Las directivas de entrada y las listas de acceso IP pueden bloquear el área de trabajo si están mal configuradas. Mantenga siempre el acceso administrativo mediante un rango de direcciones IP de confianza.

Control de acceso de los destinatarios de OpenSharing

OpenSharing usa sus propias listas de acceso IP configuradas en objetos de destinatario. Esto es independiente de las listas de acceso IP del espacio de trabajo y no está contemplado en el control de acceso de entrada basado en el contexto. Se aplica únicamente al intercambio de datos de Databricks a Open (destinatarios que no utilicen Azure Databricks).

Consulte Restringir el acceso de destinatarios de OpenSharing mediante listas de acceso IP (uso compartido de Databricks a Open).

Conectividad entrante

Establece conectividad privada para el acceso de los usuarios a la interfaz de usuario del espacio de trabajo y a la API. Los usuarios acceden al espacio de trabajo a través de la VPN o de una conexión Private Link de entrada, nunca a través de la Internet pública.

Consulte Configuración de Inbound Private Link.

DNS personalizado

Configurar el DNS privado para resolver los puntos de conexión de Azure Databricks a direcciones IP privadas.

Azure crea automáticamente zonas DNS privadas al crear puntos de conexión privados.

Salida

Los controles de salida sin servidor (directivas de red y puntos de conexión privados de NCC) se heredan de la configuración de referencia de conectividad reforzada. Esta arquitectura hace que el firewall externo, opcional en Hardened, sea necesario para la inspección de salida de proceso clásica completa.

Firewall externo (obligatorio)

Enrute todo el tráfico de salida a través de un firewall para la inspección, el registro y la aplicación de directivas. Entre las opciones se incluyen:

• Azure Firewall o aplicaciones virtuales de red de terceros (NVA).

Tip

Utilice directivas de punto de conexión de servicio para el almacenamiento de artefactos de Azure Databricks para omitir el firewall, lo que reduce los costes de transferencia de datos. El almacenamiento de artefactos por sí solo puede suponer hasta 11 GB descargados por cada nodo del clúster.

Consulte Direcciones IP y dominios de servicios y recursos de Azure Databricks para conocer los puntos de conexión necesarios de Azure Databricks que deben permitir las reglas del firewall.

Tip

Para el bloqueo máximo, considere la posibilidad de hospedar un repositorio de paquetes privados (como JFrog Artifactory o Sonatype Nexus) para paquetes Python, R y Maven. Esto elimina la necesidad de reglas de firewall que permitan el acceso a índices de paquetes públicos como PyPI.

Advertencia

El plano de control de Azure Databricks y las conexiones de retransmisión de SCC usan TLS con fijación de certificados. No active la inspección TLS (descifrar y volver a cifrar) en el tráfico entre sus clústeres y el plano de control de Azure Databricks. Si lo hace, se producen errores en el clúster. Configure reglas de firewall para permitir estas conexiones por FQDN de destino o IP sin interceptación de TLS. Consulte las direcciones IP y los dominios de los servicios y recursos de Azure Databricks para conocer los puntos de conexión necesarios.

Important

Las reglas de firewall configuradas incorrectamente pueden interrumpir las funcionalidades de Azure Databricks. Pruebe exhaustivamente en un entorno que no sea de producción.

Protección contra la filtración de datos

Configure directivas de red y controles de firewall para evitar la filtración de datos no autorizadas:

• Control de salida sin servidor a través de directivas de red.
• Salida de proceso clásica mediante firewall o NVA.
• Reglas de punto de conexión privado para destinos de datos aprobados.

Consulte Protección de filtración de datos para obtener instrucciones de implementación.

Base informática clásica

La línea base de proceso clásica se hereda de la seguridad administrada y los puntos de conexión de servicio en la nube se heredan de la conectividad protegida. No se requieren componentes de proceso clásicos adicionales para esta arquitectura.

La configuración base incluye inyección en la VNet, Conectividad segura del clúster (SCC) y Private Link clásico. Los puntos de conexión de servicio en la nube incluyen rutas definidas por el usuario (UDR), puntos de conexión de servicio y puntos de conexión privados para cuentas de almacenamiento administradas por el cliente.

Enfoques de salida para el acceso a datos

Hay dos enfoques para gestionar el acceso saliente a datos desde recursos de computación:

• Puerta de enlace NAT con firewall: implemente una puerta de enlace NAT para la conectividad saliente y enrute el tráfico a través de un firewall para su inspección. Este enfoque permite el acceso controlado a repositorios y API de paquetes externos y mantiene la visibilidad de los patrones de tráfico. Use este enfoque cuando deba acceder a recursos externos, pero requiera inspección y registro.

• Sin puerta de enlace NAT (totalmente privada): Quite por completo la puerta de enlace NAT para eliminar cualquier comunicación pública desde los recursos de computación. Todo el acceso a los datos se produce solo a través de puntos de conexión privados y puntos de conexión de VPC. Este enfoque tiene el mayor nivel de seguridad mediante la eliminación de la posibilidad de filtración de datos a través de rutas de acceso de salida públicas. Utilice este enfoque cuando su organización prohíba cualquier comunicación a través de la Internet pública desde los recursos informáticos.

Implementation

Comience desde una línea base de conectividad protegida implementada. Las fases siguientes agregan el acceso al área de trabajo privada y el firewall externo necesario que definen esta arquitectura.

Fase 1: Controles de entrada

1. Configure el vínculo privado de entrada para que el acceso de los usuarios a la interfaz de usuario y las API de Azure Databricks de Azure se dirija de manera privada en lugar de hacerlo a través de direcciones IP públicas. Consulte Configuración de Inbound Private Link.
2. Configure Acceso a redes públicas del área de trabajo como Deshabilitado en el portal de Azure. Esto es lo que realmente bloquea la entrada pública. Sin él, el área de trabajo sigue aceptando tráfico de Internet incluso con Private Link entrante configurado.
3. Pruebe el acceso de los usuarios a través de VPN o Private Link para confirmar que los usuarios autenticados pueden acceder al área de trabajo solo a través de la ruta de acceso de red privada y que el acceso público está bloqueado.

Fase 2: Firewall externo (obligatorio)

1. Implemente Azure Firewall o una aplicación virtual de red de terceros (NVA) en una red virtual de concentrador y conecte la red virtual del área de trabajo mediante el emparejamiento de VNet o un centro virtual.
2. Configure rutas definidas por el usuario (UDR) en las subredes del espacio de trabajo con una ruta predeterminada al firewall para que el tráfico saliente de los recursos de proceso de Azure Databricks pase a través del firewall de la red central. Consulte Configuración de rutas definidas por el usuario para Azure Databricks.
3. Configure las reglas de aplicación y de red de Azure Firewall para permitir solo los puntos de conexión necesarios de Azure Databricks (consulte Direcciones IP y dominios de los servicios y recursos de Azure Databricks) sin inspección de TLS en el plano de control ni en el tráfico de retransmisión de SCC.

Fase 3: Validación

1. Compruebe el control de salida revisando los registros y diagnósticos de Azure Firewall para comprobar que el tráfico de Azure Databricks se inspecciona y se limita según la directiva.
2. Confirme que no se asigna ninguna dirección IP pública a nodos de clúster u otros recursos de proceso administrados Azure Databricks en la red virtual del área de trabajo.
3. Compruebe que todo el tráfico de control, de datos y entrante fluye a través de los puntos de conexión de Private Link configurados y del firewall del concentrador, según lo previsto.

El Azure Databricks Terraform SRA proporciona plantillas de infraestructura como código como punto de partida para este patrón de implementación.

Validation

Después de implementar la arquitectura, ejecute las siguientes comprobaciones para confirmar que el aislamiento de red completo, la conectividad privada y los controles de salida funcionan según lo configurado.

Troubleshooting

Si se produce un error en una comprobación de validación o una carga de trabajo no se puede conectar a un punto de conexión necesario, use la tabla específica de la nube que sigue para diagnosticar problemas comunes.

Mantenimiento continuo

• Reglas de firewall: revise y actualice las listas de permitidos de salida con regularidad.
• Administración de DNS: actualice los registros al agregar áreas de trabajo.
• Supervisión de puntos de conexión: realice un seguimiento de los costos de mantenimiento y transferencia de datos del punto de conexión privado.
• Directivas de red: agregue puntos de conexión privados para los nuevos orígenes de datos aprobados.
• Quitar firewall: si la sobrecarga operativa del firewall es demasiado alta o los requisitos de cumplimiento se relajan, puede quitar el componente de firewall y mantener la conectividad privada y el acceso VPN.
• Degradación a conectividad protegida: si el acceso al área de trabajo privada se convierte en una barrera de productividad.

Pasos siguientes