Libro de cocina Azure

Capítulo 1. Seguridad Seguridad

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Las violaciones de datos ocurren con frecuencia hoy en día. Hackers y usuarios malintencionados atacan los sistemas informáticos de pequeñas, medianas y grandes organizaciones. Estos ataques cuestan millones de dólares cada año, pero el coste no es el único daño. Las empresas atacadas aparecerán en las noticias durante días, semanas o incluso años, y pueden sufrir daños permanentes en su reputación y su base de clientes. En la mayoría de los casos, seguirán las demandas judiciales.

Puede que tengas la impresión de que los servicios de nube pública son muy seguros. Al fin y al cabo, empresas como Microsoft gastan millones de dólares en mejorar la seguridad de sus plataformas. Pero las aplicaciones y los sistemas de datos alojados en la nube pública de Microsoft (así como en las nubes de otros proveedores) no son inmunes a los ciberataques. De hecho, son más propensos a las violaciones de datos debido a la naturaleza pública de la nube.

Es fundamental comprender que la seguridad en la nube es una responsabilidad común compartida entre Microsoft Azure y tú. Azure proporciona seguridad física del centro de datos, directrices, documentación y potentes herramientas y servicios para ayudarte a proteger tus cargas de trabajo. Es tu responsabilidad configurar correctamente la seguridad de los recursos. Por ejemplo, Azure Cosmos DB puede configurarse para aceptar tráfico sólo de una red específica, pero el comportamiento por defecto permite todos los clientes, incluso de la Internet pública.

Consejo

La seguridad en la nube es un tema en evolución. Microsoft Azure sigue introduciendo nuevas funciones de seguridad para proteger tus cargas de trabajo frente a nuevas amenazas. Microsoft mantiene la documentación sobre buenas prácticas y patrones de seguridad de Azure, que puedes consultar para conocer las buenas prácticas de seguridad más actualizadas.

Hemos elegido la seguridad como tema del primer capítulo de este libro para transmitir este importante mensaje: ¡La seguridad debe ser lo primero! Debes tener la seguridad en mente mientras diseñas, implementas y das soporte a tus proyectos en la nube. En este capítulo, compartiremos recetas útiles que muestran cómo asegurar los servicios clave de Azure y, a continuación, utilizaremos los resultadosde estasrecetas a lo largo del libro.

Advertencia

En este capítulo cubrimos temas importantes de la seguridad de Azure. Sin embargo, no es posible cubrir todos los temas relacionados con la seguridad de Azure. Los servicios y capacidades de Azure siguen evolucionando a diario. Debes consultar la documentación de Microsoft para obtener una lista completa y actualizada.

Configuración del puesto de trabajo

Tendrás que preparar tu estación de trabajo antes de empezar con las recetas de este capítulo. Sigue las instrucciones de "Lo que necesitarás" para configurar tu máquina para ejecutar los comandos de la CLI de Azure. Clona el repositorio GitHub del libro utilizando el siguiente comando:

git clone https://github.com/zaalion/AzureCookbook.git

Crear un nuevo usuario en tu cuenta Azure

Problema

La cuenta Propietario (administrador ) tiene muchos más permisos de los necesarios para las tareas cotidianas de desarrollo. Necesitas crear una nueva cuenta de usuario para un desarrollador con los permisos justos para completar las tareas asignadas.

Solución

En primer lugar, crea un nuevo usuario en tu Azure Active Directory(Azure AD). A continuación, asigna a ese usuario la función de control de acceso basado en roles (RBAC) de Colaborador, de modo que se le asignen suficientes permisos sin conceder a este usuario el mismo nivel de permisos que al Propietario. En la Figura 1-1 se muestra un diagrama de arquitectura de la solución.

Figura 1-1. Asignar un rol integrado a usuarios/grupos de Azure AD

Pasos

1. Inicia sesión en tu suscripción a Azure con el rol de Propietario. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Visita la página Directorio predeterminado | Visión general en el portal de Azure para encontrar el nombre de dominio principal de tu inquilino de Azure Active Directory, como se muestra en la Figura 1-2.

Figura 1-2. Encontrar el dominio principal de tu inquilino de Azure AD

3. Crea un nuevo usuario en Azure AD. Sustituye <password> por la contraseña deseada y <aad-tenant-name> por el nombre de dominio de tu inquilino de Azure AD. Puede ser el nombre de dominio predeterminado que termina en onmicrosoft.com, o un dominio personalizado registrado en tu Azure Active Directory (por ejemplo, zaalion.com):

   password="<password>"
   
   az ad user create \
     --display-name developer \
     --password $password \
     --user-principal-name developer@<aad-tenant-name>

Advertencia

Utiliza una contraseña segura con letras minúsculas y mayúsculas, números y caracteres especiales. Elegir una contraseña segura es el primer paso, y el más importante, para proteger tususcripción a Azure.

4. La cuenta de usuario que has creado no tiene permisos. Puedes solucionarlo asignándole un rol RBAC de Azure. En esta receta, utilizaremos el rol incorporado Colaborador, pero puedes elegir cualquier rol que se ajuste a tus necesidades. El rol RBACde Colaborador concede acceso completo a los recursos, pero no permite asignar roles en Azure RBAC ni gestionar asignaciones de Azure Blueprints. Asignas un rol RBAC a un asignado, sobre un ámbito. En nuestro caso, el asignado es el usuario que acabas de crear, el nombre del rol es Colaborador y el ámbito es la suscripción Azure actual. En primer lugar, almacena el ID de tu suscripción en una variable:

   subscriptionId=$(az account show \
     --query "id" --output tsv)
   
   subscriptionScope="/subscriptions/"$subscriptionId

