Az - Basic Information
Jerarquía de Organización
Grupos de Gestión
Si tu organización tiene muchas suscripciones de Azure, es posible que necesites una forma de gestionar el acceso, políticas y cumplimiento para esas suscripciones. Los grupos de gestión proporcionan un alcance de gobernanza por encima de las suscripciones.
Ten en cuenta que se pueden soportar 10,000 grupos de gestión en un solo directorio y un árbol de grupos de gestión puede soportar hasta seis niveles de profundidad.
De la documentación: Cada directorio recibe un único grupo de gestión de nivel superior llamado grupo de gestión raíz. El grupo de gestión raíz está integrado en la jerarquía para que todos los grupos de gestión y suscripciones se plieguen a él. Este grupo de gestión raíz permite que políticas globales y asignaciones de roles de Azure se apliquen a nivel de directorio. El Administrador Global de Azure AD necesita 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 del grupo de gestión raíz.
El grupo de gestión raíz no puede ser movido o eliminado, a diferencia de otros grupos de gestión.
Los grupos de gestión te brindan gestión a nivel empresarial a gran escala, sin importar qué tipo de suscripciones puedas tener. Sin embargo, todas las suscripciones dentro de un solo grupo de gestió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 con el propósito de provisionar recursos técnicos o comerciales. 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. Esta estructura facilita la delegación de acceso, utilizando mecanismos de control de acceso basado en roles.
Grupos de Recursos
De 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 un grupo. Generalmente, agrega recursos que compartan 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, todos los recursos dentro de él también se eliminan.
Unidades Administrativas
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 pueden 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 pudieran 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 permisos asignados sobre esa unidad administrativa que pueden usar para gestionar 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 el servicio de identidad empresarial en Azure. Además, Azure AD no es como Windows Active Directory, es un servicio de identidad que funciona de 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.
Principales
Azure soporta diferentes tipos de principales:
Usuario: Una persona regular con credenciales para acceder.
Grupo: Un grupo de principales gestionados juntos. Los permisos otorgados a los grupos son heredados por sus miembros.
Principal de Servicio/Aplicaciones Empresariales: 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 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 a 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 conectarse a recursos compatibles con la autenticación de Azure Active Directory (Azure AD). Al utilizar identidades administradas, las aplicaciones pueden asegurar los tokens de Azure AD mientras eliminan la necesidad de manejar credenciales directamente. 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 una identidad en Azure AD. La identidad está vinculada al ciclo de vida de esa instancia de servicio. Cuando se elimina el recurso, Azure automáticamente elimina 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 de Azure independiente. 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 y Permisos
Los roles son asignados a principales en un alcance: principal -[HAS ROLE]->(scope)
Los 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
Roles Integrados
De la documentación: El control de acceso basado en roles de Azure (Azure RBAC) 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.
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:
Estos roles también pueden ser asignados sobre contenedores lógicos (como grupos de gestió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.
Roles Personalizados
Azure también permite crear roles personalizados con los permisos que el usuario necesita.
Permiso Denegado
Para que un principal tenga algún acceso sobre un recurso, necesita que se le otorgue un rol explícito (de cualquier manera) otorgándole ese permiso.
Una asignación de rol explícita de negación tiene prioridad sobre el rol que otorga el permiso.
Administrador Global
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 gestión raíz. Esto significa que un Administrador Global podrá gestionar el acceso a todas las suscripciones de Azure y grupos de gestión. Esta elevación se puede hacer 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 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 cumplimiento con los estándares corporativos y 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 regulaciones externas y políticas internas. Algunos ejemplos:
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 asegurar que todos sus datos se almacenen en Europa para cumplir con el GDPR.
Imponiendo 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.
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.
Imponiendo 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 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.
Limitando el Acceso Público a 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.
Aplicando Configuraciones de Seguridad Automáticamente: 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.
Ten en cuenta que las Políticas de Azure pueden ser adjuntadas a cualquier nivel de la jerarquía de Azure, pero son comúnmente utilizadas en el grupo de gestión raíz o en otros grupos de gestión.
Alcance 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.
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 ya 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 granular 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 rol es un chequeo adicional que puedes agregar opcionalmente a tu asignación de rol para proporcionar un control de acceso más granular. Una condición filtra los permisos otorgados como parte de la definición de rol y la asignación de 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 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 (puede ser desactivado)
Crear Grupos de Seguridad
Leer membresías de Grupo no ocultas
Agregar invitados a Grupos Propios
Crear nueva aplicación (puede ser desactivado)
Agregar hasta 50 dispositivos a Azure (puede ser desactivado)
Puedes ver la lista completa de permisos predeterminados de los usuarios en la documentación aquí. Además, ten en cuenta que en esa lista también puedes ver la lista de permisos predeterminados de los invitados.
Recuerda que para enumerar recursos de Azure, el usuario necesita un otorgamiento explícito del permiso.
Gestión de Identidades Privilegiadas (PIM)
La Gestión de Identidades Privilegiadas (PIM) en Azure es una herramienta que gestiona, controla y monitorea el acceso privilegiado en Azure Active Directory y Azure. Mejora la seguridad al proporcionar acceso privilegiado justo a tiempo y limitado en el tiempo, imponiendo flujos de trabajo de aprobación y requiriendo autenticación adicional. Este enfoque minimiza el riesgo de acceso no autorizado al asegurar que los permisos elevados se otorguen solo cuando sea necesario y por un período específico.
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 puede ser utilizado para una combinación específica de usuario, cliente y recurso y no puede ser revocado hasta su expiración - que es 1 hora por defecto. La detección es baja usando 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: Proporcionados 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 puede ser revocado. La expiración predeterminada es 90 días para tokens de actualización inactivos y sin expiración para tokens activos.
La información para acceso condicional está almacenada dentro del JWT. Así que, si solicitas el token desde una dirección IP permitida, esa IP será almacenada en el token y luego puedes 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:
Los puntos finales de API más comunes son:
Azure Resource Manager (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, que está en desuso, es graph.windows.net)
Referencias
Last updated
