Introducción al control de acceso

  • Artículo

Azure Data Explorer control de acceso se basa en la autenticación y autorización. Cada consulta y comando en un recurso de Azure Data Explorer, como un clúster o una base de datos, debe pasar las 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 con el clúster, un cliente debe comunicarse con Microsoft Entra ID y solicitar un token de acceso específico de Azure Data Explorer. A continuación, el cliente puede usar el token de acceso adquirido como prueba de identidad al emitir solicitudes al clúster.

Los escenarios de autenticación principales son los siguientes:

  • Autenticación de usuario: se usa para comprobar la identidad de los usuarios humanos.
  • Autenticación de la aplicación: 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 que una aplicación intercambie 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 de usuarios y obtengan tokens para acceder al clúster. Este flujo debe implementarse con MSAL.

Nota

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

Autenticación de usuarios

La autenticación de usuario se produce cuando un usuario presenta credenciales para Microsoft Entra ID o un proveedor de identidades que se federa con Microsoft Entra ID, como Servicios de federación de Active Directory (AD FS). 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.

Azure Data Explorer admite los siguientes métodos de autenticación de usuario, incluidas las bibliotecas cliente de Kusto:

  • Autenticación de usuario interactiva con inicio de sesión a través de la interfaz de usuario.
  • Autenticación de usuario con un token de Microsoft Entra emitido para Azure Data Explorer.
  • Autenticación de usuario con un token de Microsoft Entra emitido para otro recurso que se puede intercambiar para un token de Azure Data Explorer mediante la autenticación en nombre de (OBO).

Autenticación de la aplicación

La autenticación de la aplicación 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.

Azure Data Explorer admite los siguientes métodos de autenticación de aplicaciones, incluidas las bibliotecas cliente de Kusto:

  • Autenticación de aplicaciones con una identidad administrada de Azure.
  • Autenticación de aplicación con un certificado X.509v2 instalado localmente.
  • Autenticación de aplicación con un certificado X.509v2 proporcionado a la biblioteca cliente como flujo de bytes.
  • Autenticación de la aplicación con un identificador de aplicación de Microsoft Entra y una clave de aplicación de Microsoft Entra. El identificador de aplicación y la clave de aplicación son como un nombre de usuario y una contraseña.
  • Autenticación de aplicaciones con un token de Microsoft Entra válido obtenido anteriormente, emitido a Azure Data Explorer.
  • Autenticación de aplicaciones con un token de Microsoft Entra emitido para otro recurso que se puede intercambiar para un token de Azure Data Explorer mediante la autenticación en nombre de (OBO).

Authorization

Antes de realizar una acción en un recurso de Azure Data Explorer, todos los usuarios autenticados deben pasar una comprobación de autorización. Azure Data Explorer usa el modelo de control de acceso basado en roles 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 de 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 Microsoft Entra ID. Para más información sobre cómo asignar roles de seguridad, consulte Introducción a los roles de seguridad.

Autorización de grupo

La autorización se puede conceder a Microsoft Entra ID grupos mediante la asignación de uno o varios roles al grupo.

Cuando se comprueba la autorización de un usuario o una entidad de seguridad de aplicación, el sistema comprueba primero si hay una asignación de roles explícita que permite la acción específica. Si no existe ninguna asignación de roles, el sistema analiza la pertenencia de la entidad de seguridad en todos los grupos que podrían autorizar la acción. Si se confirma que la entidad de seguridad es miembro de cualquiera de estos grupos, se autoriza la acción solicitada. De lo contrario, si la entidad de seguridad no es miembro de ninguno de estos grupos, la acción no pasa la comprobación de autorización y no se permite la acción.

Nota

La comprobación de las pertenencias a grupos puede consumir muchos recursos. Dado que las pertenencias a grupos no cambian con frecuencia, los resultados de las comprobaciones de pertenencia se almacenan en caché. La duración del almacenamiento en caché varía y se ve afectada por factores como el resultado de la pertenencia (si la entidad de seguridad es miembro o no), el tipo de entidad de seguridad (usuario o aplicación), entre otros. La duración máxima del almacenamiento en caché puede extender hasta tres horas, mientras que la duración mínima es de 30 minutos.

Contenido relacionado