5. Utiliza el siguiente comando CLI para asignar el rol Colaborador a la cuenta de usuario desarrollador@<aad-nombre-del-teniente>. Si se te pide que instales la extensión Cuenta, responde Y. Ya puedes utilizar la nueva cuenta de desarrollador para completar las recetas de este libro:

   MSYS_NO_PATHCONV=1 az role assignment create \
     --assignee "developer@<aad-tenant-name>" \
     --role "Contributor" \
     --scope $subscriptionScope

Consejo

Git Bash traduce automáticamente los ID de los recursos a rutas de Windows, lo que hace que este comando falle. Simplemente añade MSYS_NO_PATHCONV=1 delante del comando para desactivar temporalmente este comportamiento. Consulta la documentación de Bash para más detalles.

6. Ejecuta el siguiente comando para comprobar la nueva asignación de funciones. En el resultado, busca el campo roleDefinitionId. Su valor debe terminar en /role​Def⁠ini⁠tions/b24988ac-6180-42a0-ab88-20f7382dd24c, que es el ID de definición del rol de Colaborador:

   az role assignment list \
     --assignee developer@<aad-tenant-name>

Debate

No es una buena práctica de seguridad en utilizar una cuenta con privilegios elevados, como la de Propietario (administrador), para realizar tareas cotidianas de desarrollo, monitoreo y pruebas. Por ejemplo, un desarrollador encargado únicamente de leer los datos de un contenedor Cosmos DB no necesita permisos sobre otros recursos de la suscripción.

Azure tiene varios roles RBAC incorporados para servicios generales y específicos. El rol RBAC de Colaborador da acceso a todos los servicios de Azure. Puedes utilizar roles específicos de servicio si tu usuario sólo necesita trabajar con un único servicio. Por ejemplo, el rol Operador de Cosmos DB sólo permite gestionar una base de datos Cosmos DB. Consulta la documentación de Microsoft para obtener una lista completa de roles incorporados.

Advertencia

Conceder a un usuario un nivel de acceso superior al necesario es una receta para el desastre. Tienes que identificar qué tareas necesita realizar un usuario, y sólo conceder el acceso necesario a su cuenta. Esto se conoce como el principio del menor privilegio.

En esta receta, asignamos el rol Colaborador a nuestra cuenta de usuario desarrollador. Esto permite a nuestro usuario gestionar todos los servicios de Azure excepto los roles RBAC y la asignación de Blueprints. Consulta la documentación sobre el rol RBAC de Colaborador para obtener más detalles. Si los roles RBAC integrados en Azure no se ajustan exactamente a tus necesidades, puedes crear roles RBAC personalizados y asignarlos a los usuarios. Veremos esto en la siguiente receta.

Crear un nuevo rol personalizado para nuestro usuario

Problema

En necesitas conceder un conjunto limitado de permisos a un usuario, grupo o entidad principal de Azure AD. No hay ningún rol RBAC de Azure incorporado que ofrezca estos permisos exactos.

Solución

En primer lugar, crea un rol Azure personalizado y, a continuación, asigna el rol a los usuarios, grupos o responsables (consulta la Figura 1-3).

Figura 1-3. Asignar un rol personalizado a un usuario/grupo de Azure AD

Pasos

1. Inicia sesión en tu suscripción a Azure con el rol de Propietario. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Toma nota de la cuenta de usuario que creaste en "Crear un nuevo usuario en tu cuenta de Azure". Más adelante en esta receta, asignaremos nuestro rol personalizado a este usuario.

3. Cuando define un rol personalizado, debes especificar un ámbito. El nuevo rol sólo estará disponible en los ámbitos indicados. Un ámbito puede ser una o varias suscripciones o grupos de gestión de Azure. Ejecuta el siguiente comando para encontrar el ID de tu suscripción actual:

   subscriptionId=$(az account show \
     --query "id" --output tsv)
   
   subscriptionScope="/subscriptions/"$subscriptionId
   
   echo $subscriptionScope

4. Necesitamos un rol personalizado de Azure que permita a los usuarios leer blobs de datos encuentas de almacenamiento de Azure. Crea un archivo JSON con el siguiente contenido, nómbraloCustomStorageDataReader.json y guárdalo en tu máquina. A continuación, sustituye <subscription-scope> por el valor de la variable $subscriptionScope del paso anterior. Como sólo necesitamos leer blobs, la única acción que tenemos queañadir es Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. Consulta la documentación de Microsoft para ver la lista completa de Actions y DataActions que puedes utilizar en tus roles personalizados:

   {
     "Name": "Custom Storage Data Reader",
     "IsCustom": true,
     "Description": "Read access to Azure storage accounts",
     "DataActions": [
       "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
     ],
     "AssignableScopes": [
       "<subscription-scope>"
     ]
   }

Consejo

Asegúrate de que los Actions se añaden a la sección correcta del archivo JSON. Estas secciones incluyen Actions, DataActions, Not​A⁠ctions, y NotDataActions. Consulta "Entender las definiciones de rol de Azure" para obtener más detalles sobre las secciones de rol.

5. Ya tenemos lista la definición del rol personalizado, así que ahora podemos crear el rol personalizado:

   az role definition create \
     --role-definition CustomStorageDataReader.json

6. Tu rol RBAC personalizado de ya está creado y se puede asignar a usuarios o grupos del mismo modo que se asignan los roles incorporados. En nuestro caso, el asignado es el usuario que creaste anteriormente, el nombre del rol es Lector de datos de almacenamiento personalizado y el ámbito es la suscripción Azure actual. Además de a usuarios y grupos, puedes asignar roles de Azure a otras entidades principales de Azure AD, como identidades gestionadas y registros de aplicaciones.

