Az - Información Básica

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Jerarquía de Organización

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

Grupos de Gestión

  • 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.

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

Suscripciones de Azure

  • Es otro contenedor lógico donde se pueden ejecutar y facturar recursos (VMs, DBs…).
  • 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.

Grupos de Recursos

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.

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

IDs de Recursos de Azure

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 vs Entra ID vs Servicios de Dominio de Azure AD

Azure

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 (anteriormente Azure Active Directory)

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.

Servicios de Dominio de Entra (anteriormente Azure AD DS)

Los Servicios de Dominio de Entra amplían 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 la Política de Grupo para la 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.

Principales de Entra ID

Usuarios

  • 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”

Permisos Predeterminados para Miembros e Invitados

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 Invitados (se puede desactivar)
  • Crear grupos de seguridad
  • Leer membresías de grupos no ocultos
  • Agregar invitados a grupos de propiedad
  • Crear nueva aplicación (se puede desactivar)
  • Agregar hasta 50 dispositivos a Azure (se puede desactivar)

Note

Recuerda que para enumerar recursos de Azure, el usuario necesita un otorgamiento explícito del permiso.

Permisos Configurables Predeterminados para Usuarios

  • Miembros (docs)
  • Registrar Aplicaciones: Predeterminado Sí
  • Restringir a los 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: Predeterminado No (ver en Configuración de Dispositivos)
  • Leer otros usuarios: Predeterminado Sí (a través de Microsoft Graph)
  • Invitados
  • Opciones de restricciones de acceso para usuarios invitados:
  • Los usuarios invitados tienen el mismo acceso que los miembros.
  • Los usuarios invitados tienen acceso limitado a propiedades y membresías de objetos de directorio (predeterminado). Esto restringe el acceso de los 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 la más restrictiva.
  • Opciones de invitación de invitados:
  • Cualquiera en la organización puede invitar a usuarios invitados, incluidos invitados y no administradores (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 (más restrictivo)
  • Los usuarios externos pueden salir: Predeterminado Verdadero
  • Permitir a los usuarios externos salir de la organización

Tip

Aunque estén restringidos por defecto, los usuarios (miembros e invitados) con permisos otorgados podrían realizar las acciones anteriores.

Grupos

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.

Principales de Servicio

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 tenga acceso sobre la clave privada.

Registraciones de Aplicaciones

Una Registración de Aplicación es una configuración que permite a una aplicación integrarse con Entra ID y realizar acciones.

Componentes Clave:

  1. ID de Aplicación (Client ID): Un identificador único para tu aplicación en Azure AD.
  2. URIs de Redirección: URLs donde Azure AD envía respuestas de autenticación.
  3. 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).
  4. 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).
  5. Permisos de API: Especifica qué recursos o APIs puede acceder la aplicación.
  6. Configuraciones de Autenticación: Define los flujos de autenticación soportados por la aplicación (por ejemplo, OAuth2, OpenID Connect).
  7. 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.
  8. El principal de servicio obtendrá todos los permisos solicitados con los que fue configurado.

Permisos de Consentimiento Predeterminados

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, aplicaciones internas y aplicaciones que solo solicitan permisos seleccionados (Recomendado)
  • Todos los usuarios pueden consentir aplicaciones que solo solicitan permisos clasificados como “bajo impacto”, aplicaciones de editores verificados y aplicaciones registradas en el inquilino.
  • 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 cualquier aplicación para acceder 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
  • Configurar también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración

Identidad Administrada (Metadatos)

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 ellas.

Aplicaciones Empresariales

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.

Unidades Administrativas

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.

