DV Konzept - Berechtigungskonzept

Das Berechtigungskonzept ist ein zentraler Bestandteil der Sicherheitsstrategie innerhalb eines Softwareprojekts. Es definiert, wie die Zugriffsrechte und Benutzerberechtigungen im System vergeben und getestet werden. Ziel ist es, sicherzustellen, dass nur autorisierte Nutzer Zugang zu bestimmten Daten und Funktionen haben, und dass die Sicherheitsanforderungen effektiv umgesetzt und eingehalten werden.

In einem Unternehmen sind grundsätzlich die Informationen und IT Systeme zu schützen, deren Kenntnis bzw. Zugang einem Wettbewerber oder einem Unberechtigten Vorteile materieller oder immaterieller Art verschaffen oder deren freie Nutzung der Unternehmung schaden könnte.

Verstöße im Bereich des Berechtigungsmanagements können zu schwerwiegenden Beeinträchtigungen der Ordnungsmäßigkeit, zu immensen finanziellen Schäden und Reputationsschäden führen.

Ein Berechtigungskonzept eines IT Systems bildet die zentrale Grundlage für die Beschreibung aller Rollen und Kompetenzen sowie aller berechtigungsspezifischen Prozesse.

Die Zuständigkeit für die Definition und Kontrolle der Berechtigungskonzepte in den Fachanwendungen obliegt in der Regel dem Business Architekt.

Wesentliche Aufgaben eines Berechtigungskonzeptes
»	Definition und Pflege fachliche / administrative Zugangsberechtigungen (z.B. mittels eines Rollen Konzeptes)
»	Definition eines rollenbasierten Rechtekonzeptes für den Zugriff auf eine Systemanwendung
»	Regelmäßige Prüfung von Berechtigungen bezüglich weiterbestehender Erforderlichkeit

Die Dokumentation eines Berechtigungskonzeptes enthält elementar auch eine Berechtigungen-Matrix sowie einen Systemrollen Steckbrief.

Zielsetzung des Berechtigungskonzepts

Definition der Berechtigungsrollen
Festlegen der verschiedenen Benutzerrollen und der damit verbundenen Rechte und Privilegien.
Sicherstellung der Datensicherheit
Gewährleistung, dass der Zugriff auf sensible Informationen und kritische Systemfunktionen streng kontrolliert wird.
Überprüfung der Implementierung
Sicherstellen, dass die technische Umsetzung der Berechtigungsregeln den fachlichen Vorgaben entspricht.

Wesentliche Ziele eines Berechtigungskonzeptes
»	Definition der notwendigen Rollen und Rechte für die Anwendung
»	Erstellung Antragsprozess für den Zugriff auf Systeme
»	Übergabe der Einrichtung, Änderung und Löschung von Berechtigung und Usern

Technische Elemente in einem Rollenkonzept sollten im Detail beschrieben werden. Entscheidend ist hierbei, dass alle Elemente die zur Modellierung des Berechtigungskonzeptes benötigt werden in ihren Zusammenhängen und Eigenschaften (Funktionen und Ausprägungen) erläutert werden.

Da Systeme in der Regel unterschiedlich konfiguriert sind, müssen sie sich im Berechtigungskonzept zwecks Differenzierung wiederfinden. In einer Rollenbeschreibung muss von daher auch dargestellt werden, wie mit umfangreichen administrativen (zu schützenden) Rechten, vor allem für das Produktivsystem, umgegangen wird.

Werden durch Prozesse Zugriffe auf Fremdsysteme durchgeführt oder wird in bestimmten Prozessen auf das zu schützende System zugegriffen, muss in einem Berechtigungskonzept beschrieben werden, wie diese Zugriffe gesteuert werden und wie der Schutz des Systems gewährleistet ist. Es muss unter anderem eindeutig hervor gehen, dass der Schutz - den das erstellte Berechtigungskonzept errichtet - nicht durch andere Zugriffe umgangen werden kann.

