Azure AD: Gobernanza de Office 365 y Recursos de Azure (Parte 3)

En este nuevo articulo sobre la gobernanza de Azure, vamos a centrarnos en Rbac, Grupos de Administración y Azure Policy.  Veamos la necesidad de disponer estos tres elementos tan importantes en el gobierno de Azure.

Lo “primero” la infografía de este artículo, los componentes para gobernar AzureAD (sincronización), grupos de administración y políticas:

En los artículos anteriores habíamos comentado cual es la finalidad de AzureAD, como sincronizar nuestro Active Directory On-Premises, como gestionar diferentes roles de administración de Office 365 utilizando los usuarios y grupos sincronizados.

Pues ahora que ya tenemos nuestros usuarios y grupos sincronizados con AzureAD, ya podemos empezar a definir otras configuraciones que nos permitirán gobernar todos los recursos que tengamos en Azure. Hasta el momento, como he comentado, nos hemos dedicado a “conocer” que es AzureAD y que aplicación práctica tiene con Office 365, pero ahora toca el definir como vamos definir el control de acceso basado en el rol (Rbac) de nuestros usuarios y algunos otros aspectos importantes para gestionar nuestras suscripciones de Azure.

Cuando hablamos de una suscripción de Azure, hablamos o pensamos tener poder contratar máquinas y redes virtuales, gateway VPN, cuentas de almacenamiento, servicios de IoT, etc… pues si, es realmente esto pero en su sentido más amplio. Al disponer de una suscripción de Azure, ya podemos contratar recursos en cualquier región de Azure, adquirir servicios de terceros en el marketplace de Azure (Adobe, Citrix, Fortinet, Barracauda, etc…).

El concepto de suscripción también nos sirve para agrupar los costes asociados a los recursos contratados en dicha suscripción, podemos tener múltiples suscripciones por muchos motivos:

• Gestión de costes
• Delegación de administración
• Límites por suscripción

Siento no poder entrar en profundidad en el concepto de suscripción, pero es que sino este artículo sería inmenso. Intento no irme mucho de la temática principal de este artículo, que es la gobernanza de Azure en su globalidad. Claramente, necesitamos suscripciones para poder “gobernar” y las suscripciones son obligatorias si queremos disponer  servicios en nube (máquinas virtuales, web apps, IoT, firewalls, etc…).

Cuando sólo disponemos de una suscripción, administrarla (gobernarla) es sencillo, puesto que con la utilización de rbac podemos controlar de forma sencilla quien tiene acceso a que recursos y con que nivel de acceso. Pero cuando tenemos varias suscripciones, se nos complica un poco la gestión/gobernanza de los recursos actuales y los que el personal de IT vaya creando en el futuro.

Microsoft para empezar la gobernar suscripciones de Azure, ha puesto a nuestra disposición los Grupos de Administración. Los grupos de adminitración permiten un administración por encima de la suscripciones, puesto que son contenedores donde tenemos una estructura jerárquica para anidar suscripciones y otros grupos de administración.

Los grupos de administración nos permiten además nos permite administrar el acceso (Rbac), las directivas y el cumplimiento (Azure Policy). Y esto todo, permitiendo heredarse de forma sencilla por todas las suscripciones que están en los diferentes grupos de recursos. A continuación os muestro una estructura de grupos de administración y suscripciones de ejemplo (imagen de Msft):

Antes de continuar, veamos los límites que tienen los grupos de administración:

• Se admiten 10 000 grupos de administración en un único directorio.
• Un árbol de grupo de administración puede admitir hasta seis niveles de profundidad.
• Este límite no incluye el nivel raíz o de suscripción.
• Cada grupo de administración y suscripción admite solo un elemento primario.
• Cada grupo de administración puede tener muchos elementos secundarios.
• Todas las suscripciones y grupos de administración están dentro de una única jerarquía en cada directorio.

Esta forma de administrar nuestras suscripciones nos permite controlar no sólo quien accede, sino a aplicar diferentes niveles de políticas que nos permiten entre otras cosas controlar algunas de las siguientes características:

