{"id":87793,"date":"2020-07-10T13:41:57","date_gmt":"2020-07-10T11:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya"},"modified":"2020-07-10T13:41:57","modified_gmt":"2020-07-10T11:41:57","slug":"stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Wir bauen ein Rollenmodell f\u00fcr die Zugriffssteuerung auf. Teil eins, vorbereitend.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zurzeit arbeite ich in einem Softwareanbieter-Unternehmen, konkret im Bereich der Zugangsverwaltung. Mein fr\u00fcherer Berufshorizont stammt von der Kundenseite \u2013 einer gro\u00dfen Finanzorganisation. Damals konnte unsere Gruppe f\u00fcr Zugangssteuerung im IT-Sicherheitsdepartement nicht mit gro\u00dfen 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.
\n\"Wir
\nIndem ich meine schmerzhaften Erfahrungen von der Kundenseite mit dem Wissen und den Kompetenzen des Anbieters kombiniere, m\u00f6chte ich mit Ihnen im Grunde eine Schritt-f\u00fcr-Schritt-Anleitung teilen: wie man in einem gro\u00dfen Unternehmen ein Rollenmodell f\u00fcr die Zugangsverwaltung erstellt und welchen Nutzen man daraus zieht. Meine Anleitung besteht aus zwei Teilen: der erste \u2013 Vorbereitungen f\u00fcr den Aufbau des Modells, der zweite \u2013 das eigentliche Bauen. Vor Ihnen liegt der erste Teil, die Vorbereitung.
\n<\/a><\/noindex>
\nN.B.<\/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\u00fcr ein Zugangsmanagement-\u00d6kosystem. Bereiten Sie sich also auf ein langfristiges Spiel vor.
\n<\/i>
\nZun\u00e4chst lassen Sie uns kl\u00e4ren \u2013 was ist Zugangsverwaltung auf Rollenbasis? Angenommen, Sie haben eine gro\u00dfe 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 \u2013 genau so viele Verbindungen m\u00fcssen Sie zun\u00e4chst aufbauen und dann \u00fcberwachen. Ist es realistisch, dies manuell zu tun? Nat\u00fcrlich nicht \u2013 um diese Aufgabe zu l\u00f6sen, wurden Rollen eingef\u00fchrt.<\/p>\n

Eine Rolle ist eine Sammlung von Berechtigungen, die ein Benutzer oder eine Benutzergruppe zur Erledigung bestimmter Arbeitsaufgaben ben\u00f6tigt. 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\u00e4hrt werden. Rollen k\u00f6nnen an bestimmte Positionen, Abteilungen oder funktionale Aufgaben der Mitarbeiter gebunden sein.<\/p>\n

\"Wir
\n
\nRollen werden normalerweise aus einzelnen Befugnissen eines Mitarbeiters in jedem Informationssystem erstellt. Anschlie\u00dfend werden aus den Rollen jedes Systems globale Gesch\u00e4ftsrollen gebildet. Zum Beispiel umfasst die Gesch\u00e4ftsrolle \"Kreditmanager\" mehrere einzelne Rollen in Informationssystemen, die im Kundenb\u00fcro der Bank verwendet werden. Sagen wir, in Systemen wie dem Hauptautomatisierungssystem der Bank, dem Kassamodul, dem System f\u00fcr elektronische Dokumentenverarbeitung, dem Service-Manager und anderen. Gesch\u00e4ftsrollen sind in der Regel an die organisatorische Struktur gebunden \u2013 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).<\/p>\n

\"Wir
\n
\nEs ist zu beachten, dass es einfach unm\u00f6glich ist, ein 100 % Rollenmodell zu erstellen, das alle erforderlichen Befugnisse f\u00fcr jede Position in der kommerziellen Struktur sicherstellt. Und das ist auch nicht n\u00f6tig. Denn ein Rollenmodell kann nicht statisch sein, da es von einem sich st\u00e4ndig \u00e4ndernden Umfeld abh\u00e4ngt. Und von den Ver\u00e4nderungen in den Gesch\u00e4ftsaktivit\u00e4ten des Unternehmens, die entsprechend die Organisationsstruktur und die Funktionalit\u00e4t 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\u00fcrfnisse hinsichtlich der notwendigen Grundrechte bei der Ernennung auf eine Position abdeckt. Die verbleibenden 20 % k\u00f6nnen bei Bedarf sp\u00e4ter durch separate Antr\u00e4ge angefordert werden.<\/p>\n