7. Utiliza el siguiente comando CLI para asignar el rol Lector de Datos de Almacenamiento Personalizado a la cuenta de usuario desarrollador:

   MSYS_NO_PATHCONV=1 az role assignment create \
     --assignee "developer@<aad-tenant-name>" \
     --role "Custom Storage Data Reader" \
     --scope $subscriptionScope

El usuario desarrollador tiene ahora acceso de lectura a todos los blobs de la cuenta Azure Storage de tu suscripción.

Debate

Los roles personalizados son perfectos para situaciones en las que necesitas asignar exactamente la cantidad adecuada de permisos a un usuario. También se puede conceder acceso a múltiples servicios utilizando roles personalizados. Los archivos JSON de definición de roles pueden almacenarse en un sistema de control de origen e implementarse mediante Azure CLI, Azure PowerShell o incluso plantillas ARM. Puedes asignar varias funciones RBAC a un usuario o grupo. Nuestro usuario de prueba tiene asignadas las funciones de Colaborador y Lector de Datos de Almacenamiento Personalizado. En escenarios del mundo real, tendrás que eliminar el rol de Colaborador de tu usuario, porque otorga muchos más permisos en comparación con el rol personalizado.

Nota

Puede que exista un rol incorporado que satisfaga las necesidades del usuario y no le dé más permisos de los necesarios. Asegúrate de consultar la documentación de Microsoft sobre roles integrados antes de invertir tiempo en crear un rol personalizado.

Asignación de tipos de recursos Azure permitidos en una suscripción

Problema

En tienes que limitar los tipos de recursos de Azure que pueden crear los usuarios de la suscripción.

Solución

Asigna la política Azure "Tipo de recurso permitido" a los ámbitos de grupo de gestión, suscripción o grupo de recursos, con la lista de tipos de recursos permitidos como parámetro de la política. En la Figura 1-4 se muestra un diagrama de arquitectura de esta solución.

Figura 1-4. Asignar una política Azure a un ámbito

Pasos

1. Inicia sesión en tu suscripción a Azure con el rol de Propietario. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Primero necesitas encontrar el ID de la política de Azure para "Tipos de recursos permitidos". Utiliza el siguiente comando para obtener este ID:

   policyName=$(az policy definition list \
     --query "[?displayName == 'Allowed resource types'].name" --output tsv)

3. Utiliza el siguiente comando para obtener la lista de IDs y nombres de políticas disponibles:

   az policy definition list \
     --query "[].{Name: name, DisplayName: displayName}"

4. Si la definición de tu política tiene parámetros, deberás indicarlos en el momento de la asignación. En nuestro caso, necesitamos indicar a la política qué recursos queremos permitir en nuestra suscripción. Crea un archivo JSON con el siguiente contenido y llámalo allowedResourcesParams.json:

   {
     "listOfResourceTypesAllowed": {
       "value": [
           "Microsoft.Storage/storageAccounts"
       ]
     }
   }

5. Ahora tenemos todo lo que necesitamos para crear la asignación de la política. Utiliza el siguiente comando para asignar la definición de política a tu suscripción. Para simplificar, sólo permitiremos la creación de cuentas de almacenamiento Azure en esta suscripción. En la mayoría de los casos, necesitarás permitir múltiples recursos para tus proyectos:

   az policy assignment create \
     --name 'Allowed resource types in my subscription' \
     --enforcement-mode Default \
     --policy $policyName \
     --params allowedResourcesParams.json

Nota

Establecemos la política --enforcement-mode en Default. Esto impide que se creen nuevos recursos si no están enla listapermitida. También puedes establecer el modo de aplicación enDoNotEnforce, que permite que se creen los recursos y sólo informa del incumplimiento de la política en los registros y en la página de resumen de la política.

6. Si dejas esta asignación de directiva en su lugar, sólo se podrán implementar cuentas de almacenamiento Azure en tu suscripción. Necesitamos desplegar otros tipos de recursos en este libro de recetas, así que eliminemos ahora esta asignación de directiva:

   az policy assignment delete \
     --name 'Allowed resource types in my subscription'

Debate

Utiliza la política de Azure para gobernar tus recursos de Azure e imponer el cumplimiento. Digamos que sólo quieres permitir que tu equipo implemente cuentas de almacenamiento Azure y Cosmos DB en la suscripción de desarrollo. Podrías confiar en que tu equipo siga estas directrices, y esperar que las cumpla, o podrías utilizar políticas para hacerlas cumplir. Esto último es un enfoque más seguro.

Hay numerosas políticas integradas, que puedes asignar a los ámbitos deseados. Puedes utilizar estas políticas para permitir o denegar el aprovisionamiento de determinados tipos de recursos, o para limitar las regiones en las que se pueden desplegar recursos.

Nota

Si necesitas aplicación, asegúrate de que el valor --enforcement-mode está ajustado a Default, no a DoNotEnforce.

Varias políticas integradas están diseñadas para mejorar la seguridad de tu suscripción a Azure. Puedes encontrar las definiciones y nombres de las políticas integradas en el portal de Azure, o utilizando herramientas como Azure CLI. Azure también ofrece políticas dirigidas a tipos de recursos Azure específicos; por ejemplo, la política "Las claves de las cuentas de almacenamiento no deben caducar", cuando se asigna, se asegura de que las claves de las cuentas de almacenamiento no caduquen. Echa un vistazo a la documentación de Microsoft para obtener más detalles sobre las políticas.

