Gruppenverschachtelung – Ressourcen – Funktion – Rollen und warum Sie davon nur profitieren können

In diesem Artikel geht es um das “Warum” eine Gruppenschachtelung sinnvoll, aber manchmal doch auch unsinnig ist.

Hier erkläre ich die Details warum ein Rollenkonzept auf dieser Basis dienlich ist, und warum ab und zu die dadurch entstehende Komplexität manchmal nicht sinnvoll ist.

Gruppierung der Infrastruktur Komponenten

Einleitung

Es gibt viele Gründe AD Gruppen zu verschachteln. Die einen nennen es Rollenkonzept. Die anderen nennen es Sicherheitszonen. Schlussendlich können diese aus meiner Erfahrung heraus fast immer auf die Themen “Vertrauen”, “Fähigkeiten” und “Wissen” heruntergebrochen werden.

  • Vertraust du deinem Co-Admin?
    • Gibt es immer gute Tage, oder kann auch mal was schief gehen?
    • Hat er das notwendige Wissen aktuell und präsent?
  • Weißt du als Chef, was deine Administratoren machen?
    • Hat jeder die gleichen Fähigkeiten und Rechte?
  • Können alle Ihren Job gleich gut?
    • Gibt es Qualitätsunterschiede, andere Zeitliche Abläufe und Resultate?
  • Wie argumentierst du in einem Überwachungsaudit auf Sicherheitsrelevante Vorfälle?
  • Wie werden IT-Services aus deinem Portfolio strukturiert?
    • On Demand oder basierend auf Abteilungsebene?

Aus diesen Kernfragen lässt sich (auch wenn viele Auftraggeber es zunächst nicht hören wollen) schnell ableiten, warum ein Rollenkonzept mit verschachtelten Gruppen und ggf. unter Zuhilfenahme von zusätzlichen Benutzerkonten für die gleichen Personen, in unterschiedlichen Funktionsrollen, sinnvoll ist.

Mit einer Status Quo Feststellung schneller zum Individuellen Rollenmodell

Einige Ansätze und Gründe versprechen oft mehr als andere. So verhält es sich auch häufig mit vorbereiteten Rollenmodellen, welche über Berater, Dienstleister oder “weil es schon immer so gemacht wurde”.

Schlussendlich wird das fertige und zum Einsatz kommende Administrative Rollenmodell und die Dauer bis zur Umsetzung darüber entscheiden, wie gut dieses in IT-Abteilungen ankommt und Anklang findet. In Vorgesprächen lässt sich dies häufig durch drei kleine Meetings identifizieren und so bares Geld sparen.

Bestehende Gruppen und Rollenmodelle identifizieren

Eine Review der aktuellen Unternehmensstruktur als auch die der IT-Infrastruktur hilft dabei aktuelle Defizite, als auch die Arbeitsweise der Systemadministration aufzudecken und so aufzuzeigen wo Schwachstellen als auch zusätzliche bisher unbeachtete “schwarze Flecken” der Systemadministration, im Verhältnis zum Organisationsdiagramm, versteckst sein könnten.

Eine genaue Betrachtung der Eingliederungsprozesse hilft dabei die möglichen Potentiale durch ein Rollen und Rechtemodell aufzuzeigen. Die gleiche Betrachtung sollte bei Personalverschiebungen innerhalb des Unternehmens geschehen.

Top Down oder Bottom Up Ansatz

Wenn bisher keine klare Linie in den Administrativen Strukturen vorliegt, kann mit diesen beiden Ansätzen das Ziel einer fertigen Gruppenstruktur erreicht werden.

Hierbei wird von “oben” das Organigramm in Richtung der IT-Administration oder in der Rückwärtsvariante die Systemlandschaft zum Organigramm nach einem möglichen Gruppenmodell betrachtet.

Rollenmodelle für Benutzer, Administratoren und Systeme

Mehrdeutigkeit des Begriffs “Rolle”

Die deutsche Sprache ist eine Waffe. So ist es erfahrungsgemäß auch beim Begriff einer “Rolle”. Es kann falsch verstanden werden.

Die zwei häufigsten Wahrnehmungen:

