Casi todas las semanas hay noticias de un incidente de ciberseguridad con una empresa importante. De la misma manera que ha utilizado varias formas de automatización para hacer crecer o replicar sus aplicaciones y datos, los atacantes automatizan sus propias acciones. Es improbable que una sola persona trate de comprometer la seguridad de sus sistemas de forma manual. Este concepto dificulta la defensa de sus sistemas 24 horas al día, 7 días a la semana y 365 días al año (está bien, o 366 días).
El capítulo anterior analizó cómo cifrar sus datos y VM. Este proceso es un gran primer paso, y hemos analizado brevemente cómo crear y utilizar las claves de cifrado almacenadas con el servicio Azure Key Vault. Los datos seguros, como claves, secretos y certificados, se almacenan de mejor manera en un almacén digital como un almacén de claves, que puede administrar, emitir y auditar de forma centralizada el uso de sus credenciales y datos críticos. A medida que sus aplicaciones y servicios requieren acceso a diferentes recursos, pueden solicitar, recuperar y utilizar automáticamente estas claves, secretos y credenciales. En este capítulo, aprenderá por qué y cómo crear un almacén de claves seguro, controlar el acceso y, a continuación, almacenar y recuperar secretos y certificados.

Protección de la información en la nube
A medida que las aplicaciones se tornan más complejas y crece el riesgo de ciberataques, la seguridad se convierte en una parte fundamental de cómo diseñar y ejecutar sus servicios. Asegurarse de minimizar el riesgo del acceso a datos no autorizados, en especial cuando ejecuta más aplicaciones orientadas a Internet, ya sea locales o en la nube, debe ser una de las principales áreas de diseño en las que enfocarse. No tiene sentido tener la mejor pizzería del mundo si los clientes no confían en usted para entregarle sus detalles de pago o información personal.
Una manera común de proporcionar seguridad para las aplicaciones y los servicios es a través de claves digitales, secretos y certificados, como se muestra en la figura. En lugar de usar un nombre de usuario y una contraseña que se deben introducir manualmente una y otra vez, o, quizás peor, escribirlas en un archivo de configuración sin cifrar, se utiliza un almacén digital para almacenar de forma segura estas credenciales y datos. Cuando una aplicación o servicio requiere acceso, solicita la clave o secreto específico que necesita, y también se crea un registro de auditoría para rastrear cualquier posible uso indebido o incumplimiento de la seguridad.

Cuando se diseñan e implementan correctamente, estos almacenes digitales están automatizados casi por completo y seguros. Los servicios pueden solicitar un nuevo certificado digital, emitir uno que se almacene de forma segura en el almacén y usarlo para autorizarse contra otros componentes de la aplicación. Los servidores pueden configurar el software al recuperar secretos como contraseñas del almacén digital y, a continuación, instalar componentes de la aplicación, sin que las credenciales se almacenen en un archivo de configuración basado en texto. Un administrador de aplicaciones puede administrar de forma centralizada todos los secretos, claves y certificados de un servicio y actualizarlos periódicamente según sea necesario.
Azure Key Vault proporciona todas estas características de seguridad digital y le permite controlar de cerca qué usuarios y recursos pueden acceder a los datos seguros. Los almacenes de claves se pueden replicar de forma segura para redundancia y mejorar el rendimiento de las aplicaciones, e integrarse con recursos comunes de Azure, como VM, aplicaciones web y cuentas de Azure Storage.

Almacenes de software y módulos de seguridad de hardware
Antes de pasar de lleno a un ejemplo práctico de cómo crear y utilizar un almacén de claves, es importante comprender la forma en que se almacena la información segura en un almacén. Como se muestra en la figura, todas las claves, secretos y certificados de un almacén de claves se almacenan en un módulo de seguridad de hardware (HSM). Estos dispositivos no son únicos en Azure, sino que son dispositivos de hardware de toda la industria que proporcionan un alto nivel de seguridad para los datos almacenados en ellos.

