AWS Cloud Practitioner #5: Shared Responsibility Model - ¿Quién es Responsable de Qué?

Incidente: Bucket S3 con 100,000 registros de clientes públicamente accesible
 
Análisis:
❌ "Es culpa de AWS"
✅ "Es culpa nuestra"
 
¿Por qué?
- AWS es responsable de: Seguridad DE la plataforma S3
- TÚ eres responsable de: Configurar el bucket como privado

AWS: Security OF the Cloud
     (Infraestructura física y software que corre AWS)
 
CLIENTE: Security IN the Cloud
         (Datos, configuración, accesos)

- Servidores físicos
- Storage devices
- Network equipment
- Cables, racks, refrigeración

- Seguridad física del edificio
- Control de acceso (biométrico, guardias)
- Vigilancia 24/7
- Energía y refrigeración redundante

- Routers, switches
- Firewalls perimetrales
- DDoS protection
- Network monitoring

- Hypervisor (software de virtualización)
- Isolation entre clientes
- Hardware segregation

Para servicios como RDS, Lambda:
- OS patches
- Database updates
- Scaling infrastructure

Servicio: Amazon RDS (PostgreSQL)
 
AWS gestiona:
✅ Servidores físicos donde corre RDS
✅ Hypervisor que virtualiza recursos
✅ Patches del OS
✅ Patches de PostgreSQL
✅ Backups automáticos (infraestructura)
✅ Multi-AZ replication (infraestructura)
 
Tú NO necesitas:
❌ Preocuparte por seguridad física
❌ Actualizar el OS manualmente
❌ Configurar replicación a nivel de hardware

- Proteger datos sensibles
- Encriptar información
- Clasificar datos
- Retención y eliminación

- Código de tu aplicación
- Configuración de aplicaciones
- Dependencies y libraries

- Usuarios y permisos
- MFA (Multi-Factor Authentication)
- Password policies
- Roles y policies

- Patches de OS
- Firewall configuration
- Anti-virus

- Security Groups
- Network ACLs
- VPC configuration
- Subnet design

- Security Group rules
- WAF rules
- Network ACL rules

- Encriptar antes de subir a AWS
- Gestionar encryption keys

- Habilitar encryption en S3
- Configurar KMS keys
- Encryption at rest configuration

Servicio: Amazon S3
 
Tú gestionas:
✅ Configurar bucket como privado/público
✅ Configurar policies de acceso (quién puede leer/escribir)
✅ Habilitar versioning
✅ Habilitar encryption
✅ Configurar lifecycle policies
✅ Configurar bucket logging
✅ Contenido que subes al bucket
 
