Techie Universe C.A.

Appearance

AWS IAM ​

Cuando se crea una cuenta de AWS se establece un usuario inicial conocido como root (raíz). Tal usuario nos da apertura y acceso inicial a la nube de AWS. Sin embargo, debe evitarse usarse en adelante por sus altos poderes o privilegios.

La recomendación sería usar root solo para crear los diversos usuarios que tendrían los privilegios bien definidos. Tales usuarios se gestionan a traves de AWS IAM (Identity and Access Managment). Además, se aconseja habilitar el MFA (Multi-Factor Authentication) de modo que No solo se ingrese con una contraseña sino también con un número aleatorio o segundo factor autenticación.

La gestión de identidad en AWS busca brindar seguridad definiendo quién se puede autenticar y qué está autorizado a hacer sobre los recursos, planteando ciertas categorias o conceptos:

  • Usuario (IAM): Corresponde a la identidad de quién puede acceder.
  • Grupo: Los grupos permiten proporcionar una colección de usuarios que tienen algo en común, un perfil o enfoque sobre los recursos de AWS.
  • Rol: Cuando no se trata solo de usuarios sino de un recurso, usuario de otra cuenta o un servicio al que se le otorga un privilegio por un periodo de tiempo, AWS proporciona para esto el concepto de rol. Es decir, algo que ejerce un rol en un determinado momento puede tener autorización a un recurso, bien sea un servicio, un usuario que se otorga un privilegio provisional, o un usuario de otra cuenta de AWS. En muchos casos es recomendable establecer roles para impartir la autorización a los recursos (mediante políticas asociadas).
  • Política: Se refiere a las sentencias de autorización o privilegios que se admiten o deniegan para un usuario, grupo o rol. Las políticas se nombran y suelen describirse en formato JSON (JavaScript Object Notation), aunque se pueden definir desde la Consola de AWS indicando las características de un modo simplificado. En últimas la autorización a un recurso se otorga a través de políticas. Las políticas basadas en identidad contienen atributos como: Version, Effect, Action, Resource, Condition. Las políticas basadas en recursos es común encontrar un atributo adicional con nombre Principal (por ejemplo, indicando AWS con Id de la cuenta), también un atributo de identificación denominado Sid.

Imagen tomada de https://docs.aws.amazon.com

Anatomía de una política IAM ​

Una política IAM se escribe en formato JSON y tiene esta estructura básica:

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mi-bucket"
    }
  ]
}

Los atributos más importantes son:

  • Version: la versión del lenguaje de políticas (usar siempre "2012-10-17").
  • Statement: arreglo de una o más sentencias de autorización.
  • Effect: puede ser "Allow" (permitir) o "Deny" (denegar).
  • Action: el servicio y la acción que se autoriza o deniega (por ejemplo, "s3:ListBucket", "ec2:StartInstances"). Se usa "*" para todas las acciones de un servicio.
  • Resource: el ARN (Amazon Resource Name) del recurso al que aplica. Puede ser un recurso específico o "*" para todos los recursos.
  • Condition (opcional): condiciones adicionales como dirección IP, horario, MFA, etc.

ARN: el identificador de los recursos en AWS ​

Cada recurso en AWS tiene un ARN (Amazon Resource Name) único. Ejemplos:

  • arn:aws:s3:::mi-bucket: un bucket de S3
  • arn:aws:s3:::mi-bucket/*: todos los objetos dentro del bucket
  • arn:aws:ec2:us-east-1:123456789012:instance/*: todas las instancias EC2 en una cuenta y región
  • arn:aws:iam::123456789012:user/Andrey: un usuario IAM específico

Conociendo la anatomía de una política y el ARN, ahora veamos ejemplos concretos y frecuentes.

Ejemplo 1: Acceso de solo lectura a un bucket de S3 ​

Imagina que tienes un bucket llamado datos-empresa y quieres que un usuario o grupo solo pueda ver y descargar archivos, pero sin poder subir, modificar ni eliminar nada.

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::datos-empresa"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::datos-empresa/*"
    }
  ]
}

¿Qué hace cada parte?

  • s3:ListBucket → permite listar los archivos (objetos) dentro del bucket. El Resource apunta al bucket mismo (datos-empresa).
  • s3:GetObject → permite descargar (leer) cualquier archivo dentro del bucket. El Resource apunta a datos-empresa/*, es decir, todos los objetos dentro del bucket.

Con esta política, el usuario puede ejecutar aws s3 ls s3://datos-empresa/ y aws s3 cp s3://datos-empresa/documento.pdf ., pero no puede subir (s3:PutObject), eliminar (s3:DeleteObject) ni modificar nada.

Ejemplo 2: Acceso completo a EC2, pero solo en una región específica ​

Supón que quieres que un desarrollador pueda arrancar, detener, crear y eliminar instancias EC2, pero únicamente en la región us-east-1. Además, se requiere que use MFA (autenticación de dos factores).

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

¿Qué hace cada parte?

  • El primer Statement permite ("Allow") todas las acciones de EC2 ("ec2:*") pero solo cuando la región solicitada es us-east-1 (gracias a "Condition").
  • El segundo Statement deniega ("Deny") todas las acciones de EC2 si el usuario no ha iniciado sesión con MFA. Esto fuerza al usuario a usar siempre el segundo factor de autenticación.

El orden de las sentencias importa: Deny siempre gana sobre Allow. Si el usuario no tiene MFA, aunque esté en us-east-1, se le denegará el acceso.

Buenas prácticas con IAM ​

  1. Usa el usuario root solo para lo estrictamente necesario: crea tu primer usuario administrador y habilítale MFA. Luego guarda las credenciales root en un lugar seguro y no las uses en el día a día.
  2. Principio de mínimo privilegio: otorga solo los permisos que realmente se necesitan, nada más. Siempre empieza con permisos restrictivos y ve ampliándolos si hace falta.
  3. Usa grupos en lugar de asignar políticas directamente a usuarios: asigna políticas a grupos y agrega usuarios a esos grupos. Así es más fácil mantener el control cuando hay muchos usuarios.
  4. Prefiere roles a usuarios para accesos temporales o entre servicios: por ejemplo, una instancia EC2 que necesita leer de S3 debe asumir un rol, no tener credenciales de usuario almacenadas.
  5. Habilita MFA para todos los usuarios: especialmente para aquellos con permisos administrativos.
  6. Revisa periódicamente los permisos: usa IAM Access Analyzer para identificar permisos no utilizados o demasiado amplios.

© 2025 by César Arcila