Autorización y API de seguridad de Microsoft Graph

Los datos de seguridad accesibles a través de la API de seguridad de Microsoft Graph son confidenciales y están protegidos por los permisos y los roles de Azure Active Directory (Azure AD).

La API de seguridad de Microsoft Graph admite dos tipos de autorización:

  • Autorización a nivel de aplicación: ningún usuario inició sesión (por ejemplo, un escenario SIEM). Los permisos otorgados a la aplicación determinan la autorización.

    Nota: esta opción también admite casos en los que la aplicación administra el Control de acceso basado en roles (RBAC).

  • Autorización delegada por el usuario: un usuario miembro del espacio empresarial de Azure AD ha iniciado sesión. El usuario debe ser miembro de un rol de administrador limitado de Azure AD (ya sea lector o administrador de seguridad) y, además, la aplicación debe contar con los permisos necesarios.

Si realiza una llamada a la API de seguridad de Microsoft Graph desde Probador de Graph:

  • El administrador del espacio empresarial de Azure AD debe conceder de forma explícita los permisos solicitados a la aplicación del Explorador de Graph.
  • El usuario debe ser miembro del rol de administrador limitado del lector de seguridad en Azure AD (ya sea lector o administrador de seguridad).

Nota: el Explorador de Graph no admite la autorización a nivel de aplicación.

Si realiza una llamada a la API de seguridad de Microsoft Graph desde una aplicación propia o personalizada:

  • El administrador del espacio empresarial de Azure AD debe conceder de forma explícita los permisos a su aplicación. Esto es necesario tanto para las autorizaciones a nivel de aplicación y delegadas por usuarios.
  • Si usa una autorización delegada por usuario, dicha persona debe ser miembro del rol de administrador limitado del lector o administrador de seguridad en Azure AD.

Administrar la autorización en las aplicaciones cliente con API de seguridad

Los datos de seguridad proporcionados a través de la API de seguridad de Microsoft Graph son confidenciales y deben estar protegidos por los mecanismos de autorización y autenticación adecuados. La siguiente tabla indica los pasos para registrarse y crear una aplicación cliente que puede acceder a la API de seguridad de Microsoft Graph.

Quién Acción
Propietario o desarrollador de la aplicación Registra la aplicación como una aplicación de empresa.
Administrador de un espacio empresarial Le concede permisos a la aplicación.
Administrador de un espacio empresarial Asigna roles a los usuarios.
Desarrollador de la aplicación Inicia sesión como usuario y usa la aplicación para acceder a la API de seguridad de Microsoft Graph.

El registro de la aplicación solo define qué permisos necesita la aplicación para poder ejecutarse. NO le concede los permisos a la aplicación.

El administrador de espacios empresariales de Azure AD DEBE conceder de forma explícita los permisos a la aplicación. Esto debe realizarse por espacio empresarial cada vez que se modifican los permisos de aplicación en el portal de registro correspondiente.

Por ejemplo, imagine que tiene una aplicación, dos espacios empresariales de Azure AD (E1 y E2) y dos permisos (P1 y P2). A continuación, se muestra el proceso de autorización:

  • La aplicación se registra para exigir el permiso P1.
  • Cuando los usuarios del espacio empresarial E1 obtienen un token de Azure AD para esta aplicación, el token no contiene ningún permiso.
  • El administrador de Azure AD del espacio empresarial E1 concede de forma explícita permisos a la aplicación. Cuando los usuarios del espacio empresarial E1 obtienen un token de Azure AD para la aplicación, el token contendrá el permiso P1.
  • Cuando los usuarios del espacio empresarial E2 obtienen un token de Azure AD para la aplicación, el token no contiene ningún permiso, ya que el administrador del espacio empresarial E2 todavía no le ha concedido permisos a la aplicación. Los permisos deben otorgarse por espacio empresarial y por aplicación.
  • El registro de la aplicación cambia para que ahora se requieran permisos P1 y P2.
  • Cuando los usuarios del espacio empresarial E1 obtienen un token de Azure AD para la aplicación, el token solo contendrá el permiso P1. Los permisos concedidos a una aplicación se registran como instantáneas de lo que se le ha concedido: no cambian automáticamente después de que cambie el registro (permiso) de la aplicación.
  • El administrador del espacio empresarial E2 le concede permisos P1 y P2 a la aplicación. Ahora bien, cuando los usuarios del espacio empresarial E2 obtienen un token de Azure AD para la aplicación, el token contendrá los permisos P1 y P2.

Nota: Los tokens de Azure AD para la aplicación en el espacio empresarial E1 y E2 contienen diferentes permisos, ya que cada administrador del espacio empresarial ha concedido diferentes permisos a la aplicación.

  • Para que la aplicación vuelva a funcionar en el espacio empresarial E1, el administrador del espacio E1 debe concederle los permisos P1 y P2 de forma explícita a la aplicación.

