Willkommen zu unserem KuppingerCole Webinar, Unlocking Success, Praxisorientiertes Rollenmanagement und Berechtigungskonzeptverwaltung im Fokus. Mein Name ist Matthias Reinwarth, I am the Director of Practice, I am bei KuppingerCole Analysts, und ich habe zwei Gäste bei mir, und die möchte ich gerne kurz begrüßen. Als allererstes die Lara-Sophie Ense, sie ist Business Analyst, I am bei der DEVK. Hallo Lara. Hallo Matthias, danke für die Vorstellung.
Schön, dass du dabei bist, und ich begrüße den Alexander Puchta, der ist der Head of Professional Services bei Nexis. Hallo Alexander. Hallo Matthias, danke, dass wir dabei sein dürfen. Ich freue mich auf die Praxis nachher, da bin ich sehr gespannt drauf. Bevor wir dahin kommen, würde ich jetzt ganz kurz das Housekeeping machen, das heißt kurz erläutern, wie dieses Webinar vonstatten geht. Das geht ganz schnell, Audio, alle Teilnehmer, und ich freue mich, dass so viele mit live dabei sind, sind zentral stumm geschaltet, da müssen sie gar nichts dran tun, das machen wir für sie.
Sie müssen aber nicht richtig still sein, denn sie können in der Q&A-Section schriftlich im Control Panel Fragen stellen, und die sind uns wichtig, die kommen nämlich nachher in der Fragenrunde dran. Die findet am Ende des Webinars statt, sehen wir gleich nochmal bei der Agenda, und da freuen wir uns auf ihre Fragen, dass wir tatsächlich, der Alexander, die Lara und vielleicht auch ich, was Wichtiges, Sinnvolles zu dem Thema Ihnen antworten können, was Sie bewegt, was Sie bedrückt.
Aufnahme und Folien, dieses Webinar wird aufgezeichnet, und Sie bekommen die Aufnahme und alle drei Präsentationsdecks in den nächsten Tagen zur Verfügung gestellt. Sie müssen also keine Screenshots machen, legen Sie sich zurück und schauen Sie sich das entspannt an, stellen Sie Fragen und diskutieren Sie mit. Das war es schon mit dem Housekeeping, insofern schaue ich jetzt noch schnell auf die Agenda, und dann würde ich mit einem ganz kurzen Teil beginnen, den wir auch schon auf Punkt 1 sehen, von der Regulatorik zu Berechtigungen.
Klingt immer so ein bisschen düster, wenn die Regulatorik die Berechtigungen fordert, aber ist halt eben auch einer der zentralen Punkte, die man hiermit bewegen kann. Danach kommt der Alexander mit Standardisierung und Integration zur Compliance. Dann gucken wir auf die Lösungen, die die Probleme lösen, die ich vorher aufgespannt habe, und dann schauen wir uns in der Praxis an, wie das tatsächlich funktioniert. Und dann kommt die Lara mit ins Spiel. Sie berichtet über die Transformation von Berechtigungskonzepten, im konkreten Beispiel bei der DEVK.
Und dann kommt das schon angekündigte Q&A-Zeitfenster, das wir haben. Da können wir uns über Ihre Fragen hermachen, und deswegen nochmal die Bitte, wenn Sie Fragen haben, dann bitte in die Q&A-Session. Ich habe ein Auge drauf, und ich würde diese noch entsprechend sukzessive am Ende mit einbinden. Und das war's von der Einführung. Insofern würde ich jetzt gerne einfach den kurzen Teil von der Regulatorik zu Berechtigungen angehen, und damit schauen wir dann auch mal drauf.
Denn es gibt überraschend viele Unternehmen, die es bislang erfolgreich vermieden haben, ein richtig gutes Berechtigungsmanagement zu implementieren oder auch kontinuierlich einzusetzen. Das heißt, es wird immer schwieriger, das hinzukriegen. Das heißt, Unternehmen, die bislang keinen guten Grund gefunden haben, das zu tun, und es gibt echt viele gute Gründe, das zu tun, von Effizienz über Geschwindigkeit bis hin zu der Compliance, alle die kriegen mittlerweile recht gute Gründe von außen in Form von Regulatorik, von Risikomanagement-Standards, die es zu erfüllen gilt.
Und die führen relativ zügig direkt oder indirekt zu der Notwendigkeit, ein Berechtigungskonzept zu implementieren. Und das kann rechtliche Anforderungen sein, das kann regulatorisch sein, aber auch branchenspezifisch. Denken Sie nur an TSACs in der Automobilindustrie oder die GXP in Pharma. Da kann man relativ zügig davon ausgehen, dass man ein gutes Berechtigungskonzept braucht. Wie das in den Standards aussieht, das habe ich mal an zwei Beispielen dargestellt.
Wir sehen hier auf der Folie oben in der Überschrift die üblichen Verdächtigen, die momentan durch die Nachrichten getrieben werden. Also NIST 2 im Umfeld von kritischen Infrastrukturen, DORA in Finance, TSACs im Automotive-Sektor und ISO für alle, weil das so eine Grundlage ist, die relativ gerne genommen wird und mit der fangen wir auch an. Also was steht da drin, was uns dazu bringt, tatsächlich über Berechtigungskonzepte nachzudenken?
ISO 2701 muss man käuflich erwerben, insofern sind das hier nur kurze Umschreibungen, aber nichtsdestotrotz steht das drin, was hier meine vier Punkte hergeben. In erster Näherung sagt der Appendix 5.15, dass man Zugriffskontrolle erstmal festlegen muss. Man muss sie definieren, das heißt man muss diese rechtlichen Grundlagen einfach sauber ausdefinieren, wie mit Berechtigungen umzugehen ist. Und wenn man das definiert hat, zweiter Punkt, muss man es auch ansetzen. Man muss es auch in der Realität umsetzen. Die rollenbasierte Zugriffskontrolle kann man nehmen, aber auch irgendwas anderes.
Aber es muss sinnvoll umgesetzt werden. Also erst definieren, dann umsetzen. Drittes Schritt, überwachten und prüfen. Also nicht nur einmal machen, sondern regelmäßig auditieren, gucken, passt das alles noch. Und der vierte Schritt, alles das fordert A5.15 von der ISO 2702 eigentlich, sagt dann auch ordentlich dokumentieren, Compliance gewährleisten, denn nur was man sauber dokumentiert hat, glaubt dann hinterher auch derjenige, der es sehen möchte. Also ISO 2701 ist relativ eindeutig.
Das heißt, wenn man an der Stelle sagt, okay, ich möchte das eigentlich erfüllen, zum Beispiel Kubinger-Kohl hat das getan, dann brauchen wir ein ordentliches Berechtigungsmanagement. Also dieses klassische ISMS nach ISO fordert das schon. Aber es sind viel mehr, viel mehr dieser Regulatoriken, die wir betrachten müssen. Deswegen ist dieses hässliche Bild auf der rechten Seite mit den Regulations, die da aufeinander liegen, weil es sind ganz viele. Gucken wir uns was weiteres an. Da wird es ein bisschen schwieriger. Da steht es gar nicht so klar drin.
Gucken wir uns die NIST2-Direktive an, also eine EU-Richtlinie, die relativ zeitnah, mit Datum relativ nah im Oktober aktiv wird. Aktiv ist sie eigentlich schon, aber dann wird sie enforced. Die sagt auch, und das sagen einem viele Berater, sagen die Analysten, sagen Softwarehersteller, da müsst ihr was tun. Und wenn man dann aber reinguckt in die EU-NIST2-Richtlinie, dann steht da drin in Artikel 21, ich habe es ganz unten rechts, rot hervorgehoben, da stehen vier Worte drin. Konzepte für die Zukunftskontrolle, vier Worte.
Das ist nicht unfassbar viel, und es ist insbesondere auch nicht sonderlich spezifisch, wenn es darum geht, Maßnahmen zu identifizieren. Die Idee ist klar, die NIST2-Richtlinie will die Cybersecurity in kritischen Sektoren erhöhen. Das heißt, da muss eine Menge passieren, aber in der Richtlinie steht es direkt erstmal nicht drin. Muss man also interpretieren. Interpretieren heißt bei einer EU-Richtlinie insbesondere auch nochmal auf die rechtliche Grundlage gucken. Ich bin kein Anwalt, kein Politiker, aber es muss in konkrete nationale Gesetze umgesetzt werden.
Also muss es ein nationales Umsetzungsgesetz geben, und das gibt es für Deutschland am Beispiel auch. Da gibt es derzeit nach meinem letzten Stand einen Referentenentwurf. Das Kabinett hat den Entwurf beschlossen, das Gesetzgebungsverfahren läuft, und wenn man da genau reinguckt, dann gibt es den Paragraf 30, und ich habe es wieder rot hervorgehoben, da steht das Gleiche drin wie in der Direktive. Konzepte für die Zukunftskontrolle. Weiterhin vier Worte. Damit zu implementieren und Requirements, Anforderungsprofile zu schreiben, was muss ich denn alles tun, fällt damit relativ schwer.
Außer man guckt links und rechts wieder zur ISO, vielleicht wieder zur NIST als Rahmenwerk für Controls, die man implementieren kann, die natürlich auch das Identity- und Access-Management und das Berechtigungsmanagement betreffen. Aber wenn ich mehr wissen will, war man bis vor kurzer Zeit relativ schlecht aufgestellt, aber es ist was passiert, was man tatsächlich sehr, sehr gut benutzen kann.
Ich habe da einen Blogpost zugeschrieben und würde da entsprechend auch noch mal drauf leuchten, weil das ist richtig gut, was einem da weiterhilft, und aus Analystensicht, glaube ich, auch eine sehr, sehr gute Menge an Anforderungen, die man betrachten kann. Vor einigen Wochen ist nämlich ein Dokument veröffentlicht worden, das für was ganz anderes geschrieben war, aber im NIST-II-Kontext gilt. Das gilt nämlich für multinationale Unternehmen, die als kritische Infrastruktur betrachtet werden müssen und die so groß sind, dass sie nicht national abgedeckt werden können.
Das ist meine Interpretation, weiterhin kein Anwalt. Links steht der Dokumenttitel, das ist der ganz linke blaue Kasten, beginnt mit Commission Implementing bis runter bis Trust Service Providers. Das definiert auch den Scope von dem Dokument, nämlich alle Unternehmen, die eben nicht national sind und wichtig sind und insbesondere digitale Dienste anbieten, DNS Service Provider, Managed Service Provider, Managed Security Service Provider oder Online Social Networks.
Die haben auf einmal von der EU ein Dokument bekommen, wo richtig viel drinsteht, und zwar steht das genauer in diesem Annex, das sind zwei Dokumente. Es ist wieder verlinkt für diejenigen, die es lesen wollen. Da stehen konkrete Anforderungen, insbesondere auch an die Access Control, an das Berechtigungsmanagement, also Richtlinien zur Zukunfts- und Zugangskontrolle.
Das ist eine ganz kurze Zusammenfassung, es sind in Summe drei Seiten, und dann steht auf einmal eine ganze Menge an Anforderungen drin, die dann natürlich an den Annex und an die Lara herangetragen werden, um zu sagen, okay, das müsst ihr eigentlich tun. Das sind Anforderungen, die konkret zu erfüllen sind, und das geht von wiederum die Definition von den Zugriffs- und Zugangskontrollen, also den Berechtigungen. Das geht nicht nur an Personen, also nicht nur die kohlenstoffbasierten Lebensformen, sondern auch Prozesse, die müssen regelmäßig überprüft werden.
Ich gehe jetzt nicht alles von oben nach unten durch, Sie hatten ja Zeit, ein bisschen drüber zu lesen. Da steht echt viel drin, ein bisschen zur starken Identifizierung von Identitäten, aber auch zu sagen, wie regelmäßig überprüfe ich und wie gestalte ich ein Berechtigungskonzept ordentlich. Und dann sind wir jetzt da, Berechtigungskonzepte, die werden uns immer näher gebracht durch diese Regulatorik, an den Beispielen genannt. Wir können es aber über beliebige weitere auch entsprechend durchziehen.
Die Zeit habe ich noch nicht, deswegen habe ich NIST 2 und ISO 2701 als Beispiel genommen, und wenn wir es jetzt tun, wäre jetzt die Frage, was mache ich denn damit, und warum tue ich das, warum sind diese Berechtigungskonzepte so wichtig? Ich erfülle in erster Näherung natürlich diese Anforderungen, das war leicht. Aber da sind auch tatsächlich konkrete Maßnahmen dahinter, wenn ich es nicht ordentlich mache, Strafen, Bußgelder, die dann durchaus auch an Schmerzen bei den entsprechenden Verantwortlichen verursachen können.
Also man fordert ein strukturiertes Berechtigungskonzept auch als Grundlage von der Vermeidung rechtlicher Konsequenzen. Aber, nachdem ich das alles Hässliche weggeräumt habe, Transparenz und Nachvollziehbarkeit, das ist ein Wert an sich, den möchte ich haben. Klare Dokumentation der Zugriffsrechte, beispielsweise aber auch die Umsetzung dieses Minimalprinzips, zu sagen, ich habe nur die Berechtigungen, die ich brauche, um meinen täglichen Job zu machen und keine mehr. Aber genau die, die brauche ich.
Das heißt, wenn ich Berechtigungen nicht habe, die ich nicht dringend brauche, kann ich mit denen auch keinen Unfug machen. Und das gilt auch für den internen Bösewicht, den ich eigentlich entsprechend einschränken möchte. Angenommen, es gäbe jemand, der tatsächlich übermäßige Berechtigungen missbrauchen wollte, dann nehme ich ihm diese übermäßigen Berechtigungen durch ein gutes Berechtigungskonzept und dessen kontinuierlicher Umsetzung unter regelmäßigen Überprüfung. Regelmäßig draufgucken, regelmäßig anpassen, dafür sorgen, dass Berechtigungen aktuell sind.
Wichtiger Aspekt, gerade im Finance-Umfeld, wird vielleicht auch die Lara nochmal was dazu sagen, ist Segregation of Duties, also die Trennung von Aufgabenbereichen. Jeder kennt das Beispiel, wenn ich einen Antrag stellen darf, das sollte ich nicht genehmigen dürfen, dann hat es nämlich keinen Sinn, dann verletze ich dieses Prinzip, dass ich eine Aufgabentrennung erreicht habe. Und am Ende des Tages ist natürlich ein gutes Berechtigungskonzept auch die Grundlage für eine gute IT-Sicherheit, weil jeder nur das können dürfen sollte, was er machen soll.
Letzter Aspekt, den ich betrachte, wir haben es eben hergeleitet, wir müssen es also tatsächlich in vielen Fällen tun. Wenn wir es nicht müssen, sollten wir es wollen, ganz wichtig. Was es dann bedeutet und was es mir an Nutzen bringt, habe ich an einigen Beispielen dargestellt. Und jetzt natürlich noch die Frage zentrale Verwaltung. Berechtigungsmanagement macht mir dann ganz viel Sinn, wenn es von der administrativen Seite her, nicht notwendigerweise von der Umsetzung, zentralisiert ist.
Wenn ich also eine moderne Lösung, da kommt der Alexander ins Spiel, nutze, um zentrale Verwaltung und Kontrolle von Berechtigungen durchzuführen. Um das dann hinten raus, deswegen dieses Bild mit diesem Baum in der Mitte, das Berechtigungsmanagement drumherum als Blätter oder Äste, die Systeme dann entsprechend in die Systeme zu integrieren.
Denn dann habe ich an zentraler Stelle die Notwendigkeit und die Möglichkeit, dass ich Berechtigungen anpassen kann, weil sich an einer Person etwas geändert hat, weil sich in einem System etwas geändert hat, weil sich in der Zuordnung von Berechtigungen zu einer Person entsprechend Dinge geändert haben oder eine Rolle neu geschnitten wird. Dann werde ich effizienter, ich werde schneller.
Ich kann natürlich diese eben gerade dahergebrachten Compliance-Vorgaben zentral administriert leichter erfüllen, indem ich konsistent meine Richtlinien dann auch umsetze und von dort, von wo ich gerade bin, nämlich zentral mit einem guten System entsprechend die Berechtigungen nach außen trage und auch wieder entziehen kann. Ganz wichtig, an der letzten Stelle steht die zentrale Dokumentation. Das ist nicht nur was für den Auditor, das ist was für das eigene Management, das ist was für KPIs und zu sagen, ich bin gut in dem, was ich tue mit meinem Management von meinen Berechtigungen.
Ich kann den Application-Ownern sagen, hier, guck mal, dein System wird von diesen genutzt und ich weiß auch, warum. Es steht nämlich hier in der Dokumentation. Und am Ende des Tages kann auch ein Geldfaktor sein, eine zu viel erteilte Lizenz einer kostspieligen Lösung kostet das Unternehmen direkt Geld. Also zentrale Dokumentation, Effizienzsteigerung, kontinuierliche Anpassung kann an der Stelle nur dem Unternehmen im Ganzen helfen.
Insofern haben wir jetzt eine ganze Menge Rahmenbedingungen gesehen, die ich jetzt ganz entspannt als Analyst dem Implementor, dem Software-Vendor, dem Projekt rüberwerfen kann. So, das war alles das, was ihr machen müsst. Wie geht das denn in der Praxis?
Das heißt, an der Stelle würde ich zu dem Alexander Buchta rüberwerfen, nicht aber ohne vorher nochmal gesagt zu haben, denken Sie bitte daran, dass Sie jetzt auch, vielleicht nicht zu meinem Text, aber ganz sicher zu dem Alexander Vortrag, entsprechend Fragen in die Q&A-Section schreiben können, sodass wir die entsprechend dann übernehmen können. Aber jetzt gebe ich ab an den Alexander und freue mich auf den praxisorientierten Teil. Vielen herzlichen Dank, Herr Matthias. Und herzlich willkommen auch zu unserem Teil. Es wird vorrangig hier heute um zwei verschiedene Themen gehen.
Einerseits um das Rollenmanagement, das wir auf den Folien jetzt gerade schon von Dirk Matthias gesehen haben. Andererseits ja auch sehr prominent platziert das Berechtigungskonzept und das Management dahinter. Und man sieht es auch rechts oben schon, wie wir das Ganze auch im Nexus 4 entsprechend abbilden können.
Wir, das sind einerseits Lara von der DEVK. Lara ist Spezialistin im IAM-Team der DEVK und wird gleich auch noch ein bisschen mehr zum Berechtigungskonzept und der Integration dort erzählen.
Und ich, Alexander Puchter, verantworte bei der Nexus GmbH das Consulting Professional Services, bin seit mehr als acht Jahren jetzt bei der Firma. Die Nexus GmbH gibt es seit 2009. Wir sind in Regensburg verortet und haben derzeit um die 50 Personen, die gleichzeitig Beratung leisten, aber natürlich auch an unsere Softwarelösung Nexus 4 im Hintergrund schrauben. In der Vorbereitung zu diesem Webinar habe ich mir mal ein paar Gedanken gemacht.
Was sind denn so klassische Probleme, die natürlich aus der Regulatorik Matthias von Dir, aber natürlich auch in der Praxis einfach vorkommen, die jetzt vielleicht ein bisschen schwerer versteckt sind, die wir so aus unserer Kundenerfahrung herauskennen. Ganz rechts zu der Regulatorik hat Matthias schon etwas erzählt. Wenn wir uns die anderen Themen angucken, dann sind es immer wieder ähnliche Probleme, vor denen unsere Kunden stehen. Beispielsweise viele unserer Kunden haben schon ein Rollenmodell, also das AirBug, das die ISO und Co fordern, ist dort schon implementiert.
Wenn wir uns das Ganze ansehen, ist es allerdings häufig so, dass diese Geschäftsrollen mal gebaut wurden und dann aber nicht mehr wirklich aktualisiert werden oder wenn, dann nur händisch aktualisiert werden. Das bedeutet, diese Rollenmodelle, die Sie vielleicht dann veranlassen, dass Sie das erste Mal in der Prüfung den Haken kriegen, könnte natürlich bei entsprechendem Outdating dazu führen, dass es mal Probleme gibt in den Audits.
Was wir dort besonders kennen, zum Beispiel aus der Corona-Zeit, es werden Office 365 oder Teams-Berechtigungen vergeben, allerdings nicht über meine zentrale Basisrolle gesteuert, sondern als Direktzuweisung und ich muss wieder hinterherlaufen und daran denken, diese Berechtigungen beispielsweise in meine Basisrolle einzusteuern. Ebenso Integration von Endusern respektive, dass Enduser immer häufiger ihr Reagieren anstelle eines agierenden Verhaltens haben.
Bedeutet, ich habe sehr viel zentralisiert und meine Enduser, die ja eigentlich das Wissen haben in den Fachbereichen, die müssen immer nur reagieren, sind aber nicht in der Lage mit einer Software oder mit einem zentralen Ankerpunkt. Beispielsweise auch Ideen, wie zum Beispiel neue Rollenvorsteige oder Anpassungen des Berechtigungskonzepts einzubringen. Stichwort Berechtigungskonzept, auch hier sehen wir in der Praxis sehr oft diesen hier Missing Link genannten Punkt.
Das bedeutet, ich habe einerseits ein Dokument, eine Word-Datei, ein Excel auf der einen Seite und auf der anderen Seite eigentlich ein hoch verknüpftes digitales Berechtigungsmanagement. Und die haben nicht viel miteinander zu tun. Was in dieser Word-Datei steht, ist erstmal geduldiges digitales Papier, während in meinem IAM natürlich die eigentliche digitale Post abgeht, indem ich dort meine Berechtigungen verwalte. Und was in dem Dokument steht, entspricht oftmals nicht so ganz dem, was dann in der Realität gelebt wird.
Und auch hier sehen wir ganz oft ein Problem und Lara wird uns natürlich auch entsprechend zeigen, wie dann die DVK dieses Problem angegangen ist. Und ganz allgemein wäre es jetzt natürlich langweilig, wenn wir sie mit diesem Problem im Regen stehen lassen. Sondern wir haben hier auch mit Nexus 4 beispielsweise ein Produkt, das sich als Add-on versteht zu verschiedensten IAM-Systemen.
Das heißt, wir können uns generisch an sämtliche dieser Systeme anbinden, können uns die Daten entsprechend ins System laden und können dort entsprechende Probleme lösen, indem wir eine Breite verschiedenster Funktionen, wie Sie hier unten beispielsweise sehen, anbieten können. Grundsätzlich wollen wir uns für heute allerdings vor allem auf zwei Funktionen beschränken, nämlich das Rollenmanagement und die Berechtigungskonzepte selbst.
Das heißt, wir mischen so ein bisschen Altbewährtes, also gerade Nexus, vormalig Nexus Control, ist ja für das Rollenmanagement, Roll Mining eigentlich bekannt. Das heißt, hier werde ich Ihnen noch ein bisschen was erzählen, wie wir das Ganze allgemein angehen, respektive wie es auch in der DVK umgesetzt wurde. Und Lara wird dann gleich noch zu den Berechtigungskonzepten kommen. Was verstehen wir denn unter diesem automatisierten Rollenmanagement, wie es hier oben so schön steht? Grundsätzlich wird Ihnen alle klar sein, wie ein Rollenmanagement aufgeteilt ist.
Wir haben generell mal diese initiale Modellierungsphase, in der ich mich darum kümmere, mein erstes Rollenmodell aufzubauen. Das bedeutet gar nicht mal so sehr, nur die Rollen zu modellieren, sondern natürlich auch alle Konzepte, alle Dokumentationen im Hintergrund zu erzeugen, zu erstellen und abzustimmen. Wenn unser Rollenmodell dann einmal implementiert ist, folgt im Prinzip ein Lebenszyklusprozess. Das heißt, ich habe neue Geschäftsrollen, die in mein Modell kommen. Ich habe Rollen, die ich ändern möchte und ähnliches.
Und in einer Optimierungsphase möchte ich dann entsprechend natürlich auch dieses Rollenmodell möglichst automatisiert mit Vorschlägen unterstützend verbessern. Und unsere Automatisierung greift hier eigentlich in allen Ebenen an. Das bedeutet, während der Modellierungsphase sind wir in der Lage, zugriffs- und zugriffsregelbasiert Geschäftsrollen zu bauen. Das bedeutet, alle Personen, die zum Beispiel in einer gewissen Fachabteilung sind, kriegen automatisch Berechtigungen über eine Geschäftsrolle zugewiesen, respektive verlieren diese auch wieder.
Ebenso im Lebenszyklusmanagement, in dem wir beispielsweise über Trigger automatisiert Prozesse starten können oder in der Optimierung entsprechend im Rollenmodell das Ganze analysieren können und auf Basis dieser Analysen Vorschläge geben können, um beispielsweise Berechtigungen, Stichwort Microsoft Teams Berechtigungen beispielsweise, in eine zentrale Basisrolle packen zu können, wenn man feststellt, dass die einzeln vergeben wurden stattdessen.
Wenn wir uns das Ganze angucken, wie es bei der DEVK implementiert wurde, dort vielleicht zum Hintergrund, das Ganze war damals ein zweijähriges Projekt. Erschwerend hinzukommt, das war während der Corona-Phase. Das bedeutet, auch hier waren es tatsächlich harte Monate für die DEVK, um diese Workshops jetzt nicht vor Ort in Person zu organisieren, sondern man musste auch entsprechend auf die Remote-Workshops zurückgreifen. Nichtsdestotrotz würde ich sagen, war es ein sehr erfolgreiches Projekt damals, wenn man sich die KPIs unten anguckt.
Wir haben knapp 1400 Geschäftsrollen dort modelliert, dadurch eine Abdeckung von mehr als 87% erzielt. Das heißt, mehr als 87% aller Zuweisungen sind rollengesteuert und haben gleichzeitig hier knapp 2500 Altrollen ersetzen können. Grundsätzlich fragt man sich jetzt, okay, 1400 neue Rollen für 2400 Altrollen getauscht. Wo ist der große Mehrwert?
Diese 1400 Rollen sind überwiegend automatisiert gesteuert, während die Altrollen tatsächlich überlappend waren, mit wenig Beschreibung versehen waren und dadurch extrem schwierig auch für Fachbereiche verständlich war, welche der Altrollen werden denn überhaupt noch benötigt und was muss ich bestellen. Das heißt, ich habe ein entsprechendes Konstrukt auf die Beine gestellt, das ich dann entsprechend bei der DEVK mit verschiedensten Workflows hinterlegt habe.
Das bedeutet, dort wird mittlerweile über Rezertifizierungen bis hin zur Möglichkeit, dass Fachbereiche selbst über eine grafische UI neue Rollen beantragen können, bis hin zum Thema Datenqualität sehr viel über Workflows, also verschiedene Prozesse gesteuert. Ein Beispiel der Datenqualität, immer wenn neue Berechtigungen angelegt werden, bekommt die DEVK das automatisch über Nexus zugespielt und kann sich darum kümmern, sämtliche wichtigen Informationen, Kriptikalität oder Berechtigungen dort entsprechend einzusteuern. Und zuletzt natürlich noch eine Optimierung.
Das bedeutet, auch hier nutzt die DEVK die Optimierungsengine von Nexus, um hier jetzt als kleines Beispiel aus einer Testumgebung dort beispielsweise zu erkennen, welche Altrollen denn im neuen Rollenkonzept schon umgesetzt und abgelöst werden können. Das heißt, ich muss nicht selbst erkennen, ob gewisse Altrollen schon redundant sind, sondern kann das über Nexus vollautomatisch erkennbar machen und kriege dann eigentlich nur meine Vorschläge zurückgespielt an mich. Und sämtliche dieser drei Dimensionen werden von der DEVK entsprechend auch bespielt.
Wenn wir uns das angucken, wo die Reise denn weiterhin geht, ist eigentlich das Schlagwort Smart, Simple, Scaling genau das, wie Nexus hier weiter in diesen Funktionen wachsen möchte. Das Passwort AI ist natürlich in aller Munde. Wir werden uns hier hauptsächlich und vorrangig auf ein Machine Learning fokussieren, um beispielsweise Erkenntnisse im Role Mining, aber auch in den Berechtigungskonzepten, die wir gleich sehen, entsprechend noch bessere Vorschläge machen zu können.
Wir versuchen Prozesse, die wir definiert haben, die viele unserer Kunden nutzen, entsprechend out of the box mit auszuliefern und werden auch bezüglich des Scalings noch flexibler, was das Deployment angeht, beispielsweise indem wir auch SaaS-Lösungen mit anbieten. Das in aller Kürze zum Nexus-Thema und dem Rollenmanagement, das wir dort abdecken. Natürlich jetzt der spannende Teil auch zu dir, Laura, bezüglich des Autorisierungskonzepts. Wie ihr das denn mit Hilfe von Nexus 4 bei euch abgebildet habt? Vielen Dank, Alex.
Und zwar werde ich Ihnen jetzt etwas zum Thema Berechtigungskonzepte erzählen und wie wir gerade in der DEVK das Thema Berechtigungskonzepte transformieren. Folgende Themen habe ich mitgebracht. Ich werde einmal ganz kurz was zum Thema von Relevanz von Berechtigungskonzepten erzählen. Da hatte der Matthias ja eben schon ganz viel zu gesagt und da werde ich dementsprechend nur noch kurz drauf eingehen. Dann natürlich die Frage, ich bin ja hier mit dem Alexander zusammen, warum haben wir uns für Nexus entschieden und macht es nicht irgendwie anders?
Warum lösen wir es so, wie wir es jetzt machen? Wie sind wir vorgegangen? Und dann habe ich einen kleinen Tipp da mitgebracht, werde ein paar Punkte zeigen, wie wir das aktuell umgesetzt haben, wo wir dran sind und am Ende gehe ich noch kurz auf unsere Latenz-Learn ein. Warum brauchen wir Berechtigungskonzepte?
Ja, das hat der Matthias eben schon ganz viel gesagt. Bei uns als Versicherung ist es vor allem die Versicherungsaufsichtlichen Anforderungen an die IT und dann ab nächstem Jahr auch die DORA, die Berechtigungskonzepte fordern und auch der BSI verlangt eben das Berechtigungskonzept zu akzeptieren und vorliegen und das ist unsere wichtigste regulatorische Grundlage dafür.
Dann müssen wir als Unternehmen in der Finanzbranche natürlich auch regelmäßig unsere Rollen und Rollenzuweisungen und Rechtezuweisungen rezertifizieren und dazu brauchen wir eben auch Berechtigungskonzepte, denn die legen den Rollzustand fest und die Rezertifizierung ist ja am Ende ein Soll-Ist-Abgleich und das Soll muss irgendwo definiert sein.
Und ja, wir haben auch ein Eigeninteresse daran, dass eben die Zugriffe auf unsere Daten und Prozesse sauber dokumentiert sind, denn ja, wie auch eben schon gesagt, das ist ja auch wichtig, dass das irgendwo sauber geregelt ist, dass da keine Funktionsbrennungskonflikte vorliegen etc. Eben schon gesagt, wir sind ein reguliertes Unternehmen, das heißt, wir werden ja auch, wir stehen unter der Aufsicht der Waffen und werden dementsprechend regelmäßig geprüft. Dementsprechend achten wir auch bei Berechtigungskonzepten auf verschiedene Punkte.
Das lässt sich einmal so unterteilen in inhaltliche und organisatorische Faktoren. Inhaltlich haben wir einmal so die Thematiken von Verantwortlichkeiten, dass die eben klar definiert sind für die Rollen, für die Rechte, für die nicht personalisierten Benutzer.
Dann ja, für wen ist eine Anwendung vorgesehen, was ist da der Benutzerkreis, welche Rollen, welche Berechtigung gibt es, wie sind die Rollen und Rechte miteinander verknüpft. Ja, gibt es nicht personalisierte Accounts und falls ja, wer ist verantwortlich, wer ist die natürliche Person, die hinter so einem Account steht.
Dann, wie autorisiere ich mich gegenüber der Anwendung, ist die Anwendung so kritisch, dass ich irgendwie nicht bei Faktor Authentifizierung brauche beispielsweise. Auch das sind Punkte, die halten wir im Berechtigungskonzept fest. Und dann gegebenenfalls auch das Thema Berechtigungsverwaltung innerhalb einer Anwendung. Also in einer idealen Welt ist natürlich alles miteinander verknüpft und über viele Systeme angebunden. Es gibt ja aber immer noch auch Anwendungen, die eben eine eigene Berechtigungsverwaltung haben und die Prozesse müssen natürlich auch unkonditioniert sein.
Und wir haben uns eben entschieden, diese Prozesse, wie dann die Berechtigungsverwaltung funktioniert, eben auch im Berechtigungskonzept abzudecken. Genau, dann organisatorisch achten die Prüfer natürlich darauf, dass Berechtigungskonzepte aktuell sind und regelmäßig aktualisiert werden, dass sie nachvollziehbar sind, dass sie vollständig sind.
Und natürlich ist es denen auch lieber, wenn die irgendwie einheitlich dargestellt sind und wir jetzt nicht zu 300 Anwendungen, 150 verschiedene Vorlagen und Templates haben für ein Berechtigungskonzept, sondern das Ganze eben möglichst einheitlich und strukturiert dargestellt wird.
Genau, dann war natürlich die Frage, wie schaffen wir das jetzt, die Ziele zu erreichen, beziehungsweise das Ganze eben einheitlich darzustellen und auch zu schaffen, dass wir sicherstellen, dass das Ganze aktuell gehalten wird und an zentraler Stelle das Ganze kriegen können und haben uns dazu entschieden, das Ganze eben mit der Nexus zusammen umzusetzen. Das hat verschiedene Gründe. Zum einen haben wir eben sehr, sehr viele Rechte und Rollen, die bereits in Nexus abgebildet sind, die dort beschrieben sind, die Verantwortlichen dazu geordnet sind und die entsprechend eingeordnet sind.
Und die Berechtigungskonzeptlösung in Nexus ermöglicht uns eben die Informationen, die sowieso dann bestehen, für rechte Verwaltung auch gleichzeitig zur Definition des Sollzustands zu nutzen und dort entsprechend dann mit einem Berechtigungskonzept zu verlinken.
Also manche Bereiche sind vorher wirklich auch einfach hingegangen und haben sich die Informationen, die aktuellen aus Nexus rausgesucht, die Informationen im Berechtigungskonzept in Word beispielsweise aktualisiert und ebenso ihre Aktualisierung durchgeführt und so bekommen wir die ganzen Aspekte jetzt eben viel, viel besser miteinander verknüpft. Und wie der Alexander eben schon erwähnt hatte, wir arbeiten schon seit einigen Jahren mit Nexus zusammen, das heißt auch viele der Anwender kennen Nexus bereits.
Es ist eine gut bedienbare Oberfläche und entsprechend bekannt und erfordert nicht viel Neueinführung oder Zufühlung. Dann ermöglicht es uns eben zu sehen, welche Berechtigungskonzepte gibt es und eben auch welche Berechtigungskonzepte fehlen uns noch, um so dieses ganze Thema Einheitlichkeit und Überwichtigkeit eben abzuhaken. Und wir können auch Berechtigungskonzepte als PDF-Datei exportieren, falls die Prüfer zum Beispiel ein Konzept sehen wollen. Dann können wir uns bei wichtigen Punkten auch technische Unterstützung mit ins Wort holen. Da haben wir einmal das Thema Aktualität.
Wenn die Konzepte überprüft sind, planen wir die Aktualität regelmäßig kampagnenbasiert zu aktualisieren, zu überprüfen. Also dass die Verantwortlichen der Konzepte dann regelmäßig aufgefordert werden zu schauen, stimmt das hier noch, hier ist vielleicht was dazugekommen, bitte prüf einmal, ob das Ganze noch so stimmt, ob hier was angepasst werden muss.
Dann geben wir alle Berechtigungskonzepte frei, das heißt die Verantwortlichen für eine Anwendung geben das Konzept frei und auch wir machen noch einmal eine Qualitätssicherung darauf, dass wir sicherstellen, dass auch wirklich nur gute Berechtigungskonzepte sozusagen freigegeben werden. Und die Freigabe kann überhaupt erst gestartet werden, wenn alle wichtigen Informationen aufgefüllt sind. Warum Nexus? Es gibt ja auch noch andere Anbieter, die Berechtigungskonzepte toolbasiert darstellen.
Wir haben uns für Nexus entschieden, weil wir eben schon seit ein paar Jahren zusammenarbeiten und da auch auf eine gute Zusammenarbeit zurückklicken können. Und weil wir natürlich auch als relativ großes Unternehmen eine Vielzahl an Tools im Unternehmen haben und es dann auch einfach angenehm ist, wenn nicht noch ein neues Tool eingeführt wird, sondern wenn das Ganze dann direkt in einem Tool miteinander verbunden wird. Dann werde ich als nächstes ein paar Worte darüber verlieren, wie wir vorgegangen sind und wie wir aktuell die Workouts durchführen.
Wir hatten vor etwa einem Jahr den ersten Workshop zum Thema Berechtigungskonzepte in Nexus und haben da einmal unsere Anforderungen sondiert. Wir hatten vorher schon ein bisschen Vorarbeit geleistet und Wordbasiert damals noch eine neue Vorlage erstellt. Die hat die Nexus dann als Grundlage genommen und einen ersten Entwurf gestartet, wie so ein Berechtigungskonzept dann eben in der Anwendung aussehen kann. Das Ganze haben wir dann mit zwei Anwendungen im Unternehmen pilotiert.
Das hatte dann auch alles ziemlich gut funktioniert, sodass wir dann einen erweiterten Piloten gestartet haben mit allen aus den Bereichen, die eben eine Beratung angefragt haben zu Berechtigungskonzepten für neue Anwendungen und haben dann natürlich ganz viel Feedback bekommen. Wir haben nochmal einige Anforderungen an die Nexus durchgegeben, sodass wir dann mit den Anpassungen, die dann durchgeführt wurden, erst mit kritischen Anwendungen gestartet sind und jetzt fachberechtigterweise weiter vorgehen und die Konzepte langsam im Haus ausrollen.
Wir haben ja in der Regel schon ein berechtigtes Konzept vorliegen, sodass die bestehenden Konzepte irgendwie überführt werden müssen. Bei uns im Haus ist es so, dass wir gesagt haben, wir bekommen das nicht irgendwie skriptbasiert hin, sondern das muss mit menschlichem Wissen überführt werden. Da bieten wir aber Unterstützung an als ERM-Team, sodass wir eben in der Regel mit einer Kick-Off-Veranstaltung starten. Dann bekommen die Fachbereiche ein paar Hausaufgaben auf.
Die brauchen zum Beispiel ihr Altersberechtigungskonzept, Liste mit technischen Benutzern, gewisse Beschreibungen, die angelegt werden müssen. Wir haben da eine Checkliste mit Informationen, die wir benötigen.
Alles, was die Bereiche liefern können, liefern wir uns dann. Dann werden die Berechtigungskonzepte mit unserer Hilfe überführt. Wir haben da auch gerade für die einfacheren Konzepte auch Werkstudenten eingearbeitet, die bei dem Thema entsprechend gut unterstützen. Am Ende gibt es dann noch immer ein paar offene Punkte zu klären. Der Fachbereich schaut noch mal drüber, dass wir am Ende ein bis zwei Abnahmegespräche machen, um das Ganze gemeinsam zu finalisieren. Und dann geht es eben in den Freigabe-Workflow.
Natürlich gibt es auch Bereiche, die sagen, ach nee, wir brauchen eure Unterstützung nicht, wir lernen gerne Neues. Wir machen es gerne selbst oder auch neue Berechtigungskonzepte, die zu erstellen sind. Dann unterstützen wir eben bei der Neuanlage im System, sind da erberatend tätig. Und die eigentliche Erstellung und Übertragung der Informationen oder Anlage der Informationen erfolgt dann eben durch die Fachbereiche ohne Direkt. Und am Ende wird das Ganze dann auch einmal freigegeben und qualitätsgesichert.
Genau, das ist die Theorie. Jetzt habe ich noch ein paar Minuten Zeit, um zumindest mal einen groben Überblick in das System zu geben und zu zeigen, wie das bei uns so ausschaut. Da haben wir ein dann die Berechtigungskonzept, wo ich jetzt einfach mal die wichtigsten Punkte zeigen würde. Wir haben hier einmal eine Übersichtsseite und unter dem Menüpunkt würde ich jetzt eben alle Berechtigungskonzepte sehen, für die ich verantwortlich bin. Und ich habe jetzt hier das nächstes Involve-Berechtigungskonzept aufgewählt. Das Konzept startet erstmal mit einer Übersichtsseite.
Das ist ein kleines Deckblatt, das wir aus einem normalen Dokumenten-Deckblatt nachempfunden haben. Wir haben hier den Dokumentenstatus, wir haben die Verantwortlichen. Das ist erstmal ein relativ allgemeines Blatt. Die Einhaltung überspringe ich jetzt mal. Hier sind direkt auch die Stammdaten des Systems. Das sind einfach verschiedene Stammdaten zu der Anwendung.
Also, was macht das System, wie heißt es, wie kritisch ist das Ganze, ist es rechnungslegungsrelevant, wer ist verantwortlich, welche Datenbank liegt dahinter. Oder eben auch solche Themen wie, ist es eine eingekaufte Software, ist es eine Ausbilderung, die hier gerade durchgeführt wird. Wird eine alte Software abgelöst, also wirklich einfache Stammdaten. Dann hatten wir eben schon angesprochen, wir haben den großen Vorteil durch die Nexus-Lösung, dass wir eben die Rollen und Rechte direkt auf Nexus übernehmen können.
Sodass wir jetzt hier mal schauen, wie das Ganze aussieht, wenn wir Rollen haben für die Anwendung, die in Nexus hinterlegt sind. Und in dem Fall haben wir jetzt hier drei Rollen, die zu der Anwendung Nexus Involve gehören. Und sehen dann hier einmal in der Mitte, im mittleren Part, die drei Rollen aufgelistet. Und ganz rechts haben wir dann die Stammdaten zu der Rolle, also die Beschreibung, die Kritikalität, die Verantwortlichen etc. Und hier haben wir auch nochmal verschiedene Informationen, die dann angezeigt werden.
Dann sehen wir auf der nächsten Seite, welche Rechte sind hier hinterlegt. In dem Fall enthält die Rolle zwei Rechte, die dort hinterlegt sind. Und sie ist in keiner übergreifenden Fachbereichsrolle verbaut. Ansonsten wäre das unten im unteren Teil des Bildschirms nochmal angezeigt. Und eben wurde auch das Thema Funktionstrennung angesprochen. Wir bilden in Nexus aktuell die Systeminterne Funktionstrennung ab.
Also das heißt, wenn jetzt hier zwei Rollen innerhalb dieser Anwendung nicht miteinander kombiniert werden dürfen, die hier eben zum Beispiel die Demorolle abmüllen und die Demorolle 001, dann kann ich das hier über diesen Funktionstrennungstab, über diese Ausschlussbehandlung eben auch hinterlegen. Und wir wollen dann auch damit arbeiten, dass wir abprüfen, wenn jetzt hier Funktionstrennungskonflikte hinterlegt sind, dass die entsprechend auch regelmäßig geprüft werden und dann auch mitigiert werden können.
Dann haben wir hier noch weitere Informationen, die im Berechtigungskonzept angegeben werden können. Also die ganzen Informationen zu Rollen und Rechten werden dann eben mit einem Konstrukt drumherum angereichert. Und hier haben wir jetzt das Beispiel Benutzerkonten, wo wir eben sagen, okay, wer darf denn überhaupt im System existieren und welche technischen Benutzer, welche nicht personalisierten Passenden Benutzer gibt es denn innerhalb des Systems, wer ist verantwortlich und auch wo liegt das Passwort ab.
Und das Letzte, was ich jetzt noch zeigen möchte, ist ein Feature, an dem wir gerade noch gemeinsam mit der Nexus arbeiten, das noch in der Implementierung ist. Das ist die Fragabe-Historie, daher auch jedes kleine Bildchen von wegen in Arbeit. Da wird sich noch ein bisschen was dran ändern, aber da haben wir dann auch entsprechend eine Historie, mit was habe ich geändert und was ist da passiert. Das ist jetzt erstmal die Information zu dem System, der Einblick. Dann wäre meine letzte Folie, wären jetzt die Lessons Learned.
Was haben wir gelernt, was würden wir vielleicht auch im Nachhinein ein bisschen anders machen. Ich glaube, das ist ja bei jedem Thema, das angegangen wird, normal, dass man nach ein paar Monaten zurückblickt und reflektiert, was ist gut gelaufen und wo könnte man optimieren. Was wir ganz klar gemerkt haben in der Darstellung der Screens, ist, dass es wirklich wichtig ist, sich auf relevante Informationen zu beschränken. Am Anfang hatten wir hier und da auch ein paar mehr Informationen, die angezeigt wurden im berechtigten Konzept.
Da wir eben dachten, zum einen haben die Fachbereiche, die Pilotteilnehmer sich das gewünscht, die Informationen noch zu sehen. Und zum anderen dachten wir, wenn es ihnen hilft, dann bieten wir es eben auch an. Aber nach ein paar Monaten und mehr Usern auf dem Modul ist uns dann eben klar geworden, okay, wir sollten die User jetzt nicht mit zusätzlichen Informationen verwirren, wenn die nicht essentiell ein Bestandteil des berechtigten Konzepts sind.
Dann dieses Thema Filtermöglichkeiten und funktionale Felder, würde ich inzwischen etwas anders handhaben und mehr funktionale Felder, mehr Attribute an einem Objekt verwenden und weniger Freitextfelder bzw. einfache HTML-Felder in dem Tool.
Dann, was auch wichtig ist, frühzeitig die Prüfungsanforderungen und das Thema Auswertbarkeit zu kommunizieren. Einfach damit man danach, wenn man in einer Prüfungssituation ist, als reguliertes Unternehmen nicht irgendwie in die Tridulie kommt oder da lange suchen muss.
Dann, was wir mit den Piloten gemacht haben, war eben das Thema, dass wir Keyplayer aus den Unternehmen eingebunden haben, weil uns das eben dann in weiteren Veranstaltungen geholfen hat. Wenn die gesagt haben, ja, wir haben das schon gemacht und es ist gut gelaufen. Je mehr Reste in Nexus abgebildet sind, je mehr Systeme angebunden sind, desto besser. Der letzte Punkt bei Entwicklung und Design ist ein Dankeschön an die Nexus, denn wir haben da wirklich gute Unterstützung erfahren und immer schnell Feedback bekommen.
Was das Rollout betrifft, ist es wichtig, auf jeden Fall frühzeitig die Personen mit einzubeziehen und das Ganze auch breit im Vorfeld zu kommunizieren, auf die fachlichen und technischen Ansprechpartner zu gehen, weil am Ende ist so ein berechtigtes Konzept, wie wir das wollen, ein Zusammenspiel aus Fachlichkeit und Technik. Nur Sammeltermine funktioniert nicht mit nur individueller Kommunikation und nur Einzelterminen redet man ein bisschen munterwillig, sodass da eine gesunde Mischung sich gut erwiesen hat.
An sich der Rollout, bei so vielen Anwendungen, die wir hier haben, gestalten wir den phasenweise, weil das auch anders gar nicht zu handeln wäre, im Team dort angemessen zu unterstützen. Dann haben wir hier noch das Thema zentrale Unterstützung, Experten im Team aufbauen, dass wir zum Beispiel die Werkstudenten dazu genommen haben und auch die Kollegen aus dem Tagesgeschäft in das Thema einarbeiten. Ein positiver Nebeneffekt ist, dass durch diese Anzeige der Rollen und Rechte im Berechtigungskonzept natürlich die Standarten der Rollen und der Rechte optimiert werden.
Ich denke, das Thema geht Hand in Hand, je besser die Rollen, desto schneller ist ein Berechtigungskonzept erstellt und je mehr Berechtigungskonzepte überführt sind, desto schöner ist der Datenstand im System. Dann bin ich jetzt gespannt auf Ihre Fragen und bedanke mich für die Aufmerksamkeit.
Und genau, gehen wir wieder zurück an dich, Matthias. Super, vielen Dank. Das waren wirklich zwei großartige Vorträge, danke euch dafür. Wir haben noch Fragen und das ist sehr gut und ich bitte die Teilnehmer gerne noch mehr dazu zu schreiben, aber wir haben schon eine gute Basis, mit der wir loslegen können. Ich habe eine Frage, die setzt auf etwas auf, was du gerade schon vorgestellt hast, Lara.
Nämlich, ich lese es einfach vor, gibt es Erfahrungswerte einer Delegation des Rollenmanagements aus dem IAM-Team heraus in die Fachbereiche? Das hast du ja schon erwähnt. Wie waren denn eure Erfahrungen, wenn man die Anwendungsverantwortlichen oder die Fachseite tatsächlich involviert war? Kannst du dazu ein bisschen berichten? Das ist ja eine der Silver Bullets, die heißen, wenn ich das machen muss, dann gebe ich das nach draußen, die wissen es eh besser und sollen es immer machen. Wie hat das funktioniert?
Wir arbeiten zum einen bei uns in der Firma mit Ansprechpartnern in jedem Fachbereich, die auf IAM-Themen speziell geschützt sind. Das heißt, wir haben in jedem Fachbereich Multiplikatoren und Ansprechpartner zur Verfügung, die uns dann auch noch mal unterstützen.
Dadurch, dass wir jetzt auch schon relativ lange mit solchen Themen wie Rollenstandarten, Rechtestandarten, Rezertifizierung auf die Bereiche zu gehen, ist da inzwischen auch eine gewisse Akzeptanz da. Ich glaube, da habe ich auch viel, was die Akzeptanz betrifft, der Vorarbeit meiner Kollegen zu verdanken. Aber inzwischen ist da wirklich die Akzeptanz da. Die wissen, hier wird etwas reguliert und wir versuchen es denen auch durch diese Berechtigungskonzepte, Lösungen langfristig einfacher zu machen.
Dadurch, dass wir eben auch diese Unterstützung angeboten haben, die wir dort durch die Studenten haben, ist die Akzeptanz relativ groß und es wird auch relativ wenig delegiert tatsächlich. Meistens sprechen wir mit den Anwendungsverantwortlichen direkt oder bekommen dann eine andere. Manchmal kümmern sich auch andere Leute, die dann benannt werden, um die Berechtigungskonzeption. Aber da bekommen wir in der Regel immer kompetente Personen an die Hand, die uns dann unterstützen.
Da ist auch nicht viel Qualitätssicherung von euch nötig, sondern die verstehen ihr System und das funktioniert eigentlich auch mit dem neuen Konzept. Wir müssen schon Qualität sichern, aber der Schmerz war da und inzwischen. Das ist so eine Geschichte, die kommt einfach übers Lernen, aber da bekommen wir wirklich viel auch in guter Qualität geliefert. Perfekt. Wir können ja die Fragen voten und die Frage, die den meisten Votes hat, ist die nach dem Aufwand. Wie viel Migrationsaufwand pro Berechtigungskonzept, pro Applikation so typisch bei euch? Das ist ganz, ganz schwer zu sagen.
Das ist ein klares kommt drauf an. Wenn wir natürlich Berechtigungskonzepte mit ein, zwei Rechten, ein, zwei Rollen haben, dann hat man ein Konzept auch mal in 30 bis 60 Minuten erstellt. Wenn das jetzt irgendwie ein großes Konzept ist für eine große Anwendung, dann ist es deutlich mehr. Wir haben auch Anwendungen, wo sehr, sehr viel mehr Rechte und Rollen hinter sind.
Und ja, das war dann schon wirklich mehrere Tage Arbeit. Wobei dann da die Arbeit eben war, nicht die Migration der Informationen, sondern eben das Feintuning, also dass eben am Ende alles wirklich genau da ist, wo es hingehört und genau so benannt und beschrieben ist, wie es eben sein muss.
Ja, aber ich frage nochmal nach, du hast nur von Tagen gesprochen, also nicht von Wochen oder Monaten. Ich sage mal Arbeitstagen. Das zieht sich dann natürlich, je nachdem, schon auch mal über mehrere Wochen. Wenn man jede Woche einen Tag macht, kann sich das auch ein bisschen ziehen. Das ist ganz klar. Allein schon wegen anderen Themen, Urlauben, Abwesenheiten. Aber ich denke, es ist alles im Rahmen und wir sind da zuversichtlich, wenn es dann an die Aktualisierung geht, dass das Ganze dann nicht mehr so aufwendig ist. Sehr gut.
Der Alexander hat vorhin gesprochen, dass ihr ganz viel auch Unterstützungsprozesse, AI, Workflows entsprechend mit reinbinden könnt und wollt und auch daran arbeitet. Gibt es so eine Unterstützung auch beim Applikationsonboarding, bei der Übernahme in so ein Berechtigungsmanagement?
Ja, also hier ist es praktisch, alles gut. Hier ist es ja so, dass wir tatsächlich bei der DVK sowas nicht haben. Grundsätzlich ist es auch hier wieder so und kommt darauf an, wenn das Berechtigungskonzept sehr stark strukturiert ist oder sehr gut strukturiert ist, beziehungsweise auch die Versionen relativ ähnlich sind und beispielsweise im Word oder Excel vorliegen, lassen sich die Informationen pausen und können dann bei uns tatsächlich automatisiert übernommen werden. Haben wir bei der DVK diskutiert.
Da gab es dann immer unterschiedliche Versionen, sodass da vermutlich der Aufwand tatsächlich ähnlich hoch war. Wie eine händische Migration. Schwieriges Thema, wenn ich tatsächlich auf Word-Dokumenten arbeite, natürlich da viel zu automatisieren. Verstanden, okay. Ich bin ja Advisor und ich rede viel mit Unternehmen. Eines meiner zentralen Punkte ist das Thema Eigentümerschaft von irgendwas, von einem privilegierten Account, von einer Rolle, von einem System. Beim Lebenszyklus von Rollen gehe ich davon aus, dass ihr natürlich Rolleneigentümer hinterlegt.
Und dann spielen ja zwei Sachen zusammen. Einerseits der Lebenszyklus der Rolle und der Lebenszyklus der Person, die der Rolleneigentümer ist. Was macht man denn bei der DVK, wenn so ein Rolleneigentümer die Rolle wechselt im Unternehmen oder das Unternehmen verlässt? Geht ihr damit um? Wir kontaktieren dann die Führungskraft, die nächste Höre, und bitten dann eben um Zuweisung einer anderen Person. Vielleicht auch noch ergänzen praktisch. Das Ganze läuft dann automatisiert über die Workflows bei euch ab.
Das heißt, da muss keine Person hingehen, also Laura muss nicht die Leute anschreiben, sondern ihr habt Automatismen dahinter, die dann praktisch die Leute anschreiben. Und ich glaube, wenn ich richtig bin bei euch, sogar wenn er nicht reagiert, dann bleibt er, also die Führungskraft einfach als Verantwortlicher. Also ihr sorgt dafür, dass es immer jemanden gibt. Wir motivieren quasi die Führungskraft, jemand anderes zu nennen.
Okay, perfekt. Jetzt muss ich gerade mal gucken. Also wenn ich nach unten gucke, bin ich nicht unhöflich. Da unten sind meine Fragen auf meinem iPad. Deswegen wollen wir mal schnell gucken.
Okay, ein ganz anderer Aspekt. Das ist eine Frage, die wahrscheinlich Richtung Alexander geht. Hybrid Role Mining, was verbirgt sich dahinter, was ist dieser Ansatz? Das ist so ein bisschen Stück weg von der DEVK-Thematik, aber vielleicht kannst du dazu ein bisschen was sagen.
Ja, im Prinzip ist das unser Ansatz, den wir auch bei der DEVK tatsächlich durchgezogen haben. Das bedeutet, ich setze einerseits auf Role Mining-Möglichkeiten aus Nexus. Das heißt, ich kann über entsprechende Eingaben Rollenvorschläge erhalten. Ich kann das Ganze dann aber mit einem Role Engineering Ansatz kombinieren. Das bedeutet, ich gehe tatsächlich dann mit diesem Vorschlag in den Fachbereich Workshops und kläre dort, ob dieser Mining-Vorschlag korrekt ist, ob wir dort noch entsprechende Ergänzungen vornehmen können, sowohl additiv als auch entsprechend entziehend.
Und kann damit praktisch aus meinem gemeinten Rollenkandidaten eine finale Geschäftsrolle machen. Hat gleichzeitig auch den charmanten Vorteil, dass sie sowieso mit Fachbereichen im Gespräch sind und damit praktisch die Rolle dort bekannt ist und dann auch das Thema Ownerschaft, da sind wir wieder bei deinem Thema, Matthias, entsprechend dann auch deutlich leichter durchzusetzen ist, weil die Personen diese Rollen sowieso aus den Workshops schon kennen. Ähnlich hat es die DEVK jetzt übrigens auch für die Berechtigungskonzepte adaptiert.
Das heißt, auch dort wird mit den Verantwortlichen gesprochen und entsprechend dann abgeklärt. Das hatte ich auch eben als Nachfrage, als wir gesagt haben, was habt ihr für Erfahrungen bei der Delegation der Übernahme von Applikationen ins Berechtigungskonzept? Wo liegt denn dann die Eigentümerschaft für das Berechtigungskonzept, für diese Applikation? Liegt die beim Application Owner oder liegt die beim Team, bei Lara? Oder wo liegt die? Die Ownerschaft für ein Berechtigungskonzept liegt beim Application Owner, beim Verantwortlichen für die Applikation.
Und wir unterstützen natürlich, wir beraten, aber die eigentliche Verantwortung, dass da was vorliegt und dass das Ganze eben auch den Vorgaben entspricht, liegt eben bei den Ownern der Anwendung. Okay, perfekt. Du hattest vorhin auf der Folie, ich weiß gar nicht, bei wem es war, es könnte auch sein, dass es bei Alexander war, aber ist egal, es trifft die DEVK, KPIs, da waren Werte dargestellt, um zu zeigen, okay, wir sind so weit, das haben wir erreicht, wir haben so viele Applikationen migriert, wir haben so viele Rollen transformiert.
Wie wichtig sind denn KPIs und die einfache Verfügbarkeit von KPIs durch das Tool, durch das Dashboarding, für euch in der Argumentation gegenüber dem Team, gegenüber den Applikationen, gegenüber denjenigen, die da Aufsicht durchführen, wie wichtig ist das für euch? Ist das eine Argumentationshilfe? Ein Stück weit ja, würde ich sagen, weil natürlich, wenn wir sagen, okay, es haben schon so und so viele Personen gemacht, dann will ja auch keiner irgendwo hinten anstehen und nachher negativ auffallen, als Einziger, ohne die neue Lösung.
Aber grundsätzlich, was bei uns wichtiger ist, ist tatsächlich das Thema Regulatorik. Also wenn es eben in der FIDE oder in der DORA steht, dass es so und so ausschauen muss, und dann die Prüfer entsprechende Anmerkungen geben, dann ist das eben das, was nachher wirklich in der Motivation sieht und wichtig ist. Das heißt, du würdest bestätigen, dass ich da acht Minuten über Regulatorik geredet habe, das war gerechtfertigt?
Absolut, ja. Auf jeden Fall. Okay. Dann muss ich das natürlich den Alex auch fragen. Seht ihr das tatsächlich momentan in den Anfragen aus der Fläche, aus anderen Unternehmen an euch, dass NIST 2, dass DORA tatsächlich die Unternehmen so ein Stück weit umtreibt und jetzt tatsächlich wieder begonnen wird?
Also ja, gerade was diese KPI-Dashboards angeht, gibt es durchaus Nachfragen.
Das heißt, wir haben bei verschiedenen Kunden neben diesen klassischen Inhalts-Dashboards, in denen ich tatsächlich inhaltlich IOM-Elemente Anfragen gestalten kann, du hast immer mal wieder Anwendungsfälle, in der sich Kunden solche KPIs basteln, sei es jetzt, wie viele Geschäftsrollen irgendeine Datenqualitätsregel verletzen, bis hin zu Abdeckungsgraden oder Ähnliches, sodass ich mehr steuernd wirken kann und wirklich so ein Cockpit habe und dann eigentlich diese Actions, die ich entsprechend resultierend habe, dann entsprechend delegieren kann in meine Fachbereiche. Okay.
Also ich sehe, es kommen sehr viele gute Fragen. Keep them going. Also das ist auf jeden Fall schon mal sehr schön. Eins auch meiner Lieblingsthemen immer wieder gern genommen, der Emergency Lever.
Gibt es, ist das etwas, was ihr in Nexus umsetzt? Gibt es dafür Workflows?
Derjenige, ich übersetze es mal kurz ins Deutsche, der am besten innerhalb der nächsten 30 Sekunden nichts mehr unternehmen machen können sollte. Wie wird mit dem umgegangen? Macht ihr das einerseits die EVK, andererseits Nexus? Wie sieht da die Praxis aus? Vielleicht mit Lara anfangen. Das Ganze wird zentral an oberster Stelle gehandhabt. Genau. Also das machen wir woanders. Machen wir woanders. Okay. Aber es ginge, oder, Alex? Klar. Also theoretisch können wir einen Workflow bauen, der im Prinzip per Knopfdruck den User deaktiviert.
Hier muss jetzt aber tatsächlich ja gesagt werden, wenn ich es in Nexus klicke, dadurch, dass wir als Add-on zu sehen sind, muss ich dann die Info natürlich rüber ans IAM-System spielen. Typischerweise kein Problem mit unseren standardisierten Schnittstellen, sodass ich solche Prozesse tatsächlich auch als Emergency Button sogar theoretisch im Nexus abbilden könnte. Okay. Irgendjemand kennt meine Lieblingsthemen bei den Fragen.
Reorganisation an einem Stichtag wirkt sich sofort auf ein Berechtigungskonzept aus, weil natürlich Berechtigungen gerne an Abteilungen, an Organisationsbezeichnungen etc. hängen. Und dabei kann natürlich beliebig viel auch schiefgehen, sodass eine halbe Abteilung dann am Montag nicht mehr arbeiten kann. Das gilt es zu verhindern. Wie kann man innerhalb von Nexus sowas sicherstellen, dass solche Massenänderungen, die man nicht haben möchte, verhindert werden, durch ein gutes, angemessenes Rollendesign? Ich weiß nicht, wer dazu antworten möchte. Ich kann gerne schon mal antworten.
Ja, es ist immer so eine Schwierigkeit, gerade wenn die Informationsläufe so gestrickt sind, dass die IT einen Tag nach der Reorganisation die Info kriegt. Grundsätzlich lässt sich das beispielsweise in Nexus auch darüber lösen, dass wir die Leute nicht sofort entziehen, sondern dass erstmal eine Simulation praktisch stattfindet. Das heißt, ich bekomme angezeigt, was würde entzogen werden und kann das beispielsweise nochmal bestätigen, sodass ich hier nicht mit runtergezogenen Hosen umgangssprachlich dastehe, sondern nochmal gegensteuern könnte. Okay.
Eine Frage können wir noch, denke ich mir. Ja, eine schaffen wir noch. Soll ist Abgleich. Das heißt, in dem Moment, wo eine Provisionierung stattgefunden hat, wo also aus einer Rollendefinition einer Zuordnung zu einer Person tatsächlich konkret in einer Applikation provisioniert wird, wie funktioniert der Soll-Ist-Abgleich dann tatsächlich und wie geht Nexus damit um, insbesondere wenn es viele Applikationen sind? Also wie kann man sich das einfach gut vorstellen, dass tatsächlich das, was man möchte, das in den Systemen stattfindet, auch tatsächlich in den Systemen stattfindet?
Wie erfolgt das technisch von der Konnektivität etc.? Ja, also grundsätzlich haben wir da tatsächlich zwei verschiedene Philosophien, die unsere Kunden mit den Berechtigungskonzepten umsetzen. Einerseits kann ich sagen, das Berechtigungskonzept ist ausschlaggebend für meine Berechtigungen. Das heißt, das, was ich da drücke, muss dann im Nachgang im Prinzip in die IAM-Systeme gepusht werden.
Und da ist es tatsächlich so, ich klicke im Nexus beispielsweise in meinem Konzept, sage, ich möchte hier eine Berechtigung entziehen und dann wird das Ganze als Freigabe im Rahmen des Berechtigungskonzepts in den Auftrag an das IAM geschickt und provisioniert. Die zweite Option ist tatsächlich, dass ein Berechtigungskonzept so ein bisschen hinterherläuft. Das ist nicht 100 Prozent der Regulatorik vielleicht entsprechend, ist allerdings meistens der einfachere Ansatz aufwandstechnisch.
Das bedeutet, ich review meine Berechtigungskonzepte regelmäßig, hol mir da den Snapshot des Ist-Zustands, kann das Ganze überprüfen, kann dort Änderungen vornehmen und sobald ich es bestätigt habe, dann ist im Prinzip, das ist dem Soll wieder angepasst. Das heißt, entweder habe ich ein vorherlaufendes Berechtigungskonzept, dann habe ich tatsächlich Aktionen oder ich habe ein Berechtigungskonzept, das im Prinzip hinterherläuft, in Anführungszeichen, und dann eigentlich das eher bestätigt oder überprüft, was denn heute umgesetzt ist.
Okay, prima. Vielen Dank. Wir laufen auf das Ende der Stunde zu, die wir hatten. Insofern würde ich jetzt langsam an das Abmoderieren gehen. Es waren zwei tolle Vorträge. Ich bedanke mich bei euch dafür. Ich bedanke mich bei den Teilnehmern für die tollen Fragen und fürs Teilnehmen. Es hat wirklich großen Spaß gemacht. Wenn weitere Fragen kommen, ich gehe davon aus, eure Mailadressen sind leicht rauszufinden, sodass man auf euch nochmal zugehen kann. Das Gleiche gilt auch für mich.
Ich würde mich freuen, wenn es da noch Feedback gäbe und wenn das auch weiter für Richtung Nexus und Richtung DEVK laufen würde. Ansonsten kann ich mich nur noch bei euch beiden bedanken für die Teilnahme hier an diesem Webinar und hoffe, dass es den Teilnehmern was gebracht hat und für die Sichtbarkeit eines wirklich guten und erfolgreichen DEVK-Rollenkonzeptes, denke ich, ist es auch hilfreich, weil ab und zu muss man auch Tue Gutes und Rede darüber sagen und das klang ziemlich gut, was ihr da präsentiert habt. Ich danke euch. Danke auch für die tolle Organisation. Alles klar.
Dankeschön und auf Wiederhören. Auch danke an die Teilnehmer. Bis dahin. Tschüss.