Nat\u00fcrlich k\u00f6nnen Sie fragen: \u201eGibt es \u00fcberhaupt 100 % Rollenmodelle?\u201c Nun, warum nicht? Solche Modelle finden sich beispielsweise in Non-Profit-Organisationen, die nicht h\u00e4ufigen Ver\u00e4nderungen unterworfen sind \u2013 in einem Forschungsinstitut. Oder in Unternehmen der R\u00fcstungsindustrie 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.<\/p>\n

Der gr\u00f6\u00dfte 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.<\/p>\n

Nehmen wir ein Einzelhandelsunternehmen: Dort arbeiten Tausende von Verk\u00e4ufern, aber die Berechtigungen im System N sind f\u00fcr sie identisch, und es wird nur eine Rolle f\u00fcr sie erstellt. Ein neuer Verk\u00e4ufer kommt in das Unternehmen \u2013 ihm wird automatisch die erforderliche Rolle im System zugewiesen, in dem bereits alle notwendigen Berechtigungen vorhanden sind. Auch mit einem Klick k\u00f6nnen die Berechtigungen f\u00fcr Tausende von Verk\u00e4ufern gleichzeitig ge\u00e4ndert werden, zum Beispiel, indem eine neue Option zur Berichtserstellung hinzugef\u00fcgt wird. Es ist nicht n\u00f6tig, Tausende von Operationen durchzuf\u00fchren, um die neue Berechtigung an jedes Benutzerkonto zu binden \u2013 es reicht aus, diese Option in die Rolle aufzunehmen, und sie wird gleichzeitig f\u00fcr alle Verk\u00e4ufer verf\u00fcgbar sein.<\/p>\n

Ein weiterer Vorteil des rollenspezifischen Managements ist der Ausschluss der Vergabe inkompatibler Berechtigungen. Das hei\u00dft, 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\u00fcr ist das Verbot, Eingabe- und Kontrollfunktionen bei finanziellen Transaktionen zu kombinieren.<\/p>\n

Alle, die interessiert sind, wie das rollenbasierte Zugriffsmanagement entstanden ist, k\u00f6nnen
\n in die Geschichte eintauchen<\/b>
\n Wenn wir auf die Geschichte zur\u00fcckblicken, dann begann die IT-Community bereits in den 70er Jahren des 20. Jahrhunderts \u00fcber Methoden des Zugriffsmanagements nachzudenken. Zwar waren die Anwendungen damals recht einfach, doch wie auch heute wollten alle bequem den Zugriff darauf verwalten. Berechtigungen f\u00fcr Benutzer zu erteilen, zu \u00e4ndern und zu kontrollieren \u2013 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.<\/p>\n

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\u00fcrbaren Beitrag zur Entwicklung dieses Bereichs geleistet haben.<\/p>\n

Das erste und wahrscheinlich das einfachste Modell ist das diskretion\u00e4re (wahlweise) Zugriffsmanagement<\/b> (DAC \u2013 Discretionary Access Control). Dieses Modell erm\u00f6glicht es allen Beteiligten im Zugriffsprozess, gemeinsame Rechte zu nutzen. Jeder Benutzer erh\u00e4lt 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\u00fcr die Verwaltung angesehen: Die Zugriffslisten werden im Laufe der Zeit riesig und schwer zu kontrollieren.<\/p>\n

Das zweite Modell ist Die mandatierte Zugangskontrolle (MAC \u2013 Mandatory Access Control)<\/b>. In diesem Modell erh\u00e4lt jeder Benutzer Zugriff auf ein Objekt basierend auf der formal erteilten Erlaubnis f\u00fcr ein bestimmtes Datenschutzniveau. Dementsprechend m\u00fcssen die Objekte nach ihrem Datenschutzniveau kategorisiert werden. Im Gegensatz zum ersten flexiblen Modell hat sich dieses als zu strikt und einschr\u00e4nkend erwiesen. Ihre Anwendung rechtfertigt sich nicht, wenn in einem Unternehmen viele verschiedene Informationsressourcen vorhanden sind: Um den Zugriff auf unterschiedliche Ressourcen zu regeln, m\u00fcssen zahlreiche Kategorien eingef\u00fchrt werden, die sich nicht \u00fcberschneiden.<\/p>\n

