msolarczekandClaude Opus 4.8
b7d5df41d4
WP2.2 — Rendering-Doppelartikel (Variante B, Report §6):
- Variablen-Defaults ohne führenden Artikel: TOOL_TICKET „Ticketsystem",
TOOL_NAME „ISMS-Tool", TOOL_IAM „Entra ID / Active Directory".
- Fließtext angepasst: „im/in {{VAR}}" rendert nun korrekt („im Ticketsystem");
„über {{TOOL_TICKET}}" → „über das {{TOOL_TICKET}}"; TOOL_IAM (Adjektiv) mit
korrekter Deklination ausgeschrieben („über das zentrale Verzeichnis (…)",
„im zentralen Verzeichnis (…)"). Doppeldeutige Orte „bzw. ISMS-Tool" bereits in WP1 aufgelöst.
- Wert-Migration (Prisma-Migration, idempotent): strippt den führenden Artikel aus
bestehenden, nicht angepassten Variablenwerten — auch für Bestandsmandanten/Deploy.
WP4 — Feinschliff:
- F16 (R06 2.1.4): „mobiles Arbeiten" konkret verortet (Regelung, hinterlegt im ISMS-Tool).
- F21 (VA-10): abgeschnittene RACI-Spaltentexte vervollständigt.
- F18: 13 SEHR-HOCH-Sätze in den -elev-Blöcken in {{#if FLAG_VERY_HIGH_PROTECTION}}
ausgelagert → bei AL2 kein „Bei sehr hohem Schutzbedarf …" mehr.
Verifiziert: _verify.py Render 0 / Mapping sauber; Render-Gegenprobe mit echten
Defaults ohne „im das …"; AL2/AL3-Flag-Gegenprobe rückstandsfrei (SEHR-HOCH nur bei AL3);
Browser: R08 rendert „im Ticketsystem" und „über das zentrale Verzeichnis (Entra ID / Active Directory)".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
235 lines
12 KiB
Markdown
235 lines
12 KiB
Markdown
# Richtlinie Identitäts- und Zugriffsmanagement
|
||
|
||
| Dokumenteninformation | Wert |
|
||
|-----------------------|------|
|
||
| Dokumententyp | Richtlinie |
|
||
| Geltungsbereich | {{ISMS_SCOPE}} |
|
||
| Organisation | {{ORG_NAME}} |
|
||
| Verantwortlich | {{ROLE_IT_LEAD}} |
|
||
| Freigabe durch | {{ROLE_MANAGEMENT}} |
|
||
| Version | {{DOC_VERSION}} |
|
||
| Datum | {{DOC_DATE}} |
|
||
| Status | {{DOC_STATUS}} |
|
||
|
||
|
||
## 1. Zweck
|
||
|
||
Diese Richtlinie regelt Identifikationsmittel, sichere Anmeldung, Kontenverwaltung sowie Vergabe und Kontrolle von Zugriffsrechten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
|
||
|
||
## 2. Geltungsbereich
|
||
|
||
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
|
||
|
||
## 3. Anforderungen und Umsetzung
|
||
|
||
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
|
||
|
||
### 3.1 Umgang mit Identifikationsmitteln (ISA 4.1.1)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 4.1.1-M1 -->
|
||
- **[MUSS]** Die Anforderungen an den Umgang mit Identifikationsmitteln über den gesamten Lebenszyklus sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.1-S1 -->
|
||
- **[SOLL]** Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden.
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 4.1.1-H1 -->
|
||
- **[HOCH]** Eine Strategie zur Sperrung oder Ungültigmachung von Identifikationsmitteln im Verlustfall ist vorbereitet und soweit möglich umgesetzt. (C, I, A)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 4.1.1 -->
|
||
Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über das zentrale Verzeichnis ({{TOOL_IAM}}) vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07, siehe {{LINK:VA-03}}).
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 4.1.1-elev -->
|
||
Bei hohem Schutzbedarf besteht eine umgesetzte Strategie zur Sperrung/Ungültigmachung von Identifikationsmitteln im Verlustfall.
|
||
{{/if}}
|
||
|
||
### 3.2 Sichere Anmeldung (ISA 4.1.2)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 4.1.2-M1 -->
|
||
- **[MUSS]** Die Verfahren zur Benutzerauthentifizierung sind auf Basis einer Risikobewertung ausgewählt; mögliche Angriffsszenarien (z. B. direkte Erreichbarkeit über das Internet) wurden berücksichtigt.
|
||
<!-- REQ 4.1.2-M2 -->
|
||
- **[MUSS]** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.2-S1 -->
|
||
- **[SOLL]** Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevanten Anforderungen definiert und umgesetzt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.2-S2 -->
|
||
- **[SOLL]** Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktiken authentifiziert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.2-S3 -->
|
||
- **[SOLL]** Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. Privileged Access Management, Zwei-Faktor-Authentifizierung).
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 4.1.2-H1 -->
|
||
- **[HOCH]** Abhängig von der Risikobewertung sind Authentifizierung und Zugangskontrolle durch ergänzende Maßnahmen verstärkt (z. B. kontinuierliche Zugriffsüberwachung, starke Authentifizierung, automatische Abmeldung, Sperre bei Inaktivität, Brute-Force-Prävention). (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 4.1.2-V1 -->
|
||
- **[SEHR HOCH]** Vor dem Zugriff auf Daten mit sehr hohem Schutzbedarf werden Benutzer mittels starker Authentifizierung (z. B. Zwei-Faktor) nach dem Stand der Technik authentifiziert. (C, I)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 4.1.2 -->
|
||
Die Authentifizierungsverfahren sind risikobasiert ausgewählt und entsprechen dem Stand der Technik; Passwortvorgaben nach BL-IAM-01 (mind. {{PW_MIN_LENGTH}} Zeichen, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) werden über das zentrale Verzeichnis ({{TOOL_IAM}}) erzwungen. Für Fernzugriffe, administrative Zugänge und Cloud-Dienste wird MFA (BL-IAM-02) über {{TECH_MFA}} durchgesetzt; privilegierte Konten nutzen höherwertige Verfahren (PAM).
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 4.1.2-elev -->
|
||
Bei hohem Schutzbedarf sind Authentifizierung/Zugangskontrolle durch ergänzende Maßnahmen verstärkt (Zugriffsüberwachung, Auto-Logout BL-IAM-03, Sperre BL-IAM-04, Brute-Force-Schutz). {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf erfolgt der Zugriff nur nach starker Authentifizierung (Zwei-Faktor).{{/if}}
|
||
{{/if}}
|
||
|
||
### 3.3 Benutzerkonten und Anmeldeinformationen (ISA 4.1.3)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 4.1.3-M1 -->
|
||
- **[MUSS]** Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt.
|
||
<!-- REQ 4.1.3-M2 -->
|
||
- **[MUSS]** Eindeutige und personalisierte Benutzerkonten werden verwendet.
|
||
<!-- REQ 4.1.3-M3 -->
|
||
- **[MUSS]** Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollziehbarkeit verzichtbar ist).
|
||
<!-- REQ 4.1.3-M4 -->
|
||
- **[MUSS]** Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei Vertragsende).
|
||
<!-- REQ 4.1.3-M5 -->
|
||
- **[MUSS]** Benutzerkonten werden regelmäßig überprüft.
|
||
<!-- REQ 4.1.3-M6 -->
|
||
- **[MUSS]** Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt.
|
||
<!-- REQ 4.1.3-M7 -->
|
||
- **[MUSS]** Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S1 -->
|
||
- **[SOLL]** Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genutzt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S2 -->
|
||
- **[SOLL]** Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Sperren oder Passwortänderung).
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S3 -->
|
||
- **[SOLL]** Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S4 -->
|
||
- **[SOLL]** Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip).
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S5 -->
|
||
- **[SOLL]** Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S6 -->
|
||
- **[SOLL]** Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S7 -->
|
||
- **[SOLL]** Die Verwendung von Standardpasswörtern wird technisch verhindert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S8 -->
|
||
- **[SOLL]** Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S9 -->
|
||
- **[SOLL]** Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Kunden.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.1.3-S10 -->
|
||
- **[SOLL]** Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert.
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 4.1.3 -->
|
||
Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) (siehe {{LINK:VA-03}}) eindeutig personalisiert im zentralen Verzeichnis ({{TOOL_IAM}}) verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.
|
||
|
||
### 3.4 Zugriffsrechte (ISA 4.2.1)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 4.2.1-M1 -->
|
||
- **[MUSS]** Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
|
||
<!-- REQ 4.2.1-M2 -->
|
||
- **[MUSS]** Die für normale und privilegierte Benutzerkonten sowie technische Konten vergebenen Zugriffsrechte werden regelmäßig überprüft, auch in IT-Systemen von Kunden.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.2.1-S1 -->
|
||
- **[SOLL]** Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.2.1-S2 -->
|
||
- **[SOLL]** Autorisierungsrollen werden verwendet.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.2.1-S3 -->
|
||
- **[SOLL]** Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich vergeben.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.2.1-S4 -->
|
||
- **[SOLL]** Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 4.2.1-S5 -->
|
||
- **[SOLL]** Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisiert.
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 4.2.1-H1 -->
|
||
- **[HOCH]** Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmigt. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 4.2.1-V1 -->
|
||
- **[SEHR HOCH]** Informationen werden auf Inhaltsebene (z. B. Dateiebene) verschlüsselt gespeichert, um unbefugten Zugriff (auch privilegierter Nutzer) zu verhindern. Wo Verschlüsselung nicht machbar ist, greifen gleichwertige Maßnahmen. (C)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 4.2.1-V2 -->
|
||
- **[SEHR HOCH]** Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 4.2.1 -->
|
||
Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über das zentrale Verzeichnis ({{TOOL_IAM}}) vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}} (siehe {{LINK:VA-03}}). Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 4.2.1-elev -->
|
||
Bei hohem Schutzbedarf werden Zugriffsrechte durch den verantwortlichen internen Information Officer genehmigt. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden Informationen inhaltsverschlüsselt gespeichert (Schutz auch vor privilegierten Nutzern) und Zugriffsrechte in kürzeren Abständen (z. B. quartalsweise) überprüft.{{/if}}
|
||
{{/if}}
|
||
|
||
## 4. Verbindlichkeit
|
||
|
||
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
|
||
|
||
## 5. Rollen und Verantwortlichkeiten
|
||
|
||
| Rolle | Verantwortung in dieser Richtlinie |
|
||
|-------|-------------------------------------|
|
||
| {{ROLE_IT_LEAD}} | Technische Umsetzung IAM |
|
||
| Fachbereiche | Freigabe von Berechtigungen |
|
||
| {{ROLE_ISB}} | Überwachung |
|
||
|
||
## 6. Überprüfung und Aktualisierung
|
||
|
||
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
|
||
|
||
## 7. Nachweise
|
||
|
||
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
|
||
|
||
## 8. Verwandte Dokumente
|
||
|
||
- Zugehörige Verfahren: {{LINK:VA-03}}
|
||
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
|
||
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
|
||
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
|
||
- Weitere: {{LINK:R02}}, {{LINK:R05}}, {{LINK:R10}}
|
||
|
||
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
|