MSTech Geeks

Introducción

La nube ha transformado la forma en que desarrollamos y desplegamos aplicaciones: más rápido, más flexible y con mayor capacidad de innovación. Sin embargo, esa velocidad también abre la puerta a nuevos riesgos si no se protege adecuadamente cada capa del entorno.

En este artículo presentamos una arquitectura básica de referencia para entornos de desarrollo en la nube, diseñada bajo principios de Zero Trust. Se trata de un modelo sencillo pero robusto, que incorpora los controles de seguridad esenciales:

• Gestión de identidades con User Assigned Managed Identity (UAMI) y RBAC granular.
• Protección de secretos y claves con Azure Key Vault, incluyendo cifrado de imágenes en ACR con Customer-Managed Keys (CMK).
• Aislamiento de red mediante VNETs dedicadas, Private Endpoints y resolución segura con Azure Private DNS Resolver.
• Mínima superficie expuesta: solo Azure Front Door como punto de entrada público y seguro.
• Observabilidad integrada con Application Insights, Azure Monitor y Sentinel.

Este diseño básico proporciona una base segura para proyectos en la nube, sobre la que es posible construir arquitecturas más avanzadas con mayor nivel de automatización, cumplimiento y resiliencia.

Arquitectura

Componentes principales:

• Developer Workstation (Docker Desktop + VS Code): Estación de trabajo del desarrollador. Desde aquí se construyen imágenes de contenedor y se gestionan los proyectos. El push/pull de imágenes hacia Azure se hace de forma controlada.
• VNET Secure Development (vnet-secure-development-ne): Red virtual central que agrupa los recursos de desarrollo en un entorno aislado y controlado. Garantiza segmentación de tráfico y separación del resto de la infraestructura.
• Subnets dedicadas (snet-pep, snet-out-web, snet-dnsresolver, GatewaySubnet):
  • snet-pep: subred para Private Endpoints, permitiendo acceso privado a servicios de Azure.
  • snet-out-web: salida controlada para Azure App Service.
  • snet-dnsresolver: resolución de nombres mediante Private DNS Resolver, en este caso, sustituimos la versión PaaS por una máquina virtual que hace el mismo efecto con la intención de reducción de costes. En un entorno de producción se recomienda usar el servicio PaaS de Microsoft.
  • GatewaySubnet: usada para conectividad híbrida o VPN.
• Private Endpoints (privatelink.*): Conexiones privadas hacia servicios como Azure Container Registry, Azure Websites y Azure Key Vault, eliminando exposición pública.
• Key Vault (kv-secure-development-ne): Almacena secretos, claves y certificados para el desarrollo. Todo acceso es a través de private endpoint.
• Managed Identity (uami-secure-development-ne): Identidad administrada asignada a recursos de la arquitectura para autenticación segura sin necesidad de credenciales en código.
• Azure Container Registry (azrscdevsecse): Registro privado para almacenar imágenes de contenedor.
  – Push desde la estación de desarrollo.
  – Pull desde los entoP2rnos de ejecución.
  El acceso se realiza a través de Private Endpoint y está controlado por políticas.
• App Service Plan + Web App (asp-secure-development-ne / web-secure-development-ne): Entorno de ejecución de aplicaciones. Desplegado en la VNET con conectividad privada, asegurando que las apps no estén expuestas directamente a Internet.
• Application Insights: Monitorización de telemetría de la aplicación: rendimiento, errores, disponibilidad y experiencia de usuario. Integra con Log Analytics Workspace y aporta trazabilidad detallada para detectar anomalías.
• Azure Front Door (afd-secure-development-ne): Punto de entrada seguro para el tráfico externo hacia la aplicación. Ofrece WAF, TLS, protección DDoS y distribución global.
• DNS privado y zonas privatelink.*: Resolución interna de recursos mediante zonas privadas de Azure DNS. Permite que el acceso a servicios (Key Vault, ACR, Web App) siempre sea privado.
• Internet: Medio de conexión del desarrollador hacia los recursos de Azure. Todo el tráfico está securizado y pasa por canales definidos. Los usuarios acceden a la aplicación únicamente a través de Azure Front Door, que es la única superficie expuesta públicamente.

Configuración segura de Web App con Azure Container Registry (ACR):

Autenticación:

• La Web App se conecta a ACR usando una User Assigned Managed Identity (UAMI).
• En ACR, se asignan los permisos mínimos necesarios (principio de mínimo privilegio) a esa identidad, como Container Registry Repository Reader o Writer. Actualmente, ACR también ofrece ABAC en preview, lo que permite aplicar condiciones adicionales en los permisos a nivel de repositorio. Este modo, denominado “RBAC Registry + ABAC Repository Permissions”, aporta una granularidad extra para escenarios avanzados.
• En nuestro caso, hemos optado por RBAC con scope reducido al repositorio (repository-scoped roles), lo que proporciona un control suficiente y elimina la necesidad de credenciales embebidas o contraseñas de servicio.

Conectividad de red:

• El acceso de la Web App al ACR se hace mediante Private Endpoint, evitando exposición pública del registro.
• Se configura la Web App en modo VNET Integration, de forma que todo el tráfico al ACR fluye de forma privada dentro de la VNET Secure Development.

Ciclo de imágenes:

