Kurzfassung

Die Sicherheit von KI-Workloads in der Cloud erfordert einen fundamentalen Paradigmenwechsel gegenüber traditioneller Cloud-Sicherheit. Tony de la Fuente, Gründer des Open-Source-Projekts Prowler, warnt vor einer wachsenden „Shared Responsibility Gap" bei verwalteten KI-Diensten wie AWS Bedrock oder Google Vertex AI. Das zentrale Problem: Während Cloud-Provider ihre Verantwortungsbereiche bei klassischen Diensten (etwa S3 oder EC2) klar definieren, bleibt unklar, welche Konfigurationsoptionen und Sicherheitsoptionen Kunden selbst verwalten müssen. Die Komplexität wächst exponentiell, wenn KI-Services als Zwischenschicht zu OpenAI, Claude oder anderen Modellen fungieren – es entstehen vierte und fünfte Verantwortungsebenen.

Personen

Themen

  • KI-Sicherheit vs. Cloud-Sicherheit
  • Shared Responsibility Model
  • Open-Source-Sicherheitstools
  • Infrastructure-as-Code Sicherheit
  • LLM-Konfiguration und Datenschutz

Clarus Lead

Die Verschiebung von Cloud- zu KI-Sicherheit ist nicht bloss eine technische Evolution, sondern eine architektonische Neuausrichtung. Während 90 % aller Software Open-Source enthält und KI-Modelle zunehmend in Produktionsumgebungen eingesetzt werden, entsteht ein kritisches Vakuum: Vendor-dokumentierte Sicherheitsempfehlungen für Dienste wie AWS Bedrock haben sich innerhalb von 18 Monaten verdoppelt, was belegt, dass Verantwortungen sukzessive vom Provider auf Kunden verschoben werden. Für Entscheider bedeutet dies, dass traditionelle Cloud-Governance-Modelle (Netzwerk, IAM, Logging) bei KI-Services unzureichend sind – es braucht zusätzliche Sicherheitsschichten auf Model-Ebene, bei Tool-Integration (wie MCPs) und im Datenzugriff.

Detaillierte Zusammenfassung

Das Kernproblem der Shared Responsibility Gap

Im klassischen Cloud-Zeitalter war die Verantwortungsteilung nachvollziehbar: AWS verwaltet physische Infrastruktur, Hypervisor, Netzwerk; Kunden konfigurieren Sicherheitsgruppen, IAM-Rollen, Verschlüsselung. Bei KI-Services verschwimmt diese Grenze dramatisch. Ein AWS-Bedrock-Deployment bietet hunderte Konfigurationsoptionen – von Model-Zugriffskontrolle über Logging bis zu Datenspeicherungsrichtlinien – deren Sicherheitsimplikationen vielen Teams unbekannt sind. Die Situation verschärft sich, wenn Bedrock selbst als Gateway zu ChatGPT, Claude oder proprietären Modellen fungiert. Plötzlich existieren mehrere Vertrauensgrenzen: AWS (Infrastructure), Bedrock-Konfiguration (Governance), Third-Party-LLM (Service-Sicherheit). Kunden wissen oft nicht, dass sie diese Komplexität selbst verwalten müssen.

Architektur statt nur Konfiguration

De la Fuente betont einen kritischen Unterschied: KI-Sicherheit ist weniger Konfigurationsproblem als vielmehr Architektur-Design-Problem. Ein häufiger Fehler ist es, Model Context Protocols (MCPs) – die Schnittstellen zwischen KI-Modellen und Datenquellen – direkt mit Datenbankzugriffen zu verbinden. Stattdessen sollte eine strikte Role-Based Access Control (RBAC) unterhalb der MCP-Schicht liegen. Das bedeutet: Die KI erhält keine direkten Berechtigungen auf Datenbanken; stattdessen stellt eine dedizierte API-Schicht mit RBAC sicher, dass das Modell nur auf die Daten zugreift, die es benötigt. Dies erfordert Designentscheidungen vor der Deployment-Phase, nicht danach.

Die Rolle von Open-Source und kontinuierlichem Scanning

Prowler, als Open-Source-Tool mit 300+ Contributors, hat seinen Fokus von reiner Cloud-Sicherheit (S3-Buckets, IAM-Policies) auf KI-Workloads ausgedehnt. Das Tool nutzt nun OWASP-AI-Mappings und Integration mit Frameworks wie „From" (ein LLM-Assessment-Tool), um sowohl Infrastruktur- als auch Model-Sicherheit zu überprüfen. Der Vorteil von Open-Source: Transparenz ermöglicht Vertrauen, schnellere Iteration, und – durch KI-Erweiterungen – automatische Detektionsgenerierung. Ein Beispiel: Google Cloud Code hätte grosse Schwierigkeiten, eine einfache Sicherheitsprüfung („Gibt es öffentlich zugängliche S3-Buckets?") durchzuführen; Prowler löst dies elegant, indem es regelbasierte Engine mit KI-generierten Detektionen kombiniert.

Shadow AI und Datenschutz-Compliance

