mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-01 07:25:51 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
Translator
@@ -21,7 +21,7 @@
|
||||
|
||||
### Suscripciones de Azure
|
||||
|
||||
- Es otro **contenedor lógico donde se pueden ejecutar recursos** (VMs, DBs…) y se facturará.
|
||||
- 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.
|
||||
@@ -32,7 +32,7 @@
|
||||
|
||||
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.
|
||||
|
||||
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
<figure><img src="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
|
||||
### IDs de Recursos de Azure
|
||||
|
||||
@@ -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 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
|
||||
|
||||
@@ -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 a Invitados (_se puede desactivar_)
|
||||
- Invitar Invitados (_se puede desactivar_)
|
||||
- Crear grupos de seguridad
|
||||
- Leer membresías de grupos no ocultos
|
||||
- Agregar invitados a grupos de propiedad
|
||||
- Crear nuevas aplicaciones (_se puede desactivar_)
|
||||
- Crear nueva aplicación (_se puede desactivar_)
|
||||
- Agregar hasta 50 dispositivos a Azure (_se puede desactivar_)
|
||||
|
||||
> [!NOTE]
|
||||
@@ -103,20 +103,20 @@ Puedes consultarlos en [https://learn.microsoft.com/en-us/entra/fundamentals/use
|
||||
- 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**
|
||||
- **Restricciones de acceso para usuarios invitados**
|
||||
- **Los usuarios invitados tienen el mismo acceso que los miembros** otorga todos los permisos de usuario miembro a los usuarios invitados por defecto.
|
||||
- **Los usuarios invitados tienen acceso limitado a propiedades y membresías de objetos de directorio (predeterminado)** restringe el acceso de 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 el más restrictivo.
|
||||
- **Los invitados pueden invitar**
|
||||
- **Cualquiera en la organización puede invitar a usuarios invitados, incluidos invitados y no administradores (el más inclusivo) - Predeterminado**
|
||||
- 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 (el más restrictivo)**
|
||||
- **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é restringido por defecto, los usuarios (miembros e invitados) con permisos otorgados podrían realizar las acciones anteriores.
|
||||
> Aunque estén restringidos por defecto, los usuarios (miembros e invitados) con permisos otorgados podrían realizar las acciones anteriores.
|
||||
|
||||
### **Grupos**
|
||||
|
||||
@@ -128,7 +128,7 @@ Hay **2 tipos de grupos**:
|
||||
|
||||
Hay **2 tipos de membresías**:
|
||||
|
||||
- **Asignado**: Permite agregar manualmente miembros específicos a un grupo.
|
||||
- **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**
|
||||
@@ -148,8 +148,8 @@ 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 conociendo el **ID de aplicación**, el **secreto** o **certificado** y el **inquilino** (dominio o ID).
|
||||
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.
|
||||
@@ -157,7 +157,7 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
|
||||
|
||||
### Permisos de Consentimiento Predeterminados
|
||||
|
||||
**Consentimiento de usuario para aplicaciones**
|
||||
**Consentimiento del 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 cualquier aplicación para acceder a los datos de la organización.
|
||||
- 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 
|
||||
- Configurar también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración
|
||||
|
||||
### **Identidad Administrada (Metadatos)**
|
||||
|
||||
@@ -184,7 +184,7 @@ 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 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 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.
|
||||
@@ -214,22 +214,22 @@ Ejemplo:
|
||||
|
||||
### 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
|
||||
- Para gestionar Entra ID hay algunos **roles integrados** que se pueden asignar a los 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
|
||||
|
||||
**Los roles** son **asignados** a **principales** en un **alcance**: `principal -[TIENE ROL]->(alcance)`
|
||||
**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.
|
||||
**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** | <ul><li>Acceso total a todos los recursos</li><li>Puede gestionar el acceso para otros usuarios</li></ul> | Todos los tipos de recursos |
|
||||
| **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 |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **Colaborador** | <ul><li>Acceso total a todos los recursos</li><li>No puede gestionar el acceso</li></ul> | Todos los tipos de recursos |
|
||||
| **Lector** | • Ver todos los recursos | Todos los tipos de recursos |
|
||||
@@ -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 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)**.**
|
||||
[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)**.**
|
||||
|
||||
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 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
@@ -352,7 +352,7 @@ Ejemplo de política de Azure en json:
|
||||
```
|
||||
### Herencia de Permisos
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user