El cómputo en la nube ha revolucionado el mundo de TI, haciendo que sea más fácil para las empresas desplegar infraestructura y aplicaciones y entregar servicios al público. La idea de no gastar millones de dólares en equipo e instalaciones para hostear un data center on-premises es un prospecto atractivo para muchos. Y, ciertamente, mover recursos hacia la nube debe ser más seguro, ¿verdad? El proveedor de la nube va a mantener seguros nuestros datos y aplicaciones. Los hackers no tienen ninguna oportunidad. Está equivocado. Escucho esta ilusión más a menudo de lo que me gustaría de parte de muchos clientes. La verdad es que, sin una configuración y las capacidades apropiadas que administren la presencia en la nube, además de implementar prácticas de sentido común de seguridad, los servicios en la nube son igual de vulnerables (si no es que más).
El Modelo de Responsabilidad Compartida
Antes de avanzar, necesitamos discutir el modelo de responsabilidad compartida del proveedor del servicio en la nube y el usuario.
[image url=”https://blog.trendmicro.com/wp-content/uploads/2020/05/shared-responsibility-model.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Cuando uno planea su migración hacia la nube, se debe estar consciente de cuáles responsabilidades recaen en qué entidad. Como muestra la tabla de arriba, el proveedor de servicio en la nube es responsable por la seguridad física y de la infraestructura de la misma nube. En contraste, el cliente es responsable de sus propios datos, la seguridad de sus workloads (hasta la capa de OS), así como de la red interna dentro de los VCPs de la empresa.
Un aspecto muy importante que queda en las manos del cliente es el control de accesos. ¿Quién tiene acceso a qué recursos? Este aspecto no es tan diferente de como solía ser antes, la excepción es que la seguridad física del data center es gestionada por el CSP en lugar de un equipo on-premises de seguridad, pero la empresa (específicamente TI y seguridad de TI) es responsable de proteger sus recursos adecuadamente.
Muchas veces, este modelo de responsabilidad compartida es ignorado, y en su lugar se hacen suposiciones que funcionan como los recursos de seguridad de la empresa. El caos emerge, y tal vez un despido o dos.
Entonces, ahora que hemos establecido el modelo de responsabilidad compartida y que el cliente es responsable por la seguridad de sus propios recursos y datos, démosle un vistazo a algunos de los problemas de seguridad más comunes que pueden afectar a la nube.
Amazon S3
Amazon S3 es un gran servicio de Amazon Web Services. La capacidad de almacenar datos, hostear sitios estáticos o crear almacenamiento para aplicaciones de uso común son algunos de los motivos de uso para este servicio. Los buckets S3 también son un blanco importante para actores maliciosos, ya que muchas veces existen temas de configuración.
Un ejemplo de esto ocurrió en el 2017 cuando Booz Allen Hamilton, un contratista de defensa para los Estados Unidos, vio sus imágenes y credenciales de administración saqueadas.
Otra incidencia ocurrió en el 2017, cuando, debido a un bucket inseguro de Amazon S3, los registros electorales de 198 millones de americanos fueron expuestos. Hay una buena probabilidad de que si está leyendo esto y es ciudadano estadounidense, esta brecha lo haya afectado.
Una brecha más reciente de un bucket de Amazon S3 (y uso la palabra “brecha”; sin embargo, la mayoría de estas incidencias fueron resultado de malas configuraciones y exposición pública, no por un hacker usando técnicas sofisticadas) tuvo que ver con el proveedor de almacenamiento en la nube “Data Deposit Box.” Utilizando buckets de Amazon S3 para el almacenamiento, un problema de configuración causó que se filtraran más de 270,000 archivos personales, así como información personalmente identificable de sus usuarios.
Una última cosa que se debe tocar en el tema del almacenamiento de archivos en la nube tiene que ver con cuántas organizaciones están usando Amazon S3 para almacenar datos de clientes como un lugar al que se manda para que otras partes de la aplicación los procesen. El problema aquí es ¿cómo sabemos si lo que se está subiendo es malicioso o no? Esta pregunta surge cada vez más frecuentemente cuando hablo con clientes y colegas en el mundo de TI.
API
Las APIs son geniales. Nos permiten interactuar con programas y servicios de una forma automatizada y programática. Cuando se trata de la nube, las APIs permiten que los administradores interactúen con los servicios y, de hecho, son una piedra angular de todos los servicios en la nube, ya que permite que los diferentes servicios se comuniquen. Y, como con todo en este mundo, también operan en un mundo peligroso.
Comencemos con el API gateway, un constructo común en la nube para permitir la comunicación con aplicaciones del backend. El API gateway por sí mismo es un blanco, porque puede permitir que un hacker manipule el gateway e introduzca tráfico no deseado a través de él. Los API gateways fueron diseñados para integrarse en las aplicaciones. No fueron diseñados para la seguridad. Esto significa que conexiones no confiables pueden pasar a través del dicho gateway y tal vez recuperen datos que no deben ser vistos. De manera similar, las solicitudes de la API hacia el gateway pueden venir con cargas maliciosas.
Otro ataque que puede afectar su API gateway y la aplicación detrás de él es un ataque DDOS. La respuesta común para defenderse ante este ataque es un Web Application Firewall (WAF). El problema es que los WAFs tienen problemas para lidiar con ataques DDOS lentos y bajos, porque el flujo de solicitudes llega a parecer tráfico normal. Una gran manera de detener ataques DDOs en el API gateway es, sin embargo, limitar el número de solicitudes para cada método.
Una gran manera de prevenir ataques de API está en la configuración. Es importante negar accesos anónimos. De forma similar, cambiar tokens, contraseñas y claves limitan las posibilidades de que credenciales efectivas puedan ser usadas. Por último, deshabilitar cualquier tipo de autenticación de texto claro. Además, reforzar la encripción SSL/TLS e implementar autenticación multifactor son grandes barreras para estos ataques.
Cómputo
Ningún servicio en la nube está completo sin recursos de cómputo. Esto es cuando una organización construye máquinas virtuales para hostear aplicaciones y servicios. Esto también introduce una nueva superficie de ataque que, una vez más, no está protegida por el proveedor del servicio en la nube. Esto es la responsabilidad del cliente.
Muchas veces, al discutir la migración de mis clientes de un data center on-premises hacia la nube, uno de los métodos comunes es el enfoque “lift-and-shift”. Esto significa que los clientes toman las máquinas virtuales que ya están corriendo en su data center y simplemente las migran hacia la nube. Ahora, la pregunta es, ¿qué tipo de evaluación de seguridad se hizo en estas máquinas virtuales antes de su migración? ¿Estaban parchadas? ¿Se encontraron y arreglaron las fallas de seguridad? En mi experiencia personal, la respuesta es no. Por lo tanto, estas organizaciones simplemente están llevando sus problemas de una ubicación a otra. Los agujeros de seguridad todavía existen y tienen el potencial de verse explotados, especialmente si el servidor está de cara al público o si las políticas de red no son aplicadas correctamente. Para este tipo de proceso, creo que una mejor forma de ver esto es “correct-and-lift-and-shift”.
Ahora, una vez que las organizaciones ya han establecido su presencia en la nube, eventualmente necesitarán desplegar nuevos recursos, y esto puede significar desarrollar o construir sobre una imagen en la máquina. La cosa más importante para recordar es que estas son computadoras. Aún son vulnerables al malware, entonces, sin importar si está en la nube o no, se requieren los mismos controles de seguridad, incluyendo antimalware, IPS en el host, monitoreo de integridad y control de aplicaciones, sólo por mencionar algunos.
Networking
Los servicios en la nube hacen que sea increíblemente fácil desplegar redes y dividirlas en subredes, e incluso permitir la comunicación entre redes. También le dan la capacidad de elegir los tipos de tráfico que tienen permitido cruzar las redes para alcanzar los recursos. Es aquí donde entran los grupos de seguridad. Estos grupos de seguridad están configurados por personas, por lo que siempre hay una posibilidad de que un puerto que no debe estar abierto lo esté, abriendo así la puerta a vulnerabilidades potenciales. Es increíblemente importante desde esta perspectiva tener un panorama de con qué está “hablando” un recurso de cómputo y por qué, para que se puedan aplicar las medidas apropiadas de seguridad.
Entonces, ¿está la nube verdaderamente segura ante los hackers? En realidad, no es más segura que cualquier otra infraestructura, a menos de que las organizaciones tomen la seguridad en sus manos y entiendan dónde inicia su responsabilidad, y dónde termina la del proveedor de la nube. La carrera de armamentos entre los hackers y los profesionales de seguridad sigue siendo la misma de siempre. Simplemente ha cambiado el campo de batalla.
Leave a Reply