Curso: Microsoft Azure INA. Tema05: Módulo 02: Creación de una estrategia de gobernanza en la nube en Azure

Unidad 1: Introducción

El término gobernanza describe el proceso general por el que se establecen reglas y directivas y se garantiza que esas reglas y directivas se aplican.

Si usamos la nube, disponer de una buena estrategia de gobernanza ayuda a tener el control de las aplicaciones y los recursos que se administran en la nube. Al tener el control del entorno, nos aseguramos de que sigue siendo compatible con lo siguiente:

• Estándares del sector, como PCI DSS
• Estándares corporativos o de la organización, como asegurarse de que los datos de red están cifrados

Las ventajas de la gobernanza son mayores en los siguientes casos:

• Hay varios equipos de ingeniería que trabajan en Azure.
• Hay varias suscripciones que administrar.
• Hay requisitos normativos que deben aplicarse.
• Hay estándares que deben seguirse en todos los recursos en la nube.

Conozca Tailwind Traders

Tailwind Traders es una empresa ficticia que distribuye productos para la remodelación del hogar. Esta empresa cuenta con ferreterías minoristas en todo el mundo y en línea.

Tailwind Traders está especializada en precios competitivos, envío rápido y una amplia gama de artículos. Va a examinar las tecnologías en la nube para mejorar las operaciones comerciales y apoyar el crecimiento en nuevos mercados. Al migrar a la nube, la empresa tiene previsto mejorar su experiencia de compra para diferenciarse de sus competidores.

¿Cómo mejorará Tailwind Traders la agilidad de los equipos y mantener control al mismo tiempo?

Tailwind Traders continúa con la migración a la nube. En el centro de datos, los equipos de desarrollo y pruebas deben tramitar incidencias de soporte técnico para pedir acceso a las máquinas virtuales, el almacenamiento y los componentes de red. El personal de TI puede tardar entre dos semanas y dos meses en adquirir, aprovisionar y configurar estos componentes.

Al trabajar en la nube, el acceso a los componentes de proceso, almacenamiento y red es básicamente inmediato. Muchos tipos de grupos y usuarios (incluidos los miembros de los equipos de desarrollo, pruebas, operaciones y seguridad) pueden tener en teoría acceso directo a los recursos en la nube.

En el futuro, Tailwind Traders podría aplicar procesos similares que impidan que los equipos creen o configuren directamente recursos en Azure, algo similar al enfoque existente, según el cual el departamento central de TI aprovisiona la infraestructura. Pero la empresa sabe que estas restricciones reducen la agilidad del equipo y su capacidad de innovar. Así pues, ¿cómo pueden dar pie a la innovación y mantener el control?

En este módulo, ayudaremos a la empresa a explorar las distintas formas en las que puede aplicar estándares y, al mismo tiempo, permitir que los equipos creen y administren los recursos que necesiten para la nube.

Unidad 2: Control del acceso a los recursos en la nube por medio del control de acceso basado en roles de Azure

Cuando tenemos varios equipos de TI e ingeniería, ¿cómo podemos controlar el acceso que tienen a los recursos del entorno de nube? Una buena práctica de seguridad consiste en conceder a los usuarios únicamente los derechos que necesitan para realizar su trabajo, y solo a los recursos pertinentes.

En vez de definir los requisitos de acceso detallados de cada individuo y, posteriormente, ir actualizándolos a medida que se vayan creando más recursos, Azure permite controlar el acceso a través del control de acceso basado en roles de Azure (RBAC de Azure).

Azure proporciona roles integrados que describen las reglas de acceso comunes de los recursos en la nube. También podemos definir nuestros propios roles. Cada rol tiene un conjunto asociado de permisos de acceso que tienen que ver con ese rol. Cuando se asignan usuarios o grupos a uno o varios roles, reciben todos los permisos de acceso asociados correspondientes.

¿Cómo se aplica el control de acceso basado en roles a los recursos?

El control de acceso basado en roles se aplica a un ámbito, que es un recurso o un conjunto de recursos en los que este acceso se permite.

En este diagrama se muestra la relación entre roles y ámbitos.

Los ámbitos pueden ser lo siguiente:

• Un grupo de administración (una colección de varias suscripciones)
• Una sola suscripción
• Un grupo de recursos.
• Un solo recurso

En el diagrama, los observadores, los usuarios que administran recursos, los administradores y los procesos automatizados denotan los tipos de usuarios o cuentas que se suelen asignar a cada uno de los distintos roles.

Si se otorga acceso a un ámbito primario, esos permisos se heredan en todos los ámbitos secundarios. Por ejemplo:

• Cuando asignamos el rol Propietario a un usuario en el ámbito del grupo de administración, dicho usuario podrá administrar todo el contenido de todas las suscripciones dentro de ese grupo de administración.
• Cuando asignamos el rol Lector a un grupo en el ámbito de suscripción, los miembros de dicho grupo podrán ver todos los grupos de recursos y recursos dentro de esa suscripción.
• Cuando asignamos el rol Colaborador a una aplicación en el ámbito del grupo de recursos, dicha aplicación podrá administrar los recursos de cualquier tipo dentro de ese grupo de recursos específico, pero no los otros grupos de recursos dentro de esa suscripción.

¿Cuándo conviene usar RBAC de Azure?

Usaremos RBAC de Azure cuando necesitemos:

• Permitir que un usuario administre las VM en una suscripción y que otro usuario administre las redes virtuales.
• Permitir a un grupo de administradores de base de datos que administren bases de datos SQL de una suscripción
• Permitir que un usuario administre todos los recursos de un grupo de recursos, como las máquinas virtuales, los sitios web y las subredes
• Permitir que una aplicación acceda a todos los recursos de un grupo de recursos.

Estos son solo algunos ejemplos. Al final de este módulo hay una lista completa de roles integrados.

¿Cómo se aplica RBAC de Azure?

RBAC de Azure se aplica a cualquier acción que se inicie en un recurso de Azure que pasa por Azure Resource Manager. Resource Manager es un servicio de administración que proporciona una forma de organizar y proteger nuestros recursos en la nube.

Normalmente, se accede a Resource Manager a través de Azure Portal, Azure Cloud Shell, Azure PowerShell y la CLI de Azure. RBAC de Azure no aplica permisos de acceso en el nivel de aplicación ni de datos. La seguridad de la aplicación debe controlarla la propia aplicación.

RBAC emplea un modelo de permisos, es decir, cuando se nos asigna un rol, RBAC nos permite realizar determinadas acciones, como leer, escribir o eliminar. Si una asignación de roles nos concede permisos de lectura a un grupo de recursos y otra asignación de roles nos concede permisos de escritura al mismo grupo de recursos, tendremos permisos tanto de lectura como de escritura en ese grupo de recursos.

¿A quién se aplica RBAC de Azure?

RBAC de Azure se puede aplicar a una persona individual o a un grupo. También se puede aplicar a otros tipos de identidad especiales, como entidades de servicio e identidades administradas. Las aplicaciones y los servicios usan estos tipos de identidad para automatizar el acceso a los recursos de Azure.

Tailwind Traders tiene los siguientes equipos implicados en alguna parte de su entorno de TI general:

• Administradores de TI: este equipo tiene la propiedad definitiva de los recursos tecnológicos, tanto locales como en la nube. El equipo requiere un control completo de todos los recursos.
• Copia de seguridad y recuperación ante desastres: este equipo es responsable de administrar el estado de las copias de seguridad periódicas y de invocar cualquier recuperación de datos o del sistema.
• Coste y facturación: los miembros de este equipo realizan un seguimiento e informan sobre los gastos relacionados con la tecnología. También administran los presupuestos internos de la organización.
• Operaciones de seguridad: este equipo supervisa los incidentes de seguridad relacionados con la tecnología y responde a estos. El equipo requiere acceso continuo a los archivos de registro y a las alertas de seguridad.

¿Cómo se administran los permisos de RBAC de Azure?

Los permisos de acceso se administran en el panel Control de acceso (IAM) de Azure Portal. En este panel se muestra quién tiene acceso a qué ámbito y qué roles se aplican. En él también puede conceder o quitar cualquier tipo de acceso.

