Wer hält den Schlüssel? Drei Entscheidungen, die Multi-Tenant-RAG-Architektur prägen

Eine Standard-Aussage in der RAG-Welt lautet: „Ihre Originaldokumente verlassen Ihre Infrastruktur nicht." Das stimmt — und ist trotzdem nur die halbe Wahrheit.

In modernen RAG-Architekturen bleiben die Originaldateien tatsächlich beim Kunden. Was zum Anbieter wandert, sind nicht die Dokumente, sondern deren Index-Datensätze: kleine Textbausteine ("Chunks") plus mathematische Fingerabdrücke ("Embeddings"). Genau diese Chunks sind aber der Inhalt, den ein RAG-Modell bei einer Anfrage zurückgibt. Wer sie liest, sieht den Inhalt.

Damit verschiebt sich die Privacy-Frage von „werden Originaldateien hochgeladen?" zu „wer kann den Index lesen, und unter welchen Bedingungen?". Diese Frage stellt sich überall dort, wo Wissen auf Need-to-Know-Basis organisiert sein muss — und das ist in vielen Branchen der Normalzustand: getrennte Mandate in einer Kanzlei, Geschäftsbereiche in einem Konzern, Klient-Akten in einer Beratung, Patientenkohorten in einem Klinikverbund, Auftraggeber-Akten bei einem Dienstleister mit mehreren Kunden.

In all diesen Fällen müssen drei Architektur-Entscheidungen früh fallen.

Entscheidung 1: Wie verhindern wir, dass ein Mandant die Daten eines anderen sieht?

Die wichtigste Privacy-Frage in einem Multi-Tenant-System ist nicht „kann sich jemand reinhacken?", sondern „können wir Konfigurationsfehler verhindern, die Daten von Mandant A in einer Antwort an Mandant B auftauchen lassen?". Diese Sorte Leck — durch interne Schluderei, nicht durch externe Angriffe — ist die mit Abstand häufigste Ursache realer Vorfälle.

Stell dir den RAG-Speicher wie eine Bibliothek vor. Es gibt zwei verbreitete Ansätze.

Im ersten bekommt jeder Mandant eine eigene Sammlung — ein eigenes Aktenfach. Wer reinschreibt oder rauszieht, muss explizit benennen, welches Fach er meint. Es gibt im Datenmodell keine Möglichkeit, „aus Versehen alle Fächer auf einmal" zu durchsuchen. Die Trennung wird vom System erzwungen, nicht von der Disziplin der Entwickler.

Im zweiten Ansatz teilen sich alle Mandanten eine einzige Sammlung; jeder Datensatz trägt einen Markierungs-Stempel mit der Mandanten-Nummer. Bei jeder Anfrage wird ein Filter mitgeschickt: „nur Stempel = X". Funktioniert, solange der Filter überall korrekt gesetzt wird. Wird er an einer Stelle vergessen — durch einen neuen Endpunkt, einen Debug-Pfad, eine Code-Änderung — gibt es keine zweite Sicherungsebene. Die gesamte Privacy-Garantie hängt an einer Code-Konvention.

Für Use-Cases, in denen Wissen tatsächlich need-to-know organisiert sein muss, ist die Wahl klar: eigene Sammlung pro Mandanten-Einheit. Der minimale Skalierungs-Overhead wiegt das Risiko, dass irgendwann ein Filter vergessen wird, mehrfach auf.

Entscheidung 2: Wer kann die gespeicherten Daten technisch lesen?

Sobald Mandanten-Inhalte beim Anbieter auf der Festplatte liegen, ist die Folgefrage: wer kann sie technisch eigentlich lesen? Auch wenn vertraglich nur der Mandant berechtigt ist — ein Insider mit Datenbank-Zugriff, ein falsch konfiguriertes Backup, der Cloud-Hoster im Hintergrund — die Roh-Bytes existieren irgendwo. Verschlüsselung schließt diese Möglichkeit, allerdings nur bis zu einem klar definierten Grad.

Die Standard-Mechanik heißt Envelope-Verschlüsselung. Jeder Datensatz wird mit einem Datenschlüssel verschlüsselt; dieser Datenschlüssel wiederum mit einem zweiten, übergeordneten Schlüssel — dem „Master". Den Master verwaltet ein spezialisierter Schlüssel-Tresor (das KMS, Key Management System). Wer Daten lesen will, braucht den Master. Wer den Master löscht, macht alle damit verschlüsselten Daten unleserlich — auch alle Backups, die noch herumliegen.

Pro Mandant einen eigenen Master zu vergeben ist deshalb ungewöhnlich nützlich: es ermöglicht Crypto-Shredding. Wenn ein Mandant sein „Recht auf Vergessen" einfordert, muss der Anbieter nicht versuchen, jede einzelne Backup-Kopie zu jagen — in der Praxis unmöglich und bei Wirtschaftsprüfungen nie verlässlich nachweisbar. Stattdessen wird der Master-Schlüssel des Mandanten gelöscht, und sämtliche verschlüsselten Daten werden unleserlich. Ein Versprechen, das auf Mathematik beruht, nicht auf Vollständigkeit beim Suchen.

Beim Schlüssel-Halter gibt es drei realistische Stufen.

Provider-managed. Der Anbieter betreibt das KMS selbst, jeder Mandant hat seinen eigenen Master. Der Anbieter kann den Schlüssel rotieren, drehen, im Notfall löschen. Er könnte aber, wenn er wollte oder rechtlich gezwungen wäre, mit seinem KMS-Zugriff auch den Klartext lesen. Das ist nicht versteckt — es ist die Definition davon, dass der Anbieter den Dienst hostet. Was der Mandant bekommt, ist eine vertragliche Selbstbindung (per Auftragsverarbeitungs-Vertrag), nicht eine technische Unmöglichkeit.

