Cómo evitar brechas de seguridad con IAM

Curso de AWS Certified Solutions Architect Associate

Contenido del curso

Fundamentos de AWS

Identidad, Acceso y Gobernanza Multicuenta

Servicios de Computo en AWS

Contenedores en AWS

Redes en AWS

Escalamiento y balanceo en AWS

Almacenamiento en AWS

Bases de datos en AWS

Migración en AWS

Monitoreo y Auditoria en AWS

DNS y CDN en AWS

Servicios de Seguridad

Serverless

Servicios de Datos en AWS

Servicios de AI y ML em AWS

64
Servicios de IA y ML en AWS
04:09 min

Servicios de Backup y Recuperación ante desastres

Architect Solutions Certificate

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:009:12

Cómo evitar brechas de seguridad con IAM

Curso de AWS Certified Solutions Architect Associate

Clase 5 de 69

Clase 5 / 69

Recursos

Configurar mal un permiso en AWS puede costarte caro. Un pasante con accesos abiertos cambió las credenciales del admin de un banco y extrajo datos sensibles. Aprender AWS IAM (Identity and Access Management) es lo que separa una cuenta segura de una catástrofe, y aquí te explico cómo aplicarlo paso a paso si te preparas para la certificación de Solutions Architect.

Qué es IAM en AWS y por qué es tan crítico

IAM es el módulo donde defines quién entra a tu cuenta de AWS y qué puede hacer adentro. Sus siglas significan Identity and Access Management y funciona como el portero, el guardia y el reglamento de tu infraestructura, todo en uno [0:32].

Desde ahí controlas usuarios, permisos y políticas para que cada persona o servicio acceda solo a lo que necesita. Ni más, ni menos.

¿Qué hace IAM en AWS? Gestiona identidades y permisos dentro de tu cuenta. Define usuarios, grupos, roles y políticas para controlar quién accede a qué recursos y bajo qué condiciones.

Cuáles son los tipos de usuarios en AWS

AWS distingue dos grandes categorías de usuarios, y entender la diferencia es la primera línea de defensa de tu cuenta [0:51].

Por qué no debes usar el usuario root en el día a día

El usuario root es con el que creaste la cuenta. Tiene permisos absolutos sobre todo, por eso se le llama superusuario. La recomendación es clara:

Asígnale una contraseña muy fuerte.
Activa doble factor de autenticación (MFA).
Guárdalo y olvídate de él para tareas diarias.

Usarlo a diario es como andar con la llave maestra del edificio en el bolsillo.

Cuándo conviene usar un usuario IAM

El usuario IAM es el que sí debes usar. Es controlado, limitado y le defines exactamente qué permisos tiene. Puedes crear uno por persona, por rol o por función dentro de la organización [1:25].

Qué tipos de identidades existen dentro de IAM

Dentro de los usuarios IAM hay cuatro tipos de identidades, y cada una resuelve un problema distinto [1:43].

Usuarios: la unidad básica. Uno por persona o por función.
Grupos: agrupan permisos por rol, por ejemplo developers, admins o finanzas. Si alguien cambia de equipo, mueves al usuario de grupo y los permisos se ajustan solos.
Usuarios federados: conectan AWS con plataformas externas como Azure Active Directory o Google Workspace, evitando duplicar credenciales.
Roles: identidades sin credenciales permanentes. Sus credenciales son temporales y se asignan para acciones específicas o para que un servicio de AWS se comunique con otro.

Los roles son especialmente útiles cuando una instancia EC2 o una función Lambda necesita acceder a un archivo en S3. En lugar de exponer access keys de un usuario, AWS asigna credenciales temporales que duran minutos. Más seguro y más limpio [2:42].

Cómo se conectan los usuarios IAM en la práctica

Un usuario humano como Bob suele tener dos vías de acceso: usuario y contraseña para la consola web, y access keys para conectarse vía CLI, SDK o aplicaciones [3:09].

En cambio, un usuario para CI/CD, al ser puramente programático, solo necesita access keys. Nada de consola.

Cómo funcionan las políticas de IAM

Las políticas son el documento que dice quién puede hacer qué sobre cuáles recursos. Conceden permisos basados en identidad o en recursos, y son el corazón del control de accesos en AWS [3:38].

Qué tipos de políticas puedes crear en AWS

Dentro de IAM encuentras tres tipos principales:

