Trabajar en la nube cambia la forma de proteger una empresa. Las aplicaciones ya no están dentro de una red cerrada. Hay usuarios remotos, APIs, contenedores, cuentas de servicio y pipelines con permiso para desplegar en producción.
Zero Trust parte de una idea clara: cada acceso debe verificarse. En cloud, la confianza se revisa por identidad, contexto, permiso y recurso solicitado.
Este enfoque afecta a tres áreas principales: identidad, permisos mínimos y supply chain security. AWS, Azure y Google Cloud usan servicios distintos, pero el patrón se repite: comprobar quién accede, limitar qué puede hacer y controlar qué código llega a producción.
Qué significa Zero Trust en cloud
En una arquitectura tradicional, muchas decisiones dependían del perímetro. Estar dentro de la red daba más confianza. Ese modelo encaja mal con SaaS, trabajo híbrido, APIs públicas, workloads distribuidas y despliegues automatizados.
En cloud, una petición puede venir de una persona, una máquina virtual, una función serverless, un contenedor, una cuenta de servicio o una herramienta de CI/CD. Todas esas identidades pueden tener permisos sobre datos, redes, secretos o infraestructura.
Zero Trust busca reducir la confianza implícita. Cada acceso se autentica, se autoriza con el menor permiso posible y queda registrado. La decisión puede depender de la identidad, el dispositivo, la ubicación, el riesgo, el recurso y la acción solicitada.
Identidad: el primer punto de control
La identidad es el centro de la seguridad cloud. Casi cualquier acción sensible pasa por una identidad: crear una base de datos, leer un secreto, cambiar una regla de red o desplegar una imagen.
El riesgo aparece cuando los accesos crecen sin revisión. Un usuario conserva permisos de administrador tras terminar un proyecto. Una cuenta de servicio se reutiliza en varias aplicaciones. Un pipeline mantiene permisos para modificar producción aunque solo debería publicar una versión.
En AWS, la gestión se apoya en IAM, roles, políticas, federación y credenciales temporales. En Azure, Microsoft Entra ID centraliza la identidad y Conditional Access permite tomar decisiones según usuario, dispositivo, ubicación, aplicación o riesgo. En Google Cloud, IAM permite asignar permisos por organización, carpeta, proyecto o recurso.
Permisos mínimos: menos accesos, menos riesgo
El principio de permisos mínimos consiste en conceder solo las acciones necesarias, sobre los recursos necesarios y durante el tiempo necesario.
En producción cuesta mantenerlo. Los equipos técnicos necesitan avanzar rápido y muchas organizaciones empiezan con roles amplios para evitar bloqueos. Luego llegan integraciones, urgencias, pruebas temporales y excepciones que nadie retira.
Ese exceso aumenta la superficie de ataque. Una credencial filtrada con permisos de lectura puede exponer datos. Una identidad con permisos de escritura puede alterar servicios. Una cuenta con privilegios administrativos puede afectar a varias capas del entorno cloud.
AWS permite revisar permisos con IAM Access Analyzer y CloudTrail. Azure recomienda asignar roles en el ámbito más bajo posible: recurso, grupo de recursos o suscripción. Google Cloud cuenta con IAM Recommender para detectar permisos concedidos que apenas se usan.
La revisión debe ser periódica. Configurar IAM al inicio del proyecto no basta. Hay que comprobar qué permisos se usan, cuáles sobran y qué cuentas siguen activas.
Supply chain security: proteger el camino del código
La seguridad cloud empieza antes del despliegue. Un entorno puede tener IAM bien configurado y seguir siendo vulnerable si el código llega desde una dependencia comprometida, una imagen sin revisar o un pipeline con secretos expuestos.
Supply chain security protege el recorrido del software: repositorios, dependencias, artefactos, imágenes de contenedor, secretos, runners de CI/CD y políticas de despliegue.
Un caso habitual es instalar por error un paquete malicioso con un nombre parecido al de una librería conocida. Otro ejemplo es subir un token a Git y dejar acceso abierto a repositorios, APIs o recursos cloud.
En AWS, CodeArtifact permite centralizar paquetes internos y controlar fuentes externas. En Azure, Defender for Cloud DevOps ayuda a revisar repositorios, pipelines, secretos, dependencias e infraestructura como código. En Google Cloud, Binary Authorization permite bloquear despliegues de imágenes que incumplen una política definida.
Cómo aplicarlo sin bloquear al equipo
El despliegue de Zero Trust debe hacerse por fases. Primero conviene inventariar identidades: usuarios, grupos, cuentas de servicio, workloads y pipelines. Después se revisan permisos y se separan entornos de desarrollo, pruebas y producción.
El siguiente paso es reducir privilegios permanentes. En AWS se puede trabajar con roles y credenciales temporales. En Azure, Privileged Identity Management permite activar permisos elevados durante un tiempo limitado. En GCP, IAM Recommender ayuda a retirar permisos sobrantes.
La cadena de suministro también necesita controles desde el inicio. El equipo debe revisar secretos en repositorios, validar dependencias, escanear imágenes y definir qué artefactos pueden desplegarse.
Errores frecuentes al implantar Zero Trust
El primer error es reducir Zero Trust a MFA. La autenticación multifactor ayuda, pero no corrige permisos excesivos, secretos en repositorios, cuentas de servicio compartidas ni imágenes sin validar.
Otro fallo habitual es mantener administradores permanentes. Si una cuenta privilegiada queda comprometida, el impacto puede ser alto. El acceso temporal y justificado reduce esa exposición.
También se olvidan las identidades no humanas. Pipelines, contenedores, funciones serverless y cuentas de servicio necesitan permisos mínimos, rotación de credenciales y revisión periódica.
Otro problema aparece cuando los controles solo se aplican en producción. Si un atacante compromete el pipeline, puede modificar lo que se despliega sin atacar directamente el entorno final.
Qué perfiles trabajan con Zero Trust en la nube
Zero Trust en cloud cruza varias funciones. Un Cloud Architect define la estructura de cuentas, redes, identidades y despliegues. Un Cloud Security Engineer diseña políticas de acceso, revisa permisos y configura controles de seguridad.
El DevSecOps Engineer integra análisis de código, dependencias, secretos e imágenes en CI/CD. El SRE participa desde observabilidad, respuesta a incidentes y fiabilidad. En empresas grandes también aparece el IAM Engineer, centrado en federación, roles y gobierno de accesos.
Para trabajar en este ámbito conviene dominar IAM, redes cloud, infraestructura como código, CI/CD, gestión de secretos, escaneo de contenedores, logs de auditoría y cumplimiento.
Preguntas frecuentes sobre Zero Trust en la nube
¿Qué es Zero Trust en cloud?
Es un enfoque de seguridad que verifica cada acceso a recursos cloud, limita permisos y reduce confianza implícita en usuarios, redes, dispositivos, workloads y pipelines.
¿MFA basta para aplicar Zero Trust?
MFA ayuda, pero debe combinarse con permisos mínimos, acceso temporal, revisión continua, logs y políticas sobre despliegues.
¿Qué es supply chain security en cloud?
Es la protección del recorrido del software desde el código hasta producción. Incluye dependencias, repositorios, secretos, artefactos, imágenes, políticas y pipelines.
Conclusión
Aprender Zero Trust en cloud exige practicar con identidades, roles, automatización, monitorización y despliegues. En una formación cloud orientada a entornos reales, estos conceptos conectan con arquitectura, seguridad, DevOps y operación.
En una formación de Cloud Computing con enfoque práctico, este tipo de ejercicios permite entender cómo se conectan arquitectura, automatización, seguridad y operación. Esa visión diferencia a quien usa herramientas de quien puede diseñar plataformas internas útiles para equipos reales.
Español