En la siguiente captura de pantalla se muestra un ejemplo del panel Control de acceso (IAM) de un grupo de recursos. En este ejemplo, Alain Charon tiene asignado el rol Operador de copias de seguridad en ese grupo de recursos.

MCT: Video 5.2.1: Control de Acceso basado en roles

• El control de acceso basado en roles de Azure conocido como RBAC
• Es un sistema de autorización creado en Azure Resources Manager
• Que brinda una administración de acceso a los recursos de Azure
• El funcionamiento es la creación de roles que permiten cumplir los permisos
• Una asignación de rol consta de 3 elementos
  • Entidad de seguridad: es un objeto que representa una usuario, grupo, identidad de servicio o identidad administrada que solicita acceso a los recursos de Azure
  • Definición del rol: es un conjunto de permisos y especifican las operaciones que se pueden realizar como leer, escribir y eliminar recursos. Los roles pueden ser de alto nivel como por ejemplo como el propietario o específicos como lector de MV y son la forma de controlar el acceso a los recursos de Azure. El control de acceso de Azure ya contiene una serie de roles predefinidos que pueden ser asignados a usuarios, grupos, identidades de servicio y identidades administradas y cuando estos no satisfacen las necesidades el cliente puede crear sus propios roles personalizados
  • Ámbito: es el conjunto de recursos donde se aplican los controles de acceso, es decir podemos indicarle a los roles cual será su ámbito. Existen 4 posibles ámbitos de forma jerárquica : Grupos de administración, Suscripciones, Grupos de recursos y Recursos

• Asignación de rol es el proceso de adjuntar un rol a un entidad de seguridad
• Puede crear roles por el portal CLI de Azure, PowerShell o SDK de Azure
• El control de acceso basado en roles usa modelos de permisos es decir cuando a un usuario se le asigna un roles se le están asignado un conjunto de permisos
• Es importante considera que se le asigna una una entidad de seguridad un permisos de lectura sobre un grupo o recurso y otro de escritura al mismo recurso o grupo tendrá permisos de lectura y escritura

• Es conveniente utilizar el control de acceso basado en roles RBAC cuando:
• un usuario administre las MV’s de un suscripción y otro usuario las redes virtuales
• Que administradores de Bases de Datos administren las BD’s de una suscripción
• Un que un usuario administre un grupo de recursos como MV’s, aplicaciones y redes
• O que una aplicación acceda a un grupo de recursos
• Entre otros

• En la siguiente imagen se muestra como funciona el RBAC
• Tenemos a 2 usuarios (entidades de seguridad) Alicia y Bob
• Alicia se le asigna el ámbito de propietario en la suscripción Y a bob de colaborador de datos de blob de almacenamiento en el ámbito de cuenta de almacenamiento
• Al Alicia tener un permisos mayor puede por ejemplo leer, eliminar contenedores
• Sin embargo Alicia no puede realizar operaciones de datos Blob sin pasos adicionales
• De forma predetermina no puede leer lo blob de un contenedor para esto debe recuperar las claves de almacenamiento usadas para acceder s los blob’s
• En cambio Bob tiene permisos en el área de Colaborador de datos blob y el si puede realizar los cambios directamente ya que así esta especificado por ejemplo leer, escribir y eliminar contenedores y blob’s

• Ejemplo para esto se debe tener una suscripción propia ya que no se puede asignar roles a suscripción Azure Student
• Si accedemos a el grupo de recursos podemos ver que tenemos la opción de «Control de acceso IAM»

• La seleccionamos y vemos que personas tiene acceso
• Si queremos asignar un rol que esta creado de manera predeterminada ingresamos a «Agregar asignación de roles»

• O la opción roles

• Aquí se listan todos los roles que están creados de forma predeterminada y que podemos asignar

• Vamos hacer que un usuario puede consultar un grupo de recursos
• Buscamos el permisos de «Lector» y le damos siguiente

• Nos abre una pantalla donde podemos seleccionar los usuarios o grupos

• Nos abre una ventana donde podemos buscar y selecionar el usuario

• Nuestro usuario se agrega

• Siguiente / Revisar y Crear
• Una vez se ha asignado el rol al usuario podemos ver que tiene acceso de lectura al grupo de recursos

Unidad 3: Uso de bloqueos de recursos para evitar cambios inintencionados

Los bloqueos de recursos impiden que se eliminen o modifiquen recursos por error.

Aun cuando haya directivas de control de acceso basado en roles de Azure (RBAC de Azure) en vigor, sigue existiendo el riesgo de que alguien con el nivel de acceso adecuado elimine recursos de nube críticos. Podríamos pensar en un bloqueo de recursos como un sistema de aviso que nos recuerda que un recurso no se debe eliminar o cambiar.

Por ejemplo, en Tailwind Traders, un administrador de TI se encuentra realizando una limpieza rutinaria de recursos no utilizados en Azure y, por error, elimina unos recursos que parecen no estar usándose, pero en realidad son recursos fundamentales en una aplicación que se emplea para promociones estacionales. ¿Cómo impiden los bloqueos de recursos que se produzca este tipo de incidentes en el futuro?

¿Cómo se administran los bloqueos de recursos?

Los bloqueos de recursos se pueden administrar en Azure Portal, PowerShell, la CLI de Azure o con una plantilla de Azure Resource Manager.

Para ver, agregar o eliminar bloqueos en Azure Portal, vaya a la sección Configuración del panel Configuración de cualquier recurso en Azure Portal.

En este ejemplo se muestra cómo agregar un bloqueo de recurso desde Azure Portal. En la siguiente unidad pondremos en práctica un bloqueo de recurso similar.

¿Qué niveles de bloqueo hay disponibles?

Podemos aplicar bloqueos a una suscripción, a un grupo de recursos o a un recurso individual. Puede establecer el bloqueo de nivel en CanNotDelete o ReadOnly.

• CanNotDelete significa que las personas autorizadas pueden seguir leyendo y modificando un recurso, pero no eliminarlo sin quitar primero el bloqueo.
• ReadOnly significa que las personas autorizadas pueden leer un recurso, pero no eliminarlo ni cambiarlo. Aplicar este bloqueo es como restringir a todos los usuarios autorizados a los permisos concedidos por el rol Lector en RBAC de Azure.

¿Cómo se elimina o cambia un recurso bloqueado?

Aunque los bloqueos impiden que se produzcan cambios por error, se pueden seguir realizando cambios realizando un proceso de dos pasos.

Para modificar un recurso bloqueado, primero hay que quitar el bloqueo. Tras quitarlo, podemos aplicar cualquier acción que podamos realizar de acuerdo a nuestros permisos. Este paso adicional nos permite llevar a cabo la acción, e impide que cualquier administrador pueda hacer algo de manera accidental.

Los bloqueos de recursos se aplican con independencia de los permisos RBAC. Es decir, aun siendo el propietario del recurso, tendremos que quitar el bloqueo antes de poder realizar la actividad bloqueada.

Combinación de bloqueos de recursos con Azure Blueprints

¿Qué ocurre si un administrador de la nube elimina un bloqueo de recurso por error? Si el bloqueo de recurso se quita, los recursos asociados correspondientes se podrán cambiar o eliminar.

Para que el proceso de protección sea más riguroso, podemos combinar bloqueos de recursos con Azure Blueprints. Azure Blueprints nos permite definir el conjunto recursos estándar de Azure que la organización necesita. Así, por ejemplo, podemos definir un plano técnico que especifique que debe haber un bloqueo de recursos determinado. Azure Blueprints puede reemplazar automáticamente el bloqueo de recursos si dicho bloqueo se quita.

Posteriormente en este módulo hablaremos más sobre Azure Blueprints.

MCT: Video 5.2.2: Bloqueo de recursos

• Los bloqueos de recursos se utilizan para evitar que los recursos sean eliminados o modificados de forma accidental

