Conectividad reforzada

La conectividad protegida se basa en la seguridad administrada para agregar controles de entrada y salida en capas: entrada basada en contexto (CBI), puntos de conexión de VPC, controles de salida sin servidor y un firewall externo opcional. El acceso al espacio de trabajo sigue siendo a través de la Internet pública, protegido por CBI.

Esta arquitectura tiene:

• Entrada del área de trabajo basada en contexto: los usuarios inician sesión a través de Internet y las directivas de CBI restringen el acceso al área de trabajo por origen de red, identidad, mecanismo de autenticación y ámbito de acceso. Esto supone una renuncia en términos de simplicidad en comparación con las arquitecturas protegidas mediante VPN.
• Acceso a servicios en la nube privada: los puntos de conexión de VPC (AWS) o los puntos de conexión de servicio (Azure) mantienen el tráfico del servicio en la nube fuera de la red pública de Internet.
• Control del tráfico saliente de la computación sin servidor: Las directivas de red y los puntos de conexión privados de NCC controlan el tráfico saliente de la computación sin servidor.
• Inspección de salida opcional: implemente un firewall externo para inspeccionar y registrar la salida de proceso clásica.
• No se requiere VPN: acceso simplificado de usuario sin dependencia de red corporativa.

Use esta arquitectura cuando:

• La seguridad de los datos es la principal preocupación, no el control de acceso al área de trabajo.
• La complejidad de la VPN es una barrera para la productividad del usuario.
• Los controles de acceso basados en IP son suficientes para el cumplimiento.
• Su organización prefiere modelos de acceso que priorizan la nube.

Prerequisites

• Nivel Premium de Azure Databricks con un área de trabajo insertada en una VNet.

• Lista de intervalos IP para el control de acceso al área de trabajo.

Información general sobre la arquitectura

La arquitectura de conectividad protegida protege el tráfico de red y simplifica el acceso de los usuarios:

Componentes necesarios

Inbound

No hay Private Link de entrada. El acceso a Internet público está restringido por directivas de entrada basadas en contexto y, opcionalmente, listas de acceso IP. Siga el IAM estándar para la autenticación. Consulte Autenticación y control de acceso.

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 la entrada basada en contexto y de las listas de acceso IP del área de trabajo. Se aplica solo al uso compartido de Databricks a Open (destinatarios que no son de Azure Databricks).

Consulte Restricción del acceso de destinatarios de OpenSharing mediante listas de acceso IP (uso compartido de Databricks a Open).

Salida

La salida sin servidor se rige por directivas de red y puntos de conexión privados de NCC. Utilice Unity Catalog para la gobernanza de datos del acceso saliente a los datos. Consulte ¿Qué es Unity Catalog?

Control de salida sin servidor

Configure políticas de red para controlar el tráfico saliente del cómputo sin servidor. Defina destinos permitidos mediante intervalos IP o FQDN.

Consulte ¿Qué es el control de salida sin servidor?.

Private Link sin servidor (puntos de conexión privados de NCC)

Proporciona conectividad privada desde la computación sin servidor a sus recursos mediante Private Link. El tráfico de datos sin servidor permanece fuera de la red pública de Internet.

Consulte Configurar la conectividad privada con recursos Azure.

Base informática clásica

La línea base de proceso clásica se hereda de la seguridad administrada. No se requieren componentes de línea base adicionales, pero opcionalmente puede agregar un firewall externo para inspeccionar la salida de proceso clásica.

La configuración base incluye inyección en la VNet, Conectividad segura del clúster (SCC) y Private Link clásico.

Private Link del plano de proceso clásico

Proporciona conectividad privada entre la red virtual y el plano de control de Azure Databricks. La API REST y el tráfico de retransmisión SCC entre clústeres y el plano de control permanecen privados en lugar de usar la red pública de Internet.

Consulte Configuración de la conectividad privada del plano de proceso clásico para Azure Databricks.

Rutas definidas por el usuario

Configure el enrutamiento para el acceso al servicio en la nube para mantener el tráfico privado y reducir los costos.

Configurar UDR con etiquetas de servicio para los servicios de Azure. Consulte Configuración de rutas definidas por el usuario para Azure Databricks.

Cortafuegos externo para la computación clásica (opcional)

Enrute la salida del proceso clásico a través de un firewall externo para la inspección, el registro y la aplicación de directivas. Requerido en el entorno aislado; opcional aquí.

Las opciones incluyen Azure Firewall o una aplicación virtual de red de terceros (NVA).

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. Consulte las direcciones IP y los dominios de los servicios y recursos de Azure Databricks para conocer los puntos de conexión necesarios.

Implementation

