Conditional Access und Microsoft Defender for Endpoint: Ein Teufelskreis?

Eine wirkungsvolle Möglichkeit, die Sicherheit innerhalb eines Unternehmens zu erhöhen, besteht darin, den Microsoft Defender for Endpoint Status über eine Compliance-Richtlinie in den Compliance-Status für Intune verwaltete Geräte einzubinden. Auf diese Weise können gefährdete Geräte schnell identifiziert und vom Zugriff auf Unternehmensdaten ausgeschlossen werden. Dieser Ansatz schafft eine zusätzliche Schutzebene. Zusätzlich stellt dieser sicher, dass nur Geräte mit einem sicheren Status auf sensible Informationen zugreifen können. Insbesondere bei schwerwiegenden Sicherheitslücken oder Sicherheitsvorfällen ist dies eine zuverlässige Methode die Geräte bis zur Mitigation der Ursache vom Zugriff auf Unternehmensdaten zu sperren.

Allerdings kann die Verknüpfung von Microsoft Defender for Endpoint und Conditional Access Richtlinien schnell in einen Teufelskreis führen. Das passiert , wenn eine Conditional Access Regel implementiert ist, die den Zugriff für nicht kompatible Geräte blockiert. Dadurch entsteht ein Dilemma: Die betroffenen Geräte können sich nicht erneut als kompatibel registrieren. Der Grund dafür ist die Conditional Access Policy die den Zugriff sperrt. Das macht es für den Administrator schwer das Gerät, ohne ein komplettes Zurücksetzen wieder kompatibel zu bekommen.

Wie der Teufelskreis entsteht?

Standardmäßig können die beiden Microsoft Defender for Endpoint Applikationen nicht direkt aus Conditional Access Richtlinien ausgenommen werden. Die Folge ist, dass Geräte, die durch den Conditional Access blockiert werden, keine Möglichkeit haben, sich wieder als kompatibel zu registrieren. Der Zugriff auf dafür notwendige Dienste wird gesperrt, wodurch der Status „nicht kompatibel“ bestehen bleibt. Standardmäßig stehen die beiden Applikationen „MicrosoftDefenderATP XPlat“ und „Microsoft Defender for Mobile TVM app“ nicht im Conditional Access zur Auswahl.

Wie kann der Teufelskreis durchbrochen werden?

Um diesen Teufelskreis zu durchbrechen, müssen die beiden Service Principals registriert werden: „MicrosoftDefenderATP XPlat app“ (a0e84e36-b067-4d5c-ab4a-3db38e598ae2) und Microsoft Defender for Mobile TVM app (e724aa31-0f56-4018-b8be-f8cb82ca1196).

Dies funktioniert mit der Powershell mit folgendem Code:

Install-Module Microsoft.Graph

Import-Module Microsoft.Graph.Applications

 

Connect-MgGraph

$params = @{

              appId = "a0e84e36-b067-4d5c-ab4a-3db38e598ae2"

}

New-MgServicePrincipal -BodyParameter $params

$params = @{

              appId = "e724aa31-0f56-4018-b8be-f8cb82ca1196"

}

New-MgServicePrincipal -BodyParameter $params 

Nach der Registrierung können die Anwendungen aus den Conditional Access Richtlinien ausgeschlossen werden. Dieser Ausschluss sorgt dafür, dass die Geräte weiterhin Zugriff auf die notwendigen Dienste haben, selbst wenn sie als nicht kompatibel markiert sind. Dadurch wird es möglich, die Geräte wieder als kompatibel zu registrieren und den Zugriff zu normalisieren.

Defender for Endpoint aus Conditional Access Policy ausschließen.
Defender for Endpoint aus Conditional Access Regel ausschließen

Fazit

Mit diesem Trick kann der Teufelskreis durchbrochen werden und die Geräte erhalten wieder Zugriff auf die M365 Dienste, sobald die Compliance wiederhergestellt ist. Auch bleibt während der Non-Compliance die Kommunikation mit dem Defender for Endpoint bestehen und wird nicht „abgeschnitten“. Das erhöht die Sicherheit und hilft dabei das Potential des Defender for Endpoints bestmöglich zu nutzen. Der Defender for Endpoint Status kann unter anderem in den Compliance Policies für Windows, iOS und Android genutzt werden.

Application Protection

Ein weiterer wichtiger Schritt hin zu einer Zero-Trust-Implementierung ist es, sämtliche Anwendungen zu schützen. Azure AD (AAD), als zentrales IAM ermöglicht es einfach, die strengen Benutzerzugriffskontrollen, welche mit MFA und dem bedingten Zugriff (Conditional Access) eingerichtet wurden, für weitere Anwendungen durchzusetzen.

Um Ihre Anwendungen zu schützen, sollten Sie daher zunächst AAD für alle Ihre SaaS-Anwendungen mit SAML, OAuth oder OIDC konfigurieren.

Für Anwendungen, welche diese modernen Protokolle nicht unterstützen, verbinden Sie Ihre VPN-Lösung mit der Azure AD Authentifizierung. Dadurch können Sie die erweiterte Geräte- und Benutzervalidierung nutzen, um so die Sicherheit signifikant zu erhöhen.

Der nächste Schritt besteht darin, Anwendungen von VPNs weg zu verlagern, indem bestehende On-Prem-Geschäftsanwendungen und IaaS-Anwendungen über Azure App Proxy, Kemp Loadbalancer oder NetScaler veröffentlicht werden.

Bedingter Zugriff in Verbindung mit Kemp als Reverse Proxy

Dies schützt nicht nur die Anwendung, sondern ermöglicht es Ihnen auch, Benutzerkonten den Zugriff auf eine einzelne Anwendung zu beschränken. Im Gegensatz zu herkömmlichen VPNs, welche häufig Zugriff auf alle Ports und Protokolle in einem Netzwerk bieten. Und somit eher der Vergangenheit angehören.

Wir erinnern uns, ein wichtiger Ansatz von einer Zero-Trust-Implementierung ist es:

Benutzerkonten erhalten keinen pauschalen Zugriff auf Anwendungen, Dienste und Dateien, sondern lediglich Zugriff auf die Ressourcen, welche diese für die jeweilige Aufgabe benötigen.

Cookie Consent mit Real Cookie Banner