• Esto por que a pesar que hay directivas de control de acceso en Azure un usuario con permisos puede por accidente o desconocimiento eliminar o modificar un recurso por error
• Por eso se puede considerar como un sistema de avisos que le recuerda que un recurso no se debe eliminar o modificar
• De pueden definir por el portal de Azure, PowerShell, Azure CLI y Plantillas ARM

• Los bloqueos se pueden aplicar a una suscripción, grupos de recursos o un recurso
• Existen 2 niveles de bloqueos
  • CanNotDelete: los usuarios pueden leer y modificar un recurso pero no lo pueden eliminar
  • ReadOnly: y este solo pueden leerlo y no modificarlo o eliminarlo

• Lo bloqueos permiten realizar modificaciones estableciendo dos pasos:
  • Primero quitar el bloqueo
  • Y luego realizar la modificación

• Los bloqueos de recursos funcionan de manera independiente de los permisos de control de acceso esto quiere decir que aunque sea el propietario del recurso se debe quitar el bloqueo
• Que pasa su un administrador elimina un bloqueo por error, los recursos podrán ser modificados o eliminados, podemos reforzar la seguridad con Azure BlueSprints

¿Como habilitar un bloqueo en un recurso?

• Primero accedemos al grupo de recurso
• Luego en el menú de configuración -> Bloqueos

• Le damos Agregar
  • Un Nombre
  • Tipo de bloqueo

• Ahora si le damos eliminar

• Y para eliminar el bloqueo ingresamos a «Bloqueos» -> Eliminar

Unidad 4: Ejercicio: Uso de un bloqueo de recursos para impedir que una cuenta de almacenamiento se elimine por error

En este ejercicio, veremos cómo usar bloqueos de recursos para evitar que se eliminen recursos de Azure por error.

Para ello, crearemos un grupo de recursos desde Azure Portal (pensemos en un grupo de recursos como un contenedor de recursos de Azure relacionados). Después, agregaremos un bloqueo a ese grupo de recursos y confirmaremos que el grupo no se puede eliminar.

Por último, agregaremos una cuenta de almacenamiento a nuestro grupo de recursos y veremos cómo el bloqueo del grupo de recursos primario impide que esa cuenta de almacenamiento se elimine. Una cuenta de almacenamiento es un contenedor que agrupa un conjunto de servicios de almacenamiento de Azure.

Creación del grupo de recursos

Aquí crearemos un grupo de recursos denominado my-test-rg.

Abra Azure Portal e inicie sesión.

1. En la parte superior de la página, seleccione Grupos de recursos.
2. Seleccione + Nuevo. Aparece la página Crear un grupo de recursos.
3. En la pestaña Aspectos básicos, rellene los campos siguientes.
4. También puede seleccionar una región más cercana a la suya.
5. Seleccione Revisar y crear y, luego, Crear.

• Creamos el grupo de recursos

Adición de un bloqueo al grupo de recursos

Agregue un bloqueo de recurso al grupo de recursos. Para ello:

En Azure Portal, seleccione el grupo de recursos, GR-INA

En Configuración, seleccione Bloqueos y, luego, seleccione Agregar.

Rellene estos campos.

Seleccione Aceptar. Vemos que el bloqueo de recurso se aplica al grupo de recursos.

Se crea el bloqueo

Confirmación de que el grupo de recursos está protegido frente a eliminaciones

Aquí intentaremos eliminar el grupo de recursos para confirmar que está protegido.

En la parte superior de la página, seleccione my-test-rg para ir a la página de información general del grupo de recursos.

Seleccione Eliminar grupo de recursos.

En el símbolo del sistema, escriba my-test-rg y, luego, seleccione Aceptar. Aparecerá un mensaje que indica que el grupo de recursos está bloqueado y no se puede eliminar.

Protección de una cuenta de almacenamiento de eliminaciones por error

Ahora agregaremos una cuenta de almacenamiento a nuestro grupo de recursos y veremos cómo el bloqueo del grupo de recursos primario impide eliminar esa cuenta de almacenamiento. Para ello:

En Azure Portal, en la parte superior de la página, seleccione Inicio para volver a la página de inicio.

Seleccione Cuentas de almacenamiento. Luego, seleccione + Nuevo. Aparece la página Crear cuenta de almacenamiento.

En la pestaña Aspectos básicos, rellene los campos siguientes.

Como antes, en este caso también puede seleccionar una región más cercana a la suya.

Seleccione Revisar y crear y, luego, Crear. La implementación puede tardar un poco en completarse.

Haga clic en Go to resource (Ir al recurso).

En la parte superior de la página, seleccione Eliminar.

Aparecerá un mensaje que indica que el recurso o su grupo primario está bloqueado y no se puede eliminar. En este ejemplo se muestra el mensaje de error relativo a una cuenta de almacenamiento denominada mysa1234.

Aunque no hemos creado un bloqueo expresamente para esta cuenta de almacenamiento, el bloqueo que creamos para el grupo de recursos primario impide eliminar el recurso. En otras palabras, la cuenta de almacenamiento hereda el bloqueo del grupo de recursos primario.

Eliminación de un grupo de recursos y la cuenta de almacenamiento

Ya no necesitamos el grupo de recursos o la cuenta de almacenamiento, así que ahora los eliminaremos.

Cuando un grupo de recursos se elimina, también se eliminan sus recursos secundarios, como la cuenta de almacenamiento que creamos anteriormente.

Para eliminar el grupo de recursos, primero hay que quitar el bloqueo de recurso.

1. En Azure Portal, seleccione Inicio>Grupos de recursos>my-test-rg para ir al grupo de recursos.
2. En Configuración, seleccione Bloqueos.
3. Busque rg-delete-lock y seleccione Eliminar en esa misma fila.
4. Seleccione Información general y, después, Eliminar grupo de recursos.
5. En el símbolo del sistema, escriba my-test-rg y, luego, seleccione Aceptar. La operación de eliminación puede tardar un poco en completarse.
6. Cuando la operación finalice, seleccione Inicio>Grupos de recursos. Verá que el grupo de recursos my-test-rg ya no está en la cuenta y que la cuenta de almacenamiento también se ha eliminado.

Buen trabajo. Ya sabemos cómo usar bloqueos de recursos para evitar que se eliminen recursos de Azure por error.

Eliminamos

Unidad 5: Uso de etiquetas para organizar los recursos de Azure

A medida que el uso que hacemos de la nube va en aumento, es cada vez más importante mantenerse organizado. Una buena estrategia de organización nos ayudará a conocer cuál es nuestro uso de la nube, así como a administrar los costos.

Por ejemplo, a medida que Tailwind Traders concibe nuevas formas de implementar sus aplicaciones en Azure, necesita una manera de marcar sus entornos de prueba para poder identificar y eliminar fácilmente recursos en estos entornos cuando ya no sean necesarios.

Un método para organizar los recursos relacionados es colocarlos en sus propias suscripciones. También se pueden usar grupos de recursos para administrarlos. Las etiquetas de recursos son otra forma de organizar recursos. Las etiquetas proporcionan información extra, o metadatos, sobre los recursos. Estos metadatos son útiles para lo siguiente:

• Administración de recursos: las etiquetas permiten localizar recursos asociados a cargas de trabajo, entornos, unidades de negocio y propietarios específicos y actuar al respecto.
• Optimización y administración de costes: las etiquetas permiten agrupar recursos para que podamos informar sobre los costes, asignar centros de costes internos, mantener los presupuestos a raya y predecir costes estimados.
• Administración de operaciones: las etiquetas permiten agrupar recursos según la importancia que tiene su disponibilidad para nuestro negocio. Esta agrupación nos ayuda a formular acuerdos de nivel de servicio (SLA), que constituyen una garantía de rendimiento o de tiempo de actividad entre nosotros y nuestros usuarios.
• Seguridad: las etiquetas permiten clasificar los datos según su nivel de seguridad, por ejemplo, públicos o confidenciales.
• Gobernanza y cumplimiento normativo: las etiquetas permiten identificar los recursos que cumplen con los requisitos de gobernanza o cumplimiento normativo, como la norma ISO 27001. Las etiquetas también pueden formar parte de nuestros esfuerzos de aplicación de estándares. Así, podríamos exigir que todos los recursos se etiqueten con un nombre de departamento o propietario.
• Automatización y optimización de las cargas de trabajo: las etiquetas pueden servir para ver todos los recursos que participan en implementaciones complejas. Por ejemplo, podemos etiquetar un recurso con su nombre de aplicación o carga de trabajo asociado y usar un software como Azure DevOps para realizar tareas automatizadas en esos recursos.

