Zum Hauptinhalt springen
CENEDRIL WIKI
EN
Starter Kit · Richtlinie

Zugriffskontrollrichtlinie

Aktualisiert am 6 Min. Geprüft von: Cenedril-Redaktion
A.5.3A.5.15A.5.16A.5.17A.5.18A.8.2A.8.3A.8.4A.8.5 ISO 27001NIS2 Art. 21(2)(a)BSI ORP.4

Die Zugriffskontrollrichtlinie ist das Fundament deines gesamten Berechtigungsmanagements. Wer darf was sehen, wer darf was ändern, und wer darf administrative Eingriffe vornehmen? Jede Antwort auf diese Fragen muss dokumentiert, genehmigt und nachvollziehbar sein — genau das regelt dieses Dokument.

Mit acht Annex-A-Controls (A 5.15–18 und A 8.2–8.5) hat ISO 27001 dem Thema mehr Gewicht gegeben als fast jedem anderen Bereich. NIS2 verlangt in Art. 21(2)(a) Risikoanalyse und Sicherheitskonzepte, die ohne saubere Zugriffskontrolle ins Leere laufen. BSI IT-Grundschutz widmet dem Thema einen vollständigen Baustein (ORP.4). Weiter unten findest du die komplette Vorlage auf Deutsch und Englisch.

Worum geht es konkret?

Zugriffskontrolle klingt nach einem rein technischen Thema — IAM-Tool konfigurieren, fertig. In der Praxis steckt dahinter ein organisatorischer Prozess, der HR, IT-Betrieb, Fachabteilungen und die Geschäftsleitung gleichermaßen betrifft. Die Richtlinie definiert die Spielregeln für diesen Prozess.

Sie beantwortet Fragen wie: Wer beantragt Zugriff? Wer genehmigt ihn? Wie schnell werden Rechte entzogen, wenn jemand die Abteilung wechselt oder das Unternehmen verlässt? Was passiert mit dem Root-Account am Wochenende? Und wer prüft einmal im Quartal, ob die privilegierten Zugriffe noch gerechtfertigt sind?

Ohne dokumentierte Antworten auf diese Fragen passiert in der Praxis Folgendes: Rechte sammeln sich an (Privilege Creep), niemand widerruft sie, und nach drei Jahren hat die Praktikantin von 2023 immer noch Zugriff auf das Produktions-Deployment.

Warum ist sie so wichtig?

Regulatorische Dichte. Kein anderes Richtlinienthema hat so viele Annex-A-Controls: A 5.15 (Zugriffskontrolle), A 5.16 (Identitätsmanagement), A 5.17 (Authentisierungsinformationen), A 5.18 (Zugriffsrechte), A 8.2 (Privilegierte Zugriffe), A 8.3 (Einschränkung des Informationszugriffs), A 8.4 (Quellcode-Zugriff) und A 8.5 (Sichere Authentisierung). Auditor:innen verbringen typischerweise einen halben Tag allein mit diesem Thema.

Praktischer Schutzwert. Zugriffsrechte sind der direkteste Hebel, den du hast. Wenn ein Account kompromittiert wird, entscheidet das Rechteprofil darüber, wie groß der Schaden ausfällt. Least Privilege begrenzt den Explosionsradius.

Schnittstelle zu fast allem anderen. Die Zugriffskontrollrichtlinie referenziert Informationsklassifizierung, Personalsicherheit, physische Sicherheit, Kryptographie und den IT-Betrieb. Wenn dieses Dokument schwach ist, wackelt das ganze ISMS.

Was gehört in die Richtlinie?

Die Vorlage deckt zwölf Abschnitte ab — hier die wichtigsten im Überblick:

  • Zugriffskontroll-Rahmenwerk (A 5.15) — Need-to-know, Need-to-use, Least Privilege, Funktionstrennung, dynamische Zugriffskontrolle
  • Identitätsmanagement (A 5.16) — Eindeutige Identitäten, gemeinsam genutzte Konten, nicht-menschliche Identitäten (Service Accounts, API-Clients), Lebenszyklus von der Anlage bis zur Löschung
  • Authentisierungsinformationen (A 5.17) — Passwörter, temporäre Anmeldedaten, Passwort-Manager, kompromittierte Passwörter, SSO
  • Zugriffsrechte (A 5.18) — Formale Beantragung, Genehmigung durch Asset-Eigentümer, Entzug bei Austritt, Review nach Rollenwechsel, rollenbasierte Zugriffskontrolle (RBAC)
  • Privilegierte Zugriffe (A 8.2) — Eigener Genehmigungsprozess, MFA-Pflicht, getrennte Admin-Konten, Break-Glass-Verfahren, Vier-Augen-Prinzip
  • Informationszugriff (A 8.3) — Dynamisches Zugriffsmanagement, Zero Trust, zeitbasierte Zugriffe, Missbrauchswarnungen
  • Quellcode-Zugriff (A 8.4) — Zentrales Repository, Lese-/Schreibtrennung, Audit-Trail, Code-Integrität
  • Sichere Authentisierung (A 8.5) — Anmeldeverfahren, Brute-Force-Schutz, Sitzungs-Timeouts, biometrische Authentisierung

So führst du die Richtlinie ein

  1. 01

    Bestandsaufnahme der Identitäten

    Bevor du die Richtlinie schreibst, brauchst du ein Bild des Ist-Zustands. Wie viele Benutzerkonten gibt es? Wie viele davon sind privilegiert? Gibt es gemeinsam genutzte Konten oder generische Admin-Accounts wie root oder sa? Wie viele ehemalige Mitarbeitende haben noch aktive Konten? Diese Bestandsaufnahme zeigt dir, wo die größten Lücken liegen — und macht die Dringlichkeit des Themas für die Geschäftsleitung greifbar.

  2. 02

    Rollen und Rechteprofile definieren

    Bestimme gemeinsam mit den Fachabteilungen, welche Rollen es gibt und welche Zugriffsrechte jede Rolle benötigt. Das Ergebnis ist eine Zugriffskontroll-Matrix: Zeilen sind Rollen, Spalten sind Systeme und Datenklassen, Zellen enthalten die Zugriffsart (Lesen, Schreiben, Admin). Diese Matrix ist das Rückgrat deiner Richtlinie — ohne sie bleibt alles abstrakt.

  3. 03

    Vorlage anpassen

    Unsere Vorlage hat Platzhalter wie [IHR_ORGANISATIONSNAME] und [RICHTLINIEN_EIGENTÜMER_ROLLE]. Ersetze sie. Aber genauso wichtig: Streiche Abschnitte, die nicht zutreffen. Kein Quellcode im Haus? Abschnitt 9 kann entfallen. Keine biometrische Authentisierung? Entsprechende Absätze raus. Was übrig bleibt, muss eure Realität widerspiegeln.

  4. 04

    Genehmigung und Kommunikation

    Die Zugriffskontrollrichtlinie wird von der Geschäftsleitung genehmigt (ISO 27001, Clause 5.2). Danach kommunizierst du sie an alle Beschäftigten — nicht als Anhang einer E-Mail, die niemand liest, sondern aktiv: Kurz-Briefing für Teamleiter, Zusammenfassung der drei wichtigsten Prinzipien (Need-to-know, Least Privilege, getrennte Admin-Konten), Frist für Bestätigung.

  5. 05

    IAM-Prozess operationalisieren

    Die Richtlinie definiert das Was. Jetzt brauchst du das Wie: einen Beantragungsprozess für Zugriffsrechte, einen Genehmigungsworkflow, automatisierte Provisionierung wo möglich, und einen Review-Zyklus (vierteljährlich für Privilegien, jährlich für alles andere). Ohne diesen operativen Unterbau bleibt die Richtlinie ein Papiertiger.

Wo es in der Praxis schiefgeht

Aus Audit-Erfahrung, nach Häufigkeit sortiert:

1. Privilege Creep. Mitarbeitende wechseln die Abteilung, bekommen neue Rechte, aber die alten werden nie entzogen. Nach drei Jobwechseln hat eine Person Zugriff auf vier Abteilungen — obwohl sie nur in einer arbeitet. Das lässt sich nur durch regelmäßige Reviews und einen sauberen Prozess zwischen HR und IT verhindern.

2. Generische Admin-Konten. root, admin, sa — alle kennen das Passwort, niemand ist persönlich verantwortlich. Bei einem Vorfall lässt sich nicht nachvollziehen, wer was getan hat. Die Lösung: individuelle Admin-Konten, generische Konten über ein PAM-Tool verwalten.

3. Kein formaler Genehmigungsprozess. Zugriff wird per Zuruf erteilt („Kannst du mir kurz Zugriff auf den Server geben?“). Kein Antrag, keine Genehmigung, keine Dokumentation. Im Audit fehlt jeder Nachweis, dass Zugriffe autorisiert waren.

4. Reviews nur auf dem Papier. Die Richtlinie sagt „vierteljährliche Überprüfung“, aber die Reviews bestehen aus einer Excel-Liste, die der IT-Leiter abnickt, ohne die Einträge zu prüfen. Auditor:innen erkennen das sofort — und es wird zum Finding.

5. Service Accounts ohne Eigentümer. API-Keys und Service Accounts werden beim Projektstart angelegt und danach vergessen. Kein Ablaufdatum, keine Rotation, kein benannter Verantwortlicher. Wenn das Projekt endet, laufen die Accounts einfach weiter.

6. Fehlende Funktionstrennung. Dieselbe Person kann einen Benutzer anlegen, ihm Rechte zuweisen und die Genehmigung erteilen. Drei Rollen in einer Hand — das hebelt jede Kontrolle aus.

Vorlage: Zugriffskontrollrichtlinie

Vollständige Richtlinie

Zugriffskontrollrichtlinie

.md · DE.md · EN

Dokumentenkontrolle
Eigentümer: [RICHTLINIEN_EIGENTÜMER_ROLLE, z. B. Informationssicherheitsbeauftragte/r]
Genehmigt von: [GENEHMIGER_NAME_UND_ROLLE]
Version: [VERSION]
Gültig ab: [GÜLTIGKEITSDATUM]
Nächste Überprüfung: [NÄCHSTES_ÜBERPRÜFUNGSDATUM]

1. Rechtliche/Regulatorische Grundlage

ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Anhang A — Organisatorische & Technologische Maßnahmen:

  • A 5.15 — Zugriffskontrolle
  • A 5.16 — Identitätsmanagement
  • A 5.17 — Authentisierungsinformationen
  • A 5.18 — Zugriffsrechte
  • A 8.2 — Privilegierte Zugriffsrechte
  • A 8.3 — Einschränkung des Informationszugriffs
  • A 8.4 — Zugriff auf Quellcode
  • A 8.5 — Sichere Authentisierung

