Ein eigentlich privater Datenfundus unter anderem zum Trainieren von Künstlicher Intelligenz stand aufgrund einer Fehlkonfiguration für einen Link zum Teilen von Dateien offen im Netz. Insgesamt 38 Terabyte an Daten waren zugreifbar, bestehend aus Trainingsdaten für KI sowie Festplattenbackups von zwei Rechnern von Angestellten. Wie das IT-Sicherheitsunternehmen Wiz in einem Blog-Beitrag erläutert, waren darin private Schlüssel, Passwörter und mehr als 30.000 Teams-Nachrichten von 359 Microsoft-Mitarbeitern enthalten. Auf die Daten stießen die IT-Forscher in einem Github-Repository von Microsoft. Microsofts KI-Abteilung hat dort Open-Source-Code und KI-Modelle für die Bilderkennung angeboten. In der Anleitung des Repository haben die Entwickler einen Link angegeben, um das Repository herunterzuladen. Derartige Freigabe-Links heißen in Microsofts Cloud-Umgebung Azure Shared Access Signature (SAS)-Token. Der konkrete Freigabe-Link erlaubte viel weiteren Zugriff als lediglich auf die Open-Source-Modelle. Er war fälschlicherweise so konfiguriert, dass der vollständige Speicher-Account zugänglich war, inklusive der zusätzlichen privaten Daten. Zudem war der SAS-Token so konfiguriert, dass er die weitreichenden Zugriffsrechte „Volle Kontrolle“ besaß, anstatt nur lesenden Zugriff zu gewähren. Bei den Shared Access Signature-Token (SAS) in Azure handelt es sich um signierte URLs, die Zugriff auf in Azure gespeicherte Daten erlauben. Die Zugriffsrechte lassen sich von Nutzern anpassen. Die Rechte reichen von Nur-Lese- bis Vollzugriff von einzelnen Dateien über Container hin zu vollständigen Storage-Konten. Dabei lasse sich noch ein Gültigkeitszeitraum angeben, erläutert Wiz, der bis zu niemals ablaufenden Rechten reicht. Diese Konfigurierbarkeit liefert Nutzern weitreichende Möglichkeiten, stellt aber auch ein Risiko dar, falls zu großzügige Rechte eingestellt werden. Wie im vorliegenden Fall kann der Token vollen Zugriff erlauben, auf den vollständigen Account, für immer. Im Kern liefert das dieselben Zugriffsrechte wie der Konto-Schlüssel selbst. Diese SAS-Token lassen sich sehr einfach erstellen. Im Hintergrund lädt der Webbrowser den Schlüssel aus dem Azure-Konto herunter und signiert den erstellten Link respektive Token damit. Das findet vollständig Client-seitig statt, der Token ist damit kein Azure-Objekt. Dadurch bekommen Administratoren auch nicht mit, falls Nutzer zu weitreichende Rechte für einen Zugriffstoken ausstellen und wo dieser Token zirkuliert. Um einen SAS-Token zurückzuziehen, müssen Administratoren den Konto-Schlüssel austauschen, mit dem der Token signiert wurde. Es gibt keinen offiziellen Weg, solche Freigabe-Links zu überwachen. Allerdings können IT-Verantwortliche Storage-Analytics-Logs für jeden Storage-Account aktivieren. Das kostet extra, aber die Protokolle enthalten Details zu Zugriffen mit SAS-Token, einschließlich des zum Signieren genutzten Schlüssels und die erlaubten Zugriffsrechte. Das zeigt jedoch lediglich auch tatsächlich genutzte Token an. Ebenso ließen sich Azure Metrics nutzen, die die Nutzung von SAS-Token bis zu 93 Tagen vorhalten. SAS-Token sollten daher als genauso vertraulich wie Konto-Schlüssel betrachtet werden, rät Wiz. Sie sollten für das externe Teilen von Daten nicht verwendet werden. Dafür solle etwa ein Service-SAS zum Einsatz kommen, der mit einer Stored Access Policy verknüpft ist. Dadurch lassen sich die Richtlinien zentral verwalten und die Token gegebenenfalls zurückziehen. Zudem sollten IT-Verantwortliche Werkzeuge zur Suche nach Geheimnissen einsetzen, die Datenlecks anhand erkannter vertraulicher Daten melden können. Wiz ist auf Cloud-Sicherheit spezialisiert und hatte bereits in der Vergangenheit Datenlecks unter anderem bei Microsoft aufgespürt. Mitte 2021 etwa gelang der Vollzugriff auf Kundendatenbanken in Microsofts Azure-Cloud-Systemen.