Der Nutzen eines Berechtigungskonzeptes
»	Geregeltes, ordnungsmäßiges Verfahren

Da auch alle Aktivitäten im System zu protokollieren sind, müssen nicht personalisierte Benutzer nach dem Identitätsprinzip jemandem persönlich zugeordnet sein. Ein Berechtigungskonzept hat somit sicher zu stellen, dass es in einem System keinem anonymen Benutzer gibt.

Des Weiteren sollte dargestellt werden, inwieweit sich die Systemlandschaft in dem Berechtigungskonzept widerspiegelt und welche Berechtigungen nur (uns warum) für die Entwicklungssysteme eingerichtet sind.

Grundsätzlich empfiehlt es sich für Systemrollen eine Namenskonvention zu wählen, die anhand von Schlüsselfeldern deren Funktion, Aufbau, Ausprägung, Benutzergruppen und Zuordnungen erkennen lassen. In einem Systemrollenregister können die detaillierten Informationen zu den Systemrollen aufgeführt (u.a. Zuordnung von Business Function zu den Systemrollen) werden.

Grundsätzliche Struktur und Themen eines Berechtigungskonzeptes

Geltungsbereich
»		Organisationseinheiten/ Rechtseinheiten
Grundlagen
»		Um was für ein System handelt es sich (Eigenentwicklung, Hersteller Software usw)?, Hat es Module (Welche werden genutzt)?, Wer nutzt diese Applikation (alle Fachbereiche, nur einige)?Wer sind die verantwortlichen Architekten? usw.
»		Referenzieren auf Dokumente
Ziele
»		Darstellung der applikationsübergreifenden Konzeption
»		Umsetzung der Berechtigungen
Grundsätzliche Vorgaben/ Leitprinzipien
»		Verbindlichen Leitlinien und Prinzipien des Unternehmens, z.B.
			Identitätsprinzip	Das Identitätsprinzip gewährleistet die eindeutige und jederzeitige Zuordnung jedes Benutzers zu einer Identität, also der IT technischen Abbildung einer Person.
			Minimalprinzip	Wird das Minimalprinzip nur für die Arbeit notwendigen Funktionen durch entsprechend minimale Berechtigungen gewährleistet?
			Prinzip der Business Roles	Sind die Businessrollen mit den notwendigen Funktionen die Grundlage für die Definition der Berechtigungen? Liegt eine Matrix vor?
			Eigenverantwortungsprinzip	Die Business und Applikationsarchitekten sind gleichermaßen eigenverantwortlich für die Erstellung und Pflege des Berechtigungskonzeptes.
			Belegprinzip	Hier ist darzustellen wie Änderungen an Rechte und Benutzer protokolliert werden
			Funktionstrennungsprinzip	Die Notwendigkeit einer zwingenden Aufgabentrennung in beteiligten Prozessen ist zu analysieren und ggf. zu definieren, damit ein Mitarbeiter nicht allein den gesamten Prozess bearbeiten kann (Gefahr des Kontrollverlustes).
			Genehmigungsprinzip	Sämtliche Beantragungen von Berechtigungen in jedweder Form müssen nachvollziehbar genehmigt werden.
			Schriftformprinzip	Ein Berechtigungskonzept muss in einer schriftlichen, genehmigten Fassung vorliegen. Ein sachkundiger Dritter muss in der Lage sein, in angemessener Zeit Auskunft über die Nutzung von Berechtigungen sowie über die Umsetzung normativer Grundlagen und der technischen Realisierung zu erhalten.
			Kontrollprinzip	Die Umsetzung des Berechtigungskonzeptes muss für eine dritte Person nachvollziehbar/verständlich sein und durch einen neutralen Prüfe, von einer internen Revision und Wirtschaftsprüfer überprüft werden können
»		Beachtung übergreifenden Richtlinien als Mindestanforderung (z.B. OHB Reglungen)
		Informationen zur Schutzbedarfsanalyse Kompensierende Kontrollen bei vorliegenden Funktionstrennungskonflikten