BSI IT-Grundschutz:

  • ORP.4.A1 (Regelung für die Einrichtung und Löschung von Benutzern und Benutzergruppen)
  • ORP.4.A2 (Einrichtung, Änderung und Entzug von Berechtigungen)
  • ORP.4.A3 (Dokumentation der Benutzerkennungen und Rechteprofile)
  • ORP.4.A4 (Aufgabenverteilung und Funktionstrennung)
  • ORP.4.A5 (Vergabe von Zutrittsberechtigungen)
  • ORP.4.A6 (Vergabe von Zugangsberechtigungen)
  • ORP.4.A7 (Vergabe von Zugriffsrechten)
  • ORP.4.A8 (Regelung des Passwortgebrauchs)
  • ORP.4.A9 (Identifikation und Authentisierung)
  • ORP.4.A10 (Schutz von Benutzerkennungen mit weitreichenden Berechtigungen)
  • ORP.4.A11 (Zurücksetzen von Passwörtern)
  • ORP.4.A12 (Entwicklung eines Authentisierungskonzepts für IT-Systeme und Anwendungen)
  • ORP.4.A13 (Geeignete Auswahl von Authentisierungsmechanismen)
  • ORP.4.A14 (Kontrolle der Wirksamkeit der Benutzertrennung)
  • ORP.4.A15 (Vorgehensweise und Konzeption der Identitäts- und Berechtigungsmanagementprozesse)
  • ORP.4.A16 (Richtlinien für Zugriffs- und Zugangskontrolle)
  • ORP.4.A19 (Einweisung aller Mitarbeiter in den Umgang mit Authentisierungsverfahren und -mechanismen)
  • ORP.4.A22 (Regelung zur Passwortqualität)
  • ORP.4.A23 (Regelung für passwortverarbeitende Anwendungen und IT-Systeme)
  • ORP.4.A24 (Vier-Augen-Prinzip für administrative Tätigkeiten)
  • CON.8.A10 (Zugriffskontrolle für Quellcode)

Weitere jurisdiktionsspezifische Gesetze und Vorschriften — insbesondere Datenschutzrecht (DSGVO) und branchenspezifische Regulierungen (NIS2, DORA etc.) — sind im Rechtsregister aufgeführt und werden durch Verweis einbezogen.

2. Zweck & Geltungsbereich

Diese Richtlinie legt den Rahmen für das Identitäts- und Zugriffsmanagement (IAM) bei [IHR_ORGANISATIONSNAME] fest. Sie setzt die Anforderungen der ISO/IEC 27002:2022 Maßnahmen A 5.15 bis A 5.18 (Zugriffskontrolle, Identitätsmanagement, Authentisierungsinformationen, Zugriffsrechte) sowie A 8.2 bis A 8.5 (Privilegierte Zugriffsrechte, Einschränkung des Informationszugriffs, Zugriff auf Quellcode, Sichere Authentisierung) gemeinsam mit dem BSI IT-Grundschutz-Baustein ORP.4 (Identitäts- und Berechtigungsmanagement) um.

Die Richtlinie gilt für jeden logischen und physischen Zugriff auf Informationen, Informationssysteme, Netzwerke, Anwendungen und Quellcode. Sie umfasst alle Arten von Identitäten einschließlich persönlicher Benutzerkonten, Dienstkonten, gemeinsam genutzter Identitäten, privilegierter Konten und nicht-menschlicher Entitäten.

Alle Beschäftigten, Auftragnehmer, befristet Beschäftigten und Dritten, die auf organisatorische Systeme oder Informationen zugreifen, unterliegen dieser Richtlinie. Die konkreten Verantwortlichkeiten für IT-Betrieb, Systemadministratoren, Asset-Eigentümer und Führungskräfte sind im Abschnitt Rollen & Verantwortlichkeiten definiert.

3. Rahmenwerk der Zugriffskontrolle (A 5.15)

Die Eigentümer von Informationen und zugehörigen Assets bestimmen die Anforderungen an Informationssicherheit, Datenschutz und den geschäftlichen Bedarf im Zusammenhang mit der Zugriffskontrolle. Diese Richtlinie berücksichtigt diese Anforderungen und wird allen relevanten interessierten Parteien kommuniziert. Zugriffskontrollregeln werden umgesetzt, indem geeignete Zugriffsrechte und Einschränkungen den jeweiligen Entitäten — seien es menschliche Benutzer, Maschinen, Geräte oder Dienste — zugewiesen werden. Zur Vereinfachung der Verwaltung werden bestimmten Entitätsgruppen spezifische Rollen zugewiesen. Geschäftliche Anforderungen und Risiken werden bei der Entscheidung berücksichtigt, welches Zugriffskontrollsystem verwendet wird, wie Regeln angewendet werden und welche Granularität erforderlich ist.

3.1 Grundsätze der Zugriffskontrolle

  • Zuordnung Entität zu Asset: Für jedes Informationsasset und zugehörige System wird pro Entitätsrolle die erforderliche Art des Zugriffs (Lesen, Schreiben, Ausführen, Löschen, Administrieren) bestimmt. Zugriffsanforderungen werden in der Zugriffskontroll-Matrix dokumentiert und bei jeder Änderung der Asset-Eigentümerschaft oder der Geschäftsprozesse überprüft.
  • Anwendungssicherheit: Anforderungen an die Zugriffskontrolle für Anwendungen werden als Teil der Anwendungssicherheitsspezifikation definiert. Zugriffskontrollen auf Anwendungsebene setzen rollenbasierte Berechtigungen durch und sind, sofern technisch machbar, mit dem zentralen Identitätsmanagementsystem integriert.
  • Physischer Zugang: Die logische Zugriffskontrolle ist mit den physischen Zutrittskontrollen abgestimmt. Der physische Zutritt zu sicheren Bereichen wird durch angemessene physische Kontrollen wie Zugangskarten, biometrische Lesegeräte oder schlüsselbasierte Mechanismen unterstützt. Physische und logische Zugriffsrechte werden konsistent verwaltet und gemeinsam überprüft.
  • Kenntnis-bei-Bedarf-Prinzip & Klassifizierungsabgleich: Zugriffsrechte sind an Informationsklassifizierungsstufen und Datenschutzanforderungen ausgerichtet. Der Zugriff auf Informationen wird nach dem Need-to-know-Prinzip gewährt: Nur Entitäten mit dokumentiertem geschäftlichem Bedarf, auf bestimmte Informationen einer bestimmten Klassifizierungsstufe zuzugreifen, erhalten die entsprechenden Zugriffsrechte.
  • Beschränkungen privilegierter Zugriffe: Zugriffsrechte mit erhöhten Privilegien unterliegen zusätzlichen Beschränkungen einschließlich gesonderter Genehmigung, zeitlich begrenzter Gewährung, verstärkter Authentisierung und separater administrativer Identitäten. Die detaillierten Regeln für privilegierte Zugriffe sind in Abschnitt 7 dieser Richtlinie definiert.
  • Funktionstrennung: Zugriffsrechte setzen die Trennung unvereinbarer Aufgaben gemäß der Funktionstrennungs-Matrix der Organisation durch. Keine einzelne Person hält Zugriffsrechte, die es ihr erlauben würden, eine kritische Transaktion sowohl anzustoßen als auch zu genehmigen.
  • Rechtliche & vertragliche Verpflichtungen: Zugriffsbeschränkungen, die durch geltende Gesetzgebung (einschließlich DSGVO, geltendem nationalem Datenschutzrecht und branchenspezifischen Regulierungen) und vertragliche Verpflichtungen vorgeschrieben sind, werden identifiziert, dokumentiert und durch geeignete Zugriffskontrollen durchgesetzt. Der Zugriff auf personenbezogene Daten ist auf autorisierte Datenverarbeiter mit dokumentierter Rechtsgrundlage beschränkt.
  • Trennung der Zugriffskontroll-Funktionen: Die Funktionen Zugriffsantrag, Zugriffsgenehmigung und Zugriffsadministration sind voneinander getrennt. Die Person, die den Zugriff beantragt, ist nicht dieselbe Person, die ihn genehmigt, und die Person, die den Zugriff genehmigt, ist nicht dieselbe Person, die die technische Konfiguration umsetzt. In kleineren Organisationen, in denen eine vollständige Trennung nicht möglich ist, werden kompensierende Maßnahmen wie Audit-Protokollierung und periodische Überprüfung angewendet.
  • Formale Genehmigung von Zugriffsanträgen: Jeder Zugriffsantrag folgt einem formalen Genehmigungsverfahren. Zugriffe werden nicht gewährt, bevor eine dokumentierte Genehmigung des Informationseigentümers oder einer delegierten Autorität erfasst ist. Der Genehmigungsworkflow ist im Identitätsmanagementprozess definiert.
  • Lebenszyklus-Management von Zugriffsrechten: Zugriffsrechte werden über ihren gesamten Lebenszyklus hinweg verwaltet — von der initialen Bereitstellung über Änderungen bis zum Entzug. Die Prozesse zur Verwaltung von Zugriffsrechten sind im Abschnitt Zugriffsrechteverwaltung dieser Richtlinie definiert.
  • Protokollierung & Audit Trail: Alle Ereignisse der Zugriffskontrolle — einschließlich Zugriffsgewährungen, Änderungen, Entzug und Zugriffsversuchen — werden protokolliert und gemäß der Protokollierungsrichtlinie der Organisation aufbewahrt. Protokolle sind gegen Manipulation geschützt und werden regelmäßig überprüft.

3.2 Zugriffskontrollregeln

  • Klassifizierungskonforme Zugriffsrechte: Zugriffsrechte sind konsistent mit der Informationsklassifizierungsstufe jedes Assets. Höhere Klassifizierungsstufen erfordern strengere Zugriffskontrollen, kleinere Zugriffsgruppen und häufigere Zugriffsüberprüfungen.
  • Konsistenz mit physischem Perimeter: Zugriffsrechte sind konsistent mit den Anforderungen der physischen Perimetersicherheit. Entitäten, die von Standorten mit geringerer physischer Sicherheit operieren (z. B. aus dem Home Office oder öffentlichen Bereichen), unterliegen zusätzlichen logischen Zugriffsbeschränkungen wie VPN-Pflicht und Multi-Faktor-Authentisierung.
  • Zugriff in verteilten Umgebungen: In verteilten Umgebungen werden alle verfügbaren Verbindungsarten — einschließlich LAN, VPN, WLAN, Cloud und Remote Desktop — bei der Definition von Zugriffsregeln berücksichtigt. Entitäten erhalten nur Zugriff auf die Informationen, Netzwerke und Netzwerkdienste, zu deren Nutzung sie autorisiert sind, unabhängig vom Verbindungsweg. Netzwerksegmentierung und Firewall-Regeln setzen diese Beschränkungen auf Infrastrukturebene durch.
  • Dynamische Zugriffskontrolle: Wo betrieblich angemessen, werden dynamische Zugriffskontrollfaktoren — wie Gerätezustand, geografischer Standort, Tageszeit, Risikobewertung und Authentisierungsstärke — in Zugriffsentscheidungen einbezogen. Diese Faktoren ergänzen statische rollenbasierte Regeln und ermöglichen eine kontextbewusste Zugriffssteuerung.