¿Cómo se administran las etiquetas de recursos?

Podemos agregar, modificar o eliminar etiquetas de recursos a través de PowerShell, la CLI de Azure, plantillas de Azure Resource Manager, la API REST o Azure Portal.

Las etiquetas también se pueden administrar mediante Azure Policy. Por ejemplo, podemos usar etiquetas en un grupo de recursos, pero esas etiquetas no se aplican automáticamente a los recursos de ese grupo de recursos. Se puede usar Azure Policy para garantizar que un recurso herede las mismas etiquetas que su grupo de recursos primario. Posteriormente en este módulo hablaremos más sobre Azure Policy.

Azure Policy se puede usar también para aplicar reglas y convenciones de etiquetado. Así, podemos requerir que se agreguen determinadas etiquetas a los nuevos recursos a medida que se aprovisionan. Asimismo, podemos definir reglas que vuelvan a aplicar etiquetas que se han quitado.

Ejemplo de una estructura de etiquetado

Una etiqueta de recurso se compone de un nombre y un valor. Podemos asignar una o más etiquetas a cada recurso de Azure.

Después de revisar los requisitos empresariales, Tailwind Traders decide usar las siguientes etiquetas.

En este ejemplo se muestran estas etiquetas cuando se aplican a una máquina virtual durante el aprovisionamiento.

El equipo de Tailwind Traders puede ejecutar consultas (por ejemplo, con PowerShell o la CLI de Azure) para ver todos los recursos que contienen estas etiquetas.

Recordemos que no es necesario requerir que una etiqueta específica esté presente en todos los recursos. Por ejemplo, podemos decidir que solo los recursos críticos tengan la etiqueta Impact. De este modo, todos aquellos recursos que no estén etiquetados no se considerarán como críticos

MCT: Video 5.2.3: Descripción de la funcionalidad y uso de tags

• La organización de los recursos basados en la nube es una tarea importante

• Por eso se recomienda utilizar el estándar de nomenclatura y etiquetado
• Las etiquetas son metadatos asociados a los recursos que constas de cadenas pares clave:valor

• Estos dependen del usuario
• Las etiquetas pueden ser creadas desde

• Las etiquetas se pueden aplicar a un grupo de recursos pero estas no se heredan a sus hijos
• Y se puede tener más de una etiqueta
• Se pueden hacer etiquetas de
  • Funcionalidad: entorno en que se implementaron u otra funcionalidad
  • Clasificación: la forma en que se usan y las directivas que se le aplican
  • Control: permite asociar a grupos (departamentos) de la organización
  • Asociación: relaciona a los usuarios asociados al recurso
  • Propósito: relaciona el recursos con el propósito ante la organización
• Estos son ejemplos de etiquetas

Ejemplo de etiquetado

• Se crea un grupo de recursos para un servidor Web

Pasamos al siguiente paso Etiquetas

Si accedemos al recurso podemos consultar sus etiquetas

Creamos recurso (MV) dentro del grupo de recursos

También le podemos asignar etiquetas podemos agrega un grupo de etiquetas

Creamos el recurso

Podemos ir al grupo de recursos y ver que podemos filtrar por las etiquetas

si ingresamos al grupo de recurso vemos las etiquetas

y si accedemos al recurso y consultamos sus etiquetas y vemos que no se heredan las del padre

Unidad 6: Uso de Azure Policy para controlar y auditar recursos

En un ejercicio anterior de este módulo, ha identificado los requisitos empresariales y de gobernanza. ¿Cómo puede asegurarse de que estos recursos mantengan su cumplimiento? ¿Puede recibir un aviso cuando la configuración de un recurso cambie?

Azure Policy es un servicio de Azure que permite crear, asignar y administrar directivas que controlan o auditan recursos. Dichas directivas aplican distintas reglas en todas las configuraciones de los recursos para que esas configuraciones sigan cumpliendo con los estándares corporativos.

¿Cómo se definen directivas en Azure Policy?

Azure Policy permite definir tanto directivas individuales como grupos de directivas relacionadas, lo que se conoce como iniciativas. Azure Policy evalúa los recursos y resalta los que no cumplen las directivas que hemos creado. Azure Policy también puede impedir que se creen recursos no conformes.

Azure Policy incluye definiciones de iniciativas y directivas integradas para categorías como Almacenamiento, Redes, Proceso, Centro de Seguridad y Supervisión. Por ejemplo, si define una directiva que permite usar exclusivamente un determinado tamaño de SKU (referencia de almacén) para las máquinas virtuales (VM) en el entorno, esa directiva se invoca al crear una nueva máquina virtual y cada vez que se cambia el tamaño de las ya existentes. Azure Policy también evalúa y supervisa todas las máquinas virtuales que hay actualmente en el entorno.

En algunos casos, Azure Policy puede corregir automáticamente los recursos y configuraciones no conformes para garantizar la integridad del estado de los recursos. Por ejemplo, si todos los recursos de un determinado grupo de recursos deben etiquetarse con la etiqueta AppName y un valor de «SpecialOrders», Azure Policy volverá a aplicar automáticamente esa etiqueta si se ha quitado.

Azure Policy se integra con Azure DevOps aplicando directivas de integración continua y canalización de entrega que competen a las fases de implementación anterior y posterior de las aplicaciones.

Azure Policy en acción

La implementación de una directiva en Azure Policy conlleva tres tareas:

1. Crear una definición de directiva
2. Asignar la definición a los recursos
3. Revisar los resultados de evaluación

Vamos a examinar cada paso con más detalle.

Tarea 1: Crear una definición de directiva

Una definición de directiva expresa qué se debe evaluar y qué acción realizar. Por ejemplo, podemos impedir que se implementen máquinas virtuales en determinadas regiones de Azure. También podemos auditar nuestras cuentas de almacenamiento para comprobar que solo aceptan conexiones de redes permitidas.

Cada definición de directiva tiene condiciones que regulan su aplicación. Además, esta definición tiene un efecto complementario que se produce cuando se cumplen las condiciones. Estos son algunos ejemplos de definiciones de directiva:

• SKU de máquina virtual permitidas: esta directiva permite especificar un conjunto de SKU de máquina virtual que la organización puede implementar.
• Ubicaciones permitidas: esta directiva permite restringir las ubicaciones que la organización puede especificar al implementar los recursos. Su efecto se usa para exigir los requisitos de cumplimiento de replicación geográfica.
• MFA debe estar habilitado en las cuentas con permisos de escritura de la suscripción: esta directiva requiere que la autenticación multifactor (MFA) esté habilitada en todas las cuentas de la suscripción que tengan permisos de escritura, para evitar una vulneración de seguridad en esas cuentas o en los recursos.
• CORS no debe permitir que todos los recursos obtengan acceso a las aplicaciones web: el uso compartido de recursos entre orígenes (CORS) es una característica de HTTP que permite que una aplicación web que se ejecuta en un dominio acceda a recursos de otro dominio. Por motivos de seguridad, los exploradores web modernos restringen el scripting entre sitios de forma predeterminada. Esta directiva permite que solo los dominios necesarios interactúen con la aplicación web.
• Las actualizaciones del sistema deben estar instaladas en las máquinas: esta directiva permite a Azure Security Center recomendar las actualizaciones del sistema de seguridad que faltan en los servidores.

Tarea 2: Asignar la definición a los recursos

Para implementar nuestras definiciones de directiva, debemos asignar definiciones a los recursos. Una asignación de directiva es una definición de directiva que se aplica dentro de un ámbito específico. Este ámbito puede ser un grupo de administración (esto es, una colección de varias suscripciones), una sola suscripción o un grupo de recursos.

