# Az - Información Básica {{#include ../../../banners/hacktricks-training.md}} ## 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:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 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 Active Directory de Windows**. 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](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**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)** - 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: 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**: - **Asignada**: 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). 1. 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). 4. **Permisos de API:** Especifica qué recursos o APIs puede acceder la aplicación. 5. **Configuraciones de Autenticación:** Define los flujos de autenticación soportados por la aplicación (por ejemplo, OAuth2, OpenID Connect). 6. **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. 1. 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, 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 - 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 las 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. ### 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 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](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference) - El rol más privilegiado es **Administrador Global** - En la descripción del rol es posible ver sus **permisos granulares** ## Roles y Permisos **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 Clásicos | **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 | ### Roles Integrados [De la documentación: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[El control de acceso basado en roles de Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) tiene varios **roles integrados de Azure** que puedes **asignar** a **usuarios, grupos, principales de servicio e 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**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.** 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 Disco](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Proporciona 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 Virtual](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 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**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles). - Encuentra aquí una lista con [**todos los roles integrados de Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference). ### Roles Personalizados - También es posible crear [**roles personalizados**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) - 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 permisos JSON para un rol personalizado: ```json { "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**. 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](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
### Condiciones de Asignaciones y MFA Según **[la documentación](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: 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 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. 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 los 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: ```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 - [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview) - [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions) - [https://abouttmc.com/glossary/azure-subscription/#:\~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.](https://abouttmc.com/glossary/azure-subscription/) - [https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource) - [https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration](https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration) {{#include ../../../banners/hacktricks-training.md}}