Ejemplo de error común:
❌ Hacer bucket público por accidente
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",  ← ¡Acceso público!
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mi-bucket/*"
  }]
}
 
✅ Configuración correcta (privado):
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:user/juan"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mi-bucket/*"
  }]
}

✅ Hardware físico
✅ Hypervisor
✅ Network infrastructure
✅ Physical security

✅ OS (Windows/Linux)
✅ OS patches y updates
✅ Applications
✅ Security Groups
✅ IAM roles
✅ Data encryption
✅ Firewall del OS
✅ Anti-virus

# Eres responsable de actualizar el OS
# AWS NO hace esto automáticamente para EC2
 
sudo yum update -y  # Amazon Linux
sudo apt update && sudo apt upgrade -y  # Ubuntu
 
# También eres responsable de configurar firewall
sudo ufw enable
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp

✅ Hardware físico
✅ Hypervisor
✅ OS (no tienes acceso SSH)
✅ OS patches
✅ Database patches
✅ Backups (infraestructura)
✅ Multi-AZ replication (setup)

✅ Database configuration
✅ Database users y passwords
✅ IAM policies para acceso
✅ Security Groups
✅ Data encryption (habilitar)
✅ Backups (retención, scheduling)
✅ Data dentro de la database

-- AWS gestiona el engine PostgreSQL
-- Pero TÚ gestionas users, roles, data
 
-- Eres responsable de:
CREATE USER app_user WITH PASSWORD 'secure_password_123';
GRANT SELECT, INSERT ON orders TO app_user;
 
-- También de encriptar datos sensibles
CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100),
  ssn BYTEA  -- Encriptado a nivel de aplicación ANTES de insertar
);

✅ TODO el software
✅ TODO el infrastructure
✅ OS, patches, updates
✅ Scaling, availability
✅ Email delivery infrastructure

✅ Usuarios y permisos
✅ Configuración de políticas de email
✅ Data governance
✅ Compliance de contenido

✅ Hardware
✅ OS
✅ Runtime (Node.js, Python, etc.)
✅ Scaling
✅ High availability

✅ Código de la función
✅ IAM roles/policies
✅ Environment variables
✅ Configuration (memory, timeout)
✅ Dependencies

# Lambda function
# AWS gestiona: servers, OS, Python runtime
# TÚ gestionas: código, IAM role, environment vars
 
import os
import boto3
 
def lambda_handler(event, context):
    # TU responsabilidad: código seguro
    # No hardcodear credenciales
 
    # ❌ MAL
    # api_key = "sk_live_12345"
 
    # ✅ BIEN
    api_key = os.environ['API_KEY']  # Desde env vars
 
    return {
        'statusCode': 200,
        'body': 'Success'
    }

# AWS provee la capacidad
# TÚ debes habilitarla
 
# Habilitar encryption
aws s3api put-bucket-encryption \
  --bucket mi-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }]
  }'

# Terraform example
# TÚ eres responsable de configurar Security Groups
 
resource "aws_security_group" "web_sg" {
  name = "web-server-sg"
 
  # ✅ BIEN: Solo permite HTTPS
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
 
  # ❌ MAL: No abras todos los puertos
  # ingress {
  #   from_port   = 0
  #   to_port     = 65535
  #   protocol    = "tcp"
  #   cidr_blocks = ["0.0.0.0/0"]
  # }
}

Escenario: Base de datos RDS con datos sensibles
 
❌ Pensamiento erróneo:
"AWS gestiona RDS, entonces mis datos están automáticamente:
- Encriptados
- Con backups
- Protegidos de acceso no autorizado"
 
✅ Realidad:
AWS provee las herramientas, TÚ debes:
- Habilitar encryption
- Configurar backups
- Configurar Security Groups
- Gestionar users/passwords
- Configurar IAM policies

# AWS gestiona: Network infrastructure
# TÚ gestionas: Security Groups
 
# ❌ Default security group (NO recomendado para producción)
# Permite TODO el tráfico dentro del VPC
 
# ✅ Security group restrictivo
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 443 \
  --cidr 10.0.0.0/16  # Solo desde tu VPC

❌ AWS NO hace backups automáticos de EC2 instances
✅ TÚ debes: Configurar snapshots, usar AWS Backup, o third-party solutions

✅ AWS puede hacer automated backups
⚠️ Pero TÚ debes: HABILITAR la feature y configurar retention

# RDS: Habilitar automated backups
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --backup-retention-period 7 \  # Retener 7 días
  --preferred-backup-window "03:00-04:00"  # 3-4 AM

Causa raíz: Bucket S3 configurado como público
 
¿Culpa de AWS? NO
¿Culpa del cliente? SÍ
 
Responsabilidad del cliente:
- Configurar bucket policies correctamente
- No hacer buckets públicos por defecto
- Usar S3 Block Public Access
- Auditar configuraciones regularmente
 
Herramientas AWS (que cliente NO usó):
- S3 Block Public Access (previene buckets públicos)
- AWS Config (detecta configuraciones incorrectas)
- CloudTrail (audita cambios)

Causa raíz: Faltaron patches de seguridad en OS
 
¿Culpa de AWS? NO
¿Culpa del cliente? SÍ
 
Responsabilidad del cliente (para EC2):
- Aplicar patches de seguridad regularmente
- Configurar Security Groups restrictivos
- Usar IAM roles (no credenciales hardcoded)
- Implementar monitoring/alerting
 
Prevención:
# Automated patching con Systems Manager
aws ssm create-patch-baseline \
  --name "ProductionBaseline" \
  --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=CLASSIFICATION,Values=[Security]}]},ApproveAfterDays=7}]"

¿Culpa de AWS? NO
¿Culpa del cliente? SÍ
 
Responsabilidad del cliente:
- Habilitar encryption at rest para RDS
- Usar SSL/TLS para connections (encryption in transit)
- Gestionar KMS keys
 
AWS provee:
✅ Encryption capability (KMS)
✅ Documentación
 
Cliente debe:
✅ Habilitar encryption
✅ Configurar correctamente
 
# Crear RDS con encryption
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --engine postgres \
  --storage-encrypted \  # ← Cliente debe especificar
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012

Regla simple:
 
IaaS (EC2):      Cliente gestiona MÁS  (OS, apps, data)
PaaS (RDS):      Cliente gestiona MEDIO (config, data)
SaaS (WorkMail): Cliente gestiona MENOS (solo users, policies)
 
Pero SIEMPRE:
- Cliente gestiona: Data, IAM, Encryption (habilitarla)
- AWS gestiona: Physical infrastructure, hypervisor

✅ Data encryption (habilitar y configurar)
✅ IAM users, roles, policies
✅ Security Groups / Network ACLs
✅ Bucket policies (S3)
✅ Data classification
✅ Compliance con regulaciones de tu industria

✅ Physical security de data centers
✅ Hardware (servers, storage, network)
✅ Hypervisor
✅ Network infrastructure (cabling, routers físicos)
✅ Managed service operations (RDS patches, Lambda scaling, etc.)