-> (Gruppen-)Rolle im administrierten System – auf Ressource schauend

-> Rolle im genutzten Service – auf die Serviceleistung schauend

Diese Mehrdeutigkeit entsteht meist aus den unterschiedlichen Blickwinkeln/Perspektiven/Verständnissen der Gesprächsteilnehmer. Die nachfolgenden Beispiele demonstrieren das anschaulich:

Blickwinkel eines Administrators auf “Rolle” (Rolle im administrierten System – auf Ressource)

Administrative Rolle(n)ServernameFunktion/ServiceZugewiesene Ressourcen Gruppe für Service od. Rolle
Exchange-Admin Exchange-Support Exchange-User Exchange-AuditorExchange01Exchange ServerRes_EXCH_Admin Res_EXCH_Support Res_EXCH_User Res_EXCH_Auditor
Smtpgw-Admin Smtpgw-SupportSMTPGW01E-Mail GatewayRes_SMTP_Admin Res_SMTP_Support
AdminnetworksolutionsDomain RegistrarRes_NetSol_Admin
Dataroom-Admin Dataroom-AuditorDatenraum01Datenaustauschplattform (intern + extern)Res_DataRoom_Admin Res_DataRoom_Auditor

Blickwinkel eines Vorgesetzten oder Unternehmers auf “Rolle” (Rolle im genutzten Service – auf Serviceleistung)

RolleRollengruppenZugewiesene Ressourcen Gruppe für Service od. Rolle
E-Mail AdministratorROL_MailAdminRes_EXCH_Admin Res_SMTP_Admin Res_NetSol_Admin Res_SAP_ConfigAdmin
Groupware AdministratorROL_GroupwareAdminRes_EXCH_Admin Res_SMTP_Admin Res_NetSol_Admin Res_DataRoom_Admin
Interner/externer AuditorROL_AuditorRes_EXCH_Auditor Res_DataRoom_Auditor

Damit Missverständnisse beim Aufbau und der Kommunikation im Unternehmen erst gar nicht auftreten, hilft es zeitnah mittels einer Legende oder Definition, regelmäßig passend nach zu justieren.

Mit einer Klarstellung der Blickweise, entstehen so im Projekt auch weniger Missverständnisse und Wiederstände.

Funktionsgruppen als Bindeglied und Vermittler

Das Bindeglied der Sichtweisen kann die Funktionsgruppe darstellen. Je nach Ausgestaltung des anzubietenden Services können hier beide Sichtweisen auf eine “Rolle” vereint werden.

Die Rolle aus Service Sicht als auch aus der administrativen Systembetrachtung.

Bindeglied zwischen Rolle und Rolle – die Funktionsgruppe:

RollengruppenFunktionsgruppenRessourcengruppen
ROL_MailAdminFunc_MailAdminRes_EXCH_Admin Res_SMTP_Admin Res_NetSol_Admin Res_SAP_ConfigAdmin
ROL_GroupwareAdminFunc_GroupwareAdminRes_EXCH_Admin Res_SMTP_Admin Res_NetSol_Admin Res_DataRoom_Admin
ROL_AuditorFunc_GroupwareAuditorRes_EXCH_Auditor Res_DataRoom_Auditor

Kurze Randnotiz: JA, das funktioniert auch mit Diensten in AWS, Google Cloud und AZURE.

Ergebnisbetrachtung für Gruppen und Services

Das Ergebnis kann sich in vielen Fällen sehr gut sehen lassen und ermöglicht mit einer passenden Dokumentation, einen schnellen Einstieg in das Gesamtverständnis, wie die IT Abteilung mit dem Unternehmen harmonisiert wurde.

Organigramm mit IT Komponenten nach SOA

Services und Risikobetrachtung

Die Systemarchitektur der notwendigen Services kann aus den zuvor strukturierten Gruppen abgeleitet werden. Die Daraus entstehenden Service-Cluster sehen in einer Risikobetrachtung bereits im Ansatz wie eine technische System und Netzwerksegmentierung aus.

Dem BSI Grundschutzkatalog folgend können daraus vollständige Netzwerksegmente als auch Zugriffsgruppen herausgearbeitet werden, was einer Risikobetrachtung mit möglichen Angriffsszenarien und Übergriffen zwischen Systemen positiv entgegenkommt.

