Control de entrada basado en contexto

Esta página ofrece una visión general del control de entrada basado en el contexto, incluyendo sus conceptos centrales, modos de aplicación, auditoría y cómo interactúa con otros controles de red. Para configurar políticas, consulte Gestionar políticas de entrada basadas en contexto. Para el control de salida sin servidor, consulte ¿Qué es el control de salida sin servidor?.

Introducción al control de entrada basado en contexto

El control de entrada basado en el contexto funciona junto con las listas de acceso IP y la conectividad privada de front-end para permitir que los administradores de cuentas establezcan reglas de permiso y de denegación que combinen quién llama, desde dónde llama y a qué puede acceder en Azure Databricks. Esto garantiza que solo las combinaciones de confianza de identidad, origen de red y tipo de solicitud puedan llegar al entorno de trabajo. El control de entrada basado en contexto se configura en el nivel de cuenta. Una sola directiva puede controlar varias áreas de trabajo.

Con la entrada basada en contexto, puede hacer lo siguiente:

• Detenga el acceso desde redes que no son de confianza al requerir un segundo factor, un origen de red de confianza, además de las credenciales.
• Permitir el acceso de clientes SaaS sin direcciones IP de salida estables basándose en la identidad en lugar de en rangos de IP.
• Limite el acceso al permitir que los orígenes de menos confianza usen solo determinados ámbitos, como Azure Databricks API o la interfaz de usuario del área de trabajo.
• Protección de la automatización con privilegios: restrinja las entidades de servicio de alto valor solo a redes de elevada confianza.
• Audite de forma eficaz: capture registros detallados de las denegaciones en las tablas del sistema de Unity Catalog para supervisar las solicitudes bloqueadas.

Políticas a nivel de espacio de trabajo vs políticas a nivel de cuenta

El control de entrada basado en el contexto utiliza dos tipos de políticas. Las políticas a nivel de espacio de trabajo regulan el acceso a los espacios de trabajo. Las políticas a nivel de cuenta regulan el acceso a recursos a nivel de cuenta, como la consola de cuenta y el Genie One a nivel de cuenta.

Las políticas a nivel de cuenta están en Beta. Para empezar, habilite Ingreso basado en el contexto: Política de cuenta.

Conceptos básicos del control de entrada basado en contexto

Fuentes de red

Un origen de red define el origen de las solicitudes. Los tipos admitidos incluyen:

Directiva de acceso público:

• Todas las direcciones IP públicas: cualquier origen de Internet público.
• Direcciones IP seleccionadas: direcciones IPv4 específicas o intervalos CIDR.
• Plataformas asociadas (Beta): IPs que las aplicaciones de terceros (Power BI, Tableau Cloud y plataforma dbt) utilizan para conectarse a Azure Databricks. Azure Databricks administra y actualiza estas listas IP automáticamente.

Directiva de acceso privado:

• Todos los puntos de conexión privados registrados: cualquier punto de conexión privado registrado en la cuenta.
• Puntos de conexión privados seleccionados: puntos de conexión privados registrados específicos en la cuenta.

• Azure Workspace Private Link: solo en reglas de denegación de la directiva del espacio de trabajo. Deniega el acceso a todos los endpoints databricks_ui_api.
• Todo el acceso privado: Solo en las reglas de denegación de la directiva del espacio de trabajo. Deniega el acceso a todos los databricks_ui_api y puntos de conexión registrados.

Acceso entre espacios de trabajo (Beta): Controla qué espacios de trabajo de origen pueden acceder a este espacio de trabajo mediante tráfico sin servidor, usando las mismas identidades y reglas de permiso y denegación que las demás fuentes de red.

• Espacios de trabajo seleccionados: Solo los espacios de trabajo cuyos IDs mencionas.

También puedes dejar esta política en modo de compatibilidad, en cuyo caso no regula la entrada entre espacios de trabajo y se aplican los controles de red preexistentes del espacio de trabajo. Para configurar el acceso entre espacios de trabajo tanto en el lado de entrada como en el de salida, y para revisar sus limitaciones, véase Acceso entre espacios de trabajo.

Tipos de acceso

Las reglas se aplican a distintos ámbitos de solicitud entrantes. Cada ámbito representa una categoría de solicitudes entrantes que puede permitir o denegar:

Tipos de acceso a políticas a nivel de espacio de trabajo:

• Interfaz de usuario del área de trabajo: acceso del explorador al área de trabajo.
• API: acceso mediante programación a través de las API de Azure Databricks, incluidos los puntos de conexión SQL (JDBC/ODBC). Puede seleccionar cualquiera de las siguientes opciones:
  • Todas las APIs.
  • Un alcance específico de API, usando IN. Por ejemplo, puedes especificar aplicaciones, paneles de control o servicio de modelos.
  • Todos los ámbitos de API excepto los seleccionados, usando NOT IN.
• Tiempo de ejecución de aplicaciones: permite o deniega el acceso a las implementaciones de Aplicaciones de Databricks. Consulte Aplicaciones de Databricks. Solo se admite la opción de identidad Todos los usuarios y principales de servicio para este tipo de acceso.
• Tiempo de ejecución de Lakebase: conexiones a instancias de base de datos de Lakebase. Consulte Lakebase. Solo se admite la opción de identidad Todos los usuarios y principales de servicio para este tipo de acceso.

Tipos de acceso a políticas a nivel de cuenta (Beta):

• Interfaz de usuario de cuenta: acceso del explorador a los recursos de nivel de cuenta (por ejemplo, la consola de la cuenta y el nivel de cuenta Genie One).
• API de la cuenta: acceso mediante programación a través de las API de cuentas de Azure Databricks.

