[SD] Break Glass Account

In der Security Demopalooza adressiere ich #Security Themen, die in meiner täglichen Arbeit oft/öfter gefragt werden. Für eine Liste der bisher behandelten Themen besuche einfach die Übersichtsseite der Security Demopalooza.

Mit den zunehmenden Möglichkeiten die eigene Infrastruktur und Cloud Services abzusichern – z.B. mittels Multifactor Authentication (MFA) und Conditional Access – kommt es leider in seltenen Fällen einmal vor, dass entweder durch Fehlkonfigurationen oder durch Fehlfunktionen ein Logon für bestimmte User(gruppen) oder auch Admins nicht richtig funktioniert.

Genau für solche Fälle bedarf es dann schneller, aber sicherer Möglichkeiten doch einen Service zu nutzen.
Natürlich kann (und sollte) immer der entsprechende Support genutzt werden, aber da vermutlich zu diesem Zeitpunkt mehr als ein Kunde betroffen ist, dürfte es eher länger als kürzer dauern, bis der Support die notwendigen Schritte unternommen hat.
Daher gilt: „Hilfe zur Selbsthilfe“!

Für diesen Zweck wurde das Konzept von sog. „Break Glass“ Accounts eingeführt.

Dabei geht es einfach ausgedrückt um einen Account, der „sicher im Tresor“ darauf wartet, dass der Ernstfall eintritt und dieser quasi mit „Blaulicht“ an allem vorbeikommt, was den „Otto-Normal-User/Admin“ sonst aufhalten würde.

Beispiel: Der verwendete MFA Service versagt seinen Dienst und kein User kann sich mehr einloggen.
In diesem Fall könnte ein Break Glass Account dazu verwendet werden um die „All Employees“ Gruppe in die Exception für MFA zu schieben, sodass bis zur Behebung des Ausfalls alle User wieder arbeiten können (auch wenn sie in dieser Zeit nicht durch MFA abgesichert wären).

Dieses Vorgehen stellt im Übrigen eine Best Practice bei dem Umgang mit MFA über AzureAD dar!
Dazu erstellt man (mind.) 1 leere Gruppe und fügt diese den Ausnahmen der entsprechenden Conditional Access Policies hinzu. Dabei ist es unerheblich, ob der Break Glass in dieser Gruppe ist oder separat auch excludiert wird.

Im Bedarfsfall dann einfach der im Bild „CA Excludes“ Gruppe die „All Employees“ Gruppe als Member zuweisen und schon können die „normalen“ User wieder arbeiten.

Ein entsprechendes Vorgehen sollte auch an anderen Stellen genutzt werden, z.B. bei der Device Compliance, etc.

Damit die Nutzung eines Break Glass Accounts auch „sicher“ abläuft bedarf es einiger weiterer Tätigkeiten:

1. Es muss einen Prozess für die Aktivierung eines solchen Break Glass Accounts – auch für das Wochenende und auch für die Nacht – geben.
   Stichwort: wer wird Samstags um 03:00h aus dem Bett geklingelt und kommt in annehmbarer Zeit an den Tresor für diesen Account – besser noch mind. zwei Personen, die an unterschiedlichen Orten nur jeweils einen Teil der Credentials zugreifen können.
2. Es muss sichergestellt sein, dass dieser Account nicht missbräuchlich genutzt wird. Dazu ist es notwendig eine Alarmierung zu etablieren, sobald der Account genutzt wird.
   Hierzu eignet sich besonders eine Activity Policy in Microsoft Cloud App Security, die nichts anderes tut als nur die Aktivitäten des Break Glass Accounts zu überwachen:

Wenn dann ein Break Glass Account genutzt wird, dann wird ein Alert generiert:

und eine Email an die eingestellte Adresse versendet:

Im „Manage emergency access accounts in Azure AD Guide“ wurde ein anderer Weg über Log-Analytics gegangen, der ebenfalls funktioniert, aber eine Azure Subscription mit Log-Analytics erfordert.

Hinweis: zur Verdeutlichung der Idee habe ich den Break Glass Account „Breakglass@….“ genannt. In der Realität rate ich davon ab es einem Angreifer so einfach zu machen und es sollte hier besser ein beliebiger UPN verwendet werden, der nicht leicht zu erraten ist um zum einen eine zusätzliche Hürde zu erzeugen und zum anderen die empfangende Mailbox der Alerts nicht überzustrapazieren.

Hinweis2: Wenn die vordefinierten Conditional Access Policies für MFA verwendet werden (aktuell in Preview), dann ist dieses Vorgehen nicht möglich, da in diesen vordefinierten Policies keine Ausnahmen genannt werden können. Daher ist es dann unumgänglich eigene Policies zu erstellen!