Políticas manejadas por AWS: preconfiguradas para casos comunes, como S3 Full Access. Útiles, pero suelen ser demasiado amplias.
Políticas custom: las creas tú y puedes reutilizarlas entre usuarios, grupos y roles.
Políticas inline: viven solo dentro de un usuario o rol específico. No se reutilizan, por eso no son recomendadas.

La buena práctica es dar el mínimo privilegio posible. Si un rol solo necesita listar buckets, no le des full access a S3 [5:30].

¿Qué es una política inline en IAM? Es una política asociada exclusivamente a una identidad específica. No se puede reutilizar en otros usuarios o roles, lo que la hace difícil de mantener.

Cómo se estructura una política en JSON

Una política IAM en JSON tiene secciones bien definidas [6:52]:

Version: la versión del lenguaje de políticas.
Statement: uno o más bloques de permisos.
Effect: puede ser Allow o Deny.
Action: la acción permitida, por ejemplo s3:ListBucket o s3:GetObject.
Resource: sobre qué recursos aplica. Un asterisco * significa todos.

Puedes crear políticas con el editor visual seleccionando servicio, acciones y recursos, o escribiendo el JSON directamente. El editor visual es más rápido si no recuerdas los nombres exactos de las acciones.

Cómo crear un rol para que EC2 acceda a S3

Este es uno de los casos más frecuentes en arquitecturas AWS: una instancia EC2 que necesita leer o escribir en un bucket de S3 [4:50].

El flujo en consola es directo:

Entras a la sección Roles dentro de IAM.
Eliges el caso de uso, en este ejemplo EC2.
Asignas una política, por ejemplo una manejada por AWS para S3.
Le das un nombre claro como EC2AccessS3.
Creas el rol y lo asocias a la instancia.

Así evitas pegar access keys dentro del código o en variables de entorno. Las credenciales temporales se manejan automáticamente.

Cuáles son las mejores prácticas de seguridad en IAM

Las reglas básicas que evitan el 90% de los incidentes son simples [9:21]:

Activa doble factor de autenticación en todos los usuarios.
Usa siempre usuarios IAM, nunca el root para tareas diarias.
Aplica el principio de mínimo privilegio en cada política.
Prefiere roles temporales sobre access keys cuando sea un servicio AWS hablando con otro.
Crea políticas custom reutilizables en lugar de inline.

¿Recuerdas el caso del pasante que escaló privilegios al admin? La política que tenía esa cuenta queda en los recursos. Cuéntame en los comentarios qué error encuentras y cómo lo corregirías.

Eduardo Sacahui

Hace un año

Buen Video!!! y aunque no dicen como..

TL;DR: me imagino que un pasante pudo cambiar la contraseña del ADMIN porque tenía iam:UpdateLoginProfile y sobre resources * y el ADMIN no tenía MFA. Inició sesión con la contraseña temporal y tomó el control. Recuerden hay que tener prevención:

least priviledge real (no comodines)
permission boundaries/SCPs, MFA obligatorio,
trust policies estrictas!
alertas sobre eventos IAM críticos - digo yo aunque de pereza

Esto pudo haber pasao:

El setting (muy común pues, solo que me imagino que lo hicieron a la rápida)

Empresa con cuentas multi-equipo en AWS.
Para dar autonomía al helpdesk, crean un rol de apoyo para contraseñas y acceso a la consola.
Se hace el JSON “principio de mínimo privilegio” pero, con prisas, alguien copia/pega una política “temporal”.

La (mala) política que creo que empezó todo