Identidades

Las reglas pueden tener como destino diferentes tipos de identidad. Para los tipos de acceso tiempo de ejecución de Apps y tiempo de ejecución de Lakebase, la única opción admitida es Todos los usuarios y principales de servicio.

En la política a nivel de cuenta, la única opción admitida es Todos los usuarios y principales de servicio.

• Todos los usuarios y entidades de servicio: usuarios humanos y automatización.
• Todos los usuarios: solo usuarios humanos.
• Todas las entidades de servicio: solo identidades de automatización.
• Identidades seleccionadas: usuarios específicos o entidades de servicio.

Evaluación de la regla de acceso

• Denegación predeterminada: en modo restringido, se deniega el acceso a menos que se permita explícitamente.
• Denegar antes de permitir: las reglas de denegación permiten definir excepciones a las reglas de permiso.
• Política predeterminada a nivel de espacio de trabajo: cada cuenta tiene una política de entrada predeterminada a nivel de espacio de trabajo que se aplica a todos los espacios de trabajo que cumplan los requisitos y a los que no se les haya asignado explícitamente una política.

Modos de cumplimiento

Las directivas de entrada basadas en contexto permiten dos modos:

• Aplicado a todos los productos: Azure Databricks aplica activamente las reglas y bloquea las solicitudes infractoras.
• Modo de prueba para todos los productos: Azure Databricks registra violaciones, pero no bloquea las solicitudes. Use este modo para evaluar el impacto de la directiva antes de aplicarlo.

Databricks recomienda empezar en modo de simulación para observar el impacto de la política antes de pasarla a modo de aplicación obligatoria.

Auditing

Las solicitudes denegadas o de ejecución seca se registran en la tabla del system.access.inbound_network sistema. Si no tiene acceso a las tablas del sistema, un administrador de metastore puede concederle permisos. Consulte Concesión de acceso a las tablas del sistema.

Cada entrada de registro incluye:

• Hora del evento
• ID del espacio de trabajo
• Etiqueta de regla (de la regla que denegó la solicitud)
• Tipo de solicitud
• identidad
• Origen de red
• Tipo de acceso (DENEGADO o DRY_RUN_DENIAL)

Las denegaciones de la política a nivel de cuenta se registran con workspace_id establecido en 0.

Consulte estos registros para comprobar que las reglas funcionan según lo previsto y detectar intentos de acceso inesperados.

Relación con otros controles

• Listas de acceso IP del área de trabajo: se evalúa junto con la directiva de entrada basada en contexto mediante un AND lógico, sin ninguna secuencia estricta entre los dos. Solo se permite una solicitud si la lista de acceso IP y la directiva de entrada lo permiten. Las listas de acceso IP del área de trabajo pueden restringir aún más el acceso, pero no pueden ampliarla.
• Control de salida en entornos sin servidor: complementa las políticas de entrada mediante el control del tráfico de red saliente desde entornos informáticos sin servidor. Consulte Administración de directivas de red.
• Acceso entre espacios de trabajo: Controla qué espacios de trabajo de origen pueden acceder a un espacio de trabajo mediante tráfico sin servidor, además de los controles de origen de red y de identidad de esta página. Consulta Acceso entre espacios de trabajo.
• Listas de acceso IP de destinatarios de OpenSharing: El ingreso basado en contexto no se aplica a las listas de acceso IP de destinatario de OpenSharing. Estos son un control separado para los destinatarios abiertos que los proveedores configuran por destinatario. Consulte Restringir el acceso de los destinatarios de OpenSharing mediante listas de acceso de IP (compartición de Databricks a Open).

• Conectividad privada de front-end: Para las directivas del espacio de trabajo y un punto de conexión registrado determinado, se permiten los puntos de conexión permitidos, ya sea en el tráfico de entrada basado en el contexto o en el databricks_ui_api punto de conexión privado. Sin embargo, si la política de entrada basada en el contexto del espacio de trabajo tiene una regla de denegación que deniega todos los databricks_ui_api endpoints, entonces ningún endpoint databricks_ui_api puede acceder a Azure Databricks. Consulte Configurar Private Link de entrada para área de trabajo.
• Permitir alternancia de acceso a red pública: cuando permitir el acceso a la red pública está habilitado, se evalúan las listas de acceso IP del área de trabajo. De lo contrario, se bloquea todo el tráfico de entrada público y no se evalúan las directivas de tráfico de entrada público del espacio de trabajo.

Gestionar políticas de entrada basadas en el contexto

Configura y adjunta políticas al nivel que coincida con el recurso que quieres proteger:

Para configurar reglas públicas y privadas en la política a nivel de cuenta que protege los recursos a nivel de cuenta, consulte Gestionar políticas de ingreso basadas en el contexto de la cuenta.

API y Terraform

Además de la consola de cuentas, puedes gestionar las políticas de entrada basadas en el contexto de forma programática:

• API REST: Utiliza la API REST de Azure Databricks para gestionar las políticas de red.
• Terraform: Utiliza el proveedor de Terraform de Azure Databricks para gestionar las políticas de ingreso como infraestructura como código.

procedimientos recomendados

• Empieza con el modo de prueba para observar los efectos sin interrumpir el acceso.
• Use reglas basadas en identidades siempre que sea posible para los clientes SaaS que rotan direcciones IP.
• Aplique primero reglas de denegación a entidades de servicio con privilegios para limitar el área afectada.
• Mantenga los nombres de directiva claros y coherentes.

Availability