Niemand weiß (fast), was Autorisierung ist.

Während meiner Arbeit als Architekt in IdM-Implementierungsprojekten habe ich Dutzende Implementierungen von Berechtigungsmechanismen sowohl in internen Lösungen von Unternehmen als auch in kommerziellen Produkten analysiert und kann sagen, dass sie bei relativ komplexen Anforderungen fast überall nicht richtig oder zumindest nicht optimal ausgeführt werden. Der Grund ist meiner Meinung nach die geringe Aufmerksamkeit des Kunden und der Entwickler für diesen Aspekt in der Anfangsphase und die unzureichende Einschätzung der Auswirkungen von Anforderungen. Dies bestätigt indirekt den weit verbreiteten Missbrauch des Begriffs: Wenn ich den Ausdruck "Zwei-Faktor-Autorisierung" sehe, bekomme ich Schmerzen direkt unter meinem Rücken. Aus Gründen des Interesses haben wir die ersten 100 Artikel zu Habré in den Suchergebnissen nach "Autorisierung" analysiert, das Ergebnis war enttäuschend, es gab viel Schmerz:


In mehr als 80% der Fälle wird der Begriff falsch verwendet, stattdessen sollte das Wort „Authentifizierung“ verwendet werden. Als nächstes werde ich versuchen zu erklären, was es ist und warum es äußerst wichtig ist, diesem Thema besondere Aufmerksamkeit zu widmen.

Was ist das

So zitieren Sie Wikipedia:
Aus der Sicht eines Informationssystems ist dies der Entscheidungsprozess für die Bereitstellung des Zugangs zum Subjekt, um die Operation auf der Grundlage von Kenntnissen über das Subjekt durchzuführen. Zu diesem Zeitpunkt sollte das Subjekt in der Regel bereits identifiziert (wir müssen wissen, wer es ist) und authentifiziert sein (seine Identität wird bestätigt).

Die Implementierung von Berechtigungen bei der Entwicklung eines auf den Unternehmenssektor ausgerichteten Unternehmensinformationssystems oder -produkts ist eine sehr schwierige und verantwortungsvolle Aufgabe, der in der Entwurfsphase und in der ersten Entwicklungsphase häufig nicht genügend Aufmerksamkeit geschenkt wird, was in Zukunft zu einer „Krücken“ -Implementierung führt.

Ausgabe

Lassen Sie uns sehen, welche Berechtigungsanforderungen erfüllt sind und warum es äußerst wichtig ist, sie beim Entwurf eines Systems zunächst zu berücksichtigen und nicht für die Zukunft zu verschieben. In einem Unternehmensinformationssystem gibt es normalerweise zwei Quellen für Berechtigungsanforderungen: Geschäfts- und Informationssicherheit. Im allgemeinen Fall möchte ein Unternehmen Geheimnisse geheim halten und den Benutzern Berechtigungen gemäß ihrer Funktion im Geschäftsprozess erteilen, und die Sicherheit möchte sicherstellen, dass die Berechtigungen für jeden Benutzer mindestens ausreichen, und den Zugriff überwachen.

Nehmen wir zum Beispiel ein hypothetisches System für die Aushandlung großer Unternehmensverträge, ein typisches blutiges Unternehmen. Die folgenden Anforderungen an die Geschäftserlaubnis werden höchstwahrscheinlich auftreten:

1. Ein Benutzer, der nicht mit einem bestimmten Vertrag verbunden ist, sollte ihn nicht im System sehen
2. Der Autor des Vertrags sollte es in allen Phasen sehen.
3. Ein Benutzer mit einer Note von mindestens 10 hat das Recht, einen Vertrag zu erstellen.
4. Der Besucher muss den Vertrag sehen, beginnend mit dem Eingang auf der Bühne und weiter.
5. Abteilungsleiter sollten die Verträge ihrer Einheiten in der Hierarchie sehen.
6. Der Vertragsautor und der Referatsleiter haben das Recht, den Vertrag in jedem Stadium der Genehmigung zu widerrufen.
7. Die Geschäftsführung und das Sekretariat der Hauptverwaltung sollten die Unterlagen aller Zweigstellen einsehen.
8. Der Benutzer, der den Vertrag erstellt hat, sollte nicht berechtigt sein, diesen zu billigen.

Aus Sicherheitsgründen könnten wir folgende Anforderungen stellen :

1. Wissen, wer Zugriff auf einen bestimmten Vertrag hat.
2. Wissen, wer zu einem bestimmten Zeitpunkt Zugang zu einem bestimmten Vertrag hatte.
3. Dem Benutzer den Zugriff auf zuvor verfügbare Dokumente zu verweigern, wenn er seine Arbeitsaufgaben ändert.

Ich denke die Entwickler hatten schon Angst :). Ein zusätzlicher Schmerz ist die hohe Variabilität dieser Anforderungen. Übrigens sind nach den Statistiken einer großen 1C-Franchise zusätzliche Autorisierungsanforderungen eine der häufigsten Aufgaben für das Anpassen typischer Konfigurationen.

Deshalb zeigen wir auf, warum diese Anforderungen problematisch sind:

• Sie sind nicht stabil. Die Wahrscheinlichkeit ihrer Veränderung, auch kurzfristig, beträgt 1.
• Sie sind Querschnittsthemen. Ihre Implementierung wirkt sich auf alle Ebenen aus, vom Datenbankdesign bis zur Benutzeroberfläche.
• Sie liegen in der Ebene des Themenbereichs. Dies führt zu einer starken Konnektivität des Autorisierungsmechanismus mit einer Schicht von Geschäftslogik.
• Sie wirken sich auf die Leistung aus.

Lösungen

Die entwickelten Zugangskontrollmodelle helfen uns, dieses Problem zu lösen:

MAC ist ein Zugangsberechtigungsmodell. Der Zugriff des Subjekts auf das Objekt wird durch seine Zugriffsebene bestimmt: Die Zugriffsebene des Subjekts sollte nicht niedriger sein als die Geheimhaltungsstufe des Objekts.

DAC - Direktzugriffskontrolle. Der Zugriff des Subjekts auf das Objekt wird durch das Vorhandensein des Subjekts in der Zugriffsliste (ACL) des Objekts bestimmt.

RBAC ist ein Vorbild für die Zugriffskontrolle. Der Zugriff des Subjekts auf das Objekt wird durch das Vorhandensein der Rolle des Subjekts bestimmt, die die dem angeforderten Zugriff entsprechenden Befugnisse enthält.

ABAC ist ein Attributmodell der Zugriffskontrolle. Der Zugriff des Subjekts auf das Objekt wird dynamisch basierend auf einer Analyse der Richtlinien bestimmt, die die Werte der Attribute des Subjekts, Objekts und der Umgebung berücksichtigen. Dies beinhaltet auch PBAC, RAdAC, CBAC mit einigen Nuancen ( schicke Rezension von CUSTIS ).

Es wird dringend empfohlen, sie in ihrer ursprünglichen Form zu verwenden, ohne das Rad neu zu erfinden. In komplexen Informationssystemen wird häufig eine Kombination von Modellen verwendet. Beispielsweise ist die Kombination ACL + RBAC beliebt, wenn eine Rolle in einer Zugriffsliste enthalten ist. Der richtige Einsatz von Fertigmodellen ist jedoch auch keine leichte Aufgabe. Nicht jeder kann das richtige Modell auswählen, es von der Geschäftslogik trennen und eine akzeptable Leistung des Autorisierungsmechanismus erzielen.

Um die oben im Abschnitt „Probleme“ genannten Anforderungen zu implementieren, würde ich auf den ersten Blick die Kombination PBAC + ACL wählen. Die Anforderungen könnten wie folgt umgesetzt werden:

Die aufgeführten IS-Anforderungen werden problemlos mithilfe von ACLs implementiert, die Geschäftsanforderungen 5 und 7 werden jedoch mithilfe von PBAC implementiert. Um die Anforderungen von IS 1 und 2 zu implementieren, müssen Sie ihnen ein Journal oder einen ähnlichen Mechanismus hinzufügen, da dynamische Regeln bei aller Schönheit schlecht geprüft werden:

Total

Autorisierung ist ein unverdient vernachlässigtes Thema, sowohl in Veröffentlichungen als auch direkt im Entwicklungsprozess. Die Zwei-Faktor-Authentifizierung per SMS wird vom Kind auf die Site geschraubt. Das korrekte Implementieren von Berechtigungen im Unternehmenssystem ohne Krücken ist eine schwierige Aufgabe, der sich Lords und Architekten entziehen, und viele gängige kommerzielle Produkte (z. B. Atlassian Jira) stehen aufgrund der Komplexität der Anforderungen auf Krücken.

Wir planen eine Reihe von Artikeln zu Berechtigungsmodellen und zum Thema insgesamt. Wir freuen uns über Fragen und Anregungen zu Themen, die berücksichtigt werden müssen.