Se adjunta a un grupo/rol que el pasante puede asumir:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CosasDelHelpdesk",
      "Effect": "Allow",
      "Action": [
        "iam:CreateLoginProfile",
        "iam:UpdateLoginProfile",
        "iam:CreateAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

Error clave #1: confundir iam:ChangePassword (solo cambia tu propia contraseña) con iam:UpdateLoginProfile/CreateLoginProfile (pueden resetear o crear la contraseña de otros usuarios).

Error clave #2: Resource: "*". No limita a quién se le puede resetear la contraseña.

Error clave #3: el usuario ADMIN no tenía MFA. 1) El pasante con el rol de helpdesk Enumera usuarios para “ayudar” (tiene iam:ListUsers por otra política básica). 2) Ejecuta un reset accidental o malintencionado sobre el ADMIN:``` aws iam update-login-profile
--user-name AdminUser
--password 'Temp!234'
--password-reset-required

> Aunque `--password-reset-required` fuerce cambio al siguiente inicio, **quien conoce la contraseña temporal puede iniciar sesión y cambiarla**.1. Inicia sesión en la consola como **AdminUser** (sin MFA, entra directo). 2. (Opcional) Crea **nuevas access keys** para persistencia: aws iam create-access-key --user-name AdminUser

Miguel Angel Reyes Moreno

Hace un año

Gracias por compartir este aporte

Luis Fernando Bustos Ramírez

Hace 8 meses

Excelente descripción y feedback, complementa mucho la clase!!!

Fundamentos de AWS

Certificación AWS Solutions Architect Associate: Fundamentos y Preparación

Preparación para certificación AWS Arquitecto de Soluciones

Configuración de presupuestos en AWS para controlar costos

Los 6 pilares del Well-Architected Framework

Identidad, Acceso y Gobernanza Multicuenta

Cómo evitar brechas de seguridad con IAM

Creación de usuarios administrador y practicante en AWS IAM

Gestión de cuentas con AWS Organizations

Detecta recursos AWS expuestos con Access Analyzer

Cómo gestionar múltiples cuentas AWS

Servicios de Computo en AWS

Servicios de cómputo AWS: EC2, procesadores Graviton y AMIs

Compute Savings Plan para EC2 y Lambda

Cómo lanzar tu primera instancia EC2

Optimizar latencia en EC2 con tenencia dedicada

Cómo consultar metadatos de EC2 con IMDSv2

AWS Outposts: ejecutar AWS en tu data center

Despliegue de app web en Elastic Beanstalk

Contenedores en AWS

Contenedores en AWS: ECS, EKS y ECR

Gestión de imágenes de contenedores con ECR y Fargate

Configuración de clusters, tareas y servicios en Amazon ECS

Redes en AWS

Direccionamiento IP y bloques CIDR para redes AWS

NAT Gateway para subredes privadas en AWS

Configuración de instancias públicas y privadas con NAT Gateway

NACL y Security Groups en AWS

Cómo reparar un Security Group en EC2

Conectividad híbrida en AWS: VPC Peering, Transit Gateway y Endpoints

Escalamiento y balanceo en AWS

Tipos de balanceadores de carga en AWS

Configuración de balanceadores de carga en AWS para alta disponibilidad

Autoescalamiento en EC2 con Auto Scaling Groups

Cómo crear un Auto Scaling Group en EC2

Almacenamiento en AWS

Tipos de almacenamiento en AWS: EBS, EFS y S3

Instance Store vs EBS en AWS

EFS vs FSx para compartir archivos en AWS

Creación y configuración de volúmenes EBS en AWS

Transfer Acceleration para datos globales en S3

Configuración de EFS para compartir almacenamiento entre instancias

Recuperar objetos borrados en Amazon S3

Bases de datos en AWS

Bases de datos relacionales vs no relacionales en AWS

Cómo funciona DynamoDB en AWS

Creación y configuración de bases de datos Dynamo en AWS

Elasticache y DAX

RDS vs Aurora: réplicas y alta disponibilidad

Cómo configurar Aurora con alta disponibilidad en RDS

Migración en AWS

Estrategias de migración AWS: las 6 R para trasladar aplicaciones

Cómo migramos 500 TB a AWS sin downtime

Migración de datos con AWS Snow Family: opciones y características

DMS y SCT para migrar bases de datos en AWS

Monitoreo y Auditoria en AWS

CloudTrail y EventBridge en arquitecturas AWS

Monitoreo de AWS con CloudWatch

DNS y CDN en AWS

Zonas locales y de borde en AWS

CloudFront vs Global Accelerator en AWS

Failover en Route 53 para arquitectura activo-pasiva

Configuración de políticas de geoproximidad en AWS Route 53

Servicios de Seguridad

KMS vs CloudHSM para datos regulados

AWS Shield y WAF contra ataques DDoS

Servicios AWS para detectar vulnerabilidades

GuardDuty y Trusted Advisor para detectar amenazas en AWS

Serverless

API Gateway y Lambda en arquitecturas serverless

Creación y configuración de funciones Lambda para automatización

AWS SQS: Tipos de filas y configuración para arquitecturas serverless

AWS SNS y Step Functions para comunicación y workflows visuales

Servicios de Datos en AWS

Servicios de datos en AWS para tu examen

Kinesis, EMR, Glue

Casos de uso de Amazon Redshift en AWS

Servicios de AI y ML em AWS

Servicios de IA y ML en AWS

Servicios de Backup y Recuperación ante desastres