Dar acceso a tu AWS a una plataforma externa con mínimo privilegio

Cuando una plataforma opera en tu cuenta#

Muchas herramientas trabajan directamente dentro de tu cuenta de AWS: plataformas de despliegue que crean redes, bases de datos y contenedores; servicios de observabilidad que leen métricas; optimizadores de costos que revisan tu inventario. Todas necesitan permisos, y la forma en que se los das define cuánto riesgo asumes.

Un patrón frecuente en guías de integración es crear un usuario IAM, adjuntarle un par de políticas amplias que cubren una larga lista de servicios (EC2, RDS, ECS, EKS, DynamoDB, ElastiCache, OpenSearch, CloudWatch, S3, Route 53 y más) y pegar sus access keys en la plataforma. Funciona, pero deja credenciales de larga duración fuera de tu control y, a menudo, más permisos de los necesarios.

Esta guía explica la alternativa que recomienda AWS, un rol que la plataforma asume con un external ID, cómo acotar sus permisos y cómo auditar el acceso. Al final verás qué hacer si la plataforma solo acepta access keys.

Rol cross-account o access keys#

AWS recomienda usar roles para que terceros accedan a tus recursos sin compartir tus credenciales de seguridad, y en general preferir credenciales temporales frente a access keys.

Documentación: AWS IAM · Acceso para terceros ↗ · AWS IAM · Access keys ↗ · AWS IAM · Buenas prácticas ↗

El problema del confused deputy y el external ID#

El confused deputy es un problema de seguridad en el que una entidad sin permiso para una acción consigue que otra con más privilegios la ejecute. En este contexto: la plataforma atiende a muchos clientes y asume roles en todas sus cuentas. Si otro cliente conociera el ARN de tu rol, podría pedirle a la plataforma que operara sobre tu cuenta.

El external ID lo evita. La plataforma genera un identificador único para ti, tú lo exiges en la trust policy y la plataforma lo envía en cada AssumeRole. Solo las peticiones hechas en tu nombre llevan el valor correcto.

• Debe generarlo la plataforma, uno por cliente, y no debe ser adivinable.
• No es un secreto: cualquiera con permiso para ver el rol puede leerlo. Su función es evitar la confusión, no autenticar.
• Admite entre 2 y 1.224 caracteres alfanuméricos y los símbolos + = , . @ : / -.

Documentación: AWS IAM · El problema del confused deputy ↗ · AWS IAM · External ID ↗ · AWS STS · AssumeRole ↗

Crear el rol#

Necesitas tres datos de la plataforma: su ID de cuenta de AWS, tu external ID y la lista de permisos que requiere. La trust policy permite que esa cuenta asuma el rol solo con el external ID correcto:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "ID-UNICO-ENTREGADO-POR-LA-PLATAFORMA" }
      }
    }
  ]
}

# Crear el rol con la trust policy anterior (sesiones de 1 hora, el valor por defecto)
aws iam create-role \
  --role-name plataforma-externa \
  --assume-role-policy-document file://trust.json \
  --max-session-duration 3600 \
  --tags Key=owner,Value=plataforma-externa

# Adjuntar solo los permisos que la plataforma documenta que necesita
aws iam put-role-policy \
  --role-name plataforma-externa \
  --policy-name permisos-minimos \
  --policy-document file://permisos.json

# Entregar a la plataforma solo el ARN del rol (y confirmar el external ID)
aws iam get-role --role-name plataforma-externa --query 'Role.Arn'

Documentación: AWS CLI · iam create-role ↗ · AWS CLI · iam put-role-policy ↗

Acotar los permisos#

La trust policy decide quién entra; la política de permisos decide qué puede hacer. Estas técnicas se combinan:

• Empieza por la lista oficial de la plataforma y revisa servicio por servicio si de verdad lo vas a usar. Si no usas SageMaker u OpenSearch, no los incluyas.
• Limita por recurso cuando el servicio lo permita: ARNs concretos, prefijos de nombre o etiquetas.
• Si el servicio soporta control por etiquetas, usa la condición aws:ResourceTag para que la plataforma solo pueda modificar lo que ella creó y etiquetó.
• Añade un permissions boundary al rol si la plataforma crea a su vez roles o usuarios, para que nunca puedan superar un máximo.
• En AWS Organizations, las SCPs ponen un techo a toda la cuenta, por ejemplo regiones permitidas.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SoloRecursosDeLaPlataforma",
      "Effect": "Allow",
      "Action": ["ec2:StopInstances", "ec2:StartInstances", "ec2:TerminateInstances"],
      "Resource": "arn:aws:ec2:*:111122223333:instance/*",
      "Condition": {
        "StringEquals": { "aws:ResourceTag/ManagedBy": "plataforma-externa" }
      }
    }
  ]
}

Documentación: AWS IAM · Control de acceso con etiquetas ↗ · AWS IAM · Permissions boundaries ↗ · AWS Organizations · SCPs ↗

Auditar y reducir con el tiempo#

• IAM Access Analyzer genera hallazgos de acceso externo: muestra qué roles y recursos puede usar una entidad fuera de tu cuenta u organización, así confirmas que solo la cuenta de la plataforma aparece.
• La validación de políticas de Access Analyzer detecta errores y permisos demasiado amplios antes de guardar.
• La generación de políticas crea una política a partir de la actividad real registrada en CloudTrail, útil para recortar una política amplia inicial.
• La información de último acceso de IAM indica qué servicios no se han usado; si la plataforma nunca toca uno, quítalo.

CloudTrail registra las llamadas AssumeRole y cada acción que se hace con el rol, así puedes atribuir cada cambio en tu cuenta a la plataforma.

Documentación: IAM Access Analyzer ↗ · Access Analyzer · Hallazgos ↗ · Access Analyzer · Validación ↗ · Access Analyzer · Generación de políticas ↗ · IAM · Último acceso ↗ · AWS CloudTrail ↗

Si la plataforma solo acepta access keys#

Algunas herramientas solo admiten un par de access keys. En ese caso, reduce el riesgo:

• Crea políticas administradas por el cliente a partir del JSON que publique la plataforma (en la consola de IAM: Policies, Create policy, editor JSON) y etiquétalas con un owner.
• Crea un usuario IAM dedicado solo a esa plataforma, sin acceso a la consola, y adjúntale únicamente esas políticas.
• Genera la access key y guarda el secret en ese momento: AWS solo lo muestra una vez.
• Rótala periódicamente, desactívala si dejas de usar la plataforma y vigila su actividad en CloudTrail.

Documentación: AWS IAM · Crear políticas en la consola ↗ · AWS IAM · Gestionar access keys ↗

Checklist#

• Rol cross-account con el ID de cuenta de la plataforma y sts:ExternalId obligatorio.
• Permisos limitados a los servicios y recursos que la plataforma gestiona.
• Permissions boundary si la plataforma crea identidades IAM.
• Access Analyzer sin hallazgos inesperados de acceso externo.
• Access keys solo si no hay alternativa, con usuario dedicado y rotación.