AWS Cloud Practitioner #12: AWS IAM - Control de Accesos

Problema 1: Todos usan root account
❌ Root tiene acceso completo a TODO
❌ No puedes rastrear quién hizo qué
❌ Si alguien renuncia, no puedes revocar solo su acceso
 
Problema 2: Developer borra producción por error
❌ Developer tiene permisos de admin
❌ Un comando erróneo = desastre
❌ No hay prevención
 
Problema 3: Credenciales hardcoded en app
❌ AWS access keys en código
❌ Si código se filtra = cuenta comprometida

Verifica identidad:
- Username + Password
- Access Key + Secret Key
- MFA token

Determina permisos:
- ¿Puedes lanzar EC2?
- ¿Puedes borrar S3 buckets?
- ¿Puedes ver billing?

Use cases:
✅ Empleados de la empresa
✅ Applications que necesitan AWS access
✅ Contractors/consultants
 
Cada user tiene:
- Username único
- Contraseña (para Console access)
- Access Keys (para API/CLI access)
- Permisos (via policies)

# Create user
aws iam create-user --user-name juan-developer
 
# Create login profile (console access)
aws iam create-login-profile \
  --user-name juan-developer \
  --password "TempPassword123!"
 
# Create access keys (CLI access)
aws iam create-access-key --user-name juan-developer
 
# Output:
# AccessKeyId: AKIAIOSFODNN7EXAMPLE
# SecretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

✅ Un user por persona (NO compartir)
✅ Enforza password policy fuerte
✅ Rotate access keys regularmente
✅ Elimina users que ya no necesitan acceso
❌ NUNCA uses root user para tareas diarias

Ejemplo organización:
 
Group: Developers
Members: juan, maria, pedro
Permissions: EC2, RDS, S3 (dev buckets)
 
Group: Admins
Members: sofia, carlos
Permissions: Full access
 
Group: DataScience
Members: ana, luis
Permissions: S3, Glue, SageMaker
 
Beneficio:
Asignas permisos al GROUP
Todos los members heredan permisos

# Create group
aws iam create-group --group-name Developers
 
# Add user to group
aws iam add-user-to-group \
  --user-name juan-developer \
  --group-name Developers
 
# Attach policy to group (todos los members lo heredan)
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess

✅ Users pueden estar en múltiples groups
✅ Groups NO pueden contener otros groups (no nesting)
✅ Groups facilitan gestión a escala
✅ Cambios a group afectan todos los members inmediatamente

Key difference:
User: Identidad permanente (juan tiene acceso)
Role: Identidad temporal (quien asume el role tiene acceso)
 
Use cases:
✅ EC2 instance necesita acceder S3
✅ Lambda function necesita escribir a DynamoDB
✅ Cross-account access (Account A → Account B)
✅ Federated users (Google/Microsoft login)

Problema:
EC2 instance necesita leer S3 bucket
 
❌ Mala solución:
Hardcodear AWS access keys en EC2
aws configure
→ Keys en disco (inseguro)
→ Si instance comprometida = keys expuestas
 
✅ Buena solución:
IAM Role para EC2
 
1. Create role con S3 read permissions
2. Attach role a EC2 instance
3. EC2 automáticamente obtiene temporary credentials
4. App usa AWS SDK (credentials automáticas)

# 1. Create role
aws iam create-role \
  --role-name EC2-S3-Read-Role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'
 
# 2. Attach S3 read policy
aws iam attach-role-policy \
  --role-name EC2-S3-Read-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
 
# 3. Create instance profile
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-Profile
 
# 4. Add role to instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-Profile \
  --role-name EC2-S3-Read-Role
 
# 5. Launch EC2 with instance profile
aws ec2 run-instances \
  --image-id ami-12345678 \
  --instance-type t2.micro \
  --iam-instance-profile Name=EC2-S3-Profile

import boto3
 
# AWS SDK automáticamente usa role credentials
# NO need to configure access keys
s3 = boto3.client('s3')
response = s3.list_buckets()
 
print(response['Buckets'])
# ✅ Works (usando temporary credentials from role)

Role credentials son temporales:
- Se renuevan automáticamente
- Expiran después de 1-12 horas (configurable)
- Más seguro que permanent access keys

Policy estructura:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow/Deny",
      "Action": "service:Action",
      "Resource": "arn:aws:...",
      "Condition": {...}
    }
  ]
}

Predefinidas por AWS:
 
- AdministratorAccess: Full access a todo
- PowerUserAccess: Todo excepto IAM
- ReadOnlyAccess: Solo lectura
- AmazonEC2FullAccess: Full EC2
- AmazonS3ReadOnlyAccess: Read S3
 