En la actualidad, puede usar hay dos tipos de almacenes de claves: protegido por software y protegido por HSM. La diferencia puede ser confusa, por lo que quiero aclararlo antes de comenzar:
– Un almacén protegido por software almacena claves, secretos y certificados en un HSM, pero todas las operaciones criptográficas que se requieren para cifrar o descifrar su contenido las realiza la plataforma Azure en el software. Los almacenes protegidos por software son excelentes para escenarios de desarrollo y pruebas, aunque puede decidir que las cargas de trabajo de producción requieren una forma ligeramente más segura de realizar las operaciones criptográficas.
– Un almacén protegido por HSM almacena claves, secretos y certificados en un HSM, y las operaciones criptográficas que se requieren para cifrar o descifrar su contenido se realizan directamente en el HSM. También puede generar sus propias claves seguras en un HSM local y, a continuación, importarlas a Azure. Hay algunas herramientas y procesos adicionales que seguir, pero de esta manera se asegura de que usted tiene el control absoluto de las claves y que nunca saldrán del límite de HSM.
Para maximizar la seguridad y la integridad de sus datos, los almacenes protegidos por hardware son el enfoque preferido para las cargas de trabajo de producción.
Independientemente del tipo de almacén que utilice, es importante recordar que todos sus datos se almacenan de forma segura en un HSM con el estándar federal de procesamiento de información (FIPS) 140–2 nivel 2 validado (como mínimo), y que Microsoft no puede acceder o recuperar sus claves. Hay un costo adicional para que los almacenes protegidos por HSM, así como con cualquier cosa en Azure y la informática en la nube, equilibren el costo frente al riesgo de que sus datos se vean comprometidos.

Creación de un almacén de claves y secreto
Un almacén digital suena muy bien, pero puede sentirse un poco inseguro respecto a cómo hacer uso de la energía que proporciona Azure Key Vault. Creemos un ejemplo de un servidor básico que ejecuta una base de datos como el servidor MySQL, como se muestra en la figuara.

Uno de los primeros ejercicios de este libro fue crear una VM y luego instalar la pila del servidor web LAMP. Es probable que se le haya solicitado una contraseña para el servidor MySQL, o se utilizó automáticamente una contraseña en blanco. Ahora que sabe todo acerca de los almacenes de claves, puede recuperar de manera automática una contraseña del almacén y usarla dinámicamente para instalar y configurar el servidor.

Pruébelo ahora
Para crear un almacén de claves y agregar un secreto, complete los siguientes pasos:
1 Abra Azure Portal; inicie Cloud Shell; y cree un grupo de recursos, como azuremolchapter15:
az group create –name azuremolchapter15 –location eastus
2 Cree un almacén de claves con un nombre único, como azuremol, y habilítelo para la implementación a fin de que pueda utilizarlo para inyectar claves y certificados en una VM:
az keyvault create \
–resource-group azuremolchapter15 \
–name azuremol \
–enable-soft-delete \
–enabled-for-deployment
De forma predeterminada, a su cuenta de usuario Azure se le asignan permisos completos para el almacén de claves. Para estos ejercicios, eso está bien, aunque como un procedimiento recomendado de seguridad debe considerar limitar quién puede acceder a su almacén de claves. Puede agregar el parámetro –no-self-perms para omitir la asignación de permisos a su cuenta.
3 Cree un secreto, como databasepassword, y asigne un valor de contraseña, como SecureP@ssw0rd. (Sí, realmente seguro, ¿cierto?) Este secreto se puede utilizar como las credenciales para un servidor de base de datos, que se implementará en los siguientes ejercicios:
az keyvault secret set \
–name databasepassword \
–vault-name azuremol \
–description «Database password» \
–value «SecureP@ssw0rd»
4 Tiene permisos completos para el almacén de claves, para que pueda ver el contenido de su secreto:
az keyvault secret show \
–name databasepassword \
–vault-name azuremol
Desde una perspectiva de administración, también puede realizar acciones comunes como hacer una copia de seguridad y restaurar, descargar, actualizar y eliminar los elementos almacenados en un almacén de claves. Una propiedad adicional que configuró cuando se creó el almacén de claves es la opción de enable-soft-delete. Si sus aplicaciones y servicios no pueden recuperar los secretos que necesitan del almacén de claves, es posible que deba lidiar con una enorme interrupción de la aplicación. Un almacén de claves puede almacenar metadatos para secretos hasta 90 días después de que realmente se eliminan, lo que le permite recuperar datos que se eliminan de forma incorrecta o malintencionada.
5 Elimine la clave que acaba de crear para simular un error, o posiblemente alguien con intenciones malintencionadas:
az keyvault secret delete \
–name databasepassword \
–vault-name azuremol
6 Recupere el secreto para que pueda continuar utilizando la contraseña de la base de datos con su aplicación y servicios:
az keyvault secret recover \
–name databasepassword \
–vault-name azuremol
Si realmente desea eliminar un secreto, también tiene la opción de purgar un secreto eliminado. Esta opción elimina permanentemente el secreto sin esperar a que transcurra el período de recuperación predeterminado de 90 días.
No dude en volver a usar az keyvault secret show para ver la información sobre su secreto y confirmar que la contraseña que guardó está allí. Ahora, continuaremos para ver cómo una VM puede acceder a un almacén de claves y utilizar el secreto para instalar el servidor MySQL.

