Schützen Sie Microsoft 365 Break Glass-Konten mit Azure Automation

Break-Glass-Konten sind ein wichtiger Bestandteil Ihres Disaster-Recovery-Modells. Sie sollten implementiert werden, um sicherzustellen, dass Sie, wenn alles andere fehlschlägt, einen Zugangsweg zurück in Ihre Organisation haben. Eines der Probleme besteht darin, dass sie zwar bei ihrer Erstellung eine gute Idee waren, nach einiger Zeit jedoch bei der Implementierung zusätzlicher Kontrollen, wie z. B. Richtlinien für bedingten Zugriff, möglicherweise nicht mehr berücksichtigt werden. In diesem Beitrag soll dieses Problem angegangen und behoben werden.

Zweck der Glasbruchkonten

Break-Glass- oder Notfallzugriffskonten sind hochprivilegierte (globale Administrator-)Konten, die nur verwendet werden dürfen, wenn alle anderen administrativen Zugriffe gesperrt sind. Tatsächlich sind sie die Lösung für Ihr Worst-Case-Szenario, wenn Sie den Zugriff auf Ihre primären Administratorkonten verloren haben und der Mandant ausgesperrt ist.

Break-Glass-Konten sollten keinen anderen Sicherheitskontrollen entsprechen, die Sie in Ihrem Mieter eingerichtet haben. Sie sind so konzipiert, dass sie ohne Durchsetzung von Sicherheitsstandards oder bedingtem Zugriff verwendet werden können, da diese Richtlinien häufig die Ursache für die Sperrung sind. Daher wird empfohlen (und ist unbedingt erforderlich), dass Sie die Verwendung von Sicherheitsstandards vermeiden und Richtlinien für den bedingten Zugriff mit Benutzerausschlüssen nur für Ihre Break-Glass-Konten durchsetzen.

Warum Glasbruchkonten geschützt werden müssen

Im Laufe des natürlichen Lebenszyklus Ihres Microsoft 365-Mandanten ändern sich Richtlinien, Kontrollen und Benutzerkonfigurationen aufgrund unterschiedlicher Faktoren. Einige Beispiele hierfür sind:

Die Einführung neuer integrierter Softwarelösungen.
Verbesserung bestehender Sicherheitskontrollen.
Onboarding und Offboarding von IT-Mitarbeitern.

Einige dieser Änderungen können sich direkt oder indirekt auf die Nutzbarkeit Ihrer vorhandenen Break-Glass-Konten auswirken und sie daher nicht mehr so nützlich machen. Daher ist es wichtig, dass Sie Ihre Break-Glass-Konfiguration ordnungsgemäß dokumentieren, sie nur denjenigen zur Verfügung stellen, die sie benötigen, und ihre Konfiguration auch regelmäßig validieren.

Auflösen von Break-Glass-Ausschlüssen für bedingten Zugriff mit Microsoft Graph PowerShell

Um sicherzustellen, dass Sie sich jederzeit bei Ihren Break-Glass-Konten anmelden können, ist es wichtig, dass diese von allen Richtlinien für bedingten Zugriff in Ihrer Umgebung ausgeschlossen sind. Das Ausschließen des Kontos von allen Richtlinien, auch wenn einige möglicherweise keine Auswirkungen auf das Konto haben, ist unabhängig davon eine gute Vorgehensweise, falls sich der Umfang einer Richtlinie ändert, ohne dass darüber hinaus später noch über das Break-Glass-Konto nachgedacht wird.

Mithilfe von Microsoft Graph PowerShell und einer einfachen Skriptlogik können wir Informationen über die derzeit aktivierten Richtlinien für bedingten Zugriff in Microsoft Entra sammeln und jede einzelne durchlaufen, um sicherzustellen, dass unsere Break-Glass-Konten ausgeschlossen sind. Anschließend können wir die Ergebnisse per E-Mail an ein Ziel unserer Wahl senden.

Das folgende Beispiel wird genau das in einem Szenario mit Delegate-Zugriff tun. Weitere Informationen zu Berechtigungstypen mit Microsoft Graph finden Sie unter So finden Sie Berechtigungen für Microsoft Graph PowerShell.

Connect-MgGraph -Scope Policy.ReadWrite.ConditionalAccess, Policy.Read.All, User.Read.All, Mail.Send

#Define variables#
$breakglass = "address"
$to = "address"
$from = "address" #In a delegate scenario, this must be the account as your current session

#Get breack glass user Id
$userid = (Get-MgUser -userid $breakglass).id
$policies = Get-MgBetaIdentityConditionalAccessPolicy -Filter "State eq 'Enabled'"

#Generate empty arrays
$Report = [System.Collections.Generic.List[Object]]::new()
$log = @()

#Loop through policies, update and build report
Foreach ($policy in $policies){
    If ($userid -in $policy.Conditions.Users.ExcludeUsers) {
        $bgline = "Already excluded"
        $log += "No action required for policy: $($policy.DisplayName)`n"
        $action = "[No action Required]"
    } else {
        $policy.Conditions.Users.ExcludeUsers += $userid
        try {
            update-MgBetaIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -Conditions $policy.Conditions -erroraction stop
            $bgline = "Break glass account added" 
            $log += "Break glass account exlcluded for policy: $($policy.DisplayName) `n"
            $action = "[Remediated]"  
        }
        Catch {$log += "Unable add breakglass account to policy: $($policy.DisplayName)" + $_ + "`r`n"}
            $action = "[Action Required]" 
    }
    $item = [PSCustomObject][ordered]@{
            "Policy Name" = $policy.DisplayName
            "Last modified" = $policy.ModifiedDateTime
            "Break Glass" = $bgline
        }
    $report.Add($item)
}

#Message body
$report = $report | ConvertTo-Html
$Report = $report -replace '<table>', '<table border="1">'

#Message attachment
$encodedBytes = [System.Text.Encoding]::UTF8.GetBytes($log)
$MailAttachment = [System.Convert]::ToBase64String($encodedBytes)

#Send message
$body = @{
	message = @{
		subject = "$action Break glass policy review"
		body = @{
			contentType = "HTML"
			content = "$report Please see the attached for further information"
		}
		toRecipients = @(
			@{
				emailAddress = @{
					address = "$to"
				}
			}
		)
        attachments = @(
			@{
				"@odata.type" = "#microsoft.graph.fileAttachment"
				name = "log.txt"
				contentType = "text/plain"
				contentBytes = $MailAttachment
			}
    )
	}
	saveToSentItems = "false"
}
Send-MgUserMail -UserId $from -BodyParameter $body

Die Ausgabe des Skripts sieht wie folgt aus:

Mit Azure Automation nach einem Zeitplan automatisieren

Durch die Automatisierung des oben genannten Skripts können Sie garantieren, dass es nach einem definierten Zeitplan ausgeführt wird, ohne dass eine physische Aktion erforderlich ist. Es stellt außerdem sicher, dass eine grundlegende Änderung an Ihren bestehenden Richtlinien für bedingten Zugriff oder an neuen Richtlinien automatisch behoben wird, indem das Break-Glass-Konto ausgeschlossen wird. Für diesen Schritt gelten einige Voraussetzungen: Sie benötigen:

Ein Azure-Abonnement.
Ein Azure Automation-Konto mit einer vom System zugewiesenen verwalteten Identität.
So weisen Sie Ihrer verwalteten Identität die Graph-API-Berechtigungen zu.
Ändern Sie das Skript, um die verwaltete Identität für die Authentifizierung zu verwenden.

Verwenden Sie die obigen Links, um ein Azure Automation-Konto einzurichten und der zugehörigen verwalteten Identität die entsprechende Berechtigung zuzuweisen. Policy.ReadWrite.ConditionalAccess, Policy.Read.All.

Ändern Sie das Skript, um eine verwaltete Identität für die Authentifizierung zu verwenden

Um unser Skript nach einem Zeitplan sicher über das Automation-Konto auszuführen, müssen wir das Skript leicht ändern, sodass es die verwaltete Identität zur Authentifizierung verwendet. Ändern Sie dazu die erste Zeile des obigen Skripts wie folgt:

Connect-MgGraph -Identity

Ich teste dies gerne mit dem Runbook-Testbereich, bevor ich es in der Produktion veröffentliche. Wählen Sie beim Bearbeiten Ihres Runbooks Testbereich aus.