Zero Trust en AWS: identidad, permisos y red con ejemplos

Zero Trust en AWS significa que estar dentro de una VPC, conectado por VPN o trabajando desde la oficina no basta para obtener acceso. La decisión debe considerar la identidad, la acción solicitada, el recurso y las condiciones pertinentes. AWS combina controles de identidad y de red para aplicar ese enfoque; no existe un interruptor que convierta una cuenta completa en “Zero Trust”. AWS explica su modelo y casos de uso.

Esta guía te ayuda a elegir los controles para personas, aplicaciones y servicios, entender sus límites y comprobar un ejemplo de permisos de lectura en S3. Encontrarás recursos de la comunidad en español para practicar cada parte.

Qué cambia con Zero Trust

NIST SP 800-207 describe una arquitectura que protege recursos sin conceder confianza implícita por la ubicación de red ni por quién es dueño del dispositivo. Autenticar y autorizar son decisiones diferentes: demostrar quién eres no implica que puedas leer cualquier dato.

Piensa en una aplicación de facturación. Un empleado inicia sesión correctamente; eso todavía no autoriza el acceso a todas las facturas. La aplicación debe comprobar qué factura puede consultar. A su vez, el servicio que lee los archivos necesita su propia identidad y permisos en AWS: la identidad del empleado y el rol del servicio cumplen funciones distintas.

Zero Trust no obliga a pedir MFA al usuario en cada llamada ni hace que cada producto consulte continuamente la salud del dispositivo. Debes definir qué contexto usa cada control y cuándo vuelve a evaluar la decisión.

1. Usa identidades temporales para personas y cargas de trabajo

Para el acceso de tu equipo a cuentas AWS, empieza por federación e IAM Identity Center, antes llamado AWS SSO. Las personas asumen roles y reciben credenciales temporales. Usa MFA en el flujo de inicio de sesión correspondiente; si conectas un proveedor de identidad externo, revisa dónde se configura y exige ese segundo factor. Las buenas prácticas actuales de IAM recomiendan federación, credenciales temporales y MFA resistente al phishing cuando sea posible.

Para una aplicación en EC2 o Lambda, utiliza el rol asociado a la carga de trabajo. Los SDK de AWS pueden obtener las credenciales temporales de ese entorno: no hace falta insertar una access key de usuario IAM en el código. Para cargas externas, evalúa federación OIDC o IAM Roles Anywhere según las identidades disponibles. MFA interactivo no sustituye la autenticación de una máquina.

Un rol tiene dos preguntas separadas: quién puede asumirlo, definido por su política de confianza, y qué puede hacer después, definido por las políticas de permisos aplicables. La guía de roles de IAM explica esta separación. Que una credencial expire reduce su tiempo de uso; no corrige un rol con permisos excesivos ni impide que una sesión robada se use mientras siga siendo válida.

Para profundizar en español:

• El video de Marcia Villalba Cómo dar permisos temporales a cuentas de AWS introduce el acceso temporal; sirve para entender el cambio respecto de claves permanentes.
• Diana Alfaro recorre Organizations, conjuntos de permisos y acceso por CLI en Configurando nuestro entorno con AWS Organization y AWS Identity Center. Úsalo para visualizar la organización del acceso; es un tutorial histórico y sus pantallas o condiciones de Free Tier pueden haber cambiado.
• Deja de usar tu usuario raíz de AWS, de AndMore Dev, explica por qué separar la administración cotidiana del usuario root. Complementa esa lectura con las recomendaciones actuales de IAM, especialmente para acceso federado.

2. Autoriza acciones y recursos: ejemplo de lectura en S3

Supongamos que un servicio genera reportes y otro solo los descarga. El segundo no necesita escribir ni borrar archivos. Esta política de permisos de identidad, asociada a su rol, permite leer objetos cuyo nombre empieza con reportes/:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LeerReportes",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-reportes/reportes/*"
    }
  ]
}

Reemplaza el nombre de bucket por uno de tu entorno. El ejemplo sigue el patrón de permisos S3 limitados a un prefijo. Está pensado para leer un objeto cuya clave conoces mediante API o SDK: no concede s3:ListBucket, permisos de navegación por consola, acceso a versiones ni permisos para descifrar una clave KMS.

Este Allow no establece por sí solo un máximo de permisos. Otras políticas pueden conceder acceso adicional. Las políticas de recursos, límites de permisos, políticas de sesión y controles de Organizations pueden afectar el resultado; un Deny explícito aplicable prevalece. Revisa la evaluación de políticas de IAM para el tipo de principal y acceso que estás usando.

En una cuenta de práctica, con objetos existentes y sin otros permisos que amplíen el rol, comprueba estos resultados:

