Berechtigungskonzept

Anwendung X

 

Schutzbedarf               

Versionierung. 1

Rezertifizierung. 2

Anwendungsbeschreibung. 2

Verantwortlichkeiten. 2

Fachliche Verantwortung. 2

Technische Verantwortung. 2

Weitere Ansprechpartner. 3

Privilegierte Benutzer. 3

Berechtigungen. 4

IAM Rollen. 5

Funktionstrennungsmatrix. 6

 

 

 

Normal, Hoch, Sehr Hoch. Der Schutzbedarf ergibt sich aus der IT-Grundschutz-Methodik der BSI 200-2, Kapitel 7.5. Zur Feststellung des Schutzbedarfs folgendes Dokument lesen BSI - Bundesamt für Sicherheit in der Informationstechnik - BSI-Standard 200-2

 

 

Die Versionierung gilt der Übersicht aller Änderungen am Dokument. Dies verhindert Konflikte bei mehrfach Ablagen (Kopien) der Datei. Im Idealfall sollte man die Versionierung komplett über ein Workflow gesteuertes Dokumenten-Management-System durchführen.

Version	Datum	Name	Kommentar
1.0	24.12.2023	Maximilian Langel	Initiale Erstellung des Konzepts

Die Rezertifizierung ist wichtig für Dritte, die dieses Dokument überprüfen müssen. Zusätzlich zur Versionierung fordern viele Prüfer die regelmäßige Abnahme der Berechtigungskonzepte in fest definierter Zeitabständen (z.b. ein Jahr). Die Rezertifizierung kann nur von den fachlichen Hauptverantwortlichen ausgeführt werden. Sie bestätigen die Vollständigkeit und Aktualität aller Informationen im Dokument.

Version	Datum	Name	Kommentar
1.0	24.12.2023	Maximilian Langel	Abnahme der aktuellen Version. Bestätigung der Vollständigkeit aller Angaben.

 

 

Was macht die Anwendung X? In welchem Kontext wird sie im Unternehmen verwendet? Falls vorhanden Architektur Bild.

 

 

Es können ein oder mehrere fachliche oder technische Verantwortliche sowie weitere Ansprechpartner genannt werden. Für fachliche und technische Verantwortung muss mindestes eine Person definiert sein. Diese Informationen sind prüfungsrelevant und bindend.

 

Fachliche Verantwortung

 

Der fachlich Verantwortliche ist der Hauptansprechpartner der Anwendung X für die Themen Anforderungen, Tagesgeschäft und Incidents.

Name	Aufgabe	Kontakt
Maximilian Langel	Fachliche Verantwortung	maximilian.langel@companyx.com

Technische Verantwortung

 

Der technisch Verantwortliche ist der Ansprechpartner der Anwendung X für die Themen IT-Infrastruktur, Wartung und Weiterentwicklung.

Name	Aufgabe	Kontakt
Luise Mustermann	Technische Verantwortung	luise.mustermann@companyx.com

 

Weitere Ansprechpartner

 

 Personen die sich gut mit der Anwendung X auskennen aber keine klar definierte Verantwortlichkeit haben.

Name	Aufgabe	Kontakt
Alfred Mustermann	Entwickler	alfred.mustermann@dienstleisterx.com

 

Die Definition dient der Übersicht an „nicht-persönlichen“ Accounts. Privilegierte Benutzer müssen eindeutig identifizierbar sein. Diese Accounts werden meist von Maschine zu Maschine Kommunikation verwendet. Teilweise aber auch von „persönlichen“ Usern. Bei der Einführung eines PAM Systems hilft diese Information um die Anwendung X dort aufzunehmen. Die Spalte Berechtigungen hat nicht zwingend etwas mit den Berechtigungen der Anwendung X zu tun. Gemeint sind Berechtigungen im Kontext der Anwendung X (Server, Datenbanken, Betriebssysteme, Services). Beispiel:  Linux: „chmod“

 

Name	Typ	Berechtigungen	Hostname
DB-USER-AnwendungX	Datenbank	root	Localhost:3306

 

Eine Liste von Berechtigungen in der Anwendung X. Falls es verschiedene Typen von Berechtigungen gibt einfach untereinander schreiben und in der Beschreibung erwähnen. Oft haben Anwendungen bereits intern „Rollen“ gebaut, welche Rechte zusammenfassen zu einer Tätigkeit. In diesem Falle sollte die oberste Ebene in IAM aggregiert werden um unnötige Komplexität in Konzept und IAM System zu vermeiden. Die Details und deren Zusammensetzung einer Rolle kann man in der Beschreibung darstellen.