3.3 Übergeordnete Prinzipien

  • Need-to-know: Eine Entität erhält Zugriff nur auf die Informationen, die für die Erfüllung ihrer zugewiesenen Aufgaben erforderlich sind. Unterschiedliche Aufgaben und Rollen führen zu unterschiedlichen Zugriffsprofilen. Zugriffe, die über das für die aktuelle Rolle Erforderliche hinausgehen, werden nicht gewährt, unabhängig von Dienstalter oder organisatorischer Position.
  • Need-to-use: Zugriff auf IT-Infrastruktur — einschließlich Systeme, Netzwerke und Dienste — wird nur dort vergeben, wo ein klarer geschäftlicher Bedarf dokumentiert und genehmigt ist. Infrastrukturzugriff ohne aktuellen operativen Zweck wird entzogen.
  • Least Privilege (Prinzip der minimalen Rechte): Der Standardzustand ist „alles ist verboten, sofern nicht ausdrücklich erlaubt". Zugriffsrechte werden auf dem minimalen Niveau gewährt, das zur Ausübung der autorisierten Funktion erforderlich ist. Die schwächere Regel „alles ist erlaubt, sofern nicht ausdrücklich verboten" wird nicht angewendet.

3.4 Sensibilisierung & Änderungsmanagement

  • Automatische & manuelle Änderungen von Klassifizierungen: Beschäftigte werden darüber informiert, dass Änderungen an Informationskennzeichnungen — sei es automatisch durch Informationsverarbeitungssysteme oder manuell durch einen Benutzer initiiert — bestehende Zugriffsrechte beeinflussen können. Wenn sich eine Klassifizierungsstufe ändert, werden Zugriffsrechte entsprechend überprüft und angepasst.
  • System- und administratorinitiierte Berechtigungsänderungen: Beschäftigte werden darauf hingewiesen, dass sich ihre Zugriffsberechtigungen sowohl durch automatisierte Systemprozesse (z. B. rollenbasierte Bereitstellung, zeitbasierter Ablauf) als auch durch manuelle Administrationseingriffe ändern können. Benutzer, die unerwartete Berechtigungsänderungen feststellen, melden diese dem IT-Betrieb.
  • Periodische Überprüfung der Genehmigungsregeln: Genehmigungsregeln für Zugriffsanträge werden zum Zeitpunkt der initialen Einrichtung definiert und regelmäßig überprüft — mindestens jährlich sowie nach wesentlichen organisatorischen Änderungen. Die Überprüfung verifiziert, dass der Genehmigungsworkflow, die delegierten Befugnisse und die Eskalationswege weiterhin angemessen sind.

Zugriffskontrollregeln werden durch die in den folgenden Abschnitten dieser Richtlinie definierten Verfahren (Identitätsmanagement, Authentisierungsinformationen, Zugriffsrechte, privilegierte Zugriffe, Einschränkung des Informationszugriffs, Quellcode-Zugriff, sichere Authentisierung) und durch klar definierte Verantwortlichkeiten unterstützt. Alle Beschäftigten werden in die korrekte Nutzung von Authentisierungsverfahren und -mechanismen eingewiesen, bevor sie Systemzugang erhalten.

4. Identitätsmanagement (A 5.16)

Die Identitätsmanagementprozesse stellen sicher, dass jede Identität eindeutig zugewiesen, nachverfolgbar und über ihren gesamten Lebenszyklus hinweg verwaltet wird. Jedes Benutzerkonto ist unzweideutig einer einzelnen Person oder — im Falle nicht-menschlicher Identitäten — einem dokumentierten System oder Dienst zugeordnet. Identitäten werden in einem formalen Verfahren mit definierten Genehmigungsschritten erstellt, geändert und entfernt. Gastkonten und nicht benötigte Standardkonten werden deaktiviert oder entfernt. Die IAM-Prozesse werden über fünf Teilprozesse verwaltet: Richtlinienmanagement, Identitätsprofilmanagement, Benutzerkontenverwaltung, Berechtigungsprofilverwaltung und Rollenmanagement.

4.1 Identitätsmanagement-Prozesse

  • Eindeutigkeit persönlicher Identitäten: Jede einer Person zugewiesene Identität ist mit genau einer Person verknüpft. Diese 1:1-Zuordnung stellt die persönliche Verantwortlichkeit für alle unter dieser Identität durchgeführten Aktionen sicher. Jedes Benutzerkonto ist unzweideutig auf eine namentlich benannte Person rückführbar.
  • Gemeinsam genutzte Identitäten: Gemeinsam von mehreren Personen genutzte Identitäten sind nur zulässig, wenn ein dokumentierter geschäftlicher oder betrieblicher Bedarf besteht und keine Alternative umsetzbar ist. Jede gemeinsam genutzte Identität erfordert eine gesonderte Genehmigung durch die/den Informationssicherheitsbeauftragten, eine Dokumentation aller zur Nutzung berechtigten Personen sowie — sofern technisch möglich — ein Protokoll der individuellen Nutzung.
  • Nicht-menschliche Identitäten: Identitäten, die Dienstkonten, automatisierten Prozessen, API-Clients oder anderen nicht-menschlichen Entitäten zugewiesen sind, unterliegen einem getrennten Genehmigungsprozess — getrennt von der regulären Benutzerkontenbereitstellung — und einer unabhängigen laufenden Überwachung. Jede nicht-menschliche Identität hat einen benannten Eigentümer, der für ihren Lebenszyklus, ihren Zugriffsumfang und die Rotation ihrer Anmeldedaten verantwortlich ist.
  • Zeitnahe Deaktivierung & Entfernung: Identitäten, die nicht mehr benötigt werden, werden unverzüglich deaktiviert oder entfernt. Wenn eine Person die Organisation verlässt, werden alle zugehörigen Benutzerkonten am letzten Arbeitstag deaktiviert und nach einer definierten Aufbewahrungsfrist gelöscht. Bei Rollenwechseln werden die mit der früheren Rolle verknüpften Konten innerhalb von fünf Arbeitstagen überprüft und angepasst. Inaktive Konten werden nach 90 Tagen automatisch markiert und nach 180 Tagen Inaktivität deaktiviert.
  • Keine doppelten Identitäten: Innerhalb einer einzelnen Domäne oder eines einzelnen Systems wird jede Entität einer einzelnen Identität zugeordnet. Doppelte Identitäten für dieselbe Entität im selben Kontext werden vermieden. Wo eine Entität legitim mehrere Identitäten über verschiedene Domänen hinweg benötigt (z. B. ein Standardkonto und ein separates administratives Konto), wird jede Identität mit einer klaren Zweckbeschreibung dokumentiert.
  • Ereignisprotokollierung für Identitäten: Alle wesentlichen Ereignisse bezüglich der Erstellung, Änderung, Deaktivierung, Löschung und Nutzung von Benutzeridentitäten und Authentisierungsinformationen werden in einem manipulationsgeschützten Audit-Log erfasst. Dazu gehören Kontoanlage, Berechtigungsänderungen, Passwortrücksetzungen, Kontosperrungen und Kontolöschungen.
  • Änderungen an Identitätsinformationen: Änderungen an identitätsbezogenen Informationen — wie Namensänderungen, Rollenwechsel oder aktualisierte Kontaktdaten — werden über das Identitätsmanagementsystem bearbeitet. Wenn bei der initialen Identitätsprüfung Ausweisdokumente (z. B. amtlicher Lichtbildausweis) Teil des Prozesses waren, wird bei wesentlichen Änderungen der Identitätsinformationen eine erneute Überprüfung durchgeführt.

4.2 Bereitstellungsschritte

  • Bestätigung des geschäftlichen Bedarfs: Bevor eine Identität erstellt wird, wird der geschäftliche Bedarf für ihre Einrichtung durch die/den antragstellenden Vorgesetzten oder Systemeigentümer bestätigt. Der Antrag umfasst den beabsichtigten Zweck, den erforderlichen Zugriffsumfang und die erwartete Nutzungsdauer.
  • Identitätsverifizierung: Die Identität der Entität wird verifiziert, bevor eine logische Identität vergeben wird. Für Personen erfolgt diese Verifizierung während des Onboarding-Prozesses durch einen amtlichen Lichtbildausweis oder eine gleichwertige Dokumentation. Für externe Auftragnehmer bestätigt der verantwortliche interne Vorgesetzte die Identität der Person.
  • Identitätseinrichtung: Nachdem der geschäftliche Bedarf bestätigt und die Identitätsverifizierung abgeschlossen ist, wird die Identität im zentralen Identitätsmanagementsystem mit einem eindeutigen Identifikator, einem dokumentierten Eigentümer und einem definierten Umfang eingerichtet.
  • Konfiguration & Aktivierung: Die Identität wird mit den geeigneten Authentisierungsdiensten (Passwort, MFA-Token, Zertifikat) konfiguriert und erst aktiviert, wenn alle Voraussetzungen erfüllt sind. Initiale Anmeldedaten werden gemäß der in Abschnitt 5 dieser Richtlinie definierten Richtlinie für Authentisierungsinformationen generiert.
  • Zuweisung von Zugriffsrechten: Der Identität werden basierend auf den geltenden Autorisierungs- und Berechtigungsentscheidungen spezifische Zugriffsrechte zugewiesen oder entzogen. Die Zugriffsbereitstellung folgt dem in Abschnitt 6 definierten Prozess zur Zugriffsrechteverwaltung.

Wenn von Dritten bereitgestellte oder ausgegebene Identitäten (z. B. föderierte Identitäten, Social-Media-Anmeldedaten) verwendet werden, verifiziert die Organisation, dass der externe Identitätsanbieter das erforderliche Vertrauensniveau liefert und dass die damit verbundenen Risiken bekannt und behandelt sind. Vereinbarungen mit Drittanbietern für Identitätsdienste werden über den Lieferantenmanagementprozess und die in Abschnitt 5 definierten Maßnahmen zu Authentisierungsinformationen geregelt.

5. Authentisierungsinformationen (A 5.17)

Authentisierungsinformationen — einschließlich Passwörter, PINs, Zertifikate, Token und biometrische Daten — werden über ihren gesamten Lebenszyklus hinweg sicher verwaltet. Die Organisation legt Regeln für die Passwortnutzung fest, die für alle Beschäftigten verbindlich sind. Ob Passwörter allein ausreichen oder ob zusätzliche oder alternative Authentisierungsmechanismen erforderlich sind, wird pro System basierend auf dem Schutzbedarf und dem Authentisierungskonzept bestimmt. Alle Beschäftigten werden in den korrekten Umgang mit Authentisierungsverfahren und -mechanismen eingewiesen, bevor sie Zugangsdaten erhalten.

