CAFM: Rollen/Berechtigungen technisch umsetzen

Ein durchdachter Rollenaufbau ist das Fundament des Berechtigungskonzepts. Zunächst werden alle erforderlichen Berechtigungen identifiziert – typischerweise entsprechen diese bestimmten Aktionen (Funktionen) auf bestimmten Ressourcen (Objekten) im System. Diese feingranularen Berechtigungen (oft auch Privileges oder Entitlements genannt) werden zu sinnvollen Rollen zusammengefasst, die einem Jobprofil oder einer Aufgabe entsprechen. Beispielsweise könnte es Rollen geben wie „Gebäudemanager“, „Servicetechniker“, „Helpdesk-Mitarbeiter“ oder „Liegenschaftsverwalter“, die jeweils einen Bündel passender Berechtigungen enthalten. Eine Rolle ist also konzeptionell eine Sammlung von Berechtigungen, die zur Erledigung einer bestimmten Aufgabe nötig sind.

Ergänzend dazu kennt man oft Berechtigungsprofile oder Sichten, welche die Datenzugriffsebenen definieren (dazu im nächsten Abschnitt mehr). In manchen Systemen werden solche Profile separat von den Rollen verwaltet, um etwa regionale Zuständigkeiten oder Mandantengrenzen abzubilden. Ein Benutzerkonto erhält dann i.d.R. eine oder mehrere Rollen (funktionale Rechte) und optional ein Profil (Datenzugriffsbereich). Die Verwaltung erfolgt typischerweise über eine Administrationsoberfläche des CAFM-Systems: Hier können Administratoren neue Rollen anlegen, ihnen Berechtigungen zuweisen und Benutzer den Rollen zuordnen.

Benutzergruppen spielen dabei eine wichtige Rolle, vor allem zur Vereinfachung der Zuweisung. Gruppen können z. B. alle Nutzer einer Abteilung oder eines Standortes umfassen. Durch Zuweisen von Rollen an Gruppen anstatt an Einzelpersonen wird die Administration effizienter – fügt man einen Benutzer einer Gruppe hinzu oder entfernt ihn, erbt er automatisch die entsprechenden Rollen der Gruppe. Oft werden vorhandene Gruppen aus dem Unternehmens-Directory (z. B. AD-Gruppen) mit Rollen verknüpft: So kann etwa die AD-Gruppe „Facilities_Maintenance“ mit der CAFM-Rolle „Servicetechniker“ verknüpft werden. Neue Mitarbeiter der Instandhaltung erhalten dann automatisch die richtige Rolle, sobald sie in der AD-Gruppe sind (siehe dynamische Rollen unten). Wichtig ist eine klare Namenskonvention und Dokumentation der Rollen und Gruppen, damit für Administratoren und Auditoren stets nachvollziehbar bleibt, welche Berechtigungen hinter einem Rollennamen stecken und wer Mitglied welcher Rolle ist.

Die Pflege des Rollenmodells erfordert laufende Aufmerksamkeit: Über die Zeit können Aufgabenprofile sich ändern oder neue Anforderungen entstehen. Daher müssen Rollen gelegentlich angepasst werden. Es empfiehlt sich, Änderungen kontrolliert via Change-Management-Prozess durchzuführen und die Auswirkungen zuvor in einer Testumgebung zu prüfen. So bleibt das Rollenmodell konsistent und wartbar. Generell gilt: Lieber eine überschaubare Anzahl klar definierter Rollen, als ein Wildwuchs an nahezu identischen Rollen für jeden Einzelfall – letzteres führt zur gefürchteten Rollenexplosion, die die Verwaltung unübersichtlich macht. Daher sollten Rollen eher allgemeiner gefasst und mit zusätzlichen Profilen/Filtern spezialisiert werden, anstatt für jede Variation eine völlig neue Rolle zu definieren.

Ein gutes Berechtigungskonzept bietet verschiedene Granularitätsebenen, um genau festzulegen, wer was tun darf und was er sehen darf.

• Funktionsberechtigungen (funktionale Rechte): Diese betreffen welche Aktionen oder Module ein Benutzer nutzen darf. Beispielsweise könnte die Rolle „Helpdesk“ die Funktion „Ticket erstellen“ und „Ticket bearbeiten“ haben, während die Rolle „Berichtsauswertung“ Zugriff auf das Reporting-Modul gewährt. Funktionsberechtigungen steuern Menüpunkte, Buttons und Aktionen in der Anwendung. Ein Nutzer ohne eine bestimmte Funktionsberechtigung sieht z. B. das entsprechende Modul gar nicht oder der Menüpunkt ist ausgegraut. Dadurch wird sichergestellt, dass niemand in Bereiche der Software navigieren kann, für die er keine Befugnis hat.

• Objektberechtigungen (Daten- oder Objektzugriff): Darüber wird geregelt, auf welche Datenobjekte (z. B. Standorte, Gebäude, Anlagen, Verträge) sich die Rechte erstrecken. Ein typisches Beispiel ist die territoriale oder organisatorische Abgrenzung: Ein Regionalleiter darf nur die Objekte seiner Region sehen/bearbeiten, nicht aber die anderer Regionen. Im CAFM-Kontext könnte man Objektberechtigungen so einrichten, dass z. B. ein Facility Manager nur für bestimmte Liegenschaften oder Kostenstellen zuständig ist. Technisch kann dies durch Filter oder Berechtigungsprofile umgesetzt werden. So berichtet ein Anbieter, dass in seinem System sogenannte Authorization Profiles genutzt werden, um die Sichtbarkeit von Daten auf z. B. bestimmte Unternehmen oder Geschäftsbereiche einzuschränken. Ein Profil könnte z. B. definieren „Nutzer X sieht nur Objekte des Standorts Berlin und Hamburg“ oder „Techniker Y darf nur Aufträge der Abteilung Z bearbeiten“. Objektberechtigungen greifen oft auf Attribute der Datensätze zurück (z. B. Feld „Standort=Berlin“) und filtern Daten basierend darauf.

• Sichtbarkeiten (UI- und Feldebene): Feingranulare Kontrolle kann bis auf die Ebene einzelner Datenfelder oder UI-Elemente reichen. Besonders bei sensiblen Daten kann es nötig sein, Teile der Informationen auszublenden oder zu maskieren. Ein Beispiel: Ein externes Wartungsteam darf zwar die Störungsmeldungen sehen, aber keine personenbezogenen Daten des meldenden Mitarbeiters. Oder in einem Vertragsverwaltungsmodul werden Kreditkartennummern nur gekürzt (letzte 4 Stellen) angezeigt. Sichtbarkeitsrechte sorgen dafür, dass selbst innerhalb eines angezeigten Datensatzes nur das preisgegeben wird, was für die Rolle erforderlich ist. Ebenso kann darüber gesteuert werden, ob ein Feld nur lesbar oder auch editierbar ist.

Ein Benutzer bekommt nur die Funktionen angeboten, die er benötigt, nur Zugriff auf die Datensätze, für die er zuständig ist, und sieht nur die Details, die für seine Arbeit relevant sind. Die technische Umsetzung erfolgt meist über eine Kombination aus Backend- und Frontend-Logik: Das Backend prüft bei Datenabfragen die Objektberechtigungen (z. B. mittels WHERE-Klauseln auf Mandanten- oder Standort-IDs), während das Frontend UI-Elemente basierend auf Funktionsrechten ein- oder ausblendet. Wichtig ist, dass das Backend als letzte Instanz immer die Autorisierung erzwingt – UI-Ausblendungen allein sind nicht sicher genug, da findige Benutzer eventuell URLs erraten oder versteckte Felder sichtbar machen könnten. Daher gilt: Server-seitig muss jede Aktion und Datenabfrage nochmals gegen die Berechtigungen validiert werden.

Viele CAFM- und IWMS-Systeme müssen mandantenfähig sein, d. h. entweder mehrere Kunden innerhalb einer Instanz bedienen (SaaS-Szenario) oder getrennte Organisationseinheiten eines Konzerns (Multi-Org-Szenario) abbilden. Ein robustes Rollen- und Rechtekonzept muss daher organisationsspezifische Trennung gewährleisten. Praktisch heißt das: Keine Daten einer Organisation dürfen für Benutzer einer anderen Organisation einsehbar oder änderbar sein, sofern nicht gewollt. Die Autorisierungsentscheidungen müssen immer tenant-aware sein – bei jedem Zugriff wird geprüft, ob der Benutzer innerhalb dieses Mandanten/Unternehmens die geforderte Rolle hat. Ein Benutzer kann z. B. Admin in Mandant A, aber nur Leser in Mandant B sein; diese Kontexte müssen strikt getrennt gehalten werden.

Es gibt verschiedene Herangehensweisen, Rollen in einem Multi-Tenant-System zu modellieren. Eine Möglichkeit sind globale Rollen mit mandantenspezifischer Zuweisung: Dabei sind die Rollendefinitionen systemweit gültig (z. B. Rollen "Admin", "Editor", "Viewer"), aber die Zuweisung User→Rolle wird je Mandant gespeichert. Ein User kann also pro Mandant unterschiedliche Rollen haben (oder keine). Dieses Modell ist einfach, aber weniger flexibel, wenn jeder Mandant eigene Spezialrollen will. Die maximale Flexibilität bietet der Ansatz Mandanten-spezifischer Rollen: Hier hat jeder Mandant seinen eigenen Satz von Rollen (sein eigenes "Namensschema"), und Berechtigungen können pro Mandant anders definiert sein. Das erlaubt es beispielsweise, dass Mandant A eine Rolle "Objektbetreuer" definiert, die es in Mandant B gar nicht gibt. Allerdings erhöht dies den Verwaltungsaufwand erheblich, da Rollen nicht mehr zentral vorgehalten werden.

In jedem Fall muss die Softwarearchitektur garantieren, dass keine berechtigungsübergreifenden Zugriffe stattfinden. Idealerweise wird auf Datenebene mit einem Mandantenidentifier gearbeitet, der in allen relevanten Tabellen vorhanden ist, und sämtliche Abfragen filtern standardmäßig auf den Mandanten. Zusätzlich sollten Rollenprüfungen immer den Mandantenkontext berücksichtigen (z. B. Rolle "Manager" in welchem Mandanten?). Ein gut gestaltetes Multi-Tenant RBAC-Modell stellt sicher, dass keinerlei Cross-Tenant-Zugriffe möglich sind, dass Rollenzuweisungen stets tenant-scoped erfolgen und dass selbst bei Mandanten-spezifischen Anpassungen die Zugriffskontrolle beherrschbar und debug-fähig bleibt. Für SaaS-Anbieter wird empfohlen, Mandantentrennung als Sicherheitsmerkmal zu behandeln – eine fehlerhafte RBAC-Implementierung hier kann zu kritischen Datenlecks führen. Deshalb gehört die Mandantenfähigkeit von Anfang an ins Berechtigungsdesign, indem z. B. Mandanten als zusätzlicher Parameter in den Berechtigungsprüfungen verankert werden.

In vielen Fällen hängen Berechtigungen von Organisationshierarchien oder Standortstrukturen ab. Beispielsweise hat ein Leiter Facility Management vielleicht automatisch Zugriff auf alle Gebäude, die seinen unterstellten Facility Managern zugeordnet sind. Oder ein Bereichsleiter darf die Daten aller Abteilungen einsehen, die seinem Bereich untergeordnet sind. Solche hierarchischen Berechtigungen lassen sich mit RBAC durch Rollenhierarchien modellieren: Eine übergeordnete Rolle erbt die Berechtigungen von untergeordneten Rollen. Ein klassisches Beispiel: Die Rolle „Manager“ beinhaltet alle Rechte der Rolle „Mitarbeiter“ plus zusätzliche Führungsrechte. Technisch werden hierbei Rollen so verknüpft, dass z. B. bei der Berechtigungsprüfung die Rechte aller untergeordneten Rollen mit berücksichtigt werden, wenn ein Benutzer eine höhere Rolle innehat. Dadurch muss man z. B. nicht Rechte doppelt pflegen – Änderungen an der Mitarbeiter-Rolle wirken automatisch auch für Manager. Wichtig: Rollenhierarchien sollten gezielt und sparsam eingesetzt werden, um die Nachvollziehbarkeit nicht zu verlieren. Außerdem müssen Regeln zur Trennung von Aufgaben (Segregation of Duties, SoD) beachtet werden: Kein Benutzer sollte zwei Rollen kombinieren können, die zu einem Interessenkonflikt führen (z. B. Rechnungssteller und Rechnungsprüfer zugleich). Hier können Hierarchien oder Constraints im Rollensystem solche Konflikte von vornherein ausschließen.

Neben organisatorischen Hierarchien spielen auch Standort- oder objektbezogene Hierarchien eine Rolle. Ein CAFM-System könnte z. B. eine Baumstruktur von Standorten, Gebäuden, Etagen, Räumen haben. Häufig wünscht man, dass Rechte auf übergeordneten Ebenen automatisch auch für alle Untereinheiten gelten. Dies ähnelt dem hierarchischen Rollenmodell, kann aber auch über dynamische Filter gelöst werden (siehe nächster Abschnitt). Beispielsweise könnte man definieren, dass ein „Standortleiter“ Zugriff auf alle Gebäude unter diesem Standort hat, ohne dass jedem Gebäude separat eine Berechtigung zugewiesen werden muss. In manchen IAM-Systemen gibt es dafür das Konzept dynamischer Rollen in Organisationsbäumen: Eine Rolle kann an einem Knoten der Organisationsstruktur verankert werden und gilt dann für alle Benutzer in diesem Knoten bzw. optional auch in allen Unterknoten. So könnte eine dynamische Rolle „Techniker@StandortA“ allen technischen Mitarbeitern unter Standort A zugewiesen werden. Verschiebt man einen Benutzer in der Organisationshierarchie, kann er dadurch automatisch andere dynamische Rollen erhalten (weil er nun in einem anderen Zweig des Baumes ist).

Für die Praxis bedeutet dies: Bei der Rechtekonzeption sollte man organisatorische Hierarchien abbilden, entweder durch Rollenvererbung oder durch entsprechende Datenfilter. Häufig werden Standort-IDs oder Organisations-IDs im Benutzerprofil hinterlegt, um bei Datenzugriffen einen Filter zu setzen. Alternativ kann man je Standort eigene Rollen definieren (z. B. „FM-Manager Berlin“, „FM-Manager Hamburg“ etc.). Diese sind simpel, führen aber bei vielen Standorten schnell zu einem großen Rollen-Set. Flexibler ist es oft, Rollen und Datenkontext zu trennen: eine allgemeine Rolle „FM-Manager“ plus ein Datenfilter Standort=Berlin (ähnlich dem oben erwähnten Berechtigungsprofil) ergibt dann effektiv die Rechte eines Berliner FM-Managers. Viele CAFM-Systeme bieten hierfür konfigurierbare Filtermöglichkeiten auf Basis von Standort- oder Organisationsattributen, sodass man keine redundanten Rollen für jeden Kontext erstellen muss. Entscheidend ist, die Hierarchie- und Standortabhängigkeiten sauber zu dokumentieren und im System zu parametrieren, damit z. B. bei Umstrukturierungen (neue Standorte, Abteilungen) klar ist, wie sich das auf die Berechtigungen auswirkt.

Nicht alle Berechtigungszuweisungen müssen manuell erfolgen – moderne IAM- und CAFM-Lösungen erlauben auch die dynamische Rollenvergabe basierend auf Benutzerattributen. Das bedeutet, ein Benutzer erhält automatisch bestimmte Rollen, wenn er bestimmte Kriterien erfüllt. Ein gängiges Beispiel: Rollen basierend auf der Organisationszugehörigkeit. Ist im Benutzerprofil hinterlegt, dass die Person zur Abteilung „Haustechnik“ gehört, kann das System automatisch die Rolle „Servicetechniker“ vergeben. Ändert sich die Abteilung des Mitarbeiters, so entzieht das System die alte Rolle und gibt ggf. neue rollen basierend auf der neuen Abteilung.

Technisch gibt es hier verschiedene Ansätze. In einigen Systemen spricht man von dynamischen Rollen oder automatischen Rollen, die über Regeln oder Filter definiert sind. Beispielsweise könnte eine dynamische Rolle „Alle Mitarbeiter der Organisationseinheit X“ definieren. Die Regel dahinter könnte ein LDAP-Filter sein (z. B. Abteilung = X im Benutzerobjekt). Jeder Benutzer, der dieses Kriterium erfüllt, wird automatisch Mitglied dieser Rolle – ohne dass ein Administrator eingreifen muss. In einer hierarchischen Organisationsstruktur kann man den Geltungsbereich solcher dynamischen Rollen oft wählen, z. B. nur für einen Knoten oder inklusive aller Unterknoten. So könnte eine dynamische Rolle „HR-Berechtigte@Bereich A“ für Bereich A und alle Unterabteilungen gelten, basierend auf einem Filter, der alle Benutzer mit Attribut „Abteilung=A*“ einschließt.

Neben der Abteilung lassen sich auch andere Benutzerattribute heranziehen: Standort, Stellenbezeichnung, Kostenstelle, Projekttätigkeit, etc. Im Prinzip nähert man sich hier dem Konzept der Attributbasierten Zugriffskontrolle (ABAC. Während RBAC fixe Rollen hat, erlaubt ABAC die dynamische Berechnung von Berechtigungen auf Basis von Attributen des Benutzers, des Objekts oder der Umgebung (z. B. Uhrzeit, Gerätetyp). Viele Systeme nutzen einen hybriden Ansatz: RBAC bildet die Grundstruktur (die "statischen" Rechte pro Rolle), und ABAC-ähnliche Regeln verfeinern dies dynamisch. Ein Beispiel: Die Rolle „Wartungstechniker“ gibt grundsätzlich die Fähigkeit, Wartungsaufträge zu bearbeiten, aber ob ein konkreter Auftrag zugreifbar ist, hängt vom Attribut Standort ab, das dynamisch abgeglichen wird (Auftrag.Standort = User.Standort).

Die Integration ins System erfolgt meist über das Identity Management: Entweder unterstützt das CAFM-System intern solche Regeln, oder die Zuweisung wird vom übergeordneten IDM-System gesteuert, welches Benutzer aufgrund ihrer Attribute in die richtigen Gruppen/Rollen einsortiert. So kann z. B. ein HR-IAM-System (Identity Governance) bei Onboarding eines neuen Mitarbeiters automatisch die benötigten Rollen vergeben, basierend auf Stammdaten wie Position und Organisationseinheit. Der Vorteil dynamischer Rollen ist eine deutliche Reduzierung des Administrationsaufwands und Konsistenz – menschliche Fehler beim Zuweisen werden vermieden, und Berechtigungen bleiben aktueller (z. B. entfallen automatisch, wenn ein Attribut nicht mehr zutrifft, wie bei Abteilungswechsel). Allerdings muss das Regelwerk gut getestet werden, um zu vermeiden, dass falsche Zuordnungen passieren. Außerdem ist Transparenz wichtig: Es sollte für Administratoren sichtbar sein, welche Rollen dynamisch vergeben wurden und aufgrund welcher Regel, um die Nachvollziehbarkeit zu gewährleisten.

Die Benutzerverwaltung ist eng mit dem Rollen- und Rechtekonzept verzahnt. Es gibt grundsätzlich zwei Ansätze: Entweder werden Benutzerkonten manuell im CAFM-System gepflegt (inklusive ihrer Rollen), oder es erfolgt eine Anbindung an ein zentrales Identity Management des Unternehmens, das die Benutzer und ggf. auch Berechtigungen synchronisiert.

In kleineren Umgebungen oder zu Beginn einer Einführung wird man oft Benutzer direkt im CAFM/IWMS anlegen. Ein Administrator erstellt ein neues Nutzerkonto, vergibt einen Login (oder verwendet die Firmen-E-Mail) und weist initiale Rollen zu. Änderungen (z. B. zusätzliche Rolle, Deaktivierung bei Austritt) müssen dann ebenfalls manuell im System erfolgen. Dies ist überschaubar, solange die Nutzerzahl gering ist. Mit wachsender Organisation kann das aber unübersichtlich und fehleranfällig werden – hier empfiehlt sich die Anbindung eines Identity Management Systems (IDM). Moderne Systeme wie z. B. One Identity Manager oder Azure AD erlauben, Benutzerinformationen und Gruppenzugehörigkeiten an angebundene Applikationen zu verteilen. So könnte z. B. jede Nacht ein Sync laufen, der neue Mitarbeiter aus dem HR-System im CAFM als Benutzer anlegt, bestimmte Attribute (Name, E-Mail, Abteilung) überträgt und ggf. gleich die passenden Rollen oder Gruppen zuordnet.

Eine häufige Praxis ist die Integration mit LDAP/AD (Active Directory). Das CAFM-System wird dabei an das Active Directory angebunden, sodass Benutzer sich mit ihren Windows- bzw. Domänen-Credentials anmelden können. Je nach System kann man AD-Gruppen direkt als Rollen importieren oder abbilden. Eine Möglichkeit: Man erstellt in AD spezielle Sicherheitsgruppen wie „CAFM_Admin“, „CAFM_FMManager“, „CAFM_Technik“ usw., und konfiguriert im CAFM eine Zuordnung dieser AD-Gruppen zu internen Rollen. Sobald ein Mitarbeiter in AD der Gruppe „CAFM_Technik“ hinzugefügt wird, erhält er automatisch die entsprechende Rolle im CAFM (über LDAP-Abfrage oder Synchronisation). Dies reduziert den Pflegeaufwand erheblich, da die Quellsysteme (z. B. AD oder Azure AD) als Single Source of Truth für Benutzer dienen. Das CAFM muss in diesem Fall nicht mehr wissen, welcher Benutzer wo arbeitet – es erhält die relevanten Attribute und Gruppenzugehörigkeiten vom Directory. Oft werden solche Anbindungen über Standardprotokolle umgesetzt, z. B. über LDAP-Bind (für Authentifizierung) und SCIM oder CSV-Importe (für Benutzer-Provisionierung).

Wichtig bei der Integration externer Identity Stores ist die Konsistenz der IDs: Jeder Benutzer im CAFM sollte eindeutig mit einem Directory-Benutzer korrespondieren (z. B. gleicher Username oder eine ID). Bei manchen Systemen wird das via Federation (SSO) gelöst (siehe nächster Abschnitt), bei anderen durch regelmäßige Importe. Ein weiterer Aspekt ist die Deprovisionierung: Wenn ein Mitarbeiter das Unternehmen verlässt und im zentralen Verzeichnis deaktiviert oder gelöscht wird, muss dies zeitnah auch im CAFM wirken (Account sperren, Rollen entziehen). Hier zahlt sich eine IDM-Anbindung aus – ein gutes IDM-System schließt Berechtigungslücken, indem es verwaiste Accounts entfernt und temporäre Zugänge widerruft. Man sollte ferner definieren, wer die Hoheit über die Rollen hat: Werden Rollen komplett im CAFM verwaltet, oder im IDM? Oft ist es eine Mischung: Das IDM kennt geschäftliche Rollen (Business Roles) und weist sie zu; diese werden im CAFM auf technische Rollen gemappt.

Es stehen drei Modelle zur Verfügung: 1. Manuelle Pflege im CAFM: direkt in der Anwendung Benutzer anlegen/ändern, Rollen zuweisen. 2. Verzeichnisdienst-Anbindung (LDAP/AD): Benutzer authentifizieren gegen AD, optional Gruppenmapping auf Rollen. 3. Identity Management Integration (IAM/IDM): Zentrales System (z. B. Azure AD, One Identity, SAP IDM) verwaltet den Lebenszyklus der Benutzer und speist Daten + Rollen ins CAFM ein.

Die Wahl hängt von der Unternehmensgröße und IT-Strategie ab. In vielen Fällen ist heute die Identity-Integration bevorzugt, um Redundanz zu vermeiden und Single Sign-On zu ermöglichen.

Die Kopplung des CAFM-Systems mit bestehenden Identity- und Access-Management-Lösungen (IAM) ist ein entscheidender Erfolgsfaktor bei der Einführung. Gängige IAM-Systeme sind z. B. Azure AD (Microsoft Entra ID), Keycloak (Open Source), Okta, ForgeRock, u.a.

• Authentifizierung via SSO: Anstatt eigene Benutzerkonten zu pflegen, verlässt sich das CAFM auf den externen IdP (Identity Provider). Der Benutzer meldet sich z. B. über Azure AD oder Keycloak an, und das CAFM übernimmt den vom IdP bestätigten Identitätsnachweis (oft über SAML oder OpenID Connect). Dies wird im nächsten Abschnitt ausführlicher beschrieben.

• Übernahme von Rollen/Zugehörigkeiten: Manche IAM-Systeme können im Token oder SAML-Assertion bereits Rolleninformationen mitschicken. Beispielsweise lässt sich in Azure AD sogenannte App-Roles definieren, die dem Benutzer im Token als Claim roles oder groups mitgegeben werden. Das CAFM-System kann diese auslesen und auf interne Rollen abbilden. Ein realer Ansatz: Die Unternehmens-IdP sendet beim Login eine SAML-Assertion, die die Nutzerrollen enthält; diese werden im Cloud-Service des CAFM auf vordefinierte Anwendungsrollen gemappt. Damit ist beim ersten Login bereits klar, welche Rechte der User haben soll – das System ordnet ihn automatisch den richtigen Rollen zu.

• Provisionierung via IAM: In einem Szenario mit vorgelagertem IAM kann die Erstellung von Benutzern und Zuweisung von Rollen vollständig vom IAM-System gesteuert werden. Lösungen wie SCIM (System for Cross-domain Identity Management) ermöglichen es, dass sobald im Zentral-IAM ein Nutzer einer bestimmten Rolle zugeordnet wird, das CAFM diese Information empfängt und den Nutzer anlegt bzw. aktualisiert. Ebenso kann bei Entzug einer Rolle im IAM diese im CAFM entzogen werden. Dies setzt voraus, dass das CAFM entsprechende APIs für Provisionierung bietet.

Ein konkretes Beispiel liefert ein Softwareanbieter: Dessen Cloud-Plattform weist alle Rollen über Single Sign-On zu; Kunden schicken SAML-Assertions mit den User-Rollen, die dann zu den vorkonfigurierten Software-Rollen gemappt werden. Für granularere Kontrolle kann zusätzlich ein eigenes Identity & Access Management Modul (hier: Nakisa Identity & Access Management) integriert werden, das auf Standards wie SAML aufbaut und z. B. Keycloak nutzt. Dieses Modul übernimmt das User Provisioning und die Authentifizierung, stellt sicher, dass Rollen und Profile korrekt zugewiesen werden, und erlaubt sogar zeitlich befristete Zugriffsrechte und Rollenkombinationen für flexible Zugriffssteuerung.

Wichtig bei jeder IAM-Integration ist die Konsistenz der Rollenbegriffe: Man sollte klar definieren, welche Rollen im zentralen IAM existieren und wie sie auf die feineren Applikationsrechte abgebildet werden. Oft wird man im IAM eher geschäftliche Rollen führen (wie „Hausmeister“), die dann im CAFM möglicherweise in mehrere technische Rollen (für verschiedene Module) aufgeteilt werden. Hier bietet es sich an, ein Rollenkonzept-Dokument zu erstellen, das die Mappings beschreibt.

Zudem muss die Synchronisation der Identitäten sichergestellt sein: Entweder On-Demand beim Login via Token-Claims oder periodisch via API. Wird SSO benutzt, muss das CAFM dennoch einen Benutzerdatensatz anlegen (meist beim ersten Login, Just-in-Time-Provisionierung) – dabei können vom IdP gelieferte Attribute wie Name, E-Mail, Abteilung gespeichert werden. Wenn das CAFM die Rollen nicht direkt vom IdP erhält, muss man ggf. einen Connector implementieren, der Änderungen im IAM (z. B. neue Zuweisung der Person X zur Rolle Y) ans CAFM meldet.

Insgesamt erleichtert eine IAM-Integration die Administration, erhöht die Sicherheit (da zentrale Policies für Passwort, MFA, Account-Sperren greifen) und verbessert die User Experience (ein Login für alle Systeme). Allerdings erfordert die Einrichtung gründliche Tests, ob alle relevanten Rollen und Attribute korrekt übertragen und interpretiert werden. Insbesondere Sonderfälle (temporäre Rollen, Delegationen) müssen bedacht werden, ob sie im IAM oder im CAFM gepflegt werden.

Single Sign-On (SSO) ermöglicht es Benutzern, sich einmalig anzumelden und anschließend nahtlos auf das CAFM-System (und andere Anwendungen) zuzugreifen, ohne jede Applikation separat zu authentifizieren. Im Kontext eines CAFM-Projekts bedeutet SSO meist, dass das System als Service Provider (SP) in eine Föderation eingebunden wird. Der Identity Provider (IdP) – beispielsweise Azure AD, Keycloak oder ADFS – übernimmt die Authentifizierung des Users (über Passwort, Zertifikat, MFA etc.), und das CAFM vertraut auf dieses Prüfergebnis. Technisch wird dies üblicherweise via SAML 2.0 oder OAuth2/OpenID Connect (OIDC) realisiert. SAML 2.0 ist ein XML-basiertes Föderationsprotokoll, das häufig in Unternehmensumgebungen genutzt wird. Hier initiiert das CAFM (SP) einen Authn-Request, der User wird ans IdP weitergeleitet, meldet sich dort an, und der IdP schickt eine SAML-Response mit einem Assertion-Ticket zurück, das die Identität (und oft Attribute wie Name, E-Mail, Gruppen/Rollen) beinhaltet. Das CAFM prüft die Signatur dieser Assertion und erstellt eine Session für den Benutzer.

OAuth2 mit OpenID Connect ist eine modernere, JSON/REST-basierte Variante. Hier holt sich das CAFM-System (bzw. dessen Backend oder ein Javascript-Client) nach einer Weiterleitung ein ID-Token und Access-Token vom IdP. Das ID-Token (meist ein JWT) enthält die User Identity und ggf. Rollen in seinen Claims. OAuth2/OIDC wird vermehrt verwendet, insbesondere für Web- und mobile Apps, da es leichter mit modernen Libraries zu implementieren ist. Es bietet zudem Konzepte wie Scopes (Gültigkeitsbereiche für Tokens), die man mit dem RBAC-Modell verbinden kann: So könnte man definieren, dass ein Access-Token mit Scope „cafm:maintenance“ nur API-Zugriff auf den Wartungsbereich erlaubt, passend zur Rolle des Users.

Wichtig zu verstehen ist, dass SSO die Authentifizierung zentralisiert, aber die Autorisierung (RBAC) weiterhin in der Anwendung umgesetzt werden muss. OAuth2 bzw. OIDC regeln wer ein Nutzer ist (und evtl. was seine Gruppen/Rollen sind) – was er im System tun darf, entscheidet die RBAC-Logik. Ein Access-Token allein garantiert noch keine feingranularen Berechtigungen. Deshalb ist es Best Practice, SSO mit RBAC zu kombinieren, um echte Sicherheit zu erreichen. OAuth2 liefert den Schlüssel, RBAC bestimmt die Tür, die geöffnet werden darf. Ohne RBAC könnte ein OAuth-Token theoretisch Zugang zu Daten gewähren, die der Benutzer gar nicht sehen sollte. Durch die Abbildung von Token-Informationen auf Rollen sorgt man dafür, dass die Berechtigungsprüfungen im System weiterhin greifen. In vielen Szenarien werden Token-Scopes mit Rollen in Beziehung gesetzt: z. B. das Vorhandensein eines bestimmten Scopes im Token setzt eine bestimmte Rolle voraus.

Für das CAFM-Projekt bedeutet dies: Man richtet auf dem IdP eine Vertrauensstellung für die CAFM-Anwendung ein (SAML oder OIDC Client). Benutzer, die sich am IdP erfolgreich anmelden, gelangen ins System. Die Session des CAFM enthält dann entweder direkt die Rollen (aus dem Token extrahiert) oder zumindest die eindeutige User-ID, über die dann intern die Rollen geladen werden. Mit SSO entfällt also die separate Passwortverwaltung im CAFM, was Aufwand spart und die Security erhöht (einheitliche Passwort-Policy, MFA, schnelle Reaktion bei kompromittierten Accounts zentral möglich). Auch für mobile Apps des CAFM kann SSO genutzt werden, oft in Form von OIDC: Die App öffnet einen Browser zur IdP-Anmeldeseite (oder nutzt App-Auth-Frameworks), erhält ein Token und benutzt dieses für API-Calls.

SSO über SAML 2.0 oder OAuth2/OIDC ist heute quasi Standard bei größeren Einführungsvorhaben. Es bietet einheitliche Anmeldung und ermöglicht dem CAFM-System, sich auf sein Kerngeschäft (Facility-Datenverwaltung) zu konzentrieren, während die komplexen Authentifizierungsfragen vom IdP gehandhabt werden. In der Praxis sollte man die SSO-Integration gründlich testen (Stichwort: verschiedene Benutzerrollen, Token Refresh, Logout) und darauf achten, dass eventuelle Rollen-Claims korrekt interpretiert werden. Zudem muss es einen Fallback geben, wenn der IdP mal nicht verfügbar ist – z. B. einen technischen Admin-Notlogin lokal, damit man im Notfall das System administrieren kann.

Die Nutzung eines CAFM-Systems ist heute oft nicht auf die Desktop-Weboberfläche beschränkt – mobile Apps für Techniker oder Manager sowie API-Schnittstellen für Integrationen spielen eine wichtige Rolle. Das Rollen- und Berechtigungskonzept muss deshalb auch in diesen Kontexten durchgängig greifen.

Für mobile Anwendungen gilt: Sie sind letztlich Clients, die über Webservices mit dem Backend kommunizieren. Somit müssen mobile Apps die gleiche Authentifizierung und Autorisierung durchlaufen wie andere Clients. In der Praxis wird häufig OAuth2/OIDC eingesetzt: Der mobile Client erhält nach SSO-Login ein Access-Token, das er bei jedem API-Aufruf mitgibt. Das Backend validiert dieses Token (ggf. prüft Signatur, Gültigkeit beim IdP) und extrahiert daraus die User-Identität sowie evtl. enthaltene Rollen/Scopes. Anschließend gelten die üblichen RBAC-Prüfungen serverseitig für die angeforderte Operation. Wichtig ist, dass keine gesonderten „Hintertüren“ für mobile Clients existieren – z. B. sollte ein mobiler Endpunkt für Auftrag abschließen exakt dieselbe Berechtigungsprüfung durchführen wie die Weboberfläche, die denselben Auftrag abschließt.

Eine Herausforderung ist oft die Benutzerfreundlichkeit vs. Sicherheit bei mobilen Apps: Man möchte den Technikern z. B. offline Zugriff auf bestimmte Daten geben. Dann müssen ggf. Daten auf dem Gerät zwischengespeichert werden. Hier ist zu beachten, dass die Berechtigungen trotzdem respektiert werden – etwa indem die App nur die für den Benutzer relevanten Datensätze vorlädt (serverseitig gefiltert nach seinen Rechten). Falls der Benutzer online die Rechte ändert (z. B. er verliert eine Rolle), müssten im Idealfall auch die gecachten Offline-Daten entsprechend eingeschränkt werden, was jedoch technisch komplex ist. Daher sollte man Offline-Funktionalität auf das Nötigste begrenzen und klar definieren.

Für APIs (etwa REST/GraphQL-Schnittstellen) gilt ähnliches. Oft werden APIs von Drittsystemen oder Integrationsprozessen genutzt. Hier stehen zwei Ansätze zur Verfügung: 1. Benutzergebundene API-Nutzung: Ein externer Aufruf erfolgt im Namen eines konkreten Benutzers (z. B. via OAuth2 Authorization Code Flow im Kontext eines Users). In diesem Fall trägt das Token alle Rollen dieses Users, und die API setzt exakt dieselben Berechtigungschecks um. Beispiel: Eine mobile App lässt einen Manager per API einen Raum buchen – das Token des Managers wird geschickt, Backend prüft, ob er die Rolle zum Buchen hat. 2. Anwendungs-/Dienstkonten: Manchmal rufen Fremdsysteme APIs ohne einen menschlichen Nutzer an (z. B. ein IoT-System meldet Sensordaten ins CAFM). Hier verwendet man meist Client-Credentials-Flow mit einem technischen Account. Auch solche Service-Accounts sollten Rollen besitzen, die deren API-Rechte limitieren. Beispielsweise ein Service-Account „SensorImport“ hat nur die Berechtigung, Messwerte zu schreiben, aber keine Lese- oder Löschrechte.

Wichtig ist das Konzept der Scopes: In OAuth2 können Access-Tokens bestimmte scopes tragen, die angeben, auf welche API-Bereiche das Token zugreifen darf. Man sollte diese Scopes möglichst mit dem RBAC verzahnen oder zumindest konsistent halten. So verhindert man, dass ein Token mit einem breiten Scope „admin_all“ verwendet wird, wenn der Client eigentlich nur lesen dürfte. Die Empfehlung lautet: Scopes sauber definieren und klein halten, z. B. getrennte Scopes für Lesen und Schreiben je Modul, und dem aufrufenden Client nur die benötigten Scopes zuteilen. Dann kann im Backend pro Endpoint sowohl die Benutzerrolle als auch der Token-Scope geprüft werden (beliebte Frameworks wie ASP.NET Core, Spring Security etc. unterstützen solche Autorisierungs-Policies).

Zusätzlich sollte das Berechtigungssystem API-Aufrufe protokollieren (siehe Audit-Abschnitt), insbesondere wenn es um schreibende Zugriffe geht. So kann auch für Integrationen nachvollzogen werden, welche Anwendung wann welche Daten geändert hat. Für APIs, die öffentlich oder firmenweit genutzt werden, empfiehlt sich zudem eine Rate-Limiting und eine strikte Authentifizierung (z. B. kurzer Token-Lebenszyklus, Einsatz von MTLS oder API-Gateways), um Missbrauch einzudämmen.

Die Berechtigungskonfiguration muss Client-agnostisch sein – egal ob Web-Frontend, Mobile App oder API-Caller, die gleiche serverseitige Autorisierungslogik validiert alle Zugriffe. Standards wie OAuth2 helfen dabei, diese Einheitlichkeit zu wahren. Durch sorgfältige Vergabe von Rollen und Token-Scopes stellt man sicher, dass kein Client unberechtigterweise mehr sieht oder tun kann als vorgesehen, und dass mobile Nutzer ebenfalls im Rahmen ihrer Rolle agieren.

Ein zentrales Ziel eines Rollen- und Berechtigungskonzepts ist die Einhaltung von Datenschutz und Sicherheitsrichtlinien. Dazu gehört in erster Linie das Prinzip des geringstmöglichen Privilegs (Least Privilege): Jeder Benutzer soll nur die Zugriffsrechte erhalten, die für seine Aufgaben unbedingt notwendig sind. Durch RBAC lässt sich dieses Prinzip effektiv umsetzen und überprüfen. Überberechtigungen einzelner Mitarbeiter werden vermieden, indem Zugriffsrechte ausschließlich über definierte Rollen vergeben und streng nach Bedarf zugeteilt werden. Dies trägt direkt zur DSGVO-Forderung nach Datenminimierung und Vertraulichkeit bei, da kein Unbefugter auf personenbezogene oder vertrauliche Informationen zugreifen kann. RBAC unterstützt auch die Nachweisführung: Bei Audits kann klar dargelegt werden, welcher Personenkreis zu sensiblen Daten Zugang hat.

Ein weiterer Aspekt ist “Security by Design” bzw. “Data Protection by Design”. Schon bei der Konzeption des CAFM-Systems müssen Datenschutzanforderungen berücksichtigt werden. Das Rollenmodell ist hier ein Werkzeug, um von Anfang an Schutzmechanismen zu implementieren. Beispielsweise kann man vordefinierte Datenschutzrollen einführen, die regeln, wer auf besonders schützenswerte Daten zugreifen darf (z. B. eine Rolle Datenschutzbeauftragter mit Einsichtsrechten in alle Protokolle). Auch können manche Daten durch das Rollenmodell standardmäßig ausgeblendet werden (wie bereits erwähnt, z. B. Maskierung von personenbezogenen Feldern), wodurch das System Privacy by Default liefert – der Standardzustand ist der datenschutzfreundlichste, weitergehende Zugriffe müssen explizit gewährt werden.

Zur Sicherheit gehört ebenfalls die Trennung von Zuständigkeiten (Segregation of Duties): RBAC kann so gestaltet sein, dass es keine toxischen Rollen-Kombinationen gibt (z. B. jemand kann Rechnungen erstellen und freigeben). Solche SoD-Konflikte sollten in der Berechtigungsmatrix identifiziert und durch Rollentrennung vermieden werden. Manche IAM-Systeme oder Governance-Tools bieten Funktionen, um SoD-Prüfungen durchzuführen, bevor man Rollen vergibt – das ist besonders in regulierten Branchen (Banken, Pharma) wichtig.

Ein weiterer Punkt ist die Absicherung von Admin-Rechten. Administrator-Rollen sollten nur einem sehr kleinen Personenkreis vorbehalten sein, idealerweise technischen Administratoren, nicht regulären Fachanwendern. Hier kann das Least Privilege Prinzip erweitert werden: selbst Administratoren arbeiten möglichst mit zwei Accounts – ein normaler User-Account für tägliche Arbeiten (mit begrenzten Rechten) und ein Admin-Account für Systemänderungen. So wird verhindert, dass ein Admin aus Versehen oder unbemerkt dauerhaft mit sehr hohen Rechten operiert.

Auch Passwortrichtlinien und MFA spielen in den Datenschutz/Security-Kontext hinein, auch wenn sie primär die Authentifizierung betreffen. Da aber oft SSO integriert wird, müssen diese Policies auf IdP-Seite implementiert sein. Das CAFM-Team sollte sicherstellen, dass die Identity-Provider starke Authentisierungsmethoden erzwingen (z. B. MFA für kritische Rollen) und dass vielleicht sogar kontextsensitive Zugriffsrichtlinien bestehen (z. B. Zugriff auf CAFM-Daten außerhalb des Firmennetzes erfordert MFA oder wird untersagt).

Nicht zuletzt muss das Berechtigungskonzept regelmäßig überprüft werden, um neuen Bedrohungen oder geänderten Gesetzeslagen zu genügen. Prinzipien aus Normen wie ISO 27001 oder BSI-Grundschutz – etwa klare Vergabeprozesse, Rezertifizierungen, Protokollierung (siehe nächstes Kapitel) – sollten eingehalten werden. Durch eine saubere RBAC-Umsetzung sind viele dieser Punkte bereits abgedeckt, denn sie sorgt für strukturierte und dokumentierte Rechtevergabe. Wichtig ist allerdings die korrekte Umsetzung in der Technik: Es reicht nicht, Regeln zu definieren; man muss auch sicherstellen, dass das System sie technisch durchsetzt und dass es keine Hintertüren gibt (z. B. direkte DB-Zugriffe ohne RBAC-Kontrolle). Daher gehört zur Security-Konformität immer auch, dass man das System härtet, Admin-Zugänge schützt und das Berechtigungsmodell auf mögliche Umgehungsmöglichkeiten testet.

Ein oft unterschätzter, aber äußerst wichtiger Bestandteil des Berechtigungskonzepts ist die Auditierbarkeit. Es muss nachvollziehbar sein, wer wann auf welche Daten zugegriffen oder welche Änderung vorgenommen hat – und zwar insbesondere bei privilegierten Aktionen. Dafür sollte das CAFM-System umfassende Logging-Mechanismen bereitstellen. Idealerweise wird jeder sicherheitsrelevante Event protokolliert.

• Login-Versuche (erfolgreich und fehlgeschlagen) mit Zeitstempel und Benutzer-ID.

• Änderungen an Berechtigungen: z. B. wenn Admin A dem Benutzer B eine Rolle zuweist oder entzieht, sollte dies im Protokoll mitgeführt werden. Ebenso das Anlegen oder Löschen von Benutzern.

• Datenzugriffe auf sensible Objekte: Etwa wenn ein Benutzer einen Datensatz öffnet, der persönliche Informationen enthält, könnte ein Lese-Log erfasst werden. Das ist allerdings abhängig von der Systemleistung und Relevanz – nicht jeder Lesezugriff wird in allen Systemen geloggt. Für besonders schützenswerte Daten (Personalakten, Vertragsdokumente) ist es aber empfehlenswert, Lesezugriffe mitzuloggen („Benutzer X hat am 12.02.2026 14:05 das Dokument Y angesehen“).

• Änderungsaktionen (Create, Update, Delete) an Kernobjekten: Hier sollte stets nachvollziehbar sein, welcher User z. B. einen Wartungsauftrag abgeschlossen oder einen Vertrag geändert hat. In der Regel setzt man hier auf feldgenaue Historien oder zumindest Ereignislogs, um nachträglich rekonstruieren zu können, was geändert wurde.

• Fehlversuche und Zugriffsverweigerungen: Wenn ein User versucht, eine Aktion auszuführen, für die ihm die Rechte fehlen (z. B. Zugriff auf einen gesperrten Bereich), sollte auch das – zumindest summarisch – festgehalten werden, da wiederholte unautorisierte Zugriffsversuche auf einen möglichen Missbrauch hindeuten können.

Ein konkretes Beispiel aus dem Datenbankumfeld: Moderne Systeme können ein granulares Audit-Trail führen, das z.B. authentifizierungsbezogene Events, Rollenzuweisungen, Anlage/Löschung von Nutzern und Daten-Lese/Schreibzugriffe erfasst. Solche Logs dienen zwei Zwecken: Compliance-Nachweis (gegenüber Prüfern zeigen, dass Zugriffe kontrolliert stattfinden und dokumentiert sind) und forensische Analyse (im Falle eines Sicherheitsvorfalls nachvollziehen zu können, was passiert ist). Gerade für Branchen mit hohen Compliance-Anforderungen (Healthcare, Finance) sind Audit-Logs unverzichtbar.

Wichtig ist, dass die Logs auswertbar sind. Es empfiehlt sich, die CAFM-Logs in ein zentrales SIEM (Security Information and Event Management) oder Logging-System (wie ELK stack, Splunk etc.) einzuspeisen. Dort kann man Alarmierungen definieren – zum Beispiel, wenn ein Benutzer plötzlich Admin-Rechte erhält oder ein eigentlich inaktiver Account auf sensible Daten zugreift, schlägt das System Alarm. Regelmäßige Review der Logfiles oder der SIEM-Reports ist Teil der Governance: Mindestens quartalsweise sollten Berechtigungslogs durchgesehen werden, idealerweise automatisch ausgewertet auf Anomalien. Einige Best Practices empfehlen sogar monatliche Mini-Audits und quartalsweise große Reviews.

Aus administrativer Sicht sollten Änderungen am Rollenkonzept selbst auch dokumentiert werden. Wenn z. B. eine neue Rolle eingeführt oder die Berechtigungen einer Rolle geändert werden, gehört das ins Änderungsprotokoll (Changelog) und möglicherweise ebenfalls ins Audit-Log, damit im Nachhinein nachvollziehbar ist, ab wann welche Rolle welche Rechte enthielt. Bei der Umsetzung kann man hier das Four-Eyes-Prinzip walten lassen: Änderungen an Rollen nur durch zwei Personen freigeben lassen, um Fehler oder Missbrauch zu verhindern.

Schließlich muss man sich Gedanken machen, wie lange Audit-Logs aufzubewahren sind. DSGVO verlangt einerseits Datensparsamkeit, andererseits braucht man für Compliance-Nachweise oft Logs über mehrere Jahre. Ein gängiger Kompromiss ist: Operative Logs im System vielleicht 6-12 Monate vorhalten, aber die sicherheitsrelevanten Audit-Trails exportieren und z. B. 3-5 Jahre archivieren (in einem Compliance-Store). Wichtig ist, dass diese Daten sicher gespeichert werden, gegen Manipulation geschützt und nur berechtigten Personen zugänglich sind (z. B. dem Datenschutzbeauftragten oder Revision).

In Summe sorgt ein durchdachtes Logging dafür, dass das RBAC-Modell transparent gelebt wird: Jede Berechtigung ist nicht nur konzeptionell sauber, sondern ihre Nutzung ist auch belegbar („Wer hat was gemacht oder gesehen?“). Das erhöht das Vertrauen ins System und ermöglicht es, unangemessene Zugriffe schnell zu erkennen und zu reagieren.

Im Betriebsalltag kommt es häufig vor, dass Benutzer vorübergehend zusätzliche Rechte benötigen – sei es, um einen Kollegen zu vertreten (z. B. Urlaubsvertretung) oder um in einem Projekt befristet mitzuwirken. Ein robustes Berechtigungskonzept sollte daher temporäre Rollen oder Delegationsmöglichkeiten vorsehen. Das klassische Beispiel: Mitarbeiter A übernimmt für 2 Wochen die Aufgaben von Mitarbeiter B. In dieser Zeit soll A Zugriff auf die Vorgänge von B erhalten (damit er z. B. dessen Tickets weiterbearbeiten kann), aber nach den 2 Wochen müssen diese Rechte automatisch wieder entzogen werden.

Eine Möglichkeit ist die temporäre Rollenzuweisung mit Ablaufdatum. Viele IAM- und ITSM-Systeme haben Funktionen, um Rollen zeitlich befristet zu vergeben. Der Administrator oder der Vorgesetzte trägt ein Enddatum ein, und nach dessen Erreichen entzieht das System die Rolle automatisch. So wird verhindert, dass aus einer Vertretung eine dauerhafte Rechteausweitung wird (der sogenannte „Azubi-Effekt“, bei dem jemand durch wechselnde Stationen immer mehr Rechte ansammelt). RBAC kann diesem Effekt gezielt entgegenwirken, indem es solche temporären Mitgliedschaften ermöglicht und damit Überberechtigungen abbaut. Wichtig ist, diese befristeten Rechte auch wirklich zu nutzen: In der Praxis darf es nicht aus Bequemlichkeit doch passieren, dass ein Admin „auf unbestimmte Zeit“ eine hochprivilegierte Rolle vergibt, die dann nie zurückgenommen wird. Hier helfen Prozesse (z. B. automatische Aufgaben für Admins, temporäre Rollen zu prüfen) und Tools (Dashboards mit auslaufenden Berechtigungen).

Neben zeitlichen Befristungen gibt es das Konzept der Delegation oder Stellvertreterrollen. Dabei erteilt ein Benutzer einem anderen gezielt die Erlaubnis, in seinem Namen bestimmte Aktionen durchzuführen. Ein CAFM-Beispiel: Ein Abteilungsleiter delegiert seine Freigaberechte an seinen Stellvertreter während seiner Abwesenheit. Im System könnte dies so gelöst sein, dass der Stellvertreter eine spezielle Rolle „Freigeber-Stellvertreter“ erhält, die jedoch nur aktiv ist, solange der Hauptverantwortliche abwesend markiert ist. Alternativ loggt sich der Stellvertreter „als“ der andere Benutzer ein (Impersonation) – das ist aber weniger nachvollziehbar und datenschutzrechtlich oft heikel. Besser ist, wenn das System die Delegation intern regelt und im Audit klar vermerkt „User X hat als Vertretung für User Y Vorgang Z freigegeben“.

Wichtig bei Delegationen ist auch die Einschränkung des Umfangs: Der Vertreter sollte wirklich nur diejenigen Rechte bekommen, die für die Vertretung nötig sind. Beispielsweise muss nicht jeder Schreibzugriff delegiert werden, vielleicht nur das Freigaberecht für Bestellungen, aber nicht der Vollzugriff auf alle Stammdaten. Hier kann man fein justieren, ggf. auch separate Vertretungsrollen für Teilbereiche anbieten.

Eine Best Practice ist es, im Unternehmen Richtlinien aufzustellen: z. B. Vertretungsberechtigungen dürfen maximal X Wochen gelten, und es muss dokumentiert sein, wer wann vertreten hat. Nach Ende der Vertretung sollte eine Überprüfung stattfinden (hat der Vertreter möglicherweise noch Datenzugriff, den er nicht mehr braucht? Wenn ja, entziehen!). In der Realität gehen solche Überprüfungen leider manchmal unter, daher sind technische Automatismen wertvoll (z. B. Bericht über alle temporären Rechte, die gerade aktiv sind, mit Enddatum und Verantwortlichem).

Im Gesamtkonzept tragen temporäre und delegierte Rechte dazu bei, die Geschäftskontinuität zu sichern (Urlaub/Krankheit überbrücken) und dennoch dem Least-Privilege-Prinzip treu zu bleiben. Mit RBAC lassen sich so flexible Modelle realisieren, ohne dass man das feste Rollenmodell aufweicht. Wichtig ist eine saubere Umsetzung: Im CAFM sollte klar erkennbar sein, wenn ein Benutzer aufgrund einer Delegation handelt (ggf. in der UI anzeigen „Als Vertreter von ... tätig“) und die Logs sollten dies ebenfalls wiederspiegeln. So bleibt auch im Nachhinein transparent, dass eine bestimmte Aktion

• Rollen am Geschäftsmodell ausrichten: Definieren Sie Rollen so, dass sie echten Aufgaben und Verantwortlichkeiten im Unternehmen entsprechen. Führen Sie Interviews mit Fachbereichen, um herauszufinden, welche Tätigkeiten welche Rechte erfordern. Vermeiden Sie es, Rollen um einzelne Personen herum zu bauen – Rollen sollten immer für Gruppen von Nutzern passen (z. B. „Techniker“, „Objektverwalter“, „Teamleiter“). Jede Rolle sollte in ihrer Berechtigungszusammenstellung einen klaren Zweck haben, und jede enthaltene Permission sollte durch einen geschäftlichen Bedarf gerechtfertigt sein.

• Granularität ausgewogen gestalten: Finden Sie das richtige Maß an Granularität. Zu grob (wenige Rollen mit sehr weitreichenden Rechten) verletzt das Least-Privilege-Prinzip; zu fein (Dutzende Minirollen für jede Kleinigkeit) führt zur Rollenexplosion und unübersichtlicher Verwaltung. In der Praxis hat es sich bewährt, Rollen nach Funktionsbereichen zu gestalten (z. B. „Wartungsplanung“, „Raumbuchungs-Admin“) und selten benötigte Spezialrechte als optionale Zusatzrollen vorzusehen. Achten Sie darauf, dass die Anzahl der Rollen in einem vernünftigen Verhältnis zur Organisationsgröße steht – ein Warnzeichen ist, wenn es mehr Rollen als Mitarbeiter gibt, oder jeder Benutzer eine einzigartige Rollen-Kombination hat (dann stimmt die Rollendefinition meist nicht).

• Prinzip der minimalen Rechte strikt umsetzen: Weisen Sie neuen Benutzern zunächst nur eine Basissrolle zu (etwa „Mitarbeiter“ mit Leserechten) und erweitern Sie erst, wenn tatsächlich mehr benötigt wird. Entfernen Sie Rollen, die nicht mehr benötigt werden, z. B. nach Aufgabenwechsel eines Mitarbeiters. Lassen Sie keine „Karteileichen“ liegen – Benutzer, die austreten, sind zu deaktivieren, und Rollen, die niemand mehr innehat, können nach Prüfung gelöscht werden, um das Modell schlank zu halten. Verhindern Sie Privilege Creep, indem Zugriffsrechte auch reduziert werden, wenn Aufgaben wegfallen (nicht nur immer hinzugeben). Regelmäßige Rezertifizierungsprozesse (z. B. einmal jährlich müssen Vorgesetzte bestätigen, dass ihre Mitarbeiter die vergebenen Rechte noch brauchen) helfen dabei.

• Klare Role Governance und Change-Prozesse: Definieren Sie Zuständigkeiten für das Rollenmanagement. Wer darf neue Rollen anlegen oder ändern? Oft ist es sinnvoll, ein kleines Berechtigungs-Team oder Board zu haben, das Änderungen am Rollenkonzept koordiniert. Änderungen sollten nach dem Vier-Augen-Prinzip erfolgen und dokumentiert werden. Nutzen Sie eventuell ein ITSM-Tool, um Rollenänderungen als Changes mit Ticket nachzuverfolgen. So vermeiden Sie Wildwuchs und behalten die Kontrolle.

• Dokumentation und Schulung: Halten Sie das Rollenkonzept schriftlich fest – inklusive Beschreibung jeder Rolle, der ihr zugeordneten Rechte, der Inhaber (bzw. Kriterien) und evtl. der zugeordneten AD-Gruppen. Diese Dokumentation ist Gold wert für Einarbeitung neuer Admins und für Audits. Schulen Sie auch die Fachabteilungen: Oft wissen Nutzer gar nicht, welche Rollen es gibt und was sie bedeuten. Eine kleine „Berechtigungsmatrix“-Übersicht kann Transparenz schaffen und hilft auch, dass die richtigen Rollen beantragt werden.

• Automatisieren, wo möglich: Nutzen Sie die Möglichkeiten von IAM-Systemen, um Routineaufgaben zu automatisieren. Beispielsweise regelmäßige Access Reviews können tooling-unterstützt sein: Das System sendet automatisch jedem Abteilungsleiter eine Liste der Benutzer und deren Rollen zur Bestätigung. Oder man implementiert dynamische Rollen (wie besprochen), um manuelle Zuweisungen zu reduzieren. Ebenso können Audit-Reports automatisiert an Compliance-Verantwortliche geschickt werden (z. B. monatliche Zusammenfassung aller Admin-Aktivitäten und kritischer Zugriffe).

• Rollenexplosion vermeiden: Schon erwähnt, aber kritisch – überprüfen Sie bei jeder neuen Rollenanforderung, ob sie nicht mit einer bestehenden Rolle abgedeckt werden kann oder ob man sie durch Kombination mehrerer bestehenden lösen kann. Zu schnelle Einführung neuer Rollen führt zu Überschneidungen und redundanten Rechten. Lieber bestehende Rollen anpassen (sofern verträglich) als immer neu erstellen. Wenn doch viele feine Unterschiede verlangt werden, evaluieren Sie ABAC-Ansätze, anstatt für jede Variation separate Rollen einzuführen.

• Separation of Duties berücksichtigen: Führen Sie, falls möglich, ein SoD-Regelwerk ein. Dieses kann z. B. festlegen, dass kein Benutzer die zwei Rollen X und Y gleichzeitig haben darf. Wenn Ihr IAM-System das nicht erzwingen kann, muss wenigstens organisatorisch darauf geachtet werden. SoD-Konflikte sollten in der Rollendokumentation vermerkt sein, damit Admins bei Zuweisungen gewarnt sind.

• Testen Sie das Berechtigungsmodell intensiv: Gerade nach größeren Änderungen oder vor Go-Live einer neuen Rolle sollte man verschiedene Userkonten mit unterschiedlichen Rollen anlegen und prüfen: Sehen sie wirklich nur das, was sie sehen sollen? Können sie eventuell etwas, was sie nicht dürften? Versuchen Sie gezielt, das System aus Nutzersicht zu „brechen“ (Penetration Testing der Berechtigungen). Auch Code-Reviews oder technische Prüfungen (z. B. ob alle API-Endpunkte eine Authz-Prüfung haben) sind sinnvoll, damit keine Lücke offen bleibt.

Durch Befolgung dieser Best Practices bleibt das RBAC-System übersichtlich, sicher und flexibel anpassbar. Änderungen im Unternehmen – neue Abteilungen, geänderte Prozesse – lassen sich dann mit vertretbarem Aufwand ins Rollenmodell übertragen, ohne es jedes Mal neu erfinden zu müssen.

• Anforderungen erheben: Sammeln Sie alle Use Cases und Benutzergruppen für das CAFM-System. Identifizieren Sie, welche Aufgaben die Nutzer darin erledigen sollen und welche Daten sie benötigen. Daraus leiten Sie die ersten Berechtigungserfordernisse ab.

• Rollenkonzept entwerfen: Erstellen Sie basierend auf den Anforderungen einen Entwurf des Rollenkonzepts. Definieren Sie Rollen mit verständlichen Namen (möglichst angelehnt an die Organisationsbegriffe) und ordnen Sie ihnen die benötigten Funktions- und Objektberechtigungen zu. Nutzen Sie Tabellen oder Matrizen, um Rollen, Rechte und ggf. Sichtbarkeiten abzubilden.

• Profile/Filter für Datenzugriff planen: Überlegen Sie, ob und wie Sie Datenzugriffsfilter (Mandant, Standort, Organisationseinheit) abbilden. Entwerfen Sie Berechtigungsprofile oder Filterregeln, z. B. pro Mandant oder Standort. Legen Sie fest, ob diese über separate Profile oder in Rollen integriert umgesetzt werden.

• Integrationsstrategie festlegen: Entscheiden Sie, wie die Benutzer ins System kommen und wie die Authentifizierung erfolgt. Sollen Benutzer manuell angelegt werden oder via LDAP/SSO integriert? Stimmen Sie sich mit der IT-Infrastruktur ab, ob z. B. ein SAML-basiertes SSO mit Azure AD eingerichtet werden kann, oder ob ein IDM-System die Nutzer/Rollen liefern wird. Planen Sie entsprechend die notwendigen Konnektoren oder Mapping-Tabellen.

• Umsetzung in der Applikation: Konfigurieren Sie im CAFM-System die Rollen und Berechtigungen gemäß Konzept. Legen Sie zunächst die Rollen an, dann die Berechtigungen (entweder über die GUI oder Konfigurationsdateien/ -skripte). Richten Sie die Benutzergruppen bzw. Zuweisungen ein. Wenn SSO: Konfigurieren Sie den Service-Provider in Absprache mit dem IdP (z. B. Metadaten austauschen, Zertifikate, Redirect-URLs einrichten).

• Testphase – Berechtigungstests: Nutzen Sie Dummy-User oder Testaccounts pro Rolle und prüfen Sie, ob die Rechte passen. Führen Sie Szenarien durch: Kann der Helpdesk-Nutzer Tickets sehen? Kann der Techniker nur seine Aufträge bearbeiten? Versuchen Sie auch negatives Testing: Ein Benutzer ohne Recht X darf Funktion Y nicht sehen/ausführen. Dokumentieren Sie gefundene Abweichungen.

• Schulung und Rollout: Schulen Sie die Administratoren, wie sie Benutzer anlegen/zuweisen sollen und was bei neuen Rollen zu beachten ist. Bereiten Sie auch für Endanwender kurze Infos vor, z. B. welche Rollen es gibt und wie zusätzliche Rechte beantragt werden können. Während des Rollouts beobachten Sie genau die Rückmeldungen: Wenn viele Anfragen à la „Ich sehe Feature X nicht“ kommen, prüfen, ob evtl. Berechtigungen fehlen oder die Rolle falsch zugewiesen ist.

• Go-Live und Monitoring: Nach dem Produktivstart überwachen Sie die Nutzung. Schauen Sie in Logs oder Nutzungsmuster, ob irgendwo Zugriffe abgelehnt werden, die eigentlich erlaubt sein sollten (Feinkorrektur der Rechte). Gleichzeitig achten Sie auf unerwartete Zugriffe – eventuell in den ersten Tagen Berichte fahren, wer auf viele Datensätze zugreift, um sicherzugehen, dass keine Überberechtigung vorliegt.

• Regelbetrieb & Pflege: Etablieren Sie einen Prozess für die Berechtigungsverwaltung im Alltag. Neue Mitarbeiter? -> Klar definiert, welche Standardrolle sie bekommen. Mitarbeiter wechselt Abteilung? -> Prozess, der das ans Admin-Team meldet und Rollenwechsel vornimmt (oder gleich IAM-automatisiert). Führen Sie regelmäßige Rechte-Reviews durch (z. B. halbjährlich Abteilungsleiter bestätigen lassen, dass ihre Leute die Rollen noch benötigen). Nutzen Sie dabei Reporting-Funktionen des Systems (Liste aller User mit Rollen) zur Kontrolle.

• Weiterentwicklung: Evaluieren Sie das Berechtigungskonzept nach einigen Monaten Laufzeit. Stimmen die Rollen noch, oder sind Anpassungen nötig (weil z. B. gewisse Aufgaben nicht abgedeckt sind)? Holen Sie Feedback von den Key-Usern ein. Passen Sie das Konzept behutsam an, aber achten Sie darauf, Änderungen immer rückwärtskompatibel zu gestalten (lieber neue Rolle ergänzen als bestehende radikal ändern, damit aktuelle Nutzer nicht plötzlich Rechte verlieren, außer es ist gewollt).

Diese Schritte helfen, die Einführung strukturiert und nachvollziehbar zu gestalten. Natürlich muss jeder Schritt an die spezifische Organisation und Software angepasst werden – ein agiles Vorgehen mit Feedback-Schleifen ist empfehlenswert. Gerade bei komplexen Systemen wie CAFM ist nicht garantiert, dass auf Anhieb jede Berechtigung perfekt sitzt; iterative Verbesserung und enge Zusammenarbeit zwischen IT, Fachbereich und evtl. Datenschutzbeauftragten sind der Schlüssel. Mit einem fundierten Konzept, solider technischer Umsetzung und kontinuierlicher Pflege werden Rollen und Berechtigungen jedoch vom vermeintlichen Stolperstein zu einem Enabler: Sie sorgen für Sicherheit, Compliance und Klarheit in der Anwendung, sodass alle Beteiligten dem System vertrauen können und effizient damit arbeiten.

Die technische Umsetzung von Rollen und Berechtigungen in einem CAFM-Projekt erfordert zunächst konzeptionelle Vorarbeit und dann eine konsequente Umsetzung mit den richtigen Tools und Integrationen. Wird diese Aufgabe mit Sorgfalt angegangen – nach den genannten Best Practices – so zahlt es sich in Form eines reibungslosen Betriebs, höherer Datensicherheit und zufriedener Anwender aus. Ein gut durchdachtes Rollenmodell ist langfristig weniger aufwendig in der Wartung, da es klar, konsistent und skalierbar ist. Es lohnt sich also, diese Grundlage von Anfang an solide zu legen. Mit den hier dargestellten Empfehlungen steht einer erfolgreichen Einführung nichts mehr im Wege.