Distingue un objeto inexistente, un fallo de red y una denegación de permisos. No añadas s3:* como respuesta a cualquier error. Si el objeto usa SSE-KMS, comprueba también la autorización para kms:Decrypt sobre la clave correspondiente, como indica la referencia de GetObject; cifrado y permiso de lectura deben funcionar juntos.

El laboratorio IAM de Jonás Carrillo documenta un ejercicio de MFA y permisos acotados a S3 con pruebas de restricciones. Usa usuarios IAM para enseñar los conceptos; no sustituye la recomendación de acceso federado para tu equipo. Para escenarios con varias capas de políticas, IAM Access Analyzer — Parte 3/4, de Terry Quispe compara políticas, hallazgos y llamadas reales entre dos cuentas. Su laboratorio usa capacidades pagadas: revisa sus requisitos y costos antes de reproducirlo.

En una organización, las SCPs sirven para limitar permisos de los principales a los que se aplican. No conceden acceso y no reemplazan la política del rol.

3. Restringe la red sin convertirla en una identidad

Una subred privada reduce rutas de exposición, pero no demuestra que la aplicación que origina una conexión esté autorizada. Un atacante con acceso a un servidor interno podría aprovechar cualquier permiso o conexión que ese servidor tenga.

Los grupos de seguridad filtran tráfico de los recursos asociados y mantienen estado: las respuestas a un flujo permitido se aceptan sin otra regla de retorno. Limita puertos y orígenes según los flujos necesarios; una regla de red no comprueba quién es el usuario final ni qué factura puede consultar.

Los endpoints de VPC permiten acceder a servicios compatibles mediante rutas privadas. Una política de endpoint, cuando el servicio la admite, puede restringir qué principales, acciones y recursos pasan por ese endpoint. No reemplaza políticas IAM ni políticas del recurso, y la política predeterminada permite acceso completo a través del endpoint. AWS documenta ese alcance y sus limitaciones.

Para administración de EC2, Session Manager permite sesiones sin abrir SSH entrante, siempre que el agente, IAM y conectividad estén configurados. El repositorio de Pablo González Robles sobre EC2 privada, endpoints y Systems Manager incluye plantillas CloudFormation para estudiar esas piezas. Crear la infraestructura genera recursos facturables; revisa plantillas, permisos y eliminación antes de practicar.

4. Elige el control de acceso de la aplicación según el caso

No necesitas desplegar todos los servicios de seguridad. Identifica dónde debe tomarse y hacerse cumplir cada decisión:

Las guías de Verified Access, autorización de VPC Lattice y Verified Permissions explican funciones diferentes. Verified Access controla acceso a aplicaciones; Verified Permissions evalúa permisos de tu aplicación. No son nombres intercambiables.

Para llevarlo a código, el tutorial Asegurar API Gateway con Cognito usando SAM muestra una integración de autenticación. La demo de Verified Permissions de Gerardo Castro permite estudiar decisiones Cedar para leer, editar y borrar documentos. Es una demo didáctica con endpoints sin autenticación: úsala para entender las políticas, no como plantilla de producción ni como prueba de que autentica a los usuarios.

Si usas Lambda authorizers, revisa JWT, permisos y caché en API Gateway. Una decisión almacenada puede seguir vigente durante su TTL aunque los permisos hayan cambiado; define qué demora de revocación admite tu aplicación.

5. Protege los datos y registra lo que necesitas comprobar

TLS protege el transporte y el cifrado en reposo protege los datos almacenados. Ninguno impide por sí mismo que un principal autorizado descargue información que no debería tener. Define permisos sobre datos y claves, además de proteger secretos y respaldos. AWS KMS distingue claves administradas por el cliente, administradas por AWS y propiedad de AWS, con diferentes posibilidades de control; elegir KMS no resuelve automáticamente la autorización de los datos.

Para saber quién accedió, selecciona los registros pertinentes. CloudTrail no guarda por defecto los eventos de datos de un trail o event data store. Lecturas de objetos S3, como GetObject, requieren seleccionar esos eventos; tienen cargos adicionales. La documentación de CloudTrail explica eventos y selectores. Los logs de tu aplicación deben registrar también la decisión de negocio, sin tokens ni secretos.

GuardDuty detecta amenazas usando las fuentes y protecciones disponibles o habilitadas; un hallazgo no bloquea automáticamente cada petición. Diseña qué alertas investigar y qué respuestas automatizar, con permisos acotados y pruebas para evitar cortar acceso legítimo.

Como lectura complementaria, Observabilidad en la nube de AWS distingue CloudWatch, X-Ray y CloudTrail. El artículo de Gerardo Castro sobre auditar access keys y MFA en una AWS Organization muestra cómo encontrar credenciales olvidadas; la auditoría ayuda a revisar identidades, no demuestra por sí sola que los permisos sean mínimos.