Asignación de ubicaciones permitidas para los recursos de Azure

Problema

En tienes que limitar las ubicaciones (regiones) en las que se pueden aprovisionar los recursos de Azure.

Solución

Asigna la política "Ubicaciones permitidas" al grupo de gestión, suscripción o grupo de recursos, con la lista de regiones Azure permitidas como parámetro de la política.

Pasos

1. Inicia sesión en tu suscripción a Azure con el rol de Propietario. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Primero tienes que encontrar el ID de la política de Azure "Ubicaciones permitidas". Utiliza el siguiente comando para obtener este ID:

   policyName=$(az policy definition list \
     --query "[?displayName == 'Allowed locations'].name" --output tsv)

3. Si la definición de tu política tiene parámetros, tienes que proporcionarlos en el momento de la asignación. En nuestro caso, tenemos que indicar a la política qué regiones de Azure queremos permitir en nuestra suscripción. Crea un archivo JSON con el siguiente contenido y llámalo allowedLocationParams.json:

   {
     "listOfAllowedLocations": {
       "value": [
           "eastus",
           "westus"
       ]
     }
   }

4. Utiliza el siguiente comando para asignar la definición de política a lasuscripción activa:

   az policy assignment create \
     --name 'Allowed regions for my resources' \
     --enforcement-mode Default \
     --policy $policyName \
     --params allowedLocationParams.json

5. Puedes modificar el archivo de parámetros allowedLocationsParams.json para pasar las ubicaciones que desees a la asignación de políticas. Utiliza el siguiente comando CLI para obtener la lista de ubicaciones disponibles:

   az account list-locations --query "[].name"

Nota

Utiliza el parámetro --scope con el comando az policy assignmentcreate para definir el ámbito de la asignación de políticas. El ámbito puede ser uno o más grupos de gestión, suscripciones, grupos de recursos o una combinación de ellos. Si no se menciona, el ámbito por defecto será la suscripción activa actual.

6. Puedes utilizar el siguiente comando para eliminar esta asignación de política:

   az policy assignment delete \
     --name 'Allowed regions for my resources'

Has asignado correctamente la definición de política "Ubicaciones permitidas" a nuestra suscripción. A partir de ahora, los recursos sólo podrán desplegarse en las regiones de Azure eastus y westus.

Debate

Muchos países y regiones de tienen leyes de residencia de datos en vigor. Esto significa que los datos del usuario no deben salir de su jurisdicción geográfica. El Reglamento General de Protección de Datos (GDPR) de la UE, que prohíbe que los datos de los residentes en la UE salgan de sus fronteras, es un ejemplo de este tipo de leyes. La política de Azure "Ubicaciones permitidas" es la herramienta perfecta para imponer el cumplimiento de normas como el GDPR.

Conexión a una máquina virtual Azure privada utilizando Azure Bastion

Problema

En tienes que conectarte a una máquina virtual Azure mediante RDP o SSH. Tu máquina virtual (VM) Azure es una VM privada, lo que significa que no tiene una dirección IP pública.

Solución

Despliega un recurso host Azure Bastion en la misma red virtual (VNet) que tu VM Azure. A continuación, puedes utilizar SSH o RDP para acceder a tu VM de Azure. Una VM Azure privada no tiene dirección IP pública, lo que la hace invisible a la Internet pública. Consulta el diagrama de arquitectura de la solución en la Figura 1-5.

Figura 1-5. Utilizar Azure Bastion para conectarse a una VM privada de Azure

Pasos

1. Accede a tu suscripción de Azure con el rol de Propietario y crea un nuevo grupo de recursos para esta receta. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Ahora, vamos a crear una nueva VM Azure . Todas las máquinas virtuales Azure se implementan en una VNet Azure. El siguiente comando aprovisionauna nueva VM Azure y la coloca en una nueva VNet con el espacio de direcciones 10.0.0.0/16. Al pasar una cadena vacía por--public-ip-address, creas una VM Azure privada, sin dirección IP pública. El parámetro --nsg-rule SSH configura la conectividad SSH para tu nueva VM:

   az vm create --name MyLinuxVM01 \
     --resource-group $rgName \
     --image UbuntuLTS \
     --vnet-address-prefix 10.0.0.0/16 \
     --admin-username linuxadmin \
     --generate-ssh-keys \
     --authentication-type ssh \
     --public-ip-address "" \
     --nsg-rule SSH \
     --nsg "MyLinuxVM01-NSG"

Nota

Se recomienda utilizar claves SSH para autenticarse en las máquinas virtuales Linux. También puedes utilizar una combinación de nombre de usuario y contraseña. Al pasar--authentication-type ssh has configurado esta VM para que sólo permita la autenticación mediante claves SSH. Consulta la documentación de la CLI y "Conectarse a una VM Linux" para más detalles.

3. El comando anterior generó un nuevo par de claves SSH (tanto la clave privada como la pública) y las guardó en tu máquina. La ruta a la clave privada se encuentra en la salida del comando, por ejemplo /home/reza/.ssh/id_rsa, como se muestra en la Figura 1-6. Anota la ruta del archivo de la clave privada. Tendrás que subir esta clave al servicio Bastión para iniciar sesión en tu nueva máquina virtual.

Figura 1-6. Guardar la clave SSH en tu máquina local

4. Utiliza el siguiente comando para obtener los detalles de la nueva red virtual creada como parte del aprovisionamiento de tu máquina virtual. Necesitarás este nombre para configurar tu nuevo host Azure Bastion en los pasos siguientes:

   vnetName=$(az network vnet list \
     --resource-group $rgName \
     --query "[].name" --output tsv)

