Introducción al control de acceso

Se aplica a: ✅Microsoft Fabric✅azure Data Explorer

El control de acceso se basa en la autenticación y autorización. Cada consulta y comando de un recurso de Fabric, como una base de datos, debe pasar comprobaciones de autenticación y autorización.

• autenticación: valida la identidad de la entidad de seguridad que realiza una solicitud.
• autorización: valida la entidad de seguridad que realiza una solicitud para realizar esa solicitud en el recurso de destino.

Autenticación

Para autenticarse mediante programación, un cliente debe comunicarse con id. de Microsoft Entra y solicitar un token de acceso específico para el servicio Kusto. A continuación, el cliente puede usar el token de acceso adquirido como prueba de identidad al emitir solicitudes a la base de datos.

Los principales escenarios de autenticación son los siguientes:

• autenticación de usuario: se usa para comprobar la identidad de los usuarios humanos.
• autenticación de aplicaciones: se usa para comprobar la identidad de una aplicación que necesita acceder a los recursos sin intervención humana mediante credenciales configuradas.
• autenticación en nombre de (OBO): permite a una aplicación intercambiar un token para dicha aplicación con un token para acceder a un servicio kusto. Este flujo debe implementarse con MSAL.
• autenticación de aplicación de página única (SPA): permite que las aplicaciones web spa del lado cliente inicien sesión a los usuarios y obtengan tokens para acceder a la base de datos. Este flujo debe implementarse con MSAL.

Nota

Para la autenticación de usuarios y aplicaciones, se recomienda usar las bibliotecas cliente de Kusto de . Si necesita autenticación en nombre de (OBO) o Single-Page aplicación (SPA), debe usar MSAL directamente, ya que las bibliotecas cliente no admiten estos flujos. Para obtener más información, consulte autenticación con la biblioteca de autenticación de Microsoft (MSAL).

Autenticación de usuario

La autenticación de usuario se produce cuando un usuario presenta credenciales a Microsoft Entra ID o a un proveedor de identidades que federa con el identificador de Microsoft Entra, como los Servicios de federación de Active Directory. El usuario obtiene un token de seguridad que se puede presentar al servicio Azure Data Explorer. Azure Data Explorer determina si el token es válido, si un emisor de confianza emite el token y qué notificaciones de seguridad contiene el token.

Autenticación de aplicaciones

La autenticación de aplicaciones es necesaria cuando las solicitudes no están asociadas a un usuario específico o cuando ningún usuario está disponible para proporcionar credenciales. En este caso, la aplicación se autentica en microsoft Entra ID o en el IdP federado mediante la presentación de información secreta.

Autorización

Antes de realizar una acción en un recurso, todos los usuarios autenticados deben pasar una comprobación de autorización. Se usa el modelo de control de acceso basado en rol de Kusto, donde las entidades de seguridad se describen a uno o varios roles de seguridad. La autorización se concede siempre que uno de los roles asignados al usuario les permita realizar la acción especificada. Por ejemplo, el rol Usuario de base de datos concede a las entidades de seguridad el derecho a leer los datos de una base de datos determinada, crear tablas en la base de datos, etc.

La asociación de entidades de seguridad a roles de seguridad se puede definir individualmente o mediante grupos de seguridad definidos en el identificador de Microsoft Entra. Para obtener más información sobre cómo asignar roles de seguridad, consulte Información general sobre los roles de seguridad.

Autorización de grupo

La autorización se puede conceder a los grupos de identificadores de Entra de Microsoft asignando uno o varios roles al grupo.

Al comprobar la autorización de un usuario o una entidad de seguridad de aplicación, el sistema busca primero una asignación de roles explícita que permita la acción específica. Si la asignación de roles no existe, el sistema comprueba la pertenencia de la entidad de seguridad en todos los grupos que podrían autorizar la acción.

Si la entidad de seguridad es miembro de un grupo con los permisos adecuados, se autoriza la acción solicitada. De lo contrario, la acción no pasa la comprobación de autorización y no está permitida.

Nota

La comprobación de pertenencias a grupos puede consumir muchos recursos. Dado que las pertenencias a grupos no cambian con frecuencia, los resultados de la comprobación de pertenencia se almacenan en caché. La duración del almacenamiento en caché varía y determina la rapidez con la que se actualizan los cambios en las pertenencias a grupos. Agregar un usuario a un grupo puede tardar hasta 30 minutos en propagarse. Quitar un usuario de un grupo puede tardar hasta tres horas.

Forzar actualización de pertenencia a grupos

Las entidades de seguridad pueden forzar una actualización de la información de pertenencia a grupos. Esta funcionalidad es útil en escenarios en los que los servicios de acceso con privilegios Just-In-Time (JIT), como Microsoft Entra Privileged Identity Management (PIM), se usan para obtener privilegios más altos en un recurso.

Actualización de un grupo específico

Las entidades de seguridad pueden forzar una actualización de la de pertenencia a grupos para un grupo específico. Sin embargo, se aplican las restricciones siguientes:

• Se puede solicitar una actualización hasta 10 veces por hora por entidad de seguridad.
• La entidad de seguridad solicitante debe ser miembro del grupo en el momento de la solicitud.

La solicitud produce un error si no se cumple alguna de estas condiciones.

Para volver a evaluar la pertenencia de la entidad de seguridad actual de un grupo, ejecute el siguiente comando:

En el ejemplo siguiente, reemplace <GroupFQN> por sus propios valores, como group='aadGroup=MyGroup@MyOrg.com'.

.clear cluster cache groupmembership with (group='<GroupFQN>')

Use el nombre completo del grupo (FQN). Para obtener más información, vea Hacer referencia a entidades de seguridad y grupos de Microsoft Entra.

Actualización de otras entidades de seguridad

Una entidad de seguridad con privilegios puede solicitar un de actualización para otras entidades de seguridad. La entidad de seguridad solicitante debe tener acceso a AllDatabaseMonitor para el servicio de destino. Las entidades de seguridad con privilegios también pueden ejecutar el comando anterior sin restricciones.

Para actualizar la pertenencia a grupos de otra entidad de seguridad, ejecute el siguiente comando:

En el comando siguiente, reemplace <PrincipalFQN> por su propio nombre completo de entidad de seguridad (FQN) y <GroupFQN> por su propio FQN de grupo, como principal='aadUser=UserUpn@MyOrg.com', group='aadGroup=MyGroup@MyOrg.com'. Para obtener más información, vea Hacer referencia a entidades de seguridad y grupos de Microsoft Entra.

.clear cluster cache groupmembership with (principal='<PrincipalFQN>', group='<GroupFQN>')

Contenido relacionado

• Comprenda control de acceso basado en rol de Kusto.
• Para la autenticación de usuario o aplicación, use las bibliotecas cliente de Kusto de .
• Para la autenticación de OBO o SPA, consulte Autenticación con la biblioteca de autenticación de Microsoft (MSAL).
• Para hacer referencia a entidades de seguridad y grupos, consulte Referencia a entidades de seguridad y grupos de Microsoft Entra.