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 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 denegación que combinen quién llama, desde dónde están llamando y lo que pueden llegar 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, lo que garantiza una aplicación coherente en toda la organización.

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 a clientes SaaS sin direcciones IP de salida estables basándose en la identidad en lugar de intervalos IP.
• Limite el acceso al permitir que los orígenes de menos confianza usen solo determinados ámbitos, como las API de Databricks 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.
• Auditar eficazmente: Capturar registros de denegación detallados en las tablas del sistema de Unity Catalog para monitorear 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:

• Todas las direcciones IP públicas: cualquier origen de Internet público.
• Direcciones IP seleccionadas: direcciones IPv4 específicas o intervalos CIDR.

Tipos de acceso

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

• 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 Databricks, incluidos los puntos de conexión de SQL (JDBC/ODBC).
• 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.

• Lakebase Compute: 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.

Identidades

Las reglas pueden tener como destino diferentes tipos de identidad. En el caso de los tipos de acceso de Apps y Lakebase Compute, la única opción admitida es Todos los usuarios y entidades 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 elegidas por el administrador.

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: si existen ambos tipos de reglas, las reglas de denegación tienen prioridad.
• Directiva predeterminada: cada cuenta tiene una directiva de entrada predeterminada aplicada a todas las áreas de trabajo aptas sin una asignación de directiva explícita.

Modos de cumplimiento

Las directivas de entrada basadas en contexto admiten dos modos:

• Aplicado para todos los productos: las reglas se aplican activamente y se bloquean las solicitudes que infringen.
• Modo de ejecución seca para todos los productos: las infracciones se registran, pero no se bloquean las solicitudes, lo que le permite evaluar el impacto de la directiva de forma segura.

Auditing

Las solicitudes denegadas o de ejecución seca se registran en la tabla del system.access.inbound_network sistema. Cada entrada de registro incluye:

• Hora del evento
• ID del espacio de trabajo
• Tipo de solicitud
• identidad
• Origen de red
• Tipo de acceso (DENEGADO o DRY_RUN_DENIAL)

Puede consultar estos registros para validar que las reglas se aplican correctamente y para detectar intentos de acceso inesperados.

Relación con otros controles

• Listas de acceso IP del área de trabajo: se evalúa antes de que la directiva de entrada basada en contexto permita una solicitud. Ambos deben permitir la solicitud. 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: Se aplica junto con las políticas de ingreso cuando Permitir el acceso a la red pública está habilitado. Si Permitir el acceso a la red pública está deshabilitado, todo el ingreso público está bloqueado y no se evalúan las directivas de entrada. Consulte Configurar el enlace privado de Front-end.

procedimientos recomendados

• Comience con el modo de ejecución seca para observar impactos sin interrumpir el acceso.
• Use reglas basadas en identidades siempre que sea posible para los clientes SaaS que rotan direcciones IP.
• Aplique primero las reglas de denegación a las entidades de servicio con privilegios para limitar el alcance del impacto.
• Mantenga los nombres de las directivas claros y coherentes para asegurar la mantenibilidad a largo plazo.