Aufbau eines rollenbasierten Zugriffskontrollmodells. Teil eins, vorbereitend

Jetzt arbeite ich für einen Softwareanbieter, insbesondere für Zutrittskontrolllösungen. Und meine Erfahrung „aus einem früheren Leben“ hängt mit der Kundenseite zusammen – einem großen Finanzinstitut. Zu diesem Zeitpunkt konnte sich unsere Zutrittskontrollgruppe in der Informationssicherheitsabteilung nicht mit großen Kompetenzen im IdM rühmen. Wir haben dabei viel gelernt, wir mussten eine Reihe von Unebenheiten schließen, um einen funktionierenden Mechanismus zur Verwaltung von Benutzerrechten in Informationssystemen im Unternehmen aufzubauen.

Indem ich meine beim Kunden gesammelten Erfahrungen mit dem Wissen und den Kompetenzen des Anbieters kombiniere, möchte ich Ihnen im Wesentlichen eine Schritt-für-Schritt-Anleitung geben: Wie man in einem großen Unternehmen ein rollenbasiertes Zugriffskontrollmodell erstellt und was es am Ende bringen wird. Meine Anleitung besteht aus zwei Teilen: Im ersten Teil bereiten wir den Bau eines Modells vor, im zweiten Teil bauen wir es tatsächlich. Bevor Sie zum ersten Teil kommen, vorbereitend.

NB Der Aufbau eines Vorbildes ist leider kein Ergebnis, sondern ein Prozess. Oder besser gesagt, sogar Teil des Prozesses der Schaffung eines Zugangskontroll-Ökosystems im Unternehmen. Schalten Sie also lange auf das Spiel ein.

Lassen Sie uns zunächst definieren: Was ist rollenbasierte Zugriffskontrolle? Angenommen, Sie haben eine große Bank mit Zehn- oder sogar Hunderttausenden Mitarbeitern (Subjekten), von denen jeder über Dutzende Zugriffsrechte auf Hunderte von bankinternen Informationssystemen (Objekten) verfügt. Und nun multiplizieren Sie die Anzahl der Objekte mit der Anzahl der Subjekte – so viele Verbindungen müssen Sie mindestens zuerst aufbauen und dann steuern. Ist das wirklich manuell möglich? Natürlich nicht – Rollen schienen dieses Problem zu lösen.

Eine Rolle ist eine Reihe von Berechtigungen, die ein Benutzer oder eine Benutzergruppe benötigt, um bestimmte Arbeitsaufgaben auszuführen. Jeder Mitarbeiter kann eine oder mehrere Rollen haben und jede Rolle kann eine oder mehrere Berechtigungen enthalten, die einem Benutzer innerhalb dieser Rolle gewährt werden. Rollen können an bestimmte Positionen, Abteilungen oder funktionale Aufgaben von Mitarbeitern gebunden sein.

Rollen werden in der Regel aus individuellen Mitarbeiterberechtigungen in jedem Informationssystem erstellt. Anschließend werden aus den Rollen der einzelnen Systeme globale Geschäftsrollen gebildet. Beispielsweise umfasst die Geschäftsrolle „Kreditmanager“ mehrere separate Rollen in Informationssystemen, die im Kundenbüro der Bank verwendet werden. Zum Beispiel im Hauptautomatisierungssystem für Banken, Registrierkassen, elektronischen Dokumentenverwaltungssystemen, Servicemanagern und anderen. Geschäftsrollen sind in der Regel an die Organisationsstruktur gebunden, also an eine Reihe von Unternehmensabteilungen und Positionen in diesen. So entsteht die globale Rollenmatrix (ein Beispiel gebe ich in der folgenden Tabelle).

