Protege tus Grupos de Recursos de Azure con tu Directorio Activo On-Premises

Cualquier empresa que tenga recursos en Azure, es posible que tenga la necesidad de proteger el acceso a dichos recursos. Por ejemplo, que tengáis una serie de servidores virtuales y queréis delegar ciertas tareas administrativas a usuarios no administradores o de otras empresas.  Como sabéis, cualquier recurso (IP Públicas, Tarjetas de red, redes virtuales, almacenamiento, servidores virtuales, etc…) es susceptible de ser protegido mediante Rbac (Role-based access control), evitando así el acceso o administración por personal no validado.

Dicho eso, también es muy probable que si tenéis servicios en Azure antes hubierais adoptado Office 365 por lo que, como buena práctica tendréis vuestra sincronización de directorio con AzureAd Connect. Para lo que no sabéis que es, aquí os dejo un enlace en donde podréis documentaros al respecto: Documentación de identidad híbrida. “Básicamente” lo que nos permite el tener nuestro Directorio Activo On-Premises sincronizado con Azure, es la utilizar nuestras cuentas de usuario On-Premises para autenticar en los servicios de nube (Azure, Office 365). Y claro, además de autenticar para iniciar en los servicios de Office 365 (Exchange, Teams, Skype for Business, etc…), también queremos que nuestro equipo de IT (o no) tenga acceso a los recursos que tengamos en Azure. Además, queremos que utilizando sus propias credenciales corporativas tenga acceso a los recursos de Azure y con el rol adecuado para cada grupo de recursos.

Yo os voy a mostrar como securizar vuestros grupos de recurso de Azure, partiendo de la base que los grupos de recursos nos permiten organizar de forma cómoda y fácil todos los recursos que tiene un servidor virtual (Servidor Virtual, Cuenta de Almacenamiento, Interfaces de Red, Reglas de Seguridad, etc..). Teniendo en cuenta este detalle, mi recomendación es que creéis tantos grupos de recursos como servicios queráis implementar y/o proteger por diferentes roles de las personas que los gestionarán. A continuación os muestro un ejemplo de una suscripción de Azure y los grupos de recurso que contiene o pueden contener cualquiera de vuestros clientes:

Como podéis apreciar, por el nombre de cada grupo de recursos, se intuye fácilmente que recursos contiene. Además, siempre sigo la misma nomenclatura:

• RG: Resource Group
• NorthEurope: especifico la ubicación geográfica del grupo de recursos
• Servicio: VM para Virtual Machines o directamente Backup si utilizo los servicios de Azure Backup
• Rol: si tenemos VM es posible que queramos agrupar los mismos servicios en el mismo grupo de recursos. Ejemplos:
  • Controladores de Dominio: RG-NorthEurope-VM-Identity
  • Servidores de Adfs: RG-NorthEurope-VM-Adfs
  • Servidores de Bases de Datos SQL: RG-NorthEurope-VM-Sql

Esto nos permite tener organizado nuestro entorno en todo momento, que todos los miembros del equipo de IT tenga clara la organización de los recursos y como crear los nuevos. Ahora bien, una vez que tengamos todos los grupos recursos creados y los recursos correspondientes correctamente ubicados, ahora queremos/debemos preocuparnos por definir los permisos que tenga nuestro equipo de IT.

Los permisos se pueden aplicar a nivel de suscripción, grupos de recursos y recursos, aquí os dejo una imagen muy ilustrativa al respecto:

Si habéis creado los grupos de recursos pensando en establecer los diferentes permisos a establecer, con aplicar permisos a los grupos de recursos tendréis vuestro entorno de Azure gestionado. En Azure ya tenemos una serie de Roles predefinidos por MSFT, de tal forma que sobre un grupo de recursos o recursos de máquinas virtuales, ya podemos establecer los diferentes roles para gestionar los servidores virtuales. Aquí os dejo un enlace con el listado de todos los roles de Azure: Roles integrados en los recursos de Azure, pero aquí os muestro una captura de alguno de los roles. Para poder ver el listado de todos los roles en Azure tenéis que ir a vuestra suscripción, seleccionarla y luego ir a Control de Acceso (IAM) y pulsar en Roles:

Ahora que sabemos todos los roles que tenemos por defecto en Azure, comentaros que, si estos roles no cubren vuestras necesidades, podéis crear los vuestros (en este artículo veremos como crear un rol específico para gestionar los servidores virtuales).

