DV Konzept - Berechtigungskonzept

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.

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

Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH

Hettwer UnternehmensBeratung

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung - Umsetzungsdienstleistungen im Finanzdienstleistungssektor – Experte im Projekt- und Interimsauftragsgeschäft - www.hettwer-beratung.de

H-UB ERFOLGSGESCHICHTE

Auszeichnung:

Gold-Partner-Zertifikat

Hettwer UnternehmensBeratung GmbH wurde aufgrund der erbrachten Beraterleistungen in den exklusiven Kreis der etengo Gold-Partner aufgenommen.

H-UB EXPERTENWISSEN

Hettwer UnternehmensBeratung GmbH – Expertenprofil Klaus Georg Hettwer (Geschäftsführer): Beratungskompetenz, Fachliche Kompetenz, Methodische Kompetenz, Soziale Kompetenz, Kommunikationskompetenz; Sonderthemen: SEPA, EMIR, TARGET2, MiFID, T2S

- Eine Beratung mit PROFIL -

H-UB Leistungskatalog

H-UB Leistungskatalog.pdf
Adobe Acrobat Dokument 89.4 KB

Projekt:

Hanseatische Container Logistik GmbH

Spedition, Logistik

Projekt:

WERDER BAU Bremen GmbH

Bauunternehmen

Projekt: Vino Bello

„La Dolce Vita“

 

H-UB SOCIAL MEDIA PRÄSENZ

© 2010-2024 Hettwer UnternehmensBeratung GmbH