Empfehlung zum Owner: Die Pflege von Einzelpersonen als Owner ist mühsam. Definieren Sie Personengruppen anhand ihrer Tätigkeit oder ihrer Abteilung / Org-Einheit. Somit muss man die nur die Personengruppen pflegen. Beispiel: Berechtigungsmanagement (=Maximilian Langel, Luise Mustermann..).

 

Name	Owner	Beschreibung	Organisationseinheit	Kritikalität
Berechtigungsmanager	Berechtigungsmanagement	Der Berechtigungsmanager besitzt die Rechte um die Benutzer zu verwalten.	IT-Security	hoch
Schweiz Konten Schreibzugriff	Abteilungsleitung Banking	Veränderung von allen Schweizer Konten möglich.	Banking	mittel
Österreich Konten Schreibzugriff	Abteilungsleitung Banking	Veränderung von allen Österreicher Konten möglich.	Banking	mittel
Deutschland Konten Schreibzugriff	Abteilungsleitung Banking	Veränderung von allen Deutschen Konten möglich.	Banking	mittel
Auditor	Interne Revision	Leseberechtigung auf alle Daten der Anwendung X.	Revision	mittel
Entwicklungs-Ingenieur	Technische Verantwortung Anwendung X	Hat die Möglichkeit den Code für Anwendung X in anzupassen. Ebenso beinhaltet diese Berechtigung Zugriffe auf die Monitoring Tools.	IT-Entwicklung	hoch
Administrator	Technische Verantwortung Anwendung X	Der Nutzer besitzt alle Berechtigungen im System. Er kann alle Daten verändern und löschen.	IT-Infrastruktur	hoch

 

Tabelle zur Darstellung von Rollen die man im IAM System bauen möchte. Ist nicht zwingend nötig. Falls die vorhandenen Berechtigungen sinnvoll aufgebaut sind, kann man diese direkt verwenden.

Die Bündelung von 1-n Berechtigungen aus der obigen Tabelle. Auch hier gibt es einen Owner. Anwendungen haben oft hunderte oder tausende Berechtigungen. Diese einzeln zu pflegen und zu vergeben ist zeitaufwändig und unübersichtlich. Daher lohnt sich bei einer gewissen Anzahl von Berechtigungen ein IAM Rollenkonzept. Spätestens bei der Zertifizierung von tausenden Einzelberechtigung ist der Mensch nicht mehr handlungsfähig.

Meine Empfehlung: Nutzen Sie auch hier die Organigramme ihres Unternehmens und bauen Sie Rollen anhand von Bereich/Abteilung/Team/Jobtitel auf. Dies ist natürlich nicht immer möglich, aber versuchen Sie eine einheitliche Linie zu haben. Die Information „Organisationseinheit“ hilft dem Berechtigungsmanagement Team dabei, die Rolle in eine evtl. bereits vorhandene Rolle einzubauen. (Beispiel: Die Business Rolle „Entwickler“ beinhaltet bereits Berechtigungen die jeder Entwickler benötigt. (JIRA, GIT..).

 

 

Name	Owner	Berechtigungen	Organisationseinheit	Beschreibung	Kritikalität
Banking DACH	Abteilungsleitung Banking	Deutschland Konten Schreibzugriff, Österreich Konten Schreibzugriff, Schweiz Konten Schreibzugriff	Banking	Veränderung von allen Deutschen, Österreicher und Schweizer Konten möglich.	mittel

 

 

 

 

Die Funktionstrennungsmatrix ist eine Möglichkeit zu definieren, dass bestimmte Rollen/Berechtigungen sich gegeneinander ausschließen. Das heißt eine Identität darf nicht beide Rollen/Berechtigungen besitzen.

Beispiel: Auditoren sollten nicht gleichzeitig auch Administrator sein. Dies gilt für jede Anwendung. Besonders im Banking und Versicherungsumfeld müssen Handel und Abwicklung und Kontrolle strikt getrennt sein, um Marktmanipulation zu vermeiden.

Da solche Matrizen beliebig komplex sein können sollte man Sie auf Rollenebene aufsetzen. Also bereits gebündelte Berechtigungen. Wenn die Tabelle zu groß wird muss man die Tabelle in Excel kopieren und dort erweitern.

 

Im angehängten Dokument ist eine formatierte Tabelle für die Funktionstrennungsmatrix enthalten.