Seguridad en la nube
Cloud sustituyó muchas operaciones físicas por llamadas a una API. Crear una red, conceder acceso o publicar almacenamiento puede ocurrir en segundos y repetirse en varias regiones. La seguridad en la nube protege los datos, identidades, cargas de trabajo y servicios que nacen de ese plano de control. El proveedor opera parte de la infraestructura. El cliente sigue decidiendo cómo usa lo que controla.
Responsabilidad compartida
Sección titulada «Responsabilidad compartida»El proveedor protege los componentes que controla y el cliente protege su uso del servicio. El reparto exacto depende del modelo:
IaaS, PaaS y SaaS significan infraestructura, plataforma y software como servicio. A medida que el proveedor gestiona más capas, el cliente conserva menos operación técnica, pero sigue siendo responsable de configurar y utilizar correctamente lo que controla.
| Modelo | El cliente conserva más responsabilidad sobre |
|---|---|
| IaaS | Sistema operativo, red virtual, identidades, aplicaciones y datos |
| PaaS | Aplicaciones, identidades, configuración del servicio y datos |
| SaaS | Identidades, permisos, configuración, integraciones y gobierno de datos |
La documentación contractual y técnica del proveedor determina el límite real. “El proveedor cifra” no aclara quién gestiona las claves, qué metadatos quedan fuera ni quién puede autorizar una recuperación.
Superficies que se cruzan
Sección titulada «Superficies que se cruzan»El plano de identidad contiene cuentas raíz, federación, roles y credenciales temporales. Autoriza acciones sobre el plano de control, formado por las API que crean, modifican o eliminan recursos. Esas acciones terminan afectando al plano de datos, donde viven almacenamiento, bases de datos, colas, copias y transferencias.
La red, las cargas de trabajo y la telemetría atraviesan los tres. Una función puede carecer de dirección pública y seguir leyendo un bucket mediante su rol. Un endpoint privado limita la ruta, pero no corrige ese permiso. Los registros del plano de control pueden mostrar quién cambió la política, mientras los registros de acceso a datos explican qué objetos consultó después.
Los errores de configuración y los permisos acumulados son especialmente relevantes porque una sola identidad puede operar a gran escala y mediante API.
Por eso «no está expuesto a Internet» es una conclusión demasiado estrecha. La pregunta completa incluye quién puede asumir la identidad, desde qué organización o workload, qué acciones autoriza y qué controles independientes limitan el impacto.
Principios de trabajo
Sección titulada «Principios de trabajo»- inventariar cuentas, suscripciones, regiones, servicios y propietarios
- centralizar identidad y registros sin crear una dependencia única no recuperable
- aplicar mínimo privilegio y credenciales de corta duración
- separar entornos y cuentas según riesgo y función
- proteger datos y claves durante todo su ciclo de vida
- automatizar configuraciones de referencia y detectar desviaciones
- diseñar recuperación frente a errores, compromiso y pérdida del proveedor.
Antes de probar un entorno cloud
Sección titulada «Antes de probar un entorno cloud»Antes de probar un entorno cloud deben revisarse el alcance, las reglas del proveedor, los servicios gestionados y los límites entre tenants. Técnicas tolerables en un laboratorio propio pueden afectar capacidad compartida o incumplir las condiciones del servicio.
Una evaluación tampoco puede inferir la responsabilidad por el nombre comercial del servicio. Debe consultar la documentación vigente del proveedor y el contrato aplicable. Dos servicios SaaS pueden repartir de forma distinta las copias, las claves, los logs y la recuperación, aunque ambos oculten el sistema operativo.
Preguntas de repaso
Sección titulada «Preguntas de repaso»- ¿Por qué el modelo de responsabilidad compartida cambia entre IaaS, PaaS y SaaS?
- ¿Qué diferencia existe entre el plano de control y el plano de datos?
- ¿Por qué una identidad cloud comprometida puede tener un impacto especialmente amplio?