Super sicher. Super einfach.
Ein zentraler Super-User mit einer lokal nachgebauten Rechtematrix ist ausdrücklich nicht das Zielmodell. Microtech bleibt Autorität über Geschäftsdaten und Benutzerrechte – SuperBRAIN fügt eine zusätzliche, geprüfte Governance-Schicht hinzu.
Die Autorisierungsformel
Microtech-Recht ∩ Plattform-Policy ∩ Kunden-Policy ∩ MCP-Scopes ∩ Freigabe
Nur wenn alle fünf Bedingungen gleichzeitig erfüllt sind, wird eine Aktion überhaupt sichtbar oder ausführbar – unabhängig davon, über welchen Kanal die Anfrage kommt.
Vier strikt getrennte Identitätstypen
Keine Identität erbt implizit die Rechte einer anderen.
Interaktive Web-Identitäten
Login am Cortex Control Plane – Passwort-Hashing, verschlüsseltes TOTP/2FA, sichere Session-Cookies.
MCP-Service-Identitäten
OIDC/OAuth Client Credentials für KI-Clients und Automationen, mit rotierbaren Secrets.
ERP-Identitäten
Microtech-Benutzer, gebunden über explizite Identitäts-Verknüpfungen – nie implizit übernommen.
Kunden-/Self-Service-Identitäten
Externe Portal- oder Website-Nutzer, verifiziert per Magic Link, OTP, Passkey oder MFA.
Zwei getrennte OAuth-Resource-Server
BVP MCP Resource Server
Authentifiziert KI-Clients und Automationen gegenüber der Plattform selbst.
Microtech GraphQL Resource Server
Authentifiziert den eigentlichen ERP-Nutzer und setzt Microtechs eigene Rechte auf jedem Aufruf durch. Ein MCP-Token wird niemals als Microtech-Token weitergereicht.
Risikoklassen für Schreiboperationen
Schreiben wird nach Kritikalität gestuft – nicht alles ist gleich riskant, also wird auch nicht alles gleich behandelt.
| Klasse | Beispiele | Regel |
|---|---|---|
| R0 | Lesen & Introspektion | Keine Freigabe nötig |
| R1 | Entwurf, unkritisches Anlegen | Nach Kunden-Policy |
| R2 | Stammdaten ändern, Beleg anlegen | Explizite Freigabe erforderlich |
| R3 | Buchen, Stornieren, Konvertieren, Archivieren | Freigabe stets durch eine andere Person |
| R4 | Massenänderung, Löschung | Standardmäßig deaktiviert |
Mandantentrennung
PostgreSQL Row-Level-Security schützt jeden Mandanten zusätzlich zur Anwendungsebene. Der Sicherheitskontext wird pro Transaktion gesetzt und nie über gepoolte Verbindungen wiederverwendet – fehlender Kontext bedeutet automatisch Zugriffsverweigerung.
Secrets & Audit
ERP-Passwörter und OAuth-Secrets liegen nie im Klartext in der Datenbank – nur verschlüsselte Verweise. Jede relevante Aktion ist mandantengebunden, nachvollziehbar und auditierbar.