Unterschätztes Risiko: Shared Responsibility

Warum Verfügbarkeit nicht Sicherheit ist und was das in der Praxis für Organisationen bedeutet

Das Modell der geteilten Verantwortung (Shared Responsibility Model) ist das Rückgrat der Informations- und Infrastruktursicherheit moderner IT-Landschaften. Es definiert präzise, welche Aufgaben beim Anbieter liegen und welche der Kunde übernehmen muss.

Die aktuelle Diskussion um Anthropic und dessen spezifisches, vierstufiges Modell für KI-Agenten hat das Thema wieder in den Fokus gerückt. Doch was bedeutet Shared Responsibility in der Praxis und welche Auswirkungen hat das auf die IT-Sicherheitsstrategie von Organisationen?

Was ist Shared Responsibility?

Das Shared Responsibility Model ist ein Framework, in dem die Zuständigkeiten zwischen einem Service-Provider (z. B. Microsoft, AWS, OpenAI) und dem Nutzer festgelegt sind. Damit sollen Sicherheitslücken vermieden werden, die entstehen könnten, wenn beide Seiten davon ausgehen, dass die jeweils andere Seite für einen bestimmten Schutzaspekt (z. B. Backups oder Patching) zuständig ist.

Ein einfacher Merksatz lautet: Der Anbieter ist verantwortlich für die Sicherheit der Infrastruktur, während der Kunde für die Sicherheit seiner Daten inkl. Konfigurationen, Schnittstellen und Identitäten verantwortlich ist.

Was haben alle Modelle gemeinsam?

Trotz unterschiedlicher Dienste – Cloud, SaaS, KI, Cybersicherheit – gibt es Konstanten, die in nahezu jedem Modell in der Verantwortung des Kunden verbleiben:

• Datenhoheit: Der Kunde ist immer für die Klassifizierung, den Schutz und die rechtmäßige Verarbeitung seiner Daten verantwortlich.
• Identitäts- und Zugriffsmanagement (IAM): Der Kunde ist immer für die Verwaltung von Benutzern, Rollen und Berechtigungen sowie Authentifizierung verantwortlich.
• Endgerätesicherheit: Der Schutz der Geräte, mit denen auf die Dienste zugegriffen wird (Laptops, Smartphones), liegt in der Verantwortung des Nutzers – und damit beim Kunden.
• Konfiguration und Regelwerke: Der Provider stellt das Mischpult zur Verfügung, der Kunde muss jedoch die Regler richtig einstellen.

Unterschiede nach Dienst und Anbieter

Die Aufteilung verschiebt sich je nach Abstraktionsgrad des Dienstes.

Bei Clouddiensten hängt es vom Service-Typ ab:

• IaaS: Der Provider kümmert sich um die Stabilität, Sicherheit und Verfügbarkeit von Netzwerk, Hosts, Host-OS und der Virtualisierungsumgebung. Der Kunde muss Client-Betriebssysteme patchen und die Firewall (Security Groups) konfigurieren.
• PaaS: Der Anbieter ist auch für Dinge wie Client-Betriebssystem, Laufzeitumgebung (z. B. Java, .NET, Python), Middleware und Datenbank-Engine verantwortlich – inkl. Patch-Management.
• Storage: Der Provider garantiert die physische Integrität und die Verfügbarkeit des Speichers. Der Kunde ist verantwortlich für die Integrität und Sicherheit seiner Daten inkl. Verschlüsselung und Key-Management sowie Zugangs- und Zugriffsberechtigungen.

Bei SaaS-Angeboten übernimmt der Anbieter fast alles bis zur Anwendungsebene. Das umfasst u. a. die Verfügbarkeit der App, Software-Updates und die physische Sicherheit. Backup sowie Informations- und Datenschutz sind immer Kundensache.

Beispiel: Microsoft sichert Ihre E-Mails und Daten gegen Serverausfälle, aber nicht gegen versehentliches Löschen durch Nutzer, Phishing-Angriffe oder die Verschlüsselung durch Ransomware.

Dass immer noch viele Organisationen Verfügbarkeit mit Integrität verwechseln, belegt eine aktuelle Umfrage von Hornetsecurity. Daniel Hofmann, CEO von Hornetsecurity by Proofpoint bestätigt: „Die Umfrageergebnisse zeigen, dass sich noch immer zu viele Organisationen in Deutschland bei Microsoft 365 alleine auf die integrierten Sicherheitsfunktionen verlassen. Dabei ist ihnen nicht bewusst, dass Microsoft ein Shared-Responsibility-Modell verfolgt, das in erster Linie die Plattform selbst absichert, während die Unternehmen die Verantwortung für den Schutz ihrer E-Mail-Postfächer, Datenbestände und Benutzerkonten tragen. Dies gilt ebenso für Kollaborationsanwendungen wie Teams, die zunehmend für die geschäftliche Kommunikation und den Dokumentenaustausch genutzt werden.“

