Vollständige Anleitung zur Konfiguration von Credential Guard und Device Guard unter Windows

In modernen Unternehmensumgebungen ist der Schutz von Anmeldeinformationen und die strenge Kontrolle des auf Windows-Rechnern ausgeführten Codes unerlässlich. Mit der Einführung von Windows 10, Windows 11 und Windows Server 2016 (und späteren Versionen) hat Microsoft massiv in virtualisierungsbasierte Sicherheit investiert und Technologien wie Credential Guard, Device Guard und Application Guard entwickelt. Lesen Sie unseren vollständigen Sicherheitsleitfaden für Unternehmen unter Windows 11.

Wenn Sie ein Netzwerk von Geräten verwalten, möchten Sie genau wissen, wie Sie Credential Guard und Device Guard richtig konfigurieren , wie sie sich in andere Sicherheitsmaßnahmen wie BitLocker, Exploit Guard oder Remote Credential Guard integrieren und welche Rolle Microsoft Defender Endpoint Security Baselines spielen (insbesondere bei der Arbeit mit herkömmlichem Intune oder Gruppenrichtlinienobjekten).

Grundlagen: VBS, VSM und die Rolle von Credential Guard und Device Guard

Um zu verstehen, warum Credential Guard und Device Guard so effektiv sind, ist es wichtig, zunächst das Konzept der virtualisierungsbasierten Sicherheit (VBS) zu begreifen . VBS nutzt die Virtualisierungsfunktionen des Prozessors (Intel VT-x oder AMD-V), um eine isolierte Umgebung innerhalb des Rechners zu schaffen, die logisch vom Hauptbetriebssystem getrennt ist. Dieser Ansatz wird durch Techniken wie die Kernel-Isolation in Windows 11 ergänzt , welche die Trennung zwischen Kernel und dem restlichen System weiter verstärken.

Der virtuelle Sicherheitsmodus (VSM) , ein Subsystem zur Speicherung und Verarbeitung besonders sensibler Informationen, basiert auf diesem virtuellen Sicherheitssystem . Das „normale“ Betriebssystem greift nicht direkt auf diese Inhalte zu, sondern interagiert über sehr eingeschränkte und kontrollierte Schnittstellen mit ihnen, wodurch die Angriffsfläche reduziert wird.

In diesem Kontext kommt Credential Guard zum Einsatz, das den VSM nutzt, um Benutzeranmeldeinformationen und Authentifizierungsgeheimnisse (wie NTLM-Hashes oder Kerberos-Tickets) zu schützen. Da diese vom restlichen System isoliert sind, wird es selbst für einen Angreifer mit erhöhten Berechtigungen deutlich schwieriger, diese Anmeldeinformationen zu extrahieren.

Device Guard hingegen konzentriert sich auf die Codekontrolle. Ziel ist es, sicherzustellen, dass nur signierte und vertrauenswürdige Anwendungen ausgeführt werden und unbekannte oder potenziell schädliche Binärdateien blockiert werden. In der Praxis wird Device Guard mithilfe verschiedener Technologien implementiert, wobei die Verwendung von Codeintegritätsrichtlinien und Whitelist-basierter Konfiguration am bekanntesten ist.

Beide Lösungen basieren auf der gleichen Säule: einer sicheren Umgebung, die durch VBS/VSM isoliert ist , mit verstärkter Unterstützung durch Hardware wie TPM (Trusted Platform Module), das zum Schutz kryptografischer Schlüssel beiträgt und die Integrität des Systemstarts überprüft.

Microsoft Defender Endpoint-Sicherheitsbaselines

Wenn Sie Ihre Geräte mit Microsoft Intune oder der Microsoft Defender Endpoint Security Console verwalten, sind Sicherheitsbaselines Ihr bester Verbündeter für die Bereitstellung komplexer Konfigurationen (wie Credential Guard und Device Guard), ohne dass Sie sich in jeder einzelnen Einstellung verlieren müssen.

Eine Sicherheitsbaseline ist im Grunde eine Sammlung vorkonfigurierter Parameter für Windows, die von den Sicherheitsteams von Microsoft zusammengestellt und empfohlen werden. Wenn Sie in Intune ein Baseline-Profil erstellen, generieren Sie eine Vorlage mit zahlreichen Geräteeinstellungen: Anmeldeinformationsrichtlinien, Anwendungskontrollen, VBS-Optionen, Defender-Parameter usw.