Angesichts der offensichtlichen Unzul\u00e4nglichkeiten dieser beiden Methoden hat die IT-Community weiterhin Modelle entwickelt, die flexibler und mehr oder weniger universell zur Unterst\u00fctzung verschiedener Arten von organisatorischen Zugriffsrichtlinien sind. Und so entstand das dritte Modell der zugriffsbasierenden Kontrolle auf Rollenbasis!<\/b> Dieser Ansatz hat sich als die vielversprechendste L\u00f6sung erwiesen, da er nicht nur die Authentifizierung der Identit\u00e4t des Benutzers erfordert, sondern auch seine Arbeitsfunktionen in den Systemen.<\/p>\n

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\u00fchrt. <\/b>Diese Forschungen und die Beschreibungen der grundlegenden Komponenten sowie deren Zusammenh\u00e4nge bilden die Grundlage des bis heute g\u00fcltigen Standards INCITS 359-2012, der vom International Committee for Information Technology Standards (INCITS) genehmigt wurde.<\/p>\n

Der Standard definiert eine Rolle als \u201eeine 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\u201c. Das Dokument legt die grundlegenden Elemente von RBAC fest \u2013 Benutzer, Sitzungen, Rollen, Berechtigungen, Operationen und Objekte sowie die Beziehungen und Interaktionen zwischen ihnen.<\/p>\n

Der Standard bietet eine minimal notwendige Struktur zur Erstellung eines Rollenmodells \u2013 die Zusammenfassung von Rechten in Rollen und dann die Gew\u00e4hrung von Zugang zu Benutzern \u00fcber 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\u00fcndeln, die allen Mitarbeitern des Unternehmens notwendig sind. Dazu kann der Zugang zu E-Mails, zu einem Dokumentenmanagementsystem, zum Unternehmensportal usw. geh\u00f6ren. Diese Befugnisse k\u00f6nnen in eine gemeinsame Rolle namens \u201eMitarbeiter\u201c zusammengefasst werden, sodass nicht in jeder h\u00f6heren Rolle alle elementaren Rechte immer wieder aufgez\u00e4hlt werden m\u00fcssen. Es reicht aus, das Vererbungssymbol der Rolle \u201eMitarbeiter\u201c anzugeben.<\/p>\n

\"Wir
\n
\nSp\u00e4ter wurde der Standard um neue Zugriffsattribute erg\u00e4nzt, die mit der sich st\u00e4ndig ver\u00e4ndernden Umgebung zusammenh\u00e4ngen. Es wurde die M\u00f6glichkeit hinzugef\u00fcgt, statische und dynamische Einschr\u00e4nkungen einzuf\u00fchren. Statische beziehen sich auf die Unm\u00f6glichkeit, Rollen zu kombinieren (jene Eingabe und Kontrolle von Operationen, die oben erw\u00e4hnt wurde). Dynamische Einschr\u00e4nkungen k\u00f6nnen durch variable Parameter definiert werden, z. B. Zeit (Arbeits-\/Nichtarbeitszeiten oder -tage), Standort (B\u00fcro\/Zuhause) usw.<\/p>\n

Es ist erw\u00e4hnenswert, dass die attributbasierte Zugriffskontrolle (ABAC \u2013 Attribute-based access control).<\/b> Der Ansatz basiert auf der Bereitstellung von Zugang durch Regeln zur gemeinsamen Nutzung von Attributen. Dieses Modell kann unabh\u00e4ngig verwendet werden, erg\u00e4nzt jedoch h\u00e4ufig aktiv das klassische Rollenmodell: Zu einer bestimmten Rolle k\u00f6nnen Benutzer-, Ressourcen- und Ger\u00e4tetattribute sowie Zeit- oder Standortattribute hinzugef\u00fcgt werden. Dies erm\u00f6glicht die Verwendung weniger Rollen, die Einf\u00fchrung zus\u00e4tzlicher Einschr\u00e4nkungen und schafft minimal ausreichenden Zugang, was somit die Sicherheit erh\u00f6ht.<\/p>\n

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\u00e4hrt werden, wenn sich der Benutzer von einem registrierten Ger\u00e4t aus anmeldet. Eine gute Erg\u00e4nzung zum Rollenmodell, wird jedoch selten allein verwendet, da es notwendig ist, viele Regeln und Berechtigungstabellen zu erstellen.<\/p>\n