Ventaja: Maintained por AWS
Desventaja: Puede ser muy permisivo

Creadas por ti:
 
Ejemplo: Developers Policy
- Permite: Launch/stop EC2 en dev environment
- Niega: Terminar EC2 en prod
- Permite: Read/Write S3 en dev buckets
- Niega: Acceso a prod buckets
 
Ventaja: Customizado exactamente para tus needs

Policy directamente attached a user/group/role
 
Usa solo para one-off exceptions
Generalmente usa managed policies

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEC2Development",
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:StopInstances",
        "ec2:StartInstances",
        "ec2:DescribeInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "dev"
        }
      }
    },
    {
      "Sid": "DenyProductionTermination",
      "Effect": "Deny",
      "Action": "ec2:TerminateInstances",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "prod"
        }
      }
    }
  ]
}

Statement 1 (Allow):
- Permite launch/stop/start EC2
- Solo para instances con tag Environment=dev
 
Statement 2 (Deny):
- Niega terminate instances
- Para instances con tag Environment=prod
 
Resultado:
Developer puede trabajar libremente en dev
Pero NO puede terminar instances de prod

Cuando user intenta action:
 
1. Default: Implicitly DENY
 
2. Check all applicable policies:
   ├─ User policies
   ├─ Group policies (todos los groups)
   └─ Role policies (si usando role)
 
3. Evaluate:
   ├─ Explicit DENY? → DENY (wins always)
   ├─ Explicit ALLOW? → ALLOW
   └─ No match? → DENY (default)
 
Rule: DENY always wins over ALLOW

User: juan
Groups: Developers (allows EC2 full access)
User policy: Deny EC2 terminate for prod instances
 
Action: Terminate prod instance
 
Evaluation:
1. Group policy: Allow EC2 actions ✓
2. User policy: Deny EC2 terminate for prod ✗
 
Result: DENY (explicit deny wins)

MFA types:
1. Virtual MFA: Google Authenticator, Authy
2. Hardware MFA: YubiKey, Gemalto
3. SMS MFA (deprecated)
 
Root account MFA: CRÍTICO ✅
Users MFA: Highly recommended ✅

# Para root account:
# Console → Security Credentials → MFA → Activate MFA
 
# Para IAM user:
aws iam enable-mfa-device \
  --user-name juan-developer \
  --serial-number arn:aws:iam::123456789012:mfa/juan-developer \
  --authentication-code1 123456 \
  --authentication-code2 789012

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Principio: Solo da mínimos permisos necesarios
 
❌ Dar AdministratorAccess a todos
✅ Dar solo lo que necesitan
 
Ejemplo:
Developer que solo trabaja con Lambda:
✅ AWSLambdaFullAccess
❌ AdministratorAccess

Root account = acceso completo a TODO
 
Best practices:
✅ Habilita MFA
✅ NO uses para tareas diarias
✅ Crea IAM users para admin tasks
✅ Guarda root credentials seguramente
✅ Usa solo para account-level tasks
 
Account-level tasks:
- Cambiar payment information
- Close AWS account
- Change support plan
- Enable MFA on root

Configura password policy fuerte:
 
✅ Minimum length: 14+ characters
✅ Require uppercase
✅ Require lowercase
✅ Require numbers
✅ Require symbols
✅ Password expiration: 90 days
✅ Prevent password reuse
✅ MFA para sensitive operations

Access keys NO expiran automáticamente
 
Best practices:
✅ Rotate cada 90 días
✅ Usa roles cuando sea posible (temporary credentials)
✅ NO hardcodear en código
✅ Use AWS Secrets Manager para apps
 
Check last used:
aws iam get-access-key-last-used \
  --access-key-id AKIAIOSFODNN7EXAMPLE
 
Si no usado en 90+ días → DELETE

Siempre prefiere roles:
 
EC2 access to S3:
❌ Create access keys → store in EC2
✅ Create IAM role → attach to EC2
 
Lambda access to DynamoDB:
❌ Hardcode credentials
✅ Use execution role
 
Benefits:
- Temporary credentials (auto-rotate)
- No credential management
- Auditable (CloudTrail)

Analiza:
- S3 buckets accesibles externamente
- IAM roles assumable por external accounts
- KMS keys compartidas
- Lambda functions con cross-account access
 
Alerts:
"S3 bucket mi-bucket es público"
"Role arn:aws:iam::123:role/CrossAccount puede ser asumido por account 456"
 
Action: Review y revoca si no intencional