Cómo empezar y comprobar el resultado

Elige un flujo pequeño, por ejemplo “el servicio de reportes lee un prefijo de S3”. Documenta identidad, acciones, datos, ruta de red y responsable. Después:

1. Configura una identidad temporal y permisos que correspondan a ese flujo.
2. Revisa quién puede asumir el rol y quién puede modificar sus permisos.
3. Limita las conexiones necesarias y evita rutas de acceso que eludan el control previsto.
4. Prueba tanto operaciones permitidas como rechazadas, incluido otro recurso y otra identidad.
5. Confirma que puedes identificar las solicitudes en los registros seleccionados.
6. Comprueba qué pasa al expirar credenciales o cambiar permisos, considerando cachés y tiempos de propagación.

IAM Access Analyzer puede generar una plantilla a partir de actividad de CloudTrail. Revisa esa plantilla: el historial observado puede omitir acciones poco frecuentes que sí necesita el sistema. No confundas “no apareció en los logs” con “nunca hará falta”.

Aprende seguridad AWS con la comunidad en español

Para profundizar en políticas, puedes ver El Código del Jedi: IAM avanzado, de AWS Women Colombia y RBAC vs ABAC, del AWS User Group Chile. Sirven para continuar desde el ejemplo de un rol hacia reglas de acceso por roles y atributos.

Si quieres conversar sobre lo que estás aprendiendo o llevar una duda a un encuentro, estos enlaces del catálogo te conectan con sus organizadores:

• AWS Security Users Group LatAm comparte seguridad AWS en español; su canal de YouTube permite explorar grabaciones regionales.
• AWS Security UserGroup Argentina reúne a la comunidad de seguridad en Buenos Aires y publica encuentros, incluido su historial sobre IAM.
• AWS User Group Security Colombia ofrece un espacio para conectar con personas que estudian y trabajan en seguridad AWS.
• AWS User Group Security Ecuador anuncia encuentros especializados; su sitio y archivo de actividades organiza contenido sobre IAM, detección y defensa.
• El canal de AWS Women Colombia permite continuar con sus sesiones técnicas y de seguridad.
• AWS Girls Chile reúne sus redes, grabaciones y actividades para el aprendizaje comunitario de AWS; es una comunidad general, no un grupo dedicado exclusivamente a Zero Trust.
• Road to CloudSec LATAM publica herramientas y experiencias de seguridad en AWS en español para seguir practicando y contrastar decisiones de operación.

Eventos anunciados al 6 de octubre de 2026

• DevSecOps con agentes de IA, de AWS Security Users Group LatAm: 15 de octubre a las 16:00 GMT-5, online. Su ficha anuncia una demostración de seguridad durante el desarrollo; permite explorar cómo llevar políticas a revisiones del software.
• Compliance as Code en AWS, de Security Ecuador: 20 de octubre a las 19:00 GMT-5, online y con cupos limitados según la ficha. Incluye un caso de credenciales IAM y controles automatizados.
• AWS Community Day Panamá — Security & Data Edition 2026: 14 de noviembre, de 08:00 a 13:00 GMT-5, presencial. Anuncia charlas de seguridad y datos; al revisar la ficha, el lugar seguía pendiente de confirmar.

Son propuestas para continuar aprendiendo seguridad, no cursos ni certificaciones de Zero Trust. Revisa inscripción, disponibilidad y condiciones en el enlace del organizador. Después de esas fechas, consulta la agenda de eventos y el directorio de comunidades; los recursos para aprender y canales de creadores permiten encontrar más contenido en español.

Preguntas frecuentes

¿Una VPC privada o una VPN bastan para implementar Zero Trust?

No. Controlan conectividad, pero debes autenticar y autorizar el acceso a cada recurso protegido. Estar en la misma red no equivale a permiso para leer datos.

¿IAM Identity Center autentica a los clientes de mi aplicación?

Está orientado a las identidades de tu equipo y su acceso a cuentas y aplicaciones. Para clientes de una aplicación, evalúa el proveedor de identidad y los mecanismos de autenticación que correspondan, como Cognito. Después define la autorización sobre los objetos de negocio.

¿Tengo que activar Verified Access, VPC Lattice y Verified Permissions?

No. Resuelven casos distintos. Elige por el flujo de acceso que debes proteger, las integraciones disponibles y sus costos; sumar servicios no prueba que el acceso esté bien diseñado.

¿Zero Trust garantiza que no habrá incidentes?

No. Reduce confianza implícita y limita el alcance del acceso. Sigue siendo necesario proteger credenciales, corregir vulnerabilidades, comprobar permisos y preparar la respuesta a incidentes.