Fundamentos de IAM

Quién puede hacer qué

Cada acción en AWS se reduce a una pregunta: ¿esta identidad puede hacer esto sobre este recurso? AWS Identity and Access Management, o IAM, es el servicio que la responde. IAM es donde decides quién puede iniciar sesión en tu cuenta y qué puede hacer cada persona o aplicación una vez que está dentro.

Esto importa porque una cuenta de AWS empieza con un solo inicio de sesión todopoderoso y nada más. El trabajo real involucra a muchas personas y muchas aplicaciones, cada una con una porción distinta de acceso. IAM es la forma de repartir esas porciones de manera segura. Pesa mucho en el dominio de Seguridad y cumplimiento del examen, así que vale la pena aprender bien los componentes.

Qué es IAM

IAM es un servicio web que controla el acceso a tus recursos de AWS. Hace dos trabajos:

• La autenticación confirma quién hace una solicitud. Cuando inicias sesión con una contraseña o una aplicación llama a AWS con una clave, IAM compara esas credenciales con una identidad en la que confía.
• La autorización decide qué puede hacer esa identidad. Una vez que AWS sabe quién eres, revisa tus permisos para ver si la acción específica que pediste está permitida.

Dos datos sobre IAM son puntos fáciles en el examen. Primero, IAM es un servicio global: las identidades que creas no están ligadas a una Región, así que nunca eliges una Región al crear un usuario o un rol. Segundo, IAM en sí es gratuito. Solo pagas por los recursos de AWS que usan tus identidades, no por IAM.

Los componentes

IAM te da cuatro cosas para trabajar. Si las tienes claras, casi todo el tema cae en su lugar.

Usuarios de IAM

Un usuario de IAM es una identidad para una persona o una aplicación que necesita acceso de largo plazo a tu cuenta. Un usuario puede tener una contraseña para iniciar sesión en la consola, claves de acceso para acceso programático, o ambas. Cada usuario es una identidad distinta con sus propias credenciales, y eso es lo que te deja saber quién hizo qué.

Grupos de IAM

Un grupo es un conjunto de usuarios. Asocias políticas al grupo y cada usuario en él hereda esos permisos. Los grupos facilitan el manejo de permisos: pon a tus desarrolladores en un grupo Developers, asocia las políticas correctas una sola vez y los nuevos desarrolladores obtienen el mismo acceso en cuanto los agregas. Un grupo no es una identidad con la que puedas iniciar sesión, no tiene credenciales y no puedes anidar un grupo dentro de otro.

Roles de IAM

Un rol es una identidad que creas con un conjunto de permisos, pero a diferencia de un usuario no está ligado a una persona y no tiene contraseña ni claves de acceso de largo plazo. En su lugar, un principal de confianza asume el rol y recibe credenciales de seguridad temporales para esa sesión. Los roles son la forma de otorgar acceso sin repartir claves permanentes. Usos comunes: darle a una instancia EC2 permiso para leer de S3, dejar que una cuenta de AWS acceda a otra y conceder acceso a usuarios que ya tienen identidades fuera de AWS.

La diferencia entre un usuario y un rol es un punto frecuente del examen. Un usuario es una identidad permanente con sus propias credenciales. Un rol es un sombrero temporal que un principal se pone, recibe credenciales de corta duración y se vuelve a quitar.

Políticas de IAM

Una política es un documento, normalmente escrito en JSON, que lista permisos. Asocias políticas a usuarios, grupos o roles para definir qué pueden hacer. AWS también ofrece políticas administradas por AWS, políticas listas para usos comunes que puedes asociar como punto de partida, junto con políticas administradas por el cliente que escribes tú.

Una declaración de política simple tiene algunas partes clave:

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

• Effect es Allow o Deny.
• Action lista las operaciones, como s3:ListBucket.
• Resource nombra a qué se aplican las acciones.

No necesitas escribir JSON a mano para el examen, pero deberías reconocer estas partes y saber que Effect es lo que hace que una declaración permita o bloquee una acción.

Cómo se evalúa una solicitud

Cuando un principal hace una solicitud, AWS la procesa en orden.

1. Autenticación. AWS compara las credenciales de la solicitud con un principal en el que confía: un usuario de IAM, una sesión de rol o una identidad federada.
2. Autorización. AWS reúne todas las políticas que aplican y revisa si la acción está permitida.

La respuesta por defecto es no. El acceso se deniega salvo que una política lo permita de forma explícita, y un Deny explícito en cualquier política siempre gana, incluso sobre un Allow. Así que una solicitud tiene éxito solo cuando algo la permite y nada la deniega.

Políticas basadas en identidad y en recursos

Las políticas vienen en dos formas amplias, y distinguirlas ayuda en el examen.

Las políticas basadas en identidad dicen "esta identidad puede hacer estas cosas". Las políticas basadas en recursos dicen "estos principales pueden hacer estas cosas sobre mí". Un rol es un caso especial: lleva tanto una política de permisos como una política de confianza que nombra a quién se le permite asumirlo.

Consejos para el examen

• IAM controla la autenticación (quién eres) y la autorización (qué puedes hacer).
• IAM es un servicio global y es gratuito. Solo pagas por los recursos que usan las identidades.
• Cuatro componentes: usuarios (una persona o aplicación), grupos (un conjunto de usuarios), roles (asumibles, credenciales temporales) y políticas (permisos en JSON).
• Un usuario tiene credenciales de largo plazo; un rol se asume para obtener credenciales temporales. Conoce esta diferencia.
• Los grupos no tienen credenciales y no se pueden anidar.
• El acceso se deniega por defecto; un Deny explícito siempre gana sobre un Allow.
• Las políticas basadas en identidad se asocian a usuarios, grupos y roles. Las políticas basadas en recursos se asocian a un recurso y nombran al principal.