Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Puede contener otros grupos de gestión o suscripciones.
Esto permite aplicar controles de gobernanza como RBAC y Azure Policy una vez a nivel de grupo de gestión y que sean heredados por todas las suscripciones en el grupo.
Se pueden soportar 10,000 grupos de gestión en un solo directorio.
Un árbol de grupos de gestión puede soportar hasta seis niveles de profundidad. Este límite no incluye el nivel raíz o el nivel de suscripción.
Cada grupo de gestión y suscripción puede soportar solo un padre.
Aunque se pueden crear varios grupos de gestión, solo hay 1 grupo de gestión raíz.
El grupo de gestión raíz contiene todos los otros grupos de gestión y suscripciones y no puede ser movido o eliminado.
Todas las suscripciones dentro de un solo grupo de gestión deben confiar en el mismo inquilino de Entra ID.
Es otro contenedor lógico donde se pueden ejecutar recursos (VMs, DBs…) y se facturará.
Su padre es siempre un grupo de gestión (y puede ser el grupo de gestión raíz) ya que las suscripciones no pueden contener otras suscripciones.
Confía en un solo directorio de Entra ID
Los permisos aplicados a nivel de suscripción (o cualquiera de sus padres) son heredados a todos los recursos dentro de la suscripción.
De la documentación: Un grupo de recursos es un contenedor que alberga recursos relacionados para una solución de Azure. El grupo de recursos puede incluir todos los recursos para la solución, o solo aquellos recursos que deseas gestionar como un grupo. Generalmente, agrega recursos que comparten el mismo ciclo de vida al mismo grupo de recursos para que puedas desplegarlos, actualizarlos y eliminarlos fácilmente como un grupo.
Todos los recursos deben estar dentro de un grupo de recursos y solo pueden pertenecer a un grupo y si se elimina un grupo de recursos, todos los recursos dentro de él también se eliminan.
Cada recurso en Azure tiene un ID de Recurso de Azure que lo identifica.
El formato de un ID de Recurso de Azure es el siguiente:
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}
Para una máquina virtual llamada myVM en un grupo de recursos myResourceGroup bajo el ID de suscripción 12345678-1234-1234-1234-123456789012, el ID de Recurso de Azure se ve así:
/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM
Azure es la plataforma de computación en la nube integral de Microsoft, que ofrece una amplia gama de servicios, incluyendo máquinas virtuales, bases de datos, inteligencia artificial y almacenamiento. Actúa como la base para alojar y gestionar aplicaciones, construir infraestructuras escalables y ejecutar cargas de trabajo modernas en la nube. Azure proporciona herramientas para desarrolladores y profesionales de TI para crear, desplegar y gestionar aplicaciones y servicios sin problemas, atendiendo a una variedad de necesidades desde startups hasta grandes empresas.
Entra ID es un servicio de gestión de identidad y acceso basado en la nube diseñado para manejar la autenticación, autorización y control de acceso de usuarios. Potencia el acceso seguro a servicios de Microsoft como Office 365, Azure y muchas aplicaciones SaaS de terceros. Con características como inicio de sesión único (SSO), autenticación multifactor (MFA) y políticas de acceso condicional, entre otras.
Los Servicios de Dominio de Entra extienden las capacidades de Entra ID al ofrecer servicios de dominio gestionados compatibles con entornos tradicionales de Windows Active Directory. Soporta protocolos heredados como LDAP, Kerberos y NTLM, permitiendo a las organizaciones migrar o ejecutar aplicaciones más antiguas en la nube sin desplegar controladores de dominio locales. Este servicio también soporta Políticas de Grupo para gestión centralizada, haciéndolo adecuado para escenarios donde cargas de trabajo heredadas o basadas en AD necesitan coexistir con entornos modernos en la nube.
Nuevos usuarios
Indicar nombre de correo electrónico y dominio del inquilino seleccionado
Indicar nombre para mostrar
Indicar contraseña
Indicar propiedades (nombre, título del trabajo, información de contacto…)
El tipo de usuario predeterminado es “miembro”
Usuarios externos
Indicar correo electrónico para invitar y nombre para mostrar (puede ser un correo electrónico no de Microsoft)
Indicar propiedades
El tipo de usuario predeterminado es “Invitado”
Puedes revisarlos en https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions pero entre otras acciones, un miembro podrá:
Leer todos los usuarios, Grupos, Aplicaciones, Dispositivos, Roles, Suscripciones y sus propiedades públicas
Invitar Invitados (se puede desactivar)
Crear grupos de seguridad
Leer membresías de grupos no ocultos
Agregar invitados a grupos Propios
Crear nueva aplicación (se puede desactivar)
Agregar hasta 50 dispositivos a Azure (se puede desactivar)
Recuerda que para enumerar recursos de Azure, el usuario necesita un otorgamiento explícito del permiso.
Miembros (docs)
Registrar Aplicaciones: Predeterminado Sí
Restringir a usuarios no administradores de crear inquilinos: Predeterminado No
Crear grupos de seguridad: Predeterminado Sí
Restringir acceso al portal de administración de Microsoft Entra: Predeterminado No
Esto no restringe el acceso a la API del portal (solo web)
Permitir a los usuarios conectar cuentas de trabajo o escolares con LinkedIn: Predeterminado Sí
Mostrar mantener al usuario conectado: Predeterminado Sí
Restringir a los usuarios de recuperar la(s) clave(s) de BitLocker para sus dispositivos propios: Predeterminado No (ver en Configuración del Dispositivo)
Leer otros usuarios: Predeterminado Sí (a través de Microsoft Graph)
Invitados
Restricciones de acceso para usuarios invitados
Los usuarios invitados tienen el mismo acceso que los miembros otorga todos los permisos de usuario miembro a los usuarios invitados por defecto.
Los usuarios invitados tienen acceso limitado a propiedades y membresías de objetos de directorio (predeterminado) restringe el acceso de invitados solo a su propio perfil de usuario por defecto. El acceso a otros usuarios e información de grupos ya no está permitido.
El acceso de los usuarios invitados está restringido a propiedades y membresías de sus propios objetos de directorio es el más restrictivo.
Los invitados pueden invitar
Cualquiera en la organización puede invitar a usuarios invitados, incluidos invitados y no administradores (el más inclusivo) - Predeterminado
Los usuarios miembros y los usuarios asignados a roles de administrador específicos pueden invitar a usuarios invitados, incluidos invitados con permisos de miembro
Solo los usuarios asignados a roles de administrador específicos pueden invitar a usuarios invitados
Nadie en la organización puede invitar a usuarios invitados, incluidos administradores (el más restrictivo)
Los usuarios externos pueden salir: Predeterminado Verdadero
Permitir a los usuarios externos salir de la organización
Incluso si están restringidos por defecto, los usuarios (miembros e invitados) con permisos otorgados podrían realizar las acciones anteriores.
Hay 2 tipos de grupos:
Seguridad: Este tipo de grupo se utiliza para dar acceso a los miembros a aplicaciones, recursos y asignar licencias. Los usuarios, dispositivos, principales de servicio y otros grupos pueden ser miembros.
Microsoft 365: Este tipo de grupo se utiliza para colaboración, dando acceso a los miembros a un buzón compartido, calendario, archivos, sitio de SharePoint, etc. Los miembros del grupo solo pueden ser usuarios.
Esto tendrá una dirección de correo electrónico con el dominio del inquilino de EntraID.
Hay 2 tipos de membresías:
Asignado: Permite agregar manualmente miembros específicos a un grupo.
Membresía dinámica: Gestiona automáticamente la membresía utilizando reglas, actualizando la inclusión del grupo cuando cambian los atributos de los miembros.
Un Principal de Servicio es una identidad creada para uso con aplicaciones, servicios alojados y herramientas automatizadas para acceder a recursos de Azure. Este acceso está restringido por los roles asignados al principal de servicio, dándote control sobre qué recursos pueden ser accedidos y a qué nivel. Por razones de seguridad, siempre se recomienda usar principales de servicio con herramientas automatizadas en lugar de permitirles iniciar sesión con una identidad de usuario.
Es posible iniciar sesión directamente como un principal de servicio generándole un secreto (contraseña), un certificado, o otorgando acceso federado a plataformas de terceros (por ejemplo, Github Actions) sobre él.
Si eliges autenticación por contraseña (por defecto), guarda la contraseña generada ya que no podrás acceder a ella nuevamente.
Si eliges autenticación por certificado, asegúrate de que la aplicación tendrá acceso sobre la clave privada.
Una Registración de Aplicación es una configuración que permite a una aplicación integrarse con Entra ID y realizar acciones.
ID de Aplicación (Client ID): Un identificador único para tu aplicación en Azure AD.
URIs de Redirección: URLs donde Azure AD envía respuestas de autenticación.
Certificados, Secretos y Credenciales Federadas: Es posible generar un secreto o un certificado para iniciar sesión como el principal de servicio de la aplicación, o para otorgar acceso federado a ella (por ejemplo, Github Actions).
Si se genera un certificado o secreto, es posible que una persona inicie sesión como el principal de servicio con herramientas CLI al conocer el ID de aplicación, el secreto o certificado y el inquilino (dominio o ID).
Permisos de API: Especifica qué recursos o APIs puede acceder la aplicación.
Configuraciones de Autenticación: Define los flujos de autenticación soportados por la aplicación (por ejemplo, OAuth2, OpenID Connect).
Principal de Servicio: Un principal de servicio se crea cuando se crea una Aplicación (si se hace desde la consola web) o cuando se instala en un nuevo inquilino.
El principal de servicio obtendrá todos los permisos solicitados con los que fue configurado.
Consentimiento del usuario para aplicaciones
No permitir el consentimiento del usuario
Se requerirá un administrador para todas las aplicaciones.
Permitir el consentimiento del usuario para aplicaciones de editores verificados, para permisos seleccionados (Recomendado)
Todos los usuarios pueden consentir permisos clasificados como "bajo impacto", para aplicaciones de editores verificados o aplicaciones registradas en esta organización.
Permisos de bajo impacto predeterminados (aunque necesitas aceptar para agregarlos como bajos):
User.Read - iniciar sesión y leer el perfil del usuario
offline_access - mantener acceso a datos a los que los usuarios le han dado acceso
openid - iniciar sesión a los usuarios
profile - ver el perfil básico del usuario
email - ver la dirección de correo electrónico del usuario
Permitir el consentimiento del usuario para aplicaciones (Predeterminado)
Todos los usuarios pueden consentir que cualquier aplicación acceda a los datos de la organización.
Solicitudes de consentimiento de administrador: Predeterminado No
Los usuarios pueden solicitar consentimiento de administrador para aplicaciones a las que no pueden consentir
Si Sí: Es posible indicar Usuarios, Grupos y Roles que pueden consentir solicitudes
Configura también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración
Las identidades administradas en Azure Active Directory ofrecen una solución para gestionar automáticamente la identidad de las aplicaciones. Estas identidades son utilizadas por las aplicaciones con el propósito de conectarse a recursos compatibles con la autenticación de Azure Active Directory (Azure AD). Esto permite eliminar la necesidad de codificar credenciales en la nube en el código, ya que la aplicación podrá contactar el servicio de metadatos para obtener un token válido para realizar acciones como la identidad administrada indicada en Azure.
Hay dos tipos de identidades administradas:
Asignadas por el sistema. Algunos servicios de Azure permiten habilitar una identidad administrada directamente en una instancia de servicio. Cuando habilitas una identidad administrada asignada por el sistema, se crea un principal de servicio en el inquilino de Entra ID confiado por la suscripción donde se encuentra el recurso. Cuando se elimina el recurso, Azure automáticamente elimina la identidad por ti.
Asignadas por el usuario. También es posible que los usuarios generen identidades administradas. Estas se crean dentro de un grupo de recursos dentro de una suscripción y se creará un principal de servicio en el EntraID confiado por la suscripción. Luego, puedes asignar la identidad administrada a una o más instancias de un servicio de Azure (múltiples recursos). Para identidades administradas asignadas por el usuario, la identidad se gestiona por separado de los recursos que la utilizan.
Las Identidades Administradas no generan credenciales eternas (como contraseñas o certificados) para acceder como el principal de servicio adjunto a ella.
Es solo una tabla en Azure para filtrar principales de servicio y verificar las aplicaciones que se les han asignado.
No es otro tipo de “aplicación”, no hay ningún objeto en Azure que sea una “Aplicación Empresarial”, es solo una abstracción para verificar los Principales de Servicio, Registraciones de Aplicaciones e identidades administradas.
Las unidades administrativas permiten dar permisos de un rol sobre una porción específica de una organización.
Ejemplo:
Escenario: Una empresa quiere que los administradores de TI regionales gestionen solo a los usuarios en su propia región.
Implementación:
Crear Unidades Administrativas para cada región (por ejemplo, "AU de América del Norte", "AU de Europa").
Población de AUs con usuarios de sus respectivas regiones.
Las AUs pueden contener usuarios, grupos o dispositivos
Las AUs soportan membresías dinámicas
Las AUs no pueden contener AUs
Asignar Roles de Administrador:
Otorgar el rol de "Administrador de Usuarios" al personal de TI regional, limitado a la AU de su región.
Resultado: Los administradores de TI regionales pueden gestionar cuentas de usuario dentro de su región sin afectar a otras regiones.
Para gestionar Entra ID hay algunos roles integrados que pueden ser asignados a principales de Entra ID para gestionar Entra ID
El rol más privilegiado es Administrador Global
En la descripción del rol es posible ver sus permisos granulares
Roles son asignados a principales en un alcance: principal -[HAS ROLE]->(scope)
Roles asignados a grupos son heredados por todos los miembros del grupo.
Dependiendo del alcance al que se asignó el rol, el rol podría ser heredado a otros recursos dentro del contenedor de alcance. Por ejemplo, si un usuario A tiene un rol en la suscripción, tendrá ese rol en todos los grupos de recursos dentro de la suscripción y en todos los recursos dentro del grupo de recursos.
Propietario |
| Todos los tipos de recursos |
Colaborador |
| Todos los tipos de recursos |
Lector | • Ver todos los recursos | Todos los tipos de recursos |
Administrador de Acceso de Usuario |
| Todos los tipos de recursos |
De la documentación: El control de acceso basado en roles de Azure (Azure RBAC) tiene varios roles integrados de Azure que puedes asignar a usuarios, grupos, principales de servicio y identidades administradas. Las asignaciones de roles son la forma en que controlas el acceso a los recursos de Azure. Si los roles integrados no satisfacen las necesidades específicas de tu organización, puedes crear tus propios roles personalizados de Azure.
Los roles integrados se aplican solo a los recursos para los que están destinados, por ejemplo, revisa estos 2 ejemplos de roles integrados sobre recursos de Computación:
Proporciona permiso al cofre de copia de seguridad para realizar copias de seguridad de disco. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Ver Máquinas Virtuales en el portal e iniciar sesión como un usuario regular. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
Estos roles también pueden ser asignados sobre contenedores lógicos (como grupos de gestión, suscripciones y grupos de recursos) y los principales afectados los tendrán sobre los recursos dentro de esos contenedores.
Encuentra aquí una lista con todos los roles integrados de Azure.
Encuentra aquí una lista con todos los roles integrados de Entra ID.
También es posible crear roles personalizados
Se crean dentro de un alcance, aunque un rol puede estar en varios alcances (grupos de gestión, suscripción y grupos de recursos)
Es posible configurar todos los permisos granulares que tendrá el rol personalizado
Es posible excluir permisos
Un principal con un permiso excluido no podrá usarlo incluso si el permiso se otorga en otro lugar
Es posible usar comodines
El formato utilizado es un JSON
actions son para controlar acciones sobre el recurso
dataActions son permisos sobre los datos dentro del objeto
Ejemplo de JSON de permisos para un rol personalizado:
Para que un principal tenga acceso a un recurso, necesita que se le otorgue un rol explícito (de cualquier manera) que le otorgue ese permiso.
Una asignación de rol de denegación explícita tiene prioridad sobre el rol que otorga el permiso.
El Administrador Global es un rol de Entra ID que otorga control total sobre el inquilino de Entra ID. Sin embargo, no otorga permisos sobre los recursos de Azure por defecto.
Los usuarios con el rol de Administrador Global tienen la capacidad de 'elevar' a Administrador de Acceso de Usuario en el Grupo de Gestión Raíz de Azure. Así que los Administradores Globales pueden gestionar el acceso en todas las suscripciones y grupos de gestión de Azure. Esta elevación se puede hacer al final de la página: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Las Políticas de Azure son reglas que ayudan a las organizaciones a asegurar que sus recursos cumplan con estándares específicos y requisitos de cumplimiento. Permiten hacer cumplir o auditar configuraciones en recursos de Azure. Por ejemplo, puedes prevenir la creación de máquinas virtuales en una región no autorizada o asegurar que todos los recursos tengan etiquetas específicas para su seguimiento.
Las Políticas de Azure son proactivas: pueden detener la creación o modificación de recursos no conformes. También son reactivas, permitiéndote encontrar y corregir recursos no conformes existentes.
Definición de Política: Una regla, escrita en JSON, que especifica lo que está permitido o requerido.
Asignación de Política: La aplicación de una política a un alcance específico (por ejemplo, suscripción, grupo de recursos).
Iniciativas: Una colección de políticas agrupadas para una aplicación más amplia.
Efecto: Especifica lo que sucede cuando se activa la política (por ejemplo, "Denegar", "Auditar" o "Agregar").
Algunos ejemplos:
Asegurando el Cumplimiento con Regiones Específicas de Azure: Esta política asegura que todos los recursos se desplieguen en regiones específicas de Azure. Por ejemplo, una empresa podría querer asegurar que todos sus datos se almacenen en Europa para cumplir con el GDPR.
Haciendo Cumplir Normas de Nomenclatura: Las políticas pueden hacer cumplir convenciones de nomenclatura para los recursos de Azure. Esto ayuda a organizar e identificar fácilmente los recursos según sus nombres, lo cual es útil en entornos grandes.
Restringiendo Ciertos Tipos de Recursos: Esta política puede restringir la creación de ciertos tipos de recursos. Por ejemplo, se podría establecer una política para prevenir la creación de tipos de recursos costosos, como ciertos tamaños de VM, para controlar costos.
Haciendo Cumplir Políticas de Etiquetado: Las etiquetas son pares clave-valor asociados con recursos de Azure utilizados para la gestión de recursos. Las políticas pueden hacer cumplir que ciertas etiquetas deben estar presentes, o tener valores específicos, para todos los recursos. Esto es útil para el seguimiento de costos, propiedad o categorización de recursos.
Limitando el Acceso Público a Recursos: Las políticas pueden hacer cumplir que ciertos recursos, como cuentas de almacenamiento o bases de datos, no tengan puntos finales públicos, asegurando que solo sean accesibles dentro de la red de la organización.
Aplicando Automáticamente Configuraciones de Seguridad: Las políticas pueden usarse para aplicar automáticamente configuraciones de seguridad a los recursos, como aplicar un grupo de seguridad de red específico a todas las VMs o asegurar que todas las cuentas de almacenamiento utilicen cifrado.
Ten en cuenta que las Políticas de Azure pueden adjuntarse a cualquier nivel de la jerarquía de Azure, pero se utilizan comúnmente en el grupo de gestión raíz o en otros grupos de gestión.
Ejemplo de política de Azure en json:
En Azure los permisos pueden ser asignados a cualquier parte de la jerarquía. Eso incluye grupos de administración, suscripciones, grupos de recursos y recursos individuales. Los permisos son heredados por los recursos contenidos de la entidad donde fueron asignados.
Esta estructura jerárquica permite una gestión eficiente y escalable de los permisos de acceso.
RBAC (control de acceso basado en roles) es lo que ya hemos visto en las secciones anteriores: Asignar un rol a un principal para otorgarle acceso sobre un recurso. Sin embargo, en algunos casos puede que desees proporcionar una gestión de acceso más granular o simplificar la gestión de cientos de asignaciones de roles.
Azure ABAC (control de acceso basado en atributos) se basa en Azure RBAC al agregar condiciones de asignación de roles basadas en atributos en el contexto de acciones específicas. Una condición de asignación de rol es un chequeo adicional que puedes agregar opcionalmente a tu asignación de rol para proporcionar un control de acceso más granular. Una condición filtra los permisos otorgados como parte de la definición de rol y la asignación de rol. Por ejemplo, puedes agregar una condición que requiera que un objeto tenga una etiqueta específica para leer el objeto. No puedes explícitamente negar acceso a recursos específicos usando condiciones.
La Gestión de Identidades Privilegiadas (PIM) en Azure es una herramienta que gestiona, controla y monitorea el acceso privilegiado en Azure Active Directory y Azure. Mejora la seguridad al proporcionar acceso privilegiado justo a tiempo y limitado en el tiempo, haciendo cumplir flujos de trabajo de aprobación y requiriendo autenticación adicional. Este enfoque minimiza el riesgo de acceso no autorizado al asegurar que los permisos elevados se otorguen solo cuando sea necesario y por un período específico.
Hay tres tipos de tokens utilizados en OIDC:
Tokens de Acceso: El cliente presenta este token al servidor de recursos para acceder a recursos. Solo se puede usar para una combinación específica de usuario, cliente y recurso y no puede ser revocado hasta su expiración - que es 1 hora por defecto.
Tokens de ID: El cliente recibe este token del servidor de autorización. Contiene información básica sobre el usuario. Está vinculado a una combinación específica de usuario y cliente.
Tokens de Actualización: Proporcionados al cliente con el token de acceso. Se utilizan para obtener nuevos tokens de acceso e ID. Está vinculado a una combinación específica de usuario y cliente y puede ser revocado. La expiración por defecto es 90 días para tokens de actualización inactivos y sin expiración para tokens activos.
La información para acceso condicional está almacenada dentro del JWT. Así que, si solicitas el token desde una dirección IP permitida, esa IP será almacenada en el token y luego puedes usar ese token desde una IP no permitida para acceder a los recursos.
Dependiendo de la acción que desees realizar, el "aud" del token de acceso debe estar autorizado para contactar la URL de la API que vas a contactar.
El comando az account get-access-token --resource-type [...] soporta los siguientes tipos y cada uno de ellos añadirá un "aud" específico en el token de acceso resultante:
Ten en cuenta que los siguientes son solo las APIs soportadas por az account get-access-token, pero hay más.
aad-graph (API de Gráfico de Azure Active Directory): Usado para acceder a la API de Gráfico de Azure AD (obsoleta), que permite a las aplicaciones leer y escribir datos de directorio en Azure Active Directory (Azure AD).
https://graph.windows.net/
arm (Azure Resource Manager): Usado para gestionar recursos de Azure a través de la API de Azure Resource Manager. Esto incluye operaciones como crear, actualizar y eliminar recursos como máquinas virtuales, cuentas de almacenamiento, y más.
https://management.core.windows.net/ o https://management.azure.com/
batch (Servicios de Azure Batch): Usado para acceder a Azure Batch, un servicio que permite aplicaciones de computación paralela y de alto rendimiento a gran escala de manera eficiente en la nube.
https://batch.core.windows.net/
data-lake (Almacenamiento de Azure Data Lake): Usado para interactuar con Azure Data Lake Storage Gen1, que es un servicio de almacenamiento y análisis de datos escalable.
https://datalake.azure.net/
media (Servicios de Medios de Azure): Usado para acceder a los Servicios de Medios de Azure, que proporcionan servicios de procesamiento y entrega de medios basados en la nube para contenido de video y audio.
https://rest.media.azure.net
ms-graph (API de Microsoft Graph): Usado para acceder a la API de Microsoft Graph, el punto de acceso unificado para los datos de servicios de Microsoft 365. Permite acceder a datos e información de servicios como Azure AD, Office 365, Movilidad Empresarial y servicios de Seguridad.
https://graph.microsoft.com
oss-rdbms (Bases de Datos Relacionales de Código Abierto de Azure): Usado para acceder a los servicios de base de datos de Azure para motores de bases de datos relacionales de código abierto como MySQL, PostgreSQL y MariaDB.
https://ossrdbms-aad.database.windows.net
Consulta la siguiente página para aprender diferentes formas de solicitar tokens de acceso e iniciar sesión con ellos:
Az - Entra ID (formerly AzureAD - AAD)Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
