KIX Version 18 - Berechtigungssystem

[Torsten Thau]

Das in KIX Version 18 vollständig überarbeitete Berechtigungskonzept ist eine der grundlegendsten Änderungen. Im bisherigen Werdegang von KIX waren stets "Gruppen" und deren Berechtigungen, welche tlw. frei konfigurierbar, aber auch mitunter fest codiert waren, der Kern des Berechtigungssystems. "Rollen" dienten lediglich als eine Art "Templatenutzer" in der Zuordnung von Nutzern zu ihren jeweiligen Berechtigungen. Teilweise wurden Funktionalitäten an Berechtigungen auf Gruppen, statt an Rollenzuordnungen fest gemacht. Diese Berechtigungen waren (historisch bedingt) an den Bearbeitungsschritten in Tickets angelehnt ("create", "note", "owner", "priority", ...) aber über den Ticketkontext hinaus auf "Lesen" und "Vollzugriff" begrenzt. Für den Zugriff auf Assets/Config Items wurde eine Sonderlösung mittels eines zusätzlichen CI-Attributs geschaffen. Für kritische Angaben an einem Config Item wurde ein verschlüsselter Attributtyp bereit gestellt. Die beiden letztgenannten Beispiele illustrieren deutlich, dass verschiedenste Wege gegangen wurden, um gleichartige Probleme (Beschränkung des Zugriffs) zu lösen. 

In KIX18 werden nun die Berechtigungen "Create", "Read", "Update", "Delete" sowie die Nicht-Berechtigung "Deny" vergeben ("CRUD+DN").

• "Create" erlaubt dabei das Anlegen eines neuen Eintrags in der Ressource/in einem Kontext
• "Read" erlaubt das Lesen/Anschauen eines Eintrags
• "Update" ermöglichst das Ändern eines Eintrags
• "Delete" lässt das Löschen eines solchen Eintrags zu
• "Deny" ermöglicht es besonders sensible Bereiche/Einträge einfach und vollständig unzugreifbar zu setzen. Durch andere Rollen zugeteilte Zugriffsmöglichkeiten können so konsequent begrenzt werden.

Berechtigungen werden zudem auf verschiedenen Ebenen vergeben. Die oberste Ebene sind dabei Kontexte bzw. Ressourcen, wie Tickets, CMDB, FAQ, Organisationen, Kontakte etc. Die nächste Ebene sind die einzelnen Objekte oder Items in der Ressource, also beispielsweise ein konkretes Ticket, ein konkretes Asset/Config Item oder ein konkretes Kontaktdatensatz usw. Auf der letzten Ebene schließlich können die Zugriffe auf Eigenschaften eines Objekts beschränkt oder erteilt werden. D.h. dass bestimmte Ticketeigenschaften wie bspw. Priorität nicht geändert werden dürfen, während die Änderung des Tickettitels oder des bearbeitenden Teams (aka "Queue") durchaus zulässig ist.

Mit diesem Berechtigungssystem ist es möglich eine Mandantenorientierung aufzubauen, wie sie bislang in KIX nicht möglich war. Der Zugriff auf Kunden-/Kontaktdaten kann auf konkrete Mandanten beschränkt werden. Die Verwaltung von Textbausteinen, Teams, und sonstigen Systemeinstellungen kann ebenfalls auf einzelne Einträge beschränkt werden. Damit wird eine logische Mandantenfähigkeit in allen Teilen des KIX Service Systems realisiert. Beispielsweise können untergeordnete Organisationseinheiten oder Teams in KIX die von ihnen verwendeten Vorgaben wie Teamstrukturen, Textbausteinen, Automatisierungen usw. selbst verwalten und entlasten so die KIX-Administration.

Einige Dinge bleiben jedoch unverändert: ein Nutzer wird nach wie vor einer oder mehreren Rollen zugeordnet werden. Und die Zuordnung der Rollen kann sowohl im KIX selbst also auch durch Vorgabe aus einem Active Directory bzw. LDAP erfolgen. Die für den Nutzer geltenden Berechtigungen sind weiterhin die Summe aller Berechtigungen seiner Rollen.