El modelo de responsabilidad compartida

Cuando un archivo está “en la nube”, está en un servidor propiedad de una empresa a la que nunca has conocido ni visitarás nunca. Ese arreglo divide la responsabilidad de seguridad entre dos partes, y la mayoría de las personas nunca aprende dónde cae esa división hasta que algo sale mal. Todo proveedor de nube importante documenta esta división de forma explícita, porque equivocarse en cualquiera de las dos direcciones — asumir que el proveedor lo cubre todo, o intentar proteger cosas que el proveedor ya gestiona — provoca incidentes reales.

Dos lados de una misma línea

Amazon Web Services llama a su versión de esta división el modelo de responsabilidad compartida, dividiéndola en “seguridad de la nube” y “seguridad en la nube”. AWS es responsable de la primera: “el hardware, el software, la red y las instalaciones que ejecutan los servicios de AWS Cloud” — los centros de datos físicos, la aplicación de parches a la infraestructura, las partes que nunca podrías inspeccionar ni configurar tú mismo aunque quisieras. El cliente es responsable de la segunda, y AWS es específico sobre qué incluye eso para los servicios de almacenamiento en la nube: “gestionar sus datos (incluidas las opciones de cifrado), clasificar sus activos y usar herramientas de IAM” — es decir, quién puede acceder a ellos.

La división se mueve según lo que uses

La documentación de Microsoft hace una observación que importa para quien elige entre distintos tipos de servicios en la nube: la línea divisoria no es fija, se mueve según el modelo de servicio. Su tabla de responsabilidades enumera los datos del cliente, las identidades de las cuentas y la gestión de acceso como siempre trabajo del cliente, en todo modelo, ya sea local o en la nube. Pero a medida que te mueves de infraestructura como servicio (alquilar una máquina virtual que configuras tú mismo) hacia software como servicio (usar una aplicación ya hecha, como un servicio de correo o de compartir archivos), Microsoft asume más: los sistemas operativos, el código de las aplicaciones y la configuración de red se vuelven cada vez más trabajo de Microsoft y no tuyo. Lo que nunca se mueve, en palabras de Microsoft, es que “tú siempre conservas” la responsabilidad sobre tus datos, tus cuentas, tus dispositivos cliente y tus controles de acceso.

Por qué el lado del cliente importa más de lo que parece

Para una ONG que usa un servicio ya hecho de compartir archivos o de correo — software como servicio, el modelo donde el proveedor gestiona la mayor parte — resulta tentador asumir que la seguridad del proveedor ya es toda la historia. No lo es. El lado del proveedor en esa línea (sus servidores, su red, su aplicación de parches) suele ser excelente en los servicios grandes; precisamente por eso los atacantes rara vez se molestan en atacarlo directamente. En su lugar, apuntan al lado del cliente: una contraseña débil o reutilizada, un enlace compartido más ampliamente de lo previsto, una cuenta sin un segundo factor. Cada categoría de la lista de “siempre trabajo del cliente” de arriba es, no por casualidad, el tema de la siguiente lección de este curso.

Una pregunta que vale la pena hacerse sobre cualquier servicio en la nube que uses

Antes de confiarle material sensible a un servicio en la nube, vale la pena buscar su propia documentación de responsabilidad compartida (todos los grandes proveedores publican una) y hacerse dos preguntas: ¿qué protege realmente el proveedor por defecto, y qué queda explícitamente en mis manos? La respuesta suele aclarar exactamente de cuáles de tus propios hábitos — tratados en el resto de este curso — depende realmente la seguridad de esos datos.