En este capítulo
Modelos cloud y responsabilidad compartida
Los servicios cloud ofrecen recursos gestionados por un proveedor, pero la distribución de responsabilidades cambia según se contrate IaaS, PaaS o SaaS. En infraestructura como servicio, el cliente administra normalmente más componentes que en software como servicio. El proveedor no decide automáticamente quién puede leer los datos de una organización. Las regiones, la soberanía de información y los servicios gestionados influyen en contratos, continuidad y obligaciones regulatorias. Una exposición causada por permisos públicos de almacenamiento puede surgir aun cuando los servidores físicos estén protegidos. Entender el modelo concreto evita trasladar al proveedor responsabilidades que el cliente conserva.
Conceptos de este apartado
- IaaS, PaaS y SaaS
- Responsabilidades de proveedor y cliente
- Organizaciones, cuentas, suscripciones y proyectos
- Regiones, disponibilidad y soberanía
- Servicios gestionados y serverless
- Riesgo de configuración y shadow cloud
Gobierno y landing zones
Una landing zone establece la organización inicial de cuentas, redes, identidades y reglas cloud. Separar producción de pruebas, asignar responsables y aplicar políticas centrales ayuda a evitar cambios inseguros. El etiquetado permite reconocer activos y costes, pero también puede utilizarse para localizar recursos sin propietario. Las configuraciones de referencia o baselines definen un punto de partida verificable. Las políticas automáticas pueden bloquear acciones de alto riesgo o alertar de desviaciones. Conviene entender que una configuración segura hoy puede dejar de serlo tras un cambio de servicio, permisos o arquitectura, de modo que las comprobaciones deben repetirse.
Conceptos de este apartado
- Estructura de cuentas y suscripciones
- Políticas organizativas y guardrails
- Separación de entornos
- Etiquetado y ownership
- Baseline de configuración
- Automatización de cumplimiento
Identidad y secretos en cloud
En cloud las identidades incluyen usuarios, aplicaciones, roles de servicio y procesos temporales. La federación permite reutilizar controles corporativos y las credenciales de corta duración reducen ciertos riesgos de exposición. Los secretos como claves de API requieren almacenamiento especializado y rotación cuando corresponda. Un permiso concedido a toda una cuenta puede abarcar cientos de recursos que el solicitante no necesita. El mínimo privilegio se aplica por operación, recurso y contexto. En investigaciones, los eventos de cambio de permisos y acceso a recursos suelen ser tan importantes como los intentos de inicio de sesión.
Conceptos de este apartado
- Federación de identidades
- Roles y service principals
- Credenciales temporales
- Gestión de secretos y claves
- Mínimo privilegio cloud
- Permisos de recursos y políticas
Seguridad de red e infraestructura
Las redes virtuales, grupos de seguridad y rutas determinan qué recursos cloud pueden comunicarse. Un recurso no queda necesariamente protegido por carecer de una dirección pública: puede ser alcanzable mediante identidades comprometidas o conexiones internas. Los endpoints privados y mecanismos de acceso administrativo reducen exposición cuando están bien configurados. La protección contra ataques de denegación de servicio es otra capa distinta de la seguridad de aplicaciones. Revisar una arquitectura exige considerar conexiones híbridas, segmentación y configuración del sistema operativo. El riesgo surge tanto de amenazas externas como de errores de configuración que conectan indebidamente entornos.
Conceptos de este apartado
- VPC/VNet y segmentación
- Security groups y controles de red
- Conectividad híbrida
- Servicios perimetrales y protección DDoS
- Bastion, acceso administrativo y endpoints privados
- Hardening de cargas cloud
Protección de datos y monitorización
Proteger datos cloud requiere comprender dónde se almacenan, cómo se cifran y quién gestiona las claves. Los logs de actividad administrativa permiten reconstruir cambios de permisos, eliminación de recursos y operaciones de acceso cuando el servicio los registra. Si la retención es insuficiente, una investigación posterior puede carecer de información esencial. Las herramientas de gestión de postura de seguridad buscan configuraciones problemáticas, pero sus alertas necesitan valoración contextual. Exportar evidencia a un repositorio controlado puede ser necesario para preservar información frente a rotación de registros. Deben respetarse, además, límites de protección de datos y finalidad.
Conceptos de este apartado
- Cifrado en tránsito y reposo
- KMS y servicios de claves
- Logging de actividad administrativa
- Detección de configuraciones inseguras
- Security posture management
- Retención y centralización de evidencias
Incidentes y multicloud
La respuesta a incidentes cloud puede incluir revocar credenciales, aislar máquinas, preservar snapshots y consultar registros del proveedor. Estas acciones tienen efectos diferentes y algunas alteran evidencia si se ejecutan sin planificación. En un entorno multicloud, controles aparentemente equivalentes pueden producir registros distintos y depender de APIs incompatibles. Las estrategias de salida reducen dependencia de un proveedor y mejoran continuidad, pero requieren verificar formatos, tiempos de recuperación y obligaciones contractuales. Una arquitectura distribuida no garantiza automáticamente resiliencia si todos los servicios dependen de un único proveedor de identidad o conexión externa.
Conceptos de este apartado
- Respuesta a credenciales comprometidas
- Snapshot y preservación de evidencia
- Aislamiento de recursos
- Riesgos de SaaS y aplicaciones de terceros
- Estrategias multicloud e interoperabilidad
- Concentración, portabilidad y exit strategy
Un caso para comprenderlo
Un repositorio cloud se publica accidentalmente con permisos amplios. El informe debe establecer qué datos contenía, durante qué intervalo estuvo expuesto, qué accesos registró el proveedor y qué obligaciones pueden activarse. La respuesta puede incluir revocar permisos y conservar logs, pero no debe afirmar exfiltración sin evidencia que la sostenga.
Cómo aplicar estos conceptos
El punto de partida es describir el sistema o situación con precisión, distinguir hechos de suposiciones y seleccionar qué información permitiría comprobar una conclusión. A partir de ahí se identifican riesgos, controles, responsabilidades y evidencias posibles. La utilidad de estos conocimientos aumenta cuando se relacionan con otras áreas de la ciberseguridad y del Derecho informático.