El modelo de responsabilidad compartida

De quién es la culpa cuando el bucket queda abierto

Un equipo crea un bucket para guardar los archivos que suben los usuarios de su app. Para avanzar rápido durante las pruebas, activan el acceso público con la intención de cerrarlo antes de salir a producción. Se olvidan. Seis meses después, un investigador de seguridad encuentra el bucket completo a una búsqueda de distancia, con cada archivo subido legible por cualquiera que tenga el link. ¿Quién falló: el proveedor de nube, o el equipo?

Falló el equipo. No porque escribieran mal un comando, sino porque trataron una decisión que siempre fue suya como si el proveedor la hubiera tomado por ellos. Ese vacío entre lo que un proveedor asegura y lo que un cliente configura es exactamente lo que el modelo de responsabilidad compartida existe para cerrar.

Seguridad de la nube, seguridad en la nube

AWS le pone nombre a su mitad del reparto: "seguridad de la nube". Ahí entran los centros de datos físicos, los racks dentro de ellos, el hipervisor que divide un servidor físico en varias máquinas virtuales y la red global que conecta las regiones de AWS. Nunca ves nada de eso, y nunca lo parchas tú.

Tu mitad es "seguridad en la nube": todo lo que construyes, configuras y guardas usando los servicios que el proveedor te entrega. Ahí siempre entran tus datos y tus políticas de acceso. Según qué servicio elegiste, también puede entrar tu sistema operativo invitado y el código de tu aplicación.

El límite se mueve según el modelo de servicio

Ese reparto no está fijo en un solo punto. Se desliza a lo largo de la pila según cuánto de esa pila le pediste al proveedor que administre.

Lee la tabla de arriba hacia abajo, no columna por columna: las 2 filas de arriba casi nunca pasan al proveedor, y las 2 de abajo casi nunca pasan al cliente. Las filas del medio son donde viven las decisiones interesantes, y donde ocurren la mayoría de las preguntas de examen y las configuraciones mal hechas en el mundo real.

Ejemplo trabajado: la misma función, 2 modelos de servicio

Un equipo corre una API en Node.js sobre una máquina virtual con Ubuntu. AWS se encarga del servidor físico, del hipervisor y de la red entre zonas de disponibilidad. El equipo se encarga de parchar Ubuntu cuando sale una vulnerabilidad en el kernel, de configurar el security group para que solo el puerto 443 quede abierto y de rotar la llave SSH que usan para conectarse. Eso es IaaS: la balanza pesa fuerte del lado del cliente.

Ahora ese mismo equipo reconstruye la función de carga de imágenes con un bucket S3 y una función Lambda que redimensiona las fotos apenas llegan. AWS ahora administra por completo el sistema operativo y el runtime donde corre Lambda; no hay ningún servidor que el equipo tenga que parchar. Lo que sigue siendo suyo: la política de acceso del bucket S3, qué puede tocar el rol de IAM que asume la función y si los archivos guardados están cifrados. Pasar de IaaS a un servicio serverless tipo PaaS le quitó una fila entera al lado del cliente en la tabla. No le quitó la fila de arriba.

Lo que nunca cruza la línea

Sin importar si es IaaS, PaaS o SaaS, 2 cosas siguen siendo trabajo del cliente en todos los casos: los datos mismos, incluida su clasificación y las decisiones de cifrado, y la gestión de identidad y acceso, es decir, quién puede entrar y qué puede hacer una vez adentro. Un proveedor puede cifrar un disco por defecto, pero solo el cliente decide qué archivos son lo bastante sensibles como para restringirlos más, y solo el cliente decide quién del equipo tiene acceso a ellos. Las próximas 2 lecciones de este tema cubren justo esas 2 filas a fondo: primero identidad, después cifrado.

Error de concepto: un certificado que no ganaste

Es tentador asumir que, como tu proveedor de nube tiene certificación SOC 2 o ISO 27001, tu propia aplicación hereda esa certificación. No la hereda. El certificado del proveedor cubre la infraestructura que él opera: los centros de datos, el hipervisor, el funcionamiento interno de sus servicios administrados. Si los controles de acceso, la configuración de cifrado y las prácticas de manejo de datos de tu aplicación cumplen un estándar dado es una auditoría aparte, y solo tú puedes producir evidencia para ella. La última lección de este tema vuelve a este mismo vacío y muestra cómo los equipos lo cierran.

Pistas de examen: cómo leer una pregunta de responsabilidad compartida

La trampa clásica: una pregunta que menciona un servicio administrado o serverless y espera que asumas que el proveedor ahora se hace cargo de todo. Se hace cargo de más de lo que hacía bajo IaaS, pero los datos y la identidad nunca se mueven.

Dónde te deja esto

A medida que avanzas de IaaS hacia SaaS, la porción del proveedor en la tabla crece y la del cliente se achica, pero las 2 filas de arriba, datos e identidad, nunca cruzan esa línea en ningún sentido. Aprender a leer un escenario y ubicarlo correctamente en esta tabla es la habilidad más evaluada en seguridad de la nube. La siguiente lección abre de lleno la mitad de identidad: cómo confirma la nube quién eres, y cómo decide qué puedes hacer una vez que lo sabe.