Richtlinien-Update: 316 Anforderungen/45 Controls + Schutzbedarf-/TISAX-Schalter

Delta-Update des VDA-ISA-2027-Vorlagenpakets eingepflegt:

- Aktualisiertes Seed-Paket (ersetzt bisherigen Stand): 316 Anforderungen
  (122 MUSS · 132 SOLL · 43 HOCH · 19 SEHR HOCH) über 45 Controls; VA-01/VA-05
  jetzt enthalten (13 Verfahren vollständig). Beschädigte RACI-Tokens (VA-05/08/09/
  10/12/13) repariert. Importer: Umsetzungstext aus den .md-IMPL-Ankern extrahiert
  (mapping.json führt ihn nicht mehr), neue Obligation-Typen HOCH/SEHR HOCH.
- Neue Schutzbedarf-Flags (variables.schema): FLAG_HIGH_PROTECTION,
  FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION (abgeleitet). Render-Helper
  applyProtection: HIGH stets an, VERY_HIGH aus Global/Override, ELEVATED = HIGH||VH
  (nie manuell) — angewandt in Lese-, Bearbeiten-, Handbuch- und Coverage-Rendering.
- TISAX-Level-Schalter (AL2/AL3) zentral auf der Bibliothek (setGlobalTisaxLevel);
  AL2 = MUSS/SOLL/HOCH, AL3 = zusätzlich SEHR HOCH. Override je Richtlinie im
  Bearbeitungsmodus (setProtectionOverride, Feld protection_override); effektiver
  Wert = Dokument-Override sonst global.
- KPIs zeigen 316 Anforderungen mit Aufschlüsselung; Coverage/Badges für HOCH/SEHR
  HOCH; Control-Titel-Fallback.

Verifiziert: Import 316/45; Rendering rückstandsfrei über AL2/AL3 × Flag-Kombis;
Override R04→AL3 zeigt SEHR-HOCH-Inhalt, R02 (global AL2) nicht; global bleibt AL2.

Architektur-Hinweis: applyProtection kapselt das Level→Flags-Mapping, sodass die
globale Ebene später ohne Umbau zur TISAX-AL2/AL3-Auswahl wird (bereits so gebaut).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

seed/isms-vorlagenpaket-v2/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md

@@ -14,7 +14,7 @@
 
 ## 1. Zweck
 
-Diese Richtlinie regelt Identifikationsmittel, die sichere Anmeldung, die Verwaltung von Benutzerkonten und Anmeldeinformationen sowie die Vergabe und Kontrolle von Zugriffsrechten. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
+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
 
@@ -22,98 +22,185 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 
 ## 3. Anforderungen und Umsetzung
 
-> Aufbau je Abschnitt: **Anforderung** (normativ, aus VDA ISA; [MUSS]/[SOLL]) und **Umsetzung bei {{ORG_NAME}}** (tatsächliche Ausgestaltung, anzupassen wo erforderlich).
-
-### 3.1 Identifikationsmittel (ISA 4.1.1)
+> 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]** Der Einsatz von Identifikationsmitteln (Benutzerkennungen, Token, Zertifikate) ist geregelt und eindeutig personenbezogen.
+- **[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]** Ausgabe, Rücknahme und Sperrung von Identifikationsmitteln sind dokumentiert.
+- **[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-M1 -->
-Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden eindeutig personenbezogen über {{TOOL_IAM}} vergeben; Sammelkonten werden vermieden bzw. dokumentiert und begründet.
-{{#if FLAG_INCLUDE_SHOULD}}
-<!-- IMPL 4.1.1-S1 -->
-Ausgabe, Rücknahme und Sperrung von Identifikationsmitteln werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).
+<!-- IMPL 4.1.1 -->
+Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über {{TOOL_IAM}} vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).
+
+{{#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]** Der Zugang zu IT-Diensten und IT-Systemen ist durch sichere Authentifizierungsverfahren geschützt.
+- **[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]** Für erhöhten Schutzbedarf und Fernzugriffe wird Mehr-Faktor-Authentifizierung (MFA) eingesetzt.
+- **[MUSS]** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.
 {{#if FLAG_INCLUDE_SHOULD}}
 <!-- REQ 4.1.2-S1 -->
-- **[SOLL]** Passwortanforderungen, Sperrmechanismen und Sitzungsverwaltung sind definiert.
+- **[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-M1 -->
-Der Zugang ist durch sichere Authentifizierung geschützt; die Passwortvorgaben nach BL-IAM-01 (mind. {{PW_MIN_LENGTH}} Zeichen, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) werden zentral über {{TOOL_IAM}} erzwungen.
-<!-- IMPL 4.1.2-M2 -->
-Für Fernzugriffe, administrative Zugänge und Cloud-Dienste wird MFA gemäß BL-IAM-02 über {{TECH_MFA}} durchgesetzt.
-{{#if FLAG_INCLUDE_SHOULD}}
-<!-- IMPL 4.1.2-S1 -->
-Sperrmechanismen (BL-IAM-04) und Sitzungs-Timeouts (BL-IAM-03) sind zentral konfiguriert.
+<!-- 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 zentral über {{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). Bei sehr hohem Schutzbedarf erfolgt der Zugriff nur nach starker Authentifizierung (Zwei-Faktor).
 {{/if}}
 
-### 3.3 Konten und Anmeldeinformationen (ISA 4.1.3)
-
+### 3.3 Benutzerkonten und Anmeldeinformationen (ISA 4.1.3)
 
 **Anforderung**
 
 <!-- REQ 4.1.3-M1 -->
-- **[MUSS]** Benutzerkonten und Anmeldeinformationen werden sicher verwaltet (Erstellung, Aenderung, Sperrung, Löschung).
+- **[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]** Privilegierte und technische Konten werden gesondert verwaltet und überwacht.
+- **[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-M1 -->
-Konten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen.
-{{#if FLAG_INCLUDE_SHOULD}}
-<!-- IMPL 4.1.3-S1 -->
-Privilegierte und technische Konten werden gesondert verwaltet, einzeln zugeordnet und verstärkt protokolliert (BL-IAM-06).
-{{/if}}
+<!-- IMPL 4.1.3 -->
+Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) eindeutig personalisiert in {{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]** Zugriffsrechte werden nach dem Minimalprinzip (need-to-know / least privilege) vergeben; Verfahren für Antrag, Prüfung und Genehmigung bestehen.
+- **[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]** Zugriffsrechte werden bei Wegfall des Bedarfs entzogen und regelmäßig überprüft (Rezertifizierung){{#if FLAG_CUSTOMER_SYSTEMS}}, auch für Zugriffe in Kundensystemen{{/if}}.
+- **[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]** Berechtigungen werden über Rollen vergeben; normale Konten erhalten keine privilegierten Rechte.
+- **[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-M1 -->
-Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}.
-<!-- IMPL 4.2.1-M2 -->
-Berechtigungen werden beim Wegfall entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05){{#if FLAG_CUSTOMER_SYSTEMS}}, auch für Zugriffe in Kundensystemen{{/if}}.
-{{#if FLAG_INCLUDE_SHOULD}}
-<!-- IMPL 4.2.1-S1 -->
-Berechtigungen werden rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Standardkonten erhalten keine privilegierten Rechte.
+<!-- IMPL 4.2.1 -->
+Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}. 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. 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}}
 
 ## 4. Verbindlichkeit
@@ -125,8 +212,8 @@ Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich
 | Rolle | Verantwortung in dieser Richtlinie |
 |-------|-------------------------------------|
 | {{ROLE_IT_LEAD}} | Technische Umsetzung IAM |
-| Fachbereiche | Fachliche Freigabe von Berechtigungen |
-| {{ROLE_ISB}} | Ueberwachung der Einhaltung |
+| Fachbereiche | Freigabe von Berechtigungen |
+| {{ROLE_ISB}} | Überwachung |
 
 ## 6. Überprüfung und Aktualisierung
 
@@ -134,15 +221,14 @@ Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{RO
 
 ## 7. Nachweise
 
-Die Nachweise zur Umsetzung dieser Richtlinie 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}}).
+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
 
-- Informationssicherheitsleitlinie: {{LINK:L00}}
 - 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}}
 
-<!-- Das Mapping der Anforderungen (REQ/IMPL) zu VDA-ISA-Controls ist in mapping.json hinterlegt und wird vom Tool über die Hidden-Anker aufgelöst. Im Lesemodus nicht sichtbar. -->
+<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->