Cómo averiguar qué permisos de Microsoft Graph necesita
Al trabajar con el SDK de Microsoft Graph PowerShell
A estas alturas, debe saber que Microsoft planea retirar los módulos Azure AD y MSOL PowerShell a finales de 2022 o poco después. Los cmdlets de los módulos retirados seguirán funcionando después, pero no tendrán ningún soporte. Microsoft sugiere que actualice los scripts para usar cmdlets del SDK de Microsoft Graph PowerShell. La conversión real suele ser una cuestión de encontrar un cmdlet coincidente en el mapa de cmdlets de Microsoft y cambiar a él. Sin embargo, otras complejidades se interponen antes de que los cmdlets se ejecuten sin problemas. Averiguar los permisos correctos de la API de Microsoft Graph para acceder a los datos es solo una de esas complejidades.
Modelo de permiso mínimo
El manejo de permisos difiere significativamente entre el módulo Azure AD PowerShell y el SDK de Microsoft Graph PowerShell. Cuando inicia sesión con el cmdlet Connect-AzureAD, puede usar todos los permisos administrativos que posee la cuenta con la que inicia sesión. Sin embargo, Graph SDK opera con un modelo de permiso mínimo, lo que significa que debe solicitar permisos para realizar acciones, incluso cuando se conecta con una cuenta con muchos permisos.
El primer paso para actualizar un script de cmdlets de Azure AD a cmdlets del SDK es considerar qué permisos necesita el script para realizar su procesamiento. Esta regla se aplica independientemente de cómo use los cmdlets del SDK: de forma interactiva, a través de un trabajo en segundo plano que usa autenticación basada en certificados o en un runbook de Azure Automation. A diferencia de los permisos heredados de las cuentas iniciadas, los permisos utilizados por el SDK se otorgan a la entidad de servicio utilizada para ejecutar los cmdlets del SDK. Para sesiones interactivas, la entidad de servicio es Microsoft Graph.
Entonces surge la pregunta de cómo encontrar los permisos de la API de Microsoft Graph necesarios para realizar una acción. Puedes lograr el objetivo de cuatro maneras:
Adivina y excede el permiso
El primer método es un enfoque de conjetura y esperanza. En otras palabras, otorgue todos los permisos que un script pueda usar o siga agregando permisos hasta que se ejecute el código. El peligro aquí es que termine con una entidad de servicio con muchos permisos que se convierta en un objetivo atractivo para los atacantes. Si usa sesiones interactivas para ejecutar cmdlets del SDK, existe una buena posibilidad de que la entidad de servicio Microsoft Graph PowerShell adquiera muchos permisos con el tiempo y termine en un estado con muchos permisos (Figura 1). Volveremos a esta cuestión más adelante.
Utilice el Explorador de gráficos para resaltar los permisos de gráficos
A continuación, si ejecuta una consulta en Graph Explorer, el explorador le muestra los permisos necesarios para ejecutar la consulta en la pestaña Modificar permisos (Figura 2). El conjunto de permisos que se muestra incluye todos los permisos válidos que puede utilizar, por lo que debe seleccionar el permiso más apropiado. En este caso, la consulta es recuperar el conjunto de cuentas de usuario en el inquilino (uno del conjunto básico de operaciones de cuentas de usuario), por lo que el permiso User.Read.All es una buena opción.
Gestión de riesgos de ciberseguridad para Active Directory
Descubra cómo prevenir y recuperarse de ataques AD a través de estas soluciones de gestión de riesgos de ciberseguridad.
Lea la documentación de Graph
Todos los cmdlets del SDK se originan a partir de consultas Graph. Microsoft utiliza un proceso llamado AutoRest para procesar consultas Graph disponibles y crear cmdlets SDK. Este proceso ocurre mensualmente para crear una nueva versión del SDK. El proceso también crea documentación automatizada, pero el texto generado por la máquina suele ser obtuso y difícil de seguir, por lo que a menudo vuelvo a la documentación subyacente de Graph. Tomemos el ejemplo de enumerar cuentas de usuario. Una búsqueda rápida nos lleva a la página Lista de usuarios, que enumera los permisos necesarios tanto para los delegados (utilizados para acceder a los datos como usuario que inició sesión) como para la aplicación (utilizados para procesos en segundo plano). En este caso, la página confirma que User.Read.All es una buena opción.
Utilice la ayuda del SDK para identificar los permisos de gráficos
El SDK incluye dos cmdlets para ayudar a los desarrolladores a determinar qué permisos necesitan para realizar acciones.
- Find-MgGraphPermission: enumera los permisos delegados y de aplicación para diferentes acciones.
- Find-MgGraphCommand: enumera los cmdlets disponibles para interactuar con diferentes tipos de objetos, incluidos los permisos necesarios. El cmdlet funciona tomando el URI de un objeto para buscar los comandos disponibles.
Por ejemplo, supongamos que quiero interactuar con la información de la organización almacenada en Azure AD. Podría comenzar ejecutando el cmdlet Find-MgGraphPermission:
Find-MgGraphPermission organization | ? {$_.PermissionType -eq "Application"} | Format-List Name, Description
Name : Organization.Read.All
Description : Allows the app to read the organization and related resources, on behalf of the signed-in user. Related resources include things like subscribed skus and tenant branding information.
Name : Organization.ReadWrite.All
Description : Allows the app to read and write the organization and related resources, on behalf of the signed-in user. Related resources include things like subscribed skus and tenant branding information.
El comando canaliza su salida para filtrar y mostrar los permisos de la aplicación (los mismos permisos delegados están disponibles). A partir del resultado, es obvio que debemos usar el permiso Organization.Read.All para leer información de la organización (como el nombre y el identificador del inquilino) y Organization.ReadWrite.All. en caso de que necesitemos actualizar una configuración grabable.
Por brevedad, muestro solo el nombre del permiso y la descripción arriba. Aquí está el resultado completo del permiso Group.ReadWrite.All, necesario para actualizar las propiedades de los grupos de Azure AD, incluidos los grupos de Microsoft 365.
Id : 62a82d76-70ea-41e2-9197-370581804d09
PermissionType : Application
Consent : Admin
Name : Group.ReadWrite.All
Description : Allows the app to create groups, read all group properties and memberships, update group properties and memberships, and delete groups. Also allows the app to read and write group calendar and conversations. All of these operations can be performed by the app without a signed-in user.
Puede probar una versión modificada de los comandos para ver qué permisos se necesitan para interactuar con usuarios, grupos, Azure AD (directorio), aplicaciones (aplicación), etc.
El cmdlet Find-MgGraphCommand pasa parte de una URL de Graph para ver qué cmdlets de SDK están disponibles para esa URL. Una URL es algo así como Usuarios o Grupos para enumerar cmdlets disponibles para tratar conjuntos de objetos. Si agrega {id}, significa que desea ver los cmdlets disponibles para procesar objetos individuales.
Por ejemplo, veamos qué cmdlets están disponibles para procesar grupos individuales. El comando y su salida se muestran a continuación:
Find-MgGraphCommand -uri "/groups/{id}" | ? {$_.APIVersion -eq "v1.0"} | Fl Command, Method, Permissions
Command : Get-MgGroup
Method : GET
Permissions : {Directory.AccessAsUser.All, Directory.Read.All, Directory.ReadWrite.All, Group.Read.All...}
Command : Remove-MgGroup
Method : DELETE
Permissions : {Directory.AccessAsUser.All, Group.ReadWrite.All}
Command : Update-MgGroup
Method : PATCH
Permissions : {Directory.AccessAsUser.All, Directory.ReadWrite.All, Group.ReadWrite.All}
Graph tiene dos puntos finales, V1.0 y beta. El terminal V1.0 es la versión de producción, mientras que el terminal beta está en desarrollo. En muchos casos, utilizará cmdlets con el punto final beta porque proporcionan funcionalidad adicional. Por ejemplo, si ejecuta el cmdlet Get-MgUser en el punto final V1.0, no devuelve ninguna información de licencia para las cuentas, pero sí cuando se ejecuta en el punto final beta.
En este caso, filtré el resultado para mostrar solo los comandos disponibles en el punto final V1.0 y podemos ver que hay tres cmdlets disponibles para enumerar un grupo, eliminar un grupo y actualizar las propiedades de un grupo. También podemos ver que el permiso Group.Read.All es suficiente para leer la información del grupo, pero necesitamos Group.ReadWriteAll para eliminar o actualizar un grupo.
Alcance
Una vez que haya descubierto qué permisos de la API de Microsoft Graph son necesarios para que un script realice las acciones que necesita, indique el conjunto de permisos necesarios al conectarse a Graph en el parámetro Ámbitos del cmdlet Connect-MgGraph. Por ejemplo:
$RequiredScopes = ("Organization.ReadWrite.All”, "Directory.Read.All")
Connect-MgGraph -Scope $RequiredScopes
Para sesiones interactivas, si la entidad principal del servicio Microsoft Graph PowerShell no tiene consentimiento para usar los permisos solicitados, se le solicitará su consentimiento (Figura 3).
Si permite que la aplicación use el permiso, la sesión puede usar el permiso delegado durante la duración de la sesión. Básicamente, el permiso delegado significa que el usuario puede acceder a los datos que posee pero no puede acceder a los datos que pertenecen a otros usuarios. Sin embargo, también es posible que se pueda obtener acceso a los datos a través de funciones administrativas asignadas a una cuenta. Como explica Microsoft en su documentación, “los permisos efectivos de su aplicación son la intersección con menos privilegios de los permisos delegados que la aplicación ha recibido (por consentimiento) y los privilegios del usuario actualmente registrado .” En otras palabras, si su cuenta tiene una función de administrador, podrá acceder a más datos que si su cuenta no la tiene.
Si otorga su consentimiento en nombre de la organización, Entra ID agrega el permiso a la entidad principal del servicio y estará disponible para todas las sesiones posteriores. El consentimiento otorgado a la entidad de servicio es para un permiso de aplicación, lo que significa que el usuario puede acceder a datos de toda la organización.
Después de conectarse, puede verificar qué permisos están activos ejecutando:
(Get-MgContext).ScopesPermisos de gráficos acumulados
La acumulación constante de permisos por parte de la entidad de servicio Microsoft Graph PowerShell es algo contra lo que hay que protegerse. Si desea eliminar todos los permisos de la entidad de servicio, puede hacerlo a través del centro de administración de Azure AD (como en la Figura 1) o puede eliminar la entidad de servicio. Cuando esto sucede, el SDK detecta que falta la entidad de servicio la próxima vez que alguien intente iniciar sesión y la vuelve a crear (el AppId para la entidad de servicio siempre es 14d82eec-204b-4c2f-b7e8-296a70dab67e). .
Para crear la entidad de servicio, conéctese a Graph con el permiso Application.ReadWrite.All y ejecute estos comandos:
El cmdlet Remove-MgServicePrincipal no solicitará confirmación. Afortunadamente, pronto Azure AD demostrará la capacidad de restaurar objetos principales de servicio eliminados temporalmente, en caso de que cometa un error.
$SDKServicePrincipalId = (Get-MgServicePrincipal -all | ? {$_.DisplayName -eq "Microsoft Graph PowerShell"}).Id
Remove-MgServicePrincipal -ServicePrincipalId $SDKServicePrincipalID
Más complejo, más control
Trabajar con el SDK de Microsoft Graph PowerShell requiere más atención a los permisos que la norma (hasta ahora) con los módulos de PowerShell. En lugar de asumir permisos administrativos, debe solicitar permisos y utilizar sólo el conjunto requerido. Toma un poco de tiempo acostumbrarse y es parte de la lista de verificación para la conversión de scripts basados en los módulos de Azure AD y MSOL. Como la mayoría de las cosas en la vida, con el tiempo nos acostumbraremos a la gestión de permisos para las conexiones.