OTOBO Znuny ACLs
Zugriffskontrolllisten (ACLs) in OTOBO sind das Fundament einer robusten Rechteverwaltung. In diesem Subthema lernen Sie:
- Konzepte und Business Value: Warum ACLs unverzichtbar sind.
- Architekturüberblick: Wie das ACL-Subsystem intern aufgebaut ist.
- Match vs. Action: Grundstruktur einer ACL.
- Systemkonfigurationen: Wichtige SysConfig-Einstellungen rund um ACLs.
1. Konzepte & Business Value
ACLs definieren, welche Aktionen Agenten und Kunden im Ticketsystem ausführen dürfen – automatisiert und kontextsensitiv.
- Sicherheit: Schützen Sie sensible Funktionen (z. B. Ticket-Schließen) vor unautorisierter Nutzung.
- Usability: Blenden Sie irrelevante Buttons oder Menüs dynamisch aus, um den Anwender nicht zu überfrachten.
- Automatisierung: Steuern Sie Ticket-Flows (Priorisierung, Eskalation, Zuweisung) direkt über ACL-Regeln, ohne zusätzlichen Code.
- Wartbarkeit: Exportieren, importieren und versionieren Sie ACLs zentral – ideal für Multi-Instanz-Umgebungen.
1.1 Rollen- und Kriterien-basierte ACLs
- Rollenbasiert: Zuweisung anhand von Agenten-Rollen oder Gruppen (z. B. Admin vs. Support-Agent).
- Kriterienbasiert: Steuerung durch Ticketattribute (Queue, Status, Priority, DynamicFields, CustomerID).
Kombination beider Ansätze ermöglicht präzise Regeln, z. B.: „Nur Senior-Agenten verschieben Tickets mit Priorität > 3 in die Entwicklung-Queue.“
2. Architektur-Überblick
Das OTOBO-ACL-Subsystem verteilt sich auf mehrere Kernkomponenten:
Komponente | Aufgabe |
---|---|
Kernel::System::ACL::DB::ACL | Perl-Backend: Persistiert und lädt ACLs aus der Datenbank |
Kernel::System::YAML | Serialisiert config_match & config_change als YAML-Text |
Kernel::System::Cache | Cacht ACL-Abfragen mit TTL (SysConfig: ACL::CacheTTL ) |
acl_sync Tabelle | Protokolliert, welche ACLs neu sind oder geändert wurden (sync_state), um Deployments zu triggern |
ZZZACL.pm | Generierte Perl-Datei, die beim Deploy alle validierten ACLs in den Ticket-Modulen bereitstellt |
perl
# Beispiel: YAML-Serialisierung vor DB-Insert
my $YAML = $Kernel::OM->Get('Kernel::System::YAML');
my $ConfigMatchYAML = $YAML->Dump(Data => $Param{ConfigMatch});
my $ConfigChangeYAML = $YAML->Dump(Data => $Param{ConfigChange});
$DBObject->Do(
SQL => 'INSERT INTO acl (..., config_match, config_change, ...) VALUES (?, ?, ?, ...)',
Bind => [\$ConfigMatchYAML, \$ConfigChangeYAML, ...],
);
Hinweis: Superuser (UserID 1) ignoriert alle ACLs automatisch – um sich nicht auszusperren.
3. Grundstruktur einer ACL: Match vs. Action
Abschnitt | Aufgabe |
---|---|
Match | Definiert Bedingungen: Ticketattribute (Properties) oder DB-Werte (PropertiesDatabase) prüfen. |
Action | Legt fest, welche UI-Elemente (Buttons, Felder) ein-/ausgeblendet werden (Possible, PossibleAdd, PossibleNot) oder welche Aktionen ausgeführt werden (Status-/Queue-Wechsel). |
Beispiel Match-Optionen:
Queue
,Status
,Priority
DynamicField_<Name>
,CustomerUser
,Owner
Frontend::Module
(AgentTicketZoom, CustomerTicketCreate)
Beispiel Action-Optionen:
Possible
: Whitelist z. B. nur bestimmte Queues oder Status zulassenPossibleAdd
: Zusätzliche Werte in begrenzter Auswahl hinzufügenPossibleNot
: Bestimmte Buttons (z. B. AgentTicketClose) aus UI entfernen
4. Wichtige SysConfig-Einstellungen
Oben genannte Kernelemente werden über SysConfig konfiguriert:
Schlüssel | Beschreibung | Beispielwert |
---|---|---|
ACL::CacheTTL | Cache-Lebensdauer in Sekunden (Backend) | 3600 |
ACLKeysLevel1MatchTicket | Erlaubte erste Ebene für Match (Properties, PropertiesDatabase) | Properties, PropertiesDatabase |
ACLKeysLevel1ChangeTicket | Erlaubte erste Ebene für Change (Possible, PossibleAdd, PossibleNot) | Possible, PossibleAdd, PossibleNot |
ACLKeysLevel2::PropertiesTicket | Erlaubte Match-Keys (Queue, State, DynamicField, etc.) | Queue, State, CustomerUser, ... |
ACLKeysLevel2::PossibleTicket | Erlaubte Change-Keys (Form, FormStd, Action, Process, Ticket) | Form, FormStd, Action, ... |
ACLKeysLevel3::Actions###DefaultTicket | Liste aller möglichen Aktionen in der UI (AgentTicketClose, AgentTicketEmail, ...) | (s. Liste) |
Tipp: Passen Sie
ACLKeysLevel*
an, um das ACL-UI nur mit relevanten Einträgen zu bestücken.
Evaluierung, Stop-on-Match & Performance
Die Evaluierung von ACLs (Access Control Lists) bestimmt, welche Regeln angewendet werden, wenn ein Ticket geladen oder eine Aktion im Ticketsystem ausgeführt wird. Eine effiziente Konfiguration dieser Abläufe sowie gezielte Performance-Optimierungen sind entscheidend, um ein flüssiges und skalierbares Agenten-Interface zu gewährleisten.
Evaluierungszyklus
Jedes Mal, wenn ein Agent ein Ticket öffnet oder eine Aktion (z. B. Button-Klick) ausführt, durchläuft OTOBO die Liste aller aktiven ACLs geordnet nach ihrem Sortierschlüssel (Name oder ID). Folgender Ablauf zeigt den Prüf- und Ausführungsprozess:
- Match (ConfigMatch): Hier werden Kriterien wie Queue, Status, Priority oder DynamicFields geprüft.
- Change (ConfigChange): Definiert, welche UI-Elemente entfernt oder hinzugefügt werden (Possible, PossibleAdd, PossibleNot) oder welche automatischen Aktionen erfolgen (Queue-/Statuswechsel).
- StopAfterMatch: Wird auf 1 gesetzt, bricht die Verarbeitung nach der ersten zutreffenden ACL ab.
Merke: Ein korrekt gesetztes
StopAfterMatch
verhindert, dass nachfolgende ACLs unbeabsichtigte Änderungen auslösen.
Stop-on-Match-Strategien
Option | Wirkung |
---|---|
StopAfterMatch=1 | Sobald eine ACL matcht, wird keine weitere überprüft – ideal für exklusive Regeln. |
StopAfterMatch=0 | Alle ACLs werden geprüft – nötig, wenn mehrere ACLs unabhängig voneinander eingreifen sollen. |
Tipp: Nummerische Präfixe (z. B. 100-
, 200-
) im ACL-Namen steuern die natürliche Sortierung und damit die Priorität kritisch wichtiger Regeln.
Performance-Optimierung
Ein großes Set an ACLs kann die Ladezeiten von Ticketformularen verlängern. Diese Maßnahmen helfen, die Performance zu steigern:
- CacheTTL anpassen: In SysConfig unter
ACL::CacheTTL
(z. B. 3600 s) legen Sie fest, wie lange geladene ACL-Definitionen im Cache verbleiben. - Preselection-Cache aktivieren: Das Modul
TicketACL::ACLPreselection
füllt vorausgewählte Optionen vorab und spart wiederholte Prüfungen. - Regel-Reduktion: Entfernen Sie veraltete oder doppelte ACLs und bündeln Sie ähnliche Regeln.
- Sequenz optimieren: Platzieren Sie häufig zutreffende ACLs an den Anfang der Liste.
- Indexierte Felder: Nutzen Sie DB-Indexe für DynamicFields und andere häufig abgefragte Properties.
xml
<Setting ID="ACL::CacheTTL">
<Group>Core::Ticket::ACL</Group>
<Value>3600</Value>
<Description>Cache-Lebensdauer für DB-ACL-Backends in Sekunden.</Description>
</Setting>
Wartung & Best Practices
Praxis | Nutzen |
---|---|
YAML-Export | Versionieren Sie ACLs in Git, um Änderungen nachzuvollziehen. |
Dokumentation | Erstellen Sie ein Change-Log mit Zeitstempeln, Autor und Ziel der ACL. |
Regel-Review | Regelmäßige Überprüfung im Team verhindert Überschneidungen. |
Testumgebung | Validieren Sie neue ACLs mit kontrollierten Testtickets. |
Log-Debugging | Aktivieren Sie Debug-Logs (TicketACL::Debug::Enabled ) für detaillierte Einblicke. |
Debugging konfigurieren
xml
<Setting ID="TicketACL::Debug::Enabled">
<Group>Core::Ticket::ACL</Group>
<Value>1</Value>
<Description>ACL-Debugging aktivieren</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value><OTOBO_TICKET_TicketID></Value>
<Description>Filter für Debug-Ausgaben auf Ticket-ID.</Description>
</Setting>
Durch diese gezielten Strategien stellen Sie sicher, dass Ihre ACL-Infrastruktur in OTOBO sowohl leistungsfähig als auch wartbar bleibt – selbst in großen, verteilten Umgebungen.
Praxisbeispiele, Governance & Referenz
In diesem abschließenden Artikelteil zeigen wir anhand konkreter Szenarien, wie ACLs in OTOBO praxisnah eingesetzt werden. Anschließend behandeln wir bewährte Governance-Methoden und verweisen auf weiterführende Referenzen.
Praxisbeispiele
1. Automatische Priorisierung in die "Alarm"-Queue
Ziel: Tickets mit Priorität 5 (sehr hoch) sofort in die Queue Alarm verschieben und Bearbeiter benachrichtigen.
yaml
- Name: "100-Auto-Alarm"
StopAfterMatch: 1
ValidID: 1
ConfigMatch:
Properties:
Priority:
ID: [ 5 ]
ConfigChange:
PossibleNot:
Form:
- ticketCreateQuickClose
PossibleAdd:
Form:
- ticketCreateNotifyOwner
Action:
Queue: "Alarm"
ACL-Grunddaten und Match-Einstellung
ACL-Change: Queue-Wechsel und Button-Add
2. Eskalationsschutz für "sehr hoch" priorisierte Tickets
Ziel: Verhindern, dass Tickets mit Datenbank-Priorität 5 geschlossen werden.
yaml
- Name: "101-No-Close-High"
StopAfterMatch: 1
ValidID: 1
ConfigMatch:
PropertiesDatabase:
Priority:
Name: [ "5" ]
ConfigChange:
PossibleNot:
Action:
- AgentTicketClose
ACL-Change: Close-Button ausblenden
3. UI-Restriction pro Queue
Ziel: In der Queue Support soll die Statusoption gelöst nicht verfügbar sein.
yaml
- Name: "102-Hide-Resolved-Support"
ValidID: 1
ConfigMatch:
Properties:
Queue:
Name: [ "Support" ]
ConfigChange:
PossibleNot:
FormStd:
- State::resolved
ACL-Change: Status-Option entfernen
4. Kundenprozess-Beschränkung
Ziel: Kunden dürfen eigene Tickets nicht in andere Queues verschieben.
yaml
- Name: "103-Cust-No-Reassign"
ValidID: 1
ConfigMatch:
Properties:
Frontend:
Action:
- CustomerTicketZoomReply
ConfigChange:
PossibleNot:
Action:
- AgentTicketMove
ACL-Change: Move-Button ausblenden für Kunden
5. Zeitbasierte Eskalation nach 48 Stunden
Ziel: Tickets, die älter als 48 Stunden offen sind, werden automatisch an Senior-Agenten zugewiesen.
yaml
- Name: "104-Escalate-48h"
ValidID: 1
ConfigMatch:
Properties:
Ticket:
CreateTimeOlderThan: 48h
ConfigChange:
Action:
Owner: "Senior-Agenten"
Hinweis: Dieses Szenario erfordert gegebenenfalls eine Erweiterung für zeitbasierte Match-Kriterien.
Governance & Dokumentation
Maßnahme | Beschreibung |
---|---|
Namenskonvention | Numerische Präfixe (z. B. 100- , 200- ) für Sortierung und Übersichtlichkeit. |
Changelog | Protokollieren Sie Name , Comment , ChangeTime und ChangeBy für jede ACL-Änderung. |
Review-Prozess | Führen Sie regelmäßig Reviews durch, um Überschneidungen und Konflikte zu vermeiden. |
Versionierung | Exportieren Sie ACLs als YAML und versionieren Sie in Git oder einem Dokumentationstool. |
Testing | Validieren Sie ACLs in einer Testumgebung mit spezifischen Testtickets. |
Weiterführende Referenzen
- ACL-Referenz (YAML):
Kernel/Config/Files/ZZZACL.pm
(generiert) - SysConfig ACL-Keys: Level 1–3-Begriffe zur Feinsteuerung (
Core::Ticket::ACL
) - DynamicField-Dokumentation: Anbindung dynamischer Felder in ACLs
Mit diesen Praxisbeispielen und Governance-Empfehlungen verfügen Sie nun über das Rüstzeug, um ACLs in OTOBO sicher, effizient und nachvollziehbar zu betreiben.