Ein oft übersehenes Risiko ist „Shadow AI": Mitarbeiter laden Verträge mit Personendaten oder Geschäftsinformationen in ChatGPT, Claude oder DeepSeek hoch – ohne zu wissen, dass diese Services standardmässig Eingaben zum Model-Training verwenden. Nur explizite Opt-outs (z. B. ChatGPT Enterprise, API-Modus ohne Learning) verhindern dies. Dies ist kein technisches Problem, sondern eines von Governance und Awareness – es erfordert Policies, Tools zur Kontrolle, wer welche KI-Services nutzen darf, und Monitoring von KI-Zuragriff auf sensible Daten.

Kernaussagen

  • Shared Responsibility Gap verschärft sich: Verwaltete KI-Services verschieben mehr Sicherheitsverantwortung auf Kunden als klassische Cloud-Services; diese Verschiebung ist nicht transparent dokumentiert.
  • Architektur vor Konfiguration: Sicherheit von KI-Workloads ist ein Design-Problem (RBAC unterhalb von MCPs, API-Gating), nicht nur ein Konfigurationsproblem.
  • Open-Source ermöglicht schnellere Adaptation: Tools wie Prowler können mit KI-Integration (LLM-Assessments, automatische Detektionsgenerierung) schneller neue Sicherheitsfragen adressieren als proprietäre Lösungen.
  • Continuous Assessment ist notwendig: Neue KI-Modelle und Dienste entstehen monatlich; statische Sicherheitsprüfungen genügen nicht – kontinuierliches Scanning über Infrastruktur, Code und Runtime ist erforderlich.
  • Shadow AI ist ein Governance-Problem: Kontrollmechanismen für KI-Nutzung und Datenschutz-Compliance müssen Organisationsebene adressieren, nicht nur technische Layer.

Kritische Fragen

  1. [Evidenz/Datenqualität] Welche Quellen belegen die Verdopplung der Sicherheitsempfehlungen für Bedrock zwischen Lancierung und Anfang 2026? Sind AWS-interne Audit-Reports oder Kundenfeedback verfügbar, um diese Verschiebung nachzuvollziehen?

  2. [Datenqualität/Validität] Der Aussage „90 % aller Software ist Open-Source" – basiert diese Zahl auf einer spezifischen Studie (etwa Black Duck, GitHub)? In welchen Kontexten (Enterprise, Startups) ist diese Quote belastbar?

  3. [Interessenkonflikte] De la Fuente ist Gründer von Prowler, einem Sicherheits-Scanning-Tool. Könnte sein Fokus auf Konfigurationslücken und Architektur-Defizite unbewusst die Marktgrösse für sein Produkt überschätzen?

  4. [Kausalität/Alternativen] Ist die Shared Responsibility Gap tatsächlich dem Service-Design von Bedrock geschuldet, oder reflektiert sie schlicht die höhere Komplexität von generativen KI-Systemen – ein Problem, das auch ein vereinfachtes Shared-Responsibility-Modell nicht lösen könnte?

  5. [Gegenhypothese] Der Vorschlag, MCPs „unterhalb" von RBAC zu platzieren, reduziert KI-Flexibilität und könnte Latenz erhöhen. Sind Performanz-Trade-offs und Use-Cases, bei denen solche Architekturen nicht skalieren, dokumentiert?

  6. [Umsetzbarkeit] Wie können mittelständische Organisationen ohne dedizierte Security-Teams die vorgeschlagenen Architektur-Muster (RBAC-Layer, MCP-Isolation, kontinuierliches Scanning) praktizieren, wenn solche Designs erhebliches Cloud- und KI-Fachwissen erfordern?

  7. [Nebenwirkungen] Open-Source-Tools wie Prowler ermöglichen Transparenz, erhöhen aber auch die Attackfläche für Threat-Actor, die die Tool-Logik verstehen und umgehen können. Wie wird dieses Risiko adressiert?

  8. [Implementierungsrisiken] Shadow-AI-Kontrollen (Richtlinien, Monitoring, Opt-outs) erfordern Organisationskulturell akzeptiert zu werden. Welche Organisationen haben solche Programme erfolgreich durchgesetzt, und welche sind gescheitert?

Weitere Meldungen

  • DeepSeek-Incident: Ein ungenannter Sicherheitsvorfall mit DeepSeek wird erwähnt; Details bleiben unklar, könnten aber auf Datenschutz- oder Sicherheitsdefizite bei neuen KI-Modellen deuten.
  • Erweiterte Prowler-Integrationen: Neben AWS, Google Cloud und Azure werden nun auch Nischen-Cloud-Provider und SaaS-Lösungen (Microsoft 365, MongoDB Atlas) unterstützt.

Quellenverzeichnis

Primärquelle: Cloud Security Podcast Episode mit Tony de la Fuente – https://anchor.fm/s/10fb9928/podcast/play/115712786/

Ergänzende Quellen:

  • Prowler Open-Source-Repository (GitHub)
  • AWS Bedrock Dokumentation
  • OWASP AI Security Framework
  • From (LLM-Assessment-Tool) Dokumentation

Verifizierungsstatus: ✓ 2026-02-20

Dieser Text wurde mit Unterstützung eines KI-Modells erstellt. Redaktionelle Verantwortung: clarus.news | Faktenprüfung: 2026-02-20