mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 13:13:06 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
Translator
@@ -54,11 +54,11 @@ Azure es la **plataforma de computación en la nube integral de Microsoft, que o
|
||||
|
||||
### 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. Potencia 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.
|
||||
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.
|
||||
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
|
||||
|
||||
@@ -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 los que es propietario
|
||||
- Agregar invitados a grupos de propiedad
|
||||
- Crear nueva aplicación (_se puede desactivar_)
|
||||
- Agregar hasta 50 dispositivos a Azure (_se puede desactivar_)
|
||||
|
||||
@@ -94,7 +94,7 @@ Puedes consultarlos en [https://learn.microsoft.com/en-us/entra/fundamentals/use
|
||||
|
||||
- **Miembros (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
|
||||
- Registrar Aplicaciones: Predeterminado **Sí**
|
||||
- Restringir a los usuarios no administradores de crear inquilinos: Predeterminado **No**
|
||||
- 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)
|
||||
@@ -137,12 +137,12 @@ Un **Principal de Servicio** es una **identidad** creada para **uso** con **apli
|
||||
|
||||
Es posible **iniciar sesión directamente como un principal de servicio** generándole un **secreto** (contraseña), un **certificado**, o otorgando acceso **federado** a plataformas de terceros (por ejemplo, Github Actions) sobre él.
|
||||
|
||||
- Si eliges la autenticación por **contraseña** (por defecto), **guarda la contraseña generada** ya que no podrás acceder a ella nuevamente.
|
||||
- Si eliges la autenticación por certificado, asegúrate de que la **aplicación tenga acceso sobre la clave privada**.
|
||||
- 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**.
|
||||
|
||||
### Registros de Aplicaciones
|
||||
### Registraciones de Aplicaciones
|
||||
|
||||
Un **Registro de Aplicación** es una configuración que permite a una aplicación integrarse con Entra ID y realizar acciones.
|
||||
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:
|
||||
|
||||
@@ -187,13 +187,13 @@ 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 ellas.
|
||||
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, Registros 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, Registraciones de Aplicaciones e identidades administradas.
|
||||
|
||||
### Unidades Administrativas
|
||||
|
||||
@@ -264,7 +264,7 @@ Estos roles también pueden **ser asignados sobre contenedores lógicos** (como
|
||||
- `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:
|
||||
Ejemplo de permisos JSON para un rol personalizado:
|
||||
```json
|
||||
{
|
||||
"properties": {
|
||||
@@ -305,53 +305,46 @@ 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 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.**\
|
||||
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)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Condiciones de Asignaciones y MFA
|
||||
|
||||
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
|
||||
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**.
|
||||
|
||||
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.
|
||||
### Asignaciones de Denegación
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### Azure Policies
|
||||
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.
|
||||
|
||||
**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.
|
||||
### Políticas de Azure
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
#### **Key Concepts**
|
||||
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.
|
||||
|
||||
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").
|
||||
#### **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. **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.
|
||||
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 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.
|
||||
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 json de política de Azure:
|
||||
Ejemplo de política de Azure en json:
|
||||
```json
|
||||
{
|
||||
"policyRule": {
|
||||
|
||||
Reference in New Issue
Block a user