+BER.4 Berechtigungsmanagement
---+BER.4.1 Prinzip der geringsten Berechtigungen
------+BER.4.1.1 Rollenbasierte Berechtigung
------+BER.4.1.2 JIT‑/JEA‑Berechtigungen
---+BER.4.2 Autorisierung von Berechtigungen
---+BER.4.3 Begründung von Berechtigungen
---+BER.4.4 Überprüfung von Berechtigungen
------+BER.4.4.1 Überprüfung tatsächlicher Berechtigungen
---+BER.4.5 Systemfunktionen ohne Authentifizierung
---+BER.4.6 Anwendungsfunktionen ohne Authentifizierung
---+BER.4.7 IT-System-Zugangskonto
---+BER.4.8 Entzug von Berechtigungen
|
BER.4 Berechtigungsmanagement
1. Oversigt
| Titel |
Standard |
|
BER.4.1 Prinzip der geringsten Berechtigungen
|
Berechtigung SOLLTE die Vergabe von Berechtigungen nach dem Prinzip der geringsten Berechtigungen einschränken. Erläuterung Das Prinzip der geringsten Berechtigungen, im Englischen als Principle of Least Privilege (PoLP) bekannt, besagt, dass Nutzende, Prozesse oder Systeme nur die minimal notwendigen Zugriffsrechte erhalten dürfen, um die ihnen jeweils zugewiesenen Aufgaben zu erfüllen. Dies dient primär der Minimierung der Angriffsfläche und der Begrenzung potenzieller Schäden. Sollte beispielsweise ein Zugangskonto durch Phishing kompromittiert werden, könnte ein Angreifer ohne dieses Prinzip weitreichenden Zugriff auf kritische Daten oder Systeme erlangen und diese manipulieren, exfiltrieren oder verschlüsseln. Die konsequente Anwendung dieses Grundsatzes kann die Ausbreitung von Schadsoftware nach einem ersten Eindringen erheblich erschweren und sicherstellen, dass Mitarbeitende nur jene Informationen einsehen, die für ihre Tätigkeit unmittelbar relevant sind. Hierdurch wird auch das Risiko von Datendiebstahl durch Innentäter reduziert. Es empfiehlt sich als Ergänzung hier auch das "Need to know"-Prinzip zu betrachten, da sich beide Prinzipien ergänzen. Während das "Least Privilege"-Prinzip auf Systremrechte, Rollen und Berechtigungen fokussiert, liegt der Fokus des "Need to know"-Prinzips mehr auf Informationen und Datenzugriff. Zur sinnvollen Umsetzung kann die Institution ein rollenbasiertes Berechtigungskonzept (Role-Based Access Control, RBAC) etablieren, bei dem Berechtigungen nicht an einzelne Personen, sondern an vordefinierte Rollen (z.B. "Finanzbuchhaltung" oder "Netzwerkadministrator") gebunden werden. Für die Einführung in eine bestehende Umgebung kann ein gestuftes Vorgehen gewählt werden: (1) Zunächst wird ein Überwachungsmodus ("Audit-Only") aktiviert, der protokolliert, welche Zugriffe durch eine strengere Richtlinie verweigert würden, ohne sie tatsächlich zu blockieren. (2) Anschließend werden diese Protokolle analysiert, um legitime, für den Geschäftsbetrieb notwendige Zugriffe zu identifizieren und diese gezielt in die jeweiligen Rollen und Berechtigungsgruppen aufzunehmen. (3) Erst wenn keine legitimen Zugriffe mehr in den Protokollen als "verweigert" auftauchen, wird die Richtlinie scharf geschaltet und blockiert aktiv alle nicht explizit erlaubten Zugriffe. Alle relevanten Anforderungen zur Vergabe von Berechtigungen können mit den Handlungsworten "authentifizieren", "autorisieren" und "einschränken" gefunden werden.
|
|
BER.4.2 Autorisierung von Berechtigungen
|
Berechtigung SOLLTE die Zuweisung von Berechtigungen durch [bestimmte Personen oder Rollen] autorisieren. Erläuterung Mit „bestimmte Personen oder Rollen“ sind hier vorab festgelegte, nachvollziehbar benannte Autorisierungsinstanzen gemeint, also etwa disziplinarische Führungskräfte, fachliche Daten- oder Prozessverantwortliche, Systemverantwortliche, Rollen wie Application Owner, Data Owner, Service Owner oder Genehmiger in einem Identity-and-Access-Management-Prozess. Gemeint ist nicht eine beliebige informelle Zustimmung, sondern eine fachlich oder organisatorisch legitimierte Entscheidung darüber, ob eine konkrete Berechtigung zu einer Person, Funktion, Aufgabe oder einem Schutzbedarf passt. Die Vorschrift zielt darauf ab, unkontrollierte, fachlich nicht begründete oder zu weitreichende Berechtigungsvergaben zu vermeiden; ohne eine festgelegte Autorisierungsinstanz könnte ein Zugangskonto Zugriff auf vertrauliche Daten erhalten, eine nicht mehr passende Gruppenmitgliedschaft könnte bestehen bleiben oder ein privilegierter Zugang könnte ohne ausreichende fachliche Prüfung vergeben werden. Eine geregelte Autorisierung kann die Nachvollziehbarkeit von Zugriffsentscheidungen erhöhen, Interessenkonflikte reduzieren und sicherstellen, dass Berechtigungen an Aufgaben, Verantwortlichkeiten und Schutzbedarf ausgerichtet bleiben.
|
|
BER.4.3 Begründung von Berechtigungen
|
Berechtigung SOLLTE die Vergabe von Berechtigungen und Änderungen an Berechtigungen mit einer Begründung dokumentieren. Erläuterung Zweck ist die Nachvollziehbarkeit der Vergabe von Berechtigungen. Die Dokumentation kann z.B. mit einem Identity-Access-Management oder Personalmanagementsystem automatisiert werden.
|
|
BER.4.4 Überprüfung von Berechtigungen
|
Berechtigung SOLLTE vergebene Berechtigungen [regelmäßig] auf Erforderlichkeit überprüfen. Erläuterung Erforderlichkeit bedeutet in diesem Kontext, dass eine vergebene Berechtigung nur dann als gerechtfertigt gilt, wenn sie für die aktuelle Aufgabenwahrnehmung, Rolle oder Funktion einer Person tatsächlich benötigt wird. Dabei kann zwischen fachlicher Notwendigkeit (z. B. Zugriff auf eine bestimmte Anwendung, um Kernaufgaben erfüllen zu können) und zeitlicher Relevanz (z. B. Projektzugriff, der nur für die Dauer des Projekts sinnvoll ist) unterschieden werden. Als mögliche Werte für den Parameter regelmäßig bieten sich an: (1) quartalsweise, (2) halbjährlich, (3) jährlich – je nach Kritikalität der Systeme und Sensibilität der Daten. Die regelmäßige Überprüfung der Erforderlichkeit kann verhindern, dass sich unbemerkt überhöhte Rechte („Privilege Creep“) ansammeln, die Angreifern im Falle einer Kompromittierung zusätzlichen Spielraum eröffnen könnten. Ohne solche Kontrollen könnte ein ehemaliger Projektmitarbeiter weiterhin Zugang zu sensiblen Daten haben oder ein interner Angreifer auf nicht benötigte Administrationsrechte stoßen. Umgekehrt kann die Überprüfung sicherstellen, dass Berechtigungen stets am aktuellen Aufgabenprofil ausgerichtet bleiben und so Schaden durch Missbrauch oder Fehlhandlungen eingedämmt werden kann. Zur Umsetzung kann eine Institution rollenbasierte Zugriffskonzepte einsetzen, die regelmäßig mit den Ist-Berechtigungen der Nutzer abgeglichen werden („Access Reviews“). Dies kann durch automatisierte Reports aus Verzeichnisdiensten, Datenbanken oder Fachanwendungen erfolgen, die Verantwortlichen zur Bestätigung oder Korrektur vorgelegt werden. Hilfreich kann auch ein Vier-Augen-Prinzip sein, bei dem Vorgesetzte die Notwendigkeit von Berechtigungen bestätigen. Darüber hinaus kann es nützlich sein, temporäre Projekt- oder Sonderrechte mit Ablaufdatum zu vergeben, sodass diese automatisch entzogen werden, wenn sie nicht mehr bestätigt werden.
|
|
BER.4.5 Systemfunktionen ohne Authentifizierung
|
Berechtigung für IT-Systeme SOLLTE Funktionen, auf die ohne vorherige Authentifizierung zugegriffen werden kann, dokumentieren. Erläuterung Funktionen ohne Authentifizierung sind alle Zugriffsmöglichkeiten auf Schnittstellen oder Daten des Systems, für die keine Authentifizierung erforderlich ist. Hierzu gehören z. B. Sprachassistenten, offene Webserver-Ports oder das Einblenden von Inhalten aus Apps auf dem Sperrbildschirm, wodurch persönliche Nachrichten oder Logintoken für Unbefugte zugänglich sein könnten. Solche Funktionen sind häufige Einfallstore für Angriffe auf das System oder für Datenleaks. Daher ist es sinnvoll eine Übersicht dieser Funktionen zu führen, selbst wenn die Funktionen benötigt werden.
|
|
BER.4.6 Anwendungsfunktionen ohne Authentifizierung
|
Berechtigung für Anwendungen SOLLTE Funktionen, auf die ohne vorherige Authentifizierung zugegriffen werden kann, dokumentieren. Erläuterung Hierzu gehören z.B. der Zugriff auf öffentliche Inhalte oder Funktionen zum Zurücksetzen des Passwortes, wodurch persönliche Daten oder Logintoken für Unbefugte zugänglich sein könnten. Allerdings kann es auch unauthentifizierte Funktionen geben, die für Betrieb oder Informationssicherheit benötigt werden, z.B. Meldeformulare für Sicherheitsvorfälle oder öffentliche Webseiteninhalte.
|
|
BER.4.7 IT-System-Zugangskonto
|
Berechtigung für IT-Systeme KANN diese genau einem Zugangskonto zuweisen. Erläuterung Wenn ein besonders schützenswertes IT-System nur von einer Person oder Identität genutzt wird, empfiehlt es sich dieses mit genau einem zugehörigen Zugangskonto zu verknüpfen. Dadurch wird ausgeschlossen, dass weitere Konten unnötig Zugriff erhalten. Bei Revisionen ist auf diese Weise eindeutig nachvollziehbar, welche Identität Zugriff auf das System hatte. Das Vorgehen ist auch auf virtualisierte IT-Systeme übertragbar. Ein Beispiel ist eine spezielle Administrationskonsole, die ausschließlich einem dedizierten Admin-Konto zugeordnet ist.
|
|
BER.4.8 Entzug von Berechtigungen
|
Berechtigung SOLLTE eine Vorgehensweise zum Entzug von Berechtigungen verankern. Erläuterung Innerhalb der Institution ist ein Prozess etabliert, mit dem Berechtigungen system- und anwendungsübergreifend entzogen sowie Zugänge deaktiviert oder gelöscht werden, sobald diese nicht mehr benötigt werden. Dadurch wird sichergestellt, dass bei Personalwechseln oder Aufgabenänderungen keine Berechtigungen für einzelne Systeme oder Anwendungen bestehen bleiben. Der Entzug von Berechtigungen bei Kündigungen, Versetzungen oder Änderungen von Zuständigkeiten ist, soweit möglich, als automatisierter Ablauf umgesetzt.
|
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede reguleringer
2. Identificerede krav
3. Relaterede reguleringer
Reguleringer
| Kilde |
Regulering |
|