Los roles se pueden asignar a usuario o a grupos de usuarios, claramente … siempre que podáis utilizar grupos de seguridad. Estos grupos pueden ser de Azure AD o de vuestro Directo Activo On-Premises (sincronizado con AzureAd Connect). Los grupos son gratis y puedes crear los que necesites, no dejes de crear los grupos que necesites por cada recurso o grupo de recursos a proteger. De esta forma, siempre que queráis saber a que recursos tiene acceso un usuario, únicamente con ver sus membresias sabréis a que recursos tiene acceso. Dicho esto, yo si tengo mi Directorio Activo sincronizado con Azure Ad Connect quiero utilizar mis grupos de seguridad locales como grupos para aplicar permisos sobre los recursos de Azure. Con esto obtengo los siguientes beneficios:

• Simplicidad de gestión: si tenemos mis grupos de seguridad en On-Premises, simplemente por anidaciones ya les estoy ofreciendo acceso a los recursos de Azure
• Rapidez: si añadimos como miembro de uno de los grupos de seguridad  para Azure a algún usuario el efecto es inmediato (también con los grupos de Azure)
• Seguridad: desde nuestro AD local podemos manejar las membresias y sus permisos

Básicamente lo que busco es, ver las membresias de un usuario y saber a que recursos tiene acceso mis usuarios. Si tengo grupos de Azure únicamente, no puedo verlo desde mi AD local, pero si gestiono los permisos con mis grupos de seguridad de On-Premises ya de una sola vista tengo todo el conocimiento de a que accede mi usuario. Sobre esto trabajaré en todo el artículo, además, aquí os muestro una pequeña infografía para tomar como referencia:

La infografía es muy sencilla, tengo a mi Directorio Activo On-Premises (izquierda de la imagen) sincronizado con AzureAD Connect (derecha de la imagen). Tengo mis grupos de seguridad global para organizar los roles de mi equipo  (amarillo), los miembros de los grupos son los usuarios y luego los grupos de locales de dominio son miembros de los grupos locales. De esta forma, cuando un usuario es miembro de algún grupo global en función de su rol, por anidación tendrá acceso a los recursos de Azure que hayamos configurado. Dicho esto, vamos al lío!!!

Lo primero, crearé los grupos locales de dominio para luego gestionar cada uno de los Grupos de Recursos que tengo en Azure (captura inicial de este artículo). Mis nomenclaturas para mis grupos me darán una visión clara de que “permiso gestiona”, aquí os dejo una captura de mis grupos de seguridad en mi Directorio Activo On-Premises:

A continuación os describo mi nomenclatura:

• Acl: identificamos que es un grupo para aplicar permisos
• Rbac: identificará que controlará permisos basados en el rol
• Azure: será el recurso a proteger, en este caso Azure. Si fuese un recurso compartido sería Files, si fuese una conexión RDP sería Rds y así con todos los recursos a proteger
• RG-NorthEurope-XXX: identificamos el objeto a securizar
• (): lo que va entre paréntesis identificará el tipo de permisos, para Azure he elegido los siguientes en base a los diferentes roles existentes:
  • C: Contribute
  • R: Read
  • VMO (en la captura no lo había actualizado): Virtual Machine Operator (un rol que he creado expresamente yo y que  comentaré en este artículo)

De esta forma, si veo que un usuario pertenece al grupo Acl Rbac RG-NorthEurope-VM-SQL (R) sé que tendrá acceso de lectura al grupo de recursos RG-NorthEurope-VM-SQL que contiene todos los recursos donde tengo los servidores de SQL Server. De ahí la importante de su nomenclatura, luego todo es más fácil. Con ver las membresias del usuario (directas o por anidación) tengo un visión fácil de que a que recursos tiene acceso cualquier usuario. Si esto lo hago en Azure, tendría que ir a Azure a revisarlo, pero yo quiero verlo desde On-Premises que es nuestro día a día a nivel de permisos.

Una vez creados, para no tener que esperar a un próximo ciclo  de sincronización de mis nuevos usuarios en Azure AD forzaré dicha replicación, pero antes, revisaré si tengo la OU donde tengo estos grupos (también importante, pero esto para otro artículo) también está incluida en el proceso de replicación. Desde el servidor donde tenéis instalado el AzureAD Connect abrimos la consola de Synchrnization Service Manager  y vamos a las propiedades de nuestro conector de Active Directory Domain Services:

Nos vamos a la sección Connect To Active Directory Forest, porque por defecto estaremos en la de Propierties:

Introducimos un usuario y contraseña con permisos para acceder al Directorio Activo 

Nos vamos a la sección Configure Directory Partitions y puslamos en Containers y ahí elegimos  la OU donde tengamos los nuevos grupos