5.1 Vergabe von Authentisierungsinformationen

  • Temporäre Anmeldedaten: Während der Registrierung automatisch generierte Passwörter oder PINs sind nicht erratbar, für jede Person einmalig und laufen nach der ersten Verwendung ab. Benutzer sind verpflichtet, unmittelbar nach der ersten Anmeldung ein persönliches Passwort festzulegen.
  • Identitätsverifizierung vor Ausgabe: Bevor neue, ersetzende oder temporäre Authentisierungsinformationen bereitgestellt werden, wird die Identität der/des anfordernden Benutzenden durch ein definiertes Verfahren verifiziert. Für persönlich vorgebrachte Anfragen wird ein gültiger Lichtbildausweis geprüft. Für Fernanfragen wird ein mehrstufiges Verifizierungsverfahren unter Einbeziehung der vorgesetzten Person oder eines sekundären authentisierten Kanals angewendet.
  • Sichere Übertragung: Authentisierungsinformationen — einschließlich temporärer Anmeldedaten — werden über einen authentisierten und geschützten Kanal an Benutzer übermittelt. Ungeschützte (Klartext-)E-Mail wird nicht zur Übertragung von Passwörtern oder anderen geheimen Authentisierungsinformationen verwendet. Wo eine Out-of-Band-Übermittlung erforderlich ist, wird ein separater Kanal (z. B. SMS, versiegelter Umschlag oder verschlüsselte Nachricht) genutzt.
  • Empfangsbestätigung: Benutzer bestätigen den Empfang von Authentisierungsinformationen und erklären damit, dass sie die damit verbundenen Verantwortlichkeiten und die in dieser Richtlinie definierten Regeln zum sicheren Umgang verstanden haben.
  • Ersetzen von Standard-Anmeldedaten: Von Herstellern voreingestellte oder während der Systeminstallation bereitgestellte Standard-Authentisierungsinformationen werden unmittelbar nach der Installation und vor Anbindung des Systems an die Produktionsumgebung geändert. Vordefinierte Standard-Benutzernamen werden ersetzt, sofern dies technisch unterstützt wird.
  • Aufzeichnungsführung: Wesentliche Ereignisse bezüglich Vergabe und Verwaltung von Authentisierungsinformationen — einschließlich Ausgabe, Rücksetzung, Widerruf und Kompromittierungsmeldungen — werden protokolliert. Die Vertraulichkeit dieser Aufzeichnungen wird durch Zugriffsbeschränkungen geschützt. Ein genehmigtes Passwort-Tresor-Werkzeug wird verwendet, wo eine zentrale Ablage von Zugangsdaten erforderlich ist.

5.2 Verantwortlichkeiten der Benutzer

  • Vertraulichkeit von Anmeldedaten: Geheime Authentisierungsinformationen wie Passwörter werden jederzeit vertraulich behandelt. Persönliche Passwörter werden niemandem weitergegeben — auch nicht an Kolleginnen und Kollegen, Vorgesetzte oder IT-Support. Passwörter für gemeinsam genutzte oder nicht-personengebundene Identitäten werden nur ausdrücklich autorisierten Personen offengelegt. Passwörter werden nur unbeobachtet eingegeben und niemals auf programmierbaren Funktionstasten, Haftnotizen oder in ungeschützten Dateien gespeichert.
  • Sofortiger Wechsel nach Kompromittierung: Wenn Authentisierungsinformationen kompromittiert wurden oder der Verdacht einer Kompromittierung besteht, wird das betroffene Anmeldedatum sofort geändert. Benutzer melden vermutete Kompromittierungen unverzüglich dem IT-Betrieb. Für passwortbasierte Konten leitet der Benutzer eine sofortige Passwortänderung ein; für Token- oder zertifikatsbasierte Anmeldedaten kontaktiert der Benutzer den IT-Betrieb für Widerruf und Ersatz.
  • Starke Passwortauswahl: Wenn Passwörter als Authentisierungsinformation verwendet werden, werden starke Passwörter nach folgenden Regeln gewählt: Passwörter basieren nicht auf leicht erratbaren persönlichen Informationen (Namen, Telefonnummern, Geburtsdaten); Passwörter basieren nicht auf Wörterbuchwörtern oder einfachen Kombinationen davon; Passwörter bestehen aus gut merkbaren Passphrasen mit alphanumerischen und Sonderzeichen; und Passwörter erfüllen die im Passwortverwaltungssystem definierte Mindestlänge. Die Nutzung eines genehmigten Passwortmanagers zur Generierung und Speicherung komplexer Passwörter wird empfohlen.
  • Keine Passwort-Wiederverwendung über Dienste hinweg: Für jeden einzelnen Dienst und jedes System wird ein eindeutiges Passwort verwendet. Dasselbe Passwort wird nicht für mehrere Konten verwendet. Ein genehmigter Passwort-Tresor wird bereitgestellt, um die Verwaltung mehrerer einzigartiger Passwörter zu unterstützen.
  • Arbeitsvertragliche Verpflichtung: Die Verpflichtung zur Einhaltung dieser Regeln für Authentisierungsinformationen ist in den Arbeitsbedingungen aller Beschäftigten und in Verträgen mit externen Parteien enthalten.

5.3 Passwortverwaltungssystem

  • Self-Service-Passwortverwaltung: Benutzer können ihre eigenen Passwörter auswählen und ändern. Der Passwortänderungsprozess umfasst ein Bestätigungsverfahren (erneute Eingabe des neuen Passworts), um Eingabefehler zu vermeiden.
  • Durchsetzung der Passwortstärke: Das Passwortverwaltungssystem setzt starke Passwörter gemäß bewährter Praxis durch: Mindestlänge von mindestens 12 Zeichen für Standardkonten und mindestens 16 Zeichen für privilegierte Konten, Einbeziehung mehrerer Zeichenklassen (Großbuchstaben, Kleinbuchstaben, Ziffern, Sonderzeichen) sowie Ablehnung von Passwörtern, die Komplexitätsprüfungen nicht bestehen.
  • Passwortwechsel bei Erstanmeldung: Benutzer werden gezwungen, ihr Passwort bei der ersten Anmeldung zu ändern. Vor dem Ersetzen des initialen Passworts durch ein benutzergewähltes Passwort ist kein Zugriff auf organisatorische Ressourcen jenseits der Passwortänderungsfunktion möglich.
  • Ereignisgesteuerte Passwortänderungen: Passwortänderungen werden erzwungen, wenn ein konkretes Ereignis dies rechtfertigt: nach einem Sicherheitsvorfall mit Offenlegung von Anmeldedaten, bei Beendigung oder Änderung des Beschäftigungsverhältnisses, wenn die ausscheidende Person Passwörter für Identitäten kennt, die aktiv bleiben (z. B. gemeinsam genutzte Identitäten), oder wenn eine Kompromittierung erkannt oder vermutet wird. Routinemäßige zeitbasierte Passwortrotationen werden nicht erzwungen, sofern keine Mechanismen zur Kompromittierungserkennung verfügbar sind.
  • Passworthistorie: Das Passwortverwaltungssystem verhindert die Wiederverwendung früherer Passwörter. Eine Passworthistorie von mindestens den letzten 10 Passwörtern wird geführt und durchgesetzt.
  • Erkennung kompromittierter Passwörter: Das Passwortverwaltungssystem prüft neue Passwörter gegen Listen häufig verwendeter Passwörter und gegen bekannte kompromittierte Benutzername/Passwort-Kombinationen aus öffentlich bekannt gewordenen Datenpannen. Passwörter, die auf solchen Listen stehen, werden abgelehnt.
  • Maskierung der Passwortanzeige: Passwörter werden während der Eingabe nicht am Bildschirm angezeigt. Eingabefelder maskieren Passwortzeichen standardmäßig. Eine temporäre Einblendefunktion ist aus Barrierefreiheitsgründen zulässig.
  • Geschützte Speicherung & Übertragung: Passwörter werden ausschließlich in geschützter Form gespeichert und übertragen. Passwörter werden niemals im Klartext in Datenbanken, Konfigurationsdateien, Skripten oder Protokollen gespeichert. Die Übertragung von Passwörtern über Netzwerke erfolgt ausschließlich über verschlüsselte Kanäle.
  • Kryptographisches Hashing: Gespeicherte Passwörter werden mit genehmigten kryptographischen Verfahren gehasht — speziell mit modernen adaptiven Hashing-Algorithmen (z. B. Argon2, bcrypt, scrypt) mit individuellem Salt pro Passwort. Reversible Verschlüsselung oder veraltete Hashing-Algorithmen (z. B. MD5, SHA-1) werden für die Passwortspeicherung nicht verwendet.

5.4 Single Sign-On & Authentisierungswerkzeuge

  • Single Sign-On & Passwort-Tresore: Die Organisation stellt Single Sign-On (SSO) oder andere Werkzeuge zur Authentisierungsverwaltung (z. B. einen genehmigten Enterprise-Passwort-Tresor) bereit, um die Anzahl der von Benutzern zu verwaltenden Anmeldedaten zu reduzieren. Beschäftigte werden darauf hingewiesen, dass diese Werkzeuge auch die Auswirkungen einer Offenlegung von Anmeldedaten erhöhen — wenn das SSO-Anmeldedatum oder das Master-Passwort des Tresors kompromittiert wird, sind alle verknüpften Konten betroffen. SSO-Anmeldedaten und Tresor-Master-Passwörter werden daher mit Multi-Faktor-Authentisierung geschützt. Ein zentraler Authentisierungsdienst wird, sofern umsetzbar, verwendet, um eine einheitliche Identitätsüberprüfung über alle organisatorischen Systeme hinweg zu ermöglichen.

6. Verwaltung von Zugriffsrechten (A 5.18)

Zugriffsrechte — sowohl physische als auch logische — werden durch einen formalen Prozess der Bereitstellung, Änderung und des Entzugs verwaltet. Alle Zugriffsrechte-Zuweisungen folgen den Prinzipien der minimalen Rechte und des Need-to-know. Die Ausgabe und der Entzug physischer Zugangstoken (Chipkarten, Schlüssel, Ausweise) ist dokumentiert. Kompromittierte Zugangstoken werden umgehend ersetzt. Alle autorisierten Benutzerkonten, Benutzergruppen und Rechteprofile sind dokumentiert, und diese Dokumentation wird regelmäßig überprüft, um zu bestätigen, dass sie den tatsächlichen Stand der Zugriffsrechte widerspiegelt und weiterhin an den aktuellen Aufgaben und Sicherheitsanforderungen ausgerichtet ist.

