Inhaltsverzeichnis
Das „Best Practice“ gibt es nicht!
Thomas Gomell
Die Verwaltung von Berechtigungen (ACL/ACE) in der Windows Fileserver Welt sind komplex. Es ist vor allem deswegen so kompliziert, weil es keine gemeinsame Datenbasis gibt. Der Fileserver und die zu berechtigten Accounts kommen zwar aus der selben Welt, es gibt aber in Windows kein zentrales Directory (wie unter Novell), das die Informationen von ACE’s und Accounts zusammenführt. (Wie schön war die Zeit mit Novell 😉
Es gibt technische und regulatorische Anforderungen, die die Administratoren zu Lösungen (Workarounds) gezwungen haben, um diese zu erfüllen.
Probleme/Herausforderungen/Aspekte bei der Verwaltung von ACL mit NTFS Filesystem
- Reporting/Nachvollziehbarkeit -> Gruppen helfen nicht wirklich
Wie findet man heraus, wo überall eine Gruppe/User im Filesystem berechtigt sind, wenn man kein Tool hat, dass diese Informationen in einer Datenbank auslesen kann.
Da kam mal jemand auf eine pfiffige Idee, und erstellte Gruppen, die im Name den Verzeichnisnamen und auch das Recht enthalten, dass durch die Gruppe repräsentiert wird. Eigentlich ein schlaue Idee. Hat leider nur den Nachteil, dass die Gruppen nicht automatisch nachgepflegt oder gelöscht werden, wenn sie der Pfad ändert oder Verzeichnisse sogar gelöscht werden. Dies führt nach einer gewissen Zeit zu erheblichen Diskrepanzen zum IST im System. Dieser Ansatz taugt also nicht wirklich. - Geschwindigkeit beim Setzen von Rechten -> Nutzen Sie Gruppe, wo immer Sie können!
Dies ist ein legitimer Grund um Gruppen für Berechtigungen zu nutzen. Diese werden einmal in einer ACL eingetragen. Ändern sich die berechtigten Accounts, dann werden nur die Mitglieder der Gruppe im AD angepasst. Dies geht schnell und wirkt direkt nach einer neuen Anmeldung der betroffenen Accounts am Rechner. - Kerberos Tokensize/Tokencount -> Gehen Sie vorsichtig mit Gruppen um!
Es gibt Umgebungen, in denen wiederholt immer wieder die selben Accounts auf identische Verzeichnisse zugreifen müssen.
Z.B. wenn ein Unternehmen sehr stark in Projekten(-Verzeichnissen) arbeitet, die hochgradig standardisiert sind.
\Projekt 1 <- Zugriff für Projektleitung
->\Tischler <- Zugriff für alle Tischler
->\Einkauf <- Zugriff für alle Einkäufer
->\xxx <- Zugriff für Rolle X
In diesen Fällen kann es sehr schnell zu Kerberos Token Probleme führen, wenn man hunderte solcher Verzeichnisse besitzt und man mit Berechtigungsgruppen arbeiten würde. Der Kerberos Token Count ist hart limitiert auf maximal 1015 Gruppenmitgliedschaften. Diese können in solchen Konstellationen sehr schnell erreicht werden. User können sich dann nicht mehr an ihren Rechnern anmelden.
Kombinationen von Rollen und Berechtigungsgruppen
Wofür steht AGDLP:
- A: Benutzer- oder Computerkonto (engl. account),
- G: Globale Gruppe,
- DL: Domänenlokale Gruppe,
- P: Berechtigung (engl. permission; z.B. Eintrag in ACL).
Um die unterschiedlichen Kombinaten besser aufzeigen zu können, möchte ich dies gern übersetzen. So wird aus dem AGDLP ein A-RG-BG-P
- A: Benutzer- oder Computerkonto (engl. account),
- RG: Rollen Gruppe (Enthält alle User Accounts aus einer bestimmten Einheit oder mit einer bestimmten Funktionsrolle im Unternehmen)
- BG: Berechtigungsgruppe (Domänen Lokal/Global/Universell))
- P: Berechtigung (engl. permission; z.B. Eintrag in ACL).
Die verschiedenen Methoden für die Vergabe von Berechtigungen
| Modus | Account | RG | BG | P | Einsatz |
|---|---|---|---|---|---|
| Org-Modus | X | X | X | X | in Verzeichnissen die wie eine Abteilung heißen; Mitglieder werden autom. durch IAM verwaltet. |
| Projekt-Modus | X | X | X | sehr viele identische Konstellationen. indivduelle BG würden den Token sprengen. Verwaltung wird durch Owner(Projektleiter) übernommen. | |
| Austausch-Modus | X | (X) | X | Verzeichnisse werden nur kurzfristig genutzt aber mit sauberen Rechten versehen. Dann aber z. B. nach wenigen Tagen wieder gelöscht. Gruppen machen keinen Sinn. | |
| Prozess-Modus | X | X | X | Die Mitspieler im Prozess sind meist über organisatorischen Einheiten hinweg verteilt. Die Verwendung von Rollen ist nicht zielführend. | |
Die Suche nach dem Korrektiv – Rollengruppen ja oder nein?
Die wesentlich Frage in diesem Spiel aber ist die Folgende:
„Wer sorgt dafür, dass etwas wieder weg kommt? Wer ist das Korrektiv?„.
Darum muss man sich maßgeblich Gedanken machen. Hin, geht immer irgendwie. Aber kein User wird die IT unter Druck setzen und mit dem Chef drohen, damit ihm ein Recht wieder entzogen wird. (Lach)
Es ergeben sich zwei Möglichkeiten für diese echte Herausforderung.
- Automatische Verwaltung von Berechtigungen über Rollen
Diese Methode ist erste Wahl, wenn die Rollen durch eine verlässliche Stelle gesteuert werden. Z.B. gibt ein führendes HR-System die Mitgliedschaft von Personen in organisatorischen Einheiten vor und über eine Schnittstelle oder ein IAM System werden die Mitglieder von Rollen (Gruppen) automatische korrekt gepflegt.
Korrektiv -> HR System - Verwaltung der Berechtigungen über Owner
Wenn es keinen Automatismus gibt, von dem man profitieren kann, muss eine Person mit der Aufgabe betraut werden, die eine Beziehung und ein Interesse an den Daten und korrekten Berechtigungen hat. Diese Person bekommt die Rolle des „Owner“ zugwiesen und übernimmt über geeignete Tools die Verwaltung der Berechtigung in eigener Verantwortung.
Die Praxis hat gezeigt, dass einen Nutzungsgrad von 40% – 60% erreicht wird. Der Trend geht klar zu mehr Flexibilität und übergreifenden Datenaustausch. Dieses wird vor allem durch den Self Service von migRaven.24/7 unterstützt.
Optimale Tiefe von vergebenen Berechtigungen
Diese Frage stellt sich immer wieder. In der Vergangenheit hat man regelmäßig auf Anforderung explizite Berechtigungen auch in tieferen Ebenen vergeben müssen. Über die Jahre wirft diese Praxis eine Vielzahl von Probleme auf, die hier nicht näher benannt werden müssen.
Struktur selbst ist meist die Wurzel des Übels. Man kommt immer am besten zurecht, wenn die Objekte, die relevant sind in einem Verzeichnis findet und gar nicht erst in einer Struktur danach suchen muss. Das spart Zeit und Kosten. Aber leider sieht die Realität anders aus. Viele Verzeichnisbäume beinhalten oft mehrere tausend Dateien pro Mitarbeiter. So wie in den letzten Jahren die Anzahl der Objekte gewachsen sind, wird dies auch in den nächsten Jahren passieren. Diese Spirale muss man verlassen -> migRaven Data Retention bietet hier die richtige Lösung
Optimum ist, wenn man Berechtigungen nur auf der ersten Ebene benötigt. Das erreicht man aber nur, wenn Strukturen aufgebrochen werden. Man muss genau schauen, warum man überhaupt Berechtigungen in tieferen Ebenen benötigt. Meist ist dies der Fall, wenn man Verzeichnisse hat, die nach einem Organigramm gestaltet sind und sich dann darin Prozess-, Projekt- oder Austauschverzeichnisse befinden. Es wird nun sehr einfach, wenn man Grundstrukturen aufbaut, die von Anfang an eine saubere Trennung ermöglicht. Um die vorhandenen Strukturen aufzubrechen, sollten
- alle obsoleten Daten/Berechtigungen identifiziert und eliminiert werden
- Projekt-, Prozess- und Austauschverzeichnisse separiert werden
- restlichen Verzeichnisstrukturen flacher gestaltet werden
- dafür gesorgt werden, dass es auch so gelebt wird.
Optimale Verzeichnisstruktur aufbauen
Organisation oder Team-Verzeichnisse: angelehnt an das Organigramm, aber auf keinen Fall so strukturiert. Alle Einheiten sollten sich parallel auf der ersten Ebene befinden! Unbedingt ABE aktivieren, damit der User nur die Verzeichnisse sieht, auf die er auch berechtigt ist. Vorteil: Die Berechtigungen können bei einer sauberen Auslegung und Einsatz eines IAM Systems vollautomatisch administriert werden.
Prozess, Projektverzeichnisse: nehmen direkt flach alle Projekte oder Prozesse auf. Verwaltet werden diese durch den Owner direkt über den Self Service von migRaven.
Austauschverzeichnisse: Werden flach durch migRaven.24/7 Self Service erstellt und durch den Owner verwaltet. Empfohlen wird eine automatische Löschung dieser Verzeichnisse nach kurzer Zeit. Z.B. nach 7 Tagen. User werden immer direkt berechtigt. Die Verwaltung kann direkt über migRaven.24/7 abgebildet werden.
Public Folder: Besonderheit in diesem Fall ist, dass viele User die Informationen lesen, aber nur wenige die Daten verwalten können.
Applikationsverzeichnisse: Software Applikationen lesen oder schreiben Daten in diese Verzeichnisse. Viele Verzeichnisse konnten in den letzten Jahren nicht umbenannt werden, weil die Abhängigkeiten zu hoch waren und sich niemand getraut hat.
In allen Konstellation ist es wichtig, dass man dafür sorgt, dass Daten auch wieder die Strukturen verlassen müssen. Fileserver dürfen nicht wie aufquellen Sackgassen genutzt werden. Vielmehr wir eine Röhre, aus der am Ende die ältesten Daten wieder austreten, wenn sie nicht mehr genutzt werden.
Konsequenz
Man hört oft, dass es EIN Best-Practice für die Vergabe von Berechtigungen oder Strukturen gibt. Das kann ich so aus vielen Jahren Erfahrung nicht bestätigen. Es gibt immer wieder ganz unterschiedliche Anforderungen und man muss dann nach besten Lösung für die Anforderung suchen. Jeder unserer Kunden hatte bisher ganz eigene Anforderungen die meist in ganz spezifischen Lösungen geendet haben. Lassen Sie sich durch einen unserer Partner beraten.
