Governance

Access Reviews, die keine Tabelle sind, die niemand liest

Warum Zertifizierungen im Quartal abgenickt werden, was Sie ändern müssen, damit das aufhört, und woher die Audit-Nachweise kommen.

Fragen Sie jemanden, der ein Access Review im Quartal durchgeführt hat, wie viele Berechtigungen entzogen wurden. Die ehrliche Antwort ist meistens: fast keine.

Nicht weil die Zugriffe richtig waren. Sondern weil die prüfende Person eine Tabelle mit vierhundert Zeilen Rollennamen bekam, ohne Kontext, mit Frist, und alles freizugeben die einzige Option war, die in einen Nachmittag passte.

Das Review war nicht die Kontrolle. Es war der Papierkram, der belegt, dass es eine Kontrolle gab.

Drei Konstruktionsfehler, keiner davon liegt bei den Menschen

Die prüfende Person kann nicht erkennen, was eine Rolle bewirkt. SF_ADMIN_PROFILE_2 bedeutet der Führungskraft nichts, die es freigeben soll. Sie kennt ihr Team. Sie kennt nicht Ihre Salesforce-Konfiguration.

Freigeben hat keine Konsequenz. Entziehen könnte jemandem die Woche ruinieren. Freigeben kostet nichts, was irgendwer zurückverfolgt. Die Anreize zeigen in eine Richtung.

Es kommt alles auf einmal. Vierhundert Zeilen in einem Durchgang sind Dateneingabe, und Dateneingabe macht man schnell.

Der Quartalsexport.

Eine CSV pro Applikation, in eine Tabelle kopiert, an Führungskräfte geschickt und pauschal freigegeben, weil sie ordentlich zu lesen einen Tag dauert.

Die Nachweis-Hektik.

Die zwei Wochen vor dem Audit, in denen Admin-Konsolen abfotografiert werden, um etwas zu belegen, das vor drei Wochen stimmte.

Der verwaiste Account, den niemand gefunden hat.

Weil zwischen einem Review und dem nächsten nichts hingesehen hat.

Ändern Sie, worauf die prüfende Person schaut

Ein Access Review in Iden für Retool im Rahmen einer SOC-2-Kampagne, 57 offen und 43 erledigt, mit Beschäftigungsstatus, Abteilung, Rolle und Gruppen je Nutzer sowie Freigeben und Entziehen in jeder Zeile.

Ein SOC-2-Review für eine Applikation. Zwei Zeilen sind markiert, weil die Person im HR-System inaktiv ist und den Zugriff noch hat. Drei der Zeilen sind keine Personen.

Das ist eine Applikation innerhalb einer SOC-2-Kampagne. Einige Details darin sind das ganze Argument.

Der Beschäftigungsstatus steht neben dem Zugriff. Zwei Zeilen sind markiert, weil die Person im HR-System inaktiv ist und in der Applikation noch Zugriff hat. Das ist kein Finding, nach dem man sucht, sondern eine Spalte, und es ist das Wertvollste, was ein Review überhaupt zeigen kann.

Non-Human Identities stehen in derselben Liste. cc_github und das MCP-Token werden neben den Personen geprüft, weil sie Zugriffe halten wie Personen und meist die ältesten Berechtigungen im Bestand sind. Sie in eine eigene Übung auszulagern ist der Weg, auf dem sie nie geprüft werden.

Die Entscheidung sitzt in der Zeile. Freigeben oder entziehen, dort, im Review. Keine Notiz, die jemand später umsetzen soll.

Sagen Sie, was die Rolle kann, nicht wie sie heißt

Die prüfende Person sieht nicht SF_ADMIN_PROFILE_2. Sie sieht, dass diese Person die vollständige Kundenliste exportieren, Preise ändern und Datensätze löschen kann, die anderen gehören.

Das ist dieselbe Berechtigung, beschrieben in Begriffen, über die jemand entscheiden kann. Es ist auch die Beschreibung, die eine zu weitreichende Berechtigung offensichtlich macht, und genau das versteckt ein Rollenname besonders gut.

Zeigen Sie, was genutzt wurde

Jede Zeile trägt, ob der Zugriff genutzt wurde und wann.

Jemand hat NetSuite seit elf Monaten und hat es zweimal geöffnet, beide Male in den ersten zwei Wochen. Diese einzige Tatsache führt zu mehr Entzügen als jede Menge Policy, weil sie eine abstrakte Risikofrage in eine konkrete verwandelt.

Verkleinern Sie den Stapel

Alles, was das System selbst entscheiden kann, entscheidet es, bevor das Review beginnt. Zugriffe, die der Policy genau entsprechen, in diesem Zyklus vergeben wurden und regelmäßig genutzt werden, brauchen keinen Menschen.

Übrig bleibt der Rest: ungewöhnlich, ungenutzt oder unerklärt. Typischerweise ein Zehntel der ursprünglichen Liste, und jede Zeile steht dort aus einem Grund, den die prüfende Person sehen kann.

Neunzig Tage sind eine lange Zeit, in der niemand hinsieht

Ein Review ist von Natur aus periodisch, und alles zwischen zwei Reviews bleibt unbeobachtet. Eine Berechtigung, die am Tag nach dem Abschluss eines Zyklus vergeben wird, liegt neunundachtzig Tage ungeprüft da, und das Review, das sie irgendwann sieht, betrachtet etwas, das drei Monate alt ist.

Das ist die strukturelle Grenze der Zertifizierung als Kontrolle. Sie ist eine Momentaufnahme, und was sie steuern soll, ist ein Film.

Das Review ist deshalb nicht der Ort, an dem die meiste Arbeit passieren sollte. Es ist die Bestätigung auf einer Arbeit, die schon getan ist.

Was dazwischen läuft

Jede angebundene Applikation wird alle zwei Stunden gelesen: wer einen Account hat, was jeder Account kann und wann er zuletzt genutzt wurde. Das ist ein Lesen der Applikation selbst und keine Annahme darüber, was Iden zuletzt provisioniert hat. Das ist wichtig, weil beides auseinanderdriftet, und im Drift liegen die Findings.

Diese Lesevorgänge werden mit den Systemen abgeglichen, die die Wahrheit über Menschen halten. Das HRIS sagt, wer angestellt ist, in welcher Abteilung und ob die Person gegangen ist. Der IdP sagt, wer sich authentifizieren kann und in welchen Gruppen er ist. Ein Zugriff ohne passenden Beschäftigungsdatensatz ist ein anderes Finding als ein Zugriff ohne passende Gruppe, und unterscheiden lässt sich das nur, wenn man alle drei liest.

Dann die Analyse, die nach einer kleinen Zahl bestimmter Muster sucht:

Verwaiste Accounts. In der Identitätsquelle ausgetreten, in Applikationen weiter mit Accounts vertreten. Das ist das Offboarding, das nicht fertig wurde, und meist die größte Kategorie beim ersten Durchlauf.

Überprovisionierte Accounts. Mehr Zugriff, als die Rolle erklärt, sei es durch Ansammlung über Rollenwechsel oder durch eine Berechtigung, die niemand entfernt hat.

Accounts von Dritten. Externe Personen mit Zugriff, die am seltensten geprüft werden, weil sie zu keinem Team einer Führungskraft gehören.

Zombie-Accounts. Gültige Zugangsdaten, die seit Monaten niemand genutzt hat.

Neue privilegierte Accounts. Jemand hat seit dem letzten Durchlauf Adminrechte bekommen. Das sollte man innerhalb von Stunden wissen und nicht im nächsten Quartal.

Verstöße gegen die Funktionstrennung. Pro Applikation, pro Regel, denn die Kombination, die in Salesforce zählt, ist nicht die, die in NetSuite zählt.

Findings kommen als Eingang

Das Action Center in Iden mit 23 offenen Findings, links die Kategorien (verwaiste Accounts 10, überprovisioniert 7, Drittanbieter 4, Zombie 1, neu privilegiert 1, dazu zwei SoD-Prüfungen bei null) und rechts die verwaisten Accounts, jeweils mit dem Offboarding-Datum und der Anzahl noch gehaltener Applikationen.

Findings als Eingang. Links Kategorien und Anzahl, rechts die Warteschlange, zwei Kategorien stehen schon auf null. Angelina wurde vor drei Tagen offgeboardet und hält noch sechs Applikationen.

Das Ziel ist ein leerer Eingang, und das ist eine bewusste Entscheidung und keine Metapher. Ein Dashboard zeigt Ihnen eine Zahl und erwartet, dass Sie etwas dabei empfinden. Ein Eingang gibt Ihnen eine Warteschlange mit einem Ende, und dieses Ende ist erreichbar.

Links stehen die Kategorien mit ihrer Anzahl, rechts die Warteschlange, und zwei der Kategorien in diesem Bild stehen schon auf null. Genau darauf ist das Ganze ausgerichtet.

Zwei Details darin sind die eigentliche Konstruktion.

Das Alter steht in jeder Zeile, und die jungen sind markiert. Angelina wurde vor drei Tagen offgeboardet und hält noch sechs Applikationen. Manoj wurde vor acht Monaten offgeboardet. Das sind verschiedene Probleme: Das erste ist ein Prozess, der gerade versagt hat, das zweite ist geerbt. Eine Sortierung nur nach Anzahl begräbt den Fall von gestern unter fünfundzwanzig, die mit dem Bestand kamen.

Nichts hier macht Ihnen einen Vorwurf für das, was Sie geerbt haben. Findings, die schon bestanden, als Iden erstmals angebunden wurde, sind als solche markiert und bleiben aus der offenen Zahl heraus. Ein Werkzeug, das einem Administrator zur Begrüßung dreihundert Fehler vorhält, die er nicht verursacht hat, ist ein Werkzeug, das er nicht mehr öffnet.

Ein Finding zu schließen heißt nicht immer, es zu beheben

Es gibt drei Wege, etwas zu erledigen, und nur einer davon ist Entfernen.

An der Quelle behoben. Der Zugriff ist weg, und seine Ursache ebenfalls, das Finding kommt beim nächsten Durchlauf also nicht zurück.

Als Ausnahme erfasst, mit Ablaufdatum. Dieser Zugriff ist richtig, und hier steht, wer das sagt und bis wann. Eine benannte Ausnahme mit Datum ist ein Governance-Artefakt. Ein ignoriertes Finding ist es nicht.

Geprüft. Jemand hat hingesehen, entschieden und die Entscheidung festgehalten. Oft kann ein Administrator einen Zugriff nicht entfernen, weil ein Fachverantwortlicher Nein sagt, und ehrlich ist es dann, die Entscheidung anzuerkennen, statt die Warteschlange als Aufgabenliste über Dinge auszugeben, die er kontrolliert.

Genau das macht einen leeren Eingang erreichbar und nicht bloß wünschenswert. Wenn eine Zeile nur durch Löschen zu erledigen wäre, würde die Warteschlange nie leer und niemand würde es versuchen.

Was sich damit am Review ändert

Der Quartalszyklus bleibt, weil die meisten Rahmenwerke eine benannte Person verlangen, die nach Plan bestätigt, und kontinuierliche Prüfungen das nicht erfüllen.

Was sich ändert, ist, was darin ankommt. Wer eine Kampagne öffnet, die kontinuierliche Prüfungen bereits bereinigt haben, sieht Abwägungen in einer Menge, die sich wirklich lesen lässt, statt vierhundert Zeilen, von denen dreihundertneunzig offensichtlich in Ordnung sind.

Und das ist der einzige verlässliche Weg, eine Bestätigung überhaupt aussagekräftig zu machen.

Der Audit-Nachweis ist ein Nebenprodukt, kein Projekt

Jedes Review hält fest, welcher Umfang geprüft wurde, wer was geprüft hat, was entschieden wurde, wann, was entzogen wurde und die Bestätigung, dass es tatsächlich entfernt wurde. Jedes kontinuierliche Finding hält fest, was es ausgelöst hat, wie es erledigt wurde und von wem.

Zugeordnet zu SOC 2 CC6.1 bis CC6.3 und ISO 27001 A.9, exportierbar pro Kontrolle.

Damit werden aus den zwei Wochen vor einem Audit eine Abfrage. Nicht weil die Prüfer weniger verlangen, sondern weil die Antwort schon existiert.

Was sich tatsächlich ändert

Eine Tabelle pro QuartalMit Iden
Was die prüfende Person siehtRollennamen in einer SpalteBerechtigungen und die letzte Nutzung
Zu bearbeitende ZeilenAlles, jedes QuartalWas sich geändert hat oder auffällig ist
Ein EntzugEine Notiz, die jemand umsetzen sollIm Review direkt entfernt
Zwischen den ReviewsNichtsJede Applikation wird alle zwei Stunden neu gelesen
Wann Sie davon erfahrenIm nächsten QuartalInnerhalb von Stunden, in einer Warteschlange
Die FindingsEin BerichtEin Eingang, den Sie leeren können
Nachweise für die PrüfungWerden hinterher zusammengesuchtEntstehen, während die Arbeit passiert

Was das nicht leistet

Es entscheidet nicht für die prüfende Person. Es macht die Entscheidung günstig und informiert, und eine Führungskraft, die alles freigeben will, kann das weiterhin tun. Was sich ändert, ist, dass der Nachweis zeigt, dass sie es getan hat.

Es deckt keine Applikation ab, die nicht angebunden ist. Ein Review ist nur so vollständig wie die Konnektoren dahinter, und deshalb sind Abdeckung und Governance dasselbe Problem unter zwei Namen.

Und es schafft den periodischen Zyklus nicht ab. Die meisten Rahmenwerke verlangen eine benannte Person, die nach Plan bestätigt, und kontinuierliche Prüfungen erfüllen das allein nicht. Sie machen den Zyklus klein, und das ist ein anderes und besseres Ergebnis, als ihn verschwinden zu lassen.

Häufige Fragen

Weil die prüfende Person eine Tabelle mit Rollennamen bekommt, ohne Kontext und ohne Konsequenz, und alles freizugeben die einzige Option ist, die in einen Nachmittag passt. Ändern Sie die Prüfeinheit, dann ändert sich das Verhalten von selbst.

SOC 2 CC6.1 bis CC6.3, ISO 27001 A.9 und die Abschnitte zur Zugriffskontrolle in den meisten Sicherheitsfragebögen von Kunden. Der Nachweis lässt sich pro Kontrolle exportieren und nicht nur als ein undifferenziertes Protokoll.

Es wird entfernt, über SCIM, eine API oder einen individuellen Konnektor, je nach Applikation. Ein Review, dessen Entscheidung niemand umsetzt, ist schlimmer als kein Review, weil es einen datierten Nachweis erzeugt, dass Sie es gewusst haben.

Meistens ja, denn die meisten Rahmenwerke verlangen eine periodische Bestätigung durch eine benannte Person. Aber der Zyklus wird deutlich kleiner, weil die kontinuierlichen Prüfungen das Offensichtliche schon erledigt haben und nur noch das übrig bleibt, was eine Abwägung braucht.

Ja, und Sie sollten es tun. Service-Accounts und KI-Agenten halten Zugriffe wie alle anderen und sind meist die ältesten und weitreichendsten Berechtigungen im Bestand. Sie in eine eigene Übung auszulagern ist der Weg, auf dem sie am Ende überhaupt nie geprüft werden.