Schutz von Funktionen
Schutz des Systems
»		Änderungsbelege
		Die Berechtigung zum Löschen von Änderungsbelegen ist gesetzeswidrig und muss auf allen Systemen unterbunden werden, d.h. es darf in keiner Systemrolle vorhanden sein.
»		Systemparameter
		Systemparameter sind grundsätzlich zu schützen, damit nicht jeder diese verändern kann
»		Programmcode/ Programmen / Reportausführung
		Grundsätzlich sollten Programmcode/Programme und Reports nicht durch jeden veränderbar sein.
»		Tabellen in Datenbanken
		Grundsätzlich sollten Tabellen nicht durch jeden veränderbar sein.
»		Customizing
		In welcher Systemumgebung (Produktiv oder Test) werden technische Customizing Einstellungen durchgeführt und wie sind die Berechtigungen dazu aufgebaut?
»		Transporte
		Wie kommen Änderungen von Testsystemen in die Produktivsysteme? Gibt es ein Transportwesen von Änderungen aus der Testlandschaft in die Produktion? Werden Änderungen direkt eingestellt ohne Transport?
»		Debug Rechte
		Gibt es Debug Rechte in Produktion? Wer darf debuggen?
»		Remote Function Call Verbindungen
»		Zugriff auf Dateien im Betriebssystem
»		Ex- und Import von Daten aus / in Systeme
»		Pflege Kalender, Nummernkreise etc.
Schutz von Elementen aus der Berechtigungsadministration
»		Systemrollen
»		Sprache
»		Prüftabelle Prüfung Berechtigungsobjekte
»		Upgrade- Arbeiten Berechtigungen
»		Organisationsebenen in Systemrollen
»		Berechtigungsobjekte
»		Rollen (Sortenreinheit Einzelrolle und Sammelrollen
	Schutz von Elemente in der Benutzeradministration
	Schutz vor Datenzugriffen
	Strukturierungselemente für Systemrollen
Technologie
»		Transaktionscode
		Der Transaktionscode steht prinzipiell am Beginn jeder Aktivität im System. Die erste Berechtigungsprüfung ist die auf die Ausführberechtigung des Transaktionscodes.
»		Berechtigungsobjekt und Berechtigung
		Alle Standard Aktivitäten und alle kundeneigenen Aktivitäten im System sind über Berechtigungsobjekte zu steuern; Ausnahmen sind prozessuale Dunkelverarbeitungen, die maschinell bedient werden Jede Berechtigung basiert auf einem Berechtigungsobjekt. Die Berechtigungsobjekte und ihre Beziehungen zu Handlungen und Handlungsabläufen, die im System ausgeübt werden, sind vorgegeben und bleiben in der Regel unverändert. Falls eine Änderung oder Ausschaltung von Standard Berechtigungsprüfungen notwendig ist, ist diese Abweichung im jeweiligen applikationsspezifischen Berechtigungskonzept zu dokumentieren. Bestimmte Handlungsabläufe im System erfordern eine Prüfung von mehreren Objekten hintereinander. Objekte sind in Objektklassen unterteilt, welche sich an den Modulen orientieren. Alle Objekte bieten unterschiedliche Möglichkeiten auf Aktivitäten, Berechtigungsgruppen etc. einzugrenzen. Das Feld ist Teil des Berechtigungsobjektes, kleinstes Element in einem Berechtigungskonzept, und in der Form normalerweise von SAP vorgegeben. Die Felder sind in jedem Berechtigungsobjekt anders, es gibt wiederkehrende Felder wie „Aktivität“, die in fast allen Berechtigungsobjekten auftauchen. Ein Feld kann in mehreren Objekten verwendet werden. Durch die Ausprägung eines Berechtigungsobjektes mit Feldwerten entsteht eine Berechtigung. Die Berechtigung wiederum ist in das Profil der Einzelrolle eingebettet. Grundsätzlich darf kein Feld der aktiven Berechtigungsobjekte leer sein.
»		Organisationsebenen
		Betriebswirtschaftliche Elemente wie Buchungskreis, die über die Einrichtung des Berechtigungskonzepts besonders zu schützen sind.
»		Einzelrolle / Systemrolle
		Der technische Name einer Einzelrolle folgt im Minimum der im Weiteren dargestellten Namenskonvention. Eine applikationsspezifische Namenskonvention, die über diese übergreifende Namenskonvention hinausgeht, ist in dem jeweiligen Konzept darzustellen. Die Rollenbeschreibung enthält folgende Information in nachvollziehbarer, kurzer Form: - Die Nennung des Erstellers und des Erstellungsdatums - Technischer Funktionsumfang der Systemrolle - Einsatzort der Systemrolle - Nennung der Business Function des Domänenmodells Des Weiteren können verschiedene Systemrollen Typen wie z.B. Master Rolle, Basis Rolle etc. vorhanden sein.
»		Auswirkungen auf andere Systeme [Entwicklungs- und Produktionssystem]
		Da die Systeme unterschiedlich konfiguriert sind, muss sich das im Berechtigungskonzept niederschlagen. Diese Differenzierung muss beschrieben werden. Hier oder in der Rollenbeschreibung muss auch auseinandergesetzt werden, wie mit umfangreichen administrativen (zu schützenden) Rechten vor allem für das Produktivsystem umgegangen wird und in welcher Form sich das im Rollenkonzept niederschlägt.
»		Fremdsysteme, Schnittstellen, externe Datenbanken
		Werden durch Prozesse Zugriffe auf Fremdsysteme durchgeführt, oder wird in bestimmten Prozessen auf das zu schützende System zugegriffen, muss beschrieben werden, wie diese Zugriffe gesteuert werden und wie der Schutz des Systems gewährleistet ist. Das gleiche gilt für Kommunikation mit Systemen, z. B. über Schnittstellen. Diese Konzeption ist zu beschreiben oder auf ein entsprechendes Dokument zu verweisen. Es muss eindeutig hervor gehen, dass der Schutz, den das erstellte Berechtigungskonzept errichtet, nicht durch Zugriffe umgangen werden kann, z. B. über einen Portalzugang.
Rollenkonzeption
»		Business Function
		Eine Business Function ist die maßgebende Einheit für die Systemrolle, die sich an Prozessen und Prozessschritten orientiert. Sie umfasst eine Aktivität oder bündelt Aktivitäten, aus betriebswirtschaftlicher Sicht. Technisch gesehen kann sich eine Business Function aus mehreren Transaktionen zusammensetzen. Sind in der Definition von Business Function Transaktionscodes aus mehreren Applikationen vorhanden, wird zugunsten der Sortenreinheit die Business Function auf ein oder mehrere Systemrollen verteilt.
»		Systemrolle
		Eine Systemrolle enthält genau eine Business Function aus einer Applikation. Die Systemrolle kann einen oder mehrere Transaktionscodes beinhalten. Die Zuschnittparameter Business Function und Constraint bestimmen den Umfang und auch den Typ der Systemrolle. Die Ausprägung der Berechtigungsobjekte richtet sich nach der Kombination dieser Parameter.
»		Modellierung Systemrolle
»		Dokumentation Rollen mit applikationsübergreifenden Transaktionen
Benutzerverwaltung / Rollenmanagement
»		Prozesse
		Prozesse zur Benutzerverwaltung und zum Rollenmanagement
»		Benutzer
		Konfiguration der Benutzer mit originärer und anonymer (u.a. Auslieferungsuser) Kennung
Systemlandschaft
Namenskonvention
	Systemrollen
»		Neue Rolle
		Kennzeichnung der Rolle, dass sie unter den Bedingungen, die mit dem Projekt definiert wurden, erstellt wurde
»		Landesspezifischer Gültigkeitsbereich
		Kennzeichnung des Gültigkeitsbereichs über Länderkürzel
»		Systemtechnische Klassifizierung
		Die Kürzel lehnen sich in erster Linie an der Technologie und die dort benutzten Kürzel an. Hierbei ist erst das Modul zu nennen und dann die Applikation. Handelt es sich um eine kundeneigene Entwicklungen ist hier das im Unternehmen gängige Kürzel zu verwenden
»		Trennkennziffer
		Kennzeichnen das Ende einer technischen Klassifizierung, das Ende der funktionalen Klassifizierung, das Ende der organisatorischen Klassifizierung und das Ende der fixen Stellen sowie trennen den allgemeinen systemübergreifenden Namensteil von dem spezifischen fachorientierten Namensteil
»		Funktionale Gliederung
		Kennzeichnet die Rolle im Gefüge der Benutzergruppen
»		Funktionsart
		Kennzeichnet grob den Risikogehalt der Rolle durch Spezifizierung der Zugriffsart
»		Staging
		Kennzeichnet, auf welchem System der Systemlandschaft die Rolle benutzt wird
»		Business Function
		Kennzeichnet die im Rahmen des Projektes festgelegten Kürzel für Business Function
»		Systemrollen Typ
		Kennzeichnet die Funktion der Rolle in der Vergabe
»		Laufende Nummerierung
		Laufende Nummer, je nach Land und Systemrollen Typ
	Namenskonvention für Benutzer
»		Namenskonvention für Anonyme User (in Projekten) und sonstige Elemente
»		Berechtigungsgruppen für Programme
»		Berechtigungsgruppen für Tabellen
Anhang
»		Systemrollenregister
		Darstellung Systemrollen mit applikationsübergreifenden Transaktionen
»		Übersicht Applikationen Systemlinie
		Tabelle mit den Spalten Applikation lang/ Cluster
»		Übersicht Technisches Rollenkonzept
		Rollenmatrixen der Systemrollen mit applikationsübergreifenden Transaktionen

Exkurs: Berechtigungstests

Inhaltlich

Teststrategie für Berechtigungen
Beschreibung der Methodik und der spezifischen Tests, die durchgeführt werden, um die Korrektheit der Berechtigungen zu überprüfen.
Vorgehensweise in den Testphasen
Detaillierte Beschreibung der Prozesse und Maßnahmen in den verschiedenen Testphasen, von der initialen Einrichtung der Testumgebung bis zur finalen Überprüfung der Berechtigungen.

Durchführung der Berechtigungstests

Planungsphase
- Erstellung eines detaillierten Plans, der angibt, welche Berechtigungen für welche Rollen getestet werden.
- Festlegung der Kriterien und Bedingungen, unter denen die Tests durchgeführt werden.
Einrichtung der Testumgebung
- Konfiguration der Testumgebung mit den entsprechenden Benutzerrollen und Berechtigungen.
- Sicherstellung, dass die Testumgebung die Produktionsumgebung hinsichtlich der Berechtigungsstrukturen genau widerspiegelt.
Ausführung der Tests
- Durchführung von Tests, die überprüfen, ob die Zugriffsrechte gemäß den festgelegten Sicherheitsrichtlinien korrekt implementiert sind.
- Überprüfung, ob unautorisierte Zugriffe erfolgreich blockiert werden und ob autorisierte Zugriffe entsprechend ermöglicht werden.
Analyse und Dokumentation der Ergebnisse
- Dokumentation der Testergebnisse, einschließlich aller festgestellten Sicherheitslücken oder Abweichungen von den Berechtigungsvorgaben.
- Analyse der Ergebnisse, um zu bestimmen, ob weitere Anpassungen der Berechtigungen oder der Sicherheitsstrategie erforderlich sind.

Nachbereitung

Überarbeitung der Berechtigungsstrategie
Anpassung der Berechtigungsregeln basierend auf den Ergebnissen der Tests.
Abschließende Bewertung
Eine finale Überprüfung, um sicherzustellen, dass alle Berechtigungen korrekt umgesetzt und getestet wurden.