Wir bauen ein Rollenmodell für die Zugriffssteuerung auf. Teil eins, vorbereitend.

Zurzeit arbeite ich in einem Softwareanbieter-Unternehmen, konkret im Bereich der Zugangsverwaltung. Mein früherer Berufshorizont stammt von der Kundenseite – einer großen Finanzorganisation. Damals konnte unsere Gruppe für Zugangssteuerung im IT-Sicherheitsdepartement nicht mit großen Kompetenzen im IdM aufwarten. Wir haben im Laufe der Zeit viel gelernt und mussten viele Fehler machen, um in der Firma einen funktionierenden Mechanismus zur Verwaltung von Benutzerrechten in Informationssystemen aufzubauen.

Indem ich meine schmerzhaften Erfahrungen von der Kundenseite mit dem Wissen und den Kompetenzen des Anbieters kombiniere, möchte ich mit Ihnen im Grunde eine Schritt-für-Schritt-Anleitung teilen: wie man in einem großen Unternehmen ein Rollenmodell für die Zugangsverwaltung erstellt und welchen Nutzen man daraus zieht. Meine Anleitung besteht aus zwei Teilen: der erste – Vorbereitungen für den Aufbau des Modells, der zweite – das eigentliche Bauen. Vor Ihnen liegt der erste Teil, die Vorbereitung.

N.B. Der Aufbau eines Rollenmodells ist leider kein Ergebnis, sondern ein Prozess. Genauer gesagt, ist es sogar ein Teil des Schaffensprozesses in der Firma für ein Zugangsmanagement-Ökosystem. Bereiten Sie sich also auf ein langfristiges Spiel vor.

Zunächst lassen Sie uns klären – was ist Zugangsverwaltung auf Rollenbasis? Angenommen, Sie haben eine große Bank mit Dutzenden oder gar Hunderttausenden von Mitarbeitern (Subjekten), von denen jeder Dutzende von Zugriffsrechten in Hunderten von internen Informationssystemen (Objekten) hat. Multiplizieren Sie nun die Anzahl der Objekte mit der Anzahl der Subjekte – genau so viele Verbindungen müssen Sie zunächst aufbauen und dann überwachen. Ist es realistisch, dies manuell zu tun? Natürlich nicht – um diese Aufgabe zu lösen, wurden Rollen eingeführt.

Eine Rolle ist eine Sammlung von Berechtigungen, die ein Benutzer oder eine Benutzergruppe zur Erledigung bestimmter Arbeitsaufgaben benötigt. Jeder Mitarbeiter kann eine oder mehrere Rollen haben, und jede Rolle kann von einer bis zu vielen Berechtigungen enthalten, die dem Benutzer innerhalb dieser Rolle gewährt werden. Rollen können an bestimmte Positionen, Abteilungen oder funktionale Aufgaben der Mitarbeiter gebunden sein.

Rollen werden normalerweise aus einzelnen Befugnissen eines Mitarbeiters in jedem Informationssystem erstellt. Anschließend werden aus den Rollen jedes Systems globale Geschäftsrollen gebildet. Zum Beispiel umfasst die Geschäftsrolle "Kreditmanager" mehrere einzelne Rollen in Informationssystemen, die im Kundenbüro der Bank verwendet werden. Sagen wir, in Systemen wie dem Hauptautomatisierungssystem der Bank, dem Kassamodul, dem System für elektronische Dokumentenverarbeitung, dem Service-Manager und anderen. Geschäftsrollen sind in der Regel an die organisatorische Struktur gebunden – einfacher gesagt, an eine Reihe von Abteilungen innerhalb des Unternehmens und deren Stellen. So entsteht eine globale Rollenmatrix (ein Beispiel siehe in der Tabelle unten).

Es ist zu beachten, dass es einfach unmöglich ist, ein 100 % Rollenmodell zu erstellen, das alle erforderlichen Befugnisse für jede Position in der kommerziellen Struktur sicherstellt. Und das ist auch nicht nötig. Denn ein Rollenmodell kann nicht statisch sein, da es von einem sich ständig ändernden Umfeld abhängt. Und von den Veränderungen in den Geschäftsaktivitäten des Unternehmens, die entsprechend die Organisationsstruktur und die Funktionalität beeinflussen. Und von der unzureichenden Ressourcenausstattung, und von der Nichteinhaltung der Stellenbeschreibungen, und von dem Streben nach Gewinn auf Kosten der Sicherheit sowie von vielen anderen Faktoren. Daher muss ein Rollenmodell entwickelt werden, das bis zu 80 % der Benutzerbedürfnisse hinsichtlich der notwendigen Grundrechte bei der Ernennung auf eine Position abdeckt. Die verbleibenden 20 % können bei Bedarf später durch separate Anträge angefordert werden.

Natürlich können Sie fragen: „Gibt es überhaupt 100 % Rollenmodelle?“ Nun, warum nicht? Solche Modelle finden sich beispielsweise in Non-Profit-Organisationen, die nicht häufigen Veränderungen unterworfen sind – in einem Forschungsinstitut. Oder in Unternehmen der Rüstungsindustrie mit einem hohen Schutzniveau, wo Sicherheit an erster Stelle steht. Gelegentlich gibt es sie auch in kommerziellen Strukturen, aber innerhalb einer bestimmten Abteilung, deren Arbeit ein relativ statischer und vorhersehbarer Prozess ist.

Der größte Vorteil des rollenbasierten Managements liegt in der Vereinfachung der Berechtigungserteilung, da die Anzahl der Rollen erheblich geringer ist als die Anzahl der Benutzer im Informationssystem. Dies trifft auf jede Branche zu.

Nehmen wir ein Einzelhandelsunternehmen: Dort arbeiten Tausende von Verkäufern, aber die Berechtigungen im System N sind für sie identisch, und es wird nur eine Rolle für sie erstellt. Ein neuer Verkäufer kommt in das Unternehmen – ihm wird automatisch die erforderliche Rolle im System zugewiesen, in dem bereits alle notwendigen Berechtigungen vorhanden sind. Auch mit einem Klick können die Berechtigungen für Tausende von Verkäufern gleichzeitig geändert werden, zum Beispiel, indem eine neue Option zur Berichtserstellung hinzugefügt wird. Es ist nicht nötig, Tausende von Operationen durchzuführen, um die neue Berechtigung an jedes Benutzerkonto zu binden – es reicht aus, diese Option in die Rolle aufzunehmen, und sie wird gleichzeitig für alle Verkäufer verfügbar sein.

Ein weiterer Vorteil des rollenspezifischen Managements ist der Ausschluss der Vergabe inkompatibler Berechtigungen. Das heißt, ein Mitarbeiter, der eine bestimmte Rolle im System hat, kann nicht gleichzeitig eine andere Rolle haben, deren Berechtigungen nicht mit den Berechtigungen der ersten kompatibel sind. Ein anschauliches Beispiel dafür ist das Verbot, Eingabe- und Kontrollfunktionen bei finanziellen Transaktionen zu kombinieren.

Alle, die interessiert sind, wie das rollenbasierte Zugriffsmanagement entstanden ist, können
in die Geschichte eintauchen
Wenn wir auf die Geschichte zurückblicken, dann begann die IT-Community bereits in den 70er Jahren des 20. Jahrhunderts über Methoden des Zugriffsmanagements nachzudenken. Zwar waren die Anwendungen damals recht einfach, doch wie auch heute wollten alle bequem den Zugriff darauf verwalten. Berechtigungen für Benutzer zu erteilen, zu ändern und zu kontrollieren – einfach um zu verstehen, welcher Zugriff jedem einzelnen zusteht. Zu dieser Zeit gab es jedoch keine allgemeinen Standards; die ersten Systeme zum Zugriffsmanagement wurden entwickelt, und jedes Unternehmen basierte auf seinen eigenen Vorstellungen und Regeln.

Heute sind viele verschiedene Modelle des Zugriffsmanagements bekannt, aber sie sind nicht von heute auf morgen entstanden. Lassen Sie uns auf diejenigen eingehen, die einen spürbaren Beitrag zur Entwicklung dieses Bereichs geleistet haben.

Das erste und wahrscheinlich das einfachste Modell ist das diskretionäre (wahlweise) Zugriffsmanagement (DAC – Discretionary Access Control). Dieses Modell ermöglicht es allen Beteiligten im Zugriffsprozess, gemeinsame Rechte zu nutzen. Jeder Benutzer erhält Zugang zu bestimmten Objekten oder Operationen. Im Grunde genommen entspricht die Vielzahl der Rechteinhaber einer Vielzahl von Objekten. Dieses Modell wurde als zu flexibel und zu komplex für die Verwaltung angesehen: Die Zugriffslisten werden im Laufe der Zeit riesig und schwer zu kontrollieren.

Das zweite Modell ist Die mandatierte Zugangskontrolle (MAC – Mandatory Access Control). In diesem Modell erhält jeder Benutzer Zugriff auf ein Objekt basierend auf der formal erteilten Erlaubnis für ein bestimmtes Datenschutzniveau. Dementsprechend müssen die Objekte nach ihrem Datenschutzniveau kategorisiert werden. Im Gegensatz zum ersten flexiblen Modell hat sich dieses als zu strikt und einschränkend erwiesen. Ihre Anwendung rechtfertigt sich nicht, wenn in einem Unternehmen viele verschiedene Informationsressourcen vorhanden sind: Um den Zugriff auf unterschiedliche Ressourcen zu regeln, müssen zahlreiche Kategorien eingeführt werden, die sich nicht überschneiden.

Angesichts der offensichtlichen Unzulänglichkeiten dieser beiden Methoden hat die IT-Community weiterhin Modelle entwickelt, die flexibler und mehr oder weniger universell zur Unterstützung verschiedener Arten von organisatorischen Zugriffsrichtlinien sind. Und so entstand das dritte Modell der zugriffsbasierenden Kontrolle auf Rollenbasis! Dieser Ansatz hat sich als die vielversprechendste Lösung erwiesen, da er nicht nur die Authentifizierung der Identität des Benutzers erfordert, sondern auch seine Arbeitsfunktionen in den Systemen.

Die erste klar definierte Struktur des Rollenmodells wurde 1992 von den amerikanischen Wissenschaftlern David Ferraiolo und Richard Kuhn vom National Institute of Standards and Technology (NIST) vorgestellt. Damals wurde erstmals der Begriff RBAC (Role-Based Access Control) eingeführt. Diese Forschungen und die Beschreibungen der grundlegenden Komponenten sowie deren Zusammenhänge bilden die Grundlage des bis heute gültigen Standards INCITS 359-2012, der vom International Committee for Information Technology Standards (INCITS) genehmigt wurde.

Der Standard definiert eine Rolle als „eine Position im Kontext einer Organisation mit einer bestimmten damit verbundenen Semantik in Bezug auf die Befugnisse und Verantwortlichkeiten, die einem Benutzer zugewiesen sind, der dieser Rolle zugewiesen ist“. Das Dokument legt die grundlegenden Elemente von RBAC fest – Benutzer, Sitzungen, Rollen, Berechtigungen, Operationen und Objekte sowie die Beziehungen und Interaktionen zwischen ihnen.

Der Standard bietet eine minimal notwendige Struktur zur Erstellung eines Rollenmodells – die Zusammenfassung von Rechten in Rollen und dann die Gewährung von Zugang zu Benutzern über diese Rollen. Es werden Mechanismen zum Zusammenstellen von Rollen aus Objekten und Operationen definiert, die Rollenhierarchie und die Vererbung von Befugnissen werden beschrieben. In jedem Unternehmen gibt es Rollen, die elementare Befugnisse bündeln, die allen Mitarbeitern des Unternehmens notwendig sind. Dazu kann der Zugang zu E-Mails, zu einem Dokumentenmanagementsystem, zum Unternehmensportal usw. gehören. Diese Befugnisse können in eine gemeinsame Rolle namens „Mitarbeiter“ zusammengefasst werden, sodass nicht in jeder höheren Rolle alle elementaren Rechte immer wieder aufgezählt werden müssen. Es reicht aus, das Vererbungssymbol der Rolle „Mitarbeiter“ anzugeben.

Später wurde der Standard um neue Zugriffsattribute ergänzt, die mit der sich ständig verändernden Umgebung zusammenhängen. Es wurde die Möglichkeit hinzugefügt, statische und dynamische Einschränkungen einzuführen. Statische beziehen sich auf die Unmöglichkeit, Rollen zu kombinieren (jene Eingabe und Kontrolle von Operationen, die oben erwähnt wurde). Dynamische Einschränkungen können durch variable Parameter definiert werden, z. B. Zeit (Arbeits-/Nichtarbeitszeiten oder -tage), Standort (Büro/Zuhause) usw.

Es ist erwähnenswert, dass die attributbasierte Zugriffskontrolle (ABAC – Attribute-based access control). Der Ansatz basiert auf der Bereitstellung von Zugang durch Regeln zur gemeinsamen Nutzung von Attributen. Dieses Modell kann unabhängig verwendet werden, ergänzt jedoch häufig aktiv das klassische Rollenmodell: Zu einer bestimmten Rolle können Benutzer-, Ressourcen- und Gerätetattribute sowie Zeit- oder Standortattribute hinzugefügt werden. Dies ermöglicht die Verwendung weniger Rollen, die Einführung zusätzlicher Einschränkungen und schafft minimal ausreichenden Zugang, was somit die Sicherheit erhöht.

Beispielsweise kann einem Buchhalter der Zugriff auf Konten gestattet werden, wenn er in einer bestimmten Region arbeitet. Dann wird der Standort des Fachmanns mit einem bestimmten Referenzwert verglichen. Alternativ kann der Zugriff auf Konten nur gewährt werden, wenn sich der Benutzer von einem registrierten Gerät aus anmeldet. Eine gute Ergänzung zum Rollenmodell, wird jedoch selten allein verwendet, da es notwendig ist, viele Regeln und Berechtigungstabellen zu erstellen.

Ich gebe ein Beispiel für die Anwendung von ABAC aus meinem 'früheren Leben'. In unserer Bank gab es mehrere Filialen. Die Mitarbeiter der Kundenbüros in diesen Filialen führten absolut identische Vorgänge aus, durften jedoch nur in der Hauptsystem mit Konten ihrer Region arbeiten. Zuerst begannen wir, separate Rollen für jede Region zu erstellen – und es entstanden sehr viele Rollen mit sich wiederholender Funktionalität, aber mit Zugriff auf unterschiedliche Konten! Dann reduzierten wir die Anzahl der Rollen im System erheblich, indem wir das Standortattribut des Benutzers verwendeten und es mit einem bestimmten Kontobereich zur Überprüfung verknüpften. Infolgedessen blieben nur Rollen für eine Filiale übrig, die auf die entsprechenden Positionen in allen anderen territorialen Einheiten der Bank übertragen wurden.

Und jetzt sprechen wir über die notwendigen Vorbereitungsschritte, ohne die es einfach unmöglich ist, ein funktionierendes Rollenmodell zu erstellen.

Schritt 1. Wir erstellen ein funktionales Modell

Es ist ratsam, mit der Erstellung eines funktionalen Modells zu beginnen – einem übergeordneten Dokument, in dem die Funktionen jeder Abteilung und jedes Berufsbild detailliert beschrieben sind. In der Regel stammt die Information aus verschiedenen Dokumenten wie Stellenbeschreibungen und Richtlinien für einzelne Abteilungen – wie Büros, Verwaltungseinheiten und Abteilungen. Das funktionale Modell muss mit allen betroffenen Abteilungen (Geschäft, interne Kontrolle, Sicherheit) abgestimmt und von der Unternehmensleitung genehmigt werden. Warum ist dieses Dokument nötig? Damit das Rollenmodell darauf Bezug nehmen kann. Wenn Sie beispielsweise ein Rollenmodell basierend auf bereits bestehenden Rechten der Mitarbeiter – die aus dem System exportiert und „auf einen gemeinsamen Nenner gebracht“ wurden – erstellen möchten, können Sie bei der Abstimmung der erhaltenen Rollen mit dem Geschäftsbesitzer des Systems auf einen konkreten Punkt des funktionalen Modells verweisen, der die Aufnahme bestimmter Rechte in die Rolle begründet.

Schritt 2. Auditing der IT-Systeme und Erstellung eines Priorisierungsplans

In der zweiten Phase sollte ein Audit der IT-Systeme durchgeführt werden, um zu verstehen, wie der Zugang zu ihnen organisiert ist. In meinem Finanzunternehmen wurden mehrere hundert Informationssysteme betrieben. In allen Systemen gab es einige Ansätze des rollenbasierten Zugriffsmanagements, in den meisten Fällen jedoch nur auf Papier oder in den Systemverzeichnissen – diese waren längst veraltet, und der Zugang wurde basierend auf tatsächlichen Benutzeranfragen gewährt. Es ist selbstverständlich, dass es unmöglich ist, ein Rollenmodell gleichzeitig in mehreren hundert Systemen zu erstellen, man muss irgendwo anfangen. Wir haben eine eingehende Analyse des Zugriffsmanagementprozesses durchgeführt, um dessen Reifegrad zu bestimmen. Im Zuge der Analyse haben wir Kriterien für die Priorisierung der Informationssysteme entwickelt – Kritikalität, Bereitschaft, Pläne für die Außerbetriebnahme usw. Mit diesen Kriterien haben wir die Reihenfolge für die Entwicklung/Aktualisierung der Rollenmodelle für diese Systeme festgelegt. Anschließend haben wir die Rollenmodelle in den Integrationsplan mit der Identity-Management-Lösung aufgenommen, um das Zugriffsmanagement zu automatisieren.

Wie können Sie also die Kritikalität eines Systems bestimmen? Beantworten Sie sich folgende Fragen:

• Ist das System mit den betrieblichen Prozessen verbunden, von deren Ausführung die Kernaktivitäten des Unternehmens abhängen?
• Wird eine Störung des Systems die Integrität der Unternehmensassets beeinträchtigen?
• Wie lange ist die maximal zulässige Ausfallzeit des Systems, nach deren Überschreitung eine Wiederherstellung der Aktivitäten nicht mehr möglich ist?
• Kann eine Beeinträchtigung der Datenintegrität im System zu irreversiblen Konsequenzen führen, sowohl finanzieller als auch reputationsbezogener Art?
• Kritikalität gegenüber Betrug. Vorhandensein von Funktionen, bei unzureichender Kontrolle, die die Durchführung interner/externer betrügerischer Aktivitäten ermöglichen;
• Was sind die gesetzlichen Anforderungen sowie die internen Richtlinien und Verfahren für diese Systeme? Werden Strafen von den Regulierungsbehörden bei Nichteinhaltung verhängt?

In unserem Finanzunternehmen haben wir ein Audit so durchgeführt. Die Geschäftsleitung hat das Verfahren für die Überprüfung der Zugriffsrechte entwickelt, um die bestehenden Benutzer und deren Berechtigungen zunächst in den Informationssystemen zu identifizieren, die auf der Liste der prioritären Systeme stehen. Die Verantwortung für diesen Prozess wurde der Sicherheitsabteilung übertragen. Um jedoch ein vollständiges Bild der Zugriffsrechte im Unternehmen zu erhalten, musste die IT-Abteilung und der Geschäftsbereich in den Prozess einbezogen werden. Hier begannen die Streitigkeiten, Missverständnisse und manchmal sogar Sabotage: Niemand möchte sich von seinen aktuellen Aufgaben ablenken lassen und sich an zunächst unklaren Aktivitäten beteiligen.

N.B. Große Unternehmen mit ausgereiften IT-Prozessen sind sicherlich mit dem Verfahren des IT-Audits – IT General Controls (ITGC) – vertraut, das es ermöglicht, Schwächen in den IT-Prozessen zu identifizieren und die Kontrolle so zu optimieren, dass die Prozesse gemäß den Best Practices (ITIL, COBIT, IT Governance usw.) verbessert werden. Ein solches Audit ermöglicht es IT und Geschäft, sich besser zu verstehen und eine gemeinsame Entwicklungsstrategie zu entwickeln, Risiken zu analysieren, Kosten zu optimieren und effektivere Arbeitsansätze zu entwickeln.



Eines der Auditschwerpunkte ist die Bestimmung der Parameter für den logischen und physischen Zugang zu Informationssystemen. Die gesammelten Daten haben wir als Grundlage für die weitere Nutzung beim Aufbau des Rollenmodells genommen. Infolge eines solchen Audits haben wir ein Register der IT-Systeme erstellt, in dem deren technische Parameter definiert und beschrieben wurden. Zudem wurde für jedes System ein Eigentümer aus dem Geschäftsfeld bestimmt, im Interesse dessen es betrieben wurde: Er war verantwortlich für die Geschäftsprozesse, die dieses System unterstützte. Außerdem wurde ein IT-Service-Manager ernannt, der für die technische Umsetzung der Geschäftsanforderungen in einem bestimmten IS verantwortlich war. Die kritischsten Systeme für das Unternehmen sowie deren technische Parameter, Fristen für Inbetriebnahme und Stilllegung etc. wurden dokumentiert. Diese Parameter haben den Prozess der Vorbereitung zum Aufbau des Rollenmodells wesentlich unterstützt.

Schritt 3 Methodik erstellen

Der Schlüssel zum Erfolg eines jeden Vorhabens ist die richtig gewählte Methode. Deshalb müssen wir auch für den Aufbau des Rollenmodells und für die Durchführung des Audits eine Methodik erstellen, in der wir die Interaktion zwischen den Abteilungen beschreiben, Verantwortlichkeiten in den Unternehmensrichtlinien festlegen usw.
Zunächst müssen alle vorhandenen Dokumente untersucht werden, die das Verfahren zur Gewährung von Zugriffsrechten und -berechtigungen festlegen. Im Idealfall sollten die Prozesse auf mehreren Ebenen dokumentiert sein:

• allgemeine Unternehmensanforderungen;
• Anforderungen aus dem Bereich der Informationssicherheit (abhängig von den Tätigkeitsbereichen der Organisation);
• Anforderungen an die technologischen Prozesse (Anleitungen, Zugriffsmatrizen, methodische Hinweise, Anforderungen an Konfigurationen).

In unserem Finanzunternehmen haben wir viele veraltete Dokumente gefunden – wir mussten sie an die implementierten neuen Prozesse anpassen.

Auf Anweisung der Unternehmensleitung wurde eine Arbeitsgruppe eingerichtet, in die Vertreter aus den Bereichen Sicherheit, IT, Geschäft und interne Kontrolle eintraten. In der Anweisung wurden die Ziele der Gruppengründung, die Tätigkeitsrichtung, die Dauer der Existenz und die Verantwortlichen von jeder Seite festgelegt. Darüber hinaus haben wir eine Methodik zur Durchführung von Audits und zur Erstellung eines Rollenkonzepts entwickelt: Diese wurden von allen verantwortlichen Vertretern der Bereiche abgestimmt und von der Unternehmensführung genehmigt.

Dokumente, die den Ablauf der Arbeiten, Fristen, Verantwortlichkeiten usw. beschreiben – sind der Schlüssel dazu, dass auf dem Weg zum angestrebten Ziel, das zu Beginn nicht für jeden offensichtlich ist, niemand Fragen aufwirft wie „Warum machen wir das und wozu brauchen wir das?“ und es keine Möglichkeit gibt, das Vorhaben zu stoppen oder den Prozess zu verlangsamen.

Schritt 4. Wir dokumentieren die Parameter des bestehenden Zugriffsmanagementmodells.

Wir erstellen sozusagen einen „Systempass“ für das Zugriffsmanagement. Eigentlich handelt es sich um einen Fragebogen zu einem bestimmten Informationssystem, in dem alle Algorithmen des Zugriffsmanagements festgehalten sind. Unternehmen, die bereits Lösungen aus der IdM-Klasse implementiert haben, sind mit einem solchen Fragebogen sicherlich vertraut, denn genau dort beginnt die Untersuchung der Systeme.

Ein Teil der System- und Besitzerparameter wurde aus dem IT-Register in den Fragebogen übernommen (siehe Schritt 2, Audit), aber es wurden auch neue hinzugefügt:

• wie das Management von Benutzerkonten erfolgt (direkt in der DB oder über Programmierschnittstellen);
• wie die Benutzer in das System einloggen (mit einem separaten Konto oder unter Verwendung eines AD-, LDAP- oder anderen Kontos);
• welche Zugriffsebenen im System verwendet werden (Anwendungsebene, Systemebene, Nutzung des Netzwerkinternen von Dateiresourcen);
• Beschreibung und Parameter Server, auf denen das System läuft;
• welche Operationen zur Verwaltung von Benutzerkonten unterstützt werden (Sperre, Umbenennung usw.);
• nach welchen Algorithmen oder Regeln die Benutzeridentifikation des Systems gebildet wird;
• nach welchem Attribut eine Verbindung zum Datensatz des Mitarbeiters im Personalmanagementsystem hergestellt werden kann (Name, Personalnummer oder anderes);
• alle möglichen Attribute des Benutzerkontos und die Regeln für deren Ausfüllung;
• welche Zugriffsrechte im System existieren (Rollen, Gruppen, atomare Rechte usw., ob es verschachtelte oder hierarchische Rechte gibt);
• Zugriffsberechtigungen trennen (nach Positionen, Abteilungen, Funktionen usw.);
• Gibt es im System Regeln zur Trennung von Pflichten (SOD – Segregation of Duties), und wie funktionieren sie;
• Wie werden im System Ereignisse wie Abwesenheiten, Versetzungen, Kündigungen, Aktualisierungen von Mitarbeiterdaten usw. behandelt?

Diese Liste kann mit Details zu verschiedenen Parametern und anderen Objekten, die an der Zugangsverwaltung beteiligt sind, fortgesetzt werden.

Schritt 5. Erstellen einer geschäftsorientierten Beschreibung der Berechtigungen

Ein weiteres Dokument, das wir für den Aufbau des Rollenmodells benötigen, ist ein Verzeichnis aller möglichen Berechtigungen (Rechte), die Benutzern im Informationssystem gewährt werden können, sowie eine ausführliche Beschreibung der zugrunde liegenden Geschäftsstrategie. Häufig sind Berechtigungen im System durch bestimmte Bezeichnungen verschlüsselt, die aus Buchstaben und Zahlen bestehen, sodass die Mitarbeiter im Geschäft nicht verstehen können, was sich hinter diesen Symbolen verbirgt. Wenn sie dann die IT-Abteilung kontaktieren, können auch diese beispielsweise zu selten genutzten Rechten keine Antwort geben. In diesem Fall ist zusätzliche Testung erforderlich.

Es ist vorteilhaft, wenn eine Geschäftsbeschreibung bereits vorliegt oder sogar eine Zusammenfassung dieser Rechte in Gruppen und Rollen erfolgt ist. Für einige Anwendungen ist es eine bewährte Praxis, ein solches Verzeichnis bereits in der Entwicklungsphase anzulegen. Das kommt jedoch selten vor, weshalb wir wieder zur IT-Abteilung gehen, um Informationen über alle möglichen Rechte zu sammeln und diese zu beschreiben. Unser Verzeichnis wird letztendlich Folgendes umfassen:

• Name der Berechtigung, einschließlich des Objekts, auf das sich das Zugriffsrecht bezieht;
• Aktion, die mit dem Objekt durchgeführt werden darf (Anzeigen, Ändern usw., möglicherweise mit Einschränkungen, z. B. nach geographischer Region oder Kundengruppe);
• Code der Berechtigung (Code und Name der Funktion/Anfrage des Systems, die unter Verwendung der Berechtigung ausgeführt werden können);
• Beschreibung der Berechtigung (detaillierte Beschreibung der Aktionen im IS bei Anwendung der Berechtigung und deren Auswirkungen auf den Prozess;
• Status der Berechtigung: „Aktiv“ (wenn die Berechtigung mindestens einem Benutzer zugewiesen ist) oder „Inaktiv“ (wenn die Berechtigung nicht verwendet wird).

Schritt 6. Exportieren von Benutzerdaten und Rechten aus den Systemen und Abgleich mit der Personalquelle

In der letzten Phase der Vorbereitung müssen die Daten aus den Informationssystemen über alle Benutzer und die aktuellen Berechtigungen, die sie haben, exportiert werden. Es gibt hier zwei Szenarien. Erstens: Die Sicherheitsabteilung hat direkten Zugang zum System und die Mittel, um entsprechende Berichte zu exportieren, was nicht häufig vorkommt, aber sehr praktisch ist. Zweitens: Wir senden eine Anfrage an die IT, um die Berichte im erforderlichen Format zu erhalten. Die Praxis zeigt: Es gelingt nicht immer, mit der IT zu verhandeln und die notwendigen Daten beim ersten Mal zu erhalten. Man muss mehrere Ansätze unternehmen, bis die Informationen im gewünschten Format vorliegen.

Welche Daten müssen exportiert werden:

• Bezeichnung des Benutzerkontos
• Vollständiger Name des Mitarbeiters, dem es zugeordnet ist
• Status (aktiv oder gesperrt)
• Erstellungsdatum des Benutzerkontos
• Datum der letzten Nutzung
• Liste der verfügbaren Berechtigungen/Gruppen/Rollen

Also, wir haben die Exporte aus dem System mit allen Benutzern und allen Rechten, die ihnen gewährt wurden, erhalten. Und sofort haben wir alle gesperrten Konten beiseitegelegt, da die Arbeit am Aufbau des Rollenmodells nur mit aktiven Benutzern fortgesetzt wird.

Danach, falls Ihr Unternehmen keine automatisierten Mittel zur Schließung des Zugangs für ausgeschiedene Mitarbeiter hat (was oft der Fall ist) oder eine fragmentierte Automatisierung existiert, die nicht immer korrekt funktioniert, müssen alle „toten Seelen“ identifiziert werden. Es geht um Konten von bereits ausgeschiedenen Mitarbeitern, deren Berechtigungen aus irgendeinem Grund nicht gesperrt sind – diese müssen gesperrt werden. Zu diesem Zweck gleichen wir die exportierten Daten mit der Personalquelle ab. Auch die Personalexporte müssen im Voraus beim zuständigen Bereich, der die Personalbasis führt, eingeholt werden.

Zunächst sollten Konten, deren Inhaber in der Personalbasis nicht gefunden werden konnten und die niemandem zugeordnet sind – also herrenlos sind – getrennt erfasst werden. Für diese Liste benötigen wir das Datum der letzten Nutzung: Wenn es relativ aktuell ist, müssen wir dennoch nach den Eigentümern suchen. Dazu können Konten externer Auftragnehmer oder Dienstkonten gehören, die nicht zugeordnet sind, jedoch mit bestimmten Prozessen verbunden sind. Um die Zuordnung der Konten zu klären, können wir allen Abteilungen Briefe mit der Bitte um Rückmeldung schicken. Sobald die Eigentümer gefunden sind, tragen wir ihre Daten in das System ein: So sind alle aktiven Konten identifiziert, und die anderen werden gesperrt.

Sobald unsere Exporte von unnötigen Einträgen bereinigt sind und nur aktive Konten verbleiben, können wir mit dem Aufbau eines Rollenmodells für das spezifische Informationssystem beginnen. Aber darüber werde ich im nächsten Artikel sprechen.

Autor: Ljudmila Sewastjanowa, Marketingmanagerin bei Solar inRights

Quelle: habr.com