Identidades administradas para recursos de Azure
La capacidad de utilizar Azure Key Vault para almacenar secretos o claves es excelente, pero ¿cómo acceder a estos secretos? La CLI de Azure o Azure PowerShell pueden acceder a la información almacenada en un almacén de claves, pero a menudo es más conveniente permitir que las máquinas virtuales o las aplicaciones recuperen directamente los secretos o las claves cuando las necesiten. Una manera de hacerlo es con identidades administradas para los recursos de Azure, como se muestra en la figura.

Una identidad administrada le permite crear un tipo especial de cuenta que puede usar un recurso de Azure, como una VM. Si ha utilizado un servicio de directorio como Active Directory, a menudo se utiliza una cuenta de equipo para identificar y conceder acceso a varios recursos de red que necesita un equipo. Usted no crea y utiliza cuentas de usuario habituales para este tipo de autenticación, lo que mejora la seguridad: por ejemplo, se puede conceder un conjunto restrictivo de permisos a un único equipo en lugar de preocuparse por los permisos de usuario y el acceso a carpetas compartidas.
Una identidad administrada es como una cuenta de equipo, pero se almacena en Azure Active Directory (Azure AD). La identidad, denominada entidad de servicio, es exclusiva de cada máquina virtual y se puede utilizar para asignar permisos a otros recursos de Azure, como una cuenta de Azure Storage o almacén de claves. La VM tiene permisos para acceder a esos recursos, por lo que puede realizar tareas de script (como con Azure Automation, que exploraremos en el capítulo 18) que no requieren intervención del usuario ni avisos para los nombres de usuario y contraseñas. Las máquinas virtuales se autentican y la plataforma Azure autoriza el acceso a sus recursos asignados.
Puede crear dos tipos de identidades administradas:
– Asignada por el sistema: este tipo de identidad administrada se aplica directamente a un recurso, como una máquina virtual, y solo la utiliza ese recurso. Cada recurso cuenta con su propia identidad cuando se trata de auditar o solucionar el acceso. Cuando se elimina el recurso, la identidad administrada se elimina automáticamente.
– Asignada por el usuario: se crea y administra un recurso Azure independiente para la identidad administrada especificada. Esta identidad administrada puede compartirse con otros recursos para definir el acceso. Cuando se elimina cualquier recurso que use la identidad, la identidad administrada sigue estando disponible para su uso.
Veamos cómo se puede utilizar una identidad administrada asignada por el sistema para solicitar el secreto databasepassword desde un almacén de claves. Una vez que la VM puede recuperar el secreto, la contraseña se puede utilizar para instalar automáticamente un servidor de base de datos MySQL. Con un almacén de claves y MSI, puede ejecutar un par de comandos para recuperar el secreto del almacén de claves, ejecutar el instalador del servidor MySQL y proporcionar automáticamente la contraseña segura.

