general
  4 min. de lectura (aproximado)

Tutorial de políticas de aws iam

¿Qué es una política de IAM?

Una política de IAM es un documento en formato JSON que define permisos. Cuando se asocia a una identidad, usuario, grupo o rol, o a un recurso, AWS la evalúa cada vez que se hace una solicitud y decide si se permite o se deniega la acción.
Por defecto, todo está denegado. Solo se permite lo que explícitamente se autoriza.

Tipos principales de políticas

Tipo Se adjunta a ¿Otorga permisos? Notas importantes
Identity-based Usuarios, grupos, roles Sí Las más comunes
Resource-based Recursos (S3, SQS, KMS, Lambda, trust policy de roles…) Sí Incluye el elemento Principal
Permissions boundary Usuario o rol No (solo limita) Define el máximo de permisos
SCP (Service Control Policy) Cuentas/OUs de Organizations No (solo limita) Aplica a toda la organización
RCP (Resource Control Policy) Recursos de Organizations No (solo limita) Control centralizado de recursos
Session policies Sesión de AssumeRole / federación No (solo limita) Se pasan al asumir el rol
VPC Endpoint policies VPC Endpoints No (filtran) Límite adicional de tráfico


Las dos políticas que realmente otorgan permisos son: "Identity-based" y "Resource-based".

Estructura de una política JSON

{
  "Version": "2012-10-17",
  "Id": "PolicyOpcional",
  "Statement": [
    {
      "Sid": "NombreDescriptivo",
      "Effect": "Allow",
      "Principal": { ... },          // Solo en resource-based
      "Action": [ "servicio:accion" ],
      "Resource": [ "arn:aws:..." ],
      "Condition": { ... }           // Opcional
    }
  ]
}

Elementos principales

Elemento Obligatorio Descripción
Version Recomendado Siempre usa "2012-10-17"
Statement Sí Array de uno o más statements
Sid No Identificador legible del statement
Effect Sí "Allow" o "Deny"
Action Sí* Acciones permitidas/denegadas (s3:GetObject, ec2:*, etc.)
NotAction Alternativa Todo excepto las acciones listadas
Resource Sí* ARNs de los recursos afectados
NotResource Alternativa Todo excepto los recursos listados
Principal Solo resource-based Quién puede realizar la acción
Condition No Condiciones adicionales (IP, fecha, tags, MFA, etc.)

Managed Policies vs Inline Policies

Tipo Quién la gestiona Reutilizable Recomendado
AWS managed AWS Sí Para empezar
Customer managed Tú Sí Recomendado en producción
Inline Tú No (1:1) Solo casos muy específicos


La mejor práctica es usar siempre Customer Managed Policies.

Lógica de evaluación

  • Explicit Deny siempre gana (aunque haya un Allow).
  • Si no hay Deny:
    • Se evalúan identity-based + resource-based (unión en same-account).
    • Luego se aplican los “techos”: Permissions Boundary, SCPs, RCPs y Session Policies (intersección).
  • Si no hay ningún Allow → Implicit Deny.

Cómo crear políticas

Desde la consola, la web

  1. IAM → Policies → Create policy.
  2. Usar el Visual editor o pega JSON directamente.
  3. Validar con IAM Access Analyzer.
  4. Nombrar y crear.
  5. Adjuntar a usuarios/grupos/roles.

Con AWS CLI

aws iam create-policy \
  --policy-name MiPoliticaS3 \
  --policy-document file://politica.json

Ejemplo de política (Customer Managed)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListAndReadSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::mi-bucket-privado",
        "arn:aws:s3:::mi-bucket-privado/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Mejores prácticas

  • Empiezat con permisosmínimos e ir añadiendo solo lo necesario.
  • Evitar "*" en Action y Resource siempre que sea posible.
  • Usar condiciones, IP, MFA, tags, fecha, VPC, etc..
  • Usar variables de política, "${aws:username}", "${aws:PrincipalTag/Department}".
  • Revisar regularmente con IAM Access Analyzer y Last Accessed information.
  • Usar Permissions Boundaries para roles que crean otros roles.
  • Preferir roles a usuarios de larga duración.
  • No usar nunca la cuenta "root" para operaciones diarias.

Herramientas imprescindibles

  • IAM Policy Simulator: Prueba políticas antes de aplicarlas.
  • IAM Access Analyzer: Detecta permisos excesivos y genera políticas desde CloudTrail.
  • Access Advisor / Last Accessed: Ve qué permisos realmente se están usando.
  • Policy Validator: Detecta errores de sintaxis y malas prácticas.

. Ejemplo completo recomendado (rol de aplicación)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadWriteSpecificS3Prefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::mi-app-datos/prod/${aws:PrincipalTag/Environment}/*"
    },
    {
      "Sid": "ListOnlyOwnPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mi-app-datos",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["prod/${aws:PrincipalTag/Environment}/*"]
        }
      }
    },
    {
      "Sid": "DenyAllOutsideRegion",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "eu-west-1"
        }
      }
    }
  ]
}