{"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 das Zugangsmanagement. Teil Eins, Vorbereitung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Derzeit arbeite ich bei einem Softwareanbieter, insbesondere im Bereich von Zugangsmanagementl\u00f6sungen. Mein Wissen stamme aus der Zeit auf der Nachfrageseite \u2013 einer gro\u00dfen Finanzorganisation. Damals konnte unsere Gruppe im Bereich Zugangskontrolle im IT-Sicherheitsdepartment nicht mit gro\u00dfen Kompetenzen im Identity Management (IdM) aufwarten. Wir mussten viel lernen und einen steinigen Weg gehen, um in der Firma ein funktionierendes Managementsystem f\u00fcr Benutzerrechte in Informationssystemen aufzubauen.
\n\"Wir
\nIndem ich meine leidenschaftlich gesammelten Erfahrungen auf der Nachfrageseite mit den Kenntnissen und Kompetenzen des Anbieters kombiniere, m\u00f6chte ich Ihnen eine Schritt-f\u00fcr-Schritt-Anleitung geben: Wie man in einem gro\u00dfen Unternehmen ein Rollenmodell f\u00fcr 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<\/a><\/noindex>
\nN.B.<\/b> Der Aufbau eines Rollenmodells ist leider kein Endergebnis, sondern ein Prozess. Genauer gesagt, es ist Teil des Prozesses zur Schaffung eines Zugangsmanagement-\u00d6kosystems in der Firma. Bereiten Sie sich also darauf vor, langfristig zu denken.
\n<\/i>
\nLassen Sie uns zun\u00e4chst kl\u00e4ren, was rollenbasiertes Zugriffsmanagement ist. Stellen Sie sich vor, Sie betreiben eine gro\u00dfe Bank mit Zehntausenden oder sogar Hunderttausenden von Mitarbeitern (Subjekten), die jeweils \u00fcber Dutzende von Zugriffsrechten in Hunderten interner Informationssysteme (Objekten) verf\u00fcgen. Multiplizieren Sie nun die Anzahl der Objekte mit der Anzahl der Subjekte \u2013 genau so viele Beziehungen m\u00fcssen Sie zun\u00e4chst aufbauen und sp\u00e4ter \u00fcberwachen. Ist es realistisch, dies manuell zu verwalten? Nat\u00fcrlich nicht \u2013 genau daf\u00fcr wurden Rollen entwickelt.<\/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 einer Vielzahl von Berechtigungen enthalten, die dem Benutzer im Rahmen 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 in der Regel aus den spezifischen Befugnissen eines Mitarbeiters in jedem Informationssystem erstellt. Anschlie\u00dfend entstehen aus den Rollen jedes Systems globale Gesch\u00e4ftsrollen. Zum Beispiel wird die Gesch\u00e4ftsrrolle \u201eKreditmanager\u201c mehrere spezifische Rollen in den Informationssystemen umfassen, die im Kundenb\u00fcro der Bank verwendet werden. Denkbar sind Systeme wie das Hauptautomatisierungssystem der Bank, das Kassensystem, das System f\u00fcr elektronische Dokumentenverwaltung, der Service-Manager und weitere. Gesch\u00e4ftsrollen sind typischerweise an die organisatorische Struktur gebunden \u2013 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).<\/p>\n

\"Wir
\n
\nEs ist wichtig zu betonen, dass es unm\u00f6glich ist, ein 100% rollenspezifisches Modell zu erstellen, das allen Mitarbeitern jeder Position in einer kommerziellen Struktur die notwendigen Rechte einr\u00e4umt. Das ist auch nicht notwendig. Ein rollenspezifisches Modell kann nicht statisch sein, da es von einem sich st\u00e4ndig ver\u00e4ndernden Umfeld abh\u00e4ngt. Es wird auch von den \u00c4nderungen in der Gesch\u00e4ftst\u00e4tigkeit des Unternehmens beeinflusst, die wiederum die Organisationsstruktur und die Funktionen ver\u00e4ndern. 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\u00fcrfnisse an grundlegenden Rechten bei der Stellenvergabe abdecken kann. Die restlichen 20% k\u00f6nnen gegebenenfalls sp\u00e4ter bei Bedarf separat angefordert werden.<\/p>\n

Nat\u00fcrlich k\u00f6nnte man fragen: \"Gibt es \u00fcberhaupt keine 100%igen Rollenvorlagen?\" Doch, das gibt es, zum Beispiel in gemeinn\u00fctzigen Organisationen, die nicht h\u00e4ufigen Ver\u00e4nderungen unterworfen sind \u2013 etwa in einem Forschungsinstitut. Oder in Organisationen der Verteidigungsindustrie mit hohem Sicherheitsniveau, wo Sicherheit oberste Priorit\u00e4t hat. Es kann auch in kommerziellen Strukturen vorkommen, aber dann meist in einem speziellen Bereich, dessen Arbeitsweise relativ stabil und vorhersehbar ist.<\/p>\n

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

Nehmen wir ein Einzelhandelsunternehmen: Dort arbeiten Tausende von Verk\u00e4ufern, aber alle haben die gleichen Berechtigungen im System N, und es wird nur eine Rolle erstellt. Kommt ein neuer Verk\u00e4ufer ins Unternehmen, so wird ihm automatisch die ben\u00f6tigte Rolle im System zugewiesen, die bereits alle erforderlichen Berechtigungen enth\u00e4lt. Ebenso kann man mit einem Klick die Berechtigungen f\u00fcr Tausende von Verk\u00e4ufern gleichzeitig \u00e4ndern, zum Beispiel indem man eine neue Option zur Berichtserstellung hinzuf\u00fcgt. Es ist nicht n\u00f6tig, tausend Operationen durchzuf\u00fchren, um die neue Berechtigung an jedes Benutzerkonto zu binden \u2013 es reicht, diese Option der Rolle hinzuzuf\u00fcgen, und schon haben alle Verk\u00e4ufer sie gleichzeitig.<\/p>\n

Ein weiteres Vorteil des Rollenmanagements ist der Ausschluss der Vergabe inkompatibler Berechtigungen. Das hei\u00dft, 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\u00fcrfen. Ein anschauliches Beispiel ist das Verbot der Kombination von Eingabefunktionen und der Kontrolle von finanziellen Transaktionen.<\/p>\n

Alle, die daran interessiert sind, wie das Rollenmanagement f\u00fcr den Zugriff entstanden ist, k\u00f6nnen
\n eintauchen und einen historischen R\u00fcckblick werfen.<\/b>
\n Wenn wir auf die Geschichte zur\u00fcckblicken, 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\u00fcnschte sich jeder so wie heute eine bequeme Verwaltung des Zugangs zu ihnen. Benutzerrechte zu gew\u00e4hren, zu \u00e4ndern und zu kontrollieren \u2013 einfach, um leichter nachvollziehen zu k\u00f6nnen, 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.<\/p>\n

Heute sind viele verschiedene Modelle der Zugangskontrolle bekannt, aber sie sind nicht \u00fcber Nacht entstanden. Konzentrieren wir uns auf die Modelle, die einen sp\u00fcrbaren Beitrag zur Entwicklung dieses Bereichs geleistet haben.<\/p>\n

Das erste und wahrscheinlich einfachste Modell \u2013 Diskretion\u00e4re (oder selektive) Zugangskontrolle<\/b> (DAC \u2013 Discretionary Access Control). Dieses Modell beinhaltet die gemeinsame Nutzung von Rechten durch alle Beteiligten des Zugriffsprozesses. Jeder Benutzer erh\u00e4lt 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\u00fcr die Wartung anerkannt: Die Zugriffslisten werden im Laufe der Zeit riesig und schwer kontrollierbar.<\/p>\n

Das zweite Modell ist Mandatory Access Control (MAC \u2013 Mandatstehendes Zugriffsmanagement)<\/b>. Bei diesem Modell erh\u00e4lt jeder Benutzer Zugang zu einem Objekt entsprechend einer genehmigten Zugangsberechtigung f\u00fcr eine bestimmte Datenschutzeinstufung. Dementsprechend m\u00fcssen die Objekte nach ihrem Datenschutzlevel kategorisiert werden. Im Gegensatz zum ersten flexiblen Modell erwies sich dieses Modell als zu rigide und einschr\u00e4nkend. Seine Anwendung ist nicht gerechtfertigt, wenn das Unternehmen \u00fcber eine Vielzahl unterschiedlicher Informationsressourcen verf\u00fcgt: Um den Zugriff auf verschiedene Ressourcen zu differenzieren, m\u00fcssen viele Kategorien eingef\u00fchrt werden, die sich nicht \u00fcberschneiden.<\/p>\n

Angesichts der offensichtlichen Unzul\u00e4nglichkeiten dieser beiden Methoden hat die IT-Community weiterhin an Modellen gearbeitet, die flexibler sind und mehr oder weniger universell unterschiedliche organisatorische Zugriffskontrollpolitiken unterst\u00fctzen. So entstand das dritte Modell der rollenbasierten Zugriffskontrolle!<\/b> Dieser Ansatz hat sich als der vielversprechendste erwiesen, da er nicht nur die Authentifizierung des Benutzers, sondern auch seine funktionalen Aufgaben im System erfordert.<\/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) vorgeschlagen. Damals entstand zum ersten Mal der Begriff RBAC (Rollenbasierte Zugriffskontrolle). <\/b>Diese Forschungen und die Beschreibungen der grundlegenden Komponenten sowie deren Zusammenh\u00e4nge bilden die Grundlage f\u00fcr den bis heute geltenden Standard INCITS 359-2012, der von dem Internationalen Komitee f\u00fcr Informationstechnologiestandards (INCITS) genehmigt wurde.<\/p>\n

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 \u2013 Benutzer, Sitzungen, Rollen, Berechtigungen, Operationen und Objekte sowie deren Beziehungen und Verbindungen.<\/p>\n

Der Standard bietet eine minimal notwendige Struktur f\u00fcr die Erstellung eines Rollenmodells \u2013 die Zusammenf\u00fchrung von Rechten in Rollen und anschlie\u00dfend die Vergabe von Zug\u00e4ngen an Benutzer \u00fcber 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\u00fcndeln, die f\u00fcr alle Mitarbeiter erforderlich sind. Dazu kann der Zugang zu E-Mails, zu DMS, zum Unternehmensportal u.a. geh\u00f6ren. Diese Befugnisse k\u00f6nnen in eine gemeinsame Rolle namens 'Mitarbeiter' integriert werden, wodurch es unn\u00f6tig wird, in jeder der h\u00f6heren Rollen alle elementaren Rechte immer wieder aufzulisten. Es reicht aus, einfach das Erbe der Rolle 'Mitarbeiter' anzugeben.<\/p>\n

\"Wir
\n
\nSp\u00e4ter wurde der Standard um neue Zugriffsattribute erg\u00e4nzt, die mit der st\u00e4ndig wechselnden Umgebung in Verbindung stehen. Es wurde die M\u00f6glichkeit eingef\u00fchrt, statische und dynamische Einschr\u00e4nkungen zu definieren. Statische Einschr\u00e4nkungen bedeuten, dass Rollen nicht kombiniert werden k\u00f6nnen (dies bezieht sich auf die Eingabe und \u00dcberwachung von Operationen, wie oben erw\u00e4hnt). Dynamische Einschr\u00e4nkungen k\u00f6nnen durch variierende Parameter wie Zeit (Arbeits-\/Nichtarbeitszeiten oder -tage), Standort (B\u00fcro\/Zuhause) usw. bestimmt werden.<\/p>\n

Es ist erw\u00e4hnenswert, dass der Zugriff auf Basis von Attributen verwaltet wird (ABAC \u2013 Attribute-based access control).<\/b> Dieser Ansatz beruht auf der Bereitstellung von Zugriff 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 Attribute von Benutzern, Ressourcen und Ger\u00e4ten sowie Zeit oder Standort hinzugef\u00fcgt werden. Dies erm\u00f6glicht es, weniger Rollen zu nutzen, zus\u00e4tzliche Einschr\u00e4nkungen einzuf\u00fchren und den Zugriff auf das Minimalnotwendige zu beschr\u00e4nken, wodurch die Sicherheit erh\u00f6ht wird.<\/p>\n

Beispielsweise kann einem Buchhalter der Zugriff auf Konten gew\u00e4hrt 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\u00e4hrt werden, wenn sich der Benutzer von einem im Register der erlaubten Ger\u00e4te authentifiziert. Eine sinnvolle Erg\u00e4nzung zum Rollenmodell, jedoch wird sie aufgrund der Notwendigkeit, viele Regeln und Berechtigungstabellen zu erstellen, selten allein verwendet.<\/p>\n

Ich m\u00f6chte ein Beispiel f\u00fcr die Anwendung von ABAC aus meiner \"fr\u00fcheren Karriere\" geben. In unserer Bank gab es mehrere Filialen. Die Mitarbeiter der Kundenb\u00fcros in diesen Filialen f\u00fchrten v\u00f6llig identische Aufgaben aus, durften jedoch nur in dem Hauptsystem mit den Konten ihrer Region arbeiten. Zun\u00e4chst begannen wir, separate Rollen f\u00fcr jede Region zu erstellen \u2013 und es entstanden eine sehr gro\u00dfe Anzahl von Rollen mit sich wiederholenden Funktionalit\u00e4ten, jedoch mit Zugriff auf verschiedene Konten! Durch die Verwendung des Standortattributs f\u00fcr den Benutzer, das mit einem bestimmten Kontobereich zur \u00dcberpr\u00fcfung verkn\u00fcpft wurde, konnten wir die Anzahl der Rollen im System erheblich reduzieren. Am Ende blieben nur Rollen f\u00fcr eine Filiale \u00fcbrig, die auf die entsprechenden Positionen in allen anderen Territorialen Einheiten der Bank \u00fcbertragen wurden.<\/p>\n

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

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

\nDer erste Schritt besteht darin, ein funktionales Modell zu erstellen \u2013 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\u00fcr spezifische Bereiche \u2013 Abteilungen, Sekretariate, Abteilungen. Das funktionale Modell muss mit allen interessierten Abteilungen (Gesch\u00e4ft, 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\u00f6chten \u2013 die aus dem System exportiert und \u201eauf einen Nenner gebracht\u201c wurden. Dann k\u00f6nnen Sie bei der Abstimmung der erhaltenen Rollen mit dem Gesch\u00e4ftsinhaber auf den spezifischen Punkt des funktionalen Modells verweisen, auf dessen Grundlage in die Rolle das eine oder andere Recht aufgenommen wird.<\/p>\n

Schritt 2: Auditisieren Sie die IT-Systeme und erstellen Sie einen Priorisierungsplan.<\/h2>\n

\nIm zweiten Schritt sollte eine Pr\u00fcfung der IT-Systeme erfolgen, um zu kl\u00e4ren, wie der Zugang zu diesen organisiert ist. Zum Beispiel gab es in meinem Finanzunternehmen mehrere Hundert Informationssysteme. In allen Systemen gab es einige Ans\u00e4tze zum Rollenmanagement, in den meisten \u2013 bestimmte Rollen, aber haupts\u00e4chlich auf Papier oder im Systemverzeichnis \u2013 sie waren l\u00e4ngst veraltet, und der Zugang wurde auf Basis tats\u00e4chlicher Benutzeranforderungen gew\u00e4hrt. Nat\u00fcrlich ist es einfach unm\u00f6glich, ein Rollenmodell sofort in mehreren Hundert Systemen zu erstellen; man muss irgendwo anfangen. Wir haben eine tiefgehende Analyse des Zugangsmanagementprozesses durchgef\u00fchrt, um den Reifegrad zu bestimmen. W\u00e4hrend der Analyse haben wir Kriterien zur Priorisierung der Informationssysteme entwickelt \u2013 Kritikalit\u00e4t, Bereitschaft, Pl\u00e4ne zur Stilllegung usw. Anhand dieser 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 Zugangsmanagement zu automatisieren.<\/p>\n

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