Fundamentos de seguridad en la nube

Definición

Cloud security es el conjunto de prácticas, controles y configuraciones que protegen datos, identidades, redes y workloads desplegados en servicios cloud (IaaS/PaaS/SaaS), teniendo en cuenta que:

• El entorno es multi‑tenant (recursos compartidos mediante virtualización).
• Gran parte de la administración ocurre en el plano de control vía consola/API.
• La seguridad se rige por el modelo de responsabilidad compartida (ver Shared Responsibility Model).

Contexto

En cloud, muchos incidentes reales no ocurren por un “0‑day”, sino por configuración y permisos:

• Identidades con exceso de privilegios (IAM), credenciales expuestas o sin MFA.
• Recursos accesibles públicamente (p.ej., storage/buckets o servicios con puertos abiertos).
• Falta de logging/detección (sin trazabilidad de llamadas API).

La seguridad en cloud suele organizarse por dominios (como en el RAW):

1. Gestión de acceso (IAM)
2. Políticas (autorización granular)
3. Red (segmentación/filtrado)
4. Almacenamiento (cifrado, residencia, permisos)
5. Monitoreo/registro (detección y auditoría)
6. Backups/DR y parches (resiliencia)

Desarrollo (MIT-style)

1) Características y modelos de cloud

1.1 Características (por qué se usa)

Del RAW (y ampliado):

• Escalabilidad / elasticidad: crecer/disminuir recursos bajo demanda.
• Simplicidad: aprovisionamiento rápido y autoservicio.
• Rentable (pago por uso): coste variable vs CAPEX.
• Automatización: menos tareas manuales; más infraestructura como código.

1.2 Modelos de servicio (IaaS / PaaS / SaaS)

• IaaS: el proveedor entrega infraestructura (datacenter, red física, hypervisor). El cliente gestiona SO, configuración, apps y datos.
• PaaS: el proveedor añade plataforma/runtime gestionado. El cliente se centra en el software y los datos.
• SaaS: el proveedor opera la aplicación completa. El cliente gestiona cuentas, roles, configuración de seguridad y datos.

Nota: el RAW indica que SaaS lo usan clientes con habilidades técnicas “para la gestión”; en la práctica suele ser al revés (SaaS reduce carga operativa). Mantengo el texto original en la sección RAW y aquí dejo la aclaración.

Regla mental: cuanto más “managed” es el servicio, menos control técnico directo tienes… pero más crítica se vuelve la gobernanza de IAM/configuración/logging.

1.3 Modelos de despliegue

• Nube pública: recursos compartidos entre múltiples clientes.
• Nube privada: recursos dedicados a un único cliente.
• Nube híbrida: mezcla público/privado (p.ej., prod sensible en privado; pruebas en público).
• Nube comunitaria (mencionada en el RAW): compartida por una comunidad/organización con objetivos comunes.

Riesgos del RAW (y ampliado):

• Pública: dependencia del proveedor (lock‑in), abuso de permisos, superficies expuestas.
• Privada: riesgo de insiders del proveedor, desastres físicos, ataques externos.
• Comunitaria: dificultad de líneas base y gobernanza consistente.

2) Terminología esencial

Del RAW:

• Virtualización: base técnica para aislamiento/multi‑tenant.
• Computación (compute): capacidad de proceso (VMs/instancias/servicios gestionados).
• Almacenamiento (storage): repositorios lógicos (objetos, bloques, bases de datos).
• Redes: conectividad de alta velocidad y segmentación.

Ampliación práctica:

• VPC (Virtual Private Cloud): red virtual aislada lógicamente (subredes, rutas).
• Security Groups: firewall lógico por instancia/ENI (en AWS, reglas allow; implícito deny).
• NACL: ACL a nivel de subred (en AWS, allow/deny; y operativa distinta a SG).

3) Datos: clasificación y ciclo de vida

3.1 Qué proteger primero

El RAW aterriza el punto clave: en cloud, lo primero a proteger son los datos.

Clasificación (RAW):

• Confidenciales: críticos; incluyen PII.
• Internos: daño moderado si se exponen.
• Públicos: destinados al público.

Ampliación (buenas prácticas):

• Define owners, etiquetado, y controles por clase (cifrado, logging, retención, DLP).
• Separa “dato” (contenido) de “metadato” (nombres, tags, rutas, logs) — ambos pueden filtrar información.

3.2 Ciclo de vida (RAW → controles)

Fases del RAW: Crear/Actualizar → Almacenar → Usar → Compartir → Archivo → Destruir.

Controles recomendados (ampliación):

• En tránsito: TLS, rutas privadas cuando aplique, validación de certificados.
• En reposo: cifrado (server‑side / app‑side), control de claves (KMS/HSM), rotación.
• Acceso: mínimo privilegio, roles, revisiones periódicas.
• Backups: estrategia y pruebas de restauración (no basta con “tener backup”).
• Residencia/jurisdicción: ubicación/region, contratos y requisitos regulatorios.
• Destrucción: borrado seguro y/o crypto‑shredding (destruir claves para inutilizar datos cifrados) + validación del proceso.

4) Problemas típicos de seguridad en cloud (y mitigación)

Del RAW:

• Confidencialidad de datos (el cliente no ve el datacenter).
• Problemas de virtualización (aislamiento insuficiente).
• Interfaces/API inseguras.
• Usuarios maliciosos.
• Secuestro de cuentas/servicios (phishing, vuln, password reuse).
• Mecanismo de control de acceso (ACM) deficiente.