Registro de una aplicación con el punto de conexión de la plataforma de identidad de Microsoft para desarrolladores

Para registrar una aplicación con el punto de conexión de plataforma de identidad de Microsoft para desarrolladores, necesitará:

  • Nombre de la aplicación: una cadena que se usa para el nombre de aplicación.
  • Dirección URL de redirección: la dirección URL desde donde se envía la respuesta de autenticación de Azure AD. Para comenzar, puede usar la página principal de prueba de la aplicación web del cliente.
  • Permisos necesarios: los permisos que necesita su aplicación para poder realizar una llamada a Microsoft Graph.

Para registrar su aplicación, haga lo siguiente:

  1. Vaya al portal de registro de aplicaciones de Azure e inicie sesión.

    Nota: No necesita ser administrador de espacios empresariales. Se lo redirigirá a la lista Mis aplicaciones.

  2. Seleccione Nuevo registro.

  3. En la página de registro de la nueva aplicación, escriba un valor para nombre y seleccione los tipos de cuenta que desea usar. En el campo Dirección URL de redireccionamiento, escriba la URL correspondiente.

  4. Seleccione Registrar para crear la aplicación y ver su página de información general. *

  5. Vaya a la página Permisos de API.

  6. Seleccione Agregar un permiso y, a continuación, elija Microsoft Graph en el control flotante. Seleccione Permisos delegados Use el cuadro de búsqueda para buscar y seleccionar los permisos necesarios. Para obtener una lista de permisos, consulte Permisos de seguridad.

    Nota: La API de Microsoft Graph Security requiere el ámbito SecurityEvents.Read.All para las consultas GET y el ámbito SecurityEvents.ReadWrite.All para las consultas PATCH, POST y DELETE.

    Permiso Entidad Solicitudes admitidas
    SecurityActions.Read.All securityActions (versión preliminar) GET
    SecurityActions.ReadWrite.All securityActions (versión preliminar) GET, POST
    SecurityEvents.Read.All alerts
    secureScores
    secureScoreControlProfiles
    OBTENER
    SecurityEvents.ReadWrite.All alerts
    secureScores
    secureScoreControlProfiles
    GET, POST, PATCH
    ThreatIndicators.ReadWrite.OwnedBy tiIndicator (versión preliminar) GET, POST, PATCH, DELETE
  7. Elija Agregar permisos.

Guarde la siguiente información:

  • Identificador de aplicación (cliente)
  • Dirección URL de redireccionamiento
  • Lita de permisos necesarios

* La Protección contra amenazas avanzada de Windows Defender (WDATP) requiere roles de usuario adicionales a los que necesita la API de seguridad de Microsoft Graph. Por lo tanto, solo los usuarios de los roles de la API Microsoft Graph Security y WDATP pueden tener acceso a los datos de WDATP. Esto no limita la autenticación solo de la aplicación, por lo que le recomendamos que use un token de autenticación solo de la aplicación.

Para más información, vea Registrar la aplicación con la plataforma de identidad de Microsoft.

Conceda permisos a la aplicación.

El registro de la aplicación solo define qué permisos necesita la aplicación y no le concede los permisos. Un administrador de espacios empresariales de Azure AD explícitamente debe conceder estos permisos de forma explícita mediante una llamada al punto de conexión de consentimiento de administrador. Para obtener más información, consulte Usar el punto de conexión de consentimiento de administrador.

Para conceder permisos a una aplicación, necesitará lo siguiente:

  • Id. de aplicación: el Id. de aplicación del portal de registro de la aplicación de Azure.
  • Dirección URL de redireccionamiento: la cadena que configure en el portal de registro de la aplicación de Azure para la respuesta de autenticación.

Para conceder los permisos:

  • En un editor de texto, cree la siguiente cadena de dirección URL:

    https://login.microsoftonline.com/common/adminconsent?client_id=<Application Id>&state=12345&redirect_uri=<Redirect URL>

  • En un navegador web, vaya a esta dirección URL e inicie sesión como administrador del espacio empresarial. El cuadro de diálogo muestra la lista de permisos que necesita la aplicación, como se indica en el portal de registro de la aplicación. Elija Aceptar para conceder estos permisos a la aplicación.

Nota: Este paso concede permisos a la aplicación, no a los usuarios. Esto significa que a todos los usuarios que pertenezcan al espacio empresarial de Azure AD y que usen esta aplicación se les concederán los permisos, incluso a los usuarios que no son administradores.

Asignar roles de Azure AD a usuarios

