Es gibt zwei Wege, jemandem Zugriff auf die Produktionsdatenbank zu geben. Man vergibt ihn und hofft, dass sich die Person meldet, wenn sie fertig ist. Oder man vergibt ihn für vier Stunden.
Fast jedes Team macht das Erste und fährt dann zweimal im Jahr ein Access Review, um den Schaden zu beheben. Das ist keine Governance. Das ist Aufräumen nach Kalender.
Nicht die Warteschlange ist das Problem, sie ist das Symptom
Zugriffsanfragen sind aus einem Grund langsam, der nichts mit den Werkzeugen zu tun hat: Die freigebende Person hat keine Grundlage, auf der sie Nein sagen könnte.
Es kommt ein Ticket herein: „Marcus Lee beantragt Salesforce Admin.“ Die freigebende Person kennt Marcus. Sie kennt nicht Ihre Salesforce-Konfiguration, nicht was dieses Profil erreicht und nicht, ob er es letztes Quartal schon hatte. Vor die Wahl gestellt, freizugeben oder es herauszufinden, dauert Freigeben elf Sekunden und Herausfinden einen Nachmittag.
Also werden Anfragen freigegeben. Und weil Zugriff zu bekommen langsam und lästig ist, fragen Leute mehr an, als sie brauchen, solange sie gerade jemandes Aufmerksamkeit haben. Danach verschwindet es nie wieder.
Dort warten Zugriffsanfragen hinter Laptop-Bestellungen und Passwort-Resets.
Einmal für eine Migration 2024 vergeben und nie zurückgenommen, weil das Zurücknehmen jemanden einen Nachmittag kostet.
Worauf Leute um drei Uhr nachts zurückgreifen, wenn der Freigabeweg langsamer ist als der Incident.
Lassen Sie dort fragen, wo ohnehin gearbeitet wird
Eine Anfrage, für die man ein zweites Tool öffnen muss, wird stattdessen eine DM, und eine DM ist kein Nachweis.
Die Anfrage dort, wo ohnehin gearbeitet wird. Dauer und IAM-Gruppen kommen aus der Vorlage, getippt wird nur die Begründung.
Die gesamte Anfrage in diesem Bild ist ein Satz Tipparbeit. Applikation, Zugriffsvorlage, Dauer und IAM-Gruppen kommen alle aus der Policy. Der einzige Freitext ist die Begründung, weil die Begründung das Einzige ist, was eine Policy nicht liefern kann.
Beachten Sie die Dauer, automatisch auf zwei Tage gesetzt. Das hat in diesem Moment niemand entschieden. Es kam aus der Vorlage, und genau so bekommt man einen verlässlichen Ablauf: indem man ihn einmal festlegt, wenn niemand unter Druck steht, statt jedes Mal neu, wenn jemand es ist.
Was die freigebende Person sieht
Die Anfrage, die beim Verantwortlichen der Applikation ankommt, trägt alles, was für die Entscheidung nötig ist:
Was die Person in dieser Applikation heute hat. Was die angefragte Rolle zusätzlich mitbringt, beschrieben als konkrete Möglichkeiten und nicht als Rollenname. Ob sie schon einmal gefragt hat und was daraus wurde. Und worauf die Policy diese Berechtigung begrenzt, unabhängig von der Antwort.
Der letzte Punkt zählt mehr, als er aussieht. Wer weiß, dass die Berechtigung in 24 Stunden abläuft, trifft eine viel kleinere Entscheidung als jemand, der glaubt, sie dauerhaft zu vergeben. Und kleine Entscheidungen werden ehrlich getroffen.
Ablauf gibt es in drei Formen
Zeitlich befristet. Ein festes Fenster aus der Policy. Vier Stunden Produktionszugriff während eines Incidents, ablaufend, ob der Incident geschlossen ist oder nicht. Braucht es länger, wird erneut angefragt, und die zweite Anfrage ist ein Signal, das man haben will.
An eine Aufgabe gebunden. Gekoppelt an die Sache, für die der Zugriff war, und nicht an eine Uhr. Ein Zugriff, der für ein Ticket vergeben wurde, endet mit dem Ticket.
Dauerhaft, und als solches markiert. Manche Zugriffe sollen bleiben. Ein Support-Engineer braucht das Helpdesk täglich. Diese Berechtigungen bleiben, werden aber als bewusste Entscheidung erfasst und nicht als Standard, in den man hineingerutscht ist. Damit hat das Access Review überhaupt etwas Prüfbares: eine kurze Liste von Entscheidungen, die jemand getroffen hat, statt alles, was irgendwann irgendwer angefragt hat.
Die meisten Umgebungen können eine bewusst dauerhafte Berechtigung nicht von einer abgelaufenen temporären unterscheiden, weil im Moment der Vergabe nichts den Unterschied festgehalten hat. Genau diese Lücke wird hier geschlossen.
Break-Glass ist ein Weg, keine Ausnahme
Eine Policy, die einen Incident blockiert, ist eine Policy, um die Menschen herumarbeiten. Und in dem Moment, in dem jemand Zugangsdaten teilt, um durch einen Ausfall zu kommen, sind Ihre Kontrollen Dekoration.
Break-Glass ist deshalb von Anfang an eingeplant. Die Berechtigung wird sofort gegen eine benannte Policy vergeben, die festlegt, wer sie nutzen darf und wofür. Die Prüfung erfolgt danach. Sie wird als Break-Glass protokolliert und sieht im Reporting daher nie aus wie eine normale Freigabe.
Der Maßstab dafür, dass das funktioniert, ist nicht, dass Break-Glass nie genutzt wird. Es ist, dass niemand stattdessen einen geteilten Login benutzen musste.
Was sich tatsächlich ändert
Was das nicht leistet
Es macht Freigaben nicht unnötig. Es macht sie günstig und informiert, und das ist etwas anderes.
Es funktioniert nicht bei einer Applikation, für die niemand verantwortlich ist. Jeder Weg endet hier bei einer Person, die für diese Applikation verantwortlich ist, und wenn es diese Person nicht gibt, hat die Anfrage kein Ziel. Verantwortlichkeiten zu benennen ist die unglamouröse Voraussetzung für alles Weitere.
Und es behebt keine Kultur, in der alles dringend ist. Wenn jede Anfrage als kritisch markiert wird, ist der Ablauf die einzige echte Kontrolle, die Sie haben. Er funktioniert dann auch, aber durch Verschleiß und nicht dadurch, dass jemand eine Entscheidung trifft.