Hofman empfiehlt, alle potenziellen Risiken “durch die konsequente Optimierung von Sicherheitseinstellungen, den Einsatz zusätzlicher Schutz- und Monitoring-Mechanismen der nächsten Generation sowie ein effektives Management von Identitäten, Daten und Zugriffsrechten innerhalb der Organisation adressiert werden. Dies unterstreicht, wie wichtig es ist, dass Unternehmen ihre M365-Plattform umfassend und mehrschichtig über alle relevanten Aspekte hinweg” abzusichern.

Bei Cybersicherheitsplattformen wie der von Palo Alto Networks ist die Verantwortung besonders eng verzahnt. Der Hersteller garantiert, dass die Plattform läuft, die Signaturen/Bedrohungsdaten aktuell sind und die Sensoren funktionieren. Der Kunde ist für die Policy-Definition verantwortlich. Wenn die Firewall auf "Allow All" steht, ist das ein Fehler des Kunden, nicht der Plattform. Auch die Reaktion auf Alarme (Incident Response) liegt beim Kunden.

Im Fall von KI ist das Modell ist relativ neu und spezifisch. Die Verantwortung für die "Model Safety" (Vermeidung von schädlichem Output), die Sicherheit der Trainingsdaten und die Absicherung der API-Infrastruktur liegt in den meisten Fällen beim Provider. Der Kunde übernimmt Verantwortung für die Prompts (z. B. Eingaben dürfen keine sensiblen Daten enthalten) und die Validierung der Outputs sowie den Schutz der API-Keys.

Agentic AI

Während das klassische Shared Responsibility Model primär zwischen Infrastruktur und Daten unterscheidet, geht Anthropic bei KI-Agenten einen Schritt weiter. Der Hersteller argumentiert, dass KI-Agenten, die eigenständig Tools nutzen und Aktionen ausführen, eine neue Art der Aufgabenteilung erfordern, und unterteilt die Verantwortung wird in vier Ebenen – einen Großteil der Verantwortung sieht der Anbieter beim Kunden:

• Layer 1: Das Modell – Der Provider verantwortet die Verfügbarkeit und Funktion inkl. Training des Modells, grundlegende Sicherheitsfilter (Constitutional AI) und die Resistenz z. B. gegen Jailbreaks und Prompt Injection. Die Forschung zeigt allerdings, dass kein Modell zu 100% gegen Prompt Injection immun ist.
• Layer 2: Der Harness – Dinge wie System-Prompts, Leitplanken und Genehmigungs-Workflows, die um die KI herum konzipiert werden, verantwortet der Kunde. Viele Unternehmen vernachlässigen diese Ebene. Auch besteht die Gefahr, dass "Human-in-the-loop" (Mensch bestätigt jede Aktion) bei hoher Geschwindigkeit oft zu "Human-on-the-side" verkommt – der Mensch nickt nur noch ab, ohne zu prüfen.
• Layer 3: Die Tools – Je nach Use Case und Vertrag kann die Verantwortung für Schnittstellen, Protokolle, Dienste und Plugins, auf die ein Agent zugreift, geteilt sein. Dieses Layer bietet mit Abstand das größte Diskussionspotenzial. Diskutiert wird u. a.: Wer haftet, wenn ein Agent aufgrund eines fehlerhaften Drittanbieter-Tools Daten löscht? Anthropic fordert in diesem Zusammenhang striktere Rollen- und Berechtigungskonzepte.
• Layer 4: Die Umgebung – Die Sandbox oder das Netzwerk, in dem der Agent operiert, sieht Anthropic eindeutig in der Verantwortung des Kunden.

Was bedeutet Shared Responsibility in der IT-Praxis?

Beim Modell der Shared Responsibility kauft man ein sicheres Fundament, auf dem man die eigene Sicherheit aufbauen muss.

Für IT-Verantwortliche ergeben sich daraus drei kritische Handlungsfelder:

1. Vermeidung von "Blind Spots": IT-Verantwortliche müssen genau prüfen, wo die Verantwortung des Anbieters endet.
2. Compliance & Audit: Bei Audits müssen IT-Leiter nachweisen, dass sie ihren Teil der Verantwortung erfüllt haben. Der Provider liefert SOC-2-Reports meist nur für seinen Teil.
3. Skill-Management: Teams müssen u. a. in IAM-Strategien, Prompt-Governance und Cloud-Security-Posturing geschult werden.

Erfahren Sie auf Seite 2, wie Shared Responsibility am konkreten Beispiel "Einführung einer KI-Lösung in einem regulierten Umfeld (z. B. Bankwesen, Versicherung, Gesundheitswesen oder öffentlicher Sektor)” aussieht.

In unserem Szenario nehmen wir an, ein Unternehmen nutzt ein Large Language Model (LLM) eines Anbieters in einer Cloudumgebung (z. B. Microsoft Azure OpenAI, Google Vertex AI oder Anthropic via AWS Bedrock) für eine interne Wissensdatenbank oder einen Kunden-Chatbot.

Daraus ergeben sich folgende Verantwortlichkeiten:

Die Infrastruktur- & Modell-Ebene (Verantwortung: Provider)