• Los desarrolladores hacen push de imágenes desde el workstation hacia el CR, conectándose mediante VPN P2S.
• La Web App realiza pull automático desde ACR en el despliegue
• Se recomienda activar image scanning (con Defender for Containers) para detectar vulnerabilidades en las imágenes antes de ser usadas. Este control es complementario a la validación de integridad (Content Trust / Notary), ya que el escaneo detecta vulnerabilidades conocidas en el contenido de la imagen, mientras que la firma criptográfica garantiza su procedencia e integridad. Actualmente, cuando se habilita CMK en ACR, Content Trust no está soportado, por lo que es clave apoyarse en escaneo y estar preparados para Notary v2 / OCI signatures en el futuro.

Políticas de seguridad en ACR:

• Retention policies: limpiar imágenes antiguas automáticamente, reduciendo superficie de ataque.
• Geo-replication (opcional): si la arquitectura es multi-región, para mejorar disponibilidad y reducir latencia.

Monitorización:

• App Service Diagnostics + Application Insights → monitorizan el rendimiento de la aplicación y el ciclo de despliegue.
• Azure Monitor / Log Analytics → recopilan logs de pull/push del ACR.

Cifrado de la imagen:

Además, todas las imágenes almacenadas en ACR están cifradas en reposo (encryption at rest) utilizando Customer-Managed Keys (CMK). Estas claves son gestionadas directamente por el cliente a través de Azure Key Vault, lo que otorga:

• Control total sobre el ciclo de vida de las claves (rotación, expiración, revocación).
• Mayor alineación con normativas como ISO 27001, ENS o NIS2.
• Separación de responsabilidades: Azure garantiza la disponibilidad del servicio y el cliente controla la seguridad criptográfica.

De esta manera, el ciclo completo —push desde la estación de desarrollo, almacenamiento seguro en ACR con cifrado gestionado por el cliente y pull hacia la Web App— se mantiene protegido, garantizando seguridad, cumplimiento y soberanía sobre las claves de cifrado.

Nota: en esta arquitectura se prioriza el cifrado en reposo con Customer-Managed Keys (CMK) desde Key Vault. Cuando esta opción está habilitada, Content Trust no está soportado en ACR.

Principios aplicados en la arquitectura:

1. Zero Trust en la red → uso de Private Endpoints, subredes dedicadas y segmentación de VNET.
2. Seguridad de identidades → autenticación con User Assigned Managed Identity (UAMI) y control de acceso vía RBAC (repository-scoped roles en ACR).
3. Protección de secretos y claves → gestión centralizada en Azure Key Vault, incluyendo cifrado de imágenes en ACR con Customer-Managed Keys (CMK).
4. Aislamiento de recursos → subredes específicas para cada función (App, Private Endpoints, DNS Resolver, Gateway).
5. Reducción de superficie pública → todo el tráfico interno se mantiene privado; solo Azure Front Door queda expuesto como punto de entrada seguro.
6. Integración con CI/CD → despliegues automatizados y push/pull seguro de imágenes de contenedor desde ACR.
7. Resolución de nombres privada → uso de Private DNS Resolver y zonas DNS privadas para garantizar que todo el tráfico interno se resuelva de forma segura.
8. Monitorización y observabilidad → integración de Application Insights, Azure Monitor y Sentinel para supervisar rendimiento, seguridad y anomalías.

Conclusión

La seguridad en entornos de desarrollo en la nube no depende de un único servicio, sino de un diseño integral que combine identidad, red, datos, aplicaciones y monitorización.

En esta arquitectura, cada capa está protegida:

• Las identidades se gestionan con UAMI y RBAC granular en ACR.
• Los secretos y claves se almacenan en Key Vault, incluyendo el cifrado de imágenes en ACR con Customer-Managed Keys (CMK).
• La red se aísla con subredes específicas, Private Endpoints y Private DNS Resolver, manteniendo todo el tráfico privado.
• La exposición pública se reduce al mínimo, con Azure Front Door como único punto de entrada seguro.
• La observabilidad se refuerza con Application Insights, Azure Monitor y Sentinel, garantizando visibilidad completa.

Este enfoque garantiza tres beneficios clave:

1. Reducción de la superficie de ataque → minimizando exposición y accesos innecesarios.
2. Cumplimiento y soberanía → gracias al uso de CMK y control centralizado en Key Vault.
3. Innovación segura → permitiendo que los equipos de desarrollo desplieguen con agilidad sin comprometer la seguridad.

Pero este es solo el primer paso. A partir de esta base, la arquitectura puede evolucionar hacia escenarios más avanzados:

• Integrando pipelines DevSecOps completos con SAST/DAST, SBOM y firma de artefactos (cuando Notary v2 esté disponible).
• Añadiendo mayor segmentación con entornos separados (dev, test, prod) y tránsito controlado por Azure Firewall Premium.
• Incorporando protección de runtime con Defender for Containers en AKS u orquestadores más complejos.
• Extendiendo la arquitectura a escenarios multi-región y disaster recovery, con geo-replicación y balanceo global.

En definitiva, esta arquitectura básica ofrece un punto de partida sólido, sobre el cual se puede construir un ecosistema seguro, resiliente y alineado con los estándares más exigentes de seguridad y cumplimiento.