Azure Instance Metadata Service
Una VM habilitada con una identidad administrada utiliza un punto de conexión REST a través de Instance Metadata Service (IMDS) para solicitar un token de acceso de Azure AD que luego puede utilizar para solicitar datos de Azure Key Vault. Pero, ¿qué es Instance Metadata Service?
IMDS es un punto de conexión REST que solo es accesible internamente para las máquinas virtuales. El punto de conexión está disponible en la dirección no enrutable de Azure Instance Metadata Service
Una VM habilitada con una identidad administrada utiliza un punto de conexión REST a través de Instance Metadata Service (IMDS) para solicitar un token de acceso de Azure AD que luego puede utilizar para solicitar datos de Azure Key Vault. Pero, ¿qué es Instance Metadata Service?
IMDS es un punto de conexión REST que solo es accesible internamente para las máquinas virtuales. El punto de conexión está disponible en la dirección no enrutable de 169.254.169.254. Una VM puede hacer una solicitud al punto de conexión IMDS para recuperar información sobre sí misma, como la región Azure o el nombre del grupo de recursos. Esta capacidad permite a la VM entender cómo y dónde se está ejecutando la plataforma Azure. Se puede acceder al punto de conexión IMDS desde muchos lenguajes, incluidos Python, C#, Go, Java y PowerShell.
Para los eventos de mantenimiento, también se puede consultar el punto de conexión IMDS para que la VM tenga conocimiento de una actualización pendiente o de un evento de reinicio. Luego, pueden llevarse a cabo las tareas previas a la actualización o el reinicio. Dado que IMDS es un punto de conexión REST en una dirección IP no enrutable, no hay ningún agente o extensión para que instale la VM, y no hay problemas de seguridad de red o enrutamiento.
A efectos de la identidad administrada, el punto final de IMDS se utiliza para transmitir la solicitud de un token de acceso a Azure AD. Este enfoque proporciona una manera segura para que las máquinas virtuales soliciten acceso sin necesidad de hablar directamente con Azure AD.

Pruébelo ahora
Para crear una VM con una MSI, complete los pasos siguientes:
1 Cree una VM de Ubuntu; a continuación, proporcione su grupo de recursos, como azuremolchapter15 y dé un nombre a la VM, como molvm. Se crea una cuenta de usuario denominada azuremol, y las claves SSH que ha utilizado en capítulos anteriores se agregan a la VM:
az vm create \
–resource-group azuremolchapter15 \
–name molvm \
–image ubuntults \
–admin-username azuremol \
–generate-ssh-keys
2 Como un procedimiento recomendado de seguridad, no debe permitir que las cuentas accedan a todos los recursos a través de toda su suscripción a Azure. Especialmente para las identidades administradas, solo conceda la cantidad mínima de permisos necesarios.
Para este ejercicio, abarque el acceso solo a su grupo de recursos, como azuremolchapter15. Se establece el alcance mediante la consulta del identificador del grupo de recursos con –query id. A continuación, este identificador se asigna a una variable llamada scope:
scope=$(az group show –resource-group azuremolchapter15
➥–query id –output tsv)
3 Cree una identidad administrada asignada por el sistema para la VM con el rol de lector para que solo pueda leer recursos, no hacer cambios en ellos. Abarque la identidad en el grupo de recursos. Se proporciona la variable que creó en el paso anterior que contiene el identificador de grupo de recursos:
az vm identity assign \
–resource-group azuremolchapter15 \
–name molvm \
–role reader \
–scope $scope
4 Aplique los permisos en Azure Key Vault que concede el acceso al principal de servicio para la identidad administrada. Puede hacerlo mediante el portal bajo Directivas de acceso para el recurso de Key Vault, o bien puede utilizar la CLI de Azure. Utilicemos la CLI para ver cómo obtener la información mediante programación.
Primero, obtenga información sobre la entidad de servicio de Azure AD para su identidad administrada. Filtre por display-name de la VM que creó en el paso 3, como molvm:
az ad sp list \
–display-name molvm \
–query [].servicePrincipalNames
La salida es similar al siguiente ejemplo condensado. No se preocupe demasiado por lo que significan estos valores; no tiene que trabajar con ellos más allá de asignar los permisos iniciales aquí. Una vez más, puede utilizar Azure Portal para evitar la CLI si no se siente cómodo.
Tome nota del primer servicePrincipalName. Este valor se utiliza para asignar permisos en los recursos de Azure, como su almacén de claves y se requiere en el siguiente paso:
[
«887e9665-3c7d-4142-b9a3-c3b3346cd2e2»,
«https://identity.azure.net//
➥ihxXtwZEiAeNXU8eED2Ki6FXRPkklthh84S60CiqA4=»
]
5 Ahora defina la directiva de acceso en el almacén de claves de modo que la entidad de servicio de su VM pueda leer secretos e ingrese su primer servicePrincipalName del paso 4:
az keyvault set-policy \
–name azuremol \
–secret-permissions get \
–spn 887e9665-3c7d-4142-b9a3-c3b3346cd2e2
Un punto que señalar aquí es que cuando se creó la identidad administrada y se abarcó al grupo de recursos, eso no significó que la VM podría entonces hacer lo que quisiera. En primer lugar, la única función creada para la identidad era leer los permisos de los recursos. Pero todavía tenía que asignar permisos al propio almacén de claves. Estas capas de seguridad y permisos le dan un control preciso sobre los recursos exactos a los que puede acceder cada identidad.
Ahora que tiene acceso a un almacén de claves, es probable que desee saber cómo recuperar el secreto, ¿cierto?

