Az - Basic Information
Organization Hierarchy
Management Groups
Si tu organización tiene muchas suscripciones de Azure, es posible que necesites una forma de gestionar eficientemente el acceso, políticas y cumplimiento para esas suscripciones. Los grupos de administración proporcionan un ámbito de gobernanza por encima de las suscripciones.
Ten en cuenta que se pueden soportar 10,000 grupos de administración en un solo directorio y un árbol de grupos de administración puede soportar hasta seis niveles de profundidad.
De la documentación: A cada directorio se le asigna un único grupo de administración de nivel superior llamado grupo de administración 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 a é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 necesita elevarse a sí mismo 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 del grupo de administración raíz.
El grupo de administración raíz no puede ser movido o eliminado, a diferencia de otros grupos de administración.
Los grupos de administración te brindan una gestión a nivel empresarial a escala, sin importar el 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).
Azure Subscriptions
En Azure, una suscripción sirve como un contenedor lógico con el propósito de provisionar recursos empresariales o técnicos. Este contenedor mantiene los detalles de los recursos como máquinas virtuales (VMs), bases de datos, entre otros. Al crear un recurso de Azure, como una VM, se especifica la suscripción asociada con él. Esta estructura facilita la delegación de acceso, utilizando mecanismos de control de acceso basado en roles.
Resource Groups
De la documentación: Un grupo de recursos es un contenedor que contiene 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 un grupo. Generalmente, agrega recursos que comparten el mismo ciclo de vida al mismo grupo de recursos para que puedas desplegarlos, actualizarlos y eliminarlos fácilmente como un 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, también se eliminan todos los recursos dentro de él.
Administrative Units
De la documentación: Las unidades administrativas te permiten subdividir tu organización en cualquier unidad que desees, y luego asignar administradores específicos que puedan gestionar solo a los miembros de esa unidad. Por ejemplo, podrías usar 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 se les asignarán permisos sobre esa unidad administrativa que pueden usar para gestionar a los miembros de la unidad administrativa.
Azure vs Azure AD vs Azure AD Domain Services
Es importante notar 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 Windows Active Directory, 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 Windows Active Directory, necesitas usar Azure AD Domain Services.
Principals
Azure soporta diferentes tipos de principales:
User: Una persona regular con credenciales para acceder.
Group: Un grupo de principales gestionados juntos. Permisos otorgados a grupos son heredados por sus miembros.
Service Principal/Enterprise Applications: Es una identidad creada para uso 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 usar 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 por contraseña o autenticación por certificado.
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 tendrá acceso a la clave privada.
Managed Identity (Metadata Creds): 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 aplicaciones para conectarse 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 sin necesidad de manejar credenciales directamente. 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 una identidad en Azure AD. La identidad está vinculada al ciclo de vida de esa instancia de servicio. Cuando el recurso es eliminado, Azure elimina automáticamente la identidad por ti. Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens de Azure AD.
Asignadas 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 identidades administradas asignadas por el usuario, la identidad se gestiona por separado de los recursos que la utilizan.
Roles & Permissions
Roles son asignados a principales en un ámbito: principal -[HAS ROLE]->(scope)
Roles asignados a grupos son heredados por todos los miembros del grupo.
Dependiendo del ámbito al que se asignó el rol, el rol podría ser heredado a otros recursos dentro del contenedor del ámbito. 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.
Classic Roles
Owner |
| Todos los tipos de recursos |
Contributor |
| Todos los tipos de recursos |
Reader | • Ver todos los recursos | Todos los tipos de recursos |
User Access Administrator |
| Todos los tipos de recursos |
Built-In roles
De la documentación: Azure role-based access control (Azure RBAC) 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 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 Compute:
Proporciona permiso al vault de backup para realizar copias de seguridad de discos. | 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 pueden asignarse sobre contenedores lógicos (como grupos de administración, suscripciones y grupos de recursos) y los principales 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.
Custom Roles
Azure también permite crear roles personalizados con los permisos que el usuario necesita.
Permission Denied
Para que un principal tenga algún acceso sobre un recurso necesita que se le otorgue explícitamente un rol (de cualquier manera) otorgándole ese permiso.
Una asignación de rol de denegación explícita tiene prioridad sobre el rol que otorga el permiso.
Global Administrator
Los usuarios con el rol de Administrador Global tienen la capacidad de 'elevarse' al rol de Administrador de Acceso de Usuario de Azure en el grupo de administración raíz. Esto significa que un Administrador Global podrá gestionar el acceso a todas las suscripciones y grupos de administració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
Azure Policies
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 organizacionales y a evaluar el cumplimiento a gran escala. Estas políticas imponen diferentes reglas sobre tus recursos de Azure, asegurando que esos recursos se mantengan en conformidad 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 asegurar que los recursos se utilicen de manera adecuada y eficiente, y que cumplan con las regulaciones externas y políticas internas. Algunos ejemplos:
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.
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 basados en 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 prevenir 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 Recursos: Las políticas pueden asegurar 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 Configuraciones de Seguridad Automáticamente: Las políticas pueden usarse para aplicar configuraciones de seguridad automáticamente 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 usen cifrado.
Ten en cuenta que las Políticas de Azure pueden adjuntarse a cualquier nivel de la jerarquía de Azure, pero comúnmente se usan en el grupo de administración raíz o en otros grupos de administración.
Permissions Scope
En Azure los permisos pueden asignarse a cualquier parte de la jerarquía. Eso 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 ya hemos visto en las secciones anteriores: Asignar un rol a un principal para otorgarle acceso sobre un recurso. Sin embargo, en algunos casos podrías querer proporcionar una gestión de acceso más detallada o simplificar la gestión de cientos de asignaciones de roles.
Azure ABAC (control de acceso basado en atributos) se basa en Azure RBAC añadiendo 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 opcionalmente agregar 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 del rol y la asignación del rol. Por ejemplo, puedes agregar una condición que requiera que un objeto tenga una etiqueta específica para leer el objeto. No puedes negar explícitamente acceso a recursos específicos usando condiciones.
Default User Permissions
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 (puede desactivarse)
Crear grupos de Seguridad
Leer membresías de Grupos no ocultas
Agregar invitados a grupos Propios
Crear nueva
Last updated