Die Dokumentation zu Microsoft Defender for Endpoint veröffentlicht verschiedene Versionen dieser Baseline, beispielsweise: 24H1 , die Baseline vom Dezember 2020 (Version 6), die Baseline vom September 2020 (Version 5) sowie frühere Versionen wie die vom April und März 2020. Jede dieser Versionen enthält eine detaillierte Liste der Optionen mit ihren Standardeinstellungen und, sofern verfügbar, Links zu spezifischen Konfigurationsdienstanbietern (CSPs) oder weiterführender Dokumentation für dieselbe Produktgruppe.

Wird eine neue Version der Baseline veröffentlicht, wird automatisch auf die vorherige Version zurückgesetzt . Profile, die mit einer älteren Version erstellt wurden, sind dann schreibgeschützt: Sie können sie weiterhin zuweisen, ihren Namen, ihre Beschreibung oder Zielgruppen ändern, aber nicht ihre internen Parameter.

Um die Konfiguration an die neuen Standards anzupassen, können Sie mit Intune diese Profile auf die aktuelle Basisversion aktualisieren . Nach der Aktualisierung des Profils können Sie die Einstellungen bearbeiten und beispielsweise den Status von Credential Guard, Device Guard, BitLocker oder anderen enthaltenen Optionen anpassen.

Microsoft betont, dass diese Defender-Endpunkt-Baseline für physische Geräte optimiert ist . Die Verwendung in virtuellen Maschinen oder VDI-Umgebungen wird nicht empfohlen, da bestimmte Optionen interaktive Remotesitzungen oder spezifische Virtualisierungsarchitekturen beeinträchtigen können. Für VDI-Umgebungen ist es wichtig, die entsprechende Dokumentation zu lesen, um die Baseline-Konformität zu erhöhen, ohne die Benutzerfreundlichkeit zu beeinträchtigen.

Voraussetzungen und Systemkompatibilität

Um Credential Guard und Device Guard in Betrieb zu nehmen, und erst recht, wenn Sie sie mit anderen Technologien (Remote Credential Guard, Application Guard, Citrix-Lösungen usw.) integrieren möchten, ist es wichtig, die Hardwareanforderungen, das Betriebssystem und die Softwareversionen zu überprüfen.

Im Allgemeinen benötigen Sie Folgendes:

• CPU mit Virtualisierungsunterstützung (Intel VT-x oder AMD-V) und Virtualisierung im BIOS/UEFI aktiviert.
• Unterstützung für virtualisierungsbasierte Sicherheit (VBS) wurde in den Systemsicherheitseinstellungen aktiviert.
• TPM (vorzugsweise TPM 2.0) zur Stärkung der Schlüsselspeicherung und der Systemstartintegrität.
• Kompatible Versionen von Windows 10 / 11 Enterprise o Windows Server ab 2016, um die Vorteile von VSM zu nutzen.

Im Bereich virtueller Desktops und Remote-Anwendungen dokumentiert Citrix spezifische Anforderungen für seine erweiterte Domänentransferfunktion für SSO (Single Sign-On), die auf Remote Credential Guard basiert:

• Virtual Delivery Agent (VDA) Version 2308 oder höher; wenn Sie Windows 11 auf dem Sitzungshost oder Client verwenden, ist VDA 2407 oder 2402 LTSR CU2 oder höher erforderlich.
• Citrix Workspace-Anwendung Version 2309 oder höher und in Windows 11-Umgebungen mindestens 2405.10 oder 2402 LTSR CU2.
• Windows 10/11 64-Bit-Clients, die einer Active Directory-Domäne beigetreten sind und mit direkte Verbindung mit Domänencontrollern (Keine Verbindung, kein SSO).
• Einzel-Sitzungshosts mit Windows 10 22H2 oder Windows 11 22H2 oder höher.

Diese Citrix-Funktion ersetzt die bisherige Übergabeauthentifizierung auf Basis des alten SSO-Dienstes (ssonsvr.exe) und ist nicht mit 32-Bit-Systemen kompatibel . Außerdem können die bisherige Domänenübergabe und die neue, verbesserte Domänenübergabe nicht gleichzeitig auf demselben Host verwendet werden.

