Az - Basic Information
Jerarquía de Organización
Grupos de Administración
Si tu organización tiene muchas suscripciones de Azure, es posible que necesites una forma de gestionar eficientemente el acceso, las políticas y el cumplimiento para esas suscripciones. Los grupos de administración proporcionan un ámbito de gobierno por encima de las suscripciones.
Ten en cuenta que se pueden admitir 10,000 grupos de administración en un solo directorio y un árbol de grupos de administración puede admitir hasta seis niveles de profundidad.
Desde la documentación: A cada directorio se le asigna un grupo de administración de nivel superior único llamado raíz. El grupo de administración raíz está integrado en la jerarquía para que todos los grupos de administración y suscripciones se plieguen en él. Este grupo de administración raíz permite que se apliquen políticas globales y asignaciones de roles de Azure a nivel de directorio. El Administrador Global de Azure AD debe elevarse al rol de Administrador de Acceso de Usuario de este grupo raíz inicialmente. Después de elevar el acceso, el administrador puede asignar cualquier rol de Azure a otros usuarios o grupos del directorio para gestionar la jerarquía. Como administrador, puedes asignar tu propia cuenta como propietario de la raíz del grupo de administración.
El grupo de administración raíz no se puede mover ni eliminar, a diferencia de otros grupos de administración.
Los grupos de administración te brindan una gestión de nivel empresarial a escala, independientemente del tipo de suscripciones que puedas tener. Sin embargo, todas las suscripciones dentro de un solo grupo de administración deben confiar en el mismo inquilino de Azure Active Directory (Azure AD).
Suscripciones de Azure
En Azure, una suscripción sirve como un contenedor lógico para el propósito de aprovisionar recursos comerciales o técnicos. Este contenedor mantiene los detalles de los recursos como máquinas virtuales (VM), bases de datos, entre otros. Al crear un recurso de Azure, como una VM, se especifica la suscripción asociada a ella. Esta estructura facilita la delegación de acceso, utilizando mecanismos de control de acceso basados en roles.
Grupos de Recursos
Desde la documentación: 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 grupo. Generalmente, agrega recursos que comparten el mismo ciclo de vida al mismo grupo de recursos para poder implementar, actualizar y eliminarlos fácilmente como 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.
Unidades Administrativas
Desde la documentación: Las unidades administrativas te permiten subdividir tu organización en cualquier unidad que desees, y luego asignar administradores específicos que pueden gestionar solo los miembros de esa unidad. Por ejemplo, podrías utilizar unidades administrativas para delegar permisos a los administradores de cada escuela en una gran universidad, para que puedan controlar el acceso, gestionar usuarios y establecer políticas solo en la Escuela de Ingeniería.
Solo usuarios, grupos y dispositivos pueden ser miembros de una unidad administrativa.
Por lo tanto, una unidad administrativa contendrá algunos miembros y otros principales tendrán asignados permisos sobre esa unidad administrativa que pueden utilizar para gestionar los miembros de la unidad administrativa.
Azure vs Azure AD vs Azure AD Domain Services
Es importante tener en cuenta que Azure AD es un servicio dentro de Azure. Azure es la plataforma en la nube de Microsoft, mientras que Azure AD es un servicio de identidad empresarial en Azure. Además, Azure AD no es como Active Directory de Windows, es un servicio de identidad que funciona de una manera completamente diferente. Si deseas ejecutar un Controlador de Dominio en Azure para tu entorno de Active Directory de Windows, necesitas usar Azure AD Domain Services.
Principales
Azure admite diferentes tipos de principales:
Usuario: Una persona regular con credenciales para acceder.
Grupo: Un grupo de principales gestionados juntos. Los permisos concedidos a los grupos son heredados por sus miembros.
Principal de Servicio/Aplicaciones Empresariales: Es una identidad creada para usar 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 utilizar principales de servicio con herramientas automatizadas en lugar de permitirles iniciar sesión con una identidad de usuario.
Al crear un principal de servicio puedes elegir entre autenticación de contraseña o autenticación de certificado.
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.
Identidad Administrada (Credenciales de 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 conectar a recursos compatibles con la autenticación de Azure Active Directory (Azure AD). Al utilizar identidades administradas, las aplicaciones pueden asegurar tokens de Azure AD eliminando la necesidad de manejar credenciales directamente. Hay dos tipos de identidades administradas:
Asignada 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 una identidad en Azure AD. La identidad está vinculada al ciclo de vida de esa instancia de servicio. Cuando se elimina el recurso, Azure elimina automáticamente la identidad por ti. Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens a Azure AD.
Asignada por el usuario. También puedes crear una identidad administrada como un recurso independiente de Azure. Puedes crear una identidad administrada asignada por el usuario y asignarla 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.
Roles & Permissions
Roles are assigned to principals on a scope: principal -[HAS ROLE]->(scope)
Roles assigned to groups are inherited by all the members of the group.
Depending on the scope the role was assigned to, the role cold be inherited to other resources inside the scope container. For example, if a user A has a role on the subscription, he will have that role on all the resource groups inside the subscription and on all the resources inside the resource group.
Roles Clásicos
Propietario |
| Todos los tipos de recursos |
Contribuyente |
| 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
Desde la documentación: Control de acceso basado en roles de Azure (Azure RBAC) tiene varios roles integrados de Azure que puedes asignar a usuarios, grupos, identidades 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 cumplen con las necesidades específicas de tu organización, puedes crear tus propios roles personalizados de Azure.
Los roles integrados se aplican solo a los recursos para los que están destinados, por ejemplo, revisa estos 2 ejemplos de roles integrados sobre recursos de Cómputo:
Proporciona permiso para realizar copias de seguridad de disco en el almacén. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Ver máquinas virtuales en el portal e iniciar sesión como un usuario regular. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
Estos roles también se pueden asignar a contenedores lógicos (como grupos de administración, suscripciones y grupos de recursos) y los principios afectados los tendrán sobre los recursos dentro de esos contenedores.
Encuentra aquí una lista con todos los roles integrados de Azure.
Encuentra aquí una lista con todos los roles integrados de Azure AD.
Roles Personalizados
Azure también permite crear roles personalizados con los permisos que el usuario necesita.
Permiso Denegado
Para que un principal tenga acceso sobre un recurso, necesita que se le otorgue explícitamente un rol (de todos modos) concediéndole ese permiso.
Una asignación de rol de denegación explícita tiene precedencia sobre el rol que otorga el permiso.
Administrador Global
Los usuarios con el rol de Administrador Global tienen la capacidad de 'elevar' al rol de Administrador de acceso de usuario de Azure al grupo de administración raíz. Esto significa que un Administrador Global podrá gestionar el acceso a todas las suscripciones de Azure y grupos de administración. Esta elevación se puede realizar al final de la página: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Políticas de Azure
Las políticas de Azure son un conjunto de reglas y regulaciones en Microsoft Azure, un servicio de computación en la nube, que ayudan a gestionar y hacer cumplir los estándares organizativos y evaluar el cumplimiento a escala. Estas políticas hacen cumplir diferentes reglas sobre tus recursos de Azure, asegurando que esos recursos cumplan con los estándares corporativos y los acuerdos de nivel de servicio.
Las políticas de Azure son cruciales para la gobernanza y seguridad en la nube, ayudando a garantizar que los recursos se utilicen de manera adecuada y eficiente, y que cumplan con regulaciones externas y políticas internas. Algunos ejemplos:
Garantizar el cumplimiento con regiones específicas de Azure: Esta política asegura que todos los recursos se implementen 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.
Imponer estándares de nomenclatura: Las políticas pueden imponer 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.
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 evitar la creación de tipos de recursos costosos, como ciertos tamaños de VM, para controlar los costos.
Imponer 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 imponer 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.
Limitar el acceso público a los recursos: Las políticas pueden imponer 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.
Aplicar automáticamente configuraciones de seguridad: Las políticas se pueden utilizar 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 garantizar 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 administración raíz u otros grupos de administración.
Alcance de Permisos
En Azure, los permisos se pueden asignar a cualquier parte de la jerarquía. Esto incluye grupos de administració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 hemos visto anteriormente en las secciones anteriores: Asignar un rol a un principal para otorgarle acceso sobre un recurso. Sin embargo, en algunos casos es posible que desees proporcionar un control de acceso más detallado 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 roles es una verificación adicional que puedes agregar opcionalmente a tu asignación de roles para proporcionar un control de acceso más detallado. Una condición filtra los permisos otorgados como parte de la definición de roles y la asignación de roles. Por ejemplo, puedes agregar una condición que requiera que un objeto tenga una etiqueta específica para leer el objeto. No puedes denegar explícitamente el acceso a recursos específicos usando condiciones.
Permisos predeterminados de usuario
Un usuario básico tendrá algunos permisos predeterminados para enumerar algunas partes de AzureAD:
Leer todos los usuarios, Grupos, Aplicaciones, Dispositivos, Roles, Suscripciones y sus propiedades públicas
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)
Agregar hasta 50 dispositivos a Azure (se puede desactivar)
Puedes ver la lista completa de permisos predeterminados de usuarios en la documentación. Además, ten en cuenta que en esa lista también puedes ver la lista de permisos predeterminados de invitados.
Recuerda que para enumerar recursos de Azure, el usuario necesita una concesión explícita del permiso.
Gestión de Identidades Privilegiadas (PIM)
La Gestión de Identidades Privilegiadas (PIM) en Azure es una herramienta que gestiona, controla y supervisa el acceso privilegiado en Azure Active Directory y Azure. Mejora la seguridad al proporcionar acceso privilegiado just-in-time y por tiempo limitado, aplicando flujos de trabajo de aprobación y requiriendo autenticación adicional. Este enfoque minimiza el riesgo de acceso no autorizado al garantizar que los permisos elevados se otorgan solo cuando sea necesario y por una duración específica.
Tokens de Autenticación
Hay tres tipos de tokens utilizados en OIDC:
Tokens de Acceso: El cliente presenta este token al servidor de recursos para acceder a recursos. Solo se puede utilizar para una combinación específica de usuario, cliente y recurso y no se puede revocar hasta su vencimiento, que es de 1 hora por defecto. La detección es baja utilizando esto.
Tokens de ID: El cliente recibe este token del servidor de autorización. Contiene información básica sobre el usuario. Está vinculado a una combinación específica de usuario y cliente.
Tokens de Actualización: Se proporcionan al cliente con el token de acceso. Se utilizan para obtener nuevos tokens de acceso e ID. Está vinculado a una combinación específica de usuario y cliente y se puede revocar. El vencimiento por defecto es de 90 días para tokens de actualización inactivos y sin vencimiento para tokens activos.
La información para acceso condicional está almacenada dentro del JWT. Por lo tanto, si solicitas el token desde una dirección IP permitida, esa IP se almacenará en el token y luego podrás usar ese token desde una IP no permitida para acceder a los recursos.
Consulta la siguiente página para aprender diferentes formas de solicitar tokens de acceso e iniciar sesión con ellos:
pageAz - AzureAD (AAD)Los puntos finales de API más comunes son:
Administrador de Recursos de Azure (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, que está obsoleto, es graph.windows.net)
Referencias
Última actualización
