Kurz gesagt: API-Schlüssel sichern bedeutet, Zugangsschlüssel wie Cloudflare-, Azure- oder Entra-ID-Secrets niemals fest im Code zu hinterlegen, sondern zentral in einem Tresor wie Azure Key Vault zu verwalten, kurze Laufzeiten zu erzwingen und Zugriffe per Sign-in-Logs sowie Conditional Access zu überwachen. Der Brevo-Hack zeigt, wie schnell ein einziger gestohlener Schlüssel zur Malware-Schleuder für zehntausende Websites wird.
API-Schlüssel sichern klingt nach Pflichtübung – bis ein Kunde anruft, weil die Firmenwebsite plötzlich ein Skript von einer fremden Domain lädt und der Virenscanner sofort Alarm schlägt. Genau das passierte Mitte September 2026 Kunden von Brevo: Ein gestohlener Cloudflare-API-Schlüssel, hartkodiert im Quellcode, reichte aus, um zehntausende Websites mit Malware zu infizieren. Was auf den ersten Blick nach einem Problem für Marketing-Tools aussieht, hat in Entra ID und Azure eine fast deckungsgleiche Entsprechung.
Der Brevo-Vorfall im Kurzüberblick: Wie ein gestohlener Key zur Malware-Schleuder wurde
Laut BleepingComputer nutzten Angreifer einen langlebigen Cloudflare-API-Schlüssel mit vollen Kontorechten, der im Quellcode von Brevo hartkodiert war. Damit erstellten sie einen bösartigen Cloudflare Worker, der Inhalte direkt am CDN-Edge veränderte – ohne dass Integritätsprüfungen der Origin-Server anschlugen. Rund fünfeinhalb Stunden lang spielte der Worker manipulierte Skripte aus, die Besuchern gefälschte Cloudflare-Verifizierungsseiten mit ClickFix-Anleitungen zeigten. Auf WordPress-Seiten wurde zusätzlich ein Backdoor-Plugin nachgeladen, das Admin-Sessions ganz ohne Passwort erzeugen konnte.
Bis zu 100.000 Websites waren laut Sicherheitsforschern potenziell betroffen. Der Schlüssel war bereits Ende August kompromittiert, fiel aber erst Mitte September auf. Genau diese Kombination – lange Gültigkeit, volle Rechte, keine Rotation – zeigt, warum API-Schlüssel sichern auch für Admins in reinen Microsoft-Umgebungen kein Randthema mehr ist.
Warum API-Schlüssel sichern zum zentralen Sicherheitsthema wird
Secrets sind für Angreifer attraktiver als klassische Passwörter: Sie öffnen direkten API-Zugriff, lösen selten MFA-Prompts aus und werden seltener rotiert als Benutzerpasswörter. In Security-Communities häufen sich deshalb Berichte über gefundene Keys in GitHub-Repos, CI/CD-Pipelines und clientseitigem JavaScript. Wer API-Schlüssel sichern will, muss also nicht nur Passwörter, sondern die gesamte Maschine-zu-Maschine-Kommunikation im Blick behalten.
Supply-Chain-Risiko: Wenn eingebundene Drittanbieter-Skripte zur Hintertür werden
Der Brevo-Fall zeigt das Kernproblem von Supply-Chain-Angriffen: Ein einzelner kompromittierter Anbieter reicht aus, um tausende fremde Websites zu infizieren – unabhängig davon, wie gut die eigene Infrastruktur abgesichert ist. Tracking-Skripte, Formular-Widgets oder CDN-Ladescripte laufen mit denselben Rechten wie der Rest der Seite und werden selten separat überwacht. Deshalb reicht es nicht, nur die eigenen Systeme zu härten – API-Schlüssel sichern muss auch für eingebundene Drittanbieter gelten.
Was hat das mit Entra ID zu tun? Client Secrets, Zertifikate und Service Principals
In Azure und Entra ID heißt das Äquivalent zum Cloudflare-Key: Client Secret oder Zertifikat einer App-Registrierung. Jede App-Registrierung besitzt einen Service Principal, der sich per Secret oder Zertifikat authentifiziert – oft mit weitreichenden Graph- oder Azure-Resource-Manager-Rechten. Genau wie bei Brevo landen solche Secrets häufig hartkodiert in Config-Dateien, Pipelines oder geteilten Skripten. Wird ein solcher Schlüssel gestohlen, kann sich ein Angreifer als legitime Anwendung ausgeben – ganz ohne Benutzerkonto und ohne MFA-Hürde. Wie Angreifer ähnliche Wege nutzen, um MFA zu umgehen, zeigt der Artikel zu Session-Token-Diebstahl in Entra ID.
Warum lange gültige Secrets ein Risiko sind
Der größte Fehler bei Brevo war nicht der Diebstahl selbst, sondern dass der Schlüssel monatelang unverändert und mit vollen Rechten existierte. In Entra ID sieht man dasselbe Muster täglich: Client Secrets ohne Ablaufdatum, Zertifikate mit Laufzeiten von mehreren Jahren, App-Registrierungen mit Owner-Rechten auf ganze Subscriptions. Ohne Rotation bleibt ein einmal kompromittiertes Secret so lange gültig, bis jemand aktiv eingreift – oft Monate, manchmal nie.
Praxistipp: Öffne in Entra ID unter App-Registrierungen > Zertifikate & Geheimnisse die Übersicht aller Client Secrets und sortiere nach Ablaufdatum. Alles ohne Enddatum oder mit Laufzeit über 12 Monaten sollte auf die Rotationsliste – meist ist das in wenigen Minuten erledigt.
Managed Identities als bessere Alternative zu Client Secrets
Statt Secrets manuell zu verwalten, übernimmt bei Managed Identities Azure selbst die Schlüsselverwaltung. Eine System-Assigned Managed Identity ist fest an eine Ressource wie eine VM oder Function App gebunden und verschwindet mit ihr; eine User-Assigned Managed Identity lässt sich mehreren Ressourcen zuweisen. Anmeldedaten werden dabei nie im Code sichtbar, sondern automatisch rotiert. Für die Migration reicht es meist, in der Ressource eine Identity zu aktivieren, ihr die passende RBAC-Rolle zuzuwe