Obtención de un secreto dentro de una máquina virtual con identidad de servicio administrado
Ha almacenado un secreto en un almacén de claves para una contraseña de base de datos, y tiene una VM con una identidad administrada que proporciona acceso para leer ese secreto en el almacén de claves. ¿Y ahora qué? ¿Cómo recupera el secreto y lo usa? En la figura se muestra cómo una VM utiliza IMDS para solicitar acceso a un recurso, como un almacén de claves. Recorramos los pasos para ver cómo la VM recupera el secreto.
La mayoría de los casos prácticos de Azure Key Vault no tendrían una VM conectándose y recuperando los secretos de esta manera. Key Vault realmente se destaca cuando las propias aplicaciones, dentro del código, llegan a recuperar los secretos. El código de la aplicación utilizaría el SDK de Azure apropiado, como Python, .Net o Java. Para evitar la complejidad del código que abstrae lo que está sucediendo, el siguiente ejercicio utiliza una VM y algo de trabajo de línea de comandos. Mientras trabaje en este ejercicio, recuerde que esta magia suele ocurrir dentro del código de la aplicación.

Pruébelo ahora
Para recuperar y utilizar un secreto en una VM con una identidad administrada, complete los pasos siguientes:
1 Obtenga la dirección IP pública de la VM que creó en el ejercicio anterior, como molvm:
az vm show \
–resource-group azuremolchapter15 \
–name molvm \
–show-details \
–query [publicIps] \
–output tsv
2 SSH para su VM, como ssh azuremol@publicIps.
3 Para acceder a un almacén de claves, necesita un token de acceso. Este token de acceso se solicita desde IMDS. Es una solicitud HTTP y en una VM de Linux puede utilizar el programa curl para hacer la solicitud. IMDS pasa su solicitud a AAD:
curl ‘http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net’
➥-H Metadata:true
4 La salida es un poco difícil de leer, porque se ve como un texto desordenado. Está en el formato de JSO Web Token (JWT). Para procesar la salida JSON y permitir que las cosas sean más legibles para el ser humano, instale un analizador JSON llamado jq:
sudo apt-get update && sudo apt-get -y install jq
5 Haga su solicitud curl otra vez, pero ahora vea la salida con jq:
curl ‘http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net’
➥-H Metadata:true –silent | jq
En estos primeros pasos se muestra cómo se hacen las solicitudes y cuál es la apariencia de la salida, como se muestra en la figura. Si todavía inicia sesión en la VM y solicita manualmente un token de acceso, ¿qué sentido tiene utilizar una identidad administrada? Podría simplemente proporcionar sus propias credenciales. En el uso de producción, es probable que utilice un script que se ejecuta en la VM para hacer la solicitud de un token de acceso automáticamente y, a continuación, recuperar el secreto del almacén de claves. Seguiremos adelante para ver cómo automatizar este proceso y recuperar el secreto.

