Responsabilidades «de» y «en» la nube
Es fundamental comprender las responsabilidades que asumirá —y no asumirá— un proveedor de nube y detectar las zonas grises. AWS, por ejemplo, describe brevemente su responsabilidad como protección «de» la nube, mientras que los clientes son responsables de la protección «en» la nube. Esta simplificación parece contravenir dos responsabilidades que para los clientes son fundamentales:
1. El proveedor de la nube no es responsable de la configuración segura de las cuentas y servicios de sus clientes. Aunque los proveedores de la nube ofrecen muchas configuraciones de seguridad por defecto, es responsabilidad de los clientes comprobarlas y contar con protección adicional según sea necesario para sus aplicaciones. Una falsa sensación de seguridad en este caso puede llevar a subestimar el tiempo y el esfuerzo necesarios para configurar correctamente un conjunto de servicios. En el informe «Cómo hacer frente a las amenazas del 2020», Gartner afirma que «Durante 2023, al menos el 99 % de los fallos de seguridad en la nube serán culpa del cliente».
Solo con una instancia de EC2, un bucket de S3, Lambda para las funciones y CloudTrail para la auditoría, estos servicios ya requieren decenas de configuraciones esenciales para evitar posibles fugas de datos y brechas en la seguridad. La buena noticia es que los errores pueden evitarse fácilmente con una solución de gestión de seguridad en la nube, que puede configurarla la persona de la empresa que tenga acceso a dichas cuentas. Evitar los errores en los despliegues simples podría ser tan sencillo como hacer una prueba rápida y gratuita.
2. No existe una fórmula única para proteger «en» la nube y el cliente debe conocer y comprender los matices que conlleva cada caso. Por ejemplo, Kubernetes en la nube podría llevarse a cabo a través de EKS u Open Source con el sistema operativo EC2 Amazon Linux 2 por defecto de AWS, o mediante el propio sistema operativo Linux del cliente. El modelo de responsabilidad compartida es muy diferente entre estas opciones y exige que el cliente haga un esfuerzo para entender todo el conjunto de responsabilidades de seguridad. Para más claridad: en el ejemplo anterior de Linux, los clientes deben aplicar parches a todo sistema operativo y aplicación invitados, mientras que AWS se encargaría de aplicarlos cuando se utiliza su sistema operativo por defecto.
Conclusiones
Durante esta serie de entradas hemos ido desmintiendo algunos mitos comúnmente aceptados en torno a la adopción de soluciones cloud y su seguridad. Plantearse cómo se van a implementar las capacidades de seguridad nativas en la nube antes de pasarse a un sistema en la nube requiere definir primero conceptos clave para este tipo de sistemas como la inmutabilidad, el desplazamiento del testeo a la izquierda y el aislamiento. Con tan solo una idea general de por qué los mitos más famosos no tienen ningún fundamento, los equipos pueden hacerse una idea más clara de cómo empezar a planificar una estrategia eficaz de seguridad nativa en la nube y el proceso en general. Además, solo es posible preparar la planificación de las responsabilidades, los recursos, los controles y la forma en la que los equipos deben interactuar entre sí si se tiene una idea clara de la realidad.
Y, sobre todo, aprender sobre la seguridad nativa en la nube antes de empezar a trabajar en ella puede ayudar a los equipos a sentirse más cerca del objetivo final, que es hacer que los entornos nativos en la nube sean más seguros que nunca. Los oficiales de seguridad de la información (CISOs) harían bien en adentrarse en este mundo nativo en la nube más pronto que tarde, porque una seguridad bien planteada acelerará su adopción, mejorará la eficiencia y convertirá a los equipos de seguridad en los héroes de la nube de la empresa.
