Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

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 administrados 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.
+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
 
@@ -80,11 +80,11 @@ Los Servicios de Dominio de Entra amplían las capacidades de Entra ID al ofrece
 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_)
+- Invitar a 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_)
+- Crear nuevas aplicaciones (_se puede desactivar_)
 - Agregar hasta 50 dispositivos a Azure (_se puede desactivar_)
 
 > [!NOTE]
@@ -149,7 +149,7 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
 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).
+1. Si se genera un **certificado** o **secreto**, es posible que una persona **inicie sesión como el principal de servicio** con herramientas CLI conociendo 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.
@@ -157,7 +157,7 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
 
 ### Permisos de Consentimiento Predeterminados
 
-**Consentimiento del usuario para aplicaciones**
+**Consentimiento de usuario para aplicaciones**
 
 - **No permitir el consentimiento del usuario**
 - Se requerirá un administrador para todas las aplicaciones.
@@ -170,13 +170,13 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
 - 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.
+- 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
-- Configura también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración 
+- Configurar también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración 
 
 ### **Identidad Administrada (Metadatos)**
 
@@ -184,8 +184,8 @@ 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 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**.
+- **Asignadas por el sistema**. Algunos servicios de Azure te 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.
 
@@ -221,7 +221,7 @@ Ejemplo:
 
 ## Roles y Permisos
 
-**Los roles** son **asignados** a **principales** en un **alcance**: `principal -[HAS ROLE]->(scope)`
+**Los roles** son **asignados** a **principales** en un **alcance**: `principal -[TIENE ROL]->(alcance)`
 
 **Los roles** asignados a **grupos** son **heredados** por todos los **miembros** del grupo.
 
@@ -237,9 +237,9 @@ 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**:
+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 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
@@ -295,7 +295,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 explícita de **denegación tiene prioridad** sobre el rol que otorga el permiso.
+- Una **asignación de rol 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,14 +303,14 @@ 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**. Así que 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 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.**\
 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
 
-**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 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.
 
@@ -323,12 +323,12 @@ Las Políticas de Azure son **proactivas**: pueden detener la creación o modifi
 
 **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 asegurar 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.
+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 asegurar que todas las cuentas de almacenamiento utilicen cifrado.
+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.
 
 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.
 
@@ -352,7 +352,7 @@ Ejemplo de política de Azure en json:
 ```
 ### 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.
+En Azure **los permisos se pueden asignar 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.