Licensed to be used in conjunction with basebox, only.
// sicherheit
Konnektoren
Gilt für
Produkt: Cloud · Server · Zielgruppe: Sicherheits- / Compliance-Prüfer
Sicherheitseigenschaften, die alle Konnektoren teilen: Zugangsdaten je Nutzer, nur schreibend gespeicherte Zugangsdaten, Freigabe je App, das Zugriffskontroll-Gate in AISRV, Egress-Allowlist, Schreibwerkzeuge standardmäßig aus. Konnektoren (MCP-Server) verbinden basebox mit Ihren eigenen Systemen – Wiki, Ticketsystem, E-Mail, Fachsysteme. Das Grundprinzip: basebox verwaltet keine fremden Berechtigungen; es sorgt dafür, dass jede Anfrage als der richtige Nutzer beim Zielsystem ankommt, und das Zielsystem entscheidet. Daraus folgt: Wer eine App teilt, teilt ihre Dokumente, nie den eigenen Zugang – über Konnektoren bekommt jede Person nur Antworten aus Daten, die sie selbst öffnen darf.
Das Gate
Bevor das Modell ein Werkzeug überhaupt sieht, prüft AISRV drei Dinge und bildet die Schnittmenge:
| Prüfung | Quelle | Ohne sie |
|---|---|---|
| Organisation hat den Konnektor aktiviert | Administration | Der Konnektor existiert für die Organisation nicht |
| App gibt das Werkzeug frei | Werkzeugeinstellungen der App; Schreibwerkzeuge einzeln | Das Werkzeug wird dem Modell nicht angeboten |
| Nutzer hat den Konnektor aktiviert und – wo nötig – Zugangsdaten hinterlegt | Nutzereinstellungen | Das Werkzeug wird dem Modell nicht angeboten |
Erst dann setzt AISRV die Zugangsdaten dieses Nutzers ein und ruft den Konnektor auf; der Konnektor reicht sie unverändert ans Zielsystem durch. Sequenzdiagramm: MCP-Berechtigungsablauf.
Garantien
| Eigenschaft | Umsetzung |
|---|---|
| Anmeldung am Zielsystem | Mit dem eigenen Konto der Person: Bietet das System OAuth an, erhält basebox eine Freigabe, kein Passwort; sonst hinterlegt die Person ein eigenes Token oder Benutzername und Passwort. OAuth ist ein Anmeldeverfahren, kein eigener Konnektor |
| Isolierung je Nutzer | Zugangsdaten getrennt je Nutzer gespeichert und je Anfrage anhand der Nutzerkennung geladen |
| Kein gemeinsames Admin-Token | basebox hält kein privilegiertes Token für alle Nutzer; ein Servicekonto ist nur für allgemein zugängliche Inhalte vertretbar |
| Kein Zugangsdaten-Caching | Frisch aus der Datenbank je Anfrage; nicht im Prozessspeicher über Anfragen hinweg |
| Zielsystem setzt Rechte durch | Keine Filterschicht, keine Rechte-Kopie; 401/403 des Zielsystems werden zu sichtbaren Werkzeugergebnissen, kein Rückfall |
| Schreibzugriff standardmäßig aus | Je App; Administrator gibt Schreibwerkzeuge einzeln frei |
| Vertraulichkeit der Zugangsdaten | Nur schreibend gespeichert; Administratoren sehen sie nicht; nie in Produktionslogs |
| Sofortiger Entzug | Widerrufenes Token oder deaktiviertes Konto → nächster Aufruf scheitert; keine Sitzung, kein Cache |
| Egress-Allowlist | Jeder Konnektor erreicht nur seine deklarierten Zielhosts; das MCP-Gateway blockiert alles andere |
| Audit | Werkzeugaufrufe im Audit-Log mit Metadaten (Organisation, Nutzer, Werkzeug, Ergebnis, Zeitstempel) |
Was fließt
Bei einem Werkzeugaufruf gehen an das Zielsystem: die Parameter des Aufrufs (die das Modell aus dem Gespräch bildet – etwa ein Suchbegriff oder eine Ticketnummer) und die Zugangsdaten des Nutzers. Zurück kommt das Ergebnis des Zielsystems, das dem Modell als Kontext dient und damit in die Antwort einfließt – und auf dem Weg AISRV → Inferenz die Inferenz-Hardware erreicht (Datenflüsse). Bei Schreibwerkzeugen entstehen Änderungen im Zielsystem unter der Identität des Nutzers.
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 hinter einen Konnektor mit persönlichen Zugangsdaten, nicht in eine Wissensbasis. Dasselbe gilt für Dateien, die eine App von einem Netzlaufwerk übernimmt (nur beim Server): Netzlaufwerke sind kein Konnektor, basebox verbindet sie bei der Einrichtung mit einem Zugang für die ganze Organisation und nur lesend; die Rechte auf dem Laufwerk gelten nicht je Person, gesteuert wird über die Freigabe der App (Netzlaufwerke).
- Websuche + interner Konnektor in derselben App ist der Exfiltrationspfad – trennen (Websuche).
- Was der Nutzer sieht, sieht das Modell. Ein Konnektor macht dem Modell zugänglich, was der Nutzer ohnehin lesen darf – nicht mehr, nicht weniger. Werkzeugsichtbarkeit je Gruppe ist angekündigt.
- Eigene Konnektoren unterliegen denselben Regeln, aber Sie verantworten deren Umsetzung – Checkliste unter Berechtigungen. Konnektoren aus der Bibliothek von basebox prüft basebox; eigene oder fremde MCP-Server, die Sie innerhalb Ihrer Organisation einspielen, prüft basebox nicht.
- Organisationsweite Zugangsdaten (etwa ein API-Schlüssel eines Zielsystems, den der Administrator hinterlegt) sind eine bewusste Ausnahme vom Je-Nutzer-Prinzip und nur für Inhalte vertretbar, die alle Nutzer der App sehen dürfen (Konnektor-Authentifizierung).
Je Deployment-Modell
- Cloud: Konnektor-Dienste stellt basebox bereit; Zielsysteme in Ihrem Netz erreichen sie aus dem Noris-Rechenzentrum – Sie geben je Konnektor genau einen Pfad frei (Netzanbindung). Eigene MCP-Server bindet basebox in Abstimmung mit Ihnen an.
- Server: Konnektoren laufen als eigene Deployments im Cluster (MCP-Konnektoren mit Helm); Zielsysteme sind meist intern; die Egress-Allowlist ergänzt Ihre Firewall.
Für die Prüfung
- Liste der aktivierten Konnektoren mit Zielsystem, Nutzerkreis, Lese-/Schreibrechten und Zugangsdaten-Modell (je Nutzer / organisationsweit).
- Schreibwerkzeuge: Begründung je App, in der sie freigegeben sind.
- Websuche in eigener App, getrennt von internen Konnektoren.
- Audit-Log auf Werkzeugaufrufe prüfen; Exporte für das SIEM (SIEM-Anbindung).
Nächster Schritt: Audit & Logging