Cuando MFA no es suficiente

La regla número uno en seguridad cloud es: "usarás MFA en todo momento". ¿Por qué? Bueno, cuando se migra a la computación en cloud pública, básicamente se toman todas las interfaces administrativas, se consolidan en un único portal o API y luego… se colocan en Internet protegidas con un nombre de usuario, una contraseña y (tal vez) MFA. Incluso cuando se utiliza una federación.

Pero resulta que ni siquiera MFA es siempre suficiente, como se ha visto en varias brechas de seguridad importantes, incluida la de Uber.

Esta es una de las diferencias más críticas que hay que entender entre el cloud y la infraestructura tradicional, y es la razón por la que se escucha constantemente la frase "la identidad es el nuevo perímetro". Antes del cloud, gestionábamos nuestro centro de datos desde redes privadas internas (o mediante puntos de acceso controlados como VPN y jump boxes). Con el cloud, todo eso está en Internet de forma predeterminada y es difícil de restringir, sobre todo ahora que con mayor frecuencia damos soporte a empleados y administradores remotos.

MFA es una forma eficaz de proteger la autenticación de usuarios y administradores. Tenemos muchísimas opciones, que van desde las algo más seguras (MFA basada en mensajes) hasta las realmente seguras (llaves de hardware). Pero el problema, incluso con MFA, es que los usuarios tienen acceso persistente con privilegios persistentes. Si se le asigna un rol a un usuario, este puede usar esos permisos en cualquier momento después de autenticarse. Los atacantes lo saben y han desarrollado una serie de técnicas para obtener acceso autenticado. Ellos:

• abusan de las credenciales estáticas, especialmente si no se utiliza MFA.
• vulneran algunos tipos de MFA. Por ejemplo, hacen SIM swap para interceptar los mensajes de texto dirigidos a los teléfonos.
• aplican ingeniería social a los administradores para que desactiven MFA o lo restablezcan en un dispositivo bajo su control.
• aplican ingeniería social a los usuarios para obtener un código MFA.
• roban credenciales de sesión del sistema de un usuario después de que este ya se haya autenticado y luego las utilizan desde un sistema bajo el control del atacante.

Una vez que un atacante obtiene acceso, comienza a explorar privilegios y finalmente los utiliza para actividades maliciosas.

El mínimo privilegio es una mentira

El problema de fondo es que otorgamos permisos no en función de lo que alguien necesita hacer en un momento determinado, sino de lo que podría necesitar hacer en el futuro. Los usuarios, especialmente los administradores, tienen el conjunto máximo de permisos para todas las acciones posibles. Todos los estándares de seguridad del planeta dicen que IAM debe ser de denegación predeterminada y mínimo privilegio, pero eso es en cierto modo una mentira, ya que el conjunto de "mínimos privilegios" se define por el conjunto máximo de privilegios que necesitarán en algún momento, no en todo momento.

Incluso cuando permitimos que los usuarios cambien de rol y utilicen permisos distintos en sesiones distintas, casi siempre siguen teniendo acceso a esos roles cuando lo deseen. En realidad, el mínimo privilegio debería estar limitado por tiempo, no solo por usuario. Históricamente gestionamos los permisos asignando roles, y los roles tienen permisos dentro de un alcance. "Usted es administrador en estas 5 cuentas y usuario común en las otras 98". A menudo incluso asignamos varios roles a un usuario, que bien combinan permisos o bien le permiten alternar entre roles al realizar distintas tareas.

Imagine cuánto más difícil sería para un atacante si elimináramos los privilegios persistentes. En lugar de que un usuario se autentique y tenga acceso a todos sus permisos, tendría acceso con un conjunto muy reducido de permisos y tendría que escalar para cualquier acción potencialmente dañina.

Agregue seguridad con autorizaciones dinámicas

No propongo que eliminemos MFA u otras medidas de seguridad a nivel de autenticación. Siguen siendo de vital importancia, pero a veces no son suficientes. Esto es especialmente cierto en la seguridad cloud, debido al mayor grado de exposición inherente a Internet. Pero el cloud también tiene ventajas, entre ellas la federación basada en sesiones y las autorizaciones granulares (hasta el nivel de llamadas API individuales).

En lugar de brindar a los usuarios acceso persistente a todos los permisos que podrían llegar a necesitar, les brindamos un acceso más limitado y ellos solicitan acceso a privilegios escalados. No es un concepto nuevo; es lo que los productos de gestión de usuarios privilegiados han utilizado durante años. Pero esos productos a menudo siguen dependiendo de técnicas poco prácticas, como sesiones proxy y contraseñas temporales rotativas. El cloud es intrínsecamente más flexible, ya que los modelos IAM nativos son por naturaleza basados en sesiones y los privilegios se definen en documentos de políticas (normalmente escritos en JSON).

Así es como funcionan herramientas como nuestro FireMon Authorization Control. O bien, eche un vistazo a Netflix ConsoleMe para ver un ejemplo de código abierto. Los usuarios solicitan acceso cuando lo necesitan y, entonces, las plataformas utilizan políticas para determinar qué se requiere para su aprobación. Cuando se cumplen esas condiciones, como la aprobación de un gerente o de un compañero de trabajo, se autoriza al usuario a utilizar un rol durante una sesión. Las plataformas incluso pueden insertar condiciones, como "permitir esta sesión únicamente desde la dirección IP que la solicitó". Estas solicitudes suelen ser fuera de banda y utilizan canales alternos como ChatOps para las aprobaciones, lo que hace que el proceso sea deliberadamente ruidoso, especialmente para el acceso sensible a producción.

La seguridad a nivel de autorización en realidad facilita la vida de todos, desde los desarrolladores y usuarios hasta los administradores de seguridad. No es necesario conocer de antemano el conjunto completo de permisos posibles. En cambio, los usuarios piden lo que necesitan cuando lo necesitan. Las políticas determinan la vía con menor fricción para otorgar ese acceso sin comprometer la seguridad. Herramientas como ChatOps permiten que un desarrollador solicite acceso a una nueva cuenta y obtenga una respuesta en cuestión de segundos, en lugar de tener que enviar una solicitud a un sistema de tickets que podría tardar días o semanas.

Al agregar seguridad a la autorización, reducimos el impacto de las credenciales robadas y las autenticaciones vulneradas, al tiempo que reducimos la fricción y la carga operativa.