6 Para facilitar las cosas, y si iba a hacer todo esto en un script, puede utilizar jq para procesar la respuesta curl, extraer solo el token de acceso y establecerlo como una variable denominada access_token:
access_token=$(curl
➥’http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net’
➥-H Metadata:true –silent | jq -r ‘.access_token’)
7 Como paso manual para ayudarlo a entender cómo se ve esto, vea la variable access_token:
echo $access_token
8 ¡Ahora la parte divertida! Utilice el token de acceso para solicitar su secreto desde el almacén de claves. Primero, hagamos esto manualmente para que entienda lo que sucede.
9 Recupere el secreto con otra solicitud curl, y dé formato a la salida con jq. Introduzca su propio nombre de almacén de claves al principio de https:// address:
curl https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H «Authorization: Bearer $access_token»
➥–silent | jq
La salida es similar a lo siguiente, que muestra el valor de la contraseña almacenada en el secreto, junto con algunos metadatos adicionales sobre el secreto sobre los que no necesita preocuparse por ahora:
{
«value»: «SecureP@ssw0rd!»,
«contentType»: «Database password»,
«id»:
➥»https://azuremol.vault.azure.net/secrets/databasepassword/
➥87e79e35f57b41fdb882c367b5c1ffb3″,
}
Esta solicitud curl es la segunda parte del flujo de trabajo, como se muestra en la figura:

10 De la misma manera que usó una variable para almacenar el token de acceso, en un script también puede asignar el valor del secreto a una variable. Esta vez, utilice jq para procesar la respuesta, extraer solo el secreto del valor y establecerlo como una variable denominada database_password:
database_password=$(curl
➥https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H «Authorization: Bearer $access_token»
➥–silent | jq -r ‘.value’)
11 Una vez más, como paso manual para ayudarle a entender el proceso, vea el contenido de la variable database_password:
echo $database_password
Espero que nos siga. Si, por ejemplo, escribe una aplicación en Python, ASP.NET o Node.js, el proceso será similar al realizar una solicitud para el token de acceso y, a continuación, utilizar el token para solicitar un secreto desde un almacén de claves. Hay otras bibliotecas que podría utilizar en su código en lugar de la utilidad jq de la línea de comandos.
Como resumen rápido, todos estos pasos pueden condensarse en dos líneas, como se muestra en la siguiente lista.
Listado 15.1 Solicitud de un token de acceso y luego un secreto desde un almacén de claves
access_token=$(curl
➥’http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net’
➥-H Metadata:true –silent | jq -r ‘.access_token’)
database_password=$(curl
➥https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H «Authorization: Bearer $access_token»
➥-silent | jq -r ‘.value’)
¿Y ahora qué? La identidad administrada para su VM puede recuperar un secreto de un almacén de claves. Veamos cómo puede utilizar esa identidad administrada para instalar y configurar MySQL Server.
En Ubuntu, puede configurar selecciones de configuración para los instaladores de paquetes, como el servidor MySQL. Estas selecciones de configuración le permiten proporcionar valores como nombres de usuario y contraseñas, y usarlas automáticamente en la parte pertinente del proceso de instalación. Se terminan las solicitudes manuales para proporcionar una contraseña, como puede haber visto en el capítulo 2.
12 Defina las selecciones de configuración para las contraseñas del servidor MySQL con la variable database_password que creó en el paso 10:
sudo debconf-set-selections <<< «mysql-server mysql-server/root_password
➥password $database_password»
sudo debconf-set-selections <<< «mysql-server mysql-
➥server/root_password_again password $database_password»
13 Instale el servidor MySQL. No hay avisos, porque las selecciones de configuración proporcionan la contraseña:
sudo apt-get -y install mysql-server
14 Demostremos que todo esto funcionó. Visualice la variable database_password para que pueda ver claramente cuál debe ser su contraseña:
echo $database_password
15 Inicie sesión en el servidor MySQL. Cuando se le solicite una contraseña, introduzca el valor de database_password, que es el valor del secreto del almacén de claves:
mysql -u root -p
Inició sesión en el servidor MySQL, lo que confirma que el secreto del almacén de claves se usó para crear con éxito las credenciales de SQL Server.
16 Escriba exit dos veces para cerrar el símbolo del sistema del servidor MySQL, y luego cierre su sesión SSH en la VM.
Este ejemplo es básico, y todavía necesitaría proteger el servidor MySQL y proporcionar credenciales adicionales para que las aplicaciones accedan a bases de datos o tablas. La ventaja de utilizar un secreto desde un almacén de claves es que usted garantiza que todas las contraseñas son las mismas. Por ejemplo, si utiliza conjuntos de escala de máquinas virtuales, cada instancia de VM puede solicitar automáticamente el secreto e instalar el servidor MySQL para que esté listo para servir los datos de la aplicación. Esas contraseñas nunca se definen en scripts y nadie necesita ver cuáles son las contraseñas. Incluso podría generar contraseñas al azar y rotarlas como secretos en un almacén de claves.
Almacenar contraseñas en un almacén de claves está muy bien, pero ¿puede utilizar un almacén de claves para almacenar certificados y recuperarlos automáticamente desde sus aplicaciones o máquinas virtuales? ¡Claro que puede!