Bring-Your-Own-Key (BYOK). Der Mandant stellt den Schlüssel bereit, üblicherweise in seinem eigenen KMS (etwa Google Cloud KMS oder AWS KMS). Der Anbieter ruft ihn nur kurz auf, um zu entschlüsseln, und hält ihn nie selbst. Der Mandant kann den Anbieter zu jedem Zeitpunkt aussperren, indem er bei sich den Schlüsselzugriff zurückzieht. Stärker als Provider-managed, weil der Anbieter die „moralisch hätte ich ja zugreifen können"-Verantwortung gar nicht erst trägt. Der Preis ist Engineering-Aufwand: zwei bis vier Wochen zusätzliche Bauzeit, wenn die Grundarchitektur dafür vorgesehen ist.

Operator-blind. Der Mandant verschlüsselt selbst, bevor irgendetwas zum Anbieter wandert. Der Anbieter sieht nur Ciphertext und kann ihn nicht durchsuchen — denn um relevante Treffer zu finden, muss das System irgendwo verstehen, was gespeichert ist. Operator-blind ist deshalb nicht das, was ein zentral gehosteter Dienst realistisch anbieten kann. Sie kommt erst zurück, wenn der Mandant den ganzen Stack selbst hostet.

Daraus folgt eine Ordnungs-Regel: wer die Schlüssel hält, hostet auch. Es gibt keinen sinnvollen Pfad, bei dem ein Kunde die Schlüssel hält und der Anbieter zentral hostet. In der Praxis gibt es deshalb zwei Service-Modelle — ein gehostetes mit Provider- oder BYOK-Schlüsseln, und ein souveränes, bei dem der Mandant den Stack in seiner eigenen Umgebung betreibt.

Entscheidung 3: Wie weisen sich Mandanten gegenüber dem Dienst aus?

Jeder Aufruf an den Dienst muss eine Antwort auf die Frage tragen: Wer bin ich, und darf ich das?. Die Antwort heißt in der API-Welt Token — ein Stück geheimer Text, das mit jeder Anfrage mitgeschickt und vom Server überprüft wird. Es gibt zwei verbreitete Pattern-Familien.

Lang-lebige API-Schlüssel mit Widerrufsliste sind die pragmatische, im B2B-Bereich am weitesten verbreitete Variante. Der Mandant bekommt einen langen, geheimen Token, legt ihn sicher ab — ähnlich wie ein Passwort, das nicht abläuft — und schickt ihn mit jedem Aufruf mit. Falls der Schlüssel kompromittiert wird (typischerweise weil er versehentlich auf GitHub gelandet ist, was häufiger passiert als man denkt), wird er auf die Widerrufsliste gesetzt und ein neuer ausgestellt. Das ist das Muster hinter AWS-Access-Keys, OpenAI-Keys, Stripe-Keys. Der Nachteil: ein gestohlener Schlüssel ist gültig, bis es jemand merkt.

Kurzlebige JWT-Tokens mit Refresh-Mechanismus sind die strengere Variante. Der Mandant authentifiziert sich einmal mit einem lang-lebigen Refresh-Token und bekommt dafür einen kurz-lebigen Access-Token, der nach 24 Stunden abläuft. Falls er gestohlen wird, ist er ohnehin bald nutzlos. Der Nachteil ist die zusätzliche Komplexität beim Mandanten: Refresh-Logik, Uhrzeit-Differenzen, Fehlerbehandlung. Das macht das Onboarding härter und produziert mehr Support-Fälle.

Für die meisten B2B-Use-Cases sind lang-lebige API-Schlüssel mit Widerrufsliste die richtige Wahl. Eine schnelle Widerruf-Möglichkeit über die Admin-API und optionale automatische Rotation begrenzen das Schadens-Fenster ausreichend. JWT-Tokens lassen sich für einzelne Mandanten mit besonderen Sicherheits-Anforderungen nachziehen, ohne die Grundarchitektur zu ändern.

Die drei Entscheidungen sind eine zusammen

Es ist verlockend, die drei Entscheidungen unabhängig voneinander zu treffen. In der Praxis hängen sie zusammen und definieren gemeinsam die Trust-Posture eines Dienstes — was der Anbieter den Mandanten realistisch verspricht.

Vor Vertragsschluss lohnt es sich für einen Mandanten, drei konkrete Fragen zu stellen:

• Sind unsere Daten in einer eigenen Sammlung getrennt, oder teilen wir uns einen Speicher mit anderen Kunden?
• Wer hält den Schlüssel zu unseren Daten — der Anbieter, oder können wir einen eigenen mitbringen?
• Wie wird unser API-Zugriff authentifiziert, und wie schnell können wir einen kompromittierten Schlüssel widerrufen?

Ein Anbieter, der diese Fragen ohne Ausweichmanöver beantwortet, hat die Architektur durchdacht.

Was Creaminds dazu beiträgt

Diese drei Entscheidungen treffen wir in laufenden Projekten — für Kunden, die ihre eigene RAG-Infrastruktur aufbauen oder externe Dienste evaluieren. Wir helfen in der Architektur-Phase, wenn die Trust-Posture festgelegt wird; in der Implementierung, wenn Datenmodell und Schlüssel-Verwaltung gebaut werden; und in der Bewertung externer Anbieter, wenn Sie wissen wollen, was hinter einem „Producer-Push macht es privat"-Versprechen tatsächlich steckt.

Den hier beschriebenen Service-Stack bauen wir auch selbst — sowohl als gehostete als auch als souveräne Variante. Wenn die Architektur-Fragen aus diesem Artikel in einem konkreten Projekt bei Ihnen auftauchen, sprechen Sie uns an.