Mitigaciones prácticas:

• Tratar IAM como “nuevo perímetro”: MFA, least privilege, roles, JIT/PAM donde aplique (ver IAAA - Identification Authentication Authorization Accountability y IAM Checklist).
• Hardening de exposición: “deny by default”, apertura mínima (SG/NACL), y revisión de recursos públicos.
• Gobierno de APIs: autenticación fuerte, rate limiting, logging de llamadas, alertas.
• Seguridad de datos: cifrado + claves bien gestionadas + DLP + clasificación.

5) Seguridad a través de la gestión de acceso (IAM)

El RAW introduce la base:

• Identidades / entidades / principals (quién actúa).
• Roles (qué puede hacer bajo qué contexto).
• MFA (capa extra).

Ampliación (AWS como ejemplo, sin limitarse a AWS):

• Evita depender de un único “admin”; usa roles y asignación por grupos.
• Usa credenciales de corta duración cuando sea posible (federación/STS) en lugar de llaves permanentes.
• Separa:
  • Identidades humanas (SSO/IdP)
  • Workloads (roles de servicio)
  • Break‑glass (muy restringida, auditada)

6) Seguridad a través de políticas

Del RAW:

• Identity‑based policies (unidas a identidades).
• Resource‑based policies (en el recurso).
• Session‑based policies (temporales).

Ampliación:

• En IAM moderno, las políticas suelen evaluar Efecto (Allow/Deny) + Acción + Recurso + Condiciones (tiempo, IP, MFA, tags, etc.).
• Las condiciones son clave para pasar de RBAC puro a un enfoque tipo ABAC (atributos/tags).

7) Seguridad de red en cloud (capas)

Del RAW:

• Security Groups: reglas de permiso; sin reglas de denegación explícitas.
• NACL: listas con allow/deny para proteger subredes/VPC.
• Controles del proveedor (p.ej., firewalls administrados).

Ampliación (modelo mental):

• Usa capas: edge (WAF/CDN) → VPC/subnets (NACL/rutas) → workloads (SG) → host/app.
• Documenta “por qué” un puerto existe; el default operativo debe ser cerrado.

8) Seguridad de almacenamiento

Del RAW (y ampliación):

• Límites geográficos (residencia/region) + políticas.
• Autorización basada en roles.
• Cifrado en reposo (server‑side encryption) y estándares.

Puntos críticos (RAW):

• Proteger connection strings (host/user/password) y evitar exposición en repos o logs.
• Políticas de acceso, cifrado y controles físicos del proveedor.

9) Resiliencia: backups y Disaster Recovery (DR)

El RAW introduce “CDR” y los enfoques frío / (templado) / caliente, medidos por RTO (tiempo objetivo para recuperar).

Ampliación:

• Añade RPO (cuánta pérdida de datos es aceptable).
• DR no es “configurar y olvidar”: requiere tests periódicos, runbooks y ownership.

10) Monitoreo, registro y detección

Del RAW:

• Registro en tiempo real.
• Logging de llamadas a API.
• Informes de credenciales.
• En AWS: IAM logging básico + CloudTrail (API), CloudWatch (métricas/logs), GuardDuty (detección).

Ampliación:

• Centraliza logs (SIEM), define retención, y protege integridad.
• Activa detecciones para eventos de IAM (creación de llaves, cambios de políticas, MFA deshabilitado), exposición pública y exfil.

11) Actualizaciones y parches

El RAW menciona gestión automatizada y AWS Systems Manager / Patch Manager:

• Inventario/escaneo de parches faltantes.
• Políticas de parcheo (programado vs no programado).

Ampliación:

• Define ventanas de mantenimiento, testing, y criterios de rollback.

Ejemplos (AWS Console, basados en el RAW)

Estos ejemplos son de laboratorio (el RAW pide un usuario IAM con admin). En producción, preferir SSO/roles y mínimo privilegio.

• Crear usuario IAM (admin) con grupo AdministratorAccess.
• Crear una policy (JSON o editor visual) para denegar acciones (ejemplo: denegar RDS).
• Crear una NACL y añadir regla inbound para denegar puerto 22.
• Crear un S3 bucket y habilitar Server Side Encryption (S3 managed keys).
• Descargar Credential Report en IAM.
• Crear una Patch Policy en Systems Manager → Patch Manager.

Pitfalls / Errores comunes

• Exponer servicios a Internet por defecto (0.0.0.0/0) sin justificar.
• No exigir MFA y no revisar permisos (privilegios permanentes).
• Tener llaves/secretos en repositorios, imágenes, logs o connection strings.
• No activar CloudTrail/logging y descubrir incidentes “a ciegas”.
• Backups/DR sin pruebas (RTO/RPO teóricos).
• Cifrar datos pero no gobernar claves (rotación, acceso, separación de duties).

Diagrama

flowchart TD
  A[Datos] --> B[Clasificación]
  B --> C[Ciclo de vida: crear/almacenar/usar/compartir/archivar/destruir]

  subgraph Controles transversales
    I[IAM: identidades/roles/MFA] --> P[Políticas: allow/deny + condiciones]
    P --> N[Red: SG/NACL + segmentación]
    N --> S[Storage: cifrado + permisos + residencia]
    S --> L[Logs: API/CloudTrail + métricas + detección]
    L --> R[Resiliencia: backups/DR + parches]
  end

  C --> Controles transversales

Referencias

1. AWS Knowledge Center — Create and activate an AWS account: https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/