Licensed to be used in conjunction with basebox, only.
// sicherheit
Konnektoren
Gilt für
Produkt: Demo · 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.
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 |
|---|---|
| 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.
- 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.
- 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.
- Demo: Zum Ausprobieren des Gate-Verhaltens mit Testsystemen.
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 an das SIEM (SIEM-Integration).
Nächster Schritt: Audit & Logging