Control de entrada basado en contexto

En esta página se proporciona información general sobre el control de entrada basado en contexto. Para el control de salida sin servidor, consulte ¿Qué es el control de salida sin servidor?.

Para configurar directivas de entrada, consulte Administración de directivas de entrada basadas en contexto.

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.

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.

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 tener como destino todas las API o un ámbito de API específico, como aplicaciones, paneles o servicios de modelos.
• 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 Instancias de 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:

• 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.

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)

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.

• 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. Consulta Configurar Inbound Private Link para espacios 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.

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.