Permisos no utilizados en la nube pública: ¿solo es necesario deshabilitarlos?

Los grandes proveedores de nube pública ofrecen numerosos servicios. En 2021, AWS cuenta con más de 200 productos y servicios, Azure ofrece más de 160 servicios y Google suministra más de 90 servicios diferentes. 

Las amplias ofertas de estos grandes proveedores de la nube nos facilitan la vida, permitiéndonos centrarnos en la creación de grandes productos que nuestros usuarios disfrutan, sin tener que preocuparnos por la implementación, el mantenimiento y la escalabilidad de la infraestructura. Nuestros desarrolladores pueden acceder fácilmente a elementos básicos de infraestructura, como máquinas virtuales, así como a soluciones de plataforma como servicio (PaaS) que nos permiten integrar capacidades avanzadas de IA en nuestros productos y almacenar los datos de las aplicaciones en instancias de bases de datos gestionadas, etc. 

Por desgracia, con este nuevo escenario nos encontramos con un importante problema. Cuantos más servicios de nube pública consumamos, mayor será nuestra superficie de ataque. Muchos de nosotros estamos acostumbrados a evaluar la superficie de ataque desde el punto de vista de la red: ¿puede un actor malicioso acceder a mi sistema a través de la red? ¿Puede una máquina infectada en mi sistema comunicarse con el exterior a través de la red? Mientras que la seguridad y la supervisión del acceso a la red es primordial, a menudo se pasa por alto un vector de ataque diferente: los permisos o las autorizaciones.

Los grandes ambientes de nube pública, que aprovechan sólo un subconjunto de los cientos de servicios disponibles, pueden tener millones de permisos que necesitan ser gestionados. 

A lo largo de los años, se han desarrollado múltiples prácticas recomendadas para gestionar a los usuarios humanos. Sin embargo, en la nube pública, una gran cantidad de derechos pertenecen a identidades de máquinas (API). Lamentablemente, estos derechos a menudo se ignoran, lo que puede tener graves consecuencias, como hemos podido ver en el caso de Capital One. 

Según Gartner, hasta 2023, el 99% de los fallos de seguridad serán culpa del cliente, y el 75% de esos fallos serán consecuencia de una gestión inadecuada de las identidades, los accesos y los privilegios.

¿Cómo podemos gestionar la asignación de permisos en la nube pública? 

Un enfoque puede ser monitorear el uso de los permisos durante un período limitado. Si un permiso determinado no se ha utilizado durante 90 días, podemos asumir que no es necesario y revocarlo. 

El análisis de los detalles sobre el uso de los permisos puede obtenerse de forma automatizada del proveedor de la nube y analizarse mediante scripts escritos por el propio usuario o herramientas comerciales. 

Aunque el planteamiento descrito anteriormente es sencillo y fácil de aplicar, tiene un defecto fundamental. Considere este ejemplo: 5 desarrolladores están trabajando en una aplicación web. Se les ha asignado una cuenta de desarrollo en la nube de AWS donde despliegan y prueban su código. Sólo un desarrollador del equipo puede encender y apagar las máquinas virtuales (instancias EC2) utilizando estos permisos:

               "ec2:StartInstances"

               "ec2:StopInstances"

Como sus compañeros no estaban efectuando estas acciones durante un cierto tiempo, estos permisos se marcarían como no utilizados y se revocarían. Si el desarrollador está de baja, o ausente por cualquier motivo, uno de sus colegas tendrá que sustituirle, y encender y apagar las máquinas virtuales. En este caso, además, si su permiso fuera revocado, no podrían realizarlo, lo que crearía un problema de negocio que llevaría a tickets de soporte, proceso de aprobación y pérdida de tiempo. 

La revocación descrita anteriormente podría haberse evitado si se hubiera realizado una revisión manual y se hubiera determinado que los desarrolladores deberían tener unos permisos amplios para una cuenta de desarrollo. La revisión manual de cada permiso no utilizado, por desgracia, es algo que la mayoría de las empresas no pueden permitirse debido a la gran cantidad de permisos. 

Tenemos que encontrar una manera de minimizar nuestra superficie de ataque mediante la revocación de los permisos excesivos, mientras que al mismo tiempo nos aseguramos de que no estamos causando ninguna interrupción a nuestros colegas y / o aplicaciones. Como revisar los permisos manualmente no es factible, tenemos que confiar en la automatización o, para ser precisos, en el aprendizaje automático. Este enfoque identifica los permisos "seguros de eliminar", no solo los que no se utilizan, sino los que no se utilizan y no es probable que se necesiten en el futuro. 

Según un informe de Gartner, "la protección de la infraestructura de la nube es crucial, especialmente teniendo en cuenta el aumento de las cargas de trabajo alojadas en proveedores de servicios en la nube. Los profesionales de la seguridad y la gestión de riesgos deben desplegar herramientas que permitan una gestión eficaz de los derechos de la infraestructura en la nube y reduzcan los riesgos causados por un acceso involuntario".

Teniendo en cuenta la escala de la nube, necesitamos una solución que filtre el ruido y nos presente una lista reducida de elementos procesables (esto es, que no supongan un problema) que mejoren nuestra postura de seguridad, reduzcan la tensión entre los equipos de seguridad y DevOps y apoyen la adopción de la nube pública en la organización. 

Por último, consideremos de nuevo el ejemplo anterior con los 5 desarrolladores. Está bien que todos los desarrolladores tengan permisos generales a una cuenta AWS de desarrollo, sin embargo, si uno de los desarrolladores tiene derechos de acceso no utilizados a una cuenta de producción, mientras que ninguno de sus colegas tiene este tipo de acceso, se le marcaría para una investigación realizada por humanos. 

Una solución CIEM (Cloud Infrastructure Entitlement Management) desarrollada, por compañías como Zscaler,  permiten aplicar el aprendizaje automático para identificar si el permiso es anormal además de no ser utilizado

El CIEM es parte de una estrategia más amplia conocida como Plataforma de Protección de Aplicaciones Nativas de la Nube (CNAPP), una nueva categoría de productos de seguridad que incorpora la gestión de la postura de seguridad en la nube (CSPM), la gestión de los derechos de la infraestructura en la nube (CIEM) y la plataforma de protección de la carga de trabajo en la nube (CWPP).

CNAPP garantiza que las cargas de trabajo en la nube son seguras, combinando la seguridad de la infraestructura y los servicios en la nube con la seguridad de las cargas de trabajo/aplicaciones. Y a pesar de lo que el nombre "nativo de la nube" podría implicar, estas plataformas deberían ser tan aplicables a las cargas de trabajo que aprovechan los servicios nativos de la nube como a las cargas de trabajo de las aplicaciones tradicionales que se trasladan a la nube.

Alberto Cita, Sales Engineering Manager Iberia & Italia, Zscaler