Es gibt einen bestimmten Typ von Vorfall, den ich in den letzten Jahren wahrscheinlich öfter gesehen habe als jeden anderen: eine Anwendung, die seit Jahren völlig unauffällig lief, hört plötzlich auf zu funktionieren, mitten am Tag, ohne dass jemand etwas geändert hat. Nach kurzer Suche stellt sich heraus, dass das Client Secret der zugehörigen App Registration in Entra ID abgelaufen ist. Niemand hatte das auf dem Schirm, weil niemand mehr genau wusste, wer diese App Registration überhaupt angelegt hatte oder wofür sie im Detail gebraucht wurde.
Das Muster dahinter ist fast immer dasselbe. Eine App Registration wird von einem Entwickler oder einem externen Dienstleister im Rahmen eines Projekts angelegt, das Secret bekommt eine Standardlaufzeit von ein oder zwei Jahren, das Projekt wird abgeschlossen, der Entwickler wechselt vielleicht die Firma oder das Projekt läuft einfach im Hintergrund weiter, und irgendwann läuft die Uhr ab. Bei einem Kunden, den ich vor einiger Zeit unterstützt habe, waren beim ersten vollständigen Audit über 40 App Registrations vorhanden, für über ein Drittel davon konnte niemand mehr im Unternehmen sagen, wozu sie eigentlich dienten oder wer davon informiert werden müsste, wenn ein Secret abläuft.
Warum das native Ablauf-Alerting von Microsoft oft nicht ausreicht
Microsoft bietet inzwischen durchaus Funktionen an, um auf ablaufende Secrets hinzuweisen, unter anderem über Log Analytics Workbooks oder E-Mail-Benachrichtigungen an globale Administratoren, wenn ein Secret innerhalb der nächsten 30 Tage abläuft. Das Problem in der Praxis ist aber weniger die technische Machbarkeit der Benachrichtigung selbst, sondern wer sie tatsächlich bekommt und was mit ihr passiert. Diese Benachrichtigungen landen in der Regel bei einem globalen Administrator-Postfach, das oft von mehreren Personen mitgelesen wird oder in einem allgemeinen IT-Postfach untergeht. Der Entwickler oder Fachbereich, der die Anwendung tatsächlich betreut und weiß, ob ein Secret-Rollover unkritisch oder hochriskant ist, bekommt diese Nachricht in den seltensten Fällen direkt.
Der zweite Punkt, der mir noch wichtiger erscheint, ist das komplette Fehlen von Ownership-Zuordnung in der Standard-Entra-ID-Oberfläche. Eine App Registration hat zwar ein Feld für Owner, aber in der Praxis wird dieses Feld selten konsequent gepflegt, und selbst wenn, gibt es keinen automatisierten Prozess, der bei einem bevorstehenden Ablauf gezielt genau diese Person informiert und ihr eine einfache Möglichkeit gibt, das Secret selbst zu erneuern, ohne dafür Application Administrator Rechte im gesamten Tenant zu benötigen.
Wie ich das bei au2mator gelöst habe
Der Ansatz, den ich verfolgt habe, kombiniert zwei Dinge: erstens eine systematische Bestandsaufnahme aller App Registrations mit erzwungener Owner-Zuordnung, und zweitens ein Self-Service-Modell für die Secret-Erneuerung selbst. In au2mator läuft ein regelmäßiger Scan aller App Registrations im Tenant, der prüft, welche Secrets in den nächsten 30, 14 und 7 Tagen ablaufen. Für jede App Registration ohne definierten Owner wird automatisch eine Eskalation an das IT-Team ausgelöst, mit der klaren Aufforderung, einen Owner zu benennen, bevor das nächste Secret dort überhaupt erneuert werden kann.
Sobald ein Owner zugeordnet ist, bekommt genau diese Person eine direkte Benachrichtigung, wenn ihr Secret bald abläuft, mit einem Link zu einer einfachen Self-Service-Aktion im Portal. Der Owner kann darüber ein neues Secret anfordern, ohne selbst Application Administrator zu sein, die eigentliche Erstellung des neuen Secrets läuft im Hintergrund über ein Service-Principal mit genau diesem einen, klar begrenzten Recht.
Was sich dadurch konkret ändert
Bei dem bereits erwähnten Kunden mit den über 40 App Registrations hat allein die erste Bestandsaufnahme mit erzwungener Owner-Zuordnung dazu geführt, dass sieben App Registrations identifiziert wurden, die zu Anwendungen gehörten, die gar nicht mehr im Einsatz waren, komplett unnötige Angriffsfläche, die einfach nie aufgeräumt wurde. Für die verbleibenden aktiven Registrations hat sich die Zahl der ungeplanten Ausfälle durch abgelaufene Secrets seit der Einführung des Self-Service-Modells auf null reduziert, weil die jeweiligen Owner jetzt rechtzeitig und direkt informiert werden, statt dass die Nachricht irgendwo in einem Sammel-Postfach untergeht.
Was ich Unternehmen konkret rate
Der erste Schritt, den ich jedem empfehle, bevor überhaupt über Automatisierung nachgedacht wird, ist eine einmalige, vollständige Inventur aller App Registrations im Tenant, inklusive der Frage, wer wirklich weiß, wofür jede einzelne davon gebraucht wird. Häufig ist allein diese Übung schon aufschlussreich, weil sie zeigt, wie viele “vergessene” Registrations mit noch aktiven, aber nutzlosen Berechtigungen im Tenant herumliegen. Erst danach macht es Sinn, über automatisierte Owner-Benachrichtigungen und Self-Service-Erneuerung nachzudenken, sonst automatisiert man nur einen Prozess, bei dem am Ende sowieso niemand zuständig ist.
Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Bauen von au2mator so unterkommt. Wenn du Fragen zu deiner eigenen Umgebung hast, meld dich einfach.