6.1 Vergabe & Entzug von Zugriffsrechten

  • Autorisierung durch Eigentümer: Zugriffe auf Informationen und zugehörige Assets werden nur nach Autorisierung durch den benannten Eigentümer der Information oder des Assets gewährt. Wo die Klassifizierung des Assets es erfordert, wird zusätzlich zur Autorisierung des Eigentümers eine gesonderte Managementfreigabe eingeholt.
  • Abstimmung mit Geschäftsbedarf & Richtlinie: Jede Zugriffsrechte-Zuweisung berücksichtigt die dokumentierten geschäftlichen Anforderungen und die in dieser Zugriffskontroll-Richtlinie festgelegten Regeln. Zugriffe ohne aktuellen geschäftlichen Zweck werden auch auf Anforderung nicht gewährt.
  • Funktionstrennung in der Zugriffsbereitstellung: Die Rollen Zugriffsfreigabe und Zugriffsimplementierung sind voneinander getrennt. Die Person, die einen Zugriffsantrag genehmigt, ist nicht dieselbe, die den Zugriff im System konfiguriert. Konfliktäre Rollen — bei denen eine einzelne Person eine sensible Transaktion sowohl anstoßen als auch abschließen könnte — werden identifiziert und durch Zugriffskontrollen getrennt.
  • Zeitnaher Entzug: Zugriffsrechte werden entzogen, sobald eine Person keinen Zugriff mehr auf die Information oder das Asset benötigt. Wenn eine Person die Organisation verlässt, werden alle Zugriffsrechte spätestens am letzten Arbeitstag entzogen. Der IT-Betrieb erhält im Voraus Meldung von Personalabgängen durch die HR-Abteilung, um den Zugriffsentzug vorzubereiten.
  • Temporäre Zugriffe: Wo Zugriff für einen begrenzten Zeitraum benötigt wird — für temporäres Personal, Projektarbeit oder zeitgebundene Aufgaben — werden Zugriffsrechte mit einem expliziten Ablaufdatum bereitgestellt. Das System entzieht den Zugriff automatisch zum definierten Ablaufzeitpunkt. Verlängerungen erfordern eine neue Genehmigung.
  • Verifizierung des Zugriffsniveaus: Vor der Aktivierung von Zugriffsrechten wird das gewährte Zugriffsniveau gegen diese Zugriffskontroll-Richtlinie und gegen andere Informationssicherheits- und Datenschutzanforderungen einschließlich der Funktionstrennungs-Matrix verifiziert. Zugriffsrechte, die das durch die Richtlinie Erlaubte überschreiten, werden nicht aktiviert.
  • Aktivierung nach Autorisierung: Zugriffsrechte — einschließlich solcher, die durch Dienstleister konfiguriert werden — werden erst nach erfolgreichem Abschluss und vollständiger Dokumentation des Autorisierungsverfahrens aktiviert. Vorläufige oder provisorische Zugriffsgewährungen während einer ausstehenden Genehmigung erfolgen nicht.
  • Zentrales Zugriffsverzeichnis: Ein zentrales Verzeichnis wird über alle Zugriffsrechte geführt, die jeder Benutzeridentifikation (logisch oder physisch) auf Informationen und zugehörige Assets gewährt wurden. Dieses Verzeichnis wird aktuell gehalten und ist für die/den Informationssicherheitsbeauftragte/n, den IT-Betrieb und die interne Revision zur Überprüfung zugänglich.
  • Anpassungen bei Rollenwechseln: Wenn ein Benutzer seine Rolle oder Aufgabe innerhalb der Organisation wechselt, werden die mit der vorherigen Rolle verbundenen Zugriffsrechte überprüft und entweder entfernt oder angepasst. Das Zugriffsprofil der neuen Rolle wird angewandt, und überschüssige Rechte aus der vorherigen Rolle werden innerhalb von fünf Arbeitstagen ab Inkrafttreten der Rollenänderung entzogen.
  • Entfernung physischer & logischer Zugriffe: Wenn Zugriffsrechte entzogen werden, werden sowohl physische als auch logische Zugriffsmechanismen adressiert. Dies umfasst Entfernung, Widerruf oder Ersatz von Schlüsseln, Ausweisen, Chipkarten, Authentisierungstoken, Abonnements und Systemkontozugängen. Physische Zugangsmedien werden zurückgegeben und dokumentiert.
  • Änderungsaufzeichnungen: Alle Änderungen an logischen und physischen Zugriffsrechten der Benutzer werden mit Zeitstempel, Identität der genehmigenden Person, Identität des umsetzenden Administrators und Art der Änderung protokolliert. Dieses Änderungsprotokoll wird gemäß der Aufbewahrungsrichtlinie der Organisation aufbewahrt und ist für Audits verfügbar.

6.2 Überprüfung von Zugriffsrechten

  • Überprüfung nach organisatorischen Änderungen: Die Zugriffsrechte der Benutzer werden nach jeder organisatorischen Änderung überprüft — einschließlich Aufgabenwechseln, Beförderungen, Degradierungen und Beendigungen des Beschäftigungsverhältnisses. Die Überprüfung verifiziert, dass die aktuellen Zugriffsrechte der tatsächlichen Rolle und Verantwortung des Benutzers entsprechen.
  • Überprüfung privilegierter Zugriffe: Berechtigungen für privilegierte Zugriffsrechte werden mindestens vierteljährlich und nach jeder organisatorischen Änderung, die Personen mit privilegiertem Zugriff betrifft, überprüft. Die Überprüfung bestätigt, dass jedes privilegierte Konto weiterhin gerechtfertigt ist, dass Kompetenz und Vertrauenswürdigkeit des Kontoinhabers die Privilegien weiterhin rechtfertigen und dass der Zugriffsumfang weiterhin das notwendige Minimum darstellt.

6.3 Überlegungen vor Änderung oder Beendigung

  • Bewertung von Initiator & Grund: Wenn eine Änderung oder Beendigung des Beschäftigungsverhältnisses eintritt, werden die Umstände bewertet: ob die Änderung vom Benutzer oder vom Management initiiert wurde, und der Grund der Änderung. Management-initiierte Beendigungen und Kündigungen erfordern eine sofortige Zugriffsüberprüfung, da verärgerte Personen versuchen könnten, Informationen zu verfälschen oder Systeme zu sabotieren.
  • Aktuelle Verantwortlichkeiten: Die aktuellen Verantwortlichkeiten des Benutzers werden bewertet, um festzustellen, welche Zugriffsrechte sofortige Aufmerksamkeit erfordern. Benutzer mit Zugang zu sensiblen oder geschäftskritischen Systemen erhalten einen beschleunigten Zugriffsentzug.
  • Bewertung des Asset-Werts: Der Wert und die Sensibilität der für den Benutzer aktuell zugänglichen Assets werden bewertet. Der Zugriff auf hochwertige Assets (Systeme mit klassifizierten Informationen, Finanzdaten oder personenbezogenen Daten) wird während der Übergangsphase priorisiert entzogen oder eingeschränkt.

6.4 Rollenbasierte Zugriffskontrolle

  • Rollendefinition: Benutzerzugriffsrollen werden basierend auf geschäftlichen Anforderungen etabliert. Jede Rolle fasst eine Reihe von Zugriffsrechten zu einem Standardzugriffsprofil zusammen, das typische Aufgabenfunktionen widerspiegelt. Standardrechteprofile werden für jede Funktion und Stellenbeschreibung definiert. Rollen werden dokumentiert, von der jeweiligen Fachabteilung genehmigt und jährlich überprüft.
  • Verwaltung auf Rollenebene: Zugriffsanfragen und Zugriffsüberprüfungen werden auf der Ebene der Benutzerzugriffsrollen verwaltet und nicht auf der Ebene einzelner Zugriffsrechte. Wenn sich die Rolle eines Benutzers ändert, wird das entsprechende rollenbasierte Zugriffsprofil angewandt, statt die Zugriffsrechte eines anderen Benutzers zu klonen. Das Klonen wird vermieden, da es das Risiko birgt, im Laufe der Zeit übermäßige Zugriffsrechte anzusammeln.

6.5 Vertragliche Regelungen

  • Vertragliche Sanktionen: Arbeits- und Dienstleistungsverträge enthalten Klauseln zu Sanktionen bei versuchtem unbefugtem Zugriff. Diese Klauseln sind mit dem Disziplinarverfahren abgestimmt und werden von der Rechtsabteilung auf Durchsetzbarkeit unter dem geltenden Arbeits- und Vertragsrecht geprüft.

7. Privilegierte Zugriffsrechte (A 8.2)

Privilegierte Zugriffsrechte — diejenigen, die administrative oder systemnahe Tätigkeiten jenseits des Umfangs von Standardbenutzern ermöglichen — werden durch einen dedizierten Autorisierungsprozess gesteuert. Dies umfasst Systemadministrator-Rollen, Datenbankadministrator-Rollen, Root- und Domänenadministrator-Zugriff sowie jeden Zugriff, der die Änderung von Systemkonfigurationen, Sicherheitseinstellungen oder Audit-Protokollen ermöglicht. Konten mit erhöhten Privilegien werden mit Multi-Faktor-Authentisierung geschützt. Standardrechteprofile für administrative Rollen werden gepflegt und regelmäßig überprüft. Für Systeme mit erhöhtem Schutzbedarf wird das Vier-Augen-Prinzip auf kritische administrative Tätigkeiten angewendet.

7.1 Identifikation & Zuweisung

  • Identifikation privilegierter Benutzer: Für jedes System oder Prozess — einschließlich Betriebssysteme, Datenbankverwaltungssysteme und Anwendungen — werden die Personen, die privilegierte Zugriffsrechte benötigen, explizit identifiziert und dokumentiert. Die Liste privilegierter Benutzer pro System wird vom IT-Betrieb geführt und mindestens vierteljährlich überprüft.
  • Bedarfs- und ereignisorientierte Zuweisung: Privilegierte Zugriffsrechte werden strikt nach Bedarf zugewiesen und, wo möglich, ereignisbasiert im Einklang mit dieser Zugriffskontroll-Richtlinie. Privilegierter Zugriff wird nur Personen mit der erforderlichen Kompetenz zur Durchführung der betreffenden Tätigkeiten und nur im minimalen, für ihre funktionale Rolle erforderlichen Umfang gewährt.
  • Autorisierungsprozess & Aufzeichnung: Ein dokumentierter Autorisierungsprozess legt fest, wer privilegierte Zugriffsrechte genehmigen darf. Privilegierter Zugriff wird erst gewährt, wenn der Autorisierungsprozess vollständig durchlaufen und dokumentiert ist. Ein zentrales Verzeichnis aller vergebenen Privilegien — einschließlich der genehmigenden Person, des Umfangs der Privilegien und des Zuweisungsdatums — wird geführt und gegen unbefugte Änderungen geschützt.
  • Ablaufanforderungen: Privilegierte Zugriffsrechte haben definierte Ablaufdaten. Dauerhafte privilegierte Zugriffe werden mindestens vierteljährlich überprüft. Wo technisch machbar, wird privilegierter Zugriff als zeitlich begrenzte Sitzung gewährt, die nach dem genehmigten Wartungsfenster oder der Aufgabendauer automatisch abläuft.