Creación e inyección de certificados
Los certificados digitales son una forma común de seguridad y autenticación en los servicios y aplicaciones web. Una entidad de certificación (CA) emite los certificados, la que (esperamos) sea de confianza para los usuarios finales. El certificado les permite a los usuarios comprobar que un sitio web o aplicación es realmente lo que dice que es. Cada vez que ve un sitio web con una dirección de navegador web que comienza con https:// and has a padlock symbol, the traffic is encrypted anse protege mediante un certificado digital.
La administración de certificados digitales puede convertirse en una tarea de administración importante. Un problema común es cómo almacenar y conceder acceso a certificados, ya que los servicios y las aplicaciones los necesitan. En los ejercicios anteriores, examinamos cómo se puede utilizar un almacén de claves para compartir secretos y claves seguros con servicios y aplicaciones, pero un almacén de claves también puede hacer lo mismo con certificados. Como se muestra en la figura 15.8, se puede utilizar un almacén de claves para solicitar, emitir y almacenar certificados.
En el uso de producción, siempre debe utilizar una CA de confianza para emitir sus certificados. Para uso interno, puede emitir certificados autofirmados que usted mismo cree.

Estos certificados autofirmados no son de confianza para otros servicios y aplicaciones, por lo que normalmente generan una advertencia, pero los certificados autofirmados le permiten ponerse en marcha rápidamente y asegurarse de que el código funciona según lo esperado con el tráfico cifrado.
Azure Key Vault puede generar certificados autofirmados para usted. Por debajo, Key Vault actúa como su propia CA para solicitar, emitir y almacenar certificados. Usemos esta capacidad para generar un certificado autofirmado y ver cómo inyectarlo fácilmente en una VM. El certificado se utiliza para que un servidor web básico le muestre cómo habilitar SSL rápidamente para proteger su tráfico web.

Pruébelo ahora
Para crear e inyectar un certificado en una VM, complete los pasos siguientes:
1 Cree un certificado autofirmado en Azure Key Vault y escriba un nombre, como molcert. Las directivas se utilizan para definir propiedades como períodos de caducidad, intensidad de cifrado y formato de certificado. Puede crear diferentes directivas para adaptarse a las necesidades de sus aplicaciones y servicios. Para este ejercicio, utilice la directiva predeterminada que crea un certificado de 2048 bits y es válido durante un año:
az keyvault certificate create \
–vault-name azuremol \
–name molcert \
–policy «$(az keyvault certificate get-default-policy)»
2 Para ver el certificado en acción, cree otra VM, como molwinvm. Esta vez, cree una VM de Windows que utiliza Windows Server 2019, a fin de que extienda el encanto del sistema operativo y vea que estas funciones de Key Vault no dependen de un sistema operativo específico. Proporcione su propio nombre de usuario y contraseña de administrador:
az vm create \
–resource-group azuremolchapter15 \
–name molwinvm \
–image win2019datacenter \
–admin-username azuremol \
–admin-password P@ssw0rd1234
3 Puede agregar automáticamente el certificado a la VM directamente desde la CLI de Azure. Este enfoque no está basado en una identidad administrada; la plataforma Azure inyecta el certificado mediante el agente de VM de Windows Azure.
Agregue su certificado, como molcert, a la VM que creó en el paso 2, como molwinvm:
az vm secret add \
–resource-group azuremolchapter15 \
–name molwinvm \
–keyvault azuremol \
–certificate molcert
4 Conéctese a la VM y compruebe que el certificado se inyectó correctamente. Para conectarse a su VM, primero obtenga su dirección IP pública:
az vm show \
–resource-group azuremolchapter15 \
–name molwinvm \
–show-details \
–query [publicIps] \
–output tsv
Utilice un cliente de conexión de Escritorio remoto de Microsoft en el equipo para conectarse a la VM. Utilice las credenciales para conectarse a localhost\azuremol, no las credenciales predeterminadas del equipo local que su cliente de Escritorio remoto puede intentar utilizar, como se muestra en la figura.