Es ist erwähnenswert, dass es einfach unmöglich ist, ein 100-prozentiges Vorbild zu schaffen, das den Mitarbeitern jeder Position in einer kommerziellen Struktur alle erforderlichen Rechte bietet. Ja, das ist nicht notwendig. Schließlich kann das Vorbild nicht statisch sein, denn es hängt von der sich ständig verändernden Umgebung ab. Und aus einer Änderung der Geschäftstätigkeit des Unternehmens, die sich entsprechend auf die Änderung der Organisationsstruktur und Funktionalität auswirkt. Und aus der mangelnden vollständigen Bereitstellung von Ressourcen, aus der Nichteinhaltung von Stellenbeschreibungen, aus dem Streben nach Gewinn auf Kosten der Sicherheit und aus vielen anderen Faktoren. Daher ist es notwendig, ein Vorbild aufzubauen, das bis zu 80 % des Bedarfs der Nutzer an den notwendigen Grundrechten bei der Besetzung einer Stelle abdecken kann. Und die restlichen 20 % können sie bei Bedarf später in gesonderten Anträgen befragen.

Natürlich kann man fragen: „Was, es gibt überhaupt keine 100-prozentigen Vorbilder?“ Nun ja, das passiert zum Beispiel in gemeinnützigen Strukturen, die keinen häufigen Veränderungen unterliegen – in manchen Forschungsinstituten. Oder in militärisch-industriellen Komplexorganisationen mit einem hohen Sicherheitsniveau, bei denen Sicherheit an erster Stelle steht. Dies geschieht in einer kommerziellen Struktur, jedoch im Rahmen einer einzelnen Einheit, deren Arbeit ein ziemlich statischer und vorhersehbarer Prozess ist.

Der Hauptvorteil des Rollenmanagements liegt in der Vereinfachung der Rechtevergabe, da die Anzahl der Rollen deutlich geringer ist als die Anzahl der Benutzer des Informationssystems. Und das gilt für jede Branche.

Nehmen wir ein Einzelhandelsunternehmen: Es beschäftigt Tausende von Verkäufern, aber diese haben im N-System die gleichen Rechte und es wird nur eine Rolle für sie geschaffen. Ein neuer Verkäufer kam zum Unternehmen – ihm wurde automatisch die erforderliche Rolle im System zugewiesen, das bereits über alle erforderlichen Befugnisse verfügt. Außerdem können Sie mit einem Klick die Rechte für Tausende von Verkäufern gleichzeitig ändern und beispielsweise eine neue Option zum Erstellen eines Berichts hinzufügen. Sie müssen nicht tausend Vorgänge ausführen und jedem Konto ein neues Recht zuordnen – fügen Sie diese Option einfach zur Rolle hinzu und sie wird für alle Verkäufer gleichzeitig angezeigt.

Ein weiterer Vorteil der rollenbasierten Verwaltung ist die Vermeidung inkompatibler Berechtigungen. Das heißt, ein Mitarbeiter, der eine bestimmte Rolle im System innehat, kann nicht gleichzeitig eine andere Rolle innehaben, deren Rechte nicht mit den Rechten der ersten Rolle kombiniert werden sollten. Ein anschauliches Beispiel ist das Verbot der Kombination der Funktionen Eingabe und Kontrolle einer Finanztransaktion.

Jeder, der sich dafür interessiert, wie die rollenbasierte Zugriffskontrolle überhaupt entstanden ist, kann dies tun
Tauchen Sie ein in die Geschichte
Wenn wir uns der Geschichte zuwenden, dann dachte die IT-Community bereits in den 70er Jahren des XNUMX. Jahrhunderts zum ersten Mal über Zugangskontrollmethoden nach. Zwar waren die Anwendungen damals recht einfach, aber wie auch heute wollte jeder den Zugriff darauf bequem verwalten. Gewähren, ändern und kontrollieren Sie Benutzerrechte – nur um einfacher zu verstehen, welchen Zugriff jeder von ihnen hat. Doch damals gab es noch keine gemeinsamen Standards, die ersten Zutrittskontrollsysteme wurden entwickelt und jedes Unternehmen basierte auf seinen eigenen Vorstellungen und Regeln.

