Gartner hizo una interesante predicción hace unos años: "Hasta 2025, el 99% de los fallos de seguridad en la nube serán culpa del cliente." Prácticamente todos los fallos de seguridad en la nube pueden describirse mayoritariamente como un error de configuración de un tipo u otro. El final de 2025 es algo arbitrario en realidad; es probable que la predicción se cumpla hasta el final de los tiempos.
En mi artículo anterior, hablé de cómo atajar estos errores de configuración en su raíz. Ahora, examinaré cómo la nube ha cambiado nuestra sensación de control y exploraré otro tipo importante de riesgo relacionado con la configuración que hay que mitigar.
Mayor abstracción, menor control
Las nubes no son la tecnología más barata ni la más fácil de gestionar. Sin embargo, son ciertamente mucho más ágiles que aprovisionar cosas en las instalaciones locales y esperar meses para que se despliegue todo el hardware y se instale el software.
Las nubes son esencialmente capas crecientes de abstracción. Cuando todo estaba en local, las organizaciones podían controlar la totalidad de las TI. Cuando la infraestructura se trasladó a la nube, las organizaciones cedieron el control directo de los niveles inferiores: el edificio, la red física, los racks y todos los servidores físicos. Los controles reales comienzan ahora justo por encima del hipervisor: máquinas virtuales, middleware, aplicaciones, datos y usuarios.
Cuando las organizaciones avanzan un grado más de abstracción hacia la plataforma como servicio (PaaS), están cediendo el control del sistema operativo. Luego, si llegan al nivel más alto de abstracción, es decir — el software como servicio (SaaS) — también han cedido al control de la aplicación. Lo único que queda en manos de la organización es la protección de los datos y la definición de cómo se accede a ellos.
Uno podría suponer que la nube sería más fácil sólo porque hay menos que controlar, pero la realidad ha resultado ser muy diferente.
Control de acceso a la nube pública
En general, conseguir que el modelo de control de acceso sea correcto incluso solamente en una de las nubes públicas es una tarea de enormes proporciones — pero pocas empresas modernas colocan todo en una sola nube. La mayoría de las empresas reparten las cargas de trabajo entre varios proveedores de nubes.
Los proveedores utilizan composiciones y terminología ligeramente diferentes entre sí, por lo que no es realmente portable de una plataforma a otra. (En general, todos aplican los mismos principios, pero utilizan léxicos diferentes.) También hay algunas diferencias conceptuales. Sin embargo, cada objeto en una nube pública será accedido por algún tipo de principio de seguridad, como un usuario o un servicio, por lo que obtener la lista de control de acceso correcta para cada objeto es el primer paso crucial.
Los principales proveedores de IaaS/PaaS ya ofrecen CSPM nativo, y es sensato que las empresas que utilizan un solo proveedor empiecen con el producto de ese proveedor. Sin embargo, la mayoría de las empresas distribuyen sus cargas de trabajo entre varios proveedores. Por este motivo, sugiero que se evalúe un CSPM de terceros. Si está en un sector regulado, priorice a los proveedores con entornos adaptados a ello. Busque productos que visualicen los flujos y las relaciones entre los recursos, donde a menudo se esconden los errores de configuración. Si opta por la corrección automática, asegúrese de que el producto se ejecuta completamente dentro del contexto de seguridad de sus cargas de trabajo en la nube y no requiere la creación de una cuenta de lectura/escritura para el proveedor.
Las herramientas de CSPM pueden evaluar cientos de configuraciones diferentes, incluidos los controles de acceso, en miles de tipos de objetos diferentes comparados con varios puntos de referencia. Esto ayuda a las organizaciones a entender dónde han aplicado ya los controles y también las áreas en las que podrían mejorar.
Estas herramientas están diseñadas para ayudar a las organizaciones a reducir el riesgo. Cuando se reduce el riesgo también se reduce la probabilidad de que se produzcan violaciones de seguridad — así como todas las consecuencias posteriores para la empresa. CSPM se ha convertido casi en un requisito porque ha demostrado ser una herramienta eficaz de reducción de riesgos que puede ayudar a superar parte de la complejidad inherente que conlleva ser una organización multi-nube.
Comprobación de la infraestructura y las aplicaciones en la nube en busca de debilidades explotables
Las herramientas CSPM evalúan la postura de seguridad del entorno de una aplicación. Pero, ¿qué pasa con la seguridad del código de la aplicación real?
Ahora, hemos entrado en el ámbito de las herramientas de escaneo de código. Algunos productos también ofrecen la posibilidad de hacer una copia de todo el entorno de ejecución, incluyendo el código de la aplicación, y luego sondearlo de varias maneras para intentar que se comporte mal. Cuando se escribe un software, suelen aparecer dos tipos de errores. Los errores ordinarios se manifiestan como un comportamiento que se espera pero que, por alguna razón, no funciona. La mayoría de los desarrolladores son expertos en encontrar y arreglar este tipo de errores, y los buenos escáneres de código simplifican aún más la tarea.
El otro tipo de error se manifiesta como un comportamiento que no se espera en absoluto. Otro nombre para este tipo de error es el de vulnerabilidad, y estos errores pueden ser bastante difíciles de encontrar. Por ejemplo, imagine un simple campo de entrada que ofrece un menú: "Introduzca uno para jugar, introduzca dos para terminar el programa." ¿Pero qué ocurre cuando alguien introduce "-999,99"? Usted no comprobó esta entrada inesperada y su programa puede comportarse de una manera que no había previsto — y tal vez este mal comportamiento crea una ventaja para un atacante.
Muchas organizaciones que utilizan la nube han adoptado prácticas de infraestructura como código, en las que las secuencias para aprovisionar la infraestructura se expresan en una forma de lenguaje de programación. Las vulnerabilidades también pueden surgir en este código. Aunque algunas herramientas de CSPM pueden comprobar este tipo de vulnerabilidades críticas, el escaneo de las recetas de infraestructura como código requiere una herramienta dedicada en general. Estas averiguan si hay errores en sus recetas de programación que puedan crear ventajas para que un atacante las explote.
El mayor obstáculo para el despliegue de herramientas de escaneo puede ser obtener la aceptación de los desarrolladores. Los desarrolladores podrían percibirlas como una tarea más que interrumpe su flujo sin beneficio alguno. La incorporación del proceso de escaneo en las herramientas existentes permite a los desarrolladores corregir las vulnerabilidades de seguridad de inmediato, ahorrando en última instancia tiempo y dinero — ya que es mucho más costoso corregir una vulnerabilidad en producción. Al evaluar los productos, la compatibilidad con los entornos y cadenas de procesos existentes debe ser la primera capacidad que se investigue.
Hemos examinado tres mecanismos para reducir los tipos de riesgos más comunes: CSPM, escaneo de aplicaciones y escaneo de infraestructura como código. Es razonable suponer que, con las herramientas adecuadas, las organizaciones pueden configurar y ejecutar sus nubes correctamente y, por lo tanto, reducir significativamente la probabilidad de que se produzca un problema de seguridad en la nube — y la probabilidad de que sea noticia. Esto es cada vez más importante porque las nubes son complicadas — y las usamos cada vez más.
Este artículo fue publicado originalmente por Forbes Tech Council.