5. Por motivos de seguridad, la VM de Azure que hemos creado no tiene una dirección IP pública. Una opción que tienes para conectarte a esta VM es utilizar Azure Bastion. Este servicio permite tanto conexiones SSH como RDP. Antes de crear un host Azure Bastion, tienes que crear un recurso IP público y una nueva subred en la VNet denominada AzureBastionSubnet. Esta IP se asignará al host Bastion, no a la VM Azure:

   ipName="BastionPublicIP01"
   
   az network public-ip create \
     --resource-group $rgName \
     --name $ipName \
     --sku Standard

6. Ahora crea la nueva subred, AzureBastionSubnet, utilizando el siguiente comando. Azure Bastion se implementará en esta subred:

   az network vnet subnet create \
     --resource-group $rgName \
     --vnet-name $vnetName \
     --name 'AzureBastionSubnet'  \
     --address-prefixes 10.0.1.0/24

Consejo

El nombre de la subred debe ser exactamente AzureBastionSubnet; de lo contrario, el comando CLI bastion create devuelve un error de validación.

7. Ahora, puedes crear un recurso Azure Bastion utilizando el siguiente comando. Asegúrate de que la variable $region está rellenada. Consulta "Instrucciones generales de configuración de la estación de trabajo" para obtener más detalles. Si se te pide que instales la extensión Bastion, responde Y:

   az network bastion create \
     --location $region \
     --name MyBastionHost01 \
     --public-ip-address $ipName \
     --resource-group $rgName \
     --vnet-name $vnetName

Nota

El aprovisionamiento de Azure Bastion puede tardar hasta 10 minutos.

8. Espera a que el comando anterior tenga éxito. Ahora puedes conectarte a la Máquina Virtual utilizando el host Bastion. Accede al portal Azure y busca tu nueva Máquina Virtual. Haz clic en ella y, en el menú superior izquierdo, selecciona Conectar > Bastión, como se muestra en la Figura 1-7.

9. Rellena el nombre de usuario. En Tipo de autenticación, elige Clave privada SSH desde archivo local y elige tu archivo de clave privada SSH. A continuación, haz clic en el botón Conectar, como se muestra en la Figura 1-8.

Figura 1-7. Elegir Bastión como método de conexión

Figura 1-8. Introducir el nombre de usuario de la máquina virtual y cargar la clave SSH

10. Deberías ver el símbolo del sistema de Linux, como se muestra en la Figura 1-9.

Figura 1-9. Iniciar sesión en la máquina virtual Azure utilizando Azure Bastion

11. Ejecuta el siguiente comando para eliminar los recursos que has creado en esta receta:

    az group delete --name $rgName

Advertencia

Azure Bastion es un servicio de pago. Asegúrate de ejecutar el comando de este paso para eliminar la máquina virtual, el host Bastion y susdependencias.

En esta receta, te has conectado a una VM privada utilizando un host Azure Bastion.

Debate

Azure Bastion actúa como servidor de salto gestionado, caja de salto o anfitrión de salto. Se utiliza para gestionar máquinas virtuales Azure privadas. Antes de que se introdujera el servicio Bastion, los administradores de Azure tenían que crear sus propias máquinas jump box, o incluso exponer la VM de Azure a Internet mediante una dirección IP pública. Se podían utilizar funciones como el acceso JIT o el Cortafuegos de Azure para mejorar la seguridad de la conexión, pero exponer una VM a través de una dirección IP pública nunca es una buena idea.

Nota

Puedes autenticarte en las VM Linux de Azure con contraseñas o claves SSH. Azure Bastion también admite el uso de claves SSH con las VM Linux.

Cómo proteger los discos de las máquinas virtuales de Azure mediante el cifrado de discos de Azure

Problema

En necesitas cifrar los discos de tus máquinas virtuales Azure mediante BitLocker o dm-crypt para proteger tus datos o cumplir las normas de seguridad y conformidad de tu empresa.

Solución

Crea una clave de cifrado en Azure Key Vault, y úsala para configurar el cifrado BitLocker (Windows VM) o dm-crypt (Linux VM ) para tus máquinas virtuales Azure (consulta la Figura 1-10).

Figura 1-10. Uso del Cifrado de Disco Azure para proteger una máquina virtual Azure

Pasos

1. Accede a tu suscripción de Azure con el rol de Propietario y crea un nuevo grupo de recursos para esta receta. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Crea una nueva VM Windows utilizando el siguiente comando CLI. Sustituye <vm-password> por una contraseña segura:

   vmName="MyWinVM01"
   
   az vm create \
       --resource-group $rgName \
       --name $vmName \
       --image win2016datacenter \
       --admin-username cookbookuser \
       --admin-password <vm-password>

3. En necesitas un recurso Azure Key Vault en el que almacenar tu clave de cifrado de disco. Puedes crear un recurso Azure Key Vault con el siguiente comando CLI. El parámetro--enabled-for-disk-encryption hace que esta Bóveda de Claves sea accesible para las máquinas virtuales de Azure. Sustituye <key-vault-name> por un nombre único para tu nuevo recurso Azure Key Vault:

   kvName="<key-vault-name>"
   
   az keyvault create \
     --name $kvName \
     --resource-group $rgName \
     --location $region \
     --enabled-for-disk-encryption

4. Ahora el escenario está preparado para activar el Cifrado de Disco Azure para nuestra máquina virtual Windows:

   az vm encryption enable \
     --resource-group $rgName \
     --name $vmName \
     --disk-encryption-keyvault $kvName

