Licensed to be used in conjunction with basebox, only.
// integration
Berechtigungen
Gilt für
Produkt: Cloud · Server · Zielgruppe: Entwickler / Integrator · Sicherheitsprüfer
Sicherstellen, dass ein Nutzer über basebox nur erreicht, was er im Quellsystem erreichen darf – und wie das Zugriffskontroll-Gate von basebox das durchsetzt. Die Antwort ist bewusst einfach: basebox verwaltet keine fremden Berechtigungen. Es sorgt dafür, dass jede Anfrage als der richtige Nutzer beim Quellsystem ankommt, und das Quellsystem entscheidet.
Das Prinzip
basebox ist transparent. Es repliziert oder cacht die Zugriffsrechte des angebundenen Systems nie. Bei jeder Anfrage reicht es die eigenen Zugangsdaten des Nutzers weiter, sodass immer dessen Berechtigungsmodell gilt:
- Ein Nutzer mit Nur-Lese-Zugriff auf Projekt A erhält über basebox nur Projekt A. Das setzt das Ticketsystem durch, nicht basebox.
- Ein Nutzer ohne Zugriff auf einen Wiki-Bereich erhält dieselbe Antwort „nicht gefunden" oder „Zugriff verweigert" wie im Browser.
- basebox fügt keine Rechte hinzu und nimmt keine weg – mit einer Ausnahme: Schreibwerkzeuge sind standardmäßig deaktiviert.
Das Gate in basebox
Bevor das Modell ein Werkzeug überhaupt sieht, prüft AISRV drei Dinge und bildet die Schnittmenge:
| Prüfung | Quelle | Wirkung |
|---|---|---|
| Organisation hat den Konnektor aktiviert | Administrationseinstellung | Sonst existiert der Konnektor nicht |
| App gibt das Werkzeug frei | Werkzeugeinstellungen der App | Sonst wird es dem Modell nicht angeboten; Schreibwerkzeuge müssen einzeln freigegeben sein |
| Nutzer hat den Konnektor aktiviert und – wo nötig – Zugangsdaten hinterlegt | Nutzereinstellungen | Sonst wird es dem Modell nicht angeboten |
Erst dann setzt AISRV die Zugangsdaten dieses Nutzers in die Verbindungskonfiguration ein und ruft Ihren Server auf. Sind die Zugangsdaten ungültig oder widerrufen, lehnt das Zielsystem ab – und das ist das gewünschte Verhalten.
Was Ihr Konnektor tun muss
Durchreichen, nicht entscheiden. Der Authorization-Header geht unverändert ans Zielsystem. Jede Antwort des Zielsystems – auch eine Verweigerung – geht als Ergebnis zurück.
Nie ein gemeinsames Admin-Token für nutzerspezifische Daten. Der Klassiker, den Sie vermeiden: mit einem Servicekonto alles abrufen und dann „für den Nutzer filtern". Das ist keine Zugriffskontrolle, sondern eine Nachbildung davon – und sie ist immer unvollständig. Ein Servicekonto ist nur für Inhalte vertretbar, die alle sehen dürfen.
Keine Rechte-Kopie. Ihr Server hält keine Liste, wer was darf. Er weiß es nicht und muss es nicht wissen.
Kein Cache über Nutzer hinweg. Ein Ergebnis, das Nutzer A sehen durfte, darf nicht aus einem Cache an Nutzer B gehen.
Verweigerung sichtbar machen. 401 und 403 des Zielsystems werden zu klaren Werkzeugergebnissen („Kein Zugriff auf …"). Kein stiller Rückfall, kein zweiter Versuch mit anderen Zugangsdaten.
Was basebox garantiert – zusammengefasst
| Eigenschaft | Umsetzung |
|---|---|
| Isolierung je Nutzer | Zugangsdaten getrennt je Nutzer gespeichert und je Anfrage anhand der user_id geladen |
| Kein gemeinsames Admin-Token | basebox hält kein privilegiertes Token für alle Nutzer |
| Kein Zugangsdaten-Caching | Frisch aus der Datenbank je Anfrage; nicht im Prozessspeicher über Anfragen hinweg |
| Zielsystem setzt Rechte durch | Keine Filterschicht, keine entfernten Prüfungen |
| Schreibzugriff standardmäßig aus | Je App; Administrator gibt einzeln frei |
| Vertraulichkeit der Zugangsdaten | Nie in Produktionslogs; nur schreibend gespeichert; Administratoren sehen sie nicht |
| Sofortiger Entzug | Widerrufenes Token oder deaktiviertes Konto → nächster Aufruf scheitert; keine Sitzung, kein Cache |
Das Sequenzdiagramm dazu: MCP-Berechtigungs- und Autorisierungsablauf.
Grenzen, die Sie kennen sollten
- Wissensbasen sind anders. Dokumente in einer App-Wissensbasis sieht jeder, der die App nutzen darf – dort gibt es keine Rechteprüfung je Nutzer. Sensible Inhalte gehören deshalb hinter einen Konnektor mit persönlichen Zugangsdaten, nicht in eine Wissensbasis. Siehe Wissensbasen verwalten.
- Websuche + interne Werkzeuge in derselben App ist der Pfad, den Sicherheitsteams am ernstesten nehmen: Eine manipulierte Webseite könnte versuchen, interne Daten über eine Folgesuche herauszuschmuggeln. Die architektonische Antwort ist die Trennung je App – siehe Einführung in die Websuche-Sicherheit.
- Was der Nutzer sieht, sieht das Modell. Ein Konnektor macht dem Modell zugänglich, was der Nutzer ohnehin lesen darf – nicht mehr, aber auch nicht weniger. Gruppenweise Werkzeugsichtbarkeit ist für kommende Releases angekündigt.
Checkliste für die Sicherheitsprüfung eines Konnektors
- Nutzerspezifische Daten nur mit persönlichen Zugangsdaten
- Header unverändert durchgereicht; kein Token-Tausch
- Keine Rechte-Liste, kein Cache über Nutzer hinweg
- 401/403 als Ergebnis, kein Rückfall
- Schreibwerkzeuge getrennt, standardmäßig aus
- Nur ein Zielsystem im Netz (Egress-Allowlist)
- Keine Zugangsdaten in Logs
- Servicekonto – falls vorhanden – nur lesend, nur für allgemein zugängliche Inhalte, aus Kubernetes-Secret