Conexión a Microsoft Graph mediante el SDK de PowerShell
Conéctese a Graph de una manera segura y potente
Actualizado: 1 de agosto de 2023
En un artículo anterior, analizo el uso de cmdlets del SDK de Microsoft Graph para PowerShell para reemplazar los cmdlets de administración de licencias del módulo Azure AD antes de su retiro el 30 de junio de 2022 (actualización: Microsoft trasladó esta fecha a marzo 2024). Resulta que convertir un par de cmdlets de Azure AD reemplazándolos con cmdlets como Get-MgUser y Set-MgUserLicense no es particularmente difícil (si lo fuera, no sería capaz de hacerlo). Sin embargo, la introducción de un nuevo módulo en la combinación de PowerShell utilizada en entornos de producción siempre genera algunas preguntas e inquietudes, entre ellas la seguridad.
Existe una forma correcta e incorrecta de utilizar los cmdlets de Graph SDK en entornos de prueba y producción. En pocas palabras, ejecutar los cmdlets de forma interactiva es sencillo, pero podría provocar un problema con una entidad de servicio (aplicación) con permisos excesivos. Todo tiene que ver con la forma en que se conecta Graph SDK y los permisos que utiliza. Examinemos por qué.
Conexión al SDK de Graph
El primer paso en cualquier uso del SDK de Graph es conectarse a Graph mediante el cmdlet Connect-MgGraph. Cuando ejecuta Connect-MgGraph para conectarse a Graph, es aconsejable especificar el identificador del inquilino al que desea conectarse.
Connect-MgGraph -TenantId "828e1143-88e3-492b-bf82-24c4a47ada63"Si no especifica un inquilino, Connect-MgGraph elegirá el último inquilino en el que inició sesión durante una sesión (que puede no ser al que desea conectarse). Descubrí esto cuando me conecté a Graph y descubrí que los datos utilizados pertenecían a mi inquilino de desarrollo. Me di cuenta entonces, pero es posible que alguien se pierda esto en otro lugar, así que acostúmbrese a conectarse con el identificador del inquilino.
Una sesión dura hasta que ejecuta Disconnect-MgGraph (ver más abajo) y se puede reiniciar varias veces durante días ejecutando Connect-MgGraph. Detrás de escena, Graph SDK mantiene un caché de token cifrado y actualizará el token según sea necesario para permitirle trabajar con los comandos de Graph.
Permisos
Después de realizar una conexión exitosa, la sesión inicia sesión como su cuenta. El alcance del permiso para la conexión proviene de la entidad de servicio (aplicación empresarial) registrada en Azure AD para el SDK. Si nunca antes ha iniciado sesión en Graph SDK, el SDK crea una aplicación empresarial llamada Microsoft Graph Command Line Tools con un AppId de 14d82eec-204b-4c2f-b7e8-296a70dab67e . y solicita un conjunto limitado de permisos (Figura 1). Si es administrador, puede otorgar consentimiento para estos permisos en nombre de la organización. Para aliviar las sospechas razonables de los administradores vigilantes, sería bueno que la entidad principal de servicio apareciera como verificada, pero ese no es el caso actualmente.
Los permisos otorgados para el SDK de Microsoft Graph PowerShell los posee la entidad de servicio de la aplicación empresarial.
Obteniendo nuevos permisos
A medida que las personas comiencen a ejecutar comandos de Graph SDK utilizando el cliente interactivo, necesitarán consentimiento para los permisos necesarios para ejecutar los comandos. Por ejemplo, para usar el cmdlet Get-MgUser para recuperar un conjunto de cuentas de Azure AD, un usuario necesita permiso para leer la información del directorio, por lo que puede solicitar los permisos usando el Scope . parámetro al realizar la conexión de la siguiente manera:
$RequiredScopes = @("Directory.AccessAsUser.All", "Directory.ReadWrite.All")
Connect-MgGraph -Scopes $RequiredScopesLa conexión con un ámbito que incluye permisos que no posee la aplicación empresarial hace que Azure AD solicite consentimiento para los permisos no heredados de la entidad de servicio (Figura 2).
Al igual que otras aplicaciones que utilizan las API Graph, un administrador da su consentimiento a los permisos solicitados en nombre de la organización. Esto agrega permisos adicionales al conjunto que posee la entidad de servicio. Si un administrador no otorga su consentimiento, los permisos solicitados están disponibles (sujetos a las funciones administrativas que tiene la cuenta iniciada) para la sesión, pero no se unen al conjunto que tiene la entidad principal de servicio.
Con el tiempo, los permisos que posee la entidad principal de servicio del SDK serán los otorgados en el momento inicial del consentimiento más cualquier otro permiso otorgado posteriormente a medida que las personas trabajan con el cliente interactivo. En otras palabras, la entidad de servicio recopila permisos agregados a lo largo del tiempo. Por este motivo, no se recomienda utilizar los cmdlets del SDK de Graph de forma interactiva porque, si lo hace, con el tiempo existe una clara posibilidad de que la entidad de servicio tenga un exceso de permisos y, por lo tanto, se convierta en un riesgo de seguridad. Este es el tipo de problema destacado por App Governance for Cloud App Security (o en la solución propia que se explica en este artículo). Además, debe prestar atención a las aplicaciones a las que se les asignan permisos de alta prioridad porque son las que los atacantes podrían instalar o explotar.
La única solución para una entidad de servicio con exceso de permisos es su eliminación y recreación, momento en el cual un administrador puede otorgar consentimiento para permisos limitados a la nueva entidad de servicio. A continuación se explica cómo eliminar la entidad de servicio mediante los cmdlets de Graph SDK (naturalmente):
$Sp = Get-MgServicePrincipal -Filter "AppId eq '14d82eec-204b-4c2f-b7e8-296a70dab67e'"
Remove-MgServicePrincipal -ServicePrincipalId $Sp.IdConexión al perfil Beta
En algunas situaciones, necesitarás utilizar el perfil beta para tener acceso a ciertos comandos y datos. Esto equivale a especificar el punto final beta al emitir consultas de Graph API. Para seleccionar el perfil beta, ejecute el cmdlet Select-MgProfile:
Select-MgProfile betaActualización: V2.0 del SDK de Microsoft Graph PowerShell elimina la necesidad del cmdlet Select-MgProfile. En cambio, los cmdlets beta están en un módulo separado.
Informar su conexión
Para comprobar que está conectado al inquilino correcto con el perfil y los permisos correctos, podemos extraer información sobre el inquilino con el cmdlet Get-MgOrganization, la conexión actual con Get-MgContext cmdlet y el perfil utilizado con el cmdlet Get-MgProfile y muestra información útil:
$Details = Get-MgContext
$Scopes = $Details | Select -ExpandProperty Scopes
$Scopes = $Scopes -Join ", "
$OrgName = (Get-MgOrganization).DisplayName
CLS
Write-Host "Microsoft Graph Connection Information"
Write-Host "--------------------------------------"
Write-Host " "
Write-Host ("Connected to Tenant {0} ({1}) as account {2}" -f $Details.TenantId, $OrgName, $Details.Account)
Write-Host "+-------------------------------------------------------------------------------------------------------------------+"
Write-Host ("Profile set as {0}. The following permission scope is defined: {1}" -f $ProfileName, $Scopes)
Write-Host ""
Microsoft Graph Connection Information
--------------------------------------
Connected to Tenant a662313f-14fc-43a2-9a7a-d2e27f4f3475 (Office 365 for IT Pros) as account Global.Administrator@office365itpros.com
+-------------------------------------------------------------------------------------------------+
The following scopes are defined: Directory.AccessAsUser.All, Directory.ReadWrite.All, openid, profile, User.Read, email, Group.Read.All, Group.ReadWrite.All
Los permisos enumerados anteriormente incluyen los heredados de la entidad de servicio y cualquier otro solicitado por el usuario para la sesión.
Desconéctate cuando hayas terminado
Cuando haya terminado de interactuar con Graph, recuerde cerrar la sesión ejecutando Disconnect-MgGraph para cerrar sesión en Graph. Al desconectar la sesión se elimina el cifrado. caché de token y evita que se reinicialice una sesión.
Disconnect-MgGraphAcceso solo a la aplicación para uso en producción
La descripción anterior cubre una sesión interactiva. Esta es una buena manera de conocer los cmdlets y scripts de depuración de Graph SDK en preparación para su uso operativo. Sin embargo, cuando ejecuta cmdlets del SDK de forma interactiva, está limitado a delegar permisos. En otras palabras, puede acceder a elementos con los que puede interactuar a través de aplicaciones de Microsoft 365, pero no puede acceder a elementos que pertenecen a otros usuarios. Por ejemplo, puede leer elementos en su buzón pero no en otro buzón. Si desea ejecutar el SDK con permisos de aplicación, puede hacerlo con una aplicación o en Azure Automation (usando una cuenta RunAs o una identidad administrada).
Debido a los problemas con el consentimiento y la entidad de servicio, Microsoft recomienda que los scripts operativos utilicen aplicaciones registradas de Azure AD con autenticación basada en certificados (acceso solo a aplicaciones) o una identidad administrada. Ciertamente puedes escribir y probar scripts usando el cliente interactivo, pero una vez que el código esté completo, es hora de ejecutarlo usando su propia aplicación con un conjunto de permisos de alcance estricto. Este enfoque significa que puede restringir los permisos asignados a las aplicaciones solo al conjunto necesario para el procesamiento realizado por el script y restringir aquellos que pueden usar la aplicación a un conjunto seleccionado de cuentas. La desventaja de usar aplicaciones independientes con permisos de ámbito es que, con el tiempo, es posible que se acumulen muchas aplicaciones registradas en Azure AD que deban administrarse.
La alternativa es usar Azure Automation con identidades administradas para ejecutar scripts que usan cmdlets del SDK. Consulte este artículo para obtener más información.
Algunos problemas que Microsoft debe resolver
Tener una entidad de servicio que recopile permisos diligentemente y de forma continua no parece ser una buena idea. De hecho, es una pésima idea. Microsoft necesita encontrar una mejor manera de permitir a los administradores ejecutar cmdlets Graph SDK de forma interactiva sin crear un problema de seguridad. Eliminar la entidad de seguridad cuando se ejecuta Disconnect-MgGraph es una manera de poner a cero los permisos, pero es una mala solución. Permitir que las personas codifiquen nombres de usuarios y contraseñas o utilicen secretos de aplicaciones en scripts para autenticar el acceso a Graph tampoco es una dirección a seguir dado el panorama de amenazas actual.
El quid de la cuestión es que los administradores de inquilinos se olvidarán del problema de la acumulación de permisos a menos que verifiquen los principales de servicio. Es triste pero cierto, y se debe a las exigencias de otros trabajos. Las personas tampoco ejecutarán Disconnect-MgGraph por la misma razón que se ignoran cmdlets como Disconnect-MicrosoftTeams y Disconnect-ExchangeOnline.
Graph SDK es una idea excelente porque aísla a los usuarios de PowerShell de muchas de las complejidades involucradas en el uso de Graph API. Todavía es un trabajo en progreso, pero si Microsoft quiere hacer del Graph SDK una herramienta de referencia para los administradores de inquilinos, deben resolver el problema de los permisos. Y pronto (¡antes de esa fecha límite de desuso!)