El error de seguridad más común es “Dale Admin y Ya”

Source: Dev.to

Cuando estamos bajo presión, casi siempre gana la solución más rápida. Algo falla, alguien necesita acceso, hay una entrega cerca. Entonces hacemos lo típico: damos permisos amplios “por ahora”.
El problema es que lo temporal suele quedarse para siempre.

Menor privilegio no es paranoia. Es intención. Damos solo lo necesario para que los errores tengan un impacto pequeño y la seguridad sea más predecible.

Qué significa menor privilegio de verdad

Menor privilegio significa:

• Solo las acciones necesarias
• Solo los recursos necesarios
• Solo cuando se necesita
• Solo para la identidad correcta

Una buena política responde:

• Qué necesita hacer este sistema
• En qué recursos lo hará
• Qué cosas nunca debería poder hacer

IAM no es solo seguridad. IAM también es estabilidad. Un rol con demasiado poder puede romper más cosas más rápido.

Por Qué Importa a Gran Escala

En entornos pequeños, los permisos amplios tal vez no exploten de inmediato. En entornos grandes, tarde o temprano sí.

Menor privilegio te protege de:

• Impacto masivo si una credencial se compromete
• Borrados accidentales en producción
• Roles antiguos que nadie recuerda
• Auditorías difíciles de explicar

Además, ayuda a depurar. Si algo falla, sabemos que los límites de acceso son reales.

Dónde Fallamos Normalmente

Los patrones más comunes son:

• Wildcards como *:*
• Políticas copiadas sin limpieza
• Un rol para todo
• Permisos temporales que nunca se quitan
• No separar permisos de despliegue y ejecución

Esto les pasa a equipos buenos también. La solución es un patrón claro.

Ejemplos: Mala Política vs Buena Política

Ejemplo 1: Acceso a S3

❌ Mala política (demasiado amplia)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

✅ Buena política (limitada y práctica)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucketInPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-app-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["public/*"]
        }
      }
    },
    {
      "Sid": "ReadObjectsInPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-data/public/*"
    }
  ]
}

Un Sistema Simple para Diseñar IAM Bien

• Separar roles
• Empezar mínimo y crecer cuando sea necesario
• Usar guardrails como SCPs y boundaries
• Revisar y limpiar permisos regularmente

Mini Proyecto: Rol de Menor Privilegio para Lambda + S3 usando Terraform

Objetivo

Crear:

• Un bucket S3
• Un rol de ejecución de Lambda
• Una política de menor privilegio
• Adjuntar la política al rol

La Lambda podrá:

• Leer solo de public/
• Escribir solo en results/
• Escribir logs en CloudWatch