Comience desde una línea base de seguridad administrada implementada. En las fases siguientes se agregan los controles de entrada y salida que definen esta arquitectura.

Fase 1: Control de acceso entrante

Configuración de directivas de entrada basadas en contexto

Configurar políticas de acceso de entrada basadas en el contexto a nivel de cuenta (CBI) para restringir el acceso al espacio de trabajo en función del origen de la red, la identidad, el mecanismo de autenticación y el ámbito de acceso. Consulte Control de entrada basado en el contexto y Gestionar políticas de entrada basadas en el contexto.

Configuración de listas de acceso IP de nivel de área de trabajo (opcional)

Opcionalmente, configure listas de acceso IP en el nivel del área de trabajo junto con CBI por compatibilidad con versiones anteriores o para invalidaciones por área de trabajo. Cuando ambos están configurados, una solicitud debe ser autorizada por ambos. Consulte Configurar listas de acceso IP para áreas de trabajo.

Configuración de listas de acceso IP de nivel de cuenta

Configure las listas de acceso IP de nivel de cuenta para controlar el acceso a la consola de la cuenta. Consulte Configurar listas de acceso de IP para la consola de la cuenta.

Configurar listas de acceso IP de nivel de destinatario

Si usa OpenSharing Databricks-to-Open sharing, configure listas de acceso IP de nivel de destinatario en cada destinatario compartido. Consulte Restricción del acceso de destinatarios de OpenSharing mediante listas de acceso IP (uso compartido de Databricks a Open).

Documentar los rangos de IP configurados

Mantenga la documentación de todos los rangos IP configurados, incluida la justificación, los tickets vinculados y las fechas de revisión previstas.

Verificar el comportamiento de acceso

Compruebe el comportamiento del acceso mediante la prueba del inicio de sesión desde intervalos IP aprobados y confirme que las conexiones de intervalos IP no aprobados están bloqueadas.

Fase 2: Puntos de conexión de servicio en la nube

Configuración de rutas definidas por el usuario

Configure rutas definidas por el usuario (UDR) mediante etiquetas de servicio de Azure para que el tráfico hacia los servicios de Azure siga las rutas de salida privadas o controladas que desee. Consulte Configuración de rutas definidas por el usuario para Azure Databricks.

Configuración de puntos de conexión privados o de servicio para el almacenamiento

Configure puntos de conexión de servicio o puntos de conexión privados para cuentas de almacenamiento de Azure administradas por el cliente según sea necesario.

Fase 3: Controles de salida sin servidor

Configuración de directivas de red sin servidor

Configure directivas de red sin servidor para restringir el tráfico saliente del proceso sin servidor a destinos aprobados mediante intervalos IP o FQDN. Consulte ¿Qué es el control de salida sin servidor?.

Configuración de puntos de conexión privados de NCC

Configure los puntos de conexión privados de NCC para la conectividad privada desde recursos de proceso sin servidor hacia sus recursos de Azure. Consulte Configurar la conectividad privada con recursos Azure.

Prueba de salida sin servidor

Compruebe que las cargas de trabajo sin servidor pueden acceder a destinos aprobados y que se bloquea su acceso a los no aprobados.

Fase 4 (opcional): cortafuegos externo para el cómputo clásico

Implementación de un firewall externo

Implemente Azure Firewall o un dispositivo virtual de red (NVA) de terceros en una VNet de centro y empareje esta con la VNet del área de trabajo.

Dirige el tráfico de salida a través del firewall con UDR

Configure las UDR en las subredes del área de trabajo con una ruta predeterminada al firewall.

Configuración de reglas de firewall sin interceptación de TLS

Configure reglas de firewall para permitir los puntos de conexión necesarios de Azure Databricks sin interceptación TLS en el tráfico del plano de control y de retransmisión SCC.

El Azure Databricks Terraform SRA proporciona plantillas de infraestructura como código que automatizan esta implementación.

Validation

Después de implementar la arquitectura, ejecute las siguientes comprobaciones para confirmar que el tráfico del plano de proceso clásico permanece privado y que la lista de acceso IP restringe el acceso al área de trabajo según esté configurado.

Solución de problemas

Si se produce un error en una comprobación de validación o una carga de trabajo se comporta inesperadamente, use la tabla siguiente para diagnosticar problemas comunes.

Mantenimiento continuo

• Administración de listas de acceso IP: revise mensualmente, agregue nuevas ubicaciones, quite intervalos obsoletos.
• 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.
• Administración de repositorios de artefactos: mantenga réplicas privadas de paquetes y supervise la disponibilidad.
• Soporte al usuario: Mantener el proceso para problemas de acceso por IP.

Pasos anteriores y siguientes