Cloud Intelligence™
Anomalieerkennung bei Cloud-Kosten: Lehren aus echten Vorfällen
Das DoiT-Team hat sechs Monate an Sicherheitsvorfällen in unserer Kundenbasis ausgewertet. Die Ursache war selten neuartig: Fast immer waren es Zugangsdaten, die jemand vergessen hatte abzusichern.
Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.
Gemeinsam verfasst von den DoiT Customer Success und Forward Deployed Engineering Teams
About Kendall Wondergem
Senior Director of Customer and Partner Success at DoiT, leading teams that deliver continuous value and exceptional customer experience through our products and services. Over 20 years of experience in management consulting, SaaS, startups, and the cloud.
My personal pageTL;DR: In den vergangenen sechs Monaten haben DoiT-Teams eine wachsende Zahl von Sicherheitsvorfällen in unserer Kundenbasis und über die großen Cloud-Anbieter hinweg bearbeitet. Die überwiegende Mehrheit lässt sich auf eine Ursache zurückführen: geleakte oder unbeschränkte Zugangsdaten – meist ein API-Key oder IAM Access Key –, die irgendwo lagen, wo sie nicht hätten liegen dürfen. Einige Vorfälle wurden sofort erkannt, dank DoiT Cloud Intelligence™ Real-Time Anomaly Detection und korrekt konfigurierten Benachrichtigungen an die richtigen Ansprechpartner zur richtigen Zeit. Wo das nicht der Fall war, sahen Kunden Kostenspitzen von bis zu mehreren Hunderttausend Dollar, bevor jemand etwas bemerkte. Dieser Beitrag zeigt, was wir gesehen haben, was es gekostet hat und welche Maßnahmen Sie und Ihr Team heute ergreifen sollten, um diese Angriffe zu verhindern und Vorfälle in Minuten statt Tagen zu erkennen.
Wenn Sie Workloads in der Public Cloud betreiben, kennen Sie diesen Albtraum – vom Hörensagen oder aus eigener Erfahrung: Ein Key landet in einem öffentlichen Repo, wird in eine Mobile App eingebaut oder liegt in einer CI-Pipeline, die seit einem Jahr niemand mehr auditiert hat. Tage später fragt jemand aus der Finanzabteilung, warum auf der Cloud-Rechnung eine Null zu viel steht. Das ist kein hypothetisches Szenario. Es ist mit weitem Abstand der häufigste Sicherheitsvorfall, auf den wir reagieren.
Wir haben die Incident-Daten ausgewertet, die unsere Forward Deployed Engineers in den letzten sechs Monaten protokolliert haben, um zu sehen, welche Muster sich über eine große, heterogene Kundenbasis hinweg bestätigen. Das ist kein Anbieterbericht, der vor theoretischen Angriffen warnt. Hier geht es um das, was tatsächlich in unserer Queue landet – und wir möchten Ihnen helfen, dieselbe Situation in Ihrem Unternehmen zu vermeiden.
Muster bei Cloud-Security-Vorfällen: GCP vs. AWS
Google-Cloud-Vorfälle ließen sich fast vollständig auf eine Sache zurückführen: die explosionsartig gestiegene Nutzung von Gemini API und Vertex AI im vergangenen Jahr – und darauf, wie leicht es ist, beim schnellen Entwickeln einen API-Key unbeschränkt zu lassen. Über die Behebung des Gemini-API-Key-Missbrauchs haben wir hier im Blog geschrieben. AWS-Vorfälle folgten eher einem klassischen Muster: geleakte IAM-Keys, die in Compute-Missbrauch mündeten, plus eine Handvoll regelrechter Account-Übernahmen. Auf beiden Plattformen war die Ursache fast nie eine Schwachstelle der Plattform. Es war fast immer etwas, das ein Mensch mit Zugangsdaten getan – oder eben nicht getan – hat.
GCP-Sicherheitsvorfälle: Geleakte API-Keys sind Ursache Nr. 1
| Ursache | Anteil |
|---|---|
| Geleakte oder unbeschränkte API-Keys (Gemini, Vertex, AI Studio) | 77 % |
| Geleakter Service-Account-Key, genutzt für Krypto-Mining oder unautorisierte Compute-Engine-Flotten | 19 % |
| Admin- oder Session-Hijacking mit Billing-Manipulation oder Aussperrung der Admins | 2 % |
| Datenexfiltration über einen kompromittierten Service Account | 2 % |
Fast alles entfällt auf die erste Zeile. 77 % der GCP-Vorfälle der letzten sechs Monate gingen auf einen API-Key zurück – meist ein Firebase-Browser-Key oder ein Maps-/Gemini-Key im clientseitigen Code –, der keine HTTP-Referrer-Beschränkung, keine IP-Beschränkung und kein API-Scoping hatte. Angreifer scannen öffentliche Repos und exponierte Frontend-Bundles gezielt nach genau diesem Muster. Sobald sie einen funktionierenden Key finden, richten sie automatisierte Skripte auf die Generative Language API und lassen sie laufen. Diese Vorfälle reichten von einigen Hundert Dollar bis zu über 200.000 US-Dollar an unautorisierten Gemini-Kosten – entstanden innerhalb weniger Stunden.
Das zweite Cluster – geleakte Service-Account-Keys – verläuft anders, beginnt aber genauso: ein langlebiger Key in einem GitHub-Repo, einer CI/CD-Konfiguration oder auf dem Laptop eines Entwicklers. Sobald ein Angreifer ihn hat, treibt er nicht die API-Rechnung in die Höhe, sondern startet Compute-Ressourcen. In einem Fall, den wir bearbeitet haben, ermöglichte ein geleakter GitLab-CI-Service-Account-Key einem Angreifer, über Nacht mehr als 10.500 Krypto-Mining-VMs in einem einzigen GCP-Projekt zu starten. Und Erstattungsanträge beim Cloud-Anbieter werden nicht immer bewilligt. Genau darüber lohnt es sich nachzudenken: Cloud-Anbieter werden bei Gutschriften für "Runaway Spend" strenger, besonders bei wiederholten oder vermeidbaren Vorfällen. Eindämmung und Prävention sind wichtiger denn je, denn das Sicherheitsnetz eines Billing-Disputs ist nicht garantiert.
AWS-Sicherheitsvorfälle: Geleakte IAM-Keys und Account-Übernahmen
| Ursache | Anteil |
|---|---|
| Geleakter oder unbeschränkter IAM Access Key (Entwicklerrechner, CI/CD, Code) mit unautorisierter Nutzung von EC2, ECS, Fargate oder Bedrock | 56 % |
| Übernahme des Root-Accounts oder einer Admin-Session mit Billing-Manipulation oder Aussperrung der Admins | 15 % |
| Kompromittierter Workload oder Anwendung (exponierter Service, fehlkonfigurierte Trust Policy) mit Lateral Movement oder Exfiltration von Secrets | 15 % |
| Plattform-Missbrauch über kompromittierte Kundenkonten, Phishing oder Spam via Amazon SES | 7 % |
| DDoS- oder Netzwerkangriff ohne kompromittierte Zugangsdaten | 7 % |
Bei AWS zeigt sich ein ähnliches Bild wie bei GCP: Geleakte Zugangsdaten machen mehr als die Hälfte aller Fälle aus. IAM Access Keys, die von Entwicklerrechnern oder CI-Pipelines geleakt wurden, werden zu unautorisierten EC2- oder Fargate-Flotten voller Krypto-Miner – oder zunehmend zu unautorisierten Bedrock-API-Aufrufen, die Kosten für Modell-Inferenz auflaufen lassen.
Die Fälle von Root-Account-Übernahmen sollten Security-Verantwortliche am meisten beunruhigen, denn sie sind am schwersten rückgängig zu machen. Bei einem Vorfall setzte ein Angreifer das Passwort des AWS-Root-Accounts eines Kunden zurück, registrierte ein eigenes MFA-Gerät und sperrte die echten Administratoren vollständig aus. Anschließend führte er groß angelegte Bedrock-API-Aufrufe aus, die mehr als 500.000 US-Dollar an Kosten verursachten, bevor der Account wiederhergestellt war. Die Wiederherstellung erforderte die direkte Zusammenarbeit mit AWS, um die Eigentümerschaft neu zu verifizieren und den Zugriff von Grund auf neu aufzubauen. Keine Anomalieerkennung alarmiert schnell genug, wenn die Personen, die normalerweise reagieren würden, nicht in den Account kommen.
Wir sahen außerdem ein kleineres, aber reales Cluster von Kompromittierungen auf Workload-Ebene: ein aus dem Internet erreichbarer Load Balancer, der einen Pod exponiert, eine fehlkonfigurierte OIDC-Trust-Policy und ein Angreifer, der sich lateral bewegt und Tausende Secrets aus dem Secrets Manager exfiltriert. Hier geht es weniger um einen einzelnen geleakten Key als um die angesammelten Altlasten einer zu permissiven Netzwerk- und IAM-Konfiguration.
Identitätskompromittierung: Phishing, OAuth-Missbrauch und Account-Übernahme
Die übrigen Vorfälle folgten einem anderen, aber verwandten Muster: Phishing-Kampagnen, die Zugangsdaten abgriffen, mit denen anschließend Accounts gekapert und über eine kompromittierte Absenderidentität Spam versendet wurde – oder mit denen Angreifer via OAuth auf verbundene Drittanbieter-Tools zugriffen. Das kompromittierte Workspace-Konto eines Kunden wurde genutzt, um unautorisierte Manager-Verknüpfungen zu dessen Google-Ads-Konto hinzuzufügen und fast 50.000 US-Dollar an betrügerischen Werbeausgaben zu verursachen. Bei einem anderen Kunden wurde der Login eines Mitarbeiters genutzt, um Drittanbieter-Tools OAuth-Zugriff zu gewähren – mit unautorisierten Käufen als Folge.
Der rote Faden über alle Plattformen hinweg: Nicht die Infrastruktur des Cloud-Anbieters war die Schwachstelle. Sondern die Identität.
Die Rechnung ist der Rauch, nicht das Feuer
Es ist verlockend, eine Kostenspitze als das eigentliche Problem zu betrachten. Doch die Kostenspitze ist oft nur das erste sichtbare Symptom kompromittierter Zugangsdaten. Wer die Rechnung korrigiert, behandelt das Symptom. Wer die Hygiene seiner Zugangsdaten in Ordnung bringt und Anomalieerkennung ernst nimmt, packt die Ursache an.
Deshalb besteht unsere Empfehlung aus zwei Hälften, die zusammenspielen müssen: einem Posture Review, das die Lücken schließt, bevor sie ausgenutzt werden, und einem Monitoring, das die Ausnutzung schnell erkennt, falls doch eine Lücke durchrutscht.
Cloud-Security-Vorfälle verhindern: So schließen Sie die Lücke
Die zweiteilige Empfehlung von DoiT umfasst Folgendes:
Schritt 1: Überprüfen Sie Ihre Cloud Security Posture
Die meisten der oben beschriebenen Vorfälle wären mit Praktiken vermeidbar gewesen, die zu jedem Standard-Review der Cloud Security Posture gehören: API-Keys auf bestimmte Referrer oder IP-Bereiche beschränken, langlebige Service-Account-Keys rotieren und ausmustern, wo immer möglich von statischen Zugangsdaten auf Workload Identity Federation oder kurzlebige Tokens umstellen, MFA und Limits für die Sitzungsdauer beim Identity Provider durchsetzen und streng kontrollieren, wer IAM-Bindings auf Owner-Ebene erstellen oder nutzen darf. Nichts davon ist exotisch. Es ist die unspektakuläre, wenig glamouröse Arbeit der Zugriffshygiene – und genau diese Arbeit fehlt Vorfall für Vorfall.
Schritt 2: Richten Sie Anomalieerkennung für Cloud-Kosten und Benachrichtigungen ein
DoiT Cloud Intelligence™ Real-Time Anomaly Detection (verfügbar in unseren Enhanced- und Enterprise-Tarifen) ist genau für die Lücke gebaut, die sich durch fast jeden Vorfall in diesem Datensatz zieht: die Verzögerung zwischen dem Moment, in dem etwas schiefgeht, und dem Moment, in dem es jemand bemerkt. Die meisten abrechnungsbasierten Tools erkennen eine Kostenspitze Stunden oder Tage später, weil sie Exporte lesen, die verzögert aktualisiert werden. Real-Time Anomaly Detection liest Laufzeit-Nutzungsdaten direkt, kombiniert sie mit historischen Ausgabemustern und kann ungewöhnliche Aktivitäten innerhalb von Minuten statt Tagen melden. Jeder Alarm enthält eine Schweregrad-Bewertung und eine KI-generierte Aufschlüsselung des betroffenen Service, der SKU und der Ressource, sodass Ihr Team die Untersuchung nicht bei null beginnt.
Kunden in unserem Essentials-Tarif können und sollten unsere standardmäßig verfügbare Cloud-Anomalieerkennung konfigurieren – inklusive passender Benachrichtigungen, um Anomalien zu identifizieren und zu melden. Für ein Upgrade auf Real-Time Anomaly Detection wenden Sie sich an Ihren DoiT Account Manager oder erstellen Sie ein Ticket über Expert Inquiry in der DoiT-Konsole.
So holen Sie das Maximum aus Ihrer Anomalieerkennung heraus:
- Stellen Sie sicher, dass Anomalie-Benachrichtigungen für die richtigen Personen über die richtigen Kanäle zur richtigen Zeit konfiguriert sind. Benachrichtigungen zu Kostenanomalien erfordern die Cloud-Analytics-Berechtigung und gehen standardmäßig an Admins, Power Users, Finance Users und Standard Users. Prüfen Sie, wer in Ihrem Team das tatsächlich konfiguriert hat – und ob allen klar ist, wie wichtig eine schnelle Reaktion auf Benachrichtigungen ist.
- Bleiben Sie nicht beim Standard-Schwellenwert für den Schweregrad stehen. Wenn Ihre Organisation Workloads mit hoher Dynamik betreibt (CI/CD, GenAI-Inferenz, autoskalierende Flotten), stimmen Sie Ihren Review-Rhythmus so ab, dass eine Anomalie mittleren Schweregrads um 2 Uhr nachts noch vor dem Morgen geprüft wird.
- Ziehen Sie Ihren DoiT Customer Success Manager hinzu, um Ihre Erkennung und Benachrichtigungen konfigurieren (oder validieren) zu lassen. Die CSMs von DoiT helfen gerne und liefern den Expertenblick, der sicherstellt, dass alles korrekt eingerichtet ist.
- Richten Sie Benachrichtigungen für Kostenspitzen und die Nutzung neuer SKUs ein. Die Anomalieerkennung und Benachrichtigung für neue SKUs wird zu wenig genutzt, ist aber entscheidend: Sie meldet den Moment, in dem Ihre Organisation einen Service oder eine SKU nutzt, die sie noch nie zuvor genutzt hat – genau das passiert, wenn ein Angreifer mit einem gestohlenen Key zum ersten Mal die Generative Language API anspricht oder Bedrock-Inferenz startet. Eine legitime neue SKU taucht gelegentlich auf, wenn Ihr Team etwas Neues ausliefert. Eine unerklärliche zu einem unerwarteten Zeitpunkt sollten Sie sofort prüfen.
- Erwägen Sie Benachrichtigungen bei ausgeschöpften Quotas oder Credit-Verbrauch. Diese Funktion ist zwar für ein anderes Fehlerszenario gedacht, rundet aber das Bild unerwarteter Muster in Ihren Ausgaben ab.
- Prüfen Sie den Einsatz von Automatisierungen. Konfigurieren Sie DoiT Cloud Intelligence™ CloudFlow so, dass es bei Kostenanomalie-Triggern ausgeführt wird. So automatisieren Sie Aufgaben zur Incident-Eindämmung – etwa Slack-Nachrichten posten, Tickets erstellen oder Remediation-Schritte ausführen. Sie wissen nicht, wo Sie anfangen sollen? Ihr DoiT Customer Success Manager koordiniert eine Working Session mit einem DoiT Forward Deployed Engineer, um Ihre CloudFlows aufzusetzen.
Weitere Informationen zur Konfiguration von Anomalieerkennung und Benachrichtigungen finden Sie in der DoiT-Hilfedokumentation zu Anomalieerkennung und Benachrichtigungen – oder wenden Sie sich an Ihren DoiT Customer Success Manager.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Expertenhilfe bei der Anomalieerkennung für Cloud-Kosten
Kunden in unseren Enhanced- und Enterprise-Tarifen wenden sich an ihren DoiT Customer Success Manager oder Account Manager, um ein Security Posture Review zu vereinbaren und/oder eine robuste Strategie für Anomalieerkennung und -reaktion zu konfigurieren. Sie wissen nicht, wer Ihr CSM/AM ist? Melden Sie sich bei DoiT Cloud Intelligence™ an, klicken Sie auf das Zahnrad-Symbol oben rechts und wählen Sie "Account Managers".
Kunden in unserem Essentials-Tarif erstellen ein Ticket über die Konsole (öffnen Sie das Menü und wählen Sie "Get expert advice"). Ein Customer Success Manager hilft Ihnen dann, Ihre Anomalie- und Benachrichtigungskonfiguration einzurichten oder zu überprüfen, und teilt weitere Details zu einem eigenständig oder von DoiT durchgeführten Security Posture Review.
Checkliste für die Reaktion auf Cloud-Security-Vorfälle
Wenn in Ihrer Umgebung etwas passiert, empfehlen wir – basierend auf unserer Erfahrung mit schnell eingedämmten Vorfällen – folgende Reihenfolge:
- Deaktivieren Sie zuerst die Zugangsdaten. Löschen oder rotieren Sie den kompromittierten API-Key oder IAM Access Key sofort. Warten Sie damit nicht, bis Sie das volle Ausmaß des Schadens verstanden haben. Jede Stunde, die der Key aktiv bleibt, bedeutet mehr Kosten und mehr Risiko.
- Begrenzen Sie den Schaden auf Ressourcenebene. Beenden Sie die vom Angreifer gestarteten VMs, Instanzen oder Compute-Flotten. Steigen die Kosten schneller, als Sie Ressourcen sicher löschen können, ist das Trennen des Billing-Accounts vom betroffenen Projekt eine legitime Notbremse.
- Sichern Sie Logs, bevor Sie alles aufräumen. Audit-Logs und VPC Flow Logs brauchen sowohl Ihr Cloud-Anbieter als auch Ihr eigenes Team im Nachgang – für die Ursachenanalyse und für jeden Billing-Dispute. Wer jede Zugangskennung rotiert und jede Ressource entfernt, bevor jemand Logs gesichert hat, erschwert die Untersuchung erheblich.
- Eröffnen Sie einen Case bei Ihrem Cloud-Anbieter. Für unautorisierte Ausgaben haben die meisten Anbieter einen Prozess, um Kosten aus einer bestätigten Kompromittierung anzufechten. Bleiben Sie realistisch: Anbieter sind bei diesen Gutschriften strenger geworden, besonders bei wiederkehrenden oder vermeidbaren Vorfällen. Betrachten Sie einen Gutschriftsantrag also nicht als sicher.
- Ziehen Sie DoiT hinzu. Erstellen Sie ein Ticket über die Konsole (öffnen Sie das Menü und wählen Sie "Get expert advice") oder schreiben Sie Ihrem Customer Success Manager. Je früher wir eingebunden sind, desto besser können wir bei der Eindämmung, der Eskalation beim Anbieter und der Absicherung helfen, damit sich dieselbe Lücke nicht wieder öffnet.
- Schließen Sie die Lücke, sobald der Vorfall eingedämmt ist. Ein Vorfall ist ein Weckruf. Nutzen Sie ihn, um das Posture Review anzusetzen, das Sie sich schon lange vorgenommen haben.
FAQ
Was ist Anomalieerkennung bei Cloud-Kosten?
Anomalieerkennung bei Cloud-Kosten ist ein Monitoring, das ungewöhnliche Ausgaben- oder Nutzungsmuster – eine neue SKU, eine unerwartete Kostenspitze, ein unbekannter Service – sofort meldet, statt darauf zu warten, dass sie auf der Monatsrechnung sichtbar werden. DoiT Cloud Intelligence™ Real-Time Anomaly Detection liest Laufzeit-Nutzungsdaten direkt und kann Aktivitäten daher innerhalb von Minuten melden – statt der Stunden oder Tage, die Tools auf Basis von Billing-Exporten benötigen.
Was passiert, wenn ein API-Key geleakt wird?
Sobald ein API-Key ohne HTTP-Referrer-, IP- oder Scope-Beschränkungen exponiert ist – in einem öffentlichen Repo, einer Mobile App oder einer CI-Konfiguration –, finden Angreifer ihn durch automatisiertes Scanning meist innerhalb weniger Stunden und richten sofort Skripte auf kostenpflichtige APIs wie die Generative Language API oder Bedrock. In den von uns erfassten Vorfällen reichte das von einigen Hundert Dollar bis zu über 200.000 US-Dollar an unautorisierten Kosten – entstanden innerhalb weniger Stunden.
Wie kommt es zu einer Cloud-Account-Übernahme?
Die meisten Account-Übernahmen, die wir sehen, beginnen mit per Phishing erbeuteten oder wiederverwendeten Zugangsdaten, nicht mit einer Plattform-Schwachstelle. Ein Angreifer setzt ein Passwort zurück, registriert ein eigenes MFA-Gerät und sperrt den legitimen Admin aus – und nutzt diesen Zugriff dann, um Compute- oder Modell-Inferenz-Kosten auflaufen zu lassen oder das Billing zu manipulieren. Diese Art von Vorfall ist am schwersten rückgängig zu machen, weil die Personen, die normalerweise reagieren würden, nicht in den Account kommen.
Erstatten AWS oder Google Cloud unautorisierte Kosten durch geleakte Zugangsdaten?
Nicht automatisch und nicht immer. Beide Anbieter haben einen Prozess, um Kosten aus einer bestätigten Kompromittierung anzufechten, sind bei der Bewilligung von Gutschriften aber strenger geworden – besonders bei wiederkehrenden oder vermeidbaren Vorfällen. Betrachten Sie eine Erstattung als möglich, nicht als garantiert. Prävention und schnelle Eindämmung zählen mehr als das Sicherheitsnetz eines Billing-Disputs.
Was ist der erste Schritt bei Verdacht auf geleakte Zugangsdaten?
Rotieren oder löschen Sie den kompromittierten Key sofort, noch bevor Sie das volle Ausmaß des Schadens kennen – jede Stunde, die er aktiv bleibt, bedeutet mehr Risiko. Begrenzen Sie dann den Schaden auf Ressourcenebene (beenden Sie unautorisierte Compute-Ressourcen oder trennen Sie das Billing als Notbremse) und sichern Sie die Audit-Logs, bevor Sie aufräumen – Sie brauchen sie für die Ursachenanalyse und jeden Billing-Dispute.
Wie schnell erkennt Anomalieerkennung einen kompromittierten Key?
Mit Echtzeit-Erkennung, die auf die Nutzung neuer SKUs und nach Schweregrad bewertete Kostenspitzen alarmiert, können Teams einen kompromittierten Key innerhalb von Minuten nach der ersten Nutzung erkennen. Standard-Anomalieerkennung auf Basis von Billing-Exporten hat typischerweise eine Verzögerung von Stunden bis Tagen – genau das Zeitfenster, das in unseren Daten kleinere Vorfälle zu sechsstelligen werden ließ.
