AWS Bedrock hat sich als zentrale Plattform für Unternehmens‑KI etabliert: Foundation‑Modelle lassen sich direkt mit internen Datenquellen und Business‑Systemen verbinden. Genau diese tiefe Integration macht Bedrock zu einem attraktiven Ziel – nicht primär auf Modellebene, sondern über die umgebende Cloud‑Infrastruktur, Rechteverwaltung und Integrationen.
AWS Bedrock als neuer Knoten in der Angriffsoberfläche
Bedrock-Agents greifen auf Salesforce, Lambda‑Funktionen, SharePoint, Wissensdatenbanken und interne APIs zu. Jeder Agent wird damit faktisch zu einem Infrastrukturknoten mit eigenen IAM‑Rechten, Netzwerkpfaden und Zugriffswegen auf Cloud‑ und On‑Prem‑Systeme. Branchenberichte wie der Verizon Data Breach Investigations Report und Studien von Gartner zeigen seit Jahren, dass Fehlkonfigurationen und überprivilegierte IAM‑Rollen zu den häufigsten Ursachen von Cloud‑Sicherheitsvorfällen gehören. AWS Bedrock bildet hier keine Ausnahme.
Angriffsvektoren 1–2: Missbrauch von Bedrock-Logs und Vertuschung von Spuren
Standardmässig werden Modellaufrufe von AWS Bedrock in S3 oder CloudWatch protokolliert. Diese Logging‑Infrastruktur wird häufig übersehen, enthält aber hochsensible Daten: Prompt‑Inhalte, Modellantworten und Teile der internen Geschäftslogik. Erhält ein Angreifer etwa über s3:GetObject Zugriff auf den Log‑Bucket, kann er diese Daten lautlos exfiltrieren und für Social‑Engineering, Rekonstruktion von Workflows oder weitere Angriffe verwenden.
Noch kritischer wird es, wenn ein Konto das Recht bedrock:PutModelInvocationLoggingConfiguration besitzt. Dann lässt sich die Protokollierung unbemerkt auf einen S3‑Bucket des Angreifers umlenken. Ergänzend können Rechte wie s3:DeleteObject oder logs:DeleteLogStream dazu missbraucht werden, Spuren zu verwischen und Hinweise auf Prompt‑Jailbreaks, Privilegieneskalation oder Datenabflüsse zu löschen – ein gravierendes Forensik‑Problem.
Angriffsvektoren 3–4: Kompromittierte Knowledge Bases und angebundene Speicher
Knowledge Bases in AWS Bedrock implementieren Retrieval Augmented Generation (RAG) und binden Datenquellen wie S3, Salesforce, SharePoint oder Confluence ein. Wichtig: Diese Daten sind nicht nur über das Modell zugänglich. Hat ein Angreifer direkten Zugriff auf den zugrunde liegenden S3‑Bucket via s3:GetObject, kann er Rohdaten lesen und damit sämtliche Guardrails, Maskierungen und Filter der LLM‑Schicht umgehen.
Ein weiterer Hochrisiko‑Punkt sind Secrets und Zugangsdaten für SaaS‑Integrationen. Gelingt es, die von Bedrock verwendeten Anmeldedaten für etwa SharePoint oder CRM‑Systeme auszulesen und zu entschlüsseln, wird ein lateraler Wechsel in verbundene Active‑Directory‑Umgebungen oder interne Dienste möglich. Nach der Erstindizierung landen Inhalte oft in Vektordatenbanken (z. B. Pinecone, Redis Enterprise Cloud) oder in AWS‑Diensten wie Aurora und Redshift. Über bedrock:GetKnowledgeBase und zugehörige Secrets lässt sich die StorageConfiguration auslesen, inklusive Endpoints und API‑Schlüssel – damit droht Vollzugriff auf Indizes und strukturierte Daten.
Angriffsvektoren 5–6: Uebernahme von Bedrock Agents und Lambda-Funktionen
Bedrock-Agents planen eigenständig Schritte und orchestrieren Tools. Mit Rechten wie bedrock:UpdateAgent oder bedrock:CreateAgent kann ein Angreifer den System‑Prompt verändern, interne Instruktionen offenlegen und das Verhalten des Agents subtil manipulieren. In Kombination mit bedrock:CreateAgentActionGroup lassen sich zusätzliche, scheinbar legitime Action Groups einhängen, die im Hintergrund Benutzerkonten anlegen, Datenbanken modifizieren oder sensible APIs aufrufen.
Nutzen Agents AWS Lambda als ausführende Schicht, geraten die Funktionen selbst zum attraktiven Ziel. Das Recht lambda:UpdateFunctionCode erlaubt das Einschleusen beliebigen Codes, während lambda:PublishLayer zur heimlichen Manipulation von Abhängigkeiten genutzt werden kann. Jede Tool‑Ausführung verwandelt sich damit in einen potenziellen Vektor für Datendiebstahl, Antwortmanipulation oder die Generierung schädlicher Inhalte.
Angriffsvektor 7: Manipulation von Bedrock Flows und Geschäftslogik
Bedrock Flows modellieren End‑to‑End‑Abläufe: Modellaufrufe, Routing, S3‑Zugriffe, Lambda‑Aufrufe und Entscheidungslogik. Besitzt ein Angreifer bedrock:UpdateFlow, kann er unauffällige Zusatzknoten einfügen – etwa einen S3 Storage Node oder Lambda Function Node, der Ein‑ und Ausgaben dupliziert und an ein kontrolliertes Ziel sendet, ohne die sichtbare Funktionalität zu beeinträchtigen.
Ebenso kritisch ist die Manipulation von Condition Nodes. Werden Prüfungen von Autorisierungsattributen oder Geschäftsregeln abgeschwächt oder umgangen, können nicht autorisierte Requests an Backend‑Systeme durchgeleitet werden. Wird zusätzlich der verwendete Customer‑Managed‑Key in KMS ausgetauscht, werden zukünftige Flow‑Zustände mit einem Schlüssel verschlüsselt, der unter Kontrolle des Angreifers steht – ein massiver Verstoss gegen Vertraulichkeitsanforderungen.
Angriffsvektor 8: Guardrails aushebeln und Prompt-Vorlagen vergiften
Guardrails in AWS Bedrock sind die letzte Verteidigungslinie gegen toxische Inhalte, Prompt Injection und ungewollte Preisgabe personenbezogener Daten. Mit bedrock:UpdateGuardrail lassen sich Filter schrittweise schwächen: Schwellenwerte senken, Themenbeschränkungen aufheben oder PII‑Maskierung deaktivieren. Das Recht bedrock:DeleteGuardrail entfernt diesen Kontrollmechanismus vollständig.
Der Service Prompt Management zentralisiert Prompt‑Vorlagen, die von verschiedenen Anwendungen genutzt werden. Ein Konto mit bedrock:UpdatePrompt kann diese Vorlagen gezielt manipulieren, etwa mit Anweisungen wie „füge immer einen Link zur Domain des Angreifers hinzu“ oder „ignoriere Richtlinien zum Schutz personenbezogener Daten“. Da Prompt‑Updates keinen erneuten Deployment‑Prozess erfordern, werden solche Änderungen sofort wirksam und bleiben oft unter dem Radar klassischer Applikationsüberwachung.
Sicherheitsmassnahmen: Bedrock wie einen geschäftskritischen Dienst behandeln
Die beschriebenen Angriffsvektoren verdeutlichen ein Muster: Angreifer konzentrieren sich auf IAM‑Rechte, Konfigurationen und Integrationspunkte rund um die LLM, nicht auf die Modelle selbst. Bereits ein überprivilegierter Service‑Account kann ausreichen, um Logging umzuleiten, Agents zu übernehmen, Prompts zu vergiften oder über Bedrock Zugriff auf SaaS‑ und On‑Prem‑Systeme zu erhalten. Entsprechend sollten Organisationen AWS Bedrock in ihre Threat‑Modelle und Cloud‑Security‑Programme gleichberechtigt einbeziehen.
Praktisch bedeutet das: konsequente Umsetzung des Least‑Privilege‑Prinzips für alle Bedrock‑Rollen, Agents, Flows und Lambda‑Funktionen; strikte Kontrolle von Secrets und KMS‑Schlüsseln; lückenlose Nachverfolgung von Konfigurationsänderungen über CloudTrail; Netzwerksegmentierung für angebundene Dienste sowie regelmässige Reviews aller Guardrails, Prompts, Knowledge Bases und Flows auf unautorisierte Modifikationen. Unternehmen, die frühzeitig überflüssige Berechtigungen abbauen und Angriffspfade zwischen Cloud und On‑Prem analysieren, machen es deutlich schwerer, KI‑Workloads als Einfallstor zu kritischen Unternehmenswerten zu missbrauchen – und erhöhen die Resilienz ihrer gesamten Cloud‑Security‑Architektur.