5 Cuando haya iniciado sesión, seleccione el botón Inicio de Windows, escriba mmc y abra la Microsoft Management Console.
6 Seleccione Archivo > Agregar o quitar complemento y, a continuación, seleccione la opción para agregar el complemento Certificados.
7 Seleccione para agregar certificados para la cuenta de equipo, seleccione Siguiente y, a continuación, Finalizar.
8 Seleccione Aceptar para cerrar la ventana Agregar o quitar complemento.
9 Expanda la carpeta Certificados (equipo local) > Personal > Certificados. Se enumera el certificado de Azure Key Vault que inyectó en la VM; por ejemplo, CLIGetDefaultPolicy, como se muestra en la figura.

¡Eso es todo! Cree el certificado en Key Vault y, a continuación, agréguelo a la VM. El certificado se coloca en el almacén de certificados local del equipo, lo que permite que cualquier servicio o aplicación acceda a este. En una VM de Windows, los certificados se almacenan en la memoria caché de certificados local, como se ve en este ejercicio. En las máquinas virtuales de Linux, los archivos .prv y .crt para las partes privadas y públicas del certificado se almacenan en/var/lib/waagent/. Puede mover los certificados a donde los necesite para su aplicación o servicio.
Los certificados pueden utilizarse para la autenticación entre clientes y servidores, o entre componentes de aplicaciones y servicios. Un ejemplo común es que un servidor web utilice un certificado SSL, que es lo que hará en el laboratorio del fin del capítulo.

Laboratorio: Configuración de un servidor web seguro
En el último ejercicio, se inyectó un certificado autofirmado de Azure Key Vault en una VM de Windows. Para este laboratorio, instale y configure el servidor web IIS para utilizar el certificado, siguiendo esta guía:
1 Abra PowerShell en la VM de Windows e instale el servidor web de IIS:
Add-WindowsFeature Web-Server -IncludeManagementTools
2 Abra el Administrador de Internet Information Server (IIS). Puede hacerlo desde el menú Herramientas del Administrador de servidores.
3 Para el sitio web predeterminado, elija Modificar enlaces.
4 Agregue un vínculo HTTPS en todas las direcciones IP no asignadas en el puerto 443.
5 Seleccione el certificado autofirmado que creó e inyectó desde Key Vault, normalmente con el nombre CLIGetDefaultPolicy.
6 Abra un navegador web en la VM y escriba https://localhost. Generó un certificado autofirmado en Key Vault, por lo que el navegador web no confía en él.
7 Acepte la advertencia para continuar y compruebe que el enlace HTTPS funciona.
8 De nuevo en Azure Cloud Shell o el portal, cree una regla de NSG para la VM en el puerto TCP 443. Escriba https://yourpublicipaddress en el navegador web de su equipo local. Esta es la experiencia que sus usuarios recibirían, con una advertencia sobre un certificado autofirmado que no es de confianza. Para la mayoría de los casos de uso, recuerde utilizar una entidad de CA interna o de terceros para generar certificados de confianza y almacenarlos en un almacén de claves.

Por hoy terminamos, la proxima semana mas!!!!