• Que SKU de máquinas virtuales permitimos crear en una suscripción
• Máquinas virtuales sin direcciones IP Públicas
• Etc..

Dicho esto, como vemos, podemos tener un gran control a nivel institucional sobre toda las suscripciones que tengamos y de forma centralizada. Los grupos de administración nos ayudarán a organizar las suscripciones, aplicar directivas y controlar quien pueden acceder a las suscripciones que están dentro de cada grupo de administración y todas heredan las definiciones del grupo de nivel superior.

Aquí os dejo el enlace de MSFT sobre los grupos de administración, puesto que, creo que será más fácil entender que son y como utilizarlos: Organización de los recursos con grupos de administración de Azure

Dicho todo esto, vamos a empezar con la creación de nuestros grupos de administración. Por defecto, todas las suscripciones tienen habilitados los grupos de administración y con una grupo principal con el nombre Tenant Root Group. Lo primero, vamos a mostrar en el Portal de Azure la sección de Grupos de Administración, para ello desde el propio portal vamos a Todos los servicios y agregamos Grupos de Administración:

Ahora debemos pulsar en Empezar a usar grupos de adminsitración

Y podemos crear nuestro primero grupo de administración, podemos crear un nuevo grupo y será miembro secundario del grupo Root que todo directorio (AzureAD) tiene por defecto donde se crearán el resto de grupos de administración:

Aunque no creéis nada, en cuestión de unos minutos (15′ más o menos), ya os aparecerá del grupo por defecto y todas las suscripciones que tengáis. Si os fijáis, os pone que aún siendo administrador del directorio no tenemos los permiso necesarios para acceder al grupo de administración raíz.

Os pongo un ejemplo de que No podemos hacer sino tenemos dicho acceso, pues que podemos dar permisos a otros grupos a los grupos de administración ..

Antes de nada, tenemos que darnos derechos a nosotros mismos, pero para esto, tenemos que ser Administradores Globales, sino no podemos hacerlo. Para concedernos permisos tenemos que ir a la sección de AzureAD – Propiedades y cambiar a Si la opción de administración del acceso para los recursos de Azure (importante, cuando hayáis finalizado las tareas en cuestión, recomendable quitaros ese permiso)

Una vez que tengamos los derechos administrativos, veremos que ya podemos conceder permisos sobre el grupo de administración y todas las suscripciones que dependen de él.

Pues ahora que ya tenemos todo lo que necesitamos, podemos empezar a crear nuestros grupos de administración, recordad que a este nivel siempre serán grupos de administración secundarios del grupo Raiz.

El proceso es muy sencillo, únicamente pulsamos en Agregar Grupo de Administración y, ahora debemos escribir un ID y nombre para el grupo de administración y pulsamos  en Guardar

En cuestión de segundos ya tenemos nuestro primero grupo de administración creado

Pues ahora tendremos que realizar el mismo proceso para cada grupo de administración que queramos tener

Ahora quiero crear grupos de administración dentro de los grupos previamente creados, de tal forma que empecemos a crear nuestra propia estructura jerárquica. Lo primero, acceder al grupo de administración en cuestión:

Una vez dentro del grupo de administración, tenemos nuevamente la opción de Agregar grupo de administración y, si creamos un nuevo grupos de administración, ya vemos que se creará como un grupo secundario del grupo de Producción (grupo de administración en al que hemos accedido)

Y como antes, en cuestión de segundos ya tenemos nuestro nuevo grupo de administración:

Ya podemos ver la estructura que se está creando: Tenant Root Group>Producción>NorthEurope:

Una vez que ya tenemos nuestra estructura de grupos de administración, ahora vamos a empezar a mover  las suscripciones a los diferentes grupos de administración. Pues bien, desde la administración de cada grupo tenemos la opción de Agregar suscripción, elegimos la suscripción en cuestión y pulsamos en Guardar

Y ya tenemos nuestra suscripción movida dentro del grupo de administración

Y esto mismo lo haremos con todas las suscripciones para meterlas en los diferentes grupos de administración:

El proceso  de mover la suscripción de grupo de administraciónse puede hacer desde la opción de Agregar suscripción desde la administración de los grupos de administración o bien desde los puntos suspensivos directamente en la suscripciones. Una vez que hemos hecho clic sobre los puntos suspensivos, nos mostrará la opción de mover

Debemos seleccionar el grupo de administración a donde queremos mover la suscripción y pulsar en guardar.

Y así hasta que movamos todas la suscripciones que tengamos 

Ahora ya tenemos únicamente la estructura de grupos de administración, la mía es la siguiente:

• Tenant Root Group
  • Microsoft Partner: un tipo de suscripción por los niveles de partner de la compañía
  • Producción: todas las suscripciones donde tenemos recursos en producción
    • NorthEurope: nivel donde lo  distinto por regiones, para identificar que todo lo que ahí se cree tiene que estar en el Norte de Europa (aplicaremos directivas específicas para ello)
  • Test: todas las suscripciones para pruebas

Como en cualquier recurso de Azure, si accedemos a él, veremos que tenemos una sección de Activity Log y veremos todos los eventos de todas las acciones sobre este recurso:

Si tenemos varias suscripciones en el grupo de administración, pues ya tendremos centralizada la gestión de costes de todas las suscripciones:

Esto y otras cosas son los primeros beneficios de disponer de grupos de administración, la centralización de toda la administración y con herencia de las diferentes gestiones y políticas que se apliquen.

Lo siguiente y “más interesante”, es la posibilidad que tenemos de utilizar Azure Policy, crear y asignar Iniciativas y Directivas a dicho grupo de administración a cualquier nivel  (teniendo en cuenta la herencia que lo hará mucho más potente). Antes de nada, veamos que son las Iniciativas y Directivas de Azure Policy:

• Directivas: definiciones de directivas que permiten controlar por ejemplo que recursos creamos o que servicios pueden contener, a continuación los que están disponibles de forma predeterminada:
  • Requerir SQL Server 12.0: valida que todos los servidores SQL usan la versión 12.0. Su efecto es denegar todos los servidores que no cumplen estos criterios.
  • SKU permitidas de cuentas de almacenamiento: determina si una cuenta de almacenamiento que se va a implementar se engloba dentro de un conjunto de tamaños de SKU. Su efecto es denegar todas las cuentas de almacenamiento que no cumplen el conjunto de tamaños de SKU definidos.
  • Tipo de recurso permitido: define los tipos de recursos que se pueden implementar. Su efecto es denegar todos los recursos que no forman parte de esta lista definida.
  • Ubicaciones permitidas: restringe las ubicaciones disponibles para los nuevos recursos. Su efecto se utiliza para exigir los requisitos de cumplimiento de replicación geográfica.
  • SKU de máquina virtual permitidas: especifica un conjunto de SKU de máquina virtual que se pueden implementar.
    Aplicar etiqueta y su valor predeterminado: aplica una etiqueta obligatoria y su valor predeterminado si la solicitud de implementación no la especifica.
  • Aplicar una etiqueta y su valor: aplica una etiqueta obligatoria y su valor a un recurso.
    Tipos de recursos no permitidos: impide la implementación de una lista de tipos de recursos.
• Iniciativas: por simplificar (y mucho), son agrupaciones de un conjunto de directivas como un solo elemento, a continuación algunos ejemplos:
  • Supervisar SQL Database sin cifrar en Security Center, para supervisar servidores y bases de datos SQL sin cifrar.
    Supervisar las vulnerabilidades del SO en Security Center, para supervisar los servidores que no cumplen con la base de referencia configurada.
  • Supervisar Endpoint Protection omitido en Security Center, para supervisar los servidores que no tienen instalado un agente de protección de los puntos de conexión.

Esto será algo que iré explicando en diferentes artículos, puesto que, esto es mucho más extenso que esas mini definiciones. Igualmente, aquí os dejo un enlace para que podáis ampliar información al respecto: Introducción al servicio Azure Policy.

Para comprender mejor que es una iniciativa o directiva, vamos a ver como se aplican. Dentro de un grupo de administración, al nivel que consideréis oportuno aplicarla, nos vamos a la sección de Directiva de Asignaciones y pulsamos en Asignar Directiva:

Ahora tenemos un pequeño asistente donde debemos ir cubriendo:

• Ámbito: a que nivel se asignará esta directiva (grupo de administración, suscripción, recurso)

• Exclusiones: por defecto esta directiva se aplicará a todo lo que esté por debajo del grupo de administración donde se ha creado, si queremos filtrar a que recursos no se aplicará, debemos hacerlo desde aquí.
• Definición de directiva: aquí elegiremos la directiva que deseemos aplicar, tendremos un listado con todas las que ha creado MSFT o las personalizadas por nosotros

En mi caso, voy a escoger una “mítica”, la que evitar que se creen interfaces de red con IP Públicas. La buscamos, seleccionamos y pulsamos en Seleccionar

Podemos (debemos) especificar una descripción, siempre es recomendable explicar algo más para que queremos aplicar esta directiva, aunque, en este caso es que no queremos IP Públicas en las interfaces de red

Esta directiva únicamente analizará las interfaces de red con IP Públicas en los recursos actuales, pero en las nuevas implementaciones evitará que se puedan crear. Si todo está correcto, pulsamos en Crear

En cuestión de segundos, tendremos nuestra directiva aplicada y ahora toca esperar unos 30 minutos antes de que tenga efecto.

Si accedemos a la sección de cumplimiento, vemos que ya tenemos la directiva aplicada pero aún está en proceso de ejecución. Además, podemos ver que tenemos la posibilidad de editarla, eliminarla, ver su definición etc.. todo ello desde los puntos suspensivos 

Mientras que se va aplicando, lo que he hecho es asignar una nueva directiva, en este caso quiero definir sobre este grupo de administración (y todos las suscripciones que contenga) que no se puedan crear máquinas virtuales con un SKU diferente al permitido. 

En esta directiva tenemos parámetros a definir, no como en la anterior directiva. Aquí, definiremos el SKU que vamos a permitir, simplemente las marcamos: 

Una vez definida, pulsamos en Crear

Mientras se ejecuta revisando las máquinas virtuales ya creadas en las diferentes suscripciones, me he puesto a crear una nueva máquina virtual con un SKU diferente al permitido y con una interface con IP Pública y  … bingo!!! La directiva nos lo impide, esto es genial para la gobernanza de las suscripciones que tengamos, verdad?

Si ahora volvemos a la sección de cumplimiento donde hemos aplicado las directivas, vemos como ya vamos tiendo información de cada una de ellas:

Y está haciendo bien su trabajo, nos encontramos múltiples interfaces con IP Públicas en las suscripciones que son miembro del grupo de administración donde hemos asignado nuestra directiva:

Y si le damos el tiempo suficiente, veremos que .. los % de No compatible van subiendo

Si accedemos a alguna política, veremos los recursos que no cumplen con dicha directiva:

Y si accedemos a alguno de los recursos tendremos información ampliada:

Antes de finalizar este artículo, comentaros que, he asignado una directiva a nivel de la raíz de los grupos de administración y veremos como se aplica a todos los grupos secundarios. En este caso estoy en el grupo de administración de Producción y vemos como tenemos aplicada una directiva asignada (Auditar las máquinas virtuales que no tienen configurada la recuperación ante desastres) y como ámbito tiene Tenant Root Group (el grupo de administración raíz)

Esto como podéis apreciar es muy potente, yo os he dado una iniciación sobre su potencia, pero en próximos artículos iré mostrando más opciones interesantes que podemos configurar.

Comentar que, si queréis podéis cambiarle el nombre a los grupos de administración, inclusive el de raíz:

En próximos artículos veremos Rbac aplicado a los grupos de administración, suscripciones y recursos.

Ahora, como siempre, os toca a vosotros probarlo!!