Después de que se conceden permisos a una aplicación, todos los usuarios con acceso a ella (es decir, los miembros del espacio empresarial de Azure AD) reciben los permisos concedidos. Para proteger datos confidenciales de seguridad, la API de seguridad de Microsoft Graph también requiere que a los usuarios se les asigne el rol de lector de seguridad de Azure AD. Para obtener más información, vea Permisos de roles de administrador en Azure Active Directory y Asignar roles de administrador y de no administrador a los usuarios con Azure Active Directory.

Nota: Para realizar este paso, debe ser administrador de un espacio empresarial.

Para asignar un rol a un usuario:

  1. Inicie sesión en Azure Portal (https://portal.azure.com)).
  2. Haga clic en el icono de la esquina superior izquierda para expandir el menú de Azure Portal. Seleccione Azure Active Directory > Usuarios.
  3. Haga clic en el nombre del usuario.
  4. Elija Roles asignados y, después, Agregar tarea.
  5. Seleccione Lector de seguridad y haga clic en Agregar.

Crear un código de autenticación

Para crear un código de autenticación, necesitará lo siguiente:

  • Id. de aplicación: el Id. de aplicación del portal de registro de la aplicación.
  • Dirección URL de redirección: la dirección URL desde donde se envía la respuesta de autenticación de Azure AD. Para comenzar, puede usar https://localhost o la página principal de prueba de la aplicación web del cliente.
  • Tecla de aplicación (opcional): la tecla de la aplicación. Esto se aplica al desarrollar una aplicación que usará el código de autenticación solo de la aplicación (es decir, que no admitirá la autenticación delegada por el usuario).

En la siguiente tabla se indican los recursos que puede usar para crear un código de autenticación.

Tipo de aplicación Biblioteca de autenticación
Aplicaciones de escritorio - iOS MSAL.framework: Biblioteca de autenticación de Microsoft (versión preliminar para iOS)
Aplicaciones de escritorio - Android Biblioteca de autenticación de Microsoft (MSAL)
Aplicaciones de escritorio - .Net Biblioteca de autenticación de Microsoft (MSAL)
Aplicaciones web - JavaScript SPA Biblioteca de autenticación de Microsoft para JavaScript (versión preliminar)
Aplicaciones web - Servidor web de .NET OpenIdConnection, Cookies, SystemWeb
Aplicaciones web - aplicaciones web NodeJS

En el caso de las aplicaciones que no utilizan ninguna de las bibliotecas existentes, consulte Obtener acceso en nombre de un usuario.

  1. Obtenga un código de Azure AD. La consulta a la llamada contiene el parámetro de Id. de aplicación, Dirección URL de redirección y los permisos necesarios.
  2. Use el código para obtener un token de acceso.

Si usa una biblioteca de OpenId Connect, consulte Autenticarse con Azure AD y OpenID Connect y realice una llamada a app.UseOpenIdConnectAuthentication().

Nota: Si está solicitando tokens de autenticación delegados por el usuario, el parámetro de la biblioteca es Ámbitos solicitados. Use "User.Read" para este parámetro en lugar de lo que requiere la aplicación registrada. El parámetro Ámbitos solicitados NO afecta a los permisos que contienen los tokens de autenticación que se muestran. Estos dependen de los permisos que el administrador del espacio empresarial concede a la aplicación.

Por ejemplo, si usa la biblioteca de .NET MSAL, realice una llamada a lo siguiente:

var accessToken = (await client.AcquireTokenAsync(scopes)).AccessToken;

Nota: Este ejemplo debe utilizar los permisos con privilegios mínimos, como "User.Read". Sin embargo, el token de acceso que se muestre puede contener los permisos concedidos por el administrador del espacio empresarial para el espacio empresarial del usuario actual, como "User.Read.All" o "User.ReadWrite.All".

Azure AD muestra un token (cadena) que contiene su información de autenticación y los permisos que necesita la aplicación. Asigne este token al encabezado HTTP como un token portador, tal como se muestra en el siguiente ejemplo.

request.Headers.Authorization = new AuthenticationHeaderValue("bearer", accessToken);

Microsoft Graph validará la información que contenga este token y concederá o rechazará el acceso.

Para ver notificaciones incluidas en el token que se muestre, use la biblioteca "System.IdentityModel.Tokens.Jwt" de NuGet.

JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler();
var securityToken = tokenHandler.ReadToken(accessToken) as JwtSecurityToken;

La respuesta de Microsoft Graph contiene un encabezado llamado "client-request-id", que es un GUID. Si se rechaza el acceso, especifique este GUID cuando obtenga asistencia técnica en Microsoft Tech Community. De esta forma, podremos ayudarlo a investigar la causa de este error de autenticación.