Checkliste für Pull Requests bei Sicherheitsrichtlinien

Überblick

Verwenden Sie diese Checkliste, wenn Identitäts-, Zugriffs- oder Endpunktrichtlinien als versionierter Diff vorgeschlagen werden. Arbeiten Sie sie vor dem Öffnen der Änderung, während der Überprüfung, vor dem Merge und nach dem Rollout durch. Passen Sie Prüftiefe und Überwachung an das Risiko der Änderung an, verzichten Sie jedoch nie auf klare Verantwortung, unabhängige Freigabe, Validierung oder Nachweise.

Vor dem Öffnen der Änderung

• Beschränken Sie die Änderung auf einen klaren Zweck. Teilen Sie nicht zusammenhängende Korrekturen in separate Diffs auf, damit sie unabhängig bewertet werden können.
• Halten Sie den Diff so klein, dass er einschließlich generierter Richtlinienausgabe und betroffener Abhängigkeiten sorgfältig geprüft werden kann.
• Erläutern Sie den Grund, das erwartete Ergebnis sowie alle betroffenen Benutzer, Geräte, Workloads, Ressourcen, Umgebungen und Richtlinienverantwortlichen.
• Weisen Sie einen Verantwortlichen und eine Risikoklasse zu und verknüpfen Sie einen Change Record oder ein Issue. Erfassen Sie Fristen, Abhängigkeiten und betriebliche Einschränkungen.
• Vergleichen Sie die vorgeschlagene Änderung mit der aktuell deklarierten und effektiv durchgesetzten Richtlinie, nicht mit Erinnerungen oder einem veralteten Export.
• Kodieren Sie für temporären Zugriff und Ausnahmen einen maschinell erzwungenen Ablaufzeitpunkt mit exaktem Datum, Uhrzeit und Zeitzone. Weisen Sie jeder erforderlichen Nachprüfung einen Verantwortlichen zu.

Während der Überprüfung

• Effektive Änderung. Prüfen Sie die resultierende Berechtigungs- oder Zustandsänderung, nicht nur die bearbeiteten Zeilen. Bestätigen Sie, was erlaubt, verweigert, vorgeschrieben, ausgenommen oder vererbt wird.
• Umfang und geringste Berechtigung. Bestätigen Sie, dass die Änderung weder weiter noch enger als beabsichtigt ist und keine unnötigen Rechte, riskanten Berechtigungskombinationen oder Funktionstrennungskonflikte erzeugt.
• Auswirkungsradius. Ermitteln Sie die Anzahl betroffener Identitäten, Gruppen, Geräte, Anwendungen, Workloads, Ressourcen und Umgebungen. Untersuchen Sie jede Abweichung von der erwarteten Zielgruppe.
• Abhängigkeiten und Konflikte. Prüfen Sie Gruppenverschachtelung, vererbte Rollen, Prioritäten, überlappende Endpunktprofile sowie aktuelle und ausstehende Änderungen, die den Vorschlag verstärken oder unbemerkt aufheben könnten.
• Dauer. Bestätigen Sie, ob die Änderung dauerhaft sein soll. Stellen Sie sicher, dass temporäre Freigaben und Ausnahmen automatisch ablaufen und nicht nur von einer Erinnerung abhängen.
• Wiederherstellung. Definieren Sie einen risikogerechten, getesteten Wiederherstellungsweg: Revert, Roll-forward, Pausieren der Durchsetzung, Isolieren des Ziels oder ein freigegebenes Notfallverfahren. Legen Sie Signale und Entscheidungsbefugnis für die Auslösung fest.
• Notfallzugriff. Wenn Notfallzugänge betroffen sind, bestätigen Sie die Absicht, verifizieren Sie einen unabhängigen Wiederherstellungsweg und testen Sie ihn nach dem freigegebenen Verfahren der Organisation.
• Compliance-Zuordnung. Wenn die Änderung eine nachverfolgte Kontrolle umsetzt oder beeinflusst, verknüpfen Sie die relevante Anforderung und bestimmen Sie die aufzubewahrenden Nachweise.
• Unabhängige Prüfung durch Verantwortliche. Verlangen Sie die Freigabe durch eine andere Person als den Autor und bei Auswirkungen auf einen Kontrollbereich zusätzlich durch den zuständigen Richtlinien- oder Systemverantwortlichen.

Automatisierte Validierung

• Validieren Sie Richtliniensyntax, Schema, Referenzen, Typen und Pflichtfelder. Behandeln Sie Warnungen, die die Durchsetzung verändern können, als Fehler.
• Führen Sie Tests für beabsichtigte Freigaben und erwartete Verweigerungen aus, einschließlich Grenzfällen, Priorität, Vererbung, Ablauf und Fail-closed-Verhalten.
• Lassen Sie die Prüfung fehlschlagen, wenn keine Richtlinientests gefunden werden oder die generierte Richtlinienausgabe vom geprüften Artefakt abweicht.
• Erzeugen Sie die effektive Richtlinien- oder Berechtigungsänderung in einer prüfbaren Form. Markieren Sie unerwartete Ergänzungen, Entfernungen, Ausnahmen und Änderungen der Zielanzahl.
• Führen Sie erforderliche Prüfungen gegen exakt die freizugebende Revision aus und wiederholen Sie sie, wenn sich Diff, Abhängigkeiten oder Zielbaseline ändern.

Vor Merge und Rollout

• Validieren Sie die Änderung nach Möglichkeit in einer repräsentativen Staging-Umgebung, Simulation, mit einem Testkonto oder einer Canary-Gruppe. Prüfen Sie erwartete Erfolge und erwartete Verweigerungen.
• Definieren Sie Rollout-Ringe, Erfolgs- und Abbruchkriterien, Überwachungssignale sowie die Person, die die Bereitstellung pausieren oder eine Wiederherstellung auslösen darf.
• Verwenden Sie Repository-Regeln, die Pull-Request-Prüfung, erfolgreiche Statusprüfungen und gegebenenfalls die Freigabe durch Richtlinienverantwortliche verlangen. Verhindern Sie direkte Pushes und ungeprüfte Umgehungen des geschützten Branches.
• Binden Sie die Freigabe an den exakten Diff. Verwerfen oder wiederholen Sie die Freigabe, wenn ein späterer Commit, eine Abhängigkeitsänderung oder Konfliktauflösung den Merge-Inhalt verändert.
• Bestätigen Sie, dass das bereitstellbare Artefakt aus der geprüften Revision erzeugt wurde und der Produktionsnachweis diese Revision eindeutig identifiziert.
• Informieren Sie Helpdesk, betroffene Teams, Security und Serviceverantwortliche zu dem im Rollout-Plan definierten Zeitpunkt. Wenn ein Merge automatisch bereitstellt, muss die erforderliche Kommunikation vor dem Merge abgeschlossen sein.

Nach dem Rollout

• Erfassen Sie bereitgestellte Revision und Artefakt, Umgebung, ausführende Person oder Automationsidentität, Start- und Endzeit, Zielgruppe sowie Bereitstellungsergebnis.
• Verifizieren Sie den effektiven Zustand auf repräsentativen Zielen. Testen Sie, dass beabsichtigter Zugriff funktioniert, erwartete Verweigerungen bestehen bleiben und unabhängige Kontrollen unverändert sind.
• Überwachen Sie die definierten Erfolgs-, Fehler- und Wiederherstellungssignale über einen Zeitraum, der Risiko und Nutzungshäufigkeit entspricht. Verwenden Sie nicht für jede Richtlinie dasselbe feste Zeitfenster.
• Vergleichen Sie bei einem stufenweisen Rollout die Canary-Ergebnisse mit den Akzeptanz- und Abbruchkriterien, bevor Sie den nächsten Ring freigeben.
• Bestätigen Sie, wo unterstützt, den aktiven kontinuierlichen Abgleich. Planen Sie andernfalls einen benannten Verantwortlichen und ein Prüfintervall zur Erkennung von Drift vom freigegebenen Zustand.
• Hängen Sie Validierungs-, Freigabe-, Bereitstellungs-, Istzustands-, Ausnahme- und Wiederherstellungsnachweise an den Change Record an, bevor Sie ihn schließen.

Praxisbeispiel

Vorgeschlagene Änderung: contractor-jane bis 2026-10-31T23:59:59-04:00 zu finance-readonly hinzufügen.

Vor dem Öffnen beschränkt der Autor die Änderung auf eine Identität und eine Gruppe, erfasst Geschäftsgrund und Verantwortung, verknüpft den Auftrag und kodiert den Ablaufzeitpunkt in der Richtlinie. Während der Überprüfung prüft ein Reviewer die über finance-readonly vererbten effektiven Rechte, bestätigt, dass die Rolle eingeschränkte Daten weder schreiben noch exportieren kann, verifiziert die Zielanzahl und prüft überlappende Änderungen.

Automatisierte Prüfungen validieren die Richtlinie und testen sowohl den erlaubten Berichtszugriff als auch verweigerte Schreibvorgänge. Vor dem Merge bestätigt eine repräsentative Testidentität das erwartete Verhalten; erforderliche Prüfungen und die Freigabe des Richtlinienverantwortlichen sind an die neueste Revision gebunden, und der Helpdesk erhält die Rollout-Information.

Nach dem Rollout identifiziert der Bereitstellungsnachweis die freigegebene Revision und das Ziel. Der Verantwortliche verifiziert Janes effektiven Zugriff und verweigerte Vorgänge, überwacht die definierten Signale und bestätigt, dass der Abgleich die Freigabe entfernt oder meldet, falls sie nach dem kodierten Ablauf noch aktiv ist.

Häufige Fehler

• Unklarer Umfang. Eine breite Rolle oder Gruppe wird geändert, obwohl eine bestimmte Identität, Ressource, Aktion oder Geräteklasse die Anforderung erfüllen würde.
• Fehlender Ablauf. Temporärer Zugriff wird dauerhaft, weil seine Entfernung von einer Erinnerung oder einem Folgeticket abhängt.
• Irreführender Diff. Die bearbeiteten Zeilen wirken sicher, doch Vererbung, Priorität oder generierte Ausgabe erzeugen eine breitere effektive Änderung.
• Ungetestete Verweigerung. Der Erfolgsfall funktioniert, aber niemand prüft, ob verbotene Aktionen weiterhin blockiert werden.
• Veraltete Freigabe. Ein späterer Commit oder eine Konfliktauflösung verändert den Diff nach der Freigabe.
• Unsichere Wiederherstellung. Ein unreflektierter Revert stellt übermäßigen Zugriff wieder her oder entfernt eine neuere Schutzmaßnahme.
• Unvollständige Nachweise. Das Repository zeigt die Freigabe, kann aber nicht belegen, welche Revision die Produktion erreicht hat oder ob der effektive Zustand konvergiert ist.

So verwenden Sie diese Ressource

Überführen Sie die relevanten Punkte in eine Pull-Request-Vorlage und erzwingen Sie objektive Prüfungen durch Repository-Regeln und Continuous Integration. Definieren Sie Risikostufen, damit Routineänderungen effizient bleiben, während Änderungen mit hohen Auswirkungen auf Identität, Endpunkte, privilegierten Zugriff und Notfallzugänge strenger geprüft, getestet, ausgerollt und dokumentiert werden.

Verwandte Ressourcen

• Lesen Sie den Leitfaden GitOps für Endpoint-Compliance zum vollständigen Modell für Prüfung, Durchsetzung und Abgleich.
• Lesen Sie Zugriffsrichtlinienänderungen wie Code überprüfen für eine detaillierte Betrachtung effektiver Berechtigungsänderungen.