5. Puedes confirmar que el Cifrado de Disco de Azure está activado iniciando sesión en la máquina y comprobando el estado de BitLocker, o utilizando el siguiente comando CLI:

   az vm encryption show \
     --name $vmName \
     --resource-group $rgName

6. Ejecuta el siguiente comando para eliminar los recursos que has creado en esta receta:

   az group delete --name $rgName

Habilitamos con éxito el Cifrado de Disco de Azure para nuestra VM Windows utilizando Azure Key Vault y BitLocker. El Cifrado de Disco Azure creó automáticamente un nuevo secreto en la Bóveda de Claves para almacenar la clave de cifrado del disco. Este cifrado también está disponible para las máquinas virtuales Linux (mediante dm-crypt). Consulta la documentación de Microsoft para más detalles.

Debate

En este escenario, activamos el Cifrado de Disco Azure para una máquina virtual Azure Windows. Este cifrado se produce a nivel del SO Windows utilizando la conocida tecnología BitLocker.

Los discos de las VM de Azure se almacenan como objetos blob en Azure Storage. Microsoft Azure también ofrece otro tipo de cifrado para las máquinas virtuales de Azure. Este cifrado se denomina cifrado del lado del servidor(SSE) y tiene lugar en el nivel de almacenamiento de disco de Azure. Puedes activar tanto el Cifrado de Disco Azure como el SSE para una mayor protección.

Cifrar tu sistema operativo Azure VM y los discos de datos protege tus datos en el caso muy improbable de que las máquinas del centro de datos Azure se vean comprometidas. Además, muchas organizaciones exigen que los discos de las máquinas virtuales estén cifrados para cumplir sus compromisos de conformidad y seguridad.

Bloquear el acceso anónimo a los bloques de almacenamiento de Azure

Problema

Tú necesitas evitar que los desarrolladores concedan accidentalmente acceso público anónimo a los blobs y contenedores de Azure Storage.

Solución

Establece el indicador --allow-blob-public-access en false mediante programación, o establece el campo "Permitir acceso público a Blob" en Desactivado en el portal de Azure (consulta la Figura 1-11). Esto puede establecerse tanto para las cuentas de almacenamiento nuevas como para las existentes.

Figura 1-11. Desactivar el acceso público a las manchas en el portal Azure

Pasos

1. Accede a tu suscripción de Azure con el rol de Propietario y crea un nuevo grupo de recursos para esta receta. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Crea una nueva cuenta de almacenamiento Azure. Sustituye <storage-account-name> por el nombre deseado. Consulta la documentación sobre nomenclatura de cuentas de almacenamiento para conocer las reglas y restricciones de nomenclatura. Establece --allow-blob-public-access en false para que los desarrolladores no puedan permitir el acceso anónimo a blobs y contenedores:

   storageName="<storage-account-name>"
   
   az storage account create \
     --name $storageName \
     --resource-group $rgName \
     --location $region \
     --sku Standard_LRS \
     --allow-blob-public-access false

3. Puedes utilizar el siguiente comando CLI para configurar la misma salvaguarda para una cuenta de almacenamiento existente:

   az storage account update \
     --name $storageName \
     --resource-group $rgName \
     --allow-blob-public-access false

4. Ejecuta el siguiente comando para eliminar los recursos que has creado en esta receta:

   az group delete --name $rgName

Consulta "Configurar el Acceso Público Anónimo de Lectura para Contenedores y Blobs" para más detalles.

Debate

Cuando un contenedor o blob de cuenta de almacenamiento está configurado para acceso público, cualquier usuario de la web puede acceder a él sin necesidad de credenciales. Desactivar --allow-blob-public-access impide que los desarrolladores eliminen accidentalmente la protección de los blobs y contenedores de cuentas de almacenamiento.

Establecer la bandera --allow-blob-public-access en true no habilita el acceso anónimo para contenedores y blobs. Deja la puerta abierta a que los desarrolladores habiliten ese acceso accidental o intencionadamente.

En algunos casos, puede que necesites que tus blobs estén disponibles públicamente en la web (por ejemplo, para alojar imágenes utilizadas por un sitio web público). En estos casos, se recomienda crear una cuenta de almacenamiento separada destinada únicamente al acceso público. Nunca utilices la misma cuenta de almacenamiento para una mezcla de blobs públicos y privados.

Consejo

Puedes asignar la política de Azure "El acceso público a la cuenta de almacenamiento debe estar desautorizado" para regular la desactivación del acceso público anónimo.

Configurar una cuenta de Azure Storage para utilizar exclusivamente la autorización de Azure AD

Problema

En quieres impedir que una cuenta de almacenamiento de Azure acepte claves de almacenamiento y tokens SAS para la autorización. Hacer esto deja a los usuarios con el método más seguro de autenticación/autorización de Azure AD.

Solución

Establece la bandera --allow-shared-key-access en false mediante programación, o establece el campo "Permitir el acceso a la clave de la cuenta de almacenamiento" en Desactivado en el portal de Azure (consulta la Figura 1-12). Esto puede configurarse tanto para las cuentas de almacenamiento nuevas como para las existentes.

Figura 1-12. Establecer "Permitir el acceso a la clave de la cuenta de almacenamiento" en Desactivado en el portal Azure

Pasos

