Az - Basic Information
Last updated
Last updated
Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica GCP Hacking: 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. Permite 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 consultarlos 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 a Invitados (se puede desactivar)
Crear grupos de seguridad
Leer membresías de grupos no ocultos
Agregar invitados a grupos de propiedad
Crear nuevas aplicaciones (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 el 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 de propiedad: 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 información de otros usuarios y 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 la 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 la autenticación por contraseña (por defecto), guarda la contraseña generada ya que no podrás acceder a ella nuevamente.
Si eliges la autenticación por certificado, asegúrate de que la aplicación tenga 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 para 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
Acceso total a todos los recursos
Puede gestionar el acceso para otros usuarios
Todos los tipos de recursos
Colaborador
Acceso total a todos los recursos
No puede gestionar el acceso
Todos los tipos de recursos
Lector
• Ver todos los recursos
Todos los tipos de recursos
Administrador de Acceso de Usuario
Ver todos los recursos
Puede gestionar el acceso para otros usuarios
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 Cómputo:
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 explícita de denegación 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 el 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:
Asegurar 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.
Hacer Cumplir Estándares 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.
Restringir 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.
Hacer 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.
Limitar 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.
Aplicar 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 gestió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 detallada 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 detallado. 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
