Files
certvia/seed/isms-vorlagenpaket-v2/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md
T
msolarczekandClaude Opus 4.8 eab16c861d 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>
2026-07-08 11:23:07 +02:00

12 KiB
Raw Blame History

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

  • [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}}
  • [SOLL] Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden. {{/if}} {{#if FLAG_HIGH_PROTECTION}}
  • [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}}

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}}

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

  • [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.
  • [MUSS] Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt. {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevanten Anforderungen definiert und umgesetzt. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktiken authentifiziert. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. Privileged Access Management, Zwei-Faktor-Authentifizierung). {{/if}} {{#if FLAG_HIGH_PROTECTION}}
  • [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}}
  • [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}}

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}}

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 Benutzerkonten und Anmeldeinformationen (ISA 4.1.3)

Anforderung

  • [MUSS] Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt.
  • [MUSS] Eindeutige und personalisierte Benutzerkonten werden verwendet.
  • [MUSS] Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollziehbarkeit verzichtbar ist).
  • [MUSS] Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei Vertragsende).
  • [MUSS] Benutzerkonten werden regelmäßig überprüft.
  • [MUSS] Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt.
  • [MUSS] Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt. {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genutzt. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Sperren oder Passwortänderung). {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip). {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Die Verwendung von Standardpasswörtern wird technisch verhindert. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Kunden. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert. {{/if}}

Umsetzung bei {{ORG_NAME}}

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

  • [MUSS] Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
  • [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}}
  • [SOLL] Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Autorisierungsrollen werden verwendet. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich vergeben. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisiert. {{/if}} {{#if FLAG_HIGH_PROTECTION}}
  • [HOCH] Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmigt. (C, I, A) {{/if}} {{#if FLAG_VERY_HIGH_PROTECTION}}
  • [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}}
  • [SEHR HOCH] Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C) {{/if}}

Umsetzung bei {{ORG_NAME}}

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}}

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

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}}