Maßnahmen zur Netzwerkabschottung, Viren- und Würmer können so recht einfach ein- und umgesetzt werden.

Betrachtung Regelbetrieb vs. Auditierung vs. Risikomanagement

Alles in allem sehen diese Strukturen für Außenstehende meist sehr komplex aus. Das sind Sie bei genauer Betrachtung aber gar nicht.

Aus der Sicht des IT-Regelbetriebs entwickeln diese Vorgaben bereits in der Test- und späteren Produktivphase eine klare Linie der Berechtigungsstrukturen und ermöglichen es Netzwerkarchitekten einen passenden Aufbau zum Schutz von Infrastrukturen aufzubauen. Das mehr an zusätzlicher Strukturarbeit beim Aufbau dieser, wird spätestens im Produktivbetrieb zeitlich wieder reingeholt, wenn zusätzliche Rechte im System, neue Rollen im Unternehmen oder gar eine Unternehmensrestrukturierung oder Modulerweiterungen notwendig ist.

Schlussendlich wird beim Mitarbeiter Ein- und Austritt, durch ein definiertes Rollenmodell, die Komplexität der Benutzerberechtigungen und damit die Entscheidung für Systemrechte sowohl für den Vorgesetzten, als auch in der Systemadministration (z.B. bei der Benutzeranlage) deutlich vereinfacht.

Im Bereich der Auditierung, wo klare Strukturen und Regelungen notwendig sind, spielen die auf Gruppen basierenden Rechte ihre Stärke aus. So können sehr schnell Auswertungen der persönlichen Rechte auf Modul oder Systemebene berichtet und dargestellt werden. Durch eine zusätzliche Änderungsverfolgung, können auch systematische nachvollziehbare Unternehmensprozesse dargestellt werden.

Im Risikomanagement zeigen sich weitere Stärken dieser Rollengliederung. Zum Beispiel können Mitarbeiter mit Einzelrechten oder eine mögliche Überforderung von einzelnen Rollen über Mitgliedschaften in den Gruppen zügig in die Personalplanung einbezogen werden. Auswirkungen von Ausfällen können Abteilungs- oder Produktspezifisch betrachtet und so auch in Krisenzeiten als fundierte Basis für Entscheidungen herangezogen werden.

Zusammenfassung

Das Warum und den aktuellen Status Quo des eigenen Unternehmens zu kennen, ist in fast allen Phasen und jedem Unternehmenszyklus ein wichtiger Bestandteil des unternehmerischen Handelns. Eine klare Struktur hilft Ihnen dabei zügig fundierte Entscheidungen zu treffen und zugleich neue und bestehende Strukturen, harmonisiert auf den Weg zu bringen. Gruppenstrukturen können auf diese Weise zeitnah umgesetzt und den Wandel des Unternehmens unterstützen ohne dabei einen erheblichen zusätzlichen Aufwand in der Systemadministration zu verursachen.

Haben Sie sich in den Herausforderungen oder Strukturen wiedergefunden oder Anregungen für Ihr Unternehmen und/oder Ihren IT-Betrieb holen können?

Über mich

Gregor Tomitzek – IT Berater, Coach und Mentor

Seit über 25 Jahren berate ich Firmen und private Personen in allen Belangen der Computertechnik. Als Leiter eines Infrastrukturteams bringe ich die technischen Anforderungen der Kunden zu Lösungen, und ermögliche dadurch ein besseres und schnelleres Arbeiten.

Durch meine langjährige Erfahrung, die Ausbindungen und der Nähe zu allen Unternehmensprozessen, unterstütze ich Leistungsträger, Teamleiter und Vorstände dabei, die Überlastung in IT-Abteilung zu senken und zugleich die Leistungsfähigkeit und Zufriedenheit von IT-Teams wahrnehmbar zu steigern.


Änderungshistorie

Erstellt: 2022-11-01Zuletzt geändert: 2022-11-01
Änderungshistorie:
2022-11-01: Basis – Layout + Text
2022-12-18: Textupdate
Änderungshistorie d. Artikels

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

19 − 15 =