1. Accede a tu suscripción de Azure con el rol de Propietario y crea un nuevo grupo de recursos para esta receta. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Si tienes una cuenta de almacenamiento existente, salta al siguiente paso. Si no, utiliza este comando para crear una nueva cuenta de almacenamiento. Sustituye <storage-account-name> por el nombre deseado y establece la bandera --allow-shared-key-access en false:

   storageName="<storage-account-name>"
   
   az storage account create \
     --name $storageName \
     --resource-group $rgName \
     --location $region \
     --sku Standard_LRS \
     --allow-shared-key-access false

3. Puedes utilizar el siguiente comando CLI para configurar este ajuste para una cuenta de almacenamiento existente:

   az storage account update \
     --name $storageName \
     --resource-group $rgName \
     --allow-shared-key-access false

4. Ejecuta el siguiente comando para eliminar los recursos que has creado en esta receta:

   az group delete --name $rgName

En has desactivado Permitir acceso a la clave de la cuenta de almacenamiento para tu cuenta de almacenamiento. Esto significa que clientes como Azure Functions, App Services, etc. pueden acceder a esta cuenta de almacenamiento utilizando únicamente la autenticación/autorización de Azure AD. Se denegará cualquier solicitud que utilice claves de cuenta de almacenamiento o tokens SAS.

Debate

Las cuentas de almacenamiento de Azure admiten varios métodos de autorización, que se dividen en dos grupos:

• Acceso basado en claves, como el uso de claves de cuentas de almacenamiento, o tokens SAS

• Acceso a Azure Active Directory mediante una entidad de seguridad, usuario o grupo de Azure AD y un rol RBAC

Algunas organizaciones de prefieren el segundo método, porque no es necesario almacenar ni mantener ninguna contraseña, clave de cuenta o testigo SAS, lo que resulta en una solución más segura.

Consulta la documentación de Azure para obtener más detalles sobre la autenticación y autorización de cuentas de almacenamiento.

Consejo

Puedes asignar la política de Azure "Las cuentas de almacenamiento deben impedir el acceso a claves compartidas" para que las cuentas de almacenamiento sólo acepten solicitudes basadas en Azure AD. Consulta la documentación de Azure para obtener más información sobre esta política.

Almacenamiento y recuperación de secretos de Azure Key Vault

Problema

Tú necesitas almacenar y recuperar de forma segura contraseñas, conexiones a bases de datos y otros datos confidenciales en Azure.

Solución

Almacena tus secretos, claves y certificados en el servicio Azure Key Vault. Da acceso a los clientes para que lean los secretos de la Bóveda de Claves cuando lo necesiten. El flujo se muestra en la Figura 1-13.

Figura 1-13. Almacenamiento y acceso a claves, secretos y certificados en Azure Key Vault

Pasos

1. Accede a tu suscripción de Azure con el rol de Propietario y crea un nuevo grupo de recursos para esta receta. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Primero crea un nuevo servicio Azure Key Vault utilizando este comando CLI. Sustituye <key-vault-name> por un nombre válido y único a nivel mundial:

   kvName="<key-vault-name>"
   
   az keyvault create --name $kvName \
     --resource-group $rgName \
     --location $region

3. Ahora utiliza este comando para crear un secreto en la Bóveda de Claves:

   az keyvault secret set \
     --name MyDatabasePassword \
     --vault-name $kvName \
     --value P@$$w0rd

4. Tu secreto está ahora almacenado en la Bóveda de Claves de Azure. Sólo los clientes con la política de acceso a secretos "Obtener" pueden leer este secreto de la bóveda. Este permiso puede concederse a identidades gestionadas, principales de servicio de Azure AD o incluso a usuarios y grupos. Ya has iniciado sesión en la CLI como cuenta Propietario, por lo que deberías poder volver a leer el valor del secreto. Busca la propiedad value en la salida del comando:

   az keyvault secret show \
     --name MyDatabasePassword \
     --vault-name $kvName

5. Ejecuta el siguiente comando para eliminar los recursos que has creado en esta receta:

   az group delete --name $rgName

Debate

Azure Key Vault es la caja fuerte de Azure para almacenar datos sensibles. En una bóveda se pueden almacenar tres tipos de entidades:

Secretos

Cualquier valor personalizado que necesites salvaguardar, como cadenas de conexión a bases de datos o contraseñas de cuentas

Claves

Claves de cifrado utilizadas por otros servicios de Azure para cifrar discos, bases de datos o cuentas de almacenamiento

Certificados

Certificados X.509 utilizados para asegurar las comunicaciones entre otros servicios

Otros servicios Azure cliente pueden acceder a las entidades almacenadas en la Bóveda de Claves, siempre que el cliente tenga el acceso adecuado a la bóveda. Este acceso puede definirse mediante la Política de Acceso a la Bóveda de Claves de Azure o el RBAC de la Bóveda de Claves de Azure.

He aquí algunos de estos servicios al cliente y para qué se utilizan:

• Azure Function Apps y App Services, para que los secretos como las cadenas de conexión a la base de datos puedan obtenerse de la Bóveda de Claves en tiempo de ejecución

• Azure Cosmos DB o Azure Storage, para que las claves de cifrado gestionadas por el cliente puedan utilizarse para el cifrado de Cosmos DB en reposo

• VM de Azure, por lo que las claves de cifrado de la bóveda pueden utilizarse para cifrar los discos gestionados de las VM

• Azure Application Gateway, por lo que los certificados SSL de la cámara acorazada de claves pueden utilizarse para proteger las comunicaciones HTTPS

Hay varios casos de uso más para Azure Key Vault, que trataremos a lo largo de este libro.

Activar el cortafuegos de aplicaciones web (WAF) con Azure Application Gateway

Problema