Ich gebe ein Beispiel f\u00fcr die Anwendung von ABAC aus meinem 'fr\u00fcheren Leben'. In unserer Bank gab es mehrere Filialen. Die Mitarbeiter der Kundenb\u00fcros in diesen Filialen f\u00fchrten absolut identische Vorg\u00e4nge aus, durften jedoch nur in der Hauptsystem mit Konten ihrer Region arbeiten. Zuerst begannen wir, separate Rollen f\u00fcr jede Region zu erstellen \u2013 und es entstanden sehr viele Rollen mit sich wiederholender Funktionalit\u00e4t, 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 \u00dcberpr\u00fcfung verkn\u00fcpften. Infolgedessen blieben nur Rollen f\u00fcr eine Filiale \u00fcbrig, die auf die entsprechenden Positionen in allen anderen territorialen Einheiten der Bank \u00fcbertragen wurden.<\/p>\n

Und jetzt sprechen wir \u00fcber die notwendigen Vorbereitungsschritte, ohne die es einfach unm\u00f6glich ist, ein funktionierendes Rollenmodell zu erstellen.<\/p>\n

Schritt 1. Wir erstellen ein funktionales Modell<\/h2>\n

\nEs ist ratsam, mit der Erstellung eines funktionalen Modells zu beginnen \u2013 einem \u00fcbergeordneten 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\u00fcr einzelne Abteilungen \u2013 wie B\u00fcros, Verwaltungseinheiten und Abteilungen. Das funktionale Modell muss mit allen betroffenen Abteilungen (Gesch\u00e4ft, interne Kontrolle, Sicherheit) abgestimmt und von der Unternehmensleitung genehmigt werden. Warum ist dieses Dokument n\u00f6tig? Damit das Rollenmodell darauf Bezug nehmen kann. Wenn Sie beispielsweise ein Rollenmodell basierend auf bereits bestehenden Rechten der Mitarbeiter \u2013 die aus dem System exportiert und \u201eauf einen gemeinsamen Nenner gebracht\u201c wurden \u2013 erstellen m\u00f6chten, k\u00f6nnen Sie bei der Abstimmung der erhaltenen Rollen mit dem Gesch\u00e4ftsbesitzer des Systems auf einen konkreten Punkt des funktionalen Modells verweisen, der die Aufnahme bestimmter Rechte in die Rolle begr\u00fcndet.<\/p>\n

Schritt 2. Auditing der IT-Systeme und Erstellung eines Priorisierungsplans<\/h2>\n

\nIn der zweiten Phase sollte ein Audit der IT-Systeme durchgef\u00fchrt 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\u00e4tze des rollenbasierten Zugriffsmanagements, in den meisten F\u00e4llen jedoch nur auf Papier oder in den Systemverzeichnissen \u2013 diese waren l\u00e4ngst veraltet, und der Zugang wurde basierend auf tats\u00e4chlichen Benutzeranfragen gew\u00e4hrt. Es ist selbstverst\u00e4ndlich, dass es unm\u00f6glich ist, ein Rollenmodell gleichzeitig in mehreren hundert Systemen zu erstellen, man muss irgendwo anfangen. Wir haben eine eingehende Analyse des Zugriffsmanagementprozesses durchgef\u00fchrt, um dessen Reifegrad zu bestimmen. Im Zuge der Analyse haben wir Kriterien f\u00fcr die Priorisierung der Informationssysteme entwickelt \u2013 Kritikalit\u00e4t, Bereitschaft, Pl\u00e4ne f\u00fcr die Au\u00dferbetriebnahme usw. Mit diesen Kriterien haben wir die Reihenfolge f\u00fcr die Entwicklung\/Aktualisierung der Rollenmodelle f\u00fcr diese Systeme festgelegt. Anschlie\u00dfend haben wir die Rollenmodelle in den Integrationsplan mit der Identity-Management-L\u00f6sung aufgenommen, um das Zugriffsmanagement zu automatisieren.<\/p>\n

Wie k\u00f6nnen Sie also die Kritikalit\u00e4t eines Systems bestimmen? Beantworten Sie sich folgende Fragen:<\/p>\n