Daniel Esser

Permissions, Rollen & Security im BI-Stack
Kompliziert? Definitiv – Lösbar? Ja – Wie? bitte weiterlesen…

In diesem Beitrag möchte ich euch einen Überblick über das Themengebiet Access Control verschaffen. Dabei ist dieser Beitrag nicht auf Microsoft technologien beschränkt, orientiert sich aber mit praxisnahen Beispielen daran.

Ich möchte darum bitten, dass Ihr euch ein komplexes BI-Szenario vorstellt. Diese Szenario besteht aus mehreren dutzend Servern. Diese Server sind grob nach ihrem Verwendugszweck gruppiert; z.B. Entwicklung, Abnahme und Produktion.

Auf diesen Servern sind etliche Services installiert wie sie für diese Szenario typisch sind: OLAP, RDBMS (SMP/MPP), Standard Reporting, Analysewerkzeuge (z.B. Tableau, Executive Viewer o.ä.),  SharePoint Server und wahrscheinlich vieles mehr. Des Weiteren gibt es eine ganze Reihe verschiedener Personen die auf diese Server und Service zugreifen: Entwickler, Tester, Analysten, Administratoren, Betriebs-Teams etc. pp. Als weiterer Aspekt kommt hinzu, dass diese Personen unterschiedliche Berechtigungen auf den oben genannten Systemen haben. Diese Berechtigungen haben ein sehr hohes Spektrum; eine Berechtigung kann vom profanen Zugang zu einem Server per Remote Desktop bis hin zu einem subtilen Zugriff auf eine Spalte in einer Datenbank so ziemlich alles sein. Die Kernfrage lautet also wie kann ein solchen Universum an Möglichkeiten abgebildet und gemanaged werden?

 Role Based Access Control

In der Vergangenheit haben sich etliche Institute, Organisationen und Firmen mit genau dieser Fragestellung beschäftigt: z.B. das National Institute of Standards and Technology (NIST) und das Institute of Electrical and Electronics Engineers (IEEE) um nur zwei zu nennen. Bei der NIST wurde das Role Based Access Control (RBAC) Model als Standard definiert.

Ohne konkret auf den Inhalt des Standards einzugehen ist die grundlegende Idee von RBAC Personen & Personengruppen, Ressourcen (Computer, Datenbanken usw.) und Berechtigungen auf Ressourcen voneinander zu trennen. Dabei soll die Aufteilung so gestaltet sein, dass Berechtigungen einfach gewährt oder entfernt werden können ohne dabei großen administrativen Aufwand zu erzeugen.

RBAC und Active Directory Domain Services

Das Active Directory (AD) oder korrekterweise Active Directory Domain Services (ADDS) wird im Microsoft-Kosmos dazu verwandt Benutzer, Gruppen, Computer, Dienste, Server, Dateifreigaben und andere Geräte wie Drucker und Scanner zu verwalten. Da das ADDS für die Verwaltung von Gruppen und Benutzer eine entscheidende Rolle spielt muss dessen Funktionsumfang bei der Implementierung von RBAC berücksichtigt werden. Diese Arbeit hat Microsoft uns bereits abgenommen und diese Implementierung AGUDLP getauft. Die Abkürzung steht für account, global, universal, domain local, permissions.

Die Idee hinter AGUDLP…

lässt sich am besten durch ein einfaches Beispiel veranschaulichen:

Nehmen wir das Shared Folder \\nyc-ex-svr-01\groups\bizdev. Das Team für die Geschäftsfeldentwicklung innerhalb der Marketing Abteilung soll nun Schreib-Lese-Berechtigung bekommen. Das Team für die Geschäftsfeldentwicklung wird im AD durch eine Gruppe mit dem Namen „Geschäftsfeldentwicklung Team Mitglied“ repräsentiert. Folgende Implementierungsschritte sind nötig:

  1. Anlegen einer Gruppe mit dem Namen „Change Permissions auf \\nyc-ex-svr-01\groups\bizdev“
  2. Der Gruppe die NTFS „change“ Berechtigung erteilen.
  3. Hinzufügen der Gruppe „Geschäftsfeldentwicklung Team Mitglied“ zur Gruppe „Change Permissions auf \\nyc-ex-svr-01\groups\bizdev“

Die Vorteile liegen auf der Hand: Kommen weitere Personen zum Team für Geschäftsfeldentwicklung können diese einfach in die dafür vorgesehene Gruppe eingetragen werden. Diese Art der  Gruppe kann als fachliche Rolle bezeichnet werden, da diese ein Tätigkeitsfeld für Personen beschreibt. Ändern sich die Anforderungen an die Berechtigungen muss nur ein Eintrag am Shared Folder geändert werden, der sogennante Access Control Entry (ACE).

Weitere Überlegungen

Grundsätzlich ist man frei in bei der Definition im Aufbau der AD-Gruppen, da es bliebig viele Implementationen von RBAC gibt. Der oben genannte Weg ist ein Weg von vielen. Persönlich gesehen würde ich das Konzept noch um Ressourcen (z.B. Cubes, Datenbanken, Server & Reports) erweitern. Das bedeutet es gibt folgende Objekte im meinem RBAC-Modell:

  • Personen
  • Fachliche Rollen
  • Technische- oder Applikations-Rollen
  • Ressourcen
  • Berechtigungen

In der Grafik gibt es zwei Bäume, den für fachliche Rollen und Ressourcen. Beide Rollen werden im AD durch Gruppen realisiert. Im Baum für fachlichen Rollen werden Personen hinterlegt welche die Berechtigungen der entsprechenden fachlichen Rollen erben sollen. Zum Beispiel sind Angestellte der Finanzabteilung in der Gruppe/Rolle Finanzen. Sollten neue Angestellte zur Finanzabteilung kommen können diese hier aufgenommen werden und sind exakt genauso Berechtigt wie ihre Kollegen.

Um diese Beispiel zu konkretisieren befindet sich die Gruppe Finanzen, welche die Rolle von Mitgleidern der Finanzabteilung repräsentiert, in der Gruppe „Read Permission Financial Reporting Cube“. Die Gruppe repräsentiert die Leseberechtigung im Finanz Reporting Cube zu Analysezwecken.

Die Gruppe (Permission Group) „Read Permission Financial Reporting Cube“ ist in der technischen / applikations Rolle „Reader“ im Finanz Reporting Cube hinterlegt. Die eigentlichen Access Control Entries sind an der Rolle „Reader“ im Cube definiert.

Die Gruppen zwischen Personen und ACEs kann man belibieg tief schachteln. Allerdings wird dann das Gesamtsystem immer schwerer zu warten. Trotzdem bietet diese Art des Group Mangement entscheidende Vorteile:

  • Personen können jetzt in beliebig viele fachliche Rollen schlüpfen oder Abteilungen wechseln.
  • An technischen / applikations Rollen gibt es nur noch eine stark begrenzte Anzahl von Permission Groups und somit ACEs; diese kapseln die fachlichen Rollen weg.
  • Fein granulare Permission Groups können zu „mächtigeren“ Permission Groups zusammengefasst werden. Z.B. „Read Cube A“ und „Read Cube B“ zu „Read All Cubes“ => Ressource Baum

Role Based Access Control (im BI-Umfeld) ist ein kompliziertes Betätigungsfeld, ich hoffe dennoch, dass ich euch ein paar Einsichten gewähren konnte und stehe natürlich für Fragen und Diskussion zum Thema zur Verfügung.