Governance in IT-Security — Sponsor vor Grant
Zugriff ausführbar machen: Sponsor, Recert, SoD — ohne die Access-Säule neu zu schreiben.
Begriffe vor dem Lesen
- Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
- verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
- technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
- Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.
Sizing: KMU — ein Grant-Pfad mit Sponsor. Mid-Market — Recert-Cadence. Enterprise — SoD und Evidence-Pack.
IAM sieht jede Tabelle. Deshalb gilt Security oft als Owner. Das ist falsch: Sponsor entscheidet Zweck, Custodian setzt Grant um.
Die Serie IT-Security-Landscape gibt dir den Einstieg und den roten Faden für die folgenden Teile.
Konzept halten — Last-Säulen: Access und PII tragen diese Kette; DSDR ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.
Produkte und Entscheidungen
Grant-Produkt
Grant-ID, Sponsor, Zweck, Ablauf, Recert.
Recert-Cadence
Wer bestätigt den Zweck, nicht nur den Account.
Evidence-Pack
Wer wann welchen Zweck gewährt hat.
Wo Governance hängt
- Onboarding. Account ohne Sponsor
- Recert. Klick ohne Zweck
- Nicht-Produktion. Kopie mit Produktion-Rechten
Rollen-Mapping
Data Owner
Zweck und Sponsor.
Custodian
Grant umsetzen und entziehen.
Steward
Recert triagieren.
Architect
SoD-Schnitt.
Hilfskarte — wen zuerst fragen
Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.
| Frage | Zuerst | Dann |
|---|---|---|
| Wer darf den Zweck dieses Grants binden? | Fach-Owner | Steward |
| Wer setzt den Grant um? | Custodian | Architect |
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Owner | Custodian | Sponsor + Zweck |
| Steward | Owner | Recert-Ausnahme |
| Custodian | Auditor | Evidence-Pack |
Mini-Fall
Anwendungsbeispiel (Lehrfall, keine Kundendaten).
Symptom: Ein BI-Tool bekommt Produktivzugriff, aber niemand aus dem Fachbereich steht dafür ein. Typischer Fehlstart: Eine Rollenvorlage ausrollen. Vereinbarung: Jede Freigabe bekommt eine Zugriffs-ID, einen fachlichen Sponsor und ein Ablaufdatum.
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Einen produktiven Grant ohne Sponsor finden und stoppen oder nachziehen.
- Recert für denselben Grant datieren.
Governance in IT security
Part 1 of 5
View series