NexTool Solutions

In GLPI ist eine Berechtigung kein Ein-/Aus-Schalter: Sie ist ein Produkt aus drei Achsen, die sich multiplizieren - Profil, Einheit und Oberfläche. Eine falsche Kombination ist die häufigste Ursache für Tickets zu „verschwundenem Zugriff“ und für Sichtbarkeitslecks zwischen Abteilungen. Diese Anleitung zeigt das reale Modell, wo die Rechte in der Datenbank liegen und welche Fallen nur in Umgebungen mit mehreren Einheiten auftreten.

Das RBAC-Modell mit drei Achsen

Die Zugriffskontrolle von GLPI (RBAC, Role-Based Access Control) kombiniert drei unabhängige Dimensionen, die viele als eine einzige behandeln:

• Profil - die Menge an Rechten, also was eine Person tun darf (erstellen, bearbeiten, löschen, konfigurieren).
• Einheit - der Geltungsbereich der Daten, also wo sie etwas sieht: welche Organisation, Niederlassung oder Abteilung.
• Oberfläche - wie sie navigiert: Helpdesk (vereinfacht, für Endbenutzer) oder Central (vollständig, für den Betrieb).

Verwirrend ist, dass sich alle drei durch Zuweisung kombinieren und nicht durch automatische Vererbung. Die Tabelle glpi_profiles_users verknüpft einen Benutzer mit einem Profil innerhalb einer Einheit, mit einem Flag is_recursive, welches festlegt, ob der Zugriff an Untereinheiten weitergegeben wird. Deshalb kann ein und derselbe Benutzer Techniker in der Einheit „IT“ und Self-Service in der Einheit „Personal“ sein: Es sind zwei getrennte Zeilen in dieser Tabelle, jede mit eigenem Geltungsbereich.

Die Profilmatrix, die wir als Baseline verwenden

Statt die sieben Werksprofile von GLPI anzupassen, gehen wir von einer schlanken Matrix aus und klonen davon. Weniger Profile mit klaren Grenzen erzeugen weniger Vorfälle als zehn fast identische Profile, deren Unterschied sich niemand merkt.

Praxisregel: Wenn sich zwei Profile in einer einzigen Berechtigung unterscheiden, sollten sie wahrscheinlich eines sein. Wildwuchs bei Profilen ist technische Sicherheitsschuld: Jedes zusätzliche Profil ist eine weitere Sache, die geprüft werden muss.

Wo die Rechte wirklich liegen

Die Seite Profile (Verwaltung > Profile) ist nur eine Hülle über der Tabelle glpi_profilerights. Jede Zeile speichert ein Paar (Profil, Objekt) und eine Spalte rights, die eine ganzzahlige Bitmaske ist. Wer dies versteht, prüft ganz anders: Statt sich durch Dutzende Reiter zu klicken, lesen Sie ein Recht direkt in der Datenbank.

-- Direitos de um perfil sobre objetos-chave (o bitmask e um inteiro)
SELECT p.name    AS perfil,
       pr.name   AS objeto,
       pr.rights AS bitmask
FROM   glpi_profilerights pr
JOIN   glpi_profiles p ON p.id = pr.profiles_id
WHERE  p.name = 'Tecnico'   -- ajuste ao nome no idioma de instalacao
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Decodificacao dos bits base (validos para a maioria dos itemtypes):
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- Ex.: bitmask 15 = READ+UPDATE+CREATE+DELETE (CRUD, sem purgar)

Die Basisbits gelten für die meisten Itemtypes, aber Objekte wie ein Ticket (ticket) packen zusätzliche Flags in dieselbe Ganzzahl: Sichtbarkeit „meine / meine Gruppe / alle“, zuweisen, übernehmen, Priorität ändern. Versuchen Sie nicht, diese Bits aus dem Kopf zu erraten - prüfen Sie sie in der Oberfläche und validieren Sie sie mit einer Testsitzung, bevor Sie sich darauf verlassen.

Schnelle Diagnose: wer hat was

Bevor Sie ein Profil anfassen, halten Sie den aktuellen Zustand fest. Diese Abfrage beantwortet „Wer hat welches Profil, in welcher Einheit, und wird es an untergeordnete Einheiten weitergegeben“ - genau jenes Bild, welches bei einer Zugriffsprüfung am häufigsten fehlt:

-- Quem tem qual perfil, em qual entidade, com ou sem recursao
SELECT u.name          AS usuario,
       p.name          AS perfil,
       p.interface     AS interface,
       e.completename  AS entidade,
       pu.is_recursive AS desce_para_subentidades
FROM   glpi_profiles_users pu
JOIN   glpi_users    u ON u.id = pu.users_id
JOIN   glpi_profiles p ON p.id = pu.profiles_id
JOIN   glpi_entities e ON e.id = pu.entities_id
WHERE  u.name = 'joao.silva'
ORDER  BY e.completename;

Diese Abfrage regelmäßig auszuführen - mindestens monatlich - ist der günstige Weg, angehäufte Privilegien zu finden: ehemalige Mitglieder einer Gruppe, die weiterhin Supervisor sind, oder ein administratives Profil, welches „nur zum Testen“ zugewiesen und nie entfernt wurde. In einem ernsthaften Betrieb wird dieses SELECT zu einem geplanten Bericht und nicht zu einer manuellen Suche, wenn ein Problem bereits eingetreten ist.

Fallen aus der Praxis

Beim Betrieb von Kundenumgebungen mit mehreren Einheiten ist ein wiederkehrendes Ticket „Meine Berechtigung ist verschwunden“ fast nie ein Bug: Es ist der Sitzungscache. GLPI lädt die Rechte eines Profils beim Login in $_SESSION. Wenn Sie eine Bitmaske ändern, während ein Techniker angemeldet ist, behält er die alten Rechte, bis er im Auswahlfeld die Einheit wechselt oder sich neu anmeldet. Wir haben gelernt, „Bitten Sie ihn, sich ab- und wieder anzumelden“ fest in den Validierungsablauf aufzunehmen und immer in einer neuen oder anonymen Sitzung zu testen - sonst schwören Sie, alles richtig konfiguriert zu haben, und ein Benutzer schwört, dass es nicht funktioniert, und beide haben gleichzeitig recht.

Weitere Fallen, die häufig zu Vorfällen führen:

• Sichtbarkeit „Alle“ für Techniker - mit „Alle Tickets sehen“ sieht ein Techniker Tickets aller Einheiten, auf die er Zugriff hat, nicht nur seiner eigenen. Bei Kunden mit sensiblen Bereichen (Personal, Recht) ist dies ein stilles Leck. Bevorzugen Sie „meine Gruppe“.
• is_recursive vergessen - wird ein Profil in der Stamm-Einheit ohne Rekursion zugewiesen, sieht ein Benutzer keine einzige Untereinheit. Ein klassisches Symptom ist „Ich melde mich an, sehe aber nichts“. Umgekehrt gibt eine unnötige Rekursion zu weitreichenden Zugriff, ohne dass es jemand bemerkt.
• Central-Rechte in einem Helpdesk-Profil - die Oberfläche Helpdesk ignoriert die meisten Rechte von Central. Asset-Berechtigungen in einem Helpdesk-Profil zu setzen, bewirkt nichts; ein entsprechendes Menü existiert in dieser Oberfläche schlicht nicht.
• Zuweisungsregeln in falscher Reihenfolge - wer LDAP oder SSO nutzt, weist Profile über Regeln zur Zuweisung von Berechtigungen (RuleRight) zu. Eine generische Regel „Self-Service zuweisen“ muss zuletzt kommen; steht sie oben ohne „Verarbeitung beenden“, gewinnt sie gegen alle spezifischen Regeln, und alle landen als Self-Service.
• Nicht aus Sicht des Self-Service testen - viele Fehler zeigen sich nur in der Oberfläche Helpdesk. Halten Sie einen Testbenutzer pro Profil vor und gehen Sie die reale Nutzerreise durch, bevor Sie in Produktion freigeben.

Checkliste zur Härtung von Profilen

1. Gehen Sie von der minimalen Matrix aus; klonen Sie Profile, statt die Werksprofile zu bearbeiten.
2. Setzen Sie die Sichtbarkeit von Tickets standardmäßig auf „meine Gruppe“; „Alle“ nur mit schriftlicher Begründung.
3. Prüfen Sie das Flag is_recursive bei jeder Zuweisung zu einer Einheit.
4. Führen Sie das Diagnose-SQL monatlich aus und entfernen Sie angehäufte Privilegien.
5. Halten Sie einen Testbenutzer pro Profil vor und validieren Sie nach jeder Änderung in einer neuen Sitzung.
6. Beschränken Sie, wer Profile und Regeln bearbeitet: Ein UPDATE-Recht auf profile und rule ist in der Praxis ein Administratorrecht.

Sie brauchen eine Zugriffskontrolle für Seiten und externe Systeme direkt in GLPI, mit einer prüfbaren Matrix? Lernen Sie das Modul Access Matrix kennen. Und wenn Sie Entwurf und Betrieb der Profile auslagern möchten, implementiert und betreut NexTool GLPI-Umgebungen mit mehreren Einheiten und regelmäßig geprüfter Zugriffs-Governance.

Geprüft vom Team von NexTool Solutions.