Die ganze Belegschaft hatte Zugriff auf den Tresor mit den Secrets. Eine einzige Gruppenregel genügte

Kontext

Es begann mit etwas, das wir in Berichten sonst loben. Der Kunde hatte einen der Azure-Key-Vault-Tresore auf das von Microsoft empfohlene Autorisierungsmodell Azure RBAC umgestellt. Genau so, wie es die gute Praxis verlangt.

Kurz darauf sahen wir auf eine Regel einer dynamischen Gruppe, die in diesem Tresor den Lesezugriff auf Secrets vergab. Die Regel lautete: jeder Nutzer vom Typ Member. In der Praxis hieß das, dass jeder neue Mitarbeiter automatisch Zugriff auf Secrets und Zertifikate bekam, am Tag der Kontoerstellung. Mehrere hundert Personen. Niemand hatte das bewusst vergeben. Die Gruppe tat einfach, was in ihrer Regel stand.

Das ist ein typischer Moment in Audits der Cloud-Konfiguration. Jemand macht eine Sache nach dem Handbuch und lässt trotzdem die Tür weit offen, weil zwei gute Ideen am falschen Ort aufeinandertreffen. Erst danach kamen wir zum Rest: warum der Kunde zu uns kam, wie die Umgebung aussah und warum gerade ein Konto mit Leserecht genügte, um all das zu sehen.

Die Umgebung war typisch für eine Organisation, die schneller gewachsen war als ihre Ordnung in der Cloud. Ein Entra-ID-Tenant, ein produktives Azure-Abonnement, mehrere hundert Konten, sieben Key Vaults, zwei Synapse-Analytics-Umgebungen, einige Azure-Storage-Konten mit Produktionsdaten. Das Audit führten wir nach dem CIS Microsoft Azure Foundations Benchmark v5.0.0 durch und verbanden automatische Tests mit einer manuellen Durchsicht der Konfiguration.

Herausforderung

Die Cloud verliert selten durch ein einziges spektakuläres Loch. Sie verliert durch einen Stapel Kleinigkeiten, von denen jede für sich überlebbar scheint.

Wir mussten auch der anderen Seite gerecht werden. Die Absicherung der Identitäten war nicht dumm. Ein Teil der Vaults lief auf Azure RBAC, der Zugriff war mitunter in Lese- und Administrationsgruppen getrennt, ein Backup existierte überhaupt. Das Problem war nicht, dass sich niemand bemüht hätte. Es war, dass einige einzelne Einstellungen, jede auf "später" gestellt, diesen Bemühungen den ganzen Wert nahmen.

Unsere Aufgabe lief auf die Frage hinaus, die sich jede CISO nach einem nächtlichen Anruf stellt: Wenn ein Angreifer ein einziges normales Konto übernähme, wie weit käme er, bevor es jemand bemerkte. Die Antwort, die wir fanden, war unbequem. Weit. Und man hätte es wohl nicht bemerkt, denn das Audit der Abfragen und die Bedrohungserkennung im Warehouse waren abgeschaltet.

Was wir getan haben

Wir bekamen ein einziges Konto mit drei Leserollen: Reader, Key Vault Reader, Log Analytics Reader. Keinerlei Recht, irgendetwas zu ändern. Von ihm aus enumerierten wir Identitäten in Entra ID, RBAC-Zuweisungen auf dem Abonnement und den Ressourcen, die Netzkonfiguration der Dienste sowie die Einstellungen der Key Vaults und Storage-Konten. Daraus bauten wir dann die Pfade, die ein Ungebetener nehmen würde.

Drei davon lohnt es, in voller Länge zu zeigen.

Der erste ist die dynamische Gruppe für die Secrets. Der Key Vault beruhte auf dem korrekten RBAC-Modell, aber die Gruppe mit Leserecht hatte eine Mitgliedschaftsregel, die alle normalen Mitarbeiter umfasste. Dazu öffentlicher Netzzugriff auf den Vault aus allen Netzen. Die Zugangsdaten einer beliebigen Person, von einem beliebigen Ort der Welt genutzt, öffneten den Inhalt des Tresors.

Der zweite ist das produktive Data Warehouse auf Synapse Analytics. Die Firewall-Regel ließ Verkehr aus dem gesamten öffentlichen Adressraum herein. Die drei Einstellungen, die die ersten beiden Pfade antrieben, liefen darauf hinaus:

# Reguła zapory workspace'u hurtowni (Synapse Analytics)
name       startIP        endIP
allowAll   0.0.0.0        255.255.255.255

# Reguła członkostwa grupy dynamicznej z odczytem sekretów (Entra ID)
user.userType -eq "Member"     # trafia tu każde konto pracownika, automatycznie

# Uwierzytelnianie środowiska Synapse
azureADOnlyAuthentication = False   # aktywne lokalne konto administratora SQL

