Implicaciones de la brecha AuthN/AuthZ

Se ha vuelto de conocimiento común que en el cloud "la identidad es el nuevo perímetro". Es una frase agradable y fácil de incluir en una presentación o en un artículo, pero convertirla en una guía accionable es un poco más difícil. Hoy quiero centrarme en un solo aspecto del IAM en el cloud que llamo la "brecha AuthN/AuthZ". En realidad es un problema siempre que se utiliza federación, pero en el cloud lo que está en juego es mayor, ya que el plano de administración del cloud siempre está expuesto a internet.

Primero, una breve introducción a AuthN frente a AuthZ:

• AuthN es autenticación. El acto de demostrar que uno es una entidad determinada. Para los simples mortales, esto suele ser un nombre de usuario, una contraseña y quizás MFA.
• AuthZ es autorización. El acto de verificar si una acción está permitida. Para el cloud IaaS, esto casi siempre se traduce en una llamada a la API, incluso cuando se usa la consola o el portal web.

La autenticación y la autorización son tareas diferentes, con flujos diferentes. Cuando iniciamos sesión en un sitio web nos autenticamos y eso normalmente crea una sesión. No tenemos que volver a ingresar nuestras credenciales cada vez que hacemos clic en algo; nuestro navegador simplemente envía un token que es válido durante un período de tiempo. Las autorizaciones, en cambio, suelen verificarse cada vez que intentamos hacer algo, para asegurar que tenemos los permisos correctos.

Si lo piensa, una vez que tiene ese token de sesión, no se vuelve a verificar a menos que algo en el código fuerce una nueva comprobación. Su autenticación es válida durante la sesión y, por lo tanto, puede hacer todo lo que esté dentro del alcance de sus autorizaciones. Según la plataforma o el sistema, esas credenciales temporales seguirán funcionando incluso si se revocan o si la cuenta se elimina por completo. Esta es la brecha AuthN/AuthZ.

Dedico mucho tiempo a este tema cuando enseño respuesta a incidentes en el cloud, ya que he comprobado que incluso los responsables de seguridad con experiencia no siempre comprenden sus implicaciones. Imagine el caso de unas credenciales de cloud robadas: usted revoca o elimina las credenciales, pero el atacante tiene una sesión abierta activa y potencialmente aún puede ejecutar acciones autorizadas. Esto es… malo.

¿Cómo se resuelve?

Según cómo esté usando esas credenciales, la opción más sencilla suele ser cambiar la autorización. Basta con aplicar una política de denegación sobre la entidad (o eliminar las acciones permitidas), ya que eso se evalúa en cada llamada a la API que haga el atacante. Aunque esta es la opción más simple, no siempre es la mejor, porque puede interrumpir tareas en ejecución (las credenciales robadas no siempre están vinculadas solo a usuarios). Otras opciones, según el soporte de su proveedor de cloud, incluyen:

• Agregar condicionales para restringir la IP de origen de las llamadas a la API.
• Denegar todas las sesiones creadas antes de una fecha u hora determinada.

Es más probable que se encuentre con este problema al federarse hacia un proveedor de cloud que dentro del propio proveedor. Acabo de hacer una prueba en AWS y perdí el acceso en las sesiones abiertas bastante rápido después de eliminar un usuario de IAM. Sin embargo, no ocurre necesariamente lo mismo al federarse desde un proveedor de identidad externo, e incluso dentro de AWS algunos servicios no vuelven a verificar las credenciales durante las sesiones activas (por ejemplo, mi sesión de Session Manager siguió activa durante más de 15 minutos después de eliminar el rol que permitía el acceso).

No se trata de una gran vulnerabilidad desconocida, sino de algo que hay que tener presente al desarrollar sus controles de seguridad en el cloud y sus manuales de respuesta a incidentes. Los distintos tipos de credenciales tienen distintos tiempos de vida, tanto entre proveedores de cloud como dentro de ellos. Su proveedor de identidad también será un factor, además del lugar donde intente revocar las credenciales. Por ejemplo, si tiene un usuario en Active Directory que luego federa hacia AWS, y ese usuario asume un rol en AWS y obtiene credenciales de sesión para ese rol, usted necesita revocar o restringir las credenciales del rol asumido incluso si restringe al usuario en AD. AWS no tendrá forma de saber que la sesión del usuario desde AD ya no es válida hasta el final de la sesión, cuando proceda a revalidar la autenticación.

Internamente cambiamos al uso de nuestra herramienta Authorization Control, que admite la creación de sesiones con restricciones mediante ChatOps sin agregar fricción que pueda ralentizar a nuestros desarrolladores. Aunque todavía no está disponible de forma general, si le interesa probarla durante el acceso anticipado, simplemente escríbame directamente a rich.mogull@firemon.com.