Der Anbieter (z. B. Microsoft oder Google) garantiert die Sicherheit der „Blackbox“ und der Umgebung:

• Physische Sicherheit & Rechenzentrum: Schutz der Server, auf denen die GPU-Cluster laufen.
• Modell-Integrität: Sicherstellen, dass das Basismodell nicht durch externe Angriffe während des Betriebs manipuliert wird (Model Poisoning).
• Safety Filters (Basis): Implementierung grundlegender Filter, die verhindern, dass das Modell Anleitungen für illegale Aktivitäten oder Hassrede generiert.
• Data Residency: Optionen, die sicherstellen, dass Daten das Staatsgebiet oder die EU nicht verlassen (essenziell für DSGVO/GDPR).
• Zertifizierungen: Bereitstellung von Compliance-Nachweisen wie SOC2, ISO 27001, HIPAA-Konformität

Die Daten- & Input-Ebene (Verantwortung: Kunde / IT-Verantwortlicher)

Hier liegt das größte Risiko in regulierten Branchen. Der Anbieter weiß nicht, welche Daten in das Modell eingespeist werden.

• Daten-Klassifizierung & Anonymisierung: Bevor Daten an die KI gesendet werden, muss der Kunde sicherstellen, dass keine personenbezogenen Daten (PII) oder Geschäftsgeheimnisse übertragen werden (außer es besteht ein spezifischer Auftragsverarbeitungsvertrag).
• RAG-Sicherheit (Retrieval Augmented Generation): Wenn die KI auf kundeneigene Dokumente zugreift: Wer hat worauf Zugriff? Die KI darf z. B. einem Sachbearbeiter keine Informationen aus den Gehaltsabrechnungen der Geschäftsführung anzeigen.
• Prompt-Injection-Defense: Schutz vor böswilligen Eingaben, die versuchen, die Sicherheitsfilter der KI zu umgehen.

Die Output- & Anwendungs-Ebene (Verantwortung: Kunde)

KI-Modelle sind stochastisch – sie raten das nächste Wort. Das kollidiert oft mit der regulatorischen Forderung nach Korrektheit.

• Validierung & Halluzinationen: Wenn die KI eine falsche Rechtsauskunft oder Finanzberatung gibt, haftet der Anbieter des Dienstes – also die Bank oder die Versicherung –, nicht der Modellentwickler. Der Kunde muss Mechanismen zur Prüfung (Human-in-the-loop) etablieren.
• Bias-Monitoring: In regulierten Umfeldern muss sichergestellt werden, dass die KI niemanden aufgrund von Herkunft, Alter oder Geschlecht diskriminiert (z. B. bei Kreditentscheidungen). Das Modell-Training übernimmt der Provider, aber die Anwendung des Modells auf spezifische Gruppen überwacht der Kunde.
• Erklärbarkeit (Explainability): Regulatoren (wie die BaFin oder die EZB) fordern oft, dass Entscheidungen nachvollziehbar sind. Der Kunde muss dokumentieren können, wie die KI-Lösung zu einem Ergebnis gekommen ist.

Governance & Compliance (Geteilte Verantwortung)

Der Provider bietet Standard-Service-Level-Agreements (SLA), loggt API-Aufrufe und Systemzugriffe und stellt "Encryption at rest" bzw. "in transit" bereit.

Der Kunde loggt, welcher Mitarbeiter welche Abfrage gestellt hat, verwaltet die Verschlüsselungs-Keys (BYOK - Bring Your Own Key) und muss spezifische Zusatzvereinbarungen (z.B. für Berufsgeheimnisträger) prüfen.

Was bedeutet das konkret für den Rollout?

Wenn Sie in einem regulierten Umfeld eine KI einführen, müssen Sie als IT-Verantwortlicher folgende Checkliste abarbeiten, da der Anbieter diese Punkte nicht für Sie übernimmt:

1. Technisches Assessment: Verwendet der Provider meine Prompts zum Training seiner Modelle? (In Enterprise-Versionen meist deaktiviert, muss aber explizit geprüft werden).
2. Sicherheits-Layer: Einbau eines "Security-Gateways" zwischen Nutzer und KI, das sensible Daten filtert, bevor sie das Haus verlassen.
3. Fachliche Kontrolle: Implementierung eines Prozesses, bei dem KI-Outputs von Experten gegengelesen werden, bevor sie den Endkunden erreichen.
4. Dokumentation: Erstellung einer Risikoanalyse nach dem neuen EU AI Act, der die Verantwortung je nach Risikoklasse der Anwendung streng dem "Betreiber" (also Ihnen) zuweist.

Fazit

Bei KI-Lösungen in einem regulierten Umfeld sind Haftungs- und Compliance-Fragen weitaus komplexer als bei Standard-IT-Projekten. "Shared Responsibility" ist quasi gleichbedeutend mit einem "90-%-Risiko-Shift" zum Kunden. Während der Provider die Hardware und das Modell absichert, liegt das inhaltliche Risiko (Haftung für falsche Aussagen) zu fast 100 % bei Ihnen.