En necesitas proteger tus aplicaciones web Azure de ataques web comunes, como la inyección SQL.

Solución

Implementa un recurso Azure Application Gateway delante de tu aplicación web y habilita WAF en él, como se muestra en la Figura 1-14.

Figura 1-14. Proteger tus aplicaciones web con Azure Application Gateway WAF

Nota

WAF es una de las funciones de Azure Application Gateway. Azure Application Gateway es un equilibrador de carga web con un rico conjunto de capacidades. Configurar un Azure Application Gateway implica crear escuchas HTTP, reglas de enrutamiento, etc. Consulta la documentación CLI de Application Gateway para obtener más detalles.

Pasos

1. Accede a tu suscripción de Azure con el rol de Propietario y crea un nuevo grupo de recursos para esta receta. Consulta "Instrucciones generales de configuración de la estación de trabajo" para más detalles.

2. Primero crea un plan App Service sencillo y una aplicación web Azure en él. Tu objetivo es proteger esta aplicación web de los ataques web habituales. Sustituye <web-app-name> por el nombre deseado:

   appName="<web-app-name>"
   planName=$appName"-plan"
   
   az appservice plan create \
     --resource-group $rgName \
     --name $planName
   
   az webapp create \
     --resource-group $rgName \
     --plan $planName \
     --name $appName

3. Con la aplicación web creada, utiliza este comando para guardar su URL en una variable. Utilizaremos esta variable cuando configuremos la pasarela de aplicaciones:

   appURL=$(az webapp show \
     --name $appName \
     --resource-group $rgName \
     --query "defaultHostName" \
     --output tsv)

4. Azure Application Gateway se implementa en una Azure VNet. Por tanto, utiliza primero este comando para crear una nueva Azure VNet, con una subred por defecto:

   vnetName="AppGWVnet"
   
   az network vnet create \
     --resource-group $rgName \
     --name $vnetName \
     --address-prefix 10.0.0.0/16 \
     --subnet-name Default \
     --subnet-prefix 10.0.0.0/24

5. Tu aplicación web Azure App Service será accesible a través del nuevo Azure Application Gateway, por lo que necesitas crear una nueva dirección IP pública para asignarla al Application Gateway. Utiliza el siguiente comando para aprovisionar la dirección IP pública:

   gwIPName="appgatewayPublicIP"
   
   az network public-ip create \
     --resource-group $rgName \
     --name $gwIPName \
     --sku Standard

6. Las políticas del cortafuegos de aplicaciones web contienen todos los ajustes y configuraciones del WAF de la pasarela de aplicaciones, incluidas las reglas de seguridad gestionadas, las exclusiones y las reglas personalizadas. Utilicemos el siguiente comando para crear un nuevo recurso de política WAF con la configuración predeterminada:

   wafPolicyName="appgatewayWAFPolicy"
   
   az network application-gateway waf-policy create \
     --name $wafPolicyName \
     --resource-group $rgName

7. Dispones de todos los recursos necesarios para crear un nuevo Azure Application Gateway. Asegúrate de implementar las SKU WAF_Medium, WAF_Large o WAF_v2. La SKU WAF_v2 es la última versión de WAF: consulta la documentación de las SKU de WAF para obtener más información. Sustituye <app-gateway-name> por el nombre deseado:

   appGWName="<app-gateway-name>"
   
   az network application-gateway create \
     --resource-group $rgName \
     --name $appGWName \
     --capacity 1 \
     --sku WAF_v2 \
     --vnet-name $vnetName \
     --subnet Default \
     --servers $appURL \
     --public-ip-address $ipName \
     --priority 1001 \
     --waf-policy $policyName

Nota

Una implementación de Azure Application Gateway puede llevar hasta 15 minutos.

8. Has aprovisionado con éxito una nueva Azure Application Gateway habilitada para WAF. Ahora configura tu aplicación web para que sólo acepte tráfico de la subred de Application Gateway, de modo que los usuarios finales ya no puedan acceder directamente a la aplicación web de App Service. Consulta "Restringir el acceso de red a un Azure App Service" para obtener una guía paso a paso. El acceso a tu aplicación web a través de Azure Application Gateway (con WAF) la protege de ataques web comunes, como la inyección SQL. Ejecuta el siguiente comando para obtener la dirección IP pública de tu Application Gateway. Esta dirección IP (así como los nombres de dominio personalizados) puede utilizarse para acceder a tu aplicación web a través de Azure Application Gateway:

   IPAddress=$(az network public-ip show \
     --resource-group $rgName \
     --name $gwIPName \
     --query ipAddress \
     --output tsv)
   
     echo $IPAddress

Nota

Antes de poder acceder a tu App Service a través de Azure Application Gateway, deben configurarse correctamente los escuchadores HTTP, las sondas de salud, las reglas de enrutamiento y los backends. Consulta la documentación de Azure Application Gateway y la configuración HTTP de Application Gateway para obtener más detalles.

9. Ejecuta el siguiente comando para eliminar los recursos que has creado en esta receta:

   az group delete --name $rgName

Debate

En el momento de escribir este libro, dos servicios de Azure admiten la función WAF:

• Azure Application Gateway para backends en la misma región Azure

• Azure Front Door para backends en diferentes regiones

WAF protege tus aplicaciones web contra ataques web comunes como:

• Inyección SQL

• Secuencias de comandos en sitios cruzados

• Inyección de órdenes

• Contrabando de solicitudes HTTP

• División de la respuesta HTTP

• Inclusión remota de archivos

• Violaciones del protocolo HTTP

Consulta la documentación de las características del WAF para obtener una lista completa de las características admitidas.