Mittlerweile sind viele verschiedene Zutrittskontrollmodelle bekannt, die jedoch nicht sofort auf den Markt kamen. Lassen Sie uns auf diejenigen eingehen, die einen konkreten Beitrag zur Entwicklung dieser Richtung geleistet haben.

Das erste und wahrscheinlich einfachste Modell ist Diskretionäre (selektive) Zugangskontrolle (DAC – Diskretionäre Zugangskontrolle). Dieses Modell impliziert die gemeinsame Nutzung von Rechten durch alle Teilnehmer am Zugriffsprozess. Jeder Benutzer erhält Zugriff auf bestimmte Objekte oder Vorgänge. Tatsächlich entspricht hier die Menge der Subjekte der Rechte der Menge der Objekte. Dieses Modell erwies sich als zu flexibel und zu schwer zu warten: Zugriffslisten werden riesig und sind mit der Zeit schwer zu kontrollieren.

Das zweite Modell ist Obligatorische Zugangskontrolle (MAC). Nach diesem Modell erhält jeder Benutzer Zugriff auf das Objekt entsprechend dem erteilten Zugriff auf eine bestimmte Datenvertraulichkeitsstufe. Dementsprechend sollten Objekte nach dem Grad der Vertraulichkeit kategorisiert werden. Im Gegensatz zum ersten flexiblen Modell erwies sich dieses jedoch als zu streng und restriktiv. Sein Einsatz rechtfertigt sich nicht, wenn das Unternehmen über viele verschiedene Informationsressourcen verfügt: Um den Zugriff auf verschiedene Ressourcen abzugrenzen, müssen Sie viele Kategorien einführen, die sich nicht überschneiden.

Aufgrund der offensichtlichen Unvollkommenheiten dieser beiden Methoden hat die IT-Community weiterhin Modelle entwickelt, die flexibler und gleichzeitig mehr oder weniger universell sind, um verschiedene Arten von organisatorischen Zugriffskontrollrichtlinien zu unterstützen. Und da erschien es das dritte Modell der rollenbasierten Zugriffskontrolle! Dieser Ansatz erwies sich als der erfolgversprechendste, da er nicht nur die Autorisierung der Identität des Benutzers, sondern auch seiner Arbeitsfunktionen in den Systemen erfordert.

Die erste gut beschriebene Vorbildstruktur wurde 1992 von den amerikanischen Wissenschaftlern David Ferrailo und Richard Kuhn vom US-amerikanischen National Institute of Standards and Technology vorgeschlagen. Dann tauchte der Begriff erstmals auf RBAC (Rollenbasierte Zugriffskontrolle). Diese Studien und Beschreibungen der Hauptkomponenten sowie ihrer Beziehungen bildeten 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 Jobfunktion im Kontext einer Organisation mit einer damit verbundenen Semantik hinsichtlich der Autorität und Verantwortung, die dem Benutzer zugewiesen ist, der der Rolle zugewiesen ist“. Das Dokument legt die Grundelemente von RBAC fest – Benutzer, Sitzungen, Rollen, Berechtigungen, Vorgänge und Objekte sowie die Beziehungen und Beziehungen zwischen ihnen.

Der Standard bietet die erforderliche Mindeststruktur für den Aufbau eines Rollenmodells – die Kombination von Rechten in Rollen und die anschließende Gewährung von Zugriffsrechten an Benutzer über diese Rollen. Die Mechanismen zum Zusammensetzen von Rollen aus Objekten und Operationen werden skizziert, die Hierarchie der Rollen und die Vererbung von Befugnissen beschrieben. Tatsächlich gibt es in jedem Unternehmen Rollen, die elementare Befugnisse vereinen, die für alle Mitarbeiter des Unternehmens notwendig sind. Dies kann der Zugriff auf E-Mail, auf das EDMS, auf das Unternehmensportal usw. sein. Diese Berechtigungen können in einer allgemeinen Rolle namens „Mitarbeiter“ zusammengefasst werden, und es ist nicht erforderlich, in jeder der übergeordneten Rollen immer wieder alle elementaren Rechte aufzulisten. Es reicht aus, nur das Zeichen der Vererbung der Rolle „Mitarbeiter“ anzugeben.

Später wurde der Standard durch neue Zugriffsattribute im Zusammenhang mit der sich ständig ändernden Umgebung ergänzt. Es wurde die Möglichkeit hinzugefügt, statische und dynamische Einschränkungen einzuführen. Statische implizieren die Unmöglichkeit, Rollen zu kombinieren (die gleiche Eingabe und Steuerung der oben genannten Vorgänge). Dynamische Grenzen können durch die Änderung von Parametern wie Zeit (Arbeits-/Arbeitsfreistunden oder -tage), Standort (Büro/Zuhause) und dergleichen definiert werden.

Getrennt davon sollte gesagt werden Attributbasierte Zugriffskontrolle (ABAC). Der Ansatz basiert auf der Gewährung des Zugriffs mithilfe von Regeln zur gemeinsamen Nutzung von Attributen. Dieses Modell kann separat verwendet werden, ergänzt jedoch häufig aktiv das klassische Rollenmodell: Sie können Attribute von Benutzern, Ressourcen und Geräten sowie Zeit oder Ort zu einer bestimmten Rolle hinzufügen. Dadurch können Sie weniger Rollen verwenden, zusätzliche Einschränkungen einführen, den Zugriff auf ein Minimum beschränken und so die Sicherheit erhöhen.

Beispielsweise kann einem Buchhalter Zugriff auf Konten gewährt werden, wenn er in einer bestimmten Region arbeitet. Anschließend wird der Standort des Facharztes mit einem bestimmten Referenzwert verglichen. Oder Sie können den Zugriff auf Konten nur dann gewähren, wenn sich der Benutzer über ein Gerät anmeldet, das im Register der zulässigen Geräte eingetragen ist. Eine gute Ergänzung zum Vorbild, wird jedoch aufgrund der Notwendigkeit, viele Regeln und Tabellen mit Berechtigungen oder Einschränkungen zu erstellen, selten allein verwendet.

Ich werde ein Beispiel für die Verwendung von ABAC aus meinem „früheren Leben“ geben. Unsere Bank hatte mehrere Filialen. Mitarbeiter der Kundenbüros in diesen Filialen führten genau die gleichen Vorgänge durch, mussten jedoch im Hauptsystem nur mit Konten in ihrer Region arbeiten. Zuerst haben wir damit begonnen, für jede Region separate Rollen zu erstellen – und es gab sooo viele solcher Rollen mit sich wiederholenden Funktionen, aber mit Zugriff auf unterschiedliche Konten! Durch die Verwendung eines Standortattributs für einen Benutzer und die Verknüpfung mit einem bestimmten Bereich von zu überprüfenden Konten haben wir dann die Anzahl der Rollen im System erheblich reduziert. Dadurch blieben Rollen nur für eine Filiale bestehen, die für die entsprechenden Positionen in allen anderen Gebietseinheiten der Bank repliziert wurden.

Und nun sprechen wir über die notwendigen vorbereitenden Schritte, ohne die es einfach unmöglich ist, ein funktionierendes Vorbild aufzubauen.

Schritt 1. Erstellen Sie ein Funktionsmodell

Es lohnt sich, mit der Erstellung eines Funktionsmodells zu beginnen – einem Dokument der obersten Ebene, das die Funktionalität jeder Einheit und jeder Position detailliert beschreibt. Informationen stammen in der Regel aus verschiedenen Dokumenten: Stellenbeschreibungen und Regelungen für einzelne Bereiche – Abteilungen, Abteilungen, Abteilungen. Das Funktionsmodell muss mit allen interessierten Abteilungen (Geschäft, interne Kontrolle, Sicherheit) abgestimmt und von der Unternehmensleitung genehmigt werden. Wozu dient dieses Dokument? Damit sich das Vorbild darauf berufen kann. Sie werden zum Beispiel ein Rollenmodell aufbauen, das auf den bestehenden Rechten der Mitarbeiter basiert – aus dem System entladen und „auf einen gemeinsamen Nenner gebracht“. Bei der Vereinbarung der erhaltenen Rollen mit dem Geschäftsinhaber des Systems kann man sich dann auf einen bestimmten Punkt des Funktionsmodells beziehen, auf dessen Grundlage dieses oder jenes Recht in die Rolle aufgenommen wird.

Schritt 2. Wir prüfen die IT-Systeme und erstellen einen Priorisierungsplan

Im zweiten Schritt sollte eine Prüfung der IT-Systeme durchgeführt werden, um zu verstehen, wie der Zugriff darauf organisiert ist. Mein Finanzunternehmen betrieb beispielsweise mehrere hundert Informationssysteme. In allen Systemen gab es einige Rudimente der Rollenverwaltung, in den meisten – einige Rollen, aber meist auf Papier oder im Systemverzeichnis – sind sie längst veraltet und der Zugriff darauf wurde auf tatsächliche Benutzeranfragen verteilt. Natürlich ist es einfach unmöglich, in mehreren hundert Systemen gleichzeitig ein Vorbild aufzubauen, man muss irgendwo anfangen. Wir haben eine eingehende Analyse des Zutrittskontrollprozesses durchgeführt, um seinen Reifegrad zu bestimmen. Im Rahmen der Analyse wurden Kriterien für die Priorisierung von Informationssystemen entwickelt – Kritikalität, Bereitschaft, Stilllegungspläne usw. Mit ihrer Hilfe haben wir eine Sequenz zur Entwicklung/Aktualisierung von Vorbildern für diese Systeme erstellt. Und dann wurden Vorbilder in den Plan zur Integration mit der Identity Management-Lösung zur Automatisierung der Zugriffskontrolle aufgenommen.

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

• Ist das System mit den betrieblichen Prozessen verknüpft, von denen das Kerngeschäft des Unternehmens abhängt?
• Wird die Störung des Systems Auswirkungen auf die Integrität der Vermögenswerte des Unternehmens haben?
• Wie hoch ist die maximal zulässige Ausfallzeit des Systems, nach deren Erreichen die Aktivität nach einer Unterbrechung nicht mehr wiederhergestellt werden kann?
• Kann eine Verletzung der Integrität der Informationen im System zu irreversiblen finanziellen und rufschädigenden Folgen führen?
• Kritische Bedeutung für Betrug. Das Vorhandensein einer Funktionalität, bei deren unzureichender Kontrolle die Durchführung interner/externer betrügerischer Handlungen möglich ist;
• Welche rechtlichen Anforderungen sowie internen Regeln und Verfahren gelten für diese Systeme? Wird es bei Nichteinhaltung Strafen seitens der Aufsichtsbehörden geben?

In unserem Finanzunternehmen haben wir eine solche Prüfung durchgeführt. Das Management hat ein Prüfverfahren zur Überprüfung der Zugriffsrechte entwickelt, um sich zuerst mit vorhandenen Benutzern und Rechten in den Informationssystemen zu befassen, die auf der Liste der höchsten Priorität stehen. Der Sicherheitsabteilung wurde der Eigentümer dieses Prozesses zugewiesen. Doch um ein vollständiges Bild der Zugriffsrechte im Unternehmen zu erhalten, war es notwendig, IT- und Fachabteilungen in den Prozess einzubinden. Und hier begannen Streitigkeiten, Missverständnisse und manchmal sogar Sabotage: Niemand möchte sich von seinen aktuellen Pflichten lösen und sich auf auf den ersten Blick unverständliche Aktivitäten einlassen.

NB Große Unternehmen mit entwickelten IT-Prozessen kennen wahrscheinlich das IT-Auditverfahren – IT General Controls (ITGC), das es Ihnen ermöglicht, Mängel in IT-Prozessen zu erkennen und eine Kontrolle zu etablieren, um Prozesse gemäß Best Practices (ITIL, COBIT, IT Governance usw.) zu verbessern. Ein solches Audit ermöglicht es IT und Business, sich besser zu verstehen und eine gemeinsame Entwicklungsstrategie zu entwickeln, Risiken zu analysieren, Kosten zu optimieren und effektivere Arbeitsansätze zu entwickeln.



Einer der Prüfungsbereiche besteht darin, die Parameter des logischen und physischen Zugriffs auf Informationssysteme zu bestimmen. Die gewonnenen Daten dienten uns als Grundlage für die weitere Nutzung beim Aufbau eines Vorbildes. Als Ergebnis einer solchen Prüfung verfügen wir über ein Verzeichnis der IT-Systeme, in dem deren technische Parameter ermittelt und beschrieben wurden. Darüber hinaus wurde für jedes System ein Eigentümer aus der Geschäftsrichtung bestimmt, in dessen Interesse es betrieben wurde: Er war für die Geschäftsprozesse verantwortlich, denen dieses System diente. Außerdem wurde ein IT-Servicemanager ernannt, der für die technische Umsetzung der Geschäftsanforderungen in einem spezifischen IS verantwortlich ist. Erfasst wurden die für das Unternehmen kritischsten Systeme und deren technische Parameter, Inbetriebnahme- und Stilllegungstermine etc. Diese Parameter haben bei der Vorbereitung zum Aufbau eines Vorbildes sehr geholfen.

Schritt 3 Erstellen Sie eine Methodik

Der Schlüssel zum Erfolg eines jeden Unternehmens ist die richtige Methode. Daher müssen wir sowohl zum Aufbau eines Vorbilds als auch zur Durchführung eines Audits eine Methodik entwickeln, mit der wir die Interaktion zwischen Abteilungen beschreiben, Verantwortlichkeiten in Unternehmensvorschriften festlegen usw.
Zunächst müssen Sie alle verfügbaren Dokumente prüfen, die das Verfahren zur Gewährung von Zugang und Rechten festlegen. Sinnvollerweise sollten Prozesse auf mehreren Ebenen dokumentiert werden:

• allgemeine Unternehmensanforderungen;
• Anforderungen an die Bereiche Informationssicherheit (abhängig von den Aktivitäten der Organisation);
• Anforderungen an technologische Prozesse (Anweisungen, Zugriffsmatrizen, Richtlinien, Konfigurationsanforderungen).

In unserem Finanzunternehmen fanden wir viele veraltete Dokumente – wir mussten sie an die neu eingeführten Prozesse anpassen.

Im Auftrag der Geschäftsführung wurde eine Arbeitsgruppe gebildet, der Vertreter aus den Bereichen Sicherheit, IT, Business und Interne Kontrolle angehörten. In der Anordnung wurden die Ziele der Gruppenbildung, die Richtung der Tätigkeit, die Dauer ihres Bestehens und die Verantwortlichkeiten jeder Seite festgelegt. Darüber hinaus haben wir eine Audit-Methodik und ein Vorgehen zum Aufbau einer Vorbildfunktion entwickelt: Sie wurden von allen verantwortlichen Vertretern der Bereiche abgestimmt und von der Unternehmensleitung genehmigt.

Dokumente, die den Ablauf der Arbeiten, Fristen, Verantwortlichkeiten usw. beschreiben. - eine Garantie dafür, dass auf dem Weg zum geschätzten Ziel, das zunächst nicht für jeden offensichtlich ist, niemand die Frage hat: „Warum machen wir das, warum brauchen wir es usw.“ und es wird keine Möglichkeit geben, „abzuspringen“ oder den Prozess zu verlangsamen.

Schritt 4. Festlegen der Parameter des vorhandenen Zugriffskontrollmodells

Im Hinblick auf die Zugangskontrolle erstellen wir den sogenannten „Systempass“. Tatsächlich handelt es sich hierbei um einen Fragebogen zu einem bestimmten Informationssystem, in dem alle Algorithmen zur Verwaltung des Zugriffs darauf erfasst sind. Unternehmen, die bereits Lösungen der IdM-Klasse implementiert haben, kennen einen solchen Fragebogen wahrscheinlich, da mit ihm die Untersuchung von Systemen beginnt.

Einige der Parameter zur Anlage und Eigentümer sind aus dem IT-Register (siehe Schritt 2, Audit) in den Fragebogen eingeflossen, es wurden jedoch neue hinzugefügt:

• wie Konten verwaltet werden (direkt in der Datenbank oder über Programmschnittstellen);
• wie sich Benutzer beim System anmelden (mit einem separaten Konto oder mit einem AD-Konto, LDAP usw.);
• welche Zugriffsebenen auf das System verwendet werden (Anwendungsebene, Systemebene, Nutzung von Netzwerkdateiressourcen durch das System);
• Beschreibung und Parameter der Server, auf denen das System läuft;
• welche Kontoverwaltungsvorgänge unterstützt werden (Sperren, Umbenennen usw.);
• welche Algorithmen oder Regeln werden verwendet, um die Systembenutzerkennung zu bilden;
• Welches Attribut kann verwendet werden, um eine Verknüpfung mit einem Datensatz über einen Mitarbeiter im Personalsystem herzustellen (vollständiger Name, Personalnummer usw.);
• alle möglichen Kontoattribute und Regeln zum Ausfüllen;
• welche Zugriffsrechte existieren im System (Rollen, Gruppen, atomare Rechte etc., gibt es verschachtelte oder hierarchische Rechte);
• Mechanismen zur Trennung von Zugriffsrechten (nach Positionen, Abteilungen, Funktionalität usw.);
• ob das System über Regeln zur Rechtetrennung (SOD – Segregation of Duties) verfügt und wie diese funktionieren;
• wie Ereignisse wie Abwesenheit, Versetzung, Entlassung, Aktualisierung von Mitarbeiterdaten usw. im System verarbeitet werden.

Die Liste ließe sich fortsetzen und die verschiedenen Parameter und anderen Einheiten detailliert beschreiben, die am Zugriffskontrollprozess beteiligt sind.

Schritt 5: Erstellen Sie eine geschäftsorientierte Autorisierungsbeschreibung

Ein weiteres Dokument, das wir beim Aufbau eines Vorbilds benötigen, ist ein Leitfaden zu allen möglichen Befugnissen (Rechten), die Benutzern in einem Informationssystem gewährt werden können, mit einer detaillierten Beschreibung der dahinter stehenden Geschäftsfunktion. Oft sind die Befugnisse im System mit bestimmten Namen verschlüsselt, die aus Buchstaben und Zahlen bestehen, und Unternehmensmitarbeiter können nicht herausfinden, was sich hinter diesen Zeichen verbirgt. Dann gehen sie zum IT-Service und dort ... können sie beispielsweise auch die Frage nach selten genutzten Rechten nicht beantworten. Dann müssen Sie weitere Tests durchführen.

Gut ist es, wenn bereits eine Unternehmensbeschreibung vorliegt oder sogar eine Zuordnung dieser Rechte zu Gruppen und Rollen erfolgt. Für einige Anwendungen besteht die beste Vorgehensweise darin, einen solchen Leitfaden bereits in der Entwicklungsphase zu erstellen. Da dies jedoch nicht oft vorkommt, wenden wir uns erneut an die IT-Abteilung, um Informationen über alle möglichen Rechte einzuholen und diese zu beschreiben. Unser Leitfaden wird letztendlich Folgendes enthalten:

• der Name der Behörde, einschließlich des Objekts, für das das Zugriffsrecht gilt;
• die Aktion, die mit dem Objekt durchgeführt werden darf (Anzeigen, Ändern usw., die Möglichkeit der Einschränkung, beispielsweise auf territorialer Basis oder auf eine Gruppe von Kunden);
• Berechtigungscode (Code und Name der Systemfunktion/Anfrage, die mit der Berechtigung ausgeführt werden kann);
• Beschreibung der Autorität (eine detaillierte Beschreibung der Aktionen im IS bei der Anwendung der Autorität und ihrer Konsequenzen für den Prozess);
• Berechtigungsstatus: „Aktiv“ (wenn die Berechtigung mindestens einem Benutzer zugewiesen ist) oder „Nicht aktiv“ (wenn die Berechtigung nicht verwendet wird).

Schritt 6 Wir entladen Daten über Benutzer und Rechte aus den Systemen und gleichen diese mit der Personalquelle ab

In der letzten Vorbereitungsphase müssen Sie Daten aus Informationssystemen über alle Benutzer und die Rechte, die sie derzeit haben, hochladen. Hier sind zwei Szenarien möglich. Erstens hat die Sicherheitsabteilung direkten Zugriff auf das System und die Möglichkeit, die relevanten Berichte herunterzuladen, was selten, aber sehr praktisch ist. Zweitens: Wir senden eine Anfrage an die IT, um Berichte im erforderlichen Format zu erhalten. Die Praxis zeigt, dass es nicht möglich ist, mit der IT zu verhandeln und gleich beim ersten Mal die notwendigen Daten zu erhalten. Es sind mehrere Ansätze notwendig, bis die Informationen in der gewünschten Form und im gewünschten Format vorliegen.

Welche Daten müssen hochgeladen werden:

• Kontobezeichnung
• Name des Mitarbeiters, dem es zugewiesen ist
• Status (aktiv oder gesperrt)
• Datum der Kontoerstellung
• Datum der letzten Nutzung
• Liste der verfügbaren Rechte/Gruppen/Rollen

Wir haben also Entladungen aus dem System mit allen Benutzern und mit allen ihnen gewährten Rechten erhalten. Und sie legen alle gesperrten Konten sofort beiseite, da die Arbeit am Aufbau eines Vorbilds nur für aktive Benutzer durchgeführt wird.

Wenn Ihr Unternehmen dann nicht über automatisierte Mittel zur Sperrung des Zugangs für entlassene Mitarbeiter verfügt (das ist keine Seltenheit) oder eine Patchwork-Automatisierung vorliegt, die nicht immer ordnungsgemäß funktioniert, müssen Sie alle „toten Seelen“ identifizieren. Wir sprechen über die Konten bereits entlassener Mitarbeiter, deren Rechte aus irgendeinem Grund nicht gesperrt sind – sie müssen gesperrt werden. Dazu gleichen wir die hochgeladenen Daten mit der Personalquelle ab. Auch die Entladung des Personals ist vorab bei der den Personalstützpunkt führenden Einheit zu besorgen.

Separat ist es notwendig, Konten, deren Eigentümer nicht in der Personalbasis gefunden wurden, niemandem zuzuordnen – also eigentümerlos – beiseite zu legen. Für diese Liste benötigen wir das Datum der letzten Nutzung: Ist diese noch recht aktuell, müssen wir noch nach den Eigentümern suchen. Dabei kann es sich um Konten externer Auftragnehmer oder Dienstkonten handeln, die niemandem zugeordnet sind, aber mit beliebigen Prozessen verknüpft sind. Um die Inhaberschaft des Kontos zu klären, können Sie Briefe an alle Abteilungen mit der Bitte um Antwort senden. Wenn die Besitzer gefunden sind, geben wir Daten über sie in das System ein: Auf diese Weise werden alle aktiven Konten identifiziert und der Rest gesperrt.

Sobald unsere Uploads von unnötigen Datensätzen befreit sind und nur noch aktive Konten übrig bleiben, können wir damit beginnen, ein Vorbild für ein bestimmtes Informationssystem aufzubauen. Aber darüber werde ich im nächsten Artikel sprechen.

Autor: Lyudmila Sevastyanova, Solar inRights Promotion Manager

Source: habr.com