Die Zugangsschnittstellen des Warehouse waren also von jeder Adresse der Welt erreichbar, und daneben lief ein lokales SQL-Administratorkonto. Eine solche Anmeldung umgeht Conditional Access, die MFA-Pflicht und den gesamten Identitätsapparat von Entra ID. Wer dieses Passwort kennt oder errät, gelangt ohne jede Netzbeschränkung an die Produktionsdaten. Und da das Audit der Abfragen abgeschaltet war, gelangt er leise hinein.

Der dritte Pfad sind tote Konten mit aktiven Rechten. Das deaktivierte Konto eines ehemaligen Mitarbeiters hielt noch die Rolle Owner auf dem Warehouse-Workspace und auf einem Storage-Konto. Dazu kamen die Gastkonten eines externen Subunternehmers mit Zugriff auf das produktive Warehouse, mit namentlichen Firewall-Regeln, die ihre privaten Adressen hereinließen, darunter ein seit Langem inaktives Konto, das trotzdem weiter in die Produktionsumgebung eingelassen war.

Das Ganze fassten wir mit einer Abbildung auf MITRE ATT&CK zusammen, denn das ist die klarste Sprache für das Blue Team auf der anderen Seite:

Ergebnis

Die Umgebung erfüllte 60 von 155 CIS-Kontrollen nicht, weitere 82 fielen mit einer Warnung aus. Zwei Dinge markierten wir als kritisch, zu beheben in sieben Tagen: die für das gesamte Internet offene Firewall des produktiven Warehouse und die dynamische Gruppe, die der ganzen Belegschaft Zugriff auf die Secrets gab. Das Gesamtrisiko des Projekts lag in der oberen Hälfte der Skala, aber der Kern ist hier ein anderer als die Zahl. Keiner dieser Befunde brauchte einen Zero-Day. Alle waren ein- oder ausgeschaltete Schalter, die jemand irgendwann in der Standardstellung gelassen hatte.

Das Risiko übersetzten wir in die Sprache, in der die Geschäftsleitung über Geld spricht. Ein Tresor mit Secrets, offen für alle, bedeutet: ein einziger übernommener Laptop trennt den Angreifer von den Schlüsseln zu Integrationen und Datenbanken. Ein Warehouse ohne Netzbeschränkungen und mit lokaler SQL-Anmeldung ist ein Weg zu den Produktionsdaten unter Umgehung der MFA. Ein Backup ohne Locked-Modus und ohne Mehr-Personen-Freigabe ist das Szenario, in dem Ransomware zuerst die Kopien löscht und erst dann verschlüsselt. 96 Prozent der Secrets ohne Ablaufdatum sind Zugangsdaten, die unbefristet gültig bleiben, auch die, die längst abgeflossen oder in Vergessenheit geraten sind.

Die Empfehlungen ließen wir in abhakbarer Form, mit Frist und Priorität bei jeder:

• Entfernen Sie die Regel, die das gesamte Internet in das Warehouse lässt, und beschränken Sie den Zugriff auf vertrauenswürdige Netze oder führen Sie einen Private Endpoint ein. Das sind die ersten sieben Tage.
• Engen Sie die dynamische Gruppe für die Secrets auf die Personen mit echtem Bedarf ein, statt einer Regel, die alle Mitarbeiter umfasst. Ebenfalls die ersten sieben Tage.
• Deaktivieren Sie die lokale SQL-Authentifizierung auf dem Warehouse und wechseln Sie ausschließlich auf die Identität von Entra ID, damit der Zugriff MFA und Conditional Access unterliegt.
• Entziehen Sie dem deaktivierten Konto alle Rollenzuweisungen und überprüfen Sie den Zugriff der Gastkonten des externen Subunternehmers, einschließlich der Entfernung der namentlichen Firewall-Regeln.
• Schalten Sie das Audit der Abfragen und die Bedrohungserkennung in beiden Warehouse-Umgebungen ein, mit Versand der Logs an Sentinel, und heben Sie in Defender mindestens den Schutz für Key Vault und Storage an.
• Weisen Sie den Secrets Ablaufdaten zu und ergänzen Sie eine Azure Policy, die das Anlegen von Secrets ohne Ablaufdatum blockiert.

Ein Retest nach der Umsetzung bestätigt, dass die Kontrollen in die richtige Stellung zurückgekehrt sind. Das ist die gute Nachricht in Konfigurationsaudits: Wenn das Problem in den Einstellungen lag, dann liegt auch die Behebung in den Einstellungen und nicht im Neuschreiben der halben Architektur.

Wie viele dieser Einstellungen in Ihrer Cloud stehen heute auf "später"? Wenn Sie nicht wissen, wer Zugriff auf Ihre Secrets hat oder von welcher Adresse aus man in Ihr Warehouse gelangt, können wir das mit Leserechten prüfen, genau wie hier.