Todos los recursos secundarios dentro de ese ámbito heredarán las asignaciones de directivas. Si una directiva se aplica a un grupo de recursos, se aplicará también a todos los recursos dentro de ese grupo. Podemos excluir un subámbito de la asignación de directiva si hay recursos secundarios específicos que deban quedar fuera de la asignación de la directiva.

Tarea 3: Revisión de los resultados de la evaluación

Cuando una condición se evalúa con los recursos existentes, cada recurso se marca como conforme o no conforme. Esto nos permitirá revisar los resultados de directiva que no sean conformes y tomar las medidas oportunas.

La evaluación de la directiva se produce aproximadamente una vez cada hora. Si realizamos cambios en la definición de la directiva y creamos una asignación de directiva, dicha directiva se evaluará con los recursos en una hora.

¿Qué son las iniciativas Azure Policy?

Una iniciativa de Azure Policy es una forma de agrupar las directivas relacionadas. La definición de iniciativa contiene todas las definiciones de directiva para facilitar el seguimiento del estado de cumplimiento de cara a un objetivo mayor.

Por ejemplo, Azure Policy incluye una iniciativa denominada Habilitar la supervisión en Azure Security Center, cuyo objetivo es supervisar todas las recomendaciones de seguridad disponibles para todos los tipos de recursos de Azure en Azure Security Center.

En esta iniciativa se incluyen las siguientes definiciones de directiva:

• Supervisar base de datos SQL sin cifrar en Security Center: esta directiva supervisa servidores y bases de datos SQL sin cifrar.
• Supervisión de los puntos vulnerables del sistema operativo en Security Center: esta directiva supervisa los servidores que no cumplen la línea base de la vulnerabilidad del sistema operativo configurada.
• Supervisar la falta de Endpoint Protection en Security Center: esta directiva supervisa los servidores que no tienen instalado un agente de Endpoint Protection.

La iniciativa Habilitar la supervisión en Azure Security Center contiene más de 100 definiciones de directiva independientes, de hecho.

Azure Policy también incluye iniciativas que admiten normas de cumplimiento, como HIPAA e ISO 27001.

¿Cómo se define una iniciativa?

Las iniciativas se definen mediante Azure Portal o herramientas de línea de comandos. En Azure Portal, puede buscar en la lista de iniciativas integradas en Azure. O bien podemos crear nuestra propia definición de directiva personalizada.

En la siguiente imagen se muestran algunos ejemplos de iniciativas de Azure Policy en Azure Portal.

¿Cómo se asigna una iniciativa?

Al igual que una asignación de directiva, una asignación de iniciativa es una definición de iniciativa que se asigna a un ámbito específico de un grupo de administración, una suscripción o un grupo de recursos.

Aun cuando solo tengamos una directiva, una iniciativa nos permite aumentar el número de directivas a lo largo del tiempo. Dado que la iniciativa asociada permanece asignada, es más fácil agregar y quitar directivas sin necesidad de cambiar la asignación de directiva de los recursos.

MCT: Video 5.2.4: Descripción de la funcionalidad y uso de Azure Policy

• Azure Policy ayuda a aplicar los estándares de la organización y evaluar el cumplimiento
• Permite crear y administrar directivas que controlan y auditan recursos
• Estas directivas aplican reglas y efectos en la configuraciones de los recursos para que estos cumplan con los estándares que dicta la empresa
• Entre estas esta la gobernanza para la coherencia de los recursos, cumplimiento normativo, seguridad, costo y administración

• La definición de una directiva se da en 3 pasos:

1- Definición de directivas:

• Definen los detalles de cumplimiento de los recursos
• Que sucederá si se cumple una condición
• Son escritos en JSON
• Lo que hace es comparar un valor de un recurso con un valor requerido
• Para facilitar la administración estas directivas se pueden agrupar en «Iniciativa de Directiva» o «Policy Set»
• Y contienen los siguientes datos

2- Asignación:

• Una vez definidas las directivas o iniciativas el siguiente paso es asignar la un ámbito de recursos como Grupos de Administración, Suscripciones,1 Grupos de Recursos o recursos individuales
• Todas se aplican dentro de Resources Manager
• Si es necesario se pueden excluir sub-ámbitos

3- Revisar los resultados de evaluación

• Esto permite evaluar las directivas que se desean aplicar y tomar las medidas oportunas
• Azure utiliza un formato JSON para formar la lógica de la evaluación para ver si un recurso es compatible o no
• Los recursos de evalúan en momentos concretos de la vida de los recursos y estos son los eventos que hacen que se evalúe un recurso
  • Creación, actualización, eliminación de un recurso
  • Asignación de ámbito
  • Actualización de directiva:
  • 24 hrs y cuando se verifica el cumplimiento estándar que ocurre cada 24 hrs
• Cada vez que se cera una evaluación se genera una respuesta o efecto que puede ser generar cambios en los recursos, registrar el cambio en los recursos, modificar el recurso antes o después del cambio,

• Una iniciativa es una forma de agrupar las directivas relacionadas en un mismo conjunto facilitando el cumplimiento de un objetivo mayor

• Por ejemplo Azure tiene una iniciativa que se llama «Habilitar la Supervisión en Azure Security Center» con el objetivo de agrupar todas las recomendaciones de seguridad disponibles para todos los tipos de recursos
• Y también iniciativas para el cumplimiento de estándares ISO, entre otros

• La asignación de una iniciativa es asignar la iniciativa a un ámbitos específico como un Grupo de Administración, suscripción o grupo de recursos

• Las iniciativas tienen la ventaja sobre las directivas que es que se se asignan a un ámbito se pueden agregar, modificar u eliminar directivas sin tener que volver hacer la asignación
• Podemos utilizar la predefinidas o crea las nuestras

Ejemplo en Portal Azure

• Primero ingresamos a un grupo de recursos
• Un vez dentro dentro de «Configuración» -> «Directiva»

• Una vez dentro vemos que podemos crear «Directivas» o «Iniciativas»

• Le damos Asignar Directiva
• Aquí debemos completar el formulario
• Lo primero es el ámbito donde se aplicará
• Como vemos podemos aplicarla a la suscripción o limitarla a un grupo de recursos o recursos

• Podemos agregar exclusiones a los cuales no aplicar las directivas

• Luego debemos ingresar los datos de la directiva
• Definición de la directiva, si le damos en los «…» nos abre una ventana que contiene todas las definiciones predefinidas en Azure

• Vamos a buscar 2
• «Ubicaciones permitidas»: que permite limitar por regiones donde se pueden crear recursos
• Le damos agregar y se no cargan los datos

• Luego vemos que la directiva esta Habilitada
• Ahora el siguiente paso es definir las regiones que queremos estén habilitadas

• Y le damos «Revisar y Crear» -> Crear
• Podemos ver que la directiva se ha creado

• Ahora de puede ir al Grupo de recursos y crear una nuevo y determinar que solo puede crear en las regiones seleccionadas
• Así por ejemplo el error

• Ahora vamos hacer una nueva directiva que limite el número de SKU de MV’s que se pueden crear para así no acabar nuestra suscripción
• «Grupo de Recursos»->»Asignar Directiva»->»Ámbito»
• Ahora lo vamos a asignar no un recurso si no a la suscripción para esto debemos darle clic al botón «Borrar todas las selecciones»

• Se limpian los cambios

• Así le damos el botón de «Seleccionar» y sería toda la suscripción

• Ahora en Definición de directiva buscamos «SKU de tamaño de máquina Virtual»

• Le agregamos la descripción
• Vemos que esta habilitada
• y en parámetros seleccionamos los tamaños de MV’s (Standard_B1ls / Standard_B1ms / Standard_B20ms / Standard_B2ms)

• Revisar y crear (verificamos que se creo)
• Ahora en el grupo de recursos vamos a crear un nuevo recursos para que valide 2 directivas
• La primera es automática

• Y la segunda no es automática

• Continuamos configurando hasta revisar y crear
• donde da el error

