CAFM: Security/IAM-Architektur (SSO, Rollen, Logging)

Single Sign-On ermöglicht es, dass Benutzer sich einmal authentifizieren und dann das CAFM sowie andere Anwendungen nutzen können, ohne sich erneut anmelden zu müsse. Technisch wird dies meist über föderierte Authentifizierung realisiert. Das heißt, das CAFM-System delegiert den Anmeldevorgang an einen zentralen Identity Provider (IdP). Typische Protokolle dafür sind SAML 2.0 und OpenID Connect (OIDC). SAML ist im Unternehmensumfeld weit verbreitet und basiert auf XML-basierten Assertions: Das CAFM (als SAML Service Provider) leitet einen nicht authentifizierten Nutzer zum IdP (z.B. ADFS, Azure AD, Okta) weiter, wo dieser seine Login-Daten eingibt und ggf. eine MFA-Prüfung durchläuft. Anschließend stellt der IdP ein signiertes SAML-Token (Assertion) aus, das an das CAFM zurückgeleitet wird und dort die Identität des Nutzers bestätigt. OIDC hingegen baut auf OAuth2 auf und nutzt JSON Web Tokens (JWT). Hier holt sich das CAFM (als OIDC Client) nach erfolgreicher IdP-Anmeldung ein ID-Token sowie ein Access-Token vom OIDC-Provider. Beide Ansätze erfüllen ähnliche Zwecke – wichtig ist, dass das CAFM-System mindestens einen davon unterstützt und kompatibel zu den IdPs des Kunden ist.

Neben der föderierten Anmeldung unterstützen viele CAFM-Systeme auch Direktanmeldung gegen Verzeichnisdienste. Beispielsweise kann ein Nutzer, der bereits an der Windows-Domäne angemeldet ist, automatisch im CAFM authentifiziert werden (Integrated Windows Authentication via Kerberos/NTLM). Alternativ bieten einige Systeme Legacy-Methoden wie LDAP-Bind mit Benutzerpasswort an – dies sollte jedoch nur über verschlüsselte Verbindungen (LDAPS) erfolgen. Moderne Lösungen bevorzugen die föderierten Methoden, da sie sicherer und flexibler sind.

Unabhängig vom Authentifizierungsweg sollte stets MFA (Multi-Faktor-Authentifizierung) integriert werden, um die Sicherheit zu erhöhen. Idealerweise wird MFA vom IdP erzwungen (z.B. Azure AD Conditional Access Policy, die einen zweiten Faktor wie OTP, Smartcard oder FIDO2 verlangt). Das CAFM profitiert dann automatisch davon, ohne selbst MFA-Techniken implementieren zu müssen. Für den Fall, dass das CAFM doch eigene Logins zulässt, sollte es zumindest die gängigen MFA-Mechanismen unterstützen (OTP per App/SMS, U2F/WebAuthn-Keys, etc.).

Auch Session-Management spielt eine Rolle: Nach erfolgter SSO-Anmeldung erstellt das CAFM in der Regel eine Anwendungssession (z.B. Websession mit Token oder Cookie). Hier sind Sicherheitsrichtlinien wie Session Timeout, Inaktivitäts-Timeout und sichere Cookie-Flags wichtig. Wenn möglich sollte das CAFM Single Logout (SLO) unterstützen – d.h. beim Abmelden des Users werden IdP und andere Anwendungen informiert, um die Sitzung überall zu beenden. Zudem ist es sinnvoll, Session-Hijacking-Schutz zu aktivieren (z.B. Bindung der Session an den Client, regelmäßige Token-Erneuerung).

Es trägt SSO im CAFM-Kontext dazu bei, Benutzerkomfort und Sicherheit zu vereinen: Die Nutzer verwenden ihre vertrauten Unternehmens-Logins, während die Organisation zentrale Kontrolle über die Authentifizierung behält (mit Policies wie MFA, IP-Restriktionen usw.). Gerade für Cloud-basierte CAFM-Lösungen oder mobile Zugriffe ist SSO unverzichtbar, um eine konsistente Sicherheitsstruktur aufzubauen.

Neben der reinen Anmeldung muss das CAFM sicherstellen, dass Benutzer nur das sehen und tun können, was ihren Aufgaben entspricht. Hier kommt die rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) ins Spiel. Im RBAC-Modell werden Berechtigungen nicht direkt einzelnen Benutzern gegeben, sondern in Rollen gebündelt. Jeder Rolle ist eine definierte Menge an Rechten zugewiesen (z.B. Lese-/Schreibrechte auf bestimmte Module, Freigaberechte etc.), und die Benutzer erhalten dann eine oder mehrere Rollen entsprechend ihrer Funktion. Dieses Konzept ist übersichtlich und skalierbar: Organisatorische Rollen (wie „Techniker“, „Facility Manager“, „Controller“) spiegeln oft Abteilungen oder Jobprofile wider, während technische Rollen (wie „CAFM-Administrator“, „Schnittstellen-Benutzer“) systembezogene Privilegien bündeln. Durch die saubere Trennung – fachliche Rollen für die normalen Anwendungsfälle, technische Rollen für besondere Systemfunktionen – wird das Prinzip der geringstmöglichen Rechte (Least Privilege) einfacher umgesetzt. Ein Benutzer erhält im Tagesgeschäft nur die fachlichen Rechte, die er benötigt, und technische Sonderrechte nur bei Bedarf und meist befristet.

Ein gutes RBAC-Modell im CAFM berücksichtigt auch die Mandantenfähigkeit. Viele CAFM-Systeme werden mandantenfähig betrieben, d.h. entweder als Cloud-Service mit mehreren Kunden auf einer Instanz, oder innerhalb eines Konzerns mit mehreren unabhängigen Organisationseinheiten. Das Berechtigungsmodell muss sicherstellen, dass Daten sauber nach Mandant oder Bereich getrennt sind. Oft wird dies durch Mandanten-Attribute oder separate Rollen je Mandant erreicht. Beispielsweise könnte es pro Tochtergesellschaft eigene Rollen geben („Hausmeister Standort A“ vs. „Hausmeister Standort B“) oder ein Mandantenfilter ist Teil jeder Berechtigungsprüfung. Wichtig ist, dass ein Benutzer eines Mandanten niemals Daten eines anderen Mandanten einsehen oder verändern kann (Tenant Isolation).

In der Praxis hat es sich bewährt, mit Standardrollen und Rollenvorlagen („Template Roles“) zu arbeiten. Für typische Funktionsgruppen werden vordefinierte Rollen erstellt, die alle notwendigen Rechte beinhalten – etwa „Helpdesk-Mitarbeiter“ mit Leserechten auf Stammdaten und Schreibrechten auf Ticketmodule, etc. Diese Rollen dienen als Vorlage und können – wo das System es erlaubt – noch parametrisiert werden (z.B. Einschränkung auf bestimmte Gebäude). Durch die Nutzung solcher Standardrollen wird vermieden, dass für jeden Einzelfall separate Rollen entstehen („Rollenexplosion“). Sonderfälle sollten stattdessen durch Kombination mehrerer Rollen oder temporäre Zusatzrechte abgebildet werden. Außerdem sollten Ausnahmen restriktiv gehandhabt und zeitlich befristet werden – z.B. via segregation of duties (SoD) Regeln, die verhindern, dass ein Nutzer durch zwei Rollen in einen Interessenkonflikt gerät. Ein Beispiel für SoD: Kein Nutzer darf gleichzeitig die Rolle „Genehmiger Wartungsaufträge“ und „Erfasser Wartungsaufträge“ für denselben Bereich haben, um Selbstgenehmigungen zu unterbinden. Das CAFM-System sollte daher Rollenkonflikte erkennen oder zumindest die Möglichkeit bieten, diese administrativ festzulegen.

Es bildet RBAC das Rückgrat der Autorisierung im CAFM. Ein gut durchdachtes Rollenmodell ist übersichtlich, nachvollziehbar und wartungsarm, da Änderungen (etwa neue Module oder geänderte Prozesse) durch Rollenanpassungen zentral gemanagt werden können, statt jeden Benutzer einzeln anzufassen. Zudem unterstützt ein rollenbasiertes Konzept die Compliance, weil jederzeit ersichtlich ist, welche Funktion welche Zugriffe hat – Überberechtigungen und Rechteanhäufungen einzelner Benutzer werden so vermieden. Wichtig ist, das Rollenmodell in enger Abstimmung mit den Fachbereichen zu entwickeln, damit es die Realität abbildet und akzeptiert wird.

Die Zuweisung und Verwaltung von Berechtigungen im laufenden Betrieb sollte klar geregelten Prozessen folgen. Idealerweise gibt es definierte Rechtemanagement-Prozesse: Zum Beispiel beantragt ein Mitarbeiter den Zugriff auf ein bestimmtes CAFM-Modul über ein Self-Service-Portal oder via Ticket; anschließend muss ein Verantwortlicher (z.B. der Vorgesetzte oder Systemverantwortliche) diesen Antrag prüfen und genehmigen (Vier-Augen-Prinzip). Erst nach Freigabe wird die entsprechende Rolle dem Benutzer zugewiesen. Durch solche mehrstufigen Genehmigungsverfahren stellt man sicher, dass erhöhte oder abweichende Berechtigungen nicht willkürlich vergeben werden. Gerade bei privilegierten Rechten (z.B. Administratorrolle im CAFM) sollten immer zusätzliche Prüfungen oder Freigaben erfolgen, ggf. sogar durch ein Gremium oder per SoD-Matrix, um „toxic combinations“ zu verhindern.

In vielen Fällen kann ein IAM-System diese Workflows unterstützen oder automatisieren. Hat das Unternehmen z.B. ein Identity Governance & Administration (IGA) Tool im Einsatz, lässt sich die CAFM-Berechtigungsverwaltung dort integrieren. Dann werden Zugriffsanfragen im IGA-System gestellt, genehmigt und das System provisioniert anschließend automatisch die entsprechende Rolle im CAFM (über SCIM oder API). Falls kein solches Tool vorhanden ist, sollte zumindest dokumentiert sein, wer welche Rollen zuteilen darf (z.B. nur der CAFM-Systemowner oder eine kleine Admin-Gruppe, auf Anforderung der Fachabteilung).

Delegation bezieht sich darauf, Rechte oder Aufgaben temporär an andere zu übertragen. Im CAFM-Kontext kann dies bedeuten: Wenn ein Verantwortlicher (etwa Gebäudeleiter) abwesend ist, kann er einen Stellvertreter benennen, der in seiner Abwesenheit z.B. Freigaben erteilen darf. Das System sollte solche vertretungsweisen Berechtigungsübertragungen ermöglichen, idealerweise zeitlich befristet und protokolliert. Ebenso gibt es das Konzept der delegated administration: Bestimmte weniger kritische Verwaltungsaufgaben können an lokale Admins delegiert werden, ohne dass diese Volladministrator des gesamten Systems sein müssen. Ein Beispiel: Ein Regionalleiter darf Benutzer für „seine“ Liegenschaften anlegen und ihnen fachliche Rollen zuweisen, aber keine systemweiten Einstellungen ändern. Dazu muss die Applikation feingranulare Admin-Rollen bieten.

Wichtig ist auch, dass alle Ausnahmen und Sonderberechtigungen nachvollziehbar dokumentiert und regelmäßig überprüft werden. Oft schleichen sich über die Zeit „Schattenberechtigungen“ ein – z.B. ein Mitarbeiter hat aufgrund eines Projekts temporär eine zusätzliche Rolle erhalten, die nach Projektende nie entfernt wurde. Solche Situationen gilt es zu vermeiden bzw. aufzudecken. Durch regelmäßige Rezertifizierungen (siehe Governance unten) sollten Manager oder Role Owner bestätigen, dass die zugeteilten Rechte noch korrekt sind. Delegationen sollten automatisch enden oder mindestens manuell entzogen werden, sobald ihr Zweck erfüllt ist.

Schließlich sollte das System feingranulare Autorisierungsprüfungen durchführen. Das bedeutet, nicht nur das Ob eines Zugriffs (darf User X Modul Y öffnen?) muss geprüft werden, sondern ggf. auch datensatzbezogene Berechtigungen. In einem CAFM könnte z.B. ein Benutzer zwar das Wartungsmodul nutzen dürfen, aber nur Tickets seiner eigenen Abteilung sehen. Solche Einschränkungen (Row-Level Security, Objektfilter) sind oft Teil des Berechtigungskonzepts. Sie sollten konsistent mit dem Rollenmodell umgesetzt werden und möglichst parametrierbar sein (z.B. Filter auf „eigene Organisationseinheit“ ohne dafür separate Rollen je Einheit zu brauchen).

Im Ergebnis sorgen klare Autorisierungsprozesse und Delegationsmechanismen dafür, dass jeder Benutzer genau die richtigen Rechte zur richtigen Zeit hat – nicht zu viel und nicht zu wenig. Die Organisation behält die Kontrolle, kann Verantwortlichkeiten zuweisen (wer darf freigeben, wer darf administrieren) und hält gleichzeitig die notwendige Flexibilität für den Betrieb bereit (z.B. Vertretungen, temporäre Projektrollen, Notfallzugänge unter Kontrolle).

Ein wesentlicher Bestandteil der Sicherheitsarchitektur ist das Logging und Auditing aller sicherheitsrelevanten Aktivitäten im CAFM. Nur durch eine umfassende und kluge Protokollierung ist es möglich, im Nachhinein Vorfälle zu analysieren, Manipulationen nachzuweisen und die Einhaltung von Richtlinien zu überprüfen.

Zunächst muss definiert werden, welche Ereignisse protokolliert werden sollen. Im CAFM-Kontext gehören dazu insbesondere: Authentifizierungsvorgänge (Login-Versuche, erfolgreiche Logins, Logouts; inkl. Fehler bei SSO oder MFA), Änderungen an Benutzerkonten und Rollen (Anlage, Rollenänderungen, Deaktivierung von Nutzern), Änderungen an Berechtigungen oder Rollen (wer hat wann eine Rolle angelegt oder verändert), kritische Nutzeraktionen (z.B. Löschen oder Export großer Datenmengen, Freigaben, Änderungen an Schlüsseldaten) sowie Systemereignisse (Start/Stop von Diensten, Fehler, Integrationsaufrufe). Viele dieser Ereignisse werden idealerweise in einem Audit-Log erfasst, das für Administratoren einsehbar ist. Ein CAFM-System sollte eine eingebaute Audit Trail-Funktion haben, die wichtige Änderungen mit Uhrzeit, Benutzer und Aktion aufzeichnet.

Wichtig ist die Integrität und Sicherheit der Logdaten. Logs sollten unveränderlich bzw. gegen nachträgliche Manipulation geschützt gespeichert werden (z.B. schreibender Zugriff nur append-only, ggf. kryptographische Signaturen oder Ablage in einem manipulationssicheren System). Zudem ist eine zugriffstechnische Trennung ratsam: Administratoren des CAFM sollten nicht in der Lage sein, die Protokollierung ihrer eigenen Aktivitäten zu löschen oder zu veränder. Oft wird dies durch einen zentralen Logserver oder SIEM erreicht, an den das CAFM alle wichtigen Logs fortlaufend sendet. Dort liegen die Daten außerhalb der direkten Kontrolle der Anwendungs-Admins und können unabhängig ausgewertet werden. Viele Unternehmen setzen auf ein SIEM (Security Information and Event Management), das Logs aus diversen Quellen korreliert. Die Anbindung des CAFM an das SIEM (z.B. via Syslog, Logstash/ELK oder spezifischer Connector) ermöglicht es, Auffälligkeiten frühzeitig zu erkennen – etwa wenn ein Benutzerkonto im CAFM plötzlich tausende Datensätze abruft oder ein Admin mitten in der Nacht Änderungen vornimmt, schlägt das SIEM Alarm. Auch fehlgeschlagene Login-Exzesse (Brute-Force-Versuche) oder Zugriffe aus ungewöhnlichen Regionen könnten so erkannt werden.

Protokollierungsrichtlinien sollten festlegen, wie lange welche Logs aufbewahrt werden. Hier spielt die DSGVO eine wichtige Rolle: Logs, die personenbezogene Daten enthalten (und dazu zählen schon Benutzerkennungen, IP-Adressen in Zusammenhang mit Nutzern, oder personenbezogene Aktionen), dürfen nur zweckgebunden und mit begrenzter Aufbewahrungsdauer gespeichert werden. In der Regel definiert man einen Zeitraum (z.B. 6 oder 12 Monate) für sicherheitsrelevante Logs. Länger nur, wenn ein rechtlicher oder sicherheitstechnischer Grund besteht. Außerdem müssen Logs ggf. pseudonymisiert werden, sofern dies möglich ist und die Auditierbarkeit nicht untergraben wir. Ein Beispiel: In einem Nutzungs-Log könnte man anstelle des Klarnamens eines Mitarbeiters einen Hash speichern, solange man nicht ermitteln muss, wer es war. In der Praxis ist Pseudonymisierung von Audit-Logs schwierig, daher gilt es zumindest die Zugriffe auf Logs streng zu reglementieren (Vier-Augen-Prinzip für Logeinsehen) und die Löschung nach Fristablauf sicherzustellen.

Aus Datenschutz- und Compliance-Sicht ist zudem zu beachten, dass z.B. das Betriebsrat/Mitarbeitervertretungen ein Mitbestimmungsrecht haben, wenn Mitarbeiter überwacht werden (Logging kann als Überwachung gelten). Gerade bei umfangreichem Monitoring (z.B. Session Recording, Falls vorhanden) müsste Privacy-by-Design beachtet und frühzeitig der Datenschutzbeauftragte und Betriebsrat einbezogen werden. Im CAFM-Kontext ist dies meist unkritisch, da überwiegend sachbezogene Aktionen geloggt werden (wie Arbeitsaufträge etc.), aber Zugriffe auf Personaldaten im CAFM (z.B. Namen, Vertragsdaten von Dienstleistern) sind durchaus sensibel.

Zentrale Log-Infrastruktur: Es bietet sich an, einen zentralen Logserver oder Logging-Service (z.B. ELK Stack, Splunk, Azure Monitor, AWS CloudWatch etc.) zu nutzen, an den die CAFM-Anwendung ihre Logeinträge sendet. Dadurch hat man alle sicherheitsrelevanten Logs an einem Ort und kann einheitliche Auswertungen und Alerts definieren. Typische sicherheitsrelevante Logquellen im CAFM sind: Authentifizierungslogs, Autorisierungs-Entscheidungen (z.B. „Zugriff verweigert“ Meldungen), Admin-Aktionen (Konfigurationsänderungen, Benutzer-/Rollenverwaltung), evtl. APIZugriffe (siehe nächster Abschnitt) und Integrations-Schnittstellen. Auch die Datenbankebene kann Audit-Logs erzeugen (z.B. SELECT/UPDATE auf bestimmte Tabellen) – diese können ebenfalls relevant sein.

Ein umfassendes Logging ist die Basis für Audits. Regelmäßige Auditierung bedeutet, die Logs auch tatsächlich auszuwerten – sei es in Form von automatisierten Alarmierungen bei bestimmten Ereignissen oder manuellen Stichproben sowie Reporting an Compliance-Verantwortliche. Beispielsweise könnte ein monatlicher Audit-Report aus dem CAFM gezogen werden, der alle Admin-Logins und Rollenänderungen auflistet, um sicherzustellen, dass hier keine unautorisierte Aktivität stattgefunden hat. Logs liefern die nötige Beweiskraft, um im Nachhinein nachvollziehen zu können, welcher Nutzer welche Aktion durchgeführt hat – unabdingbar für forensische Analysen und um z.B. im Rahmen der DSGVO Auskunft geben zu können, wer auf personenbezogene Daten zugegriffen hat. Das Logging-Konzept sollte daher in der Sicherheitsarchitektur ebenso viel Beachtung finden wie die präventiven Maßnahmen.

Moderne CAFM-Systeme verfügen häufig über APIs und Schnittstellen – etwa RESTful Webservices für den Datenaustausch mit anderen Systemen (ERP, IoT-Sensorik, mobile Apps) oder Hintergrundjobs, die Daten importieren/exportieren. Diese Schnittstellen müssen ebenso gut abgesichert werden wie die Hauptanwendung selbst, da sie oft ein attraktives Angriffsziel darstellen.

Erster Schritt ist eine Authentifizierung und Autorisierung von API-Aufrufen. Eine gängige Methode ist die Verwendung von API-Schlüsseln (API Keys) für technische Clients oder Dienstprogramme. Ein API Key ist im Grunde ein geheimer Token, das der Client bei jedem Aufruf mit schickt, um sich zu identifizieren. Solche Keys sollten wie Passwörter behandelt und sicher gespeichert werden. Zudem müssen sie verwaltet werden (Ausstellung, regelmäßige Rotation, Entzug bei Kompromittierung). Allerdings bieten API Keys allein meist nur einfache Authentifizierung ohne Feingranularität. Daher setzen viele auf OAuth 2.0: Hier registriert man das CAFM als Resource Server und vergibt Access Tokens an berechtigte Clients. Über OAuth2 (ggf. in Verbindung mit OpenID Connect) lassen sich feingranulare Berechtigungen mittels Scopes oder Claims steuern – z.B. ein Token darf nur „Lesen“ aber nicht „Schreiben“ auf einer bestimmten API. Zudem haben OAuth-Tokens in der Regel eine begrenzte Lebensdauer, was Sicherheit erhöht (im Gegensatz zu statischen API Keys). Für Integrationen mit Benutzerkontext (etwa eine mobile App für Mitarbeiter) ist OAuth2/OIDC nahezu Standard, da so der Benutzer via SSO ein Token fürs CAFM erhalten kann, statt seine Passwortdaten in der App zu hinterlegen.

Neben der Authentifizierung ist auch Zugriffsbeschränkung und -kontrolle wichtig: Jede API sollte prüfen, ob der aufrufende Client bzw. das übermittelte Token die benötigte Berechtigung für die angeforderte Ressource hat (Autorisierung auf API-Ebene). Dies kann durch Rollenprüfungen oder Scope-Prüfungen erfolgen. Ein Beispiel: Ein Integrationsdienst hat einen speziellen technischen Account mit nur Leseberechtigung auf Stammdaten – die API erzwingt, dass dieser Account keine Schreiboperationen durchführen kann, selbst wenn technisch die Endpoint-URL bekannt wäre.

Ein häufig übersehener Aspekt ist die Absicherung gegen Missbrauch und Überlastung. Rate Limiting und Throttling sollten implementiert werden, um API-Aufrufe zu begrenzen. So kann man z.B. pro API-Key oder IP-Adresse nur X Anfragen pro Minute zulassen. Das verhindert sowohl unabsichtliche Überlast (z.B. durch fehlerhafte Skripte) als auch gezielte Denial-of-Service-Angriffe auf die Schnittstelle. Überschreitet ein Client die definierten Quoten, bekommt er z.B. HTTP 429 „Too Many Requests“ oder seine Anfragen werden verzögert (Throttling). Diese Maßnahmen schützt das System vor Performance-Problemen und kann Angriffsmuster aufdecken.

Ein weiterer Schutzmechanismus ist die Einschränkung der Zugriffsquellen. Wenn bekannt ist, dass nur bestimmte Systeme auf die API zugreifen müssen (z.B. eine Middleware-Server oder bekannte Partner), kann man IP-Adressbereiche zulassen oder eine VPN-Verbindung erfordern. Einige CAFM-APIs unterstützen auch mTLS (mutual TLS), d.h. der Client muss sich zusätzlich über ein Zertifikat authentifizieren (was abgehört oder manipulierte Anfragen deutlich erschwert). Modernere Ansätze wie DPoP (Demonstration of Proof of Possession) für OAuth2 Tokens gehen ebenfalls in die Richtung, den Tokengebrauch an die tatsächliche Client-Instanz zu binden.

Falls das CAFM mit Webhooks oder externen Callback-URLs arbeitet (z.B. um bei bestimmten Ereignissen eine externe URL aufzurufen), müssen diese Endpunkte sorgfältig konfiguriert und ggf. signiert werden, um Trust sicherzustellen (man will ja nicht, dass ein Angreifer dem System eine gefälschte Callback-URL unterschiebt).

Hintergrundprozesse im CAFM (etwa geplante Tasks, die Berichte generieren oder Daten synchronisieren) sollten mit möglichst minimalen Rechten laufen. Wenn solche Prozesse externe Verbindungen aufbauen (z.B. zum Mail-Server, zu IoT-Geräten), sind Service-Accounts notwendig, die ebenfalls sicher verwaltet werden müssen (starke Passwörter, nur notwendige Berechtigungen, keine Interaktiv-Login-Möglichkeit wenn nicht nötig). Alle Zugangsdaten, die Hintergrundjobs verwenden (APITokens, Datenbank-Credentials), gehören sicher verschlüsselt in die Konfiguration (z.B. in einen Vault oder zumindest in verschlüsselte Dateien), nicht im Klartext auf dem Server.

Zusammengefasst sollte man APIs und technische Schnittstellen mit dem gleichen Augenmerk sichern wie User-Frontends: Authentifizierung (idealerweise tokenbasiert statt statischer Schlüssel), Autorisierung pro Endpunkt, Verschlüsselung (TLS), Eingabekontrolle (um Injection zu verhindern) und Begrenzung der Nutzung. Der Einsatz eines API-Gateways kann viele dieser Aufgaben vereinfachen – es fungiert vorgeschaltet und übernimmt Authentifizierung, Ratenbegrenzung, Monitoring und manchmal sogar Payload-Validierung. So bleibt das CAFM-Core entlastet und Angriffe werden bereits am Gateway abgefangen. Gerade wenn das CAFM in der Cloud läuft, bieten viele Plattformen (Azure API Management, AWS API Gateway, etc.) solche Funktionen out-of-the-box.

Es ist zu erwähnen, dass Logging auch für APIs gilt: Jeder API-Zugriff – besonders fehlgeschlagene oder unautorisierte – sollte geloggt und analysiert werden (siehe Logging-Sektion). Dadurch kann man z.B. erkennen, wenn jemand versucht, mit einem gültigen Token aber ungenügenden Rechten auf einen Admin-Endpoint zuzugreifen (was verdächtig ist), oder ob massenhaft Anfragen in kurzer Zeit kommen.

Identity Lifecycle Management bezeichnet den gesamten Lebenszyklus eines Benutzerkontos von der Anlage bis zur Löschung – oft als Joiner-Mover-Leaver (JML) Prozess beschriebe. Im CAFM-Kontext ist es wichtig, diesen Lebenszyklus integriert mit den Unternehmensprozessen zu behandeln, um Konsistenz und Sicherheit zu gewährleisten.

• Joiner (Onboarding): Wenn ein neuer Mitarbeiter oder externer Nutzer ins Unternehmen (oder in den betreffenden Fachbereich) eintritt, muss entschieden werden, ob er einen Zugriff auf das CAFM benötigt. In vielen Fällen liefert das HR-System den initialen Anstoß – z.B. wird ein Eintrag „Neuer Mitarbeiter in Abteilung Facility Management“ erzeugt. Das IAM/AD legt daraufhin ein Benutzerkonto an (mit E-Mail, AD-Zugang etc.). In einem integrierten Szenario würde dieser Schritt auch gleich ins CAFM durchschlagen: entweder durch automatisches Provisionieren des Accounts über eine Schnittstelle, oder zumindest durch einen festen Prozessschritt, in dem der CAFM-Admin die Anlage vornimmt. Standard-Berechtigungen („birthright access“) für neue Nutzer sollten definiert sein – z.B. erhalten alle neuen FM-Mitarbeiter automatisch eine Basisrolle, die Zugriff auf allgemeine Funktionen gibt (Lesen von Gebäudeplänen, Melden von Störungen etc.). Diese könnten via Rollenmapping (AD-Gruppe -> CAFM-Rolle) oder via Templates direkt vergeben werden. Wichtig beim Onboarding ist die zeitnahe Durchführung – ein neuer Kollege sollte idealerweise am ersten Arbeitstag Zugriff auf alle benötigten Systeme haben, damit er produktiv starten kann. Verzögerungen öffnen oft die Tür für Workarounds (Account-Sharing, unsichere Übergangslösungen). Zudem müssen beim Onboarding Sicherheitsvorgaben umgesetzt werden: Der Nutzer bekommt initial einen sicheren Login (z.B. initiales Passwort mit erzwungener Änderung, oder bereits einen MFA-Setup-Prozess) und es wird sichergestellt, dass er nur auf die für ihn vorgesehenen Daten Zugriff hat (Prinzip der minimalen Rechte von Anfang an).

• Mover (Änderungen während der Zugehörigkeit): Im Laufe der Zeit können sich für einen Benutzer Änderungen ergeben – Wechsel der Abteilung oder Rolle, zusätzliche Aufgaben etc. Hier muss der Berechtigungsumfang angepasst werden, damit keine „Privilegienansammlung“ entsteht. Beispielsweise wird ein CAFM-Sachbearbeiter zum Teamleiter befördert: Er benötigt nun die Rolle „Freigabe Verantwortlicher“, sollte aber eventuell einige operative Rechte abgeben. Der Prozess sieht vor, dass das Änderungsereignis (z.B. neue Stelle in HR eingepflegt) wieder vom IAM erkannt wird. Idealerweise geschieht die Anpassung automatisch: die neue Abteilungszugehörigkeit sorgt für neue Gruppenmitgliedschaften, die via RBAC neue Rechte im CAFM ergeben, während alte Gruppen entzogen werden (z.B. keine „Sachbearbeiter“-Rolle mehr). Wo Automatik nicht möglich ist, müssen zumindest manuelle Workflows sicherstellen, dass Verantwortliche die Berechtigungen überprüfen (Rezertifizierung bei Rollenwechsel). Jeder Wechsel birgt das Risiko, dass veraltete Berechtigungen liegen bleiben – das IAM/IGA sollte deshalb Mechanismen haben wie „wenn Abteilung ≠ X, entziehe Rolle Y“. Ein guter JML-Prozess verhindert so „Access Creep“ und hält das Rechteprofil eines Nutzers stets aktuell. Im CAFM kann das auch bedeuten, dass ein Mitarbeiter bei Wechsel in eine andere Region nun nur noch die Daten seiner neuen Region sieht und die alten Standorte nicht mehr zugreifen kann.

• Leaver (Offboarding): Verlässt ein Benutzer das Unternehmen oder die berechtigte Organisation, muss sein Zugriff unverzüglich entzogen werden. Dies ist ein kritischer Moment, da ehemalige Mitarbeiter ein erhebliches Sicherheitsrisiko darstellen, wenn ihre Accounts aktiv bleiben. Der Offboarding-Prozess sollte vorsehen, dass sofort mit Wirksamwerden (z.B. am Tag nach dem Austrittsdatum) das Benutzerkonto im zentralen Verzeichnis deaktiviert wird – und damit via SSO auch kein Zugang mehr ins CAFM möglich ist. Zudem sollten direkt alle Rollen/Zugriffsrechte entzogen oder das Konto gelöscht werden. Oft wird aus Compliance-Gründen das Konto zunächst „gesperrt“ und erst nach einer Aufbewahrungsfrist endgültig gelöscht. Das kann relevant sein, wenn im CAFM noch Aktionen nachvollzogen werden müssen (Audit-Trail) oder Datenübergaben stattfinden (z.B. offene Tickets des Users müssen neu zugewiesen werden). Wichtig: Das Offboarding sollte vollständig sein – viele Schwachstellen entstehen dadurch, dass man zwar das AD-Konto deaktiviert, aber vergisst, separat im CAFM angelegte lokale Accounts zu entfernen, oder liegen gelassene API-Keys weiter gültig sind. Daher idealerweise zentrales Offboarding: ein integrativer Prozess, der alle Systeme umfasst (dokumentiert z.B. in einer Offboarding-Checkliste oder automatisiert via Skripte). Dazu gehört auch, Service-Accounts oder generische Accounts zu behandeln, wenn der Mitarbeiter diese kannte (Passwort ändern etc.).

• Reboarding und temporäre Accounts: Falls ein Benutzer nach Abwesenheit zurückkommt (z.B. Elternzeit) oder externer Dienstleister für einen Zeitraum Zugang braucht, sollte der Prozess das ebenfalls abbilden. Externe könnten befristete Konten erhalten, die automatisch zum Projektende deaktiviert werden. Intern kann es Sinn machen, ein „leaving“ erst zu finalisieren, wenn wirklich alle Zugriffe geregelt sind (z.B. falls ein Mitarbeiter intern wechselt, erst neuen Zugriff geben, dann alten entziehen, um Arbeitsfähigkeit zu erhalten – aber strikt zeitlich koordiniert).

Über den gesamten Lifecycle hinweg ist Transparenz und Dokumentation wichtig. Jeder Anlage, jede Rollenänderung und Deaktivierung sollte protokolliert werden (Wer hat wann was veranlasst), um bei Audits nachweisen zu können, dass Zugriffe korrekt vergeben wurde. Moderne IAM-Lösungen bieten hierfür Audit-Trails und Reporting, was auch für das CAFM relevant ist. Mindestens sollte der CAFM-Administrator periodisch Abgleiche fahren: welche Nutzer sind im CAFM aktiv, die laut HR schon weg sein müssten (Stichwort „Orphan Accounts“ – sollten keine vorhanden sein, und wenn doch, schnell entfernen).

Insgesamt stellt ein gutes Identity Lifecycle Management im CAFM sicher, dass jeder Benutzerzugang aktuell, berechtigt und überprüft ist. Es minimiert Sicherheitslücken (keine aktiven Accounts von Ex-Mitarbeitern), reduziert manuellen Aufwand durch Automatisierung und stellt Konsistenz her – ein Muss für sichere Betriebsabläufe.

Governance im Kontext der IAM-Architektur bedeutet, die richtigen organisatorischen Rahmenbedingungen und Kontrollen zu schaffen, damit das technische Sicherheitskonzept auch gelebt wird und den Anforderungen von Gesetzen und Richtlinien entspricht. Für ein CAFM-System sollten klare Sicherheitsrichtlinien und Zuständigkeiten definiert sein. Dazu zählt zunächst die Betriebsorganisation: Wer ist Owner des Systems (fachlich und technisch)? Wer darf Administratorrechte vergeben? Welche Stelle ist für die regelmäßige Überprüfung der Berechtigungen zuständig? Solche Fragen sollten in einer Sicherheitsrichtlinie oder Betriebsdokumentation beantwortet werden.

Ein zentrales Prinzip ist das bereits erwähnte Vier-Augen-Prinzip. In sensiblen Bereichen sollte keine einzelne Person allein umfassende Kontrolle haben. Beispielsweise könnte man festlegen, dass Änderungen an den globalen CAFM-Rollen nur durch zwei gemeinsam agierende Administratoren erfolgen dürfen (einer macht, ein zweiter kontrolliert und bestätigt). Oder dass die Vergabe einer hochprivilegierten Rolle (z.B. „CAFM-Serveradmin“) eine Freigabe durch den Informationssicherheitsbeauftragten erfordert. Diese organisatorischen Hürden verhindern Missbrauch und Versehen und schaffen Verantwortungsbewusstsein.

Weiterhin sollte eine SoD-Matrix (Segregation of Duties) erarbeitet werden, die unzulässige Rollenkombinationen bzw. Konzentrationen von Macht aufdeckt. Wie bei den Beispielen oben: Jemand, der Bestellungen auslösen kann, darf nicht derjenige sein, der sie genehmigt; jemand mit Systemvollzugriff sollte nicht zugleich der interne Prüfer sein, etc. Diese Matrix kann im IAM-System oder manuell überwacht werden. Im Rahmen der Governance ist festzulegen, wer diese Matrix pflegt und die Einhaltung kontrolliert.

Regelmäßige Audits und Rezertifizierungen sind eine wesentliche Governance-Komponente. Mindestens einmal im Jahr (besser quartalsweise für kritische Rechte) sollte ein Access Review stattfinden: Dabei erhalten z.B. alle Abteilungsleiter eine Liste der CAFM-Zugriffe ihrer Mitarbeiter und müssen bestätigen, ob diese noch stimmig sind. Unnötige Zugriffe werden entzogen. Solche Rezertifizierungen sind auch von Standards wie ISO 27001 oder PCI DSS gefordert und stellen sicher, dass Altlasten bereinigt werden. Das CAFM muss hierfür Berichte liefern können, z.B. „Wer hat Adminrechte?“ oder „Welche Benutzer haben Zugriff auf Modul X?“. Idealerweise unterstützt das IAM-System diese Rezertifizierung mit Workflows.

Compliance-Aspekte betreffen auch den Datenschutz (DSGVO) und branchenspezifische Vorgaben. Eine gute Governance sorgt dafür, dass z.B. persönliche Daten im CAFM (etwa in Personalaktenmodulen oder Besucherverwaltungen) nur von Berechtigten eingesehen werden können und dass Zugriffe auf solche Daten geloggt und auswertbar sind. Im Falle von Anfragen (Stichwort Betroffenenrechte nach DSGVO) muss man auskunftsfähig sein, wer auf welche personenbezogenen Daten zugegriffen hat.

Die Richtlinien sollten auch den Umgang mit Service-Accounts und Drittzugriffen regeln. Z.B.: Dürfen Hersteller oder Dienstleister auf das System zugreifen (Remote Support)? Falls ja, nur unter bestimmten Auflagen (zeitlich begrenzt, nur in Anwesenheit eines internen Admins, Nutzung eines separaten Monitoring-Accounts etc.). Derartige Third-Party Access Kontrollen sind Teil der Governance, damit externe nicht dauerhaft versteckte Zugänge haben.

Ein oft empfohlenes Element ist ein „Break-Glass“-Verfahren: Das ist ein Notfallzugang, falls z.B. alle Admins ausfallen oder man schnell eingreifen muss. Governance legt fest, wo die Zugangsdaten hinterlegt sind (versiegelter Umschlag o.ä.), wer sie im Ernstfall öffnen darf, und dass nach Gebrauch sofort Passwörter geändert und der Vorfall protokolliert wird. So ein Prozess stellt sicher, dass auch in Krisenfällen der Systemzugriff möglich ist, ohne die täglichen Kontrollen zu unterwandern.

Schulung und Bewusstsein gehören ebenfalls zur Governance. Die besten Prozesse nutzen wenig, wenn die Beteiligten sie nicht kennen oder nicht befolgen. Daher sollte es für Administratoren und Rechtevergeber regelmäßige Schulungen geben sowie klar verständliche Dokumentationen (z.B. Handbuch „CAFM-Berechtigungen verwalten“).

Es schafft Governance den Ordnungsrahmen: Policies definieren was erlaubt und was verboten ist, Verantwortlichkeiten legen fest, wer was tut, und Kontrollmechanismen wie Audits oder das Vier-Augen-Prinzip überwachen die Einhaltung. So wird die technische Sicherheitarchitektur abgestützt durch organisatorische Maßnahmen, was zusammen ein deutlich höheres Sicherheitsniveau ergibt, als Technik oder Organisation alleine.

Damit all die beschriebenen Sicherheitsmaßnahmen greifen, muss auch das CAFM-System selbst bestimmte Funktionen und Eigenschaften mitbringen. Schon bei der Auswahl bzw.

• Flexibles Rollen- und Rechtemodell: Die Software sollte ein granulares RBAC unterstützen, d.h. die Fähigkeit, eigene Rollen anzulegen, Berechtigungen fein zu steuern (möglichst bis auf Objekt- oder Feldebene, falls erforderlich) und Rollen zu kombinieren. Ein starres Rechtekonzept würde den Bedürfnissen großer Organisationen kaum gerecht. Optimal ist auch die Unterstützung von Hierarchien oder Vererbungen im Rollenmodell (z.B. Rollen, die andere Rollen enthalten) sowie Mandantenfähigkeit im Berechtigungssystem (z.B. durch Tenant-IDs in allen relevanten Datensätzen).

• Externe Authentifizierung/Schnittstellen: Das System muss SSO-fähig sein, also Protokolle wie SAML 2.0 oder OpenID Connect unterstützen und konfigurierbar integrieren können. Ebenso sollte es LDAP/AD-Anbindung out-of-the-box bieten (für On-Premises-Szenarien). Eine dokumentierte API für Benutzer- und Rechte-Provisionierung ist wünschenswert – entweder proprietär oder per SCIM – damit man Benutzer automatisiert anlegen/ändern/löschen kann. Einige CAFM-Systeme erlauben auch die just-in-time Provisionierung via SSO (d.h. wenn sich ein unbekannter AD-Benutzer erstmals anmeldet, wird sein Account automatisch im CAFM erstellt und Grundrechte zugeteilt). Wenn das in der Praxis gewünscht ist, sollte das System dies können.

• Audit-Trail und Logging-Funktionen: Ein CAFM-System muss jede sicherheitsrelevante Aktion protokollieren können (siehe Logging-Abschnitt). Dazu gehört ein integriertes Audit-Log-Modul, in dem mindestens Änderungen an Stammdaten, Benutzer-/Rollenänderungen und sonstige Admin-Aktionen festgehalten werden (idealerweise unveränderbar oder mit Prüfsummen). Zudem sollte es Schnittstellen zur Log-Ausleitung geben – z.B. die Möglichkeit, Syslog zu konfigurieren, oder einen zentralen Logging-Endpunkt anzugeben. Falls das System bereits gängige SIEMs unterstützt (z.B. ein Splunk-App bereitstellt), umso besser. In diesem Zusammenhang sind auch Echtzeit-Benachrichtigungen nützlich: Kann das System bei bestimmten Events (z.B. fehlgeschlagenes Login, Datenexport) sofort einen Alert oder Mail senden? Das wäre ein Plus.

• Sichere API: Wenn das CAFM eine API zur Verfügung stellt (und das tun heute die meisten, z.B. REST-API für mobile Apps), dann sollte diese Sicherheitsmechanismen mitbringen: Token-basierte Auth (OAuth2, JWT) anstelle von statischen API-Keys wo möglich, konfigurierbare Zugriffsbeschränkungen (z.B. welcher API-Client darf welche Endpunkte) und ggf. Rate Limiting Einstellungen. Ein gutes Zeichen ist, wenn der Hersteller auf OWASP API Security Richtlinien verweist oder Zertifizierungen hat.

• Passwort- und Kryptographie: Falls das System doch Benutzer-intern verwaltet (z.B. für Lokalanmeldungen oder API-Keys), müssen Passwörter sicher gehasht gespeichert werden (aktueller Stand: bcrypt, Argon2 o.ä., nicht im Klartext oder MD5!). Ebenso sollten Kommunikationswege TLS-verschlüsselt sein – insbesondere wenn das CAFM in der Cloud angeboten wird, sind HTTPS und aktuelle TLS-Versionen Pflicht. Das System sollte kompatibel mit den unternehmensweiten Kryptopolicies sein (z.B. Unterstützung von Smartcards oder Clientzertifikaten falls gefordert).

• Mandantenfähigkeit und Datenisolation: Wenn geplant ist, die Lösung für mehrere Mandanten oder Organisationsbereiche einzusetzen, muss die Software technische Mandantentrennung gewährleisten. Im Idealfall hat jeder Mandant seine eigene Datenbank oder Schema, oder es gibt zumindest eine strikte Filterung auf Mandanten-ID in allen Queries. Multi-Tenancy sollte dokumentiert sein. Auch sollten Mandanten-Admins nur Benutzer ihres Mandanten sehen und verwalten können, nicht andere.

• Benutzerfreundliches Berechtigungsmanagement: In der Praxis zeigt sich, dass komplexe Sicherheitskonzepte nur dann umgesetzt werden, wenn die Software die Administration erleichtert. Das CAFM sollte daher eine übersichtliche Oberfläche für die Rechteverwaltung haben, mit der man z.B. sehen kann, welcher Nutzer welche Rollen hat und umgekehrt. Massenpflege (mehrere Nutzer auf einmal Rolle zuweisen) ist hilfreich. Ideal ist, wenn das System Rollenvorlagen oder einen Rechteexport (nach Excel) bietet, damit man das Konzept extern prüfen/entwickeln kann.

• Integrationsfähigkeit: Neben IAM sollte das CAFM auch an andere Systeme (BMS, ERP, etc.) angebunden werden können. Sicherheitsseitig heißt das, es muss Schnittstellen-User mit minimalen Rechten dafür geben, ggf. Zertifikatsauthentifizierung für Integrationen und ein Transaktionslogging um nachzuvollziehen, welche Daten über die Schnittstellen laufen. Für Cloud-Lösungen wichtig: Unterstützung von OAuth2 Client Credentials für die Machine-to-Machine Kopplung.

• Patching und Updates: Ein sicheres System erfordert, dass bekannte Schwachstellen schnell geschlossen werden. Daher ist es wichtig, dass der Hersteller regelmäßig Security Updates liefert und das System ohne riesigen Aufwand aktualisiert werden kann. Das gehört zwar nicht direkt zur Architektur, aber als Anforderung an den Betrieb.

Diese (nicht abschließenden) Punkte sollten bei der Planung und Auswahl berücksichtigt werden. Oft lohnt es sich, mit einer Security Checkliste an den Anbieter heranzutreten oder ein kleines Proof-of-Concept durchzuführen, um z.B. SSO und Logging einmal Ende-zu-Ende zu testen, bevor man produktiv geht.

Abschließend soll ein Überblick über bewährte Praktiken und häufige Fehler gegeben werden, um aus Erfahrungen zu lernen.

• Least Privilege & Rollenpflege: Richte von Anfang an ein strikt auf Minimalprinzip basierendes Rollenmodell ein. Definiere Standardrollen mit genau den Rechten, die benötigt werden, und vermeide individuelle Sonderrechte. Führe neue Rollen nur ein, wenn wirklich erforderlich, um eine Rollenexplosion (unzählige kaum überschaubare Rollen) zu vermeiden. Nutze wo möglich temporäre Rechte (z.B. eine Rolle, die nach 24h automatisch entzogen wird für Ad-hoc-Admin-Aufgaben).

• Multi-Faktor-Authentifizierung überall: Erzwinge MFA für alle sensiblen Zugriffe, insbesondere für Admin-Logins und externe Zugriffe. In vielen Unternehmen ist MFA inzwischen Standard für alle Nutzer, was die Sicherheit deutlich erhöht.

• Automatisierung des Benutzer-Lifecycles: Kopple das CAFM an das zentrale IAM/HR, sodass On- und Offboarding nicht vergessen gehen. Ein hoher Automatisierungsgrad (z.B. via SCIM-Provisionierung) reduziert manuelle Fehler und stellt sicher, dass kein ehemaliger Mitarbeiter Zugriff behält. Ebenso sollten Rechte bei Funktionswechsel automatisch angepasst werden (z.B. durch datengetriebene Business Rules im IAM).

• Regelmäßige Rezertifizierung: Implementiere einen Prozess, bei dem mindestens jährlich alle Zugriffsrechte überprüft werden. Für hochkritische Rollen (Admins) ruhig öfter (vierteljährlich). Lass dies idealerweise vom Fachvorgesetzten durchführen, da dieser am besten weiß, wer welche Rechte noch benötigt.

• Logging-Monitoring: Sammle die Logs zentral und werte sie proaktiv aus. Definiere Alarmierungen für bestimmte Ereignisse (z.B. 5 fehlgeschlagene Logins in 5 Minuten, Änderung einer kritischen Konfiguration). Ein SIEM oder zumindest ein Log-Analyse-Tool kann dabei helfen. Schaffe klare Zuständigkeiten: Wer schaut sich Auffälligkeiten an? Wie ist das Incident Response Vorgehen, wenn etwas Verdächtiges im Log erscheint?

• Trennung von Umgebungen und Rechten: In einer produktiven Umgebung sollten Admin-Tätigkeiten möglichst nicht mit Normalnutzer-Konten durchgeführt werden. Verwende dedizierte Admin-Accounts und trenne auch Test/Staging-Umgebungen von Produktion. So vermeidet man, dass jemand versehentlich in Prod agiert, und erhöht die Nachvollziehbarkeit (weil Admin-Accounts seltener benutzt werden und im Log sofort auffallen).

• Patching und Hardening: Halte das CAFM-System und seine Komponenten (Server-OS, Webserver, DB) aktuell. Schließe unnötige Dienste, setze sichere Konfigurationen (z.B. Content Security Policy im Webserver, um XSS zu verhindern). Führe evtl. regelmäßige Schwachstellen-Scans auf die Anwendung durch (viele Hersteller bieten Penetrationstest-Zertifikate, frag danach).

• Dokumentation & Schulung: Sorge dafür, dass alle Prozesse dokumentiert sind (Benutzeranlage, Rechtevergabe, Incident Management). Schulen die Administratoren und auch Endanwender (z.B. im sicheren Umgang mit dem System, Melden von Sicherheitsvorfällen). Security Awareness ist ein fortlaufender Prozess – gerade Admins sollten über aktuelle Bedrohungen informiert sein (Passwortphishing etc.).

• Notfallpläne: Etabliere einen Notfallprozess (Break-Glass) für den Fall, dass z.B. SSO ausfällt und keiner mehr ins CAFM kommt. Mögliche Maßnahmen: ein Backup-Admin-Login lokal, der in Tresor liegt, oder die Fähigkeit, temporär auf LDAP-Login umzuschalten. Teste solche Szenarien gelegentlich, um sicher zu sein, dass sie im Ernstfall funktionieren.

• Überzogene Standardrechte: Oft werden initial zu breite Rechte vergeben (z.B. bekommt jeder Nutzer aus Bequemlichkeit gleich sehr hohe Rechte). Dies widerspricht dem Least Privilege Prinzip und führt zu unnötig hohem Schadenspotenzial. Besser klein anfangen und bei Bedarf erhöhen.

• „Role-Creep“ und fehlende Kontrolle: Nutzer wechseln intern die Position und sammeln im Laufe der Zeit immer mehr Rechte an, weil alte nicht entzogen werden. Solche Schattenberechtigungen bleiben oft unentdeckt ohne regelmäßige Überprüfung.

• Geteilte Accounts: In der Hektik werden manchmal Accounts gemeinsam genutzt (z.B. ein generisches „Techniker“ Login für Nachtschicht). Das ist eine schlechte Praxis, da weder Verantwortlichkeit noch Revisionsfähigkeit gewährleistet sind. Jede Person sollte ihren eigenen Zugang haben; für technische Zwecke lieber Dienstkonten pro Integration mit klarer Zuordnung.

• Unzureichende Offboarding-Prozesse: Ein Klassiker ist, dass Accounts ehemaliger Nutzer aktiv bleiben. Sei es, weil vergessen wurde sie zu löschen, oder weil man hoffte, der Mitarbeiter käme zurück. Solche Accounts sind Einfallstore – konsequentes Deaktivieren ist Pflicht. Dazu gehört auch, Zugriffe auf Backups, alte Administratorenkennungen, VPN-Accounts etc. im Blick zu haben.

• Fehlende Governance bei technischen Accounts: Service-Accounts werden oft mit Dauer-Adminrechten ausgestattet und dann nie wieder betrachtet. Ohne Rotation von Zugangsdaten und regelmäßige Prüfung können diese zum Schwachpunkt werden (z.B. hartkodiertes Passwort in Skripten, das seit Jahren gleich ist).

• Zu viel Vertrauen in Netzwerkgrenzen: Manche verlassen sich darauf, dass das CAFM intern im LAN ist oder hinter VPN und verzichten auf starke Authentifizierung oder Verschlüsselung. Das ist gefährlich, da Angriffe auch von innen passieren können und VPNs kompromittiert werden können. Immer Zero-Trust-Denken: Jede Schicht schützen.

• Schwachstellen in Schnittstellen: Ein häufiger Fehler ist, die API-Sicherheit zu vernachlässigen. Z.B. einen API-Endpunkt nicht zu authentifizieren, weil „kennt ja keiner die URL“ – solche Security by Obscurity rächt sich. Ebenso das Fehlen von Rate Limiting, was zu DoS ausgenutzt werden kann.

• Schlecht konfigurierte Logging-Praxis: Entweder wird zu wenig geloggt (wichtige Ereignisse fehlen) oder zu viel ungefiltert (Performance leidet, Privacy verletzt). Auch das Nicht-Auswerten der Logs ist ein Fehler – Logs ohne Monitoring sind wie Kameras ohne dass je jemand hinschaut. Zudem werden Logs manchmal zu lang aufbewahrt oder nicht ordnungsgemäß gesichert, was gegen Datenschutz verstoßen kann.

• Dokumentations- und Schulungsmangel: Wenn Admins sich „durchwursteln“ ohne klare Anleitungen, passieren Fehler. Ebenso, wenn bei Personalwechsel Wissen verloren geht. Das Fehlen von aktueller Dokumentation und Training führt oft zu Fehlbedienungen oder dazu, dass Sicherheitsfunktionen ungenutzt bleiben.

Diese Liste ist nicht abschließend, zeigt aber die häufigsten Problemfelder. Indem man sich dieser Schwachstellen bewusst ist, kann man gezielt gegensteuern. Zusammen mit den zuvor genannten Best Practices lässt sich eine robuste Security/IAM-Architektur für das CAFM etablieren, die sowohl den Schutz der sensiblen Gebäudedaten gewährleistet, als auch Compliance-Anforderungen erfüllt und den Benutzern eine möglichst einfache, sichere Nutzung ermöglicht. Schließlich ist das Ziel, dass die Sicherheit nicht als Hürde empfunden wird, sondern als integraler, unterstützender Bestandteil des Gesamtsystems – Security by Design im besten Sinne.