Roles y Permisos de Entra ID

  • Para gestionar Entra ID hay algunos roles integrados que pueden ser asignados a principales de Entra ID para gestionar Entra ID
  • Consulta los roles en https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
  • Los roles marcados como PRIVILEGIADOS por EntraID deben ser asignados con precaución porque, como explica Microsoft en la documentación: Las asignaciones de roles privilegiados pueden llevar a una elevación de privilegios si no se utilizan de manera segura y con intención.
  • El rol más privilegiado es Administrador Global
  • Los roles agrupan permisos granulares y se pueden encontrar en sus descripciones.
  • Es posible crear roles personalizados con los permisos deseados. Aunque por alguna razón no todos los permisos granulares están disponibles para que los administradores creen roles personalizados.
  • Los roles en Entra ID son completamente independientes de los roles en Azure. La única relación es que los principales con el rol Administrador Global en Entra ID pueden elevarse al rol de Administrador de Acceso de Usuario en Azure.
  • No es posible usar comodines en los roles de Entra ID.

Roles y Permisos de Azure

  • Roles son asignados a principales en un alcance: principal -[TIENE ROL]->(alcance)
  • 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.

Roles Integrados

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, consulta estos 2 ejemplos de roles integrados sobre recursos de Cómputo:

Lector de Copia de Seguridad de DiscoProporciona permiso al cofre de copia de seguridad para realizar copias de seguridad de disco.3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
Inicio de Sesión de Usuario de Máquina VirtualVer 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.

Roles Personalizados

  • 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 se refiere a permisos para operaciones de gestión sobre recursos, como crear, actualizar o eliminar definiciones y configuraciones de recursos.
  • dataActions son permisos para operaciones de datos dentro del recurso, permitiéndote leer, escribir o eliminar los datos reales contenidos en el recurso.
  • notActions y notDataActions se utilizan para excluir permisos específicos del rol. Sin embargo, no los niegan, si un rol diferente los otorga, el principal los tendrá.
  • assignableScopes es un array de alcances donde se puede asignar el rol (como grupos de gestión, suscripciones o grupos de recursos).

Ejemplo de JSON de permisos para un rol personalizado:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

Orden de permisos

  • 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 denegación explícita tiene prioridad sobre el rol que otorga el permiso.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

Administrador Global

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 rol de Azure en el Grupo de Gestión Raíz. Por lo tanto, 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

Condiciones de Asignaciones y MFA

Según la documentación: Actualmente, se pueden agregar condiciones a las asignaciones de roles integrados o personalizados que tengan acciones de datos de almacenamiento de blobs o acciones de datos de almacenamiento de colas.

Asignaciones de Denegación

Al igual que las asignaciones de roles, las asignaciones de denegación se utilizan para controlar el acceso a los recursos de Azure. Sin embargo, las asignaciones de denegación se utilizan para negar explícitamente el acceso a un recurso, incluso si a un usuario se le ha otorgado acceso a través de una asignación de rol. Las asignaciones de denegación tienen prioridad sobre las asignaciones de rol, lo que significa que si a un usuario se le otorga acceso a través de una asignación de rol pero también se le niega explícitamente el acceso a través de una asignación de denegación, la asignación de denegación tendrá prioridad.

Al igual que las asignaciones de rol, las asignaciones de denegación se aplican sobre algún ámbito que indica los principales afectados y los permisos que se están negando. Además, en el caso de las asignaciones de denegación, es posible evitar que la denegación sea heredada por recursos hijos.

Políticas de Azure

Las Políticas de Azure son reglas que ayudan a las organizaciones a garantizar 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 asegurarte de 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.

Conceptos Clave

  1. Definición de Política: Una regla, escrita en JSON, que especifica lo que está permitido o requerido.
  2. Asignación de Política: La aplicación de una política a un ámbito específico (por ejemplo, suscripción, grupo de recursos).
  3. Iniciativas: Una colección de políticas agrupadas para una aplicación más amplia.
  4. Efecto: Especifica lo que sucede cuando se activa la política (por ejemplo, “Denegar”, “Auditar” o “Agregar”).

Algunos ejemplos:

  1. 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 asegurarse de que todos sus datos se almacenen en Europa para cumplir con el GDPR.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 VM o asegurarse de que todas las cuentas de almacenamiento utilicen cifrado.

Ten en cuenta que las Políticas de Azure se pueden adjuntar 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:

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

Herencia de Permisos

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.

Azure RBAC vs ABAC

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.

Referencias

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks