Wir bauen ein Rollenmodell für das Zugangsmanagement. Teil Eins, Vorbereitung

Derzeit arbeite ich bei einem Softwareanbieter, insbesondere im Bereich von Zugangsmanagementlösungen. Mein Wissen stamme aus der Zeit auf der Nachfrageseite – einer großen Finanzorganisation. Damals konnte unsere Gruppe im Bereich Zugangskontrolle im IT-Sicherheitsdepartment nicht mit großen Kompetenzen im Identity Management (IdM) aufwarten. Wir mussten viel lernen und einen steinigen Weg gehen, um in der Firma ein funktionierendes Managementsystem für Benutzerrechte in Informationssystemen aufzubauen.

Indem ich meine leidenschaftlich gesammelten Erfahrungen auf der Nachfrageseite mit den Kenntnissen und Kompetenzen des Anbieters kombiniere, möchte ich Ihnen eine Schritt-für-Schritt-Anleitung geben: Wie man in einem großen Unternehmen ein Rollenmodell für das Zugangsmanagement erstellt und welche Vorteile sich daraus ergeben. Mein Leitfaden besteht aus zwei Teilen: Der erste Teil behandelt die Vorbereitung zur Erstellung des Modells, der zweite Teil beschreibt den eigentlichen Aufbau. Sie sehen hier den ersten Teil, die Vorbereitung.

N.B. Der Aufbau eines Rollenmodells ist leider kein Endergebnis, sondern ein Prozess. Genauer gesagt, es ist Teil des Prozesses zur Schaffung eines Zugangsmanagement-Ökosystems in der Firma. Bereiten Sie sich also darauf vor, langfristig zu denken.

Lassen Sie uns zunächst klären, was rollenbasiertes Zugriffsmanagement ist. Stellen Sie sich vor, Sie betreiben eine große Bank mit Zehntausenden oder sogar Hunderttausenden von Mitarbeitern (Subjekten), die jeweils über Dutzende von Zugriffsrechten in Hunderten interner Informationssysteme (Objekten) verfügen. Multiplizieren Sie nun die Anzahl der Objekte mit der Anzahl der Subjekte – genau so viele Beziehungen müssen Sie zunächst aufbauen und später überwachen. Ist es realistisch, dies manuell zu verwalten? Natürlich nicht – genau dafür wurden Rollen entwickelt.

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 einer Vielzahl von Berechtigungen enthalten, die dem Benutzer im Rahmen dieser Rolle gewährt werden. Rollen können an bestimmte Positionen, Abteilungen oder funktionale Aufgaben der Mitarbeiter gebunden sein.

Rollen werden in der Regel aus den spezifischen Befugnissen eines Mitarbeiters in jedem Informationssystem erstellt. Anschließend entstehen aus den Rollen jedes Systems globale Geschäftsrollen. Zum Beispiel wird die Geschäftsrrolle „Kreditmanager“ mehrere spezifische Rollen in den Informationssystemen umfassen, die im Kundenbüro der Bank verwendet werden. Denkbar sind Systeme wie das Hauptautomatisierungssystem der Bank, das Kassensystem, das System für elektronische Dokumentenverwaltung, der Service-Manager und weitere. Geschäftsrollen sind typischerweise an die organisatorische Struktur gebunden – einfacher gesagt, an die verschiedenen Abteilungen des Unternehmens und die darin enthaltenen Positionen. So ergibt sich eine globale Rollenmatrix (ein Beispiel finden Sie in der Tabelle unten).

Es ist wichtig zu betonen, dass es unmöglich ist, ein 100% rollenspezifisches Modell zu erstellen, das allen Mitarbeitern jeder Position in einer kommerziellen Struktur die notwendigen Rechte einräumt. Das ist auch nicht notwendig. Ein rollenspezifisches Modell kann nicht statisch sein, da es von einem sich ständig verändernden Umfeld abhängt. Es wird auch von den Änderungen in der Geschäftstätigkeit des Unternehmens beeinflusst, die wiederum die Organisationsstruktur und die Funktionen verändern. Hinzu kommen unzureichende Ressourcen, die Nichteinhaltung von Stellenbeschreibungen, das Streben nach Gewinn auf Kosten der Sicherheit und viele andere Faktoren. Daher sollte ein rollenspezifisches Modell entwickelt werden, das bis zu 80% der Benutzerbedürfnisse an grundlegenden Rechten bei der Stellenvergabe abdecken kann. Die restlichen 20% können gegebenenfalls später bei Bedarf separat angefordert werden.

Natürlich könnte man fragen: "Gibt es überhaupt keine 100%igen Rollenvorlagen?" Doch, das gibt es, zum Beispiel in gemeinnützigen Organisationen, die nicht häufigen Veränderungen unterworfen sind – etwa in einem Forschungsinstitut. Oder in Organisationen der Verteidigungsindustrie mit hohem Sicherheitsniveau, wo Sicherheit oberste Priorität hat. Es kann auch in kommerziellen Strukturen vorkommen, aber dann meist in einem speziellen Bereich, dessen Arbeitsweise relativ stabil und vorhersehbar ist.

Der größte Vorteil der rollenbasierten Verwaltung ist die Vereinfachung der Berechtigungsvergabe, da die Anzahl der Rollen deutlich geringer ist als die der Benutzer im Informationssystem. Das gilt für jede Branche.

Nehmen wir ein Einzelhandelsunternehmen: Dort arbeiten Tausende von Verkäufern, aber alle haben die gleichen Berechtigungen im System N, und es wird nur eine Rolle erstellt. Kommt ein neuer Verkäufer ins Unternehmen, so wird ihm automatisch die benötigte Rolle im System zugewiesen, die bereits alle erforderlichen Berechtigungen enthält. Ebenso kann man mit einem Klick die Berechtigungen für Tausende von Verkäufern gleichzeitig ändern, zum Beispiel indem man eine neue Option zur Berichtserstellung hinzufügt. Es ist nicht nötig, tausend Operationen durchzuführen, um die neue Berechtigung an jedes Benutzerkonto zu binden – es reicht, diese Option der Rolle hinzuzufügen, und schon haben alle Verkäufer sie gleichzeitig.

Ein weiteres Vorteil des Rollenmanagements ist der Ausschluss der Vergabe inkompatibler Berechtigungen. Das heißt, ein Mitarbeiter, der in einem System eine bestimmte Rolle hat, kann nicht gleichzeitig eine andere Rolle besitzen, deren Berechtigungen mit den Berechtigungen der ersten nicht kombiniert werden dürfen. Ein anschauliches Beispiel ist das Verbot der Kombination von Eingabefunktionen und der Kontrolle von finanziellen Transaktionen.

Alle, die daran interessiert sind, wie das Rollenmanagement für den Zugriff entstanden ist, können
eintauchen und einen historischen Rückblick werfen.
Wenn wir auf die Geschichte zurückblicken, wurde das Thema Zugangskontrolle erstmals in den 70er Jahren des 20. Jahrhunderts von der IT-Community aufgegriffen. Obwohl die Anwendungen damals recht einfach waren, wünschte sich jeder so wie heute eine bequeme Verwaltung des Zugangs zu ihnen. Benutzerrechte zu gewähren, zu ändern und zu kontrollieren – einfach, um leichter nachvollziehen zu können, wer welche Zugriffsrechte hat. Doch zu dieser Zeit gab es keine allgemein geltenden Standards; die ersten Zugangskontrollsysteme wurden entwickelt, und jede Firma basierte auf ihren eigenen Vorstellungen und Regeln.

Heute sind viele verschiedene Modelle der Zugangskontrolle bekannt, aber sie sind nicht über Nacht entstanden. Konzentrieren wir uns auf die Modelle, die einen spürbaren Beitrag zur Entwicklung dieses Bereichs geleistet haben.

Das erste und wahrscheinlich einfachste Modell – Diskretionäre (oder selektive) Zugangskontrolle (DAC – Discretionary Access Control). Dieses Modell beinhaltet die gemeinsame Nutzung von Rechten durch alle Beteiligten des Zugriffsprozesses. Jeder Benutzer erhält Zugang zu bestimmten Objekten oder Operationen. Im Grunde genommen gibt es hier eine Vielzahl von Subjekten, die den Rechten zugeordnet sind, und eine Vielzahl von Objekten. Dieses Modell wurde als zu flexibel und zu komplex für die Wartung anerkannt: Die Zugriffslisten werden im Laufe der Zeit riesig und schwer kontrollierbar.

Das zweite Modell ist Mandatory Access Control (MAC – Mandatstehendes Zugriffsmanagement). Bei diesem Modell erhält jeder Benutzer Zugang zu einem Objekt entsprechend einer genehmigten Zugangsberechtigung für eine bestimmte Datenschutzeinstufung. Dementsprechend müssen die Objekte nach ihrem Datenschutzlevel kategorisiert werden. Im Gegensatz zum ersten flexiblen Modell erwies sich dieses Modell als zu rigide und einschränkend. Seine Anwendung ist nicht gerechtfertigt, wenn das Unternehmen über eine Vielzahl unterschiedlicher Informationsressourcen verfügt: Um den Zugriff auf verschiedene Ressourcen zu differenzieren, müssen viele Kategorien eingeführt werden, die sich nicht überschneiden.

Angesichts der offensichtlichen Unzulänglichkeiten dieser beiden Methoden hat die IT-Community weiterhin an Modellen gearbeitet, die flexibler sind und mehr oder weniger universell unterschiedliche organisatorische Zugriffskontrollpolitiken unterstützen. So entstand das dritte Modell der rollenbasierten Zugriffskontrolle! Dieser Ansatz hat sich als der vielversprechendste erwiesen, da er nicht nur die Authentifizierung des Benutzers, sondern auch seine funktionalen Aufgaben im System erfordert.

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) vorgeschlagen. Damals entstand zum ersten Mal der Begriff RBAC (Rollenbasierte Zugriffskontrolle). Diese Forschungen und die Beschreibungen der grundlegenden Komponenten sowie deren Zusammenhänge bilden die Grundlage für den bis heute geltenden Standard INCITS 359-2012, der von dem Internationalen Komitee für Informationstechnologiestandards (INCITS) genehmigt wurde.

Der Standard definiert eine Rolle als 'eine Funktion 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 zugeordnet ist'. Das Dokument legt die grundlegenden Elemente von RBAC fest – Benutzer, Sitzungen, Rollen, Berechtigungen, Operationen und Objekte sowie deren Beziehungen und Verbindungen.

Der Standard bietet eine minimal notwendige Struktur für die Erstellung eines Rollenmodells – die Zusammenführung von Rechten in Rollen und anschließend die Vergabe von Zugängen an Benutzer über diese Rollen. Die Mechanismen zur Erstellung von Rollen aus Objekten und Operationen werden bezeichnet, und die Hierarchie der Rollen sowie die Vererbung von Befugnissen werden beschrieben. Denn in jedem Unternehmen gibt es Rollen, die elementare Befugnisse bündeln, die für alle Mitarbeiter erforderlich sind. Dazu kann der Zugang zu E-Mails, zu DMS, zum Unternehmensportal u.a. gehören. Diese Befugnisse können in eine gemeinsame Rolle namens 'Mitarbeiter' integriert werden, wodurch es unnötig wird, in jeder der höheren Rollen alle elementaren Rechte immer wieder aufzulisten. Es reicht aus, einfach das Erbe der Rolle 'Mitarbeiter' anzugeben.

Später wurde der Standard um neue Zugriffsattribute ergänzt, die mit der ständig wechselnden Umgebung in Verbindung stehen. Es wurde die Möglichkeit eingeführt, statische und dynamische Einschränkungen zu definieren. Statische Einschränkungen bedeuten, dass Rollen nicht kombiniert werden können (dies bezieht sich auf die Eingabe und Überwachung von Operationen, wie oben erwähnt). Dynamische Einschränkungen können durch variierende Parameter wie Zeit (Arbeits-/Nichtarbeitszeiten oder -tage), Standort (Büro/Zuhause) usw. bestimmt werden.

Es ist erwähnenswert, dass der Zugriff auf Basis von Attributen verwaltet wird (ABAC – Attribute-based access control). Dieser Ansatz beruht auf der Bereitstellung von Zugriff 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 Attribute von Benutzern, Ressourcen und Geräten sowie Zeit oder Standort hinzugefügt werden. Dies ermöglicht es, weniger Rollen zu nutzen, zusätzliche Einschränkungen einzuführen und den Zugriff auf das Minimalnotwendige zu beschränken, wodurch die Sicherheit erhöht wird.

Beispielsweise kann einem Buchhalter der Zugriff auf Konten gewährt werden, wenn er in einer bestimmten Region arbeitet. Das Standort des Spezialisten wird dann mit einem festgelegten Referenzwert verglichen. Alternativ kann der Zugriff auf Konten auch nur gewährt werden, wenn sich der Benutzer von einem im Register der erlaubten Geräte authentifiziert. Eine sinnvolle Ergänzung zum Rollenmodell, jedoch wird sie aufgrund der Notwendigkeit, viele Regeln und Berechtigungstabellen zu erstellen, selten allein verwendet.

Ich möchte ein Beispiel für die Anwendung von ABAC aus meiner "früheren Karriere" geben. In unserer Bank gab es mehrere Filialen. Die Mitarbeiter der Kundenbüros in diesen Filialen führten völlig identische Aufgaben aus, durften jedoch nur in dem Hauptsystem mit den Konten ihrer Region arbeiten. Zunächst begannen wir, separate Rollen für jede Region zu erstellen – und es entstanden eine sehr große Anzahl von Rollen mit sich wiederholenden Funktionalitäten, jedoch mit Zugriff auf verschiedene Konten! Durch die Verwendung des Standortattributs für den Benutzer, das mit einem bestimmten Kontobereich zur Überprüfung verknüpft wurde, konnten wir die Anzahl der Rollen im System erheblich reduzieren. Am Ende blieben nur Rollen für eine Filiale übrig, die auf die entsprechenden Positionen in allen anderen Territorialen Einheiten der Bank übertragen wurden.

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

Schritt 1. Wir erstellen ein funktionales Modell

Der erste Schritt besteht darin, ein funktionales Modell zu erstellen – ein hochrangiges Dokument, das die Funktionen jedes Bereichs und jeder Position detailliert beschreibt. In der Regel stammen die Informationen aus verschiedenen Dokumenten: Stellenbeschreibungen und Regelungen für spezifische Bereiche – Abteilungen, Sekretariate, Abteilungen. Das funktionale Modell muss mit allen interessierten Abteilungen (Geschäft, interne Kontrolle, Sicherheit) abgestimmt und von der Unternehmensleitung genehmigt werden. Wozu dient dieses Dokument? Damit das Rollenmodell darauf Bezug nehmen kann. Wenn Sie beispielsweise ein Rollenmodell auf der Basis bereits vorhandener Rechte der Mitarbeiter erstellen möchten – die aus dem System exportiert und „auf einen Nenner gebracht“ wurden. Dann können Sie bei der Abstimmung der erhaltenen Rollen mit dem Geschäftsinhaber auf den spezifischen Punkt des funktionalen Modells verweisen, auf dessen Grundlage in die Rolle das eine oder andere Recht aufgenommen wird.

Schritt 2: Auditisieren Sie die IT-Systeme und erstellen Sie einen Priorisierungsplan.

Im zweiten Schritt sollte eine Prüfung der IT-Systeme erfolgen, um zu klären, wie der Zugang zu diesen organisiert ist. Zum Beispiel gab es in meinem Finanzunternehmen mehrere Hundert Informationssysteme. In allen Systemen gab es einige Ansätze zum Rollenmanagement, in den meisten – bestimmte Rollen, aber hauptsächlich auf Papier oder im Systemverzeichnis – sie waren längst veraltet, und der Zugang wurde auf Basis tatsächlicher Benutzeranforderungen gewährt. Natürlich ist es einfach unmöglich, ein Rollenmodell sofort in mehreren Hundert Systemen zu erstellen; man muss irgendwo anfangen. Wir haben eine tiefgehende Analyse des Zugangsmanagementprozesses durchgeführt, um den Reifegrad zu bestimmen. Während der Analyse haben wir Kriterien zur Priorisierung der Informationssysteme entwickelt – Kritikalität, Bereitschaft, Pläne zur Stilllegung usw. Anhand dieser 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 Zugangsmanagement zu automatisieren.

Wie lässt sich also die Kritikalität eines Systems bestimmen? Beantworten Sie sich folgende Fragen:

• Steht das System in Verbindung mit den Betriebsabläufen, von denen die Haupttätigkeit des Unternehmens abhängt?
• Wird eine Störung des Systems die Integrität der Unternehmenswerte beeinträchtigen?
• Was ist die maximal zulässige Ausfallzeit des Systems, nach deren Erreichen eine Wiederherstellung der Tätigkeit nach einer Unterbrechung nicht mehr möglich ist?
• Kann die Verletzung der Informationsintegrität im System zu irreversiblen Konsequenzen führen, sowohl finanzieller als auch reputationsbezogener Art?
• Kritikalität bei Betrugsgefahr. Vorhandensein von Funktionen, bei denen ohne ausreichende Kontrolle interne/externe betrügerische Handlungen möglich sind;
• Welche gesetzlichen Anforderungen sowie internen Regeln und Verfahren gelten für diese Systeme? Wird es Bußgelder von den Regulierungsbehörden bei Nichteinhaltung geben?

In unserem Finanzunternehmen haben wir ein Audit durchgeführt. Die Geschäftsführung hat das Verfahren zur Überprüfung der Zugriffsrechte eingeführt, um die bestehenden Benutzer und deren Berechtigungen zunächst in den informationssystemen zu überprüfen, die auf der Prioritätenliste ganz oben stehen. Die Verantwortung für diesen Prozess wurde der Sicherheitsabteilung übertragen. Um jedoch ein umfassendes Bild der Zugriffsrechte im Unternehmen zu erhalten, mussten auch die IT- und Business-Abteilungen in den Prozess eingebunden werden. Hier begannen die Diskussionen, Missverständnisse und manchmal sogar Sabotage: Niemand möchte von seinen aktuellen Aufgaben abgelenkt werden und sich auf vermeintlich unverständliche Aktivitäten einlassen.

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



Ein Bereich der Prüfung ist die Bestimmung der Parameter für den logischen und physischen Zugang zu Informationssystemen. Die gewonnenen Daten dienten uns als Grundlage für die weitere Verwendung beim Aufbau des Rollenmodells. Durch diese Prüfung erhielten wir ein Verzeichnis der IT-Systeme, in dem ihre technischen Parameter definiert und beschrieben wurden. Darüber hinaus wurde für jedes System ein Eigentümer aus dem Geschäftsbereich bestimmt, dessen Interessen es diente: er war verantwortlich für die Geschäftsprozesse, die dieses System unterstützte. Zudem wurde ein IT-Service-Manager ernannt, der für die technische Umsetzung der geschäftlichen Anforderungen in dem spezifischen Informationssystem zuständig war. Die kritischsten Systeme für das Unternehmen sowie deren technische Parameter, Betriebs- und Stilllegungsfristen und weitere relevante Informationen wurden festgehalten. Diese Parameter erwiesen sich als äußerst hilfreich bei der Vorbereitung des Aufbaus des Rollenmodells.

Schritt 3: Methodologie erstellen

Der Schlüssel zum Erfolg liegt in der richtigen Wahl der Methode. Daher benötigen wir sowohl für die Erstellung eines Rollenmodells als auch für die Durchführung eines Audits eine Methodologie, in der wir die Interaktionen zwischen den Abteilungen beschreiben, Verantwortlichkeiten in den Unternehmensrichtlinien festlegen usw.
Zunächst sollten wir alle vorhandenen Dokumente untersuchen, die den Zugang und die Rechte regeln. Idealerweise sollten die Prozesse auf mehreren Ebenen dokumentiert sein:

• allgemeine Unternehmensanforderungen;
• spezifische Anforderungen an den Bereich Informationssicherheit (abhängig von den Tätigkeitsfeldern des Unternehmens);
• Anforderungen an technologische Prozesse (Anleitungen, Zugriffsmatrizen, methodische Hinweise, Anforderungen an Konfigurationen).

In unserem Finanzunternehmen haben wir viele veraltete Dokumente festgestellt – wir mussten diese an die neuen Prozesse anpassen, die wir implementieren.

Auf Anordnung der Geschäftsführung wurde eine Arbeitsgruppe eingerichtet, die Vertreter aus den Bereichen Sicherheit, IT, Unternehmensleitung und interner Kontrolle umfasst. In der Anordnung wurden die Ziele der Gruppe, die Richtung der Aktivitäten, die Dauer der Existenz und die Verantwortlichen aus jeder Seite festgelegt. Zudem haben wir eine Methode zur Durchführung von Audits und die Vorgehensweise zur Erstellung eines Rollenmodells entwickelt, die von allen verantwortlichen Vertretern der Bereiche abgestimmt und von der Unternehmensleitung genehmigt wurde.

Dokumente, die den Ablauf der Arbeiten, Fristen, Verantwortlichkeiten usw. beschreiben, sind eine Garantie dafür, dass auf dem Weg zum angestrebten Ziel, das anfangs nicht jedem klar ist, niemand Fragen aufwirft wie 'Warum machen wir das? Was bringt uns das?' und dass es keine Möglichkeit gibt, den Prozess zu umgehen oder zu verlangsamen.

Schritt 4. Wir dokumentieren die Parameter des bestehenden Zugriffsmanagementmodells.

Wir erstellen das sogenannte "Systempass" im Bereich des Zugriffsmanagements. Im Wesentlichen handelt es sich um einen Fragebogen zu einem bestimmten Informationssystem, in dem alle Zugriffsmanagement-Algorithmen dokumentiert sind. Unternehmen, die bereits Lösungen der Kategorie IdM implementiert haben, sind mit solch einem Fragebogen vertraut, da dies der Ausgangspunkt für die Systemanalyse ist.

Einige Parameter über das System und die Eigentümer wurden aus dem IT-Register in den Fragebogen übernommen (siehe Schritt 2, Audit), aber es wurden auch neue hinzugefügt:

• Wie das Management der Benutzerkonten erfolgt (direkt in der Datenbank oder über Programmierschnittstellen);
• Wie Benutzer sich im System anmelden (mit einem separaten Konto oder unter Verwendung eines AD-, LDAP- oder anderen Kontos);
• Welche Zugriffslevels im System verwendet werden (Anwendungsebene, Systemebene, Nutzung von netzwerkbasierten Dateiquellen durch das System);
• Beschreibung und Parameter Server, auf denen das System läuft;
• Welche Operationsarten im Benutzerkontenmanagement unterstützt werden (Sperrung, Umbenennung usw.);
• Nach welchen Algorithmen oder Regeln die Benutzer-ID im System generiert wird;
• Welches Attribut kann genutzt werden, um eine Verbindung zu der Mitarbeiterdatensatz im Personalsystem herzustellen (z. B. Name, Personalnummer oder andere)?
• Alle möglichen Attribute des Benutzerkontos und die Regeln für deren Ausfüllung.
• Welche Zugriffsrechte gibt es im System (Rollen, Gruppen, atomare Rechte usw., gibt es verschachtelte oder hierarchische Rechte)?
• Mechanismen zur Trennung von Zugriffsrechten (nach Positionen, Abteilungen, Funktionen usw.).
• Gibt es im System Regeln zur Trennung der Rechte (SOD – Segregation of Duties) und wie funktionieren diese?
• Wie werden im System Ereignisse wie Abwesenheit, Versetzung, Kündigung, Aktualisierung von Mitarbeiterdaten usw. verarbeitet?

Diese Liste kann mit Details zu verschiedenen Parametern und anderen Objekten, die im Prozess des Zugangsmanagements verwendet werden, fortgesetzt werden.

Schritt 5. Erstellen Sie eine geschäftsorientierte Beschreibung der Befugnisse.

Ein weiteres Dokument, das wir für die Erstellung des Rollenmodells benötigen, ist ein Verzeichnis aller möglichen Berechtigungen (Rechte), die Benutzern im Informationssystem bereitgestellt werden können, mit einer detaillierten Beschreibung der geschäftlichen Funktion dahinter. Oft sind die Berechtigungen im System durch bestimmte Bezeichnungen verschlüsselt, die aus Buchstaben und Zahlen bestehen, und die Mitarbeiter im Geschäft können nicht nachvollziehen, was sich hinter diesen Symbolen verbirgt. In solchen Fällen wenden sie sich an den IT-Service, wo ebenfalls keine Antworten auf Fragen zu selten verwendeten Rechten gegeben werden können. Daher müssen zusätzliche Tests durchgeführt werden.

Es ist von Vorteil, wenn eine Geschäftsbeschreibung bereits vorhanden ist oder sogar eine Zusammenfassung dieser Rechte in Gruppen und Rollen existiert. Für einige Anwendungen gilt es als Best Practice, ein solches Verzeichnis schon in der Entwicklungsphase zu erstellen. Doch das kommt nur selten vor, weshalb wir erneut zur IT-Abteilung gehen müssen, um Informationen über alle möglichen Rechte zu sammeln und diese zu beschreiben. Unser Verzeichnis wird schließlich Folgendes enthalten:

• Bezeichnung der Berechtigung, einschließlich des Objekts, auf das das Zugriffsrecht angewendet wird;
• eine Handlung, die mit einem Objekt zulässig ist (z. B. Ansicht, Änderung und ähnliche Möglichkeiten, eventuell mit Einschränkungen, beispielsweise nach geografischen oder Kundenkategorien);
• Berechtigungscode (Code und Name der Funktion / Anfrage im System, die mit dieser Berechtigung ausgeführt werden kann);
• Berechtigungsbeschreibung (detaillierte Beschreibung der Aktionen im Informationssystem, die mit der Berechtigung ausgeführt werden, und deren Auswirkungen auf den Prozess);
• Status der Berechtigung: „Aktiv“ (wenn die Berechtigung mindestens einem Benutzer zugewiesen ist) oder „Inaktiv“ (wenn die Berechtigung nicht genutzt wird).

Schritt 6: Daten über Benutzer und Rechte aus den Systemen exportieren und mit der Personalquelle abgleichen.

In der finalen Phase der Vorbereitung müssen die Daten aus den Informationssystemen über alle Benutzer und die ihnen derzeit zugeordneten Berechtigungen exportiert werden. Hier sind zwei Szenarien möglich. Erstens: Die Sicherheitsabteilung hat direkten Zugang zu dem System und verfügt über die Mittel, die entsprechenden Berichte zu exportieren, was selten der Fall ist, aber sehr praktisch. Zweitens: Wir senden eine Anfrage an die IT, um die Berichte im gewünschten Format zu erhalten. Die Praxis zeigt, dass es oft nicht gelingt, sich beim ersten Mal mit der IT zu einigen und die benötigten Daten zu erhalten. Man muss mehrere Versuche unternehmen, bis die Informationen in der benötigten Form und im richtigen Format vorliegen.

Welche Daten müssen exportiert werden:

• Kontoname
• Vollständiger Name des Mitarbeitern, dem es zugeordnet ist
• Status (aktiv oder blockiert)
• Erstellungsdatum des Kontos
• Datum der letzten Nutzung
• Liste der verfügbaren Berechtigungen/Gruppen/Rollen

So, wir haben die Exporte aus dem System mit allen Benutzern und allen Berechtigungen, die ihnen gewährt wurden, erhalten. Und sofort haben wir alle blockierten Konten beiseitegelegt, da die Arbeit am Rollenmodell nur für aktive Benutzer erfolgen wird.

Wenn in Ihrem Unternehmen keine automatisierten Mechanismen zur Sperrung von Zugängen für entlassene Mitarbeiter vorhanden sind (was häufig vorkommt) oder wenn es eine fragmentierte Automatisierung gibt, die nicht immer korrekt funktioniert, müssen alle "toten Seelen" identifiziert werden. Dies bezieht sich auf die Konten ehemaliger Mitarbeiter, deren Zugriffsrechte aus irgendeinem Grund nicht blockiert wurden – diese müssen gesperrt werden. Dazu vergleichen wir die exportierten Daten mit der Personalquelle. Auch die Personalabteilung muss zuvor die entsprechenden Daten bereitstellen.

Es ist notwendig, die Konten separat zu berücksichtigen, deren Besitzer nicht in der Personalakte zu finden sind, die niemandem zugeordnet sind – das heißt, herrenlos. Für diese Liste benötigen wir das Datum der letzten Nutzung: Wenn es recht aktuell ist, müssen wir dennoch nach den Besitzern suchen. Dazu können Konten von externen Auftragnehmern oder Dienstkonten gehören, die keinem zugeordnet sind, aber mit bestimmten Prozessen verbunden sind. Um die Zugehörigkeit der Konten zu klären, kann ein Rundschreiben an alle Abteilungen gesendet werden, in dem um Rückmeldung gebeten wird. Sobald die Besitzer identifiziert sind, tragen wir ihre Daten in das System ein: auf diese Weise sind alle aktiven Konten erkannt, während die anderen gesperrt werden.

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

Autor: Lyudmila Sevastyanova, Marketing-Managerin bei Solar inRights

Quelle: habr.com