Serie Kundenportale: Teil 5 von 5
Viele Sicherheitsgespräche über Kundenportale beginnen mit der Anmeldung: Passwortregeln, Mehrfaktor-Authentifizierung und Single Sign-on. Diese Punkte sind wichtig. Sie lösen aber nur eine von mehreren Aufgaben.
Nach der Anmeldung muss das Portal entscheiden, welche Daten, Dokumente und Funktionen eine Person tatsächlich nutzen darf. Im B2B hängt das selten nur vom Benutzerkonto ab. Unternehmen, Standorte, Verträge, Produktgruppen, Märkte und Verantwortlichkeiten wirken zusammen.
SSO beantwortet, wer sich anmeldet. Das Berechtigungsmodell beantwortet, was diese Person sehen und tun darf.
Warum B2B-Berechtigungen komplexer sind
Ein Geschäftskunde kann mehrere Standorte und Tochtergesellschaften besitzen. Eine Person bestellt für einen Standort, darf Rechnungen aber nicht sehen. Eine andere verwaltet Nutzende für das gesamte Unternehmen. Externe Dienstleister benötigen zeitlich begrenzten Zugriff. Vertretungen ändern sich und ehemalige Mitarbeitende müssen zuverlässig entfernt werden.
Ein einfaches Schema aus „Admin“ und „Benutzer“ wird diesen Beziehungen nicht gerecht. Es führt entweder zu unnötigen Einschränkungen oder zu zu weitreichenden Zugriffen.
Vier Ebenen eines belastbaren Modells
1. Identität
Die Identität beschreibt die konkrete Person und den Weg ihrer Authentifizierung. Das Portal kann eigene Konten verwalten oder einen vorhandenen Identity Provider anbinden. SSO reduziert zusätzliche Zugangsdaten und kann vorhandene Sicherheitsrichtlinien nutzen.
Wichtig ist eine klare Verantwortung: Wer erstellt Identitäten, wer sperrt sie und welches System führt Passwort-, MFA- und Sicherheitsregeln?
2. Organisation
Im B2B handelt eine Person im Kontext eines Unternehmens. Dieses kann aus Standorten, Abteilungen, Tochtergesellschaften oder Partnerorganisationen bestehen. Das Organisationsmodell entscheidet beispielsweise, ob eine Person Aufträge nur für Hamburg oder für den gesamten Konzern sehen darf.
Die Organisationsstruktur sollte nicht unkontrolliert im Portal dupliziert werden. Es muss geklärt sein, ob CRM, ERP, Identity Management oder eine zentrale Datenplattform die maßgebliche Zuordnung führt.
3. Rolle
Rollen bündeln typische Verantwortlichkeiten: Einkauf, Technik, Buchhaltung, Service, Administration oder externe Partnerschaft. Sie erleichtern die Verwaltung, dürfen aber nicht zu pauschal sein.
Eine Rolle beschreibt nicht zwangsläufig alle Zugriffe. Sie muss häufig mit Organisation, Vertrag oder Produktbeziehung kombiniert werden.
4. Berechtigung am konkreten Objekt
Die kritischste Prüfung findet häufig am einzelnen Objekt statt: Darf diese Person genau dieses Dokument, diesen Auftrag oder dieses Produkt sehen? Darf sie nur lesen, Änderungen vorschlagen oder verbindlich freigeben?
Gerade bei kundenspezifischen Preisen, Verträgen, regulatorischen Dokumenten oder mehreren Mandanten darf die Oberfläche nicht die einzige Schutzschicht sein. Berechtigungen müssen auch bei Suche, Download und API-Zugriff konsequent greifen.
SSO ist Grundlage, nicht Berechtigungskonzept
Single Sign-on verbessert Bedienbarkeit und zentrale Kontrolle. Es kann vorhandene Identitätsanbieter und Sicherheitsrichtlinien einbinden. Die fachliche Berechtigung bleibt trotzdem Aufgabe des Portals und seiner Datenmodelle.
Ein Identity Provider weiß möglicherweise, dass eine Person zu einem Unternehmen gehört. Er weiß nicht automatisch, welche Produktfamilien vertraglich freigegeben sind oder welche Dokumentversion für einen Markt gilt.
Deshalb müssen Authentifizierung und fachliche Autorisierung getrennt geplant und sauber verbunden werden.
Der Lebenszyklus wird oft vergessen
Ein Berechtigungskonzept ist nicht mit der ersten Einladung abgeschlossen. Es muss den gesamten Lebenszyklus berücksichtigen:
- Wer darf neue Personen einladen?
- Muss eine Einladung intern bestätigt werden?
- Wie werden Rollen geändert?
- Wie funktionieren Vertretungen und zeitlich begrenzte Zugriffe?
- Was geschieht bei Unternehmens- oder Standortwechsel?
- Wie werden inaktive Konten erkannt?
- Wer entzieht Zugriffe beim Offboarding?
- Welche Änderungen müssen protokolliert werden?
Je mehr diese Vorgänge manuell im Support landen, desto weniger Self-Service wurde tatsächlich erreicht.
Praxis: Datenblätter und kundenspezifische Dokumente
Beim Datenblattportal für Mankiewicz werden nahezu eine Million TDS- und Sicherheitsdatenblätter Produkten und Kunden zugeordnet. Pimcore verwaltet Datenmodell, Dokumentenzuordnung und Berechtigungslogik. Die Authentifizierung erfolgt über ein von Mankiewicz betriebenes Keycloak, das an das Unternehmensverzeichnis angebunden ist. Identitäten und zentrale Sicherheitsrichtlinien bleiben damit in der Verantwortung des Kunden.
Bei Lehmann&Voss erhalten Kunden Zugriff auf kundenspezifische Produktinformationen und Dokumente. SSO mit OpenID, Kundenbeziehungen und nachvollziehbare Dokumentprozesse greifen dabei ineinander.
Beide Beispiele zeigen: Der Login ist nur die Eingangstür. Die eigentliche Sicherheit entsteht durch die korrekte Verbindung von Identität, Kundenbeziehung, Produkt und Dokument.
Wie polargold Rollen und Rechte konzipiert
Wir erfassen nicht nur technische Rollen, sondern reale Organisationen und Verantwortlichkeiten. Gemeinsam mit Fachbereichen, IT und Datenschutz klären wir:
- welche Nutzergruppen existieren,
- in welchem Organisationskontext sie handeln,
- welche Daten und Prozesse geschützt werden,
- wo Identitäten und Kundenbeziehungen geführt werden,
- welche Einladungs- und Freigabeprozesse gelten,
- welche Zugriffe protokolliert werden müssen,
- wie Offboarding und Support funktionieren.
Darauf aufbauend entstehen Rollenmodell, Objektberechtigungen, Identity-Integration und Testszenarien. Kritische Zugriffsregeln werden nicht nur an der Oberfläche geprüft, sondern entlang der gesamten Daten- und API-Schicht.
Fazit
Ein B2B-Kundenportal ist nicht sicher, weil es einen Login besitzt. Es ist sicher, wenn jede Person ausschließlich die Informationen und Handlungen erhält, die zu ihrer Organisation, Rolle und Geschäftsbeziehung passen – und wenn sich diese Rechte verlässlich ändern oder entziehen lassen.
Wer Rollen und Rechte erst kurz vor dem Launch behandelt, muss häufig Datenmodell und Prozesse nachträglich korrigieren. Die richtige Frage gehört daher an den Projektanfang: Welche Person darf in welchem Unternehmenskontext auf welches konkrete Objekt zugreifen – und warum?
Ein sicheres B2B-Kundenportal mit polargold konzipieren