Por último, desde una consola de PowerShell ejecutamos el siguiente cmdlet: Start-ADSyncSyncCycle -PolicyType Delta y empezará a sincronizar nuestro AD con Azure (en modo Delta, si queréis replicar todo nuevamente cambiáis el Delta por Initial).

Una vez que esperemos unos 5 minutos ya deberíamos ver los grupos de seguridad en Azure, para ello, nos vamos al portal de Azure (https://portal.azure.com), a la sección de Azure Active Directory y luego a Grupos y nos llevará a la siguiente pantalla. Si os fijáis yo he filtrado por Acl Rbac Azure  y ya tengo todos los grupos sincronizados. Ahí tenéis otra ventaja de la nomenclatura de los grupos, puedo ir haciendo filtros por el prefijo de los grupos, muy útil os lo aseguro.

Ahora que ya tenemos nuestros grupos en Azure, vamos a “repasar” como tenemos los permisos de nuestros grupos de recursos. Vamos a buscar algún grupo de recursos y accedemos a él, ahora vamos a la sección Control de Acceso (IAM) y veremos todos los usuarios o grupos que tienen acceso a este recurso y su ámbito. Si os fijáis, hay un montón de usuarios con el rol de Propietario y porque viene heredado de la suscripción. Vamos que estos usuarios tienen acceso a la suscripción como propietarios, y los permisos se heredan hacia abajo (como casi cualquier permiso de recursos). Esto tiene fácil solución, únicamente quitarlos del Control de Acceso de la suscripción, pero esto lo veremos más adelante en este artículo, lo que haremos ahora será añadir los grupos creados anteriormente y darle su rol correspondiente.

Antes de empezar a aplicar los permisos, voy a crearme un nuevo Rol que no existe en Azure. Quiero un rol que únicamente permita al grupo que lo tenga pueda Iniciar, Parar y Detenga las máquinas del grupo de recursos, pero no quiero que haga nada más. El proceso es muy sencillo, aquí os dejo el script de PowerShell para que lo podáis crear:

$role = Get-AzureRmRoleDefinition “Virtual Machine Contributor”
$role.Id = $null
$role.Name = “Virtual Machine Operator“
$role.Description = “Can monitor, stop, start and restart virtual machines.”
$role.Actions.Clear()
$role.Actions. (“Microsoft.Storage/*/read”)
$role.Actions.Add(“Microsoft.Network/*/read”)
$role.Actions.Add(“Microsoft.Compute/*/read”)
$role.Actions.Add(“Microsoft.Compute/virtualMachines/start/action”)
$role.Actions.Add(“Microsoft.Compute/virtualMachines/restart/action”)
$role.Actions.Add(“Microsoft.Compute/virtualMachines/deallocate/action”)
$role.Actions.Add(“Microsoft.Authorization/*/read”)
$role.Actions.Add(“Microsoft.Resources/subscriptions/resourceGroups/read”)
$role.Actions.Add(“Microsoft.Insights/alertRules/*”)
$role.Actions.Add(“Microsoft.Support/*”)
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add(“/subscriptions/XXXXXXXXXXXXXXX“)
New-AzureRmRoleDefinition -Role $role

*Tenéis que cambiar las XXXXXXXXXXX por el ID de vuestra suscripción.

El nombre del grupo se define aquí: $role.Name = “Virtual Machine Operator” y la descripción aquí: $role.Description = “Can monitor, stop, start and restart virtual machines.”. Los permisos se definen en las siguientes líneas del script, pero si queréis más nivel de detalle aquí os dejo un enlace: https://docs.microsoft.com/es-es/azure/role-based-access-control/built-in-roles#virtual-machine-contributor. Una vea creado, en el listado de Roles lo podéis identificar muy fácilmente, puesto que tiene un icono personalizado:

Ahora tocaría gestionar los permisos sobre los grupos de recursos, y ya tenemos disponible este nuevo rol. Este rol  lo quiero para usuarios que tengan que ser miembros del grupo Acl xxxxx xxxxxx xxxx (VMO), porque serán usuarios que tengan que poder iniciar o parar los servidores virtuales del grupo. El proceso es muy simple, accedemos a cualquier grupo de recursos y nos vamos a la sección Control de Accesos (IAM) y pulsamos en Agregar, ahora elegimos el Rol en función del grupo creado:

• Acl Rbac Azure XXXX XXXXXX (C): Colaborador
• Acl Rbac Azure XXXX XXXXXX (R): Lector
• Acl Rbac Azure XXXX XXXXXX (VMO): Virtual Machine Operator

Se tiene que hacer grupo por grupo, por lo que elegimos el rol, buscamos el grupo en cuestión y pulsamos en Agregar y así con los dos o tres grupos por cada Grupo de Recursos. Si os habéis dado cuenta en la captura donde se ven todos los grupos, no tengo el (VMO) porque no en todos los grupos de recursos tengo servidores virtuales y ese rol sólo vale para grupos de recursos donde tengo servidores virtuales que reiniciar, apagar o detener).

Una vez agregados todos los grupos con sus roles correspondientes nos quedaría así la sección de Control de Acceso de cada grupo de recursos. En este caso, además, también estáis viendo dos grupos que vienen heredados de la suscripción:

• Acl Rbac Azure Suscripcion 1003512 (O): grupo creado en nuestro Directorio Activo On-Premises y aplicado como permiso directamente en la suscripción.
• Acl Rbac Azure Ext Suscripcion 1003512 (O): grupo creado en Azure  Active Directory aplicado como permiso directamente en la suscripción

Estos grupos heredados son como os comentaba anteriormente aplicados a nivel de suscripción, pero hay una diferencia con respecto a todo lo comentado, es el grupo Acl Rbac Azure Ext Suscripcion 1003512 (O).  Este grupo es un grupo de Azure Active Directory, lo utilizo para usuarios externos a nuestra organización y que tengamos de darle acceso a la suscripción (no tiene porque ser O, puede ser C o R u otro). Ahora os comento como se crea, pero primero vamos a seguir con la idea de aplicar permisos con los grupos sincronizados de nuestro Ad. Lo primero será crearme el grupo de seguridad de dominio local que luego utilizaré para aplicarlo a nivel de suscripción.  En este caso, el grupo lo he creado con la siguiente nomenclatura: Acl Rbac Azure Suscripción XXXX (O), el código de la suscripción es el código que os muestro en verde.

Simplemente lo creo en el Ad y fuerzo la replicación:

Una vez agregado el grupo (como el resto de grupos en otros Grupos de Recursos comentarios anteriormente), ya tenemos el grupo como Propietario de la suscripción. Si teníamos usuarios a este nivel, quitarlos y dejemos únicamente el grupo:

Además, como teníamos más usuarios agregados a la suscripción, lo que haré será quitarlos y dejar los grupos de seguridad que necesitamos. Simplemente los marcamos y pulsamos en Quitar:

Nos mostrará una confirmación y pulsamos en Si

Con esto ya tenemos los permisos únicamente con los grupos que queremos, de esta forma dejamos los recursos lo más prolijos posibles.

Os había comentado que había un grupo de seguridad excepcional que controlaba lo permisos para usuarios externos, puesto que, como no podemos añadirlos a grupos de seguridad sincronizados desde nuestro Directorio Activo (las membresias sólo se pueden actualizar en On-Premises). Es por ello que, debemos crear grupos de seguridad para aplicar los permisos sobre los recursos de Azure y añadir a usuarios externos a nuestra organización.

La creación de un grupo de seguridad en Azure es muy sencillo, nos vamos a Azure Active Directory – Grupos – Nuevo Grupo

Ahora cubrimos la siguiente ficha para la creación del grupo:

• Tipo: Seguridad
• Nombre del grupo: sigo con la misma política de nombres que en On-Premises, pero con la diferencia que le añado Ext porque así puedo identificar que es un grupo para usuarios externos a la organización
• Tipo de pertenencia: Asignada

Una vez cubierto todo los datos, pulsamos en Crear 

Nuevamente, volvemos a la lista de grupos y si buscamos por el prefijo común de los grupos Acl Rbac Azure Ext encontraremos todos los grupos para externos que tenemos en Azure. Ahora, si queremos añadir usuarios pulsamos encima del nombre del grupo

Pulsamos en miembros y Agregar miembros

Ahora buscaremos los usuarios que tenemos en nuestro Azure AD (sincronizado, creado manualmente o externos), en mi caso como sólo quiero externos escribo su dirección de correo y los vamos seleccionando:

Con esto ya tenemos a los usuarios agregados, insisto, la nomenclatura sólo me sirve para identificar al grupo, puedo añadir cualquier usuario disponible, pero si añado a usuario internos no tendría sentido alguno la nomenclatura que hemos decidido.

Ahora que ya tenemos todos los grupos creados, asignados con sus roles definidos a los grupos de recursos, quedaría beneficiarse de las membresias y sus anidaciones como os había comentado al principio del artículo.

En mi caso os voy a explicar los grupos globales que gestionan el equipo de IT para Azure:

• GRP Technical Support Azure (miembros)
  • GRP Technical Support Azure L1
  • GRP Technical Support Azure L2
  • GRP Technical Support Azure L3

Y por otro lado tenemos todos locales de dominio que hemos creado para aplicar los permisos sobre los grupos de recursos:

• Acl Rbac Azure RG-NorthEurope-Dns (C)
• Acl Rbac Azure RG-NorthEurope-Dns (R)
• Acl Rbac Azure RG-NorthEurope-VM-Identity (C)
• Acl Rbac Azure RG-NorthEurope-VM-Identity (R)
• Acl Rbac Azure RG-NorthEurope-VM-Identity (VMO)

Los usuarios del departmento de IT son miembros de los grupos GRP Technical Support Azure XX, en función de su nivel de formación y experiencia estarán en uno u otro grupo (L1 el más bajo, L3 el más alto). Los técnicos de L1 son los que tienen menos experiencia con los servicios de gestionan (Azure en este caso), de ahí que son los que tendrán acceso a todo pero con el rol de Lectura. Los de L2 tendrán acceso de colaboración a nivel de grupos de recursos (y no tienen porque ser todos) y luego los L3 serán los que tienen control total sobre la suscripción. Entendiendo esto, aquí os muestro como se reflejaría esto en nuestro Directorio Activo On-Premises:

El grupo GRP Technical Support Azure es el del departamento, únicamente tiene como miembros a los grupos que definen los roles (L1, L2, L3) y luego los roles son miembros de los Acl Rbac Azure XXXXXX que se necesiten. En función de lo comentado anteriormente, sería así:

• GRP Technical Support Azure L1: todos los grupos Acl Rbac Azure XXXXX (R)
• GRP Technical Support Azure L2: todos los grupos Acl Rbac Azure XXXXX (C)
• GRP Technical Support Azure L3: todos los grupos Acl Rbac Azure Suscrición xxx (O)

Y por último .. lo técnicos son miembros de los Roles, de esta forma, todos se benefician de las anidaciones y los técnicos en función del rol al que pertenezcan tendrán permisos sobre los recursos de Azure. Aquí os muestro tres usuarios para Test cada uno siendo miembro de los grupos globales los cuales definen los roles:

Una vez actualizadas las membresías, forzada la replicación con Azure, ya podríamos ver el resultado en Azure Active Directory. Aquí vemos como el grupo GRP Technical Support Azure L1 es miembro de todos los Acl Rbac Azure xxxx (R)

También podemos añadir como miembros de forma directa a los usuarios a los grupos Acl Rbac Azure xxxx, pero siempre y cuando tengamos la posibilidad de añadir grupos globales mejor que mejor.

Por último, vamos a ver que ocurre cuando un usuario tiene diferentes roles o es miembro de alguno de los grupos Acl.  En este caso, sólo tiene acceso al grupo de recursos RG-NorthEurope-VM-Adfs y cuando acceder a Azure ya ver los recursos a los que tiene acceso:

Si vamos a la sección de Grupos de Recursos vemos que sólo tiene disponible el grupo de recursos para el que tiene acceso

Tiene permisos sobre las máquinas virtuales que están dentro del grupo de recursos y tiene disponibles las opciones de inicio, reiniciar y detener

Pero si el usuario quiere crear algún recurso dentro del grupo de recursos obtendrá el siguiente resultado:

Claramente se puede apreciar que no tiene permiso para crear nada, está en los grupos de lectura. Si por ejemplo añadimos a otro usuario a más Acl Rbac Azure XXXXXX pues tendrá acceso a todos y cuantos se lo hayamos dado:     

Esto es todo, creo que ha quedado algo extenso el artículo, pero sino cubrir más o menos todo era complejo. Os pongo ahora un pequeño resumen:

• Grupo de seguridad On-Premises para sincronizar con el Azure Active Directory
  • Grupos locales de dominio para definir los permisos en Azure
  • Grupo globales para definir los roles de On-Premises
• Política de nomenclatura de los grupos: permite identificar de forma fácil que hace cada grupo y que permiso tendrán los usuarios corporativos desde On-Premises
• Grupos para externos: para los usuarios externos crearíamos grupos de seguridad en Azure, añadiendo al prefijo la palabra Ext para identificar de forma sencilla a los usuarios externos que tienen permiso en nuestros recursos de Azure
• Membresias: lo más importante, jugar con las membresias y así beneficiarse de los grupos de seguridad y sus anidaciones para controlar el acceso a recursos.

Espero que os haya gustado y sea de utilidad, para mi lo es y mucho!!