Credential Guard-Konfiguration und -Bereitstellung

Credential Guard ist eine der Kernkomponenten des VBS-Ökosystems. Seine Aufgabe ist klar: zu verhindern, dass im System gespeicherte Anmeldeinformationen (wie die In-Memory-Hashes des LSASS-Prozesses) mithilfe von Dump-Tools oder Lateral-Movement-Angriffen gestohlen werden.

Um Credential Guard mithilfe von Gruppenrichtlinien zu aktivieren, befindet sich die entsprechende Einstellung in den Windows-Sicherheitsoptionen für Virtualisierung. In neueren Versionen sind diese Richtlinien in der Regel unter Device Guard in der Gruppenrichtlinienobjektvorlage gruppiert , genauer gesagt unter „Virtualisierungsbasierte Sicherheit aktivieren“.

Wenn diese Richtlinie korrekt konfiguriert ist, startet das System mit VBS und aktiviert Credential Guard . Intern führt dies zu Änderungen in der Registrierung, insbesondere am folgenden Schlüssel:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

Der Wert „LsaCfgFlags“ , der das Verhalten von Credential Guard steuert, befindet sich hier. Der Wert 0 deaktiviert die Funktion, während andere Werte (abhängig von der Windows-Version) sie in verschiedenen Modi aktivieren. Wenn Sie diese Schlüssel ändern möchten, empfiehlt es sich, die Best Practices für sicheres Arbeiten mit der Windows-Registrierung zu befolgen und gegebenenfalls vorher Sicherungskopien zu erstellen.

In manchen Fällen, insbesondere bei Inkompatibilitäten, kann es erforderlich sein, Windows Defender Credential Guard vorübergehend zu deaktivieren . Citrix dokumentiert beispielsweise ein bekanntes Problem: Wenn Credential Guard auf dem Client aktiviert ist, kann die SSO-Anmeldung für virtuelle Sitzungen fehlschlagen und die Windows-Sicherheitsmeldung „Ihre Anmeldeinformationen sind ungültig. Windows Defender Credential Guard lässt die Verwendung von Windows-Anmeldeinformationen nicht zu.“ anzeigen.

In diesen Fällen gibt es zwei Hauptmöglichkeiten, es zu deaktivieren:

• Über Gruppenrichtlinien, durch Ändern der Option „Virtualisierungsbasierte Sicherheit aktivieren“ innerhalb Computerkonfiguration > Administrative Vorlagen > System > Device Guard.
• Durch Registrierung, Einrichtung LsaCfgFlags = 0 auf der oben angegebenen Route.

Es ist wichtig zu verstehen, dass diese Einschränkung auch die Verwendung von Remote Credential Guard über RDP betrifft . Wenn Sie Enhanced Domain Transfer mit SSO in Verbindung mit Credential Guard verwenden müssen, wird offiziell empfohlen, in diesem Fall eine Supportanfrage an Microsoft zu stellen.

Device Guard und Codekontrolle: Whitelists und Betriebsmodi

Während Credential Guard sich auf Anmeldeinformationen konzentriert, zielt Device Guard darauf ab, zu kontrollieren, welche Software auf dem Gerät ausgeführt werden darf. Ziel ist es, von einem herkömmlichen, auf Malware-Signaturen basierenden Modell zu einem präventiven Modell überzugehen, das nur Software zulässt, die der Administrator als vertrauenswürdig definiert hat.

In der Praxis wird Device Guard hauptsächlich durch Folgendes implementiert:

• Richtlinien zur Codeintegrität, die festlegen, welche Binärdateien, Zertifikate und Herausgeber als vertrauenswürdig gelten.
• Secure-Boot-Konfiguration und VBS zur Verhinderung Schadcode wird in frühen Phasen geladen System.
• Integration mit Bereitstellungs- und Verwaltungstools (wie Intune, GPO, SCCM) zur Verteilung signierter Richtlinien.

Das Verhalten von Device Guard kann je nach gewähltem Modus mehr oder weniger streng sein:

• Standalone-Benutzermodus (Ähnlich einem Test- oder benutzerdefinierten Modus), in dem der Benutzer ein gewisses Maß an Kontrolle behält und die Einschränkungen weniger streng sind. In Geschäftsumgebungen ist dies nicht ideal, da es menschliche Fehler begünstigt.
• Organisationsgesteuerter Modus (Unternehmensverwaltet oder unternehmensfähig), wobei der Administrator Positiv-, Grau- und Negativlisten definiert, um genau zu steuern, was erlaubt ist.

Bei diesem Geschäftsansatz regeln Richtlinien typischerweise drei Arten von Domains oder Websites:

• Vertrauenswürdige Seiten (Vertrauenswürdige Websites): Entspricht Whitelists. Dies sind bekannte Domains, bei denen das Risiko als gering eingeschätzt wird, sodass der Browser oder die Anwendung Laden Sie die Inhalte direkt auf das Gerät hoch. mit weniger zusätzlichen Einschränkungen.
• Neutrale Standorte (Neutrale Websites): Domains, die sensible (Unternehmens- oder persönliche) Informationen enthalten können und deren Umgang vom Kontext abhängt. Bei Zugriff aus einer sicheren Umgebung bleibt dieser Schutz erhalten; bei Zugriff von einer vollständig vertrauenswürdigen Website kann das Verhalten weniger streng sein.
• Nicht vertrauenswürdige Websites (Nicht vertrauenswürdige Websites): Entspricht Blacklists. Alle Inhalte, die von diesen Domains stammen, werden geöffnet. innerhalb einer isolierten Umgebung, wobei Virtualisierungstechnologie genutzt wird, um Risiken zu minimieren.

Parallel dazu wird Device Guard üblicherweise von weiteren Schichten wie Application Guard und Exploit Guard begleitet , die das Herunterladen und Ausführen potenziell gefährlicher Dateien sowie die Ausnutzung bekannter Sicherheitslücken überwachen und gegebenenfalls Warnungen und Sperren auslösen.

Anwendungsschutz und Exploit-Schutz: zusätzliche Verstärkung

Zusätzlich zu Credential Guard und Device Guard integriert Windows Technologien wie Application Guard (speziell für Browser und kritische Anwendungen) und Exploit Guard , die das Konzept der Isolation und Härtung erweitern.

Application Guard erstellt eine virtualisierte Umgebung zum Ausführen potenziell gefährlicher Websites oder Anwendungen . Beim Zugriff auf als nicht vertrauenswürdig gekennzeichnete Domains erzwingt das System deren Laden innerhalb dieser VBS-basierten „isolierten Box“ und verhindert so, dass schädliche Inhalte das Hauptsystem beeinträchtigen oder Daten stehlen.

Diese Lösung arbeitet in Verbindung mit den zuvor erwähnten Listen vertrauenswürdiger, neutraler und nicht vertrauenswürdiger Websites sowie den Device Guard-Richtlinien. Dadurch entsteht ein Modell, in dem der Browser und bestimmte wichtige Anwendungen beim Zugriff auf potenziell riskante Ressourcen isoliert arbeiten .

Exploit Guard hingegen vereint eine Reihe von Maßnahmen zur Minderung von Schwachstellen im System und in den Anwendungen und härtet Elemente wie beispielsweise:

• Speicherschutz zur Verhinderung beliebiger Ausführungen.
• Blockierung verdächtiger Verhaltensweisen, die typisch für Exploits sind.
• Kontrollierter Ordnerzugriff zum Schutz vor Ransomware.

Die Kombination aus Credential Guard, Device Guard, Application Guard und Exploit Guard bietet einen mehrschichtigen Schutz , der moderne Angriffe deutlich erschwert, insbesondere solche, die darauf abzielen, sich lateral im Netzwerk auszubreiten oder Anmeldeinformationen zu stehlen.

Unternehmenseinsatz: Windows 10/11, Windows Server 2016 und zugehörige neue Funktionen

Im Serverbereich führte Windows Server 2016 viele der bereits aus Windows 10 bekannten Funktionen ein, angepasst an die Anforderungen von Rechenzentren. Im Bereich Sicherheit stechen neben der Integration von Windows Defender als Standard-Antivirenprogramm Device Guard und Credential Guard als wichtige Tools zur Absicherung des Betriebssystems hervor. Weitere Informationen zu diesen Verbesserungen und neuen Funktionen finden Sie unter Erweiterte Sicherheit und Wichtige neue Funktionen in Windows Server.

Dank dieser Technologien ist es möglich, Domänencontroller, Anwendungsserver und Dateiserver vor Anmeldeinformationsdiebstahl und der Ausführung nicht autorisierter Binärdateien zu schützen. Dies ist insbesondere in Kombination mit anderen neuen Funktionen im Windows Server 2016-Ökosystem relevant:

• Unterstützung von verschachtelte VirtualisierungDadurch kann Hyper-V in virtuellen Maschinen ausgeführt werden, was die Einrichtung komplexer Labor- und Testumgebungen ermöglicht.
• Zusätzliche Werkzeuge wie Leistungsanalysatoren oder Bereitstellungssysteme für Geräte, die keiner Domäne beitreten.
• Neue Funktionen in PowerShell 5.1, darunter DSC (Desired State Configuration), PackageManagement/OneGet und PowerShell Direct zur Verwaltung virtueller Maschinen oder Container ohne die Notwendigkeit einer herkömmlichen Netzwerkverbindung.

Im Bereich der Infrastruktur enthält Windows Server 2016 auch Verbesserungen bei Rollen wie DNS (DNS-Richtlinien für bedingte Antworten), IPAM (zentrale IP-Adressverwaltung), IIS 10 mit Unterstützung für HTTP/2 sowie Speichertechnologien wie ReFS, NTFS-Deduplizierung, Storage Replica und Storage Spaces, die zwar nicht direkt zu Credential Guard oder Device Guard gehören, aber Teil des Sicherheits- und Verfügbarkeitsökosystems sind.

Remote Credential Guard, Citrix und die Delegierung von Anmeldeinformationen

Remote Credential Guard erweitert die Credential-Guard-Philosophie auf Remote-Verbindungsszenarien , insbesondere auf RDP- und Desktop-Virtualisierungslösungen. Der Gedanke dahinter ist, dass Benutzeranmeldeinformationen nicht ungeschützt an den Remote-Host übertragen werden, sondern dass Kerberos sicher und innerhalb der isolierten Umgebung des Clients verwendet und unterstützt wird.

Citrix nutzt diesen Ansatz für seine verbesserte Domänenübertragungsfunktionalität für SSO in der Citrix Workspace-App sowie in virtuellen Desktop- und Anwendungssitzungen, vorausgesetzt, die Clientgeräte sind in Active Directory eingebunden und Citrix StoreFront wird verwendet.

Einige wichtige Punkte dieser Funktion sind:

• Es wird auf 32-Bit-Betriebssystemen nicht unterstützt.
• Es ersetzt das Legacy-Übertragungsauthentifizierung basiert auf ssonsvr.exe.
• Die Aktivierung ist nicht gleichzeitig mit der herkömmlichen Transferauthentifizierung auf demselben Sitzungshost möglich.
• Während die herkömmliche Authentifizierung die Aktivierung der Richtlinie "MPR-Benachrichtigungen für das System aktivieren" erforderte, ermöglicht die verbesserte Übertragung SSO ohne diese Richtlinie.
• Für die domänenübergreifende Authentifizierung, ein bidirektionales transitives Vertrauen um Diensttickets über Domänengrenzen hinweg zu erhalten; andernfalls funktioniert die Kerberos-Delegierung nicht.

Hinsichtlich der Konfiguration erfordert die Integration mit Remote Credential Guard eine Reihe von Schritten in StoreFront, Citrix-Richtlinien, Sitzungshosts und Clientcomputern.

StoreFront und Citrix: SSO mit Remote Credential Guard einrichten

Damit der erweiterte Domaintransfer korrekt funktioniert, muss StoreFront so konfiguriert sein, dass es die Domaintransfer-Authentifizierung sowohl auf dem Shop als auch auf der zugehörigen Website akzeptiert.

Die allgemeinen Schritte sind:

• Öffnen Sie die StoreFront-Administrationskonsole.
• Gehen Sie zum Abschnitt Lager > Authentifizierungsmethoden verwalten, wo das Fenster angezeigt wird, das der Webseite entspricht.
• Aktivieren Sie das Kontrollkästchen „Domaintransfer“ und bestätigen Sie die Benachrichtigung.

Für die Webseite:

• Greifen Sie in derselben StoreFront-Konsole auf die Registerkarte zu. Speicher > Receiver für Web > Receiver für Web-Websites verwalten > Konfigurieren > Authentifizierungsmethoden.
• Im Fenster zur Website-Änderung das Kontrollkästchen „Domänentransfer“ aktivieren.
• Übernehmen Sie die Änderungen.

Als Nächstes müssen Sie die Citrix-Richtlinie für den erweiterten Domänentransfer aktivieren :

• Gehen Sie in Citrix Studio oder in der Webkonsole zu „Richtlinien“ und erstellen Sie eine neue Richtlinie.
• Suchen Sie nach der Einstellung „Erweiterter Domänentransfer für Single Sign-On“.
• Stellen Sie es auf „Zulässig“.
• Speichern und anwenden.

Darüber hinaus ist es auf den Sitzungshosts erforderlich, eine Windows-Richtlinie zu konfigurieren, die die Delegierung nicht exportierbarer Anmeldeinformationen ermöglicht:

• Ir a Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Anmeldeinformationsdelegierung.
• Aktivieren Sie die Option „Der Remotehost erlaubt die Delegierung nicht exportierbarer Anmeldeinformationen“.
• Starten Sie den Sitzungshost neu.

In Windows Server 2016 ist diese spezielle Einstellung nicht in der lokalen Richtlinie enthalten. Wenn Sie sie also lokal anstatt über Gruppenrichtlinien festlegen müssen, müssen Sie sie über die Registrierung unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa anpassen, indem Sie den DWORD-Wert DisableRestrictedAdmin mit dem Wert 0 erstellen/ändern .

Clientgerätekonfiguration und vertrauenswürdige Websites

Auch auf Clientseite sind Anpassungen erforderlich. Für ein reibungsloses SSO-Erlebnis über den erweiterten Domaintransfer ist es unerlässlich, die Funktion auf dem Client zu aktivieren und der StoreFront-Website zu vertrauen.

Die erweiterte Domänenübertragungsfunktion kann über lokale Richtlinien oder Gruppenrichtlinienobjekte aktiviert werden:

• Navigieren Sie zu Computerkonfiguration\Richtlinien\Administrative Vorlagen\Citrix-Komponenten\Citrix Workspace\Benutzerauthentifizierung.
• Aktivieren Sie die Einstellung „Erweiterte Domänenübertragung für Single Sign-On“.
• Starten Sie die Citrix Workspace-Anwendung neu, damit die Anpassung wirksam wird.

Parallel dazu müssen Sie sicherstellen, dass Clients die StoreFront-URL als Teil einer lokalen Intranetseite oder einer vertrauenswürdigen Website erkennen . Falls die URL nicht zu einer bereits vertrauenswürdigen Domäne gehört, kann sie über eine Direktive hinzugefügt werden:

• Ir a Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Internet Explorer\Internetoptionen\Sicherheit.
• Aktivieren Sie die Option „Site-zu-Zone-Zuordnungsliste“ und fügen Sie die entsprechenden URLs Ihrer Zone hinzu (z. B. lokales Intranet oder vertrauenswürdige Websites).
• Aktivieren Sie die Option „Anmeldeoptionen“ und stellen Sie sie auf „Automatische Anmeldung mit aktuellem Benutzernamen und Passwort“ ein.

Mit diesen Einstellungen kann der Kunde Remote Credential Guard und die erweiterte Domänenübertragung für SSO nutzen , vorausgesetzt, es gibt keine Einschränkungen aufgrund des Vorhandenseins von Windows Defender Credential Guard, wie im Abschnitt „Bekannte Probleme“ erläutert.

Zone für eingeschränkte Websites, ActiveX und Browserhärtung

Ein weiterer wichtiger Baustein im Sicherheitspuzzle von Windows ist die Konfiguration der Internet Explorer-Sicherheitszonen (die, obwohl sie schrittweise abgeschafft wird, immer noch viele Systemkomponenten beeinflusst) und damit auch die Art und Weise, wie ActiveX-Steuerelemente, Skripte und Downloads gehandhabt werden.

Die strengsten Richtlinien finden sich in den eingeschränkten Bereichen. Zu den gängigen Optionen, die über Gruppenrichtlinien angepasst werden können, gehören:

• Erlauben oder nicht domänenübergreifender Datenquellenzugriff.
• Aktivieren oder deaktivieren aktive Skripte und Binär- und Skriptverhalten.
• Prüfen Sie, ob es erlaubt ist. Dateien per Drag & Drop ablegen oder kopieren/einfügen zwischen Standorten und Fenstern.
• Dateidownloads und automatische Downloads zulassen oder blockieren.
• Steuern Sie das Laden von XAML-Dateien und die Verwendung von META REFRESH.
• Beschränken Sie die Verwendung von ActiveX auf ausdrücklich genehmigte Domänen, sowohl für die TDC-Kontrolle als auch für andere Kontrollmechanismen.
• Beschränken Sie die Anzahl der durch Skripte gestarteten Fenster ohne Größen- oder Positionsbeschränkungen.
• Verwaltung der Verwendung von VBScript, Java, Applets und .NET-abhängigen Komponenten.
• Entscheide, ob Sie führen einen Virenscan gegen ActiveX durch. oder die Nutzung ohne Antimalware zulässig ist.
• Aktivieren Sie Filter wie den Cross-Site-Scripting-Filter (XSS), Geschützter Modus oder SmartScreen-Filter.

Dieses gesamte Maßnahmenpaket ist Teil eines mehrschichtigen Sicherheitsansatzes, bei dem neben Credential Guard und Device Guard auch das Ziel verfolgt wird, die Angriffsfläche des Browsers zu verringern , der üblicherweise einer der häufigsten Einstiegspunkte ist.

ACLs, Zugriffskontrolle und PACs: zusätzlicher Sicherheitskontext

Neben VBS, VSM und Windows Guards basiert die Systemsicherheit maßgeblich auf Zugriffskontrolllisten (ACLs) . In Windows definieren ACLs, wer auf welche Ressourcen mit welchen Berechtigungen zugreifen darf, sowohl auf Dateisystemebene als auch in anderen internen Komponenten.

ACLs ermöglichen die Konfiguration sehr spezifischer Berechtigungen für Objekte (Objektberechtigungen), die über die üblichen Lese-/Schreibrechte hinausgehen. Beispielsweise können Sie einem Benutzer erlauben, den Inhalt einer Datei zu lesen, aber nicht deren Berechtigungen zu ändern, oder einem Dienst erlauben, einen Datensatz zu ändern, aber nicht zu löschen.

Die ACL-Vererbung spielt ebenfalls eine wichtige Rolle, da sie die Weitergabe von Berechtigungen an Unterordner und Dateien ermöglicht , ohne dass diese einzeln konfiguriert werden müssen. Dies erfordert jedoch Sorgfalt: Eine fehlerhafte Berechtigungsvererbung kann entweder mehr Dateien öffnen als nötig oder umgekehrt legitime Prozesse blockieren.

In komplexeren Szenarien unterstützt Windows richtlinienbasierte Zugriffssteuerungsmodelle (PAC), die dynamischere und kontextbezogene Regeln ermöglichen. All dies ist in das Protokollierungssystem integriert, das zwar hier nicht detailliert beschrieben wird, aber eine weitere wichtige Komponente für Sicherheit und Überwachung darstellt. In unserem Artikel zur Windows-Sicherheitsüberwachung erfahren Sie, wie Sie relevante Ereignisse protokollieren und überprüfen.

Die Beziehung zu VSM ist direkt: VSM verwendet ACLs und das Windows-Sicherheitsmodell, um sensible Teile des Systems zu isolieren und sicherzustellen, dass nur validierter Code mit den entsprechenden Berechtigungen mit den geschützten Komponenten interagieren kann.

Mit dem korrekten Einsatz von Credential Guard, Device Guard, Application Guard, Exploit Guard, Browserrichtlinien, gut konzipierten ACLs und der Verwendung von Sicherheitsbaselines ist es möglich, eine Windows-Umgebung zu schaffen, in der Anmeldeinformationen sicher sind, bösartiger Code nur sehr schwer ausgeführt werden kann und gängige Angriffsvektoren stark geschützt sind , während gleichzeitig ein angemessenes Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit für Endbenutzer gewahrt bleibt.