• Para eliminar las se puede:
  • Ingresar donde se encuentre definida por ejemplo al grupo de Recursos
  • O buscar en la barra «Directivas» y se mostrarán todas las directivas

• En sus opciones esta «Eliminar»

Unidad 7: Ejercicio: Uso de Azure Policy para restringir las implementaciones a una ubicación específica

En este ejercicio, crearemos una directiva en Azure Policy que restrinja la implementación de recursos de Azure a una ubicación específica. Para comprobar que la directiva funciona, intentaremos crear una cuenta de almacenamiento en una ubicación que la infrinja.

Tailwind Traders quiere limitar la ubicación en la que se pueden implementar recursos a la región Este de EE. UU., Esto tiene dos motivos:

• Mejor seguimiento de costes: a fin de llevar un control de los costos, Tailwind Traders usa diferentes suscripciones para realizar un seguimiento de las implementaciones en cada una de sus ubicaciones regionales. La directiva garantizará que todos los recursos se implementan en la región Este de EE. UU.
• Cumplimiento de la seguridad y residencia de los datos: Tailwind Traders debe adherirse a una regla de cumplimiento que rige dónde se pueden almacenar datos de clientes. En este caso, los datos de clientes se deben almacenar en la región Este de EE. UU.

Recordemos que podemos asignar una directiva a un grupo de administración, a una sola suscripción o a un grupo de recursos. Aquí, asignaremos la directiva a un grupo de recursos, así no afectará a otros recursos de la suscripción a Azure.

Creación del grupo de recursos

Aquí crearemos un grupo de recursos denominado my-test-rg. Es el grupo de recursos al que aplicaremos la directiva de ubicación.

A efectos de aprendizaje, usaremos el mismo nombre de grupo de recursos que usamos en el ejercicio anterior. Podemos usar el mismo nombre porque eliminamos ese grupo de recursos anterior.

1. Vaya a Azure Portal e inicie sesión.
2. Seleccione Crear un recurso.
3. Escriba grupo de recursos en el cuadro de búsqueda y presione Entrar.
4. Si se le lleva a un panel de resultados de la búsqueda, seleccione Grupo de recursos en los resultados.
5. Seleccione Crear. Luego, escriba los valores siguientes para cada opción.
6. Seleccione Revisar y crear y, luego, Crear.

• Creamos

Exploración de directivas predefinidas

Antes de configurar nuestra directiva de ubicación, vamos a echar un vistazo a algunas directivas predefinidas. A modo de ejemplo, nos fijaremos en las directivas relacionadas con los servicios de Azure Compute.

1. En Azure Portal, en la parte superior de la página, seleccione Inicio para volver a la página de inicio.
2. En la parte superior de la página, escriba directiva en la barra de búsqueda y, luego, seleccione Directiva en la lista de resultados para acceder a Azure Policy.
3. En Creación, seleccione Definiciones.

• En la lista desplegable Categoría, seleccione únicamente Compute. Observe que la definición SKU de máquina virtual permitidas nos permite especificar un conjunto de SKU de máquina virtual que la organización puede implementar.

• Si lo desea, explore cualquier otra directiva o categoría que le interese.

Configuración de la directiva de ubicación

Aquí puede configurar la directiva de ubicación permitida mediante Azure Policy. A continuación, asigne esa directiva al grupo de recursos. Para ello:

En el panel Directiva, en Creación, seleccione Asignaciones-> «Asignar Directiva»

• Se le lleva al panel Asignar directiva.
• En Ámbito, seleccione los puntos suspensivos.
• Establezca lo siguiente en el cuadro de diálogo que aparece:
• En el campo Suscripción, su suscripción a Azure.
• En el campo Grupo de recursos, my-test-rg.
• Elija Seleccionar.

En Definición de directiva, seleccione los puntos suspensivos.

1. En la barra de búsqueda, escriba ubicación.
2. Seleccione la definición Ubicaciones permitidas.
3. Elija Seleccionar.

• Esta definición de directiva especifica la ubicación en la que todos los recursos deben implementarse. Si se elige otra ubicación, se producirá un error en la implementación.
• Seleccione Siguiente para ir a la pestaña Parámetros.
• En la lista desplegable Ubicaciones permitidas, seleccione Este de EE. UU.
• Seleccione Revisar y crear y, luego, Crear.

• Vemos que ahora la asignación de directiva Ubicaciones permitidas aparece en el panel Directiva | Asignaciones, y que esa directiva se aplica al grupo de recursos my-test-rg.

Comprobación de la directiva de ubicación

Aquí intentaremos agregar una cuenta de almacenamiento a nuestro grupo de recursos en una ubicación que infringe la directiva de ubicación.

1. En Azure Portal, en la parte superior de la página, seleccione Inicio para volver a la página de inicio.
2. Seleccione Crear un recurso.
3. Escriba cuenta de almacenamiento en el cuadro de búsqueda y presione Entrar.
4. Si se le lleva a un panel de resultados de la búsqueda, seleccione Cuenta de almacenamiento en los resultados.
5. Seleccione Crear. Luego, escriba los valores siguientes para cada opción.

Si antes seleccionó Este de Japón en la directiva de ubicación, seleccione una región diferente de la lista.

• Vemos el error de validación

Seleccione Revisar y crear y, luego, Crear.

Aparecerá un mensaje que indica que se ha producido un error en la implementación debido a una infracción de la directiva. También verá los detalles de la implementación.
En este ejemplo se muestran los detalles de implementación de una cuenta de almacenamiento denominada mysa1234.

Eliminación de la asignación de directiva

Ya no necesitamos la asignación de directivas, así que la quitaremos de la suscripción.

1. En Azure Portal, seleccione Inicio>Directiva.
2. En Creación, seleccione Asignaciones.
3. En la fila Ubicaciones permitidas, seleccione los puntos suspensivos y, luego, seleccione Eliminar asignación. Cuando se le solicite, seleccione Sí.

1. Verá que la asignación de directiva Ubicaciones permitidas ya no existe.

Como paso opcional, puede probar a crear la cuenta de almacenamiento una segunda vez para comprobar que la directiva ya no surta efecto alguno.

Eliminar el grupo de recursos

Ya no necesitamos el grupo de recursos, así que lo quitaremos de la suscripción.

1. En Azure Portal, seleccione Inicio>Grupos de recursos>my-test-rg para ir al grupo de recursos.
2. Seleccione Información general y, después, Eliminar grupo de recursos.
3. En el símbolo del sistema, escriba my-test-rg y, luego, seleccione Aceptar. La operación de eliminación puede tardar un poco en completarse.
4. Cuando la operación finalice, seleccione Inicio>Grupos de recursos. Verá que el grupo de recursos my-test-rg ya no está en la cuenta

¡Excelente trabajo! Ha aplicado una directiva correctamente con Azure Policy para restringir la implementación de recursos de Azure en ubicaciones específicas. Ahora puede aplicar las directivas que necesite en el nivel de grupo de administración, suscripción o grupo de recursos.

Unidad 8: Gobernanza de varias suscripciones con Azure Blueprints

Hasta ahora, hemos visto una serie de características de Azure que pueden servir para poner en marcha nuestras decisiones de gobernanza, supervisar el cumplimiento de los recursos en la nube, controlar el acceso y proteger los recursos críticos frente a posibles eliminaciones accidentales.

¿Qué ocurre cuando nuestro entorno de nube empieza a crecer por encima de una sola suscripción? ¿Cómo podemos escalar la configuración de estas características, sabiendo que deben aplicarse a los recursos de las nuevas suscripciones?

En lugar de tener que configurar características como Azure Policy en cada nueva suscripción, con Azure Blueprints puede definir un conjunto repetible de herramientas de gobernanza y recursos de Azure estándar que la organización necesita. De este modo, los equipos de desarrollo pueden crear e implementar rápidamente nuevos entornos sabiendo que se crean de acuerdo con los estándares organizativos con un conjunto de componentes integrados que aceleran las fases de desarrollo e implementación.

Azure Blueprints organiza la implementación de varias plantillas de recursos y de otros artefactos, como son los siguientes:

