Los hackers utilizan automatizaciones para detectar los puntos débiles del cloud y encontrar de manera más fácil las brechas de seguridad.
Cuando una organización migra sus sistemas de TI a la nube -y crea nuevas aplicaciones en la nube- libera a su equipo de seguridad de la responsabilidad de construir y mantener la infraestructura física de TI. El modelo de seguridad compartida de la nube dicta que los proveedores de servicios en la nube (CSP), como Amazon Web Services (AWS), Google Cloud y Microsoft Azure, son responsables de la seguridad de la infraestructura física. Sus clientes son responsables del uso seguro de los recursos de la nube.
Pero adoptar la nube para crear y gestionar nuevas aplicaciones significa que los equipos de seguridad no pueden desplegar las tecnologías y procesos de seguridad tradicionales en los que han confiado durante mucho tiempo para frustrar los ciberataques. La computación en la nube representa un cambio de paradigma en sus funciones y responsabilidades y en su enfoque de la protección de los datos sensibles para que no caigan en manos equivocadas.
Los desarrolladores son dueños de sus entornos en la nube
La nube permite a los desarrolladores e ingenieros construir su infraestructura sobre la marcha sin la ayuda de un equipo de centro de datos. Tienen el poder de tomar sus propias decisiones de infraestructura -incluidas las configuraciones críticas para la seguridad- y luego cambiarlas cuando lo necesiten. Cuando hacen cambios, aumentan el riesgo de crear configuraciones erróneas que dejan su entorno abierto a los ataques, vulnerabilidades que las soluciones tradicionales de seguridad de redes y puntos finales no pueden detectar.
¿Por qué? Porque las interfaces de programación de aplicaciones (API) -los intermediarios de software que permiten que diferentes aplicaciones interactúen entre sí– son la base de la computación en nube. Los entornos de nube basados en API eliminan la necesidad de construir y mantener una arquitectura de TI fija en un centro de datos centralizado. La nube es un software programable, y los desarrolladores utilizan la infraestructura como código (IaC) para automatizar la construcción y la gestión de la infraestructura de la nube a escala.
Estos flujos de trabajo hacen imposible aplicar el modelo de seguridad tradicional de erigir una barrera hacia el exterior alrededor del perímetro para bloquear los ataques entrantes, y las auditorías periódicas quedan obsoletas antes de que se completen. La seguridad en la nube es una función de diseño y arquitectura, no sólo de supervisión y detección de intrusiones. Los atacantes de la nube van tras las API del plano de control de la nube para descubrir, mover y extraer datos. Las organizaciones deben dar prioridad a la seguridad del plano de control para evitar que los hackers adquieran sus claves API. Su enfoque de la seguridad debe evolucionar para seguir el ritmo de los hackers.
Los hackers actúan de forma diferente en la nube
Los malos actores utilizan la tecnología de automatización para detectar los puntos débiles que pueden explotar, como las desconfiguraciones de la nube, las vulnerabilidades de las aplicaciones y las claves de la API en el código fuente. Una vez que eligen sus objetivos, van a la caza de datos utilizando el plano de control de la nube. El compromiso del plano de control se ha producido en todas las violaciones importantes de la nube que se han producido hasta la fecha.
Los equipos de seguridad de la nube suelen encontrar y remediar docenas de problemas de desconfiguración a diario. Pero las desconfiguraciones son sólo una parte de la amenaza de seguridad más importante que representa sólo uno de los caminos que un hacker puede tomar para lograr comprometer el plano de control. Centrarse únicamente en la búsqueda y eliminación de errores de configuración de un solo recurso es una apuesta por los molinos de viento, ya que los hackers acabarán por colarse. Centrarse únicamente en la identificación de indicadores de compromiso (IOC) es aún más arriesgado: las violaciones de la nube pueden producirse en cuestión de minutos antes de que los equipos tengan la oportunidad de responder, incluso con las mejores herramientas de supervisión, análisis y alerta.