7.2 Sensibilisierung & Authentisierung

  • Bewusstsein für Privilegien: Benutzer werden sich ihrer privilegierten Zugriffsrechte bewusst gemacht und wissen, wann sie im privilegierten Zugriffsmodus operieren. Sensibilisierungsmaßnahmen umfassen die Verwendung getrennter administrativer Benutzeridentitäten (separat von Standardkonten), visuelle Indikatoren in der Benutzeroberfläche (z. B. farblich gekennzeichnete Eingabeaufforderungen) und, wo angemessen, dedizierte Admin-Workstations oder Jump-Server.
  • Verstärkte Authentisierung: Die Authentisierungsanforderungen für privilegierten Zugriff sind höher als für Standardzugriff. Multi-Faktor-Authentisierung ist für alle privilegierten Konten verpflichtend. Eine erneute Authentisierung oder Step-up-Authentisierung ist vor der Durchführung von Arbeiten mit privilegierten Zugriffsrechten erforderlich, insbesondere beim Wechsel von einer Standard- zu einer privilegierten Sitzung. Für Systeme mit erhöhtem Schutzbedarf wird Multi-Faktor-Authentisierung auf alle Konten angewendet.

7.3 Überprüfung & Lebenszyklus

  • Regelmäßige Überprüfung: Benutzer mit privilegierten Zugriffsrechten werden regelmäßig überprüft — mindestens vierteljährlich — sowie nach jeder organisatorischen Änderung. Die Überprüfung verifiziert, dass Aufgaben, Rolle, Verantwortlichkeiten und Kompetenz jeder Person weiterhin privilegierten Zugriff rechtfertigen. Privilegierter Zugriff, der nicht mehr gerechtfertigt ist, wird umgehend entzogen.
  • Generische Administrationskonten: Die Nutzung generischer Administrations-Benutzerkennungen (wie „root", „admin" oder „sa") wird vermieden, wo die Systemkonfiguration dies erlaubt. Wo generische Konten nicht eliminiert werden können (z. B. systemebene Root-Konten), werden ihre Anmeldedaten über ein Privileged-Access-Management-Tool (PAM) verwaltet, regelmäßig geändert, und Zugriffe darauf werden mit individueller Zurechenbarkeit protokolliert.
  • Temporärer privilegierter Zugriff (Break Glass): Privilegierter Zugriff wird als temporärer Zugriff für das zur Umsetzung genehmigter Änderungen oder Tätigkeiten erforderliche Zeitfenster gewährt — zum Beispiel für Wartungsarbeiten oder kritische Änderungen. Dauerhafter privilegierter Zugriff wird vermieden, wo Just-in-Time-Bereitstellung technisch umsetzbar ist. Notfallzugriffs-Verfahren („Break Glass") sind dokumentiert, und jede Nutzung des Notfallzugriffs wird protokolliert und innerhalb von 24 Stunden überprüft.

7.4 Protokollierung & Trennung

  • Audit-Protokollierung: Alle privilegierten Zugriffe auf Systeme werden zu Audit-Zwecken protokolliert. Protokolle erfassen die Identität des Benutzers, das zugegriffene System, die durchgeführten Aktionen, den Zeitstempel und die Sitzungsdauer. Privilegierte Zugriffsprotokolle sind gegen Manipulation durch die Kontoinhaber selbst geschützt und werden regelmäßig von der/dem Informationssicherheitsbeauftragten überprüft.
  • Individuelle privilegierte Identitäten: Identitäten mit privilegierten Zugriffsrechten werden nicht geteilt oder mit mehreren Personen verknüpft. Jede Person, die privilegierten Zugriff benötigt, erhält eine separate, namentlich benannte administrative Identität. Identitäten können in Gruppen zusammengefasst werden (z. B. in einer Admin-Gruppe), um die Verwaltung zu vereinfachen, doch jedes Gruppenmitglied behält seine individuelle Identität zur Zurechenbarkeit.
  • Trennung von administrativen & Standardaktivitäten: Identitäten mit privilegierten Zugriffsrechten werden ausschließlich für administrative Aufgaben verwendet. Tägliche Aktivitäten — wie das Lesen von E-Mails, das Browsen im Web oder das Bearbeiten von Dokumenten — werden unter einer separaten Standard-Benutzeridentität ausgeführt. Benutzer mit administrativen Verantwortlichkeiten pflegen mindestens zwei Konten: eines für administrative Arbeit und eines für reguläre Tätigkeiten.

8. Einschränkung des Informationszugriffs (A 8.3)

Der Zugriff auf Informationen und andere zugehörige Assets wird gemäß dieser Zugriffskontroll-Richtlinie eingeschränkt. Zugriffsbeschränkungen werden auf Anwendungs-, System- und Netzwerkebene durchgesetzt. Für jedes System und jede Anwendung existiert eine schriftliche Zugriffsregelung, die festlegt, welche Identitäten und Gruppen welches Zugriffsniveau haben. Die Organisation unterscheidet zwischen Zutritt (physischer Zugang), Zugang (Systemzugang) und Zugriff (Datenzugriff) und verwaltet alle drei Kategorien durch formal definierte Prozesse.

8.1 Grundlegende Zugriffsbeschränkungen

  • Kein anonymer Zugriff auf sensible Informationen: Der Zugriff auf sensible Informationen durch unbekannte Benutzeridentitäten oder anonym ist nicht gestattet. Öffentlicher oder anonymer Zugriff wird nur Speicherorten und Diensten gewährt, die keine sensiblen oder klassifizierten Informationen enthalten. Jeder Zugriff auf klassifizierte Informationen erfordert eine authentisierte Benutzeridentifikation.
  • Konfigurationsmechanismen: Systeme, Anwendungen und Dienste stellen Konfigurationsmechanismen zur Steuerung des Informationszugriffs bereit. Dazu gehören Zugriffskontrolllisten (ACLs), rollenbasierte Zugriffskontrollen, attributbasierte Zugriffskontrollen und Dateisystem-Berechtigungen. Zugriffskontroll-Konfigurationen werden dokumentiert und als Teil der System-Basiskonfiguration verwaltet.
  • Datenebenen-Zugriffskontrolle: Welche Daten ein bestimmter Benutzer zugreifen kann, wird basierend auf der Rolle des Benutzers, der Klassifizierungsstufe der Daten und dem dokumentierten Need-to-know des Benutzers gesteuert. Datenbank-Views, Row-Level-Security und Filter auf Anwendungsebene werden eingesetzt, wo granularer Datenzugriff erforderlich ist.
  • Zuordnung Identität zu Berechtigung: Für jedes System ist explizit definiert und dokumentiert, welche Identitäten oder Gruppen von Identitäten welche Zugriffsrechte haben — einschließlich Lese-, Schreib-, Lösch- und Ausführungsberechtigungen. Berechtigungen werden Rollen zugewiesen statt einzelnen Identitäten, wo immer möglich.
  • Isolierung sensibler Systeme: Physische oder logische Zugriffskontrollen werden eingesetzt, um sensible Anwendungen, Anwendungsdaten und Systeme von weniger sensiblen Umgebungen zu isolieren. Netzwerksegmentierung, dedizierte VLANs, Firewalls und Application-Layer-Gateways setzen Isolationsgrenzen durch. Der Zugriff auf isolierte Umgebungen erfordert eine separate Authentisierung und Autorisierung.

8.2 Dynamisches Zugriffsmanagement — Anwendungsfälle

  • Granulare zeit- und methodenbasierte Steuerung: Dynamische Zugriffsmanagement-Techniken werden angewendet, wenn die Organisation granulare Kontrolle darüber benötigt, wer wann und auf welche Weise auf bestimmte Informationen zugreift — über das hinaus, was statische rollenbasierte Kontrollen bieten.
  • Externe Weitergabe mit Kontrollerhalt: Wenn Informationen mit Personen oder Entitäten außerhalb der Organisation geteilt werden, wird dynamisches Zugriffsmanagement eingesetzt, um die Kontrolle darüber zu behalten, wer auf die geteilten Inhalte zugreifen kann, wie lange und mit welchen Berechtigungen. Der Zugriff kann jederzeit entzogen werden, ohne dass der Empfänger die Information zurückgeben oder löschen muss.
  • Echtzeit-Verwaltung der Verteilung: Für Informationen, die eine Echtzeitsteuerung ihrer Verteilung erfordern, ermöglicht dynamisches Zugriffsmanagement die sofortige Anpassung von Zugriffsberechtigungen, wenn sich Umstände ändern — zum Beispiel Einschränkung des Zugriffs bei Einleitung einer Untersuchung oder Erweiterung des Zugriffs bei wachsenden Projektteams.
  • Schutz vor unbefugter Änderung & Verteilung: Dynamische Zugriffskontrollen schützen Informationen vor unbefugten Änderungen, Kopien, Drucken und Weiterverteilung. Dokumentenebenen-Rechteverwaltung setzt diese Beschränkungen unabhängig vom Speicherort oder Übertragungsweg durch.
  • Überwachung der Nutzung: Dynamisches Zugriffsmanagement ermöglicht die Überwachung der Informationsnutzung — die Nachverfolgung, wer auf bestimmte Informationen zugegriffen hat, wann und welche Aktionen durchgeführt wurden — zur Unterstützung von Sicherheitsüberwachung und Compliance-Anforderungen.
  • Änderungsaufzeichnung für Untersuchungen: Alle Änderungen an dynamisch geschützten Informationen werden erfasst, um potenzielle zukünftige Untersuchungen zu unterstützen. Das Änderungsprotokoll erfasst die Identität der ändernden Person, die Art der Änderung und den Zeitstempel.

8.3 Dynamisches Zugriffsmanagement — Regeln

  • Dynamische Zugriffsregeln: Regeln für dynamisches Zugriffsmanagement werden basierend auf konkreten Anwendungsfällen aufgestellt. Zugriffsberechtigungen können an Identität, Gerätezustand, Standort und Anwendungskontext gebunden werden. Das Klassifizierungsschema bestimmt, welche Informationskategorien durch dynamische Zugriffsmanagement-Techniken geschützt werden müssen. Zero-Trust-Prinzipien werden angewandt, wo das Risikoprofil es rechtfertigt: Jeder Zugriffsantrag wird verifiziert, unabhängig vom Netzwerkstandort oder dem vorherigen Authentisierungsstatus.
  • Betriebs- & Überwachungsinfrastruktur: Operative Prozesse, Überwachungsverfahren und Berichtsfähigkeiten sind eingerichtet, um dynamisches Zugriffsmanagement zu unterstützen. Die für Echtzeit-Zugriffsbewertung, Policy-Durchsetzung und Audit-Protokollierung erforderliche technische Infrastruktur wird vom IT-Betrieb gepflegt und regelmäßig getestet.

8.4 Dynamisches Zugriffsmanagement — Mechanismen

  • Anforderungen an Authentisierung & Anmeldedaten: Der Zugriff auf dynamisch geschützte Informationen erfordert eine Authentisierung mit geeigneten Anmeldedaten oder einem digitalen Zertifikat. Anonymer Zugriff auf dynamisch geschützte Inhalte ist nicht gestattet.
  • Zeitlich begrenzter Zugriff: Der Zugriff auf bestimmte Informationen kann auf definierte Zeitfenster beschränkt werden — zum Beispiel Gewährung des Zugriffs erst nach einem bestimmten Datum oder Entzug nach einem angegebenen Ablaufdatum. Zeitlich begrenzte Beschränkungen werden vom Zugriffsmanagementsystem automatisch durchgesetzt.
  • Verschlüsselungsbasierter Schutz: Verschlüsselung wird eingesetzt, um Informationen im Ruhezustand und während der Übertragung zu schützen. Der Zugriff auf den Entschlüsselungsschlüssel ist selbst ein Zugriffskontrollmechanismus, der einschränkt, wer die geschützten Inhalte lesen kann.
  • Druckberechtigungen: Druckberechtigungen für klassifizierte oder sensible Informationen werden pro Klassifizierungsstufe und Benutzerrolle definiert. Das Drucken von Informationen der höchsten Klassifizierungsstufe ist standardmäßig eingeschränkt oder deaktiviert und erfordert eine ausdrückliche Genehmigung.
  • Zugriffsaufzeichnung: Wer auf dynamisch geschützte Informationen zugreift und wie die Informationen genutzt werden (Anzeigen, Bearbeiten, Drucken, Herunterladen, Weiterleiten), wird in einem Audit Trail erfasst. Zugriffsaufzeichnungen werden gemäß der Aufbewahrungsrichtlinie der Organisation aufbewahrt.
  • Missbrauchswarnungen: Automatische Warnungen werden ausgelöst, wenn Missbrauchsversuche an dynamisch geschützten Informationen erkannt werden — zum Beispiel wiederholte unbefugte Zugriffsversuche, Massendownloads über normale Muster hinaus oder Zugriffe von ungewöhnlichen Standorten oder Geräten außerhalb der Geschäftszeiten.

Dynamische Zugriffsmanagement-Techniken ersetzen nicht die klassische Zugriffsverwaltung (z. B. Zugriffskontrolllisten), sondern ergänzen zusätzliche Faktoren für Bedingtheit, Echtzeit-Bewertung, Just-in-Time-Datenreduktion und andere Verbesserungen, die besonders für die sensibelsten Informationen nützlich sind. Die Vorfallreaktion wird durch dynamisches Zugriffsmanagement unterstützt, da Berechtigungen jederzeit geändert oder entzogen werden können.

9. Zugriff auf Quellcode (A 8.4)

Der Zugriff auf Programmquellcode, zugehörige Artefakte (Entwürfe, Spezifikationen, Verifizierungs- und Validierungspläne) und Entwicklungswerkzeuge (Compiler, Builder, Integrationswerkzeuge, Test-Plattformen) ist streng kontrolliert. Quellcode wird zentral in einem Quellcode-Verwaltungssystem gespeichert. Der Zugriff auf Quellcode-Bibliotheken wird gesteuert, um das Risiko einer Korruption von Computerprogrammen zu reduzieren.

9.1 Zugriffskontrollen für Quellcode

  • Verwalteter Quellcode-Zugriff: Der Zugriff auf Programmquellcode und Quellcode-Bibliotheken wird nach etablierten Verfahren verwaltet. Zugriffsrechte werden bei Teamwechseln sowie bei Projektabschluss oder -einstellung überprüft.
  • Lese- und Schreibzugriff nach geschäftlichem Bedarf: Lese- und Schreibzugriff auf Quellcode wird basierend auf dokumentiertem geschäftlichem Bedarf gewährt und so verwaltet, dass Risiken unbefugter Änderung oder unsachgemäßer Nutzung adressiert werden. Schreibzugriff ist auf Entwickler beschränkt, die aktiv an den relevanten Codekomponenten arbeiten. Lesezugriff wird zusätzlichen Rollen (z. B. Code-Reviewer, Security-Tester) nur bei Bedarf gewährt.
  • Zentralisierter Repository-Zugriff: Wo Codekomponenten von mehreren Entwicklern innerhalb der Organisation verwendet werden, wird der Zugriff über ein zentralisiertes Code-Repository mit Lesezugriff als Standard für Konsumenten bereitgestellt. Schreibzugriff auf gemeinsam genutzte Komponenten ist auf benannte Maintainer beschränkt.
  • Drittanbieter- & Open-Source-Code: Der Zugriff auf Open-Source-Code und Drittanbieter-Codekomponenten, die innerhalb der Organisation verwendet werden, wird über Lesezugriff aus einem kuratierten internen Repository oder einer genehmigten Paket-Registry bereitgestellt. Die direkte Modifikation von Drittanbieter-Quellcode wird über ein dokumentiertes Fork- und Patch-Verfahren gesteuert.
  • Änderungsgesteuerte Aktualisierungen: Aktualisierungen von Quellcode und zugehörigen Artefakten werden gemäß Change-Management-Verfahren durchgeführt. Der Zugriff auf Quellcode zum Zweck von Änderungen wird erst nach einer geeigneten Autorisierung durch den Code-Eigentümer oder eine benannte Genehmigungsinstanz gewährt.
  • Indirekter Repository-Zugriff: Entwickler greifen nicht direkt auf Dateisystemebene auf das Quellcode-Repository zu. Alle Zugriffe werden über Entwicklerwerkzeuge (Versionskontroll-Clients, IDE-Integrationen, CI/CD-Pipelines) vermittelt, die Aktivitäten und Autorisierungen am Quellcode steuern und protokollieren.
  • Sichere Speicherung: Programmlistings und Quellcode-Archive werden in einer sicheren Umgebung aufbewahrt. Lese- und Schreibzugriff auf diese Speicherorte wird angemessen verwaltet und basierend auf dokumentierten Rollen zugewiesen. Sicherungskopien von Quellcode-Repositories sind verschlüsselt und werden gemäß der Backup-Richtlinie gespeichert.
  • Audit-Protokoll: Ein Audit-Protokoll aller Zugriffe auf und aller Änderungen an Quellcode wird vom Quellcode-Verwaltungssystem geführt. Das Audit-Protokoll erfasst die Identität der Person oder des Prozesses, die zugegriffenen Dateien oder Repositories, die Art der Aktion (Lesen, Schreiben, Merge, Löschen) und den Zeitstempel. Audit-Protokolle sind gegen Änderungen geschützt und werden gemäß der Protokollaufbewahrungsrichtlinie der Organisation aufbewahrt.
  • Code-Integritätskontrollen: Wenn Quellcode zur Veröffentlichung oder Verteilung vorgesehen ist, bieten zusätzliche Kontrollen Zusicherung über die Integrität des Codes. Dazu gehören digitale Signaturen auf Commits und Releases, kryptographische Prüfsummen für verteilte Pakete und signierte Tags im Versionskontrollsystem.

10. Sichere Authentisierung (A 8.5)

Für jedes System wird eine geeignete Authentisierungstechnik basierend auf der Klassifizierung der zuzugreifenden Informationen und dem Schutzbedarf des Systems ausgewählt. Für jedes IT-System und jede Anwendung wird ein Authentisierungskonzept entwickelt, das die geltenden funktionalen und Sicherheitsanforderungen definiert. Wo eine starke Authentisierung und Identitätsprüfung erforderlich ist, werden alternative oder zusätzliche Authentisierungsmethoden zu Passwörtern — wie digitale Zertifikate, Smartcards, Hardware-Token oder biometrische Verfahren — eingesetzt. Authentisierungsinformationen für kritische Systeme werden durch zusätzliche Authentisierungsfaktoren (Multi-Faktor-Authentisierung) ergänzt. Dem Schutzbedarf angemessene Authentisierungsmechanismen werden verwendet; nach jedem fehlgeschlagenen Authentisierungsversuch werden weitere Versuche zunehmend verzögert (Time Delay), und nach Überschreiten der definierten Anzahl fehlgeschlagener Versuche wird das Konto gesperrt. Die Benutzertrennung wird periodisch verifiziert: Benutzer melden sich nach Abschluss ihrer Aufgaben ab, und mehrere Benutzer arbeiten nicht unter derselben Identität.

10.1 Anmeldeverfahren & Technologien

  • Einschränkung der Vorauth-Informationen: Sensible System- oder Anwendungsinformationen werden erst nach erfolgreichem Abschluss des Anmeldevorgangs angezeigt. Anmeldebildschirme zeigen nur die für die Authentisierung notwendige Mindestinformation und offenbaren weder Systemnamen, Software-Versionen, interne IP-Adressen noch andere Details, die einem unbefugten Benutzer helfen könnten.
  • Hinweis für autorisierte Benutzer: Auf allen Anmeldebildschirmen wird ein allgemeiner Hinweis angezeigt, der warnt, dass das System, die Anwendung oder der Dienst nur von autorisierten Benutzern genutzt werden darf. Dieser Hinweis informiert Benutzer, dass Zugriffe protokolliert werden und unbefugte Zugriffsversuche disziplinarische und rechtliche Konsequenzen haben können.
  • Keine diagnostischen Hilfemeldungen: Während des Anmeldevorgangs werden keine Hilfemeldungen bereitgestellt, die einem unbefugten Benutzer helfen könnten. Bei einem Authentisierungsfehler zeigt das System nicht an, welcher Teil der eingereichten Daten (Benutzername oder Passwort) falsch ist. Stattdessen wird eine generische Fehlermeldung (z. B. „Authentisierung fehlgeschlagen") angezeigt.
  • Verzögerte Validierung: Anmeldedaten werden erst validiert, nachdem alle erforderlichen Eingabedaten eingereicht wurden. Partielle Validierungen — etwa die Bestätigung der Existenz eines Benutzernamens vor der Passwortabfrage — werden nicht durchgeführt, um User-Enumeration-Angriffe zu verhindern.
  • Brute-Force-Schutz: Systeme werden gegen Brute-Force-Anmeldeversuche geschützt. Schutzmaßnahmen umfassen progressive Verzögerung nach fehlgeschlagenen Versuchen (Time Delay), CAPTCHA-Abfragen nach einer definierten Anzahl Fehlversuche, verpflichtenden Passwort-Reset nach einer Schwellenanzahl fehlgeschlagener Versuche und Kontosperrung nach einer maximalen Anzahl aufeinanderfolgender Fehler. Die spezifischen Schwellen werden pro System basierend auf dessen Risikoprofil definiert.
  • Protokollierung von Authentisierungsereignissen: Sowohl erfolgreiche als auch fehlgeschlagene Authentisierungsversuche werden protokolliert. Protokolleinträge enthalten den Zeitstempel, die versuchte Benutzeridentität, die Quell-IP-Adresse oder Gerätekennung und das Ergebnis (Erfolg oder Fehlschlag). Authentisierungsprotokolle sind gegen Manipulation geschützt und werden gemäß der Protokollierungsrichtlinie aufbewahrt.
  • Sicherheits-Event-Benachrichtigung: Ein Sicherheitsereignis wird ausgelöst, wenn ein potenzieller Verstoß gegen Anmeldesicherheitskontrollen erkannt wird. Warnungen werden an den Benutzer (sofern das Konto nicht gesperrt ist) und an den IT-Betrieb gesendet, wenn eine definierte Anzahl fehlgeschlagener Authentisierungsversuche für ein einzelnes Konto erreicht wird, wenn Authentisierungsanomalien erkannt werden (z. B. gleichzeitige Sitzungen von verschiedenen Standorten) oder wenn eine erfolgreiche Authentisierung auf mehrere fehlgeschlagene Versuche folgt.
  • Post-Login-Sicherheitsübersicht: Nach erfolgreichem Abschluss einer Anmeldung werden folgende Informationen angezeigt oder über einen separaten Kanal versendet: Datum und Uhrzeit der vorherigen erfolgreichen Anmeldung und Details zu allen erfolglosen Anmeldeversuchen seit der letzten erfolgreichen Anmeldung. Dies ermöglicht Benutzern, eine unbefugte Nutzung ihres Kontos zu erkennen.
  • Maskierung der Passworteingabe: Passwörter werden während der Eingabe nicht im Klartext angezeigt. Eingabefelder maskieren Passwortzeichen standardmäßig. Wo eine temporäre Einblendefunktion zur Barrierefreiheit oder Fehlerreduzierung bereitgestellt wird, wird sie nur auf ausdrückliche Anfrage des Benutzers aktiviert und nach einer kurzen Zeit automatisch deaktiviert.
  • Verschlüsselte Netzwerkübertragung: Passwörter und andere Authentisierungsdaten werden nicht im Klartext über Netzwerke übertragen. Der gesamte Authentisierungsverkehr verwendet verschlüsselte Protokolle (z. B. TLS, SSH). Authentisierungsverkehr im Intranet ist ebenfalls verschlüsselt, um Abfangen durch Netzwerk-Sniffing zu verhindern.
  • Sitzungs-Timeout: Inaktive Sitzungen werden nach einem definierten Inaktivitätszeitraum beendet. Die Timeout-Dauer wird basierend auf dem Risikoprofil des Systems konfiguriert: Hochrisiko-Systeme (z. B. solche, die aus öffentlichen oder externen Bereichen zugänglich sind) verwenden kürzere Timeouts; Standard-Interne-Systeme verwenden einen Standard-Timeout. Nach Timeout ist eine erneute Authentisierung zur Fortsetzung der Sitzung erforderlich.
  • Begrenzung der Verbindungsdauer: Für Hochrisiko-Anwendungen werden maximale Verbindungsdauern definiert, um das Zeitfenster für unbefugten Zugriff zu reduzieren. Verbindungen zu kritischen administrativen Schnittstellen werden nach einer definierten maximalen Sitzungsdauer unabhängig von Aktivität beendet und erfordern eine erneute Authentisierung.

Biometrische Authentisierungsinformationen werden ungültig gemacht, falls sie jemals kompromittiert werden. Da biometrische Authentisierung je nach Nutzungsbedingungen (z. B. Feuchtigkeit, Alterung, Verletzung) nicht verfügbar sein kann, wird sie immer von mindestens einer alternativen Authentisierungstechnik begleitet. Für Passwort-Reset-Verfahren ist ein sicherer Prozess definiert und umgesetzt, der die Identität der anfordernden Person vor der Ausgabe neuer Anmeldedaten verifiziert. Notfall- und Notlaufverfahren für das IAM-System sind eingerichtet, um den Weiterbetrieb sicherzustellen, falls das Identitäts- und Zugriffsmanagement-System nicht verfügbar ist.

11. Rollen & Verantwortlichkeiten

  • Geschäftsleitung: Genehmigt diese Richtlinie, stellt angemessene Ressourcen für das Identitäts- und Zugriffsmanagement bereit und unterstützt das IAM-Programm.
  • Informationssicherheitsbeauftragte/r (ISB): Ist Eigentümer dieser Richtlinie, definiert Zugriffskontrollregeln, überprüft privilegierte Zugriffsgenehmigungen, überwacht die Einhaltung der Zugriffskontrollanforderungen und genehmigt Ausnahmen. Überprüft das Authentisierungskonzept für jedes IT-System und jede Anwendung.
  • IT-Betrieb: Implementiert und administriert Zugriffskontrollen in Systemen, Anwendungen und Infrastruktur. Verwaltet das Identitätsmanagementsystem, das Passwortverwaltungssystem und die PAM-Werkzeuge. Konfiguriert Authentisierungsmechanismen, pflegt Zugriffsprotokolle und führt Zugriffsbereitstellungs- und Entzugsanforderungen aus. Betreibt den zentralen Authentisierungsdienst.
  • Informations- & Asset-Eigentümer: Genehmigen Zugriffe auf die Informationen und Assets unter ihrer Eigentümerschaft. Definieren Zugriffsanforderungen und Klassifizierungsstufen. Beteiligen sich an periodischen Zugriffsüberprüfungen für ihre Assets.
  • Führungskräfte: Beantragen Zugriffsrechte für ihre Teammitglieder, genehmigen Zugriffsanträge innerhalb ihres Befugnisrahmens, melden dem IT-Betrieb zeitnah Personaländerungen (Neueinstellungen, Rollenwechsel, Austritte) und beteiligen sich an Zugriffsüberprüfungen für ihre Teams.
  • HR-Abteilung: Meldet dem IT-Betrieb Onboardings, Rollenwechsel, längere Abwesenheiten und Austritte, um die entsprechenden Identitätslebenszyklus-Aktionen auszulösen. Stellt sicher, dass Arbeitsverträge Verpflichtungen zu Authentisierungsinformationen und Sanktionsklauseln bei unbefugtem Zugriff enthalten.
  • Alle Beschäftigten: Halten diese Richtlinie ein, schützen ihre Authentisierungsinformationen, nutzen Zugriffsrechte nur zu autorisierten Zwecken, melden vermutete Zugriffskontroll-Verstöße oder Kompromittierungen von Anmeldedaten und nehmen an authentisierungsbezogenen Schulungs- und Sensibilisierungsprogrammen teil.

12. Überprüfung & Pflege

Diese Richtlinie und die zugehörigen Zugriffskontrollverfahren werden überprüft:

  • Mindestens jährlich, um eine fortlaufende Ausrichtung an aktuellen ISO/IEC 27002-, BSI-IT-Grundschutz-Empfehlungen und regulatorischen Anforderungen zu verifizieren.
  • Nach jedem wesentlichen zugriffskontrollbezogenen Sicherheitsvorfall, um Kontrolllücken zu identifizieren und Verbesserungen umzusetzen.
  • Wenn wesentliche organisatorische Änderungen eintreten — einschließlich Fusionen, Übernahmen, Umstrukturierungen oder Einführung neuer Geschäftsprozesse — die Zugriffsanforderungen oder den Identitätslebenszyklus betreffen.
  • Wenn neue Systeme, Anwendungen oder Plattformen eingeführt werden, die in das Identitäts- und Zugriffsmanagement-Rahmenwerk integriert werden müssen.
  • Bei Änderungen geltender Gesetze, Vorschriften oder vertraglicher Verpflichtungen, die Zugriffskontrollanforderungen betreffen (z. B. neue Datenschutzverordnungen, branchenspezifische Zugriffsregeln).
  • Nach Änderungen an der IAM-Systeminfrastruktur, der Authentisierungsdienstarchitektur oder PAM-Werkzeugen.

Privilegierte Zugriffsgenehmigungen werden mindestens vierteljährlich überprüft. Die Dokumentation von Benutzerkonten, Gruppen und Rechteprofilen wird mindestens jährlich überprüft und mit dem tatsächlichen Stand der Zugriffsrechte in allen Systemen abgeglichen. Ergebnisse der Zugriffsüberprüfungen werden dokumentiert, und festgestellte Abweichungen werden innerhalb einer definierten Frist behoben.

Quellen

Abgedeckte ISO-27001-Kontrollen

A.5.3 Aufgabentrennung A.5.15 Zugriffskontrolle A.5.16 Identitätsmanagement A.5.17 Authentifizierungsinformationen A.5.18 Zugriffsrechte A.8.2 Privilegierte Zugriffsrechte A.8.3 Einschränkung des Informationszugangs A.8.4 Zugang zu Quellcode A.8.5 Sichere Authentifizierung

Häufig gestellte Fragen

Wie viele Richtlinien brauche ich für Zugriffskontrolle?

Eine reicht. Unsere Vorlage deckt alle acht Annex-A-Controls (A 5.15–18 und A 8.2–8.5) in einem Dokument ab. Manche Organisationen teilen das Thema auf mehrere Dokumente auf — dann steigt der Pflegeaufwand, ohne dass der Audit-Nutzen wächst. Besser: ein Dokument, klare Abschnitte, konsistente Sprache.

Was ist der Unterschied zwischen Zutritt, Zugang und Zugriff?

Zutritt betrifft physische Räume (Gebäude, Serverraum). Zugang betrifft IT-Systeme (Anmeldung am Betriebssystem, VPN). Zugriff betrifft Daten (Lesen, Schreiben, Löschen). Das deutsche BSI-Grundschutz unterscheidet alle drei Kategorien explizit — und deine Richtlinie sollte das auch tun.

Muss ich ein PAM-Tool einsetzen?

ISO 27001 schreibt kein konkretes Tool vor, aber A 8.2 verlangt, dass privilegierte Zugriffe durch einen eigenen Autorisierungsprozess gesteuert werden. In der Praxis heißt das: Ab ca. 50 Mitarbeitenden ist ein Privileged-Access-Management-Tool (z.B. CyberArk, Delinea, open-source BastionZero) wirtschaftlich sinnvoller als manuelle Verwaltung.

Wie oft müssen Zugriffsrechte überprüft werden?

Privilegierte Zugriffe: mindestens vierteljährlich. Alle anderen: mindestens jährlich und nach jeder organisatorischen Änderung (Rollenwechsel, Austritt, Umstrukturierung). Dazu kommt ein sofortiger Review bei Sicherheitsvorfällen. In der Praxis scheitern viele Organisationen an der Vierteljahres-Kadenz für Privilegien — automatisierte Reports aus dem IAM-System helfen.

Brauche ich separate Admin-Konten?

Ja. Abschnitt 7.4 unserer Vorlage fordert explizit, dass Personen mit administrativen Rechten mindestens zwei Konten führen: eines für Admin-Aufgaben, eines für den Alltag (E-Mail, Browser, Dokumente). Das ist eine der häufigsten Anforderungen, die in Audits geprüft wird.

Was passiert mit Zugriffsrechten, wenn jemand die Abteilung wechselt?

Innerhalb von fünf Arbeitstagen müssen die alten Rechte überprüft und überschüssige Rechte entzogen werden. Gleichzeitig wird das Zugriffsprofil der neuen Rolle zugewiesen. Das klingt simpel, aber ohne einen sauberen Prozess zwischen HR und IT-Betrieb sammeln sich über Jahre Rechte an, die niemand mehr überblickt.