• Asignaciones de roles
• Asignaciones de directivas
• Plantillas de Azure Resource Manager
• Grupos de recursos

Azure Blueprints en acción

Cuando formamos un equipo de centro de excelencia en la nube o un equipo de administradores de nube, dicho equipo puede usar Azure Blueprints para escalar sus prácticas de gobernanza en toda la organización.

Para implementar un proyecto en Azure Blueprints hay que realizar estos tres pasos:

1. Crear una instancia de Azure Blueprints
2. Asignar ese plano técnico
3. Llevar un seguimiento de las asignaciones del plano técnico

Con Azure Blueprints, la relación entre la definición del plano técnico (lo que debe ser implementado) y su asignación (lo que se ha implementado) permanece. En otras palabras, Azure crea un registro que asocia un recurso con el plano técnico que lo define, y gracias a esta conexión podemos realizar el seguimiento y la auditoría de nuestras implementaciones.

Los planos técnicos también tienen versiones. El control de versiones nos permite llevar un control de los cambios que se producen en el plano técnico y comentarlos.

¿Qué son los artefactos de plano técnico?

Cada componente de la definición de un plano técnico se denomina artefacto.

Es posible que los artefactos no tengan parámetros adicionales (configuraciones). Un ejemplo es la directiva Implementar la detección de amenazas en servidores SQL Server, que no requiere ninguna configuración adicional.

Los artefactos también pueden contener uno o más parámetros que se pueden configurar. En la siguiente captura de pantalla se muestra la directiva Ubicaciones permitidas, que incluye un parámetro que especifica las ubicaciones que se pueden usar.

Puede especificar el valor de un parámetro al crear la definición del plano técnico o al asignar la definición del plano a un ámbito. De este modo, puede mantener un plano técnico estándar, pero con la flexibilidad suficiente para especificar los parámetros de configuración pertinentes en cada ámbito en el que se asigne la definición.

¿Cómo usarán Azure Blueprints en Tailwind Traders para cumplir con la norma ISO 27001?

ISO 27001 es una norma publicada por la Organización internacional de normalización, que rige la seguridad de los sistemas de tecnologías de la información (TI). Como parte de su proceso de calidad, Tailwind Traders quiere certificar que cumple con esta norma. Azure Blueprints cuenta con varias definiciones de plano técnico integradas relacionadas con ISO 27001.

Como administradores de TI, decidimos investigar la definición de la norma ISO 27001 de plano técnico de servicios compartidos. El esquema del plan es el siguiente:

1. Definir un grupo de administración llamado PROD-MG Recordemos que un grupo de administración se encarga de administrar el acceso, las directivas y el cumplimiento en varias suscripciones de Azure. Cada nueva suscripción de Azure que se cree se agregará a este grupo de administración.
2. Crear una definición de plano técnico según la norma ISO 27001 de plano técnico de servicios compartidos. A continuación, publique el plano técnico.
3. Asignar el plano técnico al grupo de administración PROD-MG

En la siguiente imagen se muestran los artefactos que se crean al ejecutar un plano técnico ISO 27001 a partir de una plantilla.

Como se aprecia en la imagen, la plantilla de plano técnico contiene asignaciones de directivas, plantillas de Resource Manager y grupos de recursos. El plano técnico implementa estos artefactos en las suscripciones existentes dentro del grupo de administración PROD-MG. También implementará estos artefactos en todas las suscripciones nuevas a medida que se vayan creando y agregando al grupo de administración.

MCT: Video 5.2.5: Descripción de la funcionalidad y uso de Azure Blueprints

• Azure Blueprints permite a los arquitectos de la nube y administradores de TI definir un conjunto de herramientas de gobernanza y recursos de Azure que cumplen con los estándares de la organización
• Los equipos de desarrollo pueden crear e implementar rápidamente nuevos entornos que se crean con los estándares de la organización
• Los planos técnicos son una manera declarativa de organizar la implementación de varias plantillas de recursos y otros artefactos como son:
  • Asignaciones de rol
  • Asignación de directivas
  • Plantillas de Azure Resources Manager
  • Grupos de recursos
• Además esta respaldado por Global Cosmos DB por lo que Azure Blueprints o planos técnicos se encuentra en varias regiones de Azure, proporcionando baja latencia, alta disponibilidad y acceso constante independientemente donde estén los recursos implementados

Diferencia entre plantilla ARM y BluePrints

• Una plantilla de Azure Resource Manager (ARM) es un archivo de denotación javascript (JSON) en el que podemos automatizar las implementaciones y utilizar la práctica de Infraestructura como Código IaC
• Casi todo que se se desea incluir en una plano técnico de BluePrints se puede definir con una plantilla de ARM, por ejemplo crear cualquier recurso de Azure o crear directivas de la organización, sin embargo una plantilla de ARM no es objeto que existe de manera nativa en Azure cada una se almacena de manera local o dentro del código fuente y se utiliza para la creación de uno o varios recursos pero una vez creado el recurso no hay relación con la plantilla
• Con BluePrints la relación de la definición del plano técnico (lo que debe ser implementado) y su asignación (lo que se ha implementado) permanece
• Esta conexión permite mejorar el seguimiento,, auditoria de las implementaciones
• Además BluePrints puede actualizar varias suscripciones a la vez que se rigen por el mismo plano técnico

Diferencia entre Azure Policy y BluePrints

• Azure Policy es un sistema de denegación explicita y permisos predeterminados que se centran en las propiedades de los recursos durante su creación y para los recurso que están administrados por Azure Policy
• La inclusión de una directiva dentro de un plano técnico permite crear el patrón o diseño correcto de la asignación del plano
• Una inclusión de una directiva en el plano técnico garantiza que solo se puedan realizar cambios aprobados o esperados dentro de la normativa del plano técnico
• Entonces podemos decir que Azure Policy puede ser un artefacto dentro de un pano técnico
• Es una herramienta para componer un conjunto de estándares, patrones, seguridad, requisitos y coherencias específicos de la implementación de la nube de Azure
• BluePrints permite definir parámetros de directivas e iniciativas

Implemetación

• Cuando creamos un equipo de administración en la nube, este puede utilizar BluePrints escalar sus prácticas de gobernanza en toda la organización y aprovechar funcionalidades de este servicio para su administración ya que existe una relación del recurso con el plano técnico que lo definió
• Y gracias a esa relación podemos realizar el seguimiento y auditoria de nuestras implementaciones
• Además los planos técnicos tienen control de versiones lo que nos permite llevar un control de los cambios
• Para crear un proyecto en BluePrints se deben seguir los siguientes pasos:
  • Crear una instancia:
  • Asignar el plano técnico
  • Llevar un seguimiento de asignaciones
• Azure crea un registro que asocia el recurso con el plano técnico que lo creo

Recursos admitidos como artefactos

• Al crear la definición de un plan técnico se debe definir donde se guardará el borrador para poder utilizarlos posteriormente al publicarlo y se pueden guardar en una suscripción, Grupo de Recursos o un Grupo de Administración
• Y una vez guardado seta disponible para asignárselo a una suscripción secundaria de ese grupo de Administración
• Y para cada plano técnico podemos definir los siguientes artefactos:
  • Grupos de Recursos: es el primero que se crean y estas disponibles para que los puedan utilizar otros artefactos del plano y permite definir como exactamente se deben estructurar los recursos y proporcionan un limitador de ámbito para roles y directivas así como plantillas de ARM
  • Plantillas ARM: permiten crear entornos complejos por ejemplo una granja de servidores SharePoint o un área de Logic Analityc
  • Asignación de políticas: permite asignar una iniciativa o directiva a la suscripción
  • Asignación de roles: permiten asignar roles a uno o conjuntos de usuarios garantizando el acceso se pueden definir para toda la suscripción o recursos específicos

Unidad 9: Aceleración del uso de la nube con Cloud Adoption Framework para Azure

Cloud Adoption Framework para Azure sirve como guía consolidada para ayudar en el recorrido para la adopción de la nube. Cloud Adoption Framework ayuda a crear e implementar las estrategias empresariales y tecnológicas necesarias para usar la nube correctamente.

Tailwind Traders necesita controlar su entorno de nube de manera que cumpla con varios estándares del sector, pero no tiene muy claro por dónde empezar. Tienen diversos requisitos empresariales, y son conscientes de que estos requisitos están ligados a sus cargas de trabajo locales. También las cargas de trabajo que se ejecuten en la nube deben cumplir con estos requisitos.

Se nos ha asignado la tarea de investigar qué hay disponible en Azure y de definir e implementar una estrategia de gobernanza para Tailwind Traders. Decidimos empezar con Cloud Adoption Framework.

¿Qué se incluye en Cloud Adoption Framework?

• Al implementar la nube debe garantizar que se cumplen con las regularizaciones y gobernaciones necesarias y ser fácil de administrar

• Implementar la nube requiere muchas decisiones que pueden tener un gran impacto
• Cloud Adoption Framework lo guía en la implementación de la nube

• En cinco etapas

• Y cuanta con una gran documentación, guías, mejores prácticas y herramientas para cada una de las etapas

1-) Definición de Estrategia

• Aquí se define por que se quiere migrar a la nube
• Y que desea esperar
• Y con que proyecto iniciar

2-) Hacer un plan

• Donde se establece las metas para acciones específicas
• Se definen elementos claves y cargas de trabajo que desea migrar a la nube

• Se definen quienes se necesitan involucrar y que habilidades se requieren y cual seria la meta final

3-) Etapa lista

• Se creará un ambiente de Azure listo para sus cargas de trabajo
• Este ambiente le permite estructurar sus suscripciones, recursos compartidos, herramientas, gobernanza, administración de finanzas, capacidades de seguridad

4-) Adopción de la nube

• Aquí se migran las primeras cargas de trabajo a Azure utilizando la guía de migración y procesos de mejora

5-) Gobernanza y Administración

• Se ofrecen herramientas de puntos de referencia y mejoras de las prácticas y gobernanza y administración de la nube

Continuamos

Como se ha mencionado en el vídeo, Cloud Adoption Framework se compone de diversas herramientas, documentación y procedimientos de eficacia probada. Cloud Adoption Framework incluye estas fases:

1. Definir la estrategia.
2. Crear un plan.
3. Preparar la organización.
4. Adoptar la nube.
5. Controlar y administrar los entornos de nube.

La fase de control se centra en la gobernanza en la nube. Cloud Adoption Framework se puede consultar como referencia para obtener instrucciones recomendadas mientras traza su estrategia de gobernanza en la nube.

A modo de ayuda para crear la estrategia de adopción, Cloud Adoption Framework desglosa cada fase en una serie de ejercicios y pasos. Echemos un vistazo a cada una de estas fases.

Definición una estrategia

En esta fase abordaremos los motivos por los que estamos trasladándonos a la nube y qué queremos obtener con la migración a la nube. ¿Necesitamos escalar para satisfacer la demanda o llegar a nuevos mercados? ¿Se reducirán los costes o aumentará la agilidad empresarial? Al definir la estrategia empresarial en la nube, conviene comprender aspectos como la economía de la nube, así como sopesar el impacto empresarial, el tiempo de respuesta, el alcance global, el rendimiento, etc.

Estos son los pasos de esta fase.

Creación un plan

En esta fase crearemos un plan que establece una correspondencia entre los objetivos que aspiramos alcanzar y acciones concretas. Un buen plan nos puede ayudar a garantizar que nuestros esfuerzos se corresponden con los resultados empresariales que buscamos.

Estos son los pasos de esta fase.

Preparación de la organización

En esta fase crearemos una zona de aterrizaje, dicho de otro modo, un entorno en la nube donde empezar a hospedar nuestras cargas de trabajo.

Estos son los pasos de esta fase.

Adopción de la nube

En esta fase empezaremos a migrar nuestras aplicaciones a la nube. A lo largo del proceso, probablemente encontremos formas de modernizar nuestras aplicaciones y crear soluciones innovadoras que usen servicios en la nube.

Cloud Adoption Framework divide esta fase en dos partes: migrar e innovar.

Migrar: estos son los pasos de la parte de migración de esta fase.

Innovar: estos son los pasos de la parte de innovación de esta fase.

Control y administración de los entornos de nube

En esta fase empezaremos a trazar nuestras estrategias de administración y gobernanza en la nube. A medida que el patrimonio de la nube cambia con el tiempo, también lo hacen los procesos y las directivas de gobernanza de la nube. Deberemos crear soluciones resistentes que se optimicen constantemente.

Gobernanza: estos son los pasos de la parte de gobernanza de esta fase.

Administración: estos son los pasos de la parte de administración de esta fase.

Unidad 10: Creación de una estrategia de gobernanza de suscripciones

Al comienzo de cualquier implementación de gobernanza en la nube, se debe identificar una estructura de la organización en la nube que cubra las necesidades empresariales. A menudo, este paso implica la conformación de un equipo centro de excelencia en la nube (también denominado equipo de habilitación de la nube o equipo de custodia de la nube). Este equipo está capacitado para implementar prácticas de gobernanza desde una ubicación centralizada para toda la organización.

A menudo, los equipos inician su estrategia de gobernanza de Azure en el nivel de suscripción. Hay tres aspectos principales que deben considerarse al crear y administrar suscripciones: facturación, control de acceso y límites de suscripción.

Vamos a echar un vistazo a cada uno de ellos con más detalle.

Facturación

Se puede crear un informe de facturación por suscripción. Si tenemos varios departamentos y necesitamos realizar un «contracargo» de costes en la nube, una posible solución es organizar las suscripciones por departamento o por proyecto.

Las etiquetas de recursos también pueden ser de ayuda. Las etiquetas se explorarán más adelante en este módulo. Al definir cuántas suscripciones se necesitan y cómo denominarlas, debemos tener en cuenta los requisitos de facturación internos.

Control de acceso

Una suscripción es un límite de implementación de los recursos de Azure. Cada suscripción está asociada a un inquilino de Azure Active Directory. Cada inquilino proporciona a los administradores la capacidad de configurar un acceso granular a través de roles definidos por medio del control de acceso basado en roles de Azure.

Al diseñar la arquitectura de suscripciones, hay que tener en cuenta el factor de límite de la implementación, por ejemplo, ¿necesitamos suscripciones independientes para los entornos de desarrollo y producción? Con suscripciones independientes, es posible controlar el acceso a cada una de ellas por separado y aislar los recursos entre sí.

Límites de suscripción

Las suscripciones también tienen algunas limitaciones de recursos. Por ejemplo, el número máximo de circuitos Azure ExpressRoute de red por cada suscripción es de 10. Estos límites se deben tener en cuenta durante la fase de diseño. Si necesitamos superar estos límites, puede que tengamos que agregar más suscripciones. Si alcanzamos un límite máximo estricto, no hay flexibilidad para aumentarlo.

Los grupos de administración también están disponibles para ayudar a administrar las suscripciones. Un grupo de administración se encarga de administrar el acceso, las directivas y el cumplimiento en varias suscripciones de Azure. Nos adentraremos en los grupos de administración más adelante en este módulo.

Unidad 11: Prueba de conocimientos

Considere el siguiente escenario:

Tailwind Traders ha creado entornos de desarrollo y pruebas para su sistema de comercio electrónico.

En este diagrama se muestran los componentes básicos de proceso, base de datos y red que hay en cada entorno.

Estos entornos permiten al equipo compilar y probar nuevas características de aplicaciones. Si ha realizado el módulo Planeación y administración de los costes de Azure, ya habrá visto este diseño.

Aunque los equipos de desarrollo y pruebas informan a diferentes departamentos, ambos entornos pertenecen a la misma suscripción de Azure.

El responsable de TI quiere implementar controles de gobernanza que ayuden a garantizar que solo los usuarios autorizados acceden a estos sistemas. Poner estos controles en marcha les servirá también para administrar y mantener a raya los costes operativos.

Elija la respuesta más adecuada para cada pregunta. Después, seleccione Comprobar las respuestas.