Cuando compras a través de enlaces de afiliados en nuestra web, es posible que obtengamos una comisión sin coste adicional para ti. Aprende 
Una importante filtración de datos en Microsoft ilustra la importancia de implantar procesos de seguridad sólidos, ya que la empresa ha revelado que un empleado reveló accidentalmente un token de firma de acceso compartido (SAS) “excesivamente permisivo” mientras entrenaba un modelo de inteligencia artificial (IA). Cuando incluso las mayores multinacionales tecnológicas pueden exponerse a brechas de seguridad SAS, ?qué deben hacer los particulares para mantener sus datos seguros?
?Qué ocurrió en Microsoft?
En 2020, mientras contribuía a modelos de aprendizaje de IA de código abierto en un repositorio público de GitHub, un empleado de Microsoft compartió una URL utilizando la función de token SAS de la plataforma de computación en la nube Azure de Microsoft, que permite a los usuarios compartir datos de cuentas de Azure Storage. La URL incluía un token SAS para una cuenta de almacenamiento interna, que tenía privilegios excesivos que permitían el acceso a la información.
La cuenta contenía 38 TB de datos privados, incluida una copia de seguridad en disco de los perfiles de las estaciones de trabajo de dos antiguos empleados. La copia de seguridad incluía claves privadas, contrase?as de servicios de Microsoft y más de 30.000 mensajes internos de Microsoft Teams de 359 empleados.
La amenaza a la seguridad no se identificó hasta junio de 2023, cuando los analistas de la empresa de seguridad en la nube Wiz.io descubrieron la exposición accidental de los datos durante una búsqueda en Internet de contenedores de almacenamiento mal configurados. Wiz.io trabajó con Microsoft para revocar el token SAS, evitar el acceso externo a la cuenta e investigar cualquier impacto en los clientes o la continuidad del negocio. “No se expuso ningún dato de clientes ni se puso en peligro ningún otro servicio interno a causa de este problema”, declaró Microsoft.
Además de proporcionar acceso, el token estaba mal configurado para permitir “control total” en lugar de permisos de sólo lectura. Esto significaba que un atacante no sólo podía ver los archivos privados, sino que podía borrarlos o sobrescribirlos. Como el token compartía los datos con el repositorio de GitHub, un atacante podría haber inyectado código malicioso en todos los modelos de IA de la cuenta de almacenamiento, infectando a todos los usuarios.
El servicio de escaneo de GitHub supervisa todos los cambios de código abierto público para detectar la exposición de credenciales y datos privados. Esto incluye la detección de SAS que se?ala las URL de Azure Storage SAS que apuntan a contenido sensible. Aún así, Microsoft ha ampliado ahora esta detección para incluir cualquier token SAS que pudiera tener privilegios o tiempos de expiración demasiado permisivos.
?Qué es un token SAS?
Un token SAS es un token de seguridad o URL que está destinado a proporcionar acceso limitado y por tiempo determinado a recursos específicos en un servicio basado en la nube. Actúa como la URL compartida que podrías enviar a un amigo para acceder a un archivo en tu Microsoft OneDrive o Google Drive. Existen tres tipos de tokens SAS: Cuenta, Servicio y Delegación de usuario. En el repositorio de Microsoft se utilizó un token SAS de Cuenta.
Microsoft Azure suele utilizar tokens SAS, pero también en otras plataformas en la nube como Amazon Web Services (AWS) y Google Cloud Platform (GCP). Los tokens SAS se utilizan a menudo para conceder acceso temporal y controlado a datos o servicios sin exponer credenciales sensibles ni permitir un acceso sin restricciones.
Los tokens SAS pueden dar a los usuarios acceso a un único archivo, a un contenedor o a toda una cuenta de almacenamiento. Los permisos de los tokens para acceder a los datos pueden personalizarse, como lectura, escritura, borrado o lista, desde sólo lectura hasta control total, y pueden restringir el acceso a recursos específicos. Tienen un tiempo de caducidad totalmente personalizable, que limita cuándo pueden utilizarse para reducir el riesgo de exposición a largo plazo. También pueden revocarse antes de su fecha de caducidad, poniendo fin al acceso a los datos.
Los tokens SAS suelen adjuntarse a la URL del archivo, carpeta u otro recurso al que dan acceso, lo que elimina la necesidad de que el usuario disponga de las credenciales de la cuenta.
Para generar un token SAS, necesita los permisos adecuados para el recurso al que desea conceder acceso y un método o herramienta específicos del servicio -como Azure SDK, Azure Portal o herramientas de línea de comandos- para crear el token con los permisos y la duración adecuados.
Ventajas e inconvenientes de los tokens SAS
Los tokens SAS proporcionan un mecanismo seguro para dar a los usuarios acceso a datos específicos dentro de una cuenta de almacenamiento, a diferencia de una clave compartida, que tiene acceso completo a toda una cuenta. Los tokens SAS pueden restringir los recursos a los que puede acceder un usuario, las operaciones que puede realizar, la red desde la que puede acceder y el tiempo de acceso. Esto proporciona control al emisor del token y agilidad al usuario, pero también crea el riesgo de conceder demasiado acceso, como en el caso de Microsoft.
Los tokens SAS pueden configurarse para que duren “efectivamente para siempre”, se?ala Wiz.io. El primer token que Microsoft compartió con el repositorio AI GitHub se a?adió en julio de 2020, y siguió siendo válido hasta el 5 de octubre de 2021, pero el 6 de octubre de 2021, la caducidad se actualizó al 6 de octubre de 2051.
El problema es que no hay forma de que un administrador de cuentas Azure sepa cuándo un usuario crea un token altamente permisivo y sin caducidad o dónde está circulando. Y la revocación de un token también hace ineficaces todos los demás tokens firmados por la misma clave. Esto hace que los tokens SAS resulten atractivos para los atacantes que buscan aprovecharse de la exposición involuntaria de datos.
“Un informe reciente de Microsoft indica que los atacantes se están aprovechando de la falta de capacidades de supervisión del servicio para emitir tokens SAS privilegiados como puerta trasera”, afirman los analistas de Wiz.io.
Buenas prácticas para el uso de tokens SAS
Las grandes filtraciones de datos pueden costar a las personas sus recursos personales y su seguridad, y a las empresas millones de dólares en multas reglamentarias, medidas correctoras y la confianza de los clientes. Dado que el acceso no autorizado a los tokens SAS puede dar lugar a un acceso no autorizado a sus datos o servicios en la nube, es esencial gestionarlos con cuidado. He aquí algunas de las mejores prácticas a seguir:
- Asegure su red. Antes de adoptar Microsoft Azure, considere cómo asegurar el acceso a la red en la nube, por ejemplo con grupos de seguridad de red y Azure Firewall.
- Limite los permisos. Cuando genere URL de SAS, aplique el principio de mínimo privilegio y restrínjalas sólo a los recursos necesarios, como un único archivo o carpeta, con los permisos que el usuario necesita para hacer su trabajo, como acceso de sólo lectura o sólo escritura.
- Establece tiempos de caducidad cortos. Establezca siempre un tiempo de caducidad relativamente corto y pida a los usuarios que soliciten nuevos tokens SAS cuando los necesiten.
- Cree cuentas de almacenamiento dedicadas para uso compartido externo. Disponer de cuentas separadas para los recursos que se compartirán con usuarios externos limita el impacto potencial de un token con demasiados permisos o de un fallo de seguridad.
- Sea precavido. Trate los tokens como datos confidenciales y compártalos sólo con usuarios que requieran acceso a una cuenta de almacenamiento concreta.
- Evite utilizar cuentas SAS para compartirlas externamente. La falta de seguridad y gobernanza sobre los tokens SAS de cuenta significa que deben considerarse tan sensibles como una clave de cuenta y no compartirse externamente.
- Establezca una estrategia para revocar tokens. Establezca una política de acceso almacenado y esté preparado para revocar el acceso a los tokens si se ven comprometidos.
- Supervise y audite las solicitudes. Realice un seguimiento de la actividad y compruebe cómo se autentican las solicitudes a su cuenta de almacenamiento. Establezca una política de caducidad para identificar a los usuarios con URL SAS de larga duración.
- Forme a los usuarios o empleados. Eduque a los usuarios sobre la importancia de mantener seguras las URL de SAS para limitar quién tiene acceso a ellas.
Seguir las mejores prácticas para crear y manejar adecuadamente los tokens SAS puede ayudar a minimizar el riesgo de accesos involuntarios o abusos.
A raíz de la brecha, Microsoft dijo que mejorará sus herramientas de detección y escaneo para identificar de forma proactiva las direcciones URL SAS sobreaprovisionadas y mejorar su postura de seguridad por defecto.
Conclusión
La brecha de seguridad de Microsoft pone de manifiesto los riesgos de compartir datos en exceso y los ataques a la cadena de suministro. El token SAS sobreaprovisionado concedía pleno acceso de escritura a la cuenta de almacenamiento, por lo que un atacante malintencionado habría podido infectarla con código malicioso que podría atacar a otros investigadores que accedieran al repositorio de GitHub y podría haber creado más da?os si el código llegara a ser accesible al público.
Estas amenazas no harán sino aumentar a medida que más investigadores y empresas se dediquen a compartir grandes conjuntos de datos con modelos de IA. Es fundamental que los equipos de seguridad establezcan directrices claras para compartir datos externos, siguiendo las mejores prácticas para el uso de tokens SAS y otras formas de acceso a la nube, como limitar los permisos y silenciar los datos de IA compartidos.
“Este caso es un ejemplo de los nuevos riesgos a los que se enfrentan las organizaciones cuando empiezan a aprovechar el poder de la IA de forma más amplia”, afirmaron los analistas de Wiz.io. “A medida que los científicos de datos y los ingenieros corren para llevar nuevas soluciones de IA a la producción, las cantidades masivas de datos que manejan requieren controles de seguridad y salvaguardias adicionales.”
