Bei einem Audit fragt niemand „Wer hat Zugriff auf das ERP?“. Gefragt wird „Wer darf im ERP eine Buchung LÖSCHEN?“ – und die Zugriffstabelle kann das selten beantworten. Access Matrix holt diese Entscheidungsmatrix ins GLPI: externe Systeme, ihre Module und vier CRUD-Flags (Erstellen, Lesen, Aktualisieren, Löschen), aufgelöst nach Funktion, Gruppe und Benutzer. Dieser Leitfaden zeigt das Auflösungsmodell, eine SQL-Diagnose direkt in der Datenbank, das Migrationsformat zwischen Umgebungen und die Stolperfallen, die erst in der Produktion auftauchen.
Das eigentliche Problem: die Tabelle, der niemand vertraut
Im Betriebssupport von Kundenumgebungen ist es immer dieselbe Anforderung, die die Schwäche der Steuerung per Tabelle offenlegt. Ein Audit steht an (ISO 27001, SOX oder ein Zugriffsbericht für die LGPD), und die Anforderung ist granular: „Listen Sie alle Funktionen auf, die im Finanzsystem Datensätze erstellen und löschen dürfen.“ Eine Tabelle mit „hat Zugriff / hat keinen Zugriff“ beantwortet das nicht: Sie trennt Lesen nicht von Schreiben, hat keinen Verlauf, wer was geändert hat, und ist bereits veraltet, weil das letzte Ausscheiden eines Mitarbeiters nicht nachgetragen wurde. Access Matrix schließt diese Lücke: Es modelliert den Zugriff in CRUD-Granularität und hält alles im GLPI, zusammen mit dem übrigen Service-Desk-Betrieb.
Was das Modul modelliert: Systeme, Module und vier Flags
Die Struktur ist bewusst einfach. Sie erfassen die externen Systeme (ERP, CRM, BI, Portale von Drittanbietern) und darin die relevanten Module (zum Beispiel „Kreditorenbuchhaltung“, „Fakturierung“, „Berichte“). Für jede Kombination aus Funktion und Modul setzen Sie vier Checkboxen: Erstellen, Lesen, Aktualisieren, Löschen. Eine Berechtigung kann auf Ebene des gesamten Systems oder pro Modul definiert werden. In der Datenbank werden daraus die Spalten can_create, can_read, can_update, can_delete (tinyint 0/1), mit dem Modul auf NULL, wenn die Regel für das ganze System gilt.
Eine ehrliche und wichtige Klarstellung: Access Matrix ist kein Proxy, der die Anmeldung im ERP blockiert, und greift nicht in das externe System ein. Es ist die maßgebliche Entscheidungsmatrix – die verlässliche Quelle, die dokumentiert, auflöst und anzeigt, wer welche Berechtigung haben soll, damit das Team, das den Zugriff einrichtet (oder der Auditor, der ihn prüft), mit verlässlichen Daten im GLPI arbeitet und nicht mit einer losen Tabelle.
Auflösung in 4 Schichten (ODER: die großzügigste gewinnt)
Die effektive Berechtigung eines Benutzers stammt nicht aus einer einzigen Quelle. Das Modul kombiniert vier Quellen mit ODER-Logik – für jedes CRUD-Flag gilt: Gewährt irgendeine Schicht es, hat der Benutzer es. In der Praxis ist das Ergebnis jedes Flags ein max() über die Schichten:
- Funktion des Benutzers – das Feld, das die Funktion definiert, ist konfigurierbar (Kategorie, Titel oder Standardgruppe des GLPI), über den Parameter
role_source. - Mit der Funktion verknüpfte Berechtigungsgruppen – wiederverwendbare CRUD-Sätze, die der Funktion zugewiesen sind.
- Direkt mit dem Benutzer verknüpfte Berechtigungsgruppen – punktuelle Ausnahmen, ohne die Funktion anzufassen.
- Individuelle Berechtigungen, die direkt dem Konto zugewiesen sind.
| # | Schicht | Herkunft im Benutzerdatensatz | Wofür sie dient |
|---|---|---|---|
| 1 | Funktion | Kategorie / Titel / Standardgruppe (Konfiguration role_source) | Basiszugriff nach Funktion |
| 2 | Berechtigungsgruppe der Funktion | Verknüpfung Funktion → Gruppe | Wiederverwendbares Paket für mehrere Funktionen |
| 3 | Berechtigungsgruppe des Benutzers | Verknüpfung Benutzer → Gruppe | Ausnahme, ohne die Funktion zu ändern |
| 4 | Individuelle Berechtigung | Direkt am Konto | Punktuelle Feinjustierung |
Im Abfrage-Reiter zeigt das Modul die effektive Berechtigung jedes Benutzers mit Badges an, die angeben, aus welcher Schicht jeder Zugriff stammt (Funktion, Gruppe oder Individuell) – das macht die Auflösung prüfbar statt zur Blackbox.
Diagnose direkt in der Datenbank (SQL)
Bei einem Audit lautet die häufigste Frage: „Wer darf in jedem System schreiben (erstellen, aktualisieren oder löschen)?“ Das lässt sich mit einem SELECT direkt auf der Tabelle der Berechtigungen pro Funktion beantworten. Das folgende Beispiel geht von der Standardquelle aus (usercategories_id, die Kategorie des Benutzers) und listet nur diejenigen, die irgendein Schreib-Flag haben:
-- Cargos (Categoria do usuario) com poder de ESCRITA em cada sistema externo
-- Fonte de cargo padrao = usercategories_id
SELECT s.name AS sistema,
COALESCE(m.name, '(sistema inteiro)') AS modulo,
c.name AS cargo,
p.can_create, p.can_update, p.can_delete
FROM glpi_plugin_nextool_accessmatrix_perm_categories p
JOIN glpi_plugin_nextool_accessmatrix_systems s
ON s.id = p.plugin_nextool_accessmatrix_systems_id
LEFT JOIN glpi_plugin_nextool_accessmatrix_modules m
ON m.id = p.plugin_nextool_accessmatrix_modules_id
JOIN glpi_usercategories c
ON c.id = p.usercategories_id
WHERE p.can_create = 1 OR p.can_update = 1 OR p.can_delete = 1
ORDER BY s.name, cargo;Dieses SELECT ist rein lesend und deckt die Funktionsschicht (die Basis) ab. Die endgültige effektive Berechtigung – unter Einbeziehung von Gruppen und individuellen Anpassungen mit dem ODER der 4 Schichten – wird vom Modul in PHP aufgelöst; nutzen Sie den Abfrage-Reiter für den konsolidierten Wert pro Benutzer. Das SQL dient für schnelle Audit-Durchläufe, bevor Sie tiefer gehen.
Migration zwischen Umgebungen: Import/Export per CSV
Die Matrix in der Testumgebung zu konfigurieren und in die Produktion zu übernehmen, ohne alles von Hand neu anzulegen, erfolgt per Import/Export als CSV. Der Export erzeugt eine einzige Datei mit Systemen, Modulen und Berechtigungen im Format:
type,system_name,module_name,comment,is_active,role_source,role_id,can_create,can_read,can_update,can_delete
system,ERP Protheus,,Gestao financeira,1,,0,0,0,0,0
module,ERP Protheus,Contas a Pagar,,1,,0,0,0,0,0
permission,ERP Protheus,Contas a Pagar,,0,usercategories_id,5,1,1,1,0
permission,ERP Protheus,,,0,groups_id,12,0,1,0,0Die Spalte type unterscheidet Zeilen für System, Modul und Berechtigung; in den Berechtigungszeilen gibt role_source an, aus welcher Schicht diese Regel stammt. Vor dem Anwenden zeigt das Modul eine Vorschau der Änderungen und speichert ein automatisches Backup (JSON-Snapshot) des vorherigen Zustands, um zurückzusetzen, falls etwas anders ausfällt als erwartet.
Integration ins Ticket
Im Formular jedes Tickets erscheint ein eigener Reiter, der den Anforderer bereits vorauswählt und dessen effektive Berechtigungen anzeigt. Wenn ein Ticket der Art „Schalten Sie Person X im Modul Y des ERP frei“ eingeht, sieht der Techniker sofort, was dieser Benutzer in jedem System bereits hat – ohne das Ticket zu verlassen, ohne einen anderen Bildschirm zu öffnen, ohne von besagter Tabelle abhängig zu sein.
Stolperfallen aus der Praxis (der häufige Fehler ist …)
Drei Details zeigen sich erst, wenn die Matrix im Einsatz ist, und stammen aus direkter Betriebserfahrung:
- ODER entzieht nie. Der häufige Fehler ist, einen Zugriff „wegnehmen“ zu wollen, indem man die Flags in der individuellen Schicht des Benutzers abwählt, während eine Berechtigungsgruppe dieses CRUD weiterhin gewährt. Da die Auflösung ODER ist (die großzügigste gewinnt), gilt die Berechtigung weiter. Es gibt kein „Verweigern“, das ein „Gewähren“ einer anderen Schicht überschreibt: Um wirklich zu entziehen, entfernen Sie es aus der Schicht, die es gewährt.
- Ein Benutzer ohne ausgefüllte Funktion erbt die Funktionsmatrix nicht. Wenn Sie die Quelle auf Kategorie gesetzt haben, im Benutzerkonto aber die Kategorie leer ist, greift Schicht 1 schlicht nicht – es gelten nur die Gruppen des Benutzers und die individuellen Berechtigungen. Das Modul weist in der Abfrage darauf hin, aber das Symptom im Alltag lautet: „Ich habe die Funktion konfiguriert, und der Benutzer hat immer noch keinen Zugriff.“ Prüfen Sie das Funktionsfeld im Benutzerdatensatz, bevor Sie das Modul verdächtigen.
- Das Wechseln der Funktionsquelle löscht Ihre Konfiguration nicht. Wenn Sie
role_sourcevon Kategorie auf Titel umstellen, verschwinden die nach Kategorie gespeicherten Berechtigungen nicht – sie ruhen in der Datenbank und werden nicht mehr angezeigt, solange nicht ihr Modus aktiv ist. Kehren Sie zur alten Quelle zurück, ist alles wieder da. Experimentieren ist also gefahrlos, aber wissen Sie: „Alles ist weg“ nach dem Wechsel der Quelle ist fast immer genau das, kein Datenverlust.
Die Matrix einmal zu modellieren ist der leichte Teil; sie bei Austritten, Funktionswechseln und wiederkehrenden Audits stimmig zu halten, ist Betriebssupport. Genau das macht NexTool: Lernen Sie Access Matrix kennen oder sprechen Sie mit dem GLPI-Betriebssupport von NexTool, um die Zugriffssteuerung auf externe Systeme mit Governance und Audit-Trail aufzubauen.
Geprüft vom Team der NexTool Solutions.
