Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -58,7 +58,7 @@ Entra ID es un servicio de **gestión de identidad y acceso basado en la nube**
 
 ### 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.
+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
 
@@ -83,7 +83,7 @@ Puedes consultarlos en [https://learn.microsoft.com/en-us/entra/fundamentals/use
 - Invitar Invitados (_se puede desactivar_)
 - Crear grupos de seguridad
 - Leer membresías de grupos no ocultos
-- Agregar invitados a grupos de propiedad
+- Agregar invitados a grupos de los que es propietario
 - Crear nueva aplicación (_se puede desactivar_)
 - Agregar hasta 50 dispositivos a Azure (_se puede desactivar_)
 
@@ -140,9 +140,9 @@ Es posible **iniciar sesión directamente como un principal de servicio** gener
 - 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**.
 
-### Registraciones de Aplicaciones
+### Registros 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.
+Un **Registro de Aplicación** es una configuración que permite a una aplicación integrarse con Entra ID y realizar acciones.
 
 #### Componentes Clave:
 
@@ -184,20 +184,20 @@ Las identidades administradas en Azure Active Directory ofrecen una solución pa
 
 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 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.
+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.
+**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, Registros de Aplicaciones e identidades administradas.
 
 ### Unidades Administrativas
 
-Las unidades administrativas permiten **otorgar permisos de un rol sobre una porción específica de una organización**.
+Las unidades administrativas permiten **dar permisos de un rol sobre una porción específica de una organización**.
 
 Ejemplo:
 
@@ -214,7 +214,7 @@ Ejemplo:
 
 ### Roles de Entra ID
 
-- Para gestionar Entra ID hay algunos **roles integrados** que se pueden asignar a los principales de Entra ID para gestionar 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**
@@ -227,7 +227,7 @@ Ejemplo:
 
 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**
+### Roles Clásicos
 
 | **Propietario**               | <ul><li>Acceso total a todos los recursos</li><li>Puede gestionar el acceso para otros usuarios</li></ul> | Todos los tipos de recursos |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
@@ -237,7 +237,7 @@ Dependiendo del alcance al que se asignó el rol, el **rol** podría ser **hered
 
 ### 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 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**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[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**:
 
@@ -259,8 +259,10 @@ Estos roles también pueden **ser asignados sobre contenedores lógicos** (como
 - 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
+- `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:
 ```json
@@ -295,7 +297,7 @@ Ejemplo de JSON de permisos para un rol personalizado:
 ### 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 rol de denegación explícita tiene prioridad** sobre el rol que otorga el permiso.
+- Una **asignación de denegación explícita tiene prioridad** sobre el rol que otorga el permiso.
 
 <figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
 
@@ -303,36 +305,53 @@ Ejemplo de JSON de permisos para un rol personalizado:
 
 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**. Por lo tanto, los Administradores Globales pueden gestionar el acceso en **todas las suscripciones y grupos de gestión de Azure.**\
+Los usuarios con el rol de Administrador Global tienen la capacidad de '**elevar' a rol de Administrador de Acceso de Usuario 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)
 
 <figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
 
-### Políticas de Azure
+### Condiciones de Asignaciones y MFA
 
-**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.
+Es posible **establecer algunas condiciones cuando se asigna un rol** a un principal. Una condición común a agregar es requerir MFA para acceder a algunos permisos de rol:
+```bash
+az role assignment create \
+--assignee <user-or-service-principal-id> \
+--role <custom-role-id-or-name> \
+--scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \
+--condition "PrincipalClaims['amr'] contains 'mfa'" \
+--condition-version 2.0
+```
+### Deny Assignments
 
-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.
+Al igual que las asignaciones de roles, **deny assignments** se utilizan para **controlar el acceso a los recursos de Azure**. Sin embargo, **deny assignments** 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. **Deny assignments** tienen prioridad sobre **role assignments**, 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 deny assignment, la deny assignment tendrá prioridad.
 
-#### **Conceptos Clave**
+Al igual que las asignaciones de roles, **deny assignments** se aplican sobre algún alcance que indica los principales afectados y los permisos que se están negando. Además, en el caso de deny assignments, es posible **evitar que la negación sea heredada** por recursos hijos.
 
-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 alcance 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").
+### Azure Policies
+
+**Azure Policies** 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 el seguimiento.
+
+Las Azure Policies 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.
+
+#### **Key Concepts**
+
+1. **Policy Definition**: Una regla, escrita en JSON, que especifica lo que está permitido o requerido.
+2. **Policy Assignment**: La aplicación de una política a un alcance específico (por ejemplo, suscripción, grupo de recursos).
+3. **Initiatives**: Una colección de políticas agrupadas para una aplicación más amplia.
+4. **Effect**: Especifica qué sucede cuando se activa la política (por ejemplo, "Deny", "Audit" o "Append").
 
 **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 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 VMs o asegurarse de que todas las cuentas de almacenamiento utilicen cifrado.
+1. **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 asegurarse de que todos sus datos se almacenen en Europa para cumplir con el GDPR.
+2. **Haciendo 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. **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.
+4. **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.
+5. **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.
+6. **Aplicando Automáticamente Configuraciones de Seguridad**: Las políticas pueden ser utilizadas 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 asegurarse de 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.
+Ten en cuenta que las Azure Policies pueden ser adjuntadas a cualquier nivel de la jerarquía de Azure, pero se utilizan **comúnmente en el grupo de administración raíz** o en otros grupos de administración.
 
-Ejemplo de política de Azure en json:
+Ejemplo de json de política de Azure:
 ```json
 {
 "policyRule": {