 TechNet Magazine June 2007

TechNet Magazine June 2007

Sicherheit : Die Benutzerkontensteuerung von Windows Vista

Benutzerkontensteuerung oder UAC ist eine der am meisten missverstandenen neuen Funktionen von Windows Vista. Doch ihr Ziel, Benutzern die Ausführung mit Standardbenutzerrechten zu ermöglichen, kann viele Sicherheitsprobleme lösen. Werfen Sie einen Blick hinter die Kulissen der Probleme, zu deren Lösung UAC entwickelt wurde, und erfahren Sie im Detail, wie diese neue Funktion arbeitet.

Mark Russinovich Sicherheit: Schlüssel zum Schützen von Daten durch BitLocker-Laufwerkverschlüsselung

BitLocker erfüllt zwei sehr wichtige Funktionen: Es stellt sowohl vollständige Volumedatenverschlüsselung als auch eine Möglichkeit bereit, vor dem Start von Windows Vista die Integrität der frühen Systemstartkomponenten zu prüfen. Verschaffen Sie sich einen Überblick über die Funktionsweise von BitLocker, und erfahren Sie, wie es zum Schutz Ihrer Organisation beitragen kann.

Byron Hynes Sicherheit: Im Blickpunkt: Die Windows-Firewall

Die Mobilität hat die Computerbedrohungen und die Gegenmaßnahmen geändert. Wenn Laptops den schützenden Unternehmensbereich verlassen und wieder zum Netzwerk zurückkommen, brauchen Sie bessere Möglichkeiten, um Ihre Systeme zu schützen. Sehen Sie selbst, wie Sie Ihre Computer mit der Windows-Firewall schützen können, sowohl im Internet als auch im firmeninternen Netzwerk.

Steve Riley Sicherheit: Neue ACLs erhöhen die Sicherheit in Windows Vista

ACLs wurden zwar keiner Generalüberholung unterzogen, aber es gibt eine Reihe wichtiger Änderungen, über die Sie bei der Verwaltung von ACLs in einer Windows Vista-Umgebung Bescheid wissen müssen. Finden Sie heraus, in welcher Hinsicht 30 ACLs geändert wurden, um die Sicherheit zu verbessern, erfahren Sie, wie sich diese ACLs auf Ihre Organisation auswirken, und lernen Sie, wie Sie diese Änderungen in Ihrer Infrastruktur verwalten können.

Jesper Johansson Sicherheit: Verwalten von Hardwareeinschränkungen über Gruppenrichtlinien

USB-Sticks und andere Wechselmedien bieten privat oft viele Vorteile, erschweren jedoch das Arbeitsleben. Sie benötigen die Kontrolle darüber, welche Hardwaregeräte die Benutzer auf ihren Arbeitssystemen installieren, um verbesserte Sicherheit zu gewährleisten. Jetzt können Sie mit der Gruppenrichtlinie kontrollieren, welche Geräte verwendet werden dürfen.

Jeremy Moskowitz Sicherheit: 4 Sicherheitstechnologien, die jedes IT-Unternehmen haben muss

Die meisten Unternehmen haben ähnliche Sicherheitsprobleme. In der heutigen vernetzten Welt gibt es vier allgemeine Arten von Sicherheitstools, über die jede Organisation unbedingt verfügen sollte. Finden Sie Details über diese Tools heraus, und informieren Sie sich, wie die damit verbundenen Technologien in Zukunft zusammenarbeiten können, um die ideale Sicherheitslösung zu erstellen.

Matt Clapham and Todd Thompson Sicherheit: Ein leistungsfähiges neues Tool für die Zertifikatsverwaltung

Zertifikate sind eine wichtige Komponente in Ihrer Infrastruktur: Wenn ein Zertifikat abläuft, kann die Produktivität zum Stillstand kommen. Wird in Ihrem Unternehmen die Microsoft PKI-Umgebung eingesetzt, dann kann die neue ILM-CM-Lösung (Identity Lifecycle Manager Certificate Management) dazu beitragen, den reibungslosen Lauf der Dinge beizubehalten. Sehen Sie selbst, wie Sie mit diesem Tool in der Lage sind, die Authentifizierungsprozesse zu optimieren und die Kosten für die Zertifikatsverwaltung zu senken.

Kevin Dallmann Mitteilung der Redaktion: Sicherheitsaspekte

Joshua Trupin Toolbox: Neue Produkte für IT-Profis

Greg Steen SQL – Fragen und Antworten: 64-Bit-Installationen, Zuweisen von Clusterspeicher und mehr

Edited by Nancy Michell Schwerpunkt Dienstprogramme: Skripterhöhungs-PowerToys für Windows Vista

Während die Benutzerkontensteuerung für eine wichtige Verbesserung der Sicherheit sorgt, ist die Möglichkeit zum Erhöhen der Berechtigungen für die Durchführung bestimmter Verwaltungsaufgaben und Funktionen unerlässlich. Im Folgenden werden einige Elevation PowerToys vorgestellt, die diese Erhöhung flexibler und leistungsfähiger gestalten.

Michael Murgolo The Cable Guy: Das Secure Socket Tunneling-Protokoll

VPN-Protokolle in Windows XP und Windows Server 2003 funktionieren für einige Konfigurationen nicht. Verschaffen Sie sich einen gründlichen Einblick in die verschiedenen Probleme und erfahren Sie, wie Windows Server „Longhorn“ und Windows Vista mit Service Pack 1 das Secure Socket Tunneling-Protokoll verwenden, um diese Probleme zu lösen.

Joseph Davies Windows PowerShell: Arbeiten mit Active Directory

Obwohl Windows PowerShell kein Get-ADSIObject-Cmdlet bereitstellt, steht das einer leistungsstarken ADSI-Unterstützung nicht im Wege. Lesen Sie eine Einführung zum Schreiben von Adaptern und erfahren Sie, wie Sie mithilfe von Windows PowerShell mit Verzeichnisobjekten arbeiten können.

Don Jones Hey, Scripting Guy!: Skripterstellung entlang der roten Wellenlinie

Suchen Sie eine leichtere Möglichkeit, Begriffe in das Microsoft Word-Wörterbuch einzufügen? Nicht mehr manuell, ein Wort nach dem anderen? Wer täte das nicht? In diesem Monat zeigen Ihnen die Scripting Guys, wie Sie benutzerdefinierte Wörterbücher in Microsoft Word erstellen und wie Sie Word programmgesteuert so konfigurieren, dass diese Wörterbücher auch tatsächlich verwendet werden.

The Microsoft Scripting Guys Die Desktopdateien: So behalten Sie Ihre Daten

Es überraschend, wie oft wichtige Daten verloren gehen. Tatsache ist jedoch, dass Informationen verloren gehen, weil Benutzer versäumen, ihre Daten zu schützen. Machen Sie sich daher mit den wichtigen Schritten vertraut, die Sie für den Schutz der Daten Ihrer Organisation ausführen können und müssen.

Wes Miller Berichte aus der Praxis: Kommunikation mit Entwicklern

Entwickler zur Erstellung überschaubarerer Anwendungen zu bewegen, ist leichter als Sie denken. Alles beginnt mit der Kommunikation. Entwickler sehen Software anders als Administratoren. Erst im Gespräch mit Entwicklern können Administratoren erläutern, was ihnen wichtig ist, sodass die Entwickler entsprechend besseren Code entwickeln können.

David Aiken Windows Confidential: Was neue Benutzer im Startmenü sehen

Stellen Sie sich vor, Sie kaufen einen neuen Computer, starten Windows, klicken auf die Schaltfläche „Start“ und sehen ein leeres Menü. Es gibt einen guten Grund dafür, warum das Startmenü Anwendungen als die am meisten verwendeten auflistet, noch bevor Sie irgendetwas verwendet haben, nämlich eine gute Benutzererfahrung. Finden Sie heraus, wie diese Anwendungen ausgewählt werden.

Raymond Chen Briefe: Antworten auf Ihre Fragen


 Sicherheit : Die Benutzerkontensteuerung von Windows Vista
Sicherheit Mark Russinovich

Die Benutzerkontensteuerung von Windows Vista
Kurz zusammengefasst:
  • Ausführung als Standardbenutzer
  • Datei- und Registrierungsvirtualisierung
  • Erhöhen des Kontostatus

Die Benutzerkontensteuerung (UAC) ist eine Funktion von Windows Vista, die häufig missverstanden wird. In meiner dreiteiligen TechNet Magazin-Reihe über Änderungen des Windows Vista-Kernels, die online unter technetmagazine.com verfügbar ist, bin ich auf UAC nicht eingegangen, da ich das Gefühl hatte, dass UAC ihren eigenen Artikel verdient.
In diesem Artikel behandle ich die Probleme, die UAC löst, und beschreibe die Architektur und die Implementierung ihrer Komponententechnologien. Diese Technologien umfassen die Umgestaltung von Operationen, für die vorher Administratorrechte erforderlich waren, die einfache Virtualisierung, um Programmen zu helfen, ohne Administratorrechte korrekt ausgeführt werden zu können, die Möglichkeit für Programme, explizit Administratorrechte anzufordern, und die Isolierung administrativer Prozesse von Prozessen, die nicht administrativ sind und auf demselben Benutzerdesktop ausgeführt werden.

Das Ziel von UAC
UAC soll Benutzern die Ausführung mit Standardbenutzerrechten statt mit Administratorrechten ermöglichen. Administratorrechte geben Benutzern die Fähigkeit, jeden beliebigen Teil des Betriebssystems zu lesen und zu ändern, einschließlich des Codes und der Daten von anderen Benutzern und sogar von Windows® selbst. Ohne Administratorrechte können Benutzer nicht versehentlich (oder vorsätzlich) Systemeinstellungen ändern, können böswillige Programme keine Systemsicherheitseinstellungen ändern und keine Antivirussoftware deaktivieren und können Benutzer die vertraulichen Informationen anderer Benutzer auf freigegebenen Computern nicht einsehen. Aus diesem Grund kann eine Ausführung mit Standardbenutzerrechten die Zahl der dringenden Anfragen beim Helpdesk in Firmenumgebungen verringern, die Auswirkungen böswilliger Programme mindern, einen reibungsloseren Betrieb von Computern zu Hause gewährleisten und vertrauliche Daten auf freigegebenen Computern schützen.
UAC musste dabei mehrere Probleme lösen, um eine Ausführung mit einem Standardbenutzerkonto praktikabel zu machen. Das erste dieser Probleme bestand darin, dass vor Windows Vista™ beim Windows-Nutzungsmodell davon ausgegangen wurde, mit Administratorrechten arbeiten zu müssen. Softwareentwickler gingen davon aus, dass ihre Programme in der Lage sein mussten, auf alle Dateien, Registrierungsschlüssel oder Betriebssystemeinstellungen zuzugreifen und diese zu ändern. Sogar dann, als in Windows NT® Sicherheit eingeführt wurde und zwischen Zugriffsrechten für Administratorbenutzer und Zugriffsrechten für Standardbenutzer unterschieden wurde, wurden die Benutzer durch einen Installationsvorgang geführt, in dem sie ermutigt wurden, das integrierte Administratorkonto zu verwenden, das ein Mitglied der Gruppe „ADMINISTRATOREN“ war.
Das zweite Problem, das von UAC gelöst werden musste, lag darin, dass Benutzer manchmal Administratorrechte benötigen, um Vorgänge wie beispielsweise das Installieren von Software, das Ändern der Systemzeit und das Öffnen von Anschlüssen im Firewall durchzuführen.
Die UAC löst diese Probleme, indem die meisten Anwendungen mit Standardbenutzerrechten ausgeführt werden, die Notwendigkeit von Administratorenrechten überflüssig gemacht wird und Softwareentwickler dazu ermutigt werden, Anwendungen zu entwickeln, die mit Standardbenutzerrechten ausgeführt werden. UAC erreicht dies, indem sie sicherstellt, dass Administratorrechte seltener benötigt werden, Legacyanwendungen die Möglichkeit bietet, mit Standardbenutzerrechten ausgeführt zu werden, Standardbenutzern einen einfacheren Zugriff auf Administratorrechte ermöglicht, sobald sie diese Rechte benötigen, und selbst Administratoren die Ausführung als Standardbenutzer ermöglicht.

Ausführung als Standardbenutzer
Durch eine vollständige Überwachung aller administrativen Vorgänge während der Entwicklung von Windows Vista wurden zahlreiche Administrationsvorgänge identifiziert, die man von Standardbenutzern ausführen lassen könnte, ohne dadurch die Sicherheit des Systems zu gefährden. So konnten beispielsweise selbst Unternehmen, die für ihre Windows XP-Desktopsysteme Standardbenutzerkonten einrichteten, nicht durchsetzen, ihre mobilen Benutzer von der Gruppe „ADMINISTRATOREN“ fernzuhalten, weil Windows XP ganz einfach keinen Unterschied zwischen dem Ändern der Zeitzone und dem Ändern der Systemzeit macht. Ein Laptopbenutzer, der die lokale Zeitzone konfigurieren möchte, damit auf Geschäftsreisen seine Termine in seinem Kalender korrekt angezeigt werden, muss über die Berechtigung zum Ändern der Systemzeit (intern als SeSystemTimePrivilege bezeichnet) verfügen, die standardmäßig nur Administratoren gewährt wird.
Da die Uhrzeit häufig in Sicherheitsprotokollen wie z. B. Kerberos verwendet wird, sich aber die Zeitzone nur darauf auswirkt, wie diese Uhrzeit angezeigt wird, wird in Windows Vista die neue Berechtigung zum Ändern der Zeitzone (SeTimeZonePrivilege) hinzugefügt und der Gruppe „BENUTZER“ zugeordnet, wie in Abbildung 1 zu sehen ist. Dies ermöglicht es vielen Unternehmen, ihre Laptopbenutzer Standardbenutzerkonten verwenden zu lassen.
Abbildung 1 Die Berechtigung zum Ändern der Zeitzone
Abbildung 1 Die Berechtigung zum Ändern der Zeitzone
Windows Vista gestattet Standardbenutzern auch, WPE-Einstellungen zu konfigurieren, wenn sie eine Verbindung zu drahtlosen Netzwerken herstellen, VPN-Verbindungen zu erstellen, Energieverwaltungseinstellungen zu ändern und wichtige Windows-Updates zu installieren. Darüber hinaus führt es Gruppenrichtlinieneinstellungen ein, die Standardbenutzern ermöglichen, Drucker und andere von IT-Administratoren genehmigten Gerätetreiber zu installieren und auf den von Administratoren genehmigten Websites ActiveX®-Steuerelemente zu installieren.
Wie sieht es nun mit Anwendungen für Privatanwender und Branchenanwendungen aus, die sich mit Standardbenutzerkonten nicht korrekt ausführen lassen? Während manche Programme zu Recht Administratorrechte erfordern, speichern viele Programme Benutzerdaten völlig unnötig an globalen Systemspeicherorten. Von Microsoft wird empfohlen, dass die Installationsprogramme für globale Anwendungen, die erwarten, mit Administratorrechten ausgeführt zu werden, unter dem Verzeichnis „%ProgramFiles%“ ein Verzeichnis anlegen sollten, um die ausführbaren Dateien und die Hilfsdateien ihrer Anwendung darin zu speichern, und unter „HKEY_LOCAL_MACHINE\Software“ einen Schlüssel für ihre Anwendungseinstellungen erstellen sollten. Wenn eine Anwendung ausgeführt wird, kann sie unter verschiedenen Benutzerkonten laufen und sollte sie daher benutzerspezifische Daten im Verzeichnis „%AppData%“ des jeweiligen Benutzers und benutzerspezifische Einstellungen im Registrierungsprofil des betreffenden Benutzers unter „HKEY_CURRENT_USER\Software“ speichern. Standardbenutzerkonten haben keinen Schreibzugriff auf das Verzeichnis „%ProgramFiles%“ oder auf „HKEY_LOCAL_MACHINE\Software“, aber da die meisten Windows-Systeme Einzelbenutzersysteme sind und bis zur Einführung von Windows Vista die meisten Benutzer Administratoren waren, werden Anwendungen, die die Daten und Einstellungen von Benutzern fälschlicherweise an diesen Orten speichern, ohnehin funktionieren.
Windows Vista ermöglicht diesen Legacyanwendungen durch die Dateisystem- und Registrierungsnamespacevirtualisierung, unter Standardbenutzerkonten ausgeführt zu werden. Wenn eine Anwendung einen globalen Systemspeicherort im Dateisystem oder in der Registrierung ändert und dieser Vorgang fehlschlägt, weil der Zugriff verweigert wird, leitet Windows den Vorgang in einen Einzelbenutzerbereich um. Wenn die Anwendung aus einem globalen Systemspeicherort liest, sucht Windows zuerst im Einzelbenutzerbereich nach Daten und gestattet dann, falls dort keine Daten vorhanden sind, den Leseversuch im globalen Speicherort.
Zur Unterstützung dieser Virtualisierung behandelt Windows Vista einen Prozess als Legacyprozess, wenn es sich um einen 32-Bit-Prozess (im Gegensatz zu einem 64-Bit-Prozess) handelt, der Prozess nicht mit Administratorrechten ausgeführt wird und er keine Manifestdatei besitzt, die angibt, dass er für Windows Vista geschrieben wurde. Alle Vorgänge, die nicht von einem Prozess stammen, der nach dieser Definition als Legacyprozess eingestuft wird, einschließlich aller Netzwerkdateifreigabezugriffe, werden nicht virtualisiert. Der Virtualisierungsstatus eines Prozesses wird als Kennzeichen in seinem Token gespeichert. Es handelt sich dabei um die Kerneldatenstruktur, die den Sicherheitskontext eines Prozesses einschließlich seines Benutzerkontos, seiner Gruppenmitgliedschaften und seiner Berechtigungen verfolgt.
Sie können den Virtualisierungsstatus eines Prozess sichtbar machen, indem Sie der Seite „Prozesse“ des Task-Managers die Spalte „Virtualisierung“ hinzufügen. Abbildung 2 zeigt, dass bei den meisten Komponenten von Windows Vista, einschließlich Desktopfenster-Manager (Dwm.exe), Client Server Runtime Subsystem (Csrss.exe) und Explorer, entweder die Virtualisierung deaktiviert ist, da sie ein Windows Vista-Manifest besitzen, oder die Komponente mit Administratorrechten ausgeführt wird und daher keine Virtualisierung möglich ist. Bei Internet Explorer® (iexplore.exe) ist Virtualisierung aktiviert, weil Internet Explorer mehrere ActiveX-Steuerelemente und Skripts hosten kann und davon ausgehen muss, dass diese nicht dafür geschrieben wurden, mit Standardbenutzerrechten einwandfrei zu funktionieren.
Abbildung 2 Der Task-Manager zeigt den Virtualisierungsstatus an.
Abbildung 2 Der Task-Manager zeigt den Virtualisierungsstatus an.
Bei den Dateisystemspeicherorten, die für Legacyprozesse virtualisiert werden, handelt es sich um „%ProgramFiles%“, „%ProgramData%“ und „%SystemRoot%“, wobei einige Unterverzeichnisse von der Virtualisierung ausgenommen sind. Allerdings sind alle Dateien mit einer Ausführungserweiterung, wie z. B. .exe, .bat, .scr, .vbs und so weiter, von der Virtualisierung ausgeschlossen. Dies bedeutet, dass Programme, die sich unter einem Standardbenutzerkonto selbst aktualisieren, fehlschlagen, anstatt private Versionen ihrer ausführbaren Dateien zu erstellen, die für einen Administrator, der ein globales Aktualisierungsprogramm ausführt, nicht sichtbar sind. Um zur Ausnahmeliste weitere Namenserweiterungen hinzuzufügen, geben Sie die gewünschten Namenserweiterungen in den folgenden Registrierungsschlüssel ein und führen Sie einen Neustart aus:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Verwenden Sie einen Typ für mehrere Zeichenfolgen, um mehrere Namenserweiterungen voneinander abzugrenzen, und setzen Sie vor die Namenserweiterung keinen Punkt.
Bei Änderungen an virtualisierten Verzeichnissen durch Legacyprozesse erfolgt eine Umleitung zum virtuellen Stammverzeichnis „%LocalAppData%\VirtualStore“ des Benutzers. Wenn beispielsweise ein auf meinem System ausgeführter virtualisierter Prozess eine Datei mit dem Pfadnamen „C:\Windows\Application.ini“ erstellt, wird in Wirklichkeit eine Datei mit dem Pfadnamen „C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini“ erstellt. Die Komponente „Local“ dieses Pfads unterstreicht die Tatsache, dass virtualisierte Dateien nicht beim Rest des Profils gespeichert werden, wenn das Konto ein Roamingprofil besitzt.
Wenn Sie in Explorer zu einem Verzeichnis navigieren, in dem virtualisierte Dateien enthalten sind, besitzt Explorer, wie in Abbildung 3 zu sehen ist, in seiner Symbolleiste eine Schaltfläche namens „Kompatibilitätsdateien“. Wenn Sie auf diese Schaltfläche klicken, gelangen Sie zum entsprechenden VirtualStore-Unterverzeichnis und werden die virtualisierten Dateien angezeigt.
Abbildung 3 Die Schaltfläche „Kompatibilitätsdateien“ weist darauf hin, dass virtualisierte Dateien in der Nähe sind.
Abbildung 3 Die Schaltfläche „Kompatibilitätsdateien“ weist darauf hin, dass virtualisierte Dateien in der Nähe sind.
Abbildung 4 zeigt, wie der UAC File Virtualization Filter Driver (%SystemRoot%\System32\Drivers\Luafv.sys) die Dateisystemvirtualisierung implementiert. Da es sich hierbei um einen Dateisystemfiltertreiber handelt, erkennt er alle Dateisystemoperationen, implementiert er aber nur Funktionen für Operationen von Legacyprozessen. Sie können erkennen, dass er den Zieldateipfad bei einem Legacyprozess ändert, der eine Datei in einem globalen Systemspeicherort erstellt, dies aber nicht bei einem Prozess tut, der eine Windows Vista-Anwendung mit Standardbenutzerrechten ausführt. Der Legacyprozess glaubt, dass die Operation erfolgreich verläuft, während in Wirklichkeit die Datei in einem für den Benutzer vollkommen zugänglichen Speicherort erstellt wird, aber Standardberechtigungen für das Verzeichnis „\Windows“ der in Windows Vista geschriebenen Anwendung den Zugriff verweigern.
Abbildung 4 Dateisystemvirtualisierung
Abbildung 4 Dateisystemvirtualisierung
Die Registrierungsvirtualisierung wird ein wenig anders implementiert als die Dateisystemvirtualisierung. Zu den virtualisierten Registrierungsschlüsseln gehört der größte Teil des Zweiges „HKEY_LOCAL_MACHINE\Software“, aber es gibt zahlreiche Ausnahmen, wie z. B. die Folgenden:
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Nur Schlüssel, die von Legacyanwendungen häufig geändert werden, aber keine Kompatibilitäts- oder Interoperabilitätsprobleme verursachen, werden virtualisiert. Windows leitet Änderungen virtualisierter Schlüssel durch eine Legacyanwendung zum virtuellen Registrierungsstamm eines Benutzers unter „HKEY_ CURRENT_USER\Software\Classes\VirtualStore“ um. Der Schlüssel befindet sich in „%LocalAppData%\Microsoft\Windows\UsrClass.dat“, der Klassenstruktur des Benutzers, die wie alle anderen virtualisierten Daten nicht zusammen mit dem Roamingprofil gespeichert werden.
Statt eine feststehende Liste virtualisierter Speicherorte zu verwalten, wie Windows dies für das Dateisystem tut, wird der Virtualisierungsstatus eines Schlüssels als ein Kennzeichen namens REG_ KEY_DONT_VIRTUALIZE im Schlüssel selbst gespeichert. Jetzt kann das Dienstprogramm Reg.exe sowohl das Kennzeichen als auch die beiden anderen mit der Virtualisierung in Verbindung stehenden Kennzeichen REG_KEY_ DONT_SILENT_FAIL und REG_KEY_ RECURSE_FLAG anzeigen, wie in Abbildung 5 zu sehen ist. Wenn REG_KEY_DONT_SILENT_FAIL gesetzt und der Schlüssel nicht virtualisiert wird (REG_KEY_DONT_ VIRTUALIZE wurde gesetzt), wird einer Legacyanwendung, der normalerweise der Zugriff verweigert würde, sobald sie versuchen würde, am Schlüssel eine Operation durchzuführen, stattdessen jeder dem Benutzer zustehende Zugriff auf den Schlüssel statt die in der Anwendung geforderten Zugriffe gewährt. REG_KEY_RECURSE_FLAG gibt an, ob neue Unterschlüssel die Virtualisierungskennzeichen des übergeordneten Schlüssels erben, statt nur die Standardkennzeichen zu erben.
Abbildung 5 Das Reg-Dienstprogramm zeigt Virtualisierungskennzeichen an.
Abbildung 5 Das Reg-Dienstprogramm zeigt Virtualisierungskennzeichen an.
Abbildung 6 zeigt, wie Registrierungsvirtualisierung vom Konfigurationsmanager implementiert wird, der die Registrierung im Betriebssystemkernel Ntoskrnl.exe verwaltet. Genau wie bei der Dateisystemvirtualisierung wird ein Legacyprozess, der einen Subschlüssel eines virtualisierten Schlüssels erstellt, zum virtuellen Registrierungsstamm des Benutzers umgeleitet, wird aber einem Windows Vista-Prozess der Zugriff durch Standardberechtigungen verweigert.
Zusätzlich zur Dateisystem- und Registrierungsvirtualisierung erfordern einige Anwendungen weitere Hilfe, um mit Standardbenutzerrechten korrekt ausgeführt werden zu können. So kann es beispielsweise vorkommen, dass eine Anwendung, die das Konto, in dem sie ausgeführt wird, auf seine Mitgliedschaft in der Gruppe „ADMINISTRATOREN“ testet, nicht ausgeführt werden kann, wenn es nicht Mitglied dieser Gruppe ist, obwohl es andernfalls funktionieren würde. Windows Vista definiert daher eine Reihe von Anwendungskompatibilitätsstartmodulen, damit solche Anwendungen trotzdem funktionieren. Die auf Legacyanwendungen für den Umgang mit Standardrechten am häufigsten angewendeten Startmodule sind in Abbildung 7 zu sehen. IT-Experten eines Unternehmens können Tools wie beispielsweise ACT (Application Compatibility Toolkit, Anwendungskompatibilitäts-Toolkit, erhältlich über technet.microsoft.com/windowsvista/aa905066.aspx) und dessen Dienstprogramm SUA (Standard User Analyzer) oder LUA Buglight von Aaron Margosis dazu verwenden, die Startmodulanforderungen für ihre Branchennwendungen zu identifizieren. Sie weisen einer Anwendung mithilfe des Compatibility Administrator-Tools, das ein Bestandteil von ACT ist, Startmodule zu und stellen danach die dadurch entstehende Kompatibilitätsdatenbank (.sdb-Datei) über Gruppenrichtlinien auf ihren Desktops bereit. Beachten Sie, dass die Virtualisierung erforderlichenfalls mithilfe einer lokalen Sicherheitsrichtlinieneinstellung für ein System vollständig deaktiviert werden kann.
Figure 7 Häufige Benutzerstartmodule (Close Figure 7)

Startmodule | Zweck
ElevateCreateProcess | Ändert CreateProcess dahingehend, ERROR_ELEVATION_REQUIRED-Fehler zu verarbeiten, indem der Application Information Service aufgerufen wird, um eine Erweiterung anzufordern.
ForceAdminAccess | Spooft Abfragen der Administratorgruppenmitgliedschaft.
VirtualizeDeleteFile | Spooft die erfolgreiche Löschung globaler Dateien und Verzeichnisse.
LocalMappedObject | Zwingt Objekte des globalen Abschnitts in den Namespace des Benutzers.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Leitet die globale Registrierung von COM-Objekten in einen benutzerspezifischen Speicherort um.
Die Auswirkungen von Virtualisierung
Sie können den Virtualisierungsstatus eines Prozesses ändern, indem Sie im Kontextmenü, das angezeigt wird, wenn Sie im Task-Manager mit der rechten Maustaste klicken, die Option „Virtualization“ (Virtualisierung) auswählen. Abbildung A zeigt das Verhalten eines Eingabeaufforderungsfensters, wenn sich sein Virtualisierungsstatus ändert. Es wird mit deaktivierter Virtualisierung gestartet, weil es ein Windows Vista-Manifest besitzt. Weil es mit Standardbenutzerrechten ausgeführt wird, ist es nicht in der Lage, im Verzeichnis „\Windows“ eine Datei zu erstellen, aber nachdem es mit dem Task-Manager virtualisiert wurde, scheint es die Datei erfolgreich zu erstellen. Wenn es wieder den Status einer deaktivierten Virtualisierung zurückerhält, kann es die Datei nicht finden, die sich in Wirklichkeit im virtuellen Speicher des Benutzers befindet.
Abbildung A Eine Änderung des Virtualisierungsstatus.
Abbildung A Eine Änderung des Virtualisierungsstatus.

Administratorgenehmigungsmodus
Selbst dann, wenn Benutzer nur Programme ausführen, die mit Standardbenutzerrechten kompatibel sind, erfordern einige Operationen nach wie vor Administratorrechte. Die meisten Softwareinstallationen erfordern Administratorrechte, um Verzeichnisse und Registrierungsschlüssel in globalen Systemspeicherorten zu erstellen oder Dienste oder Gerätetreiber zu installieren. Auch zum Ändern globaler Windows-Systemeinstellungen und Anwendungssystemeinstellungen sowie zum Bedienen der Zugangskontrollfunktion von Windows Vista werden Administratorrechte benötigt. Es wäre möglich, die meisten dieser Operationen durch das Wechseln zu einem dedizierten Administratorkonto durchzuführen, aber die Umständlichkeit dieser Vorgehensweise würde wahrscheinlich dazu führen, dass die meisten Benutzer im Administratorkonto bleiben würden, um ihre täglichen Aufgaben zu verrichten.
Aus diesem Grund bietet Windows Vista eine verbesserte „Ausführen als“-Funktionalität, mit der Standardbenutzer auf praktische Art Prozesse mit Administratorrechten starten können. Diese Funktionalität hat es notwendig gemacht, Anwendungen eine Möglichkeit zu geben, Operationen zu identifizieren, für die das System bei Bedarf für die betreffende Anwendung Administratorrechte erhalten kann. Dieses Verfahren werde ich weiter unten beschreiben.
Damit Benutzer, die als Systemadministratoren arbeiten, mit Standardbenutzerrechten ausgeführt werden können, aber nicht jedesmal Benutzernamen und Kennwörter eingeben müssen, sobald sie auf Administratorrechte zugreifen möchten, wurde in Windows Vista zusätzlich der Administratorgenehmigungsmodus (AAM) eingeführt. Diese Funktion erstellt bei der Anmeldung zwei Identitäten für den Benutzer: Eine Identität mit Standardbenutzerrechten und eine weitere Identität mit Administratorrechten. Da in einem Windows Vista-System jeder Benutzer entweder ein Standardbenutzer ist oder zum größten Teil als Standardbenutzer in AAM ausgeführt wird, müssen die Entwickler davon ausgehen, dass alle Windows-Benutzer Standardbenutzer sind, was zur Folge hat, dass mehr Programme mit Standardbenutzerrechten ohne Virtualisierung oder Startmodule funktionieren werden.
Die Zuweisung von Administratorrechten zu einem Prozess wird als Erweiterung bezeichnet. Wenn dies durch ein Standardbenutzerkonto durchgeführt wird, wird es als OTS (Over the Shoulder)-Erweiterung bezeichnet, da es die Eingabe von Anmeldeinformationen für ein Konto erfordert, das ein Mitglied der Gruppe „ADMINISTRATOREN“ ist, was normalerweise getan wird, indem ein anderer Benutzer über die Schulter des Standardbenutzers hinweg etwas eingibt. Eine Erweiterung, die von einem AAM-Benutzer durchgeführt wird, wird als Zustimmungserweiterung bezeichnet, da der Benutzer lediglich der Zuweisung seiner Administratorrechte zustimmen muss.
Windows Vista betrachtet einen Benutzer als Administrator, wenn dieser Benutzer ein Mitglied einer der in Abbildung 8 aufgelisteten administratorartigen Gruppen ist. Viele der aufgelisteten Gruppen werden nur in mit einer Domäne verbundenen Systemen verwendet und gewähren dem Benutzern nicht direkt lokale Administratorrechte, ermöglichen ihnen aber, domänenweite Einstellungen zu ändern. Wenn ein Benutzer ein Mitglied einer dieser Gruppen ist, aber nicht der eigentlichen Administratorgruppe angehört, dann greift der Benutzer auf seine Administratorrechte nicht über Zustimmungserweiterung, sondern über OTS-Erweiterung zu.
Figure 8 Administratorengruppen (Close Figure 8)

Integrierte Administratoren
Zertifikatsadministratoren
Domänenadministratoren
Unternehmensadministratoren
Richtlinienadministratoren
Schemaadministratoren
Domänencontroller
Read-Only-Domänencontroller eines Unternehmens
Read-Only-Domänencontroller
Kontenoperatoren
Sicherungsoperatoren
Kryptografische Operatoren
Netzwerkkonfigurationsoperatoren
Druckoperatoren
Systemoperatoren
RAS-Server
Hauptbenutzer
Prä-Windows 2000-kompatibler Zugriff
Wenn sich ein Benutzer anmeldet, der einer der aufgelisteten Gruppen angehört, dann erstellt Windows Vista ein Token, das die Standardbenutzerversion der administrativen Identität des Benutzers repräsentiert. Aus dem neuen Token werden alle dem Benutzer zugewiesenen Berechtigungen außer den in Abbildung 9 aufgelisteten Berechtigungen entfernt, bei denen es sich um die Standardberechtigungen für Standardbenutzer handelt. Zusätzlich werden im neuen Token alle administratorartigen Gruppen mit dem Kennzeichen USE_FOR_DENY_ONLY gekennzeichnet. Abbildung 10 zeigt den Process Explorer von Sysinternals (ein Prozessverwaltungstool, das Sie von der Website microsoft.com/technet/sysinternals herunterladen können), auf dessen rechter Seite die Gruppenmitgliedschaften und -berechtigungen eines mit Administratorrechten ausgeführten Prozesses und auf dessen linker Seite die Gruppenmitgliedschaften und -berechtigungen eines ohne Administratorrechte ausgeführten Prozesses angezeigt werden. (Um eine unbeabsichtigte Verwendung zu verhindern, erfordert das Windows-Sicherheitsmodell, dass eine Berechtigung mit deaktiviertem Kennzeichen zuerst aktiviert werden muss, bevor sie verwendet werden kann.)
Figure 9 Standardbenutzerberechtigungen (Close Figure 9)

Anzeigename | Interner Name
Traversierungsüberprüfung umgehen | SeChangeNotifyPrivilege
Herunterfahren des Systems | SeShutdownPrivilege
Entfernen des Computers von der Dockingstation | SeUndockPrivilege
Vergrößern eines Prozessworkingsets | SeIncreaseWorkingSetPrivilege
Ändern der Zeitzone | SeTimeZonePrivilege
Abbildung 10 AAM-Administrator und Standardbenutzertoken
Abbildung 10 AAM-Administrator und Standardbenutzertoken
Eine Gruppe mit dem DENY-ONLY-Kennzeichen kann nur dazu verwendet werden, dem Benutzer den Zugriff auf eine Ressource zu verweigern, aber nicht dazu, den Zugriff auf eine Ressource zu erlauben, wodurch eine Sicherheitslücke geschlossen wird, die entstehen könnte, wenn man die Gruppe stattdessen gänzlich entfernen würde. Wenn beispielsweise eine Datei eine Zugriffssteuerungsliste (ACL) hätte, die der Gruppe „ADMINISTRATOREN“ jeglichen Zugriff verweigern, aber einer anderen Gruppe, der der Benutzer angehört, eingeschränkten Zugriff gewähren würde, dann würde dem Benutzer Zugriff gewährt, falls die Administratorengruppe im Token fehlen würde, wodurch die Standardbenutzerversion der Identität des Benutzers mehr Zugriff als seine Administratoridentität erhielte.
Eigenständige Systeme, bei denen es sich in der Regel um Privatcomputer zu Hause handelt, sowie mit einer Domäne verbundene Systeme behandeln AAM-Zugriff durch Remotebenutzer unterschiedlich, da mit einer Domäne verbundene Computer in ihren Ressourcenberechtigungen Domänenadministrationsgruppen verwenden können. Wenn ein Benutzer auf die Dateifreigabe eines eigenständigen Computers zugreift, fordert Windows die Standardbenutzeridentität des Remotebenutzers an, aber bei mit einer Domäne verbundenen Systemen berücksichtigt Windows sämtliche Domänengruppenmitgliedschaften des Benutzers, indem es die administrative Identität des Benutzers anfordert.

Praktischer Zugriff auf Administratorrechte
Es gibt eine Reihe anderer Verfahren, mit denen das System und die Anwendungen die Notwendigkeit von Administratorrechten identifizieren kann. Eines dieser Verfahren, das in der Benutzeroberfläche des Explorers auftaucht, besteht aus der Funktion „Ausführen als Administrator“, die als Option im Kontextmenü und als Tastenkombination angezeigt wird. Diese Optionen verwenden ein farbiges Schildsymbol, das auf einer Schaltfläche oder einem Menübefehl platziert werden muss und beim Auswählen zu einer Erweiterung der Rechte führt. Das Auswählen der Option „Ausführen als Administrator“ hat zur Folge, dass Explorer die ShellExecute-API mit dem Verb „runas“ aufruft.
Da die meisten Installationsprogramme Administratorrechte erfordern, enthält das Bildladeprogramm, das den Start einer ausführbaren Datei initiiert, Installationsprogrammerkennungscode, um wahrscheinliche Legacyinstallationsprogramme zu identifizieren. Einige der Heuristiken, die es verwendet, dienen lediglich dazu, zu erkennen, ob das Bild in seinem Dateinamen oder in seinen internen Versionsinformationen die Wörter „Setup“, „Install“ oder „Update“ enthält. Kompliziertere Heuristiken suchen in der ausführbaren Datei nach Bytesequenzen, die in Installationswrapperprogrammen von Drittanbietern häufig vorkommen.
Das Bildladeprogramm ruft auch die Anwendungskompatibilitätsbibliothek (appcompat) auf, um nachzusehen, ob die Zielausführungsdatei Administratorrechte erfordert. Die Bibliothek sieht in der Anwendungskompatibilitätsdatenbank nach, um zu prüfen, ob mit der ausführbaren Datei die Kennzeichen „RequireAdministrator“ oder „RunAsInvoker“ verknüpft sind.
Das von ausführbaren Dateien am häufigsten verwendete Verfahren, Administratorrechte anzufordern, besteht darin, in seine Anwendungsmanifestdatei ein requestedElevationLevel-Tag aufzunehmen. Manifeste sind XML-Dateien, die zusätzliche Informationen zu einem Bild enthalten. Sie wurden in Windows XP als Möglichkeit eingeführt, Abhängigkeiten von DLL-Dateien und Microsoft .NET Framework-Assemblys zu identifizieren. Die Präsenz des trustInfo-Elements in einem Manifest (Sie können es unten in dem Zeichenfolgenauszug der Datei Firewallsettings.exe sehen) kennzeichnet eine für Windows Vista geschriebene ausführbare Datei und das in ihr verschachtelte requestedElevationLevel-Element. Das Ebenenattribut des Elements kann einen von drei Werten haben: „asInvoker“, „highestAvailable“ und „requireAdministrator“.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Ausführbare Dateien, die keine Administratorrechte erfordern, wie z. B. Notepad.exe, verwenden den Wert „asInvoker“. Einige ausführbare Dateien erwarten, dass Administratoren immer maximalen Zugriff haben möchten, und verwenden daher den Wert „highestAvailable“. Ein Benutzer, der eine ausführbare Datei mit diesem Wert ausführt, wird nur dann zu einer Erweiterung aufgefordert, wenn er in AAM ausgeführt oder nach den zuvor definierten Regeln als Administrator betrachtet wird und diese Erweiterung vornehmen muss, um auf seine Administratorrechte zuzugreifen. Regedit.exe, Mmc.exe und Eventvwr.exe sind Beispiele für Anwendungen, die den Wert „highestAvailable“ verwenden. „requireAdministrator“ löst stets eine Erweiterungsanforderung aus und wird von jeder ausführbaren Datei verwendet, die ohne Administratorrechte nicht funktionieren kann.
Eingabehilfeanwendungen setzen das uiAccess-Attribut auf „True“, um die Fenstereingabe erweiterter Prozesse zu steuern, und müssen auch signiert sein und sich in einem von mehreren sicheren Speicherorten einschließlich „%SystemRoot%“ und „%ProgramFiles%“ befinden, um dies tun zu können.
Eine einfache Methode, um die von einer ausführbaren Datei festgelegten Werte zu ermitteln, besteht darin, mithilfe des Dienstprogramms Sigcheck von Sysinternals wie folgt ihr Manifest anzuzeigen:
sigcheck –m <executable>
Das Ausführen eines Bildes, das Administratorrechte anfordert, führt dazu, dass der Application Information Service (AIS, in der Datei „%SystemRoot%\System32\Appinfo.dll“ enthalten), der innerhalb eines Diensthostprozesses (%SystemRoot%\System32\Svchost.exe) ausgeführt wird, die Datei Consent.exe (%SystemRoot%\System32\Consent.exe) startet. Die Datei Consent.exe liest ein Bitmap des Bildschirms ein, wendet einen Ausblendungseffekt darauf an, wechselt zu einem Desktop, der nur für das lokale Systemkonto zugänglich ist, und zeigt ein Erweiterungsdialogfeld an, in dem Informationen zur ausführbaren Datei enthalten sind. Durch das Anzeigen eines separaten Desktops wird jedes im Konto des Benutzers vorhandene böswillige Programm daran gehindert, das Erscheinungsbild des Dialogfelds zu ändern.
Abbildung 11 OTS-Erweiterungsdialogfelder
Abbildung 11 OTS-Erweiterungsdialogfelder
Wenn ein Bild eine von Microsoft digital signierte Windows-Komponente ist und sich im Systemverzeichnis von Windows befindet, dann ist, wie in Abbildung 11 gezeigt, im oberen Rand des Dialogfelds ein blauer Streifen zu sehen. Der graue Streifen (mittleres Dialogfeld) kennzeichnet Bilder, die nicht von Microsoft, sondern von einer anderen Person oder Organisation digital signiert wurden, und der orange Streifen (unteres Dialogfeld) kennzeichnet Bilder, die nicht signiert wurden. Das Erweiterungsdialogfeld zeigt bei digital signierten Bildern das Symbol des Bildes, seine Beschreibung und seinen Herausgeber an, aber bei Bildern, die nicht signiert wurden, zeigt es lediglich ein generisches Symbol, den Dateinamen und die Zeichenfolge „Unidentified Publisher“ (Unbekannter Herausgeber) an. Dies macht es für böswillige Programme schwieriger, das Erscheinungsbild legitimer Software nachzuahmen. Die Schaltfläche „Details“ im unteren Bereich des Dialogfelds wird erweitert und zeigt die Befehlszeile an, die beim Starten der ausführbaren Datei an die Datei übergeben wird. Das in Abbildung 12 gezeigte AAM-Zustimmungsdialogfeld ist ähnlich, fordert jedoch nicht zur Eingabe von Administratoranmeldeinformationen auf, sondern stellt die Schaltflächen „Weiter“ und „Abbrechen“ bereit.
Abbildung 12 AAM-Erweiterungsdialogfeld
Abbildung 12 AAM-Erweiterungsdialogfeld
Wenn ein Benutzer eine Erweiterung ablehnt, gibt Windows einen „Zugriff verweigert“-Fehler zum Prozess zurück, der den Start initiiert hat. Wenn ein Benutzer einer Erweiterung zustimmt, indem er entweder Administratoranmeldeinformationen eingibt oder auf die Schaltfläche „Weiter“ klickt, ruft AIS CreateProcessAsUser auf, um den Prozess mit der entsprechenden administrativen Identität zu starten. Obwohl AIS technisch betrachtet der dem erweiterten Prozess übergeordnete Prozess ist, verwendet AIS eine neuartige Unterstützung in der CreateProcessAsUser-API, die als übergeordnete Prozess-ID dieses Prozesses die Prozess-ID des Prozesses einstellt, der ihn ursprünglich gestartet hat (siehe Abbildung 13). Dies ist der Grund, weshalb in Tools (z. B. dem Process Explorer), die Prozessstrukturen anzeigen, erweiterte Prozesse nicht als untergeordnete Prozesse des AIS-Diensthostprozesses dargestellt werden.
Abbildung 13 Erweiterungsfluss
Abbildung 13 Erweiterungsfluss
Obwohl Erweiterungsdialogfelder auf einem separaten sicheren Desktop angezeigt werden, haben die Benutzer standardmäßig keine Möglichkeit, zu überprüfen, ob sie ein legitimes Dialogfeld oder ein von einem böswilligen Programm präsentiertes Dialogfeld sehen. Dies ist bei AAM kein Problem, da böswillige Programme durch ein gefälschtes Zustimmungsdialogfeld keine Administratorrechte erhalten können. Böswillige Programme könnten jedoch auf die OTS-Erweiterung eines Standardbenutzers warten, sie abfangen und dann ein Trojanerdialogfeld verwenden, um Administratoranmeldeinformationen aufzuzeichnen. Danach könnten sie mit diesen Anmeldeinformationen Zugriff auf das Konto des Administrators erhalten und es infizieren.
Aus diesem Grund wird in Unternehmensumgebungen von OTS-Erweiterungen dringend abgeraten. Um OTS-Erweiterungen zu deaktivieren (und die Zahl der Anfragen beim Helpdesk zu reduzieren), führen Sie den lokalen Sicherheitsrichtlinieneditor (Secpol.msc) aus und stellen Sie für „User Account Control: Behavior of the elevation prompt for standard users“ (Benutzerkontensteuerung: Verhalten der Aufforderung für erweiterten Zugriff für Standardbenutzer) die Option „Automatically deny elevation requests“ (Erweiterungsanforderungen automatisch ablehnen) ein.
Private Benutzer, die sicherheitsbewusst sind, sollten die OTS-Erweiterungen dafür konfigurieren, eine SAS (Secure Attention Sequence) erforderlich zu machen, die von böswilligen Programmen weder abgefangen noch simuliert werden kann. Konfigurieren Sie SAS, indem Sie den Gruppenrichtlinieneditor (Gpedit.msc) ausführen, zu „Computer Configuration | Administrative Templates | Windows Components | Credential User Interface“ (Computerkonfiguration | Administrative Vorlagen | Windows-Komponenten | Benutzeroberfläche für Anmeldeinformationen) navigieren und die Option „Require trusted path for credential entry“ (Vertrauenswürdigen Pfad für Anmeldeinformationseingabe erforderlich machen) aktivieren. Nachdem Sie das getan haben, müssen Sie STRG+Alt+Entf drücken, um auf das Erweiterungsdialogfeld zuzugreifen.

Isolieren erweiterter Prozesse
Windows Vista errichtet um erweiterte Prozesse eine Barriere, um sie vor böswilligen Programmen zu schützen, die auf demselben Desktop mit Standardbenutzerrechten ausgeführt werden. Ohne Barriere könnten böswillige Programme eine administrative Anwendung steuern, indem sie ihr über Fenstermeldungen künstliche Maus- und Fenstereingaben senden. Obwohl das Standardsicherheitsmodell von Windows verhindert, dass böswillige Programme, die in einem Prozess mit Standardbenutzerrechten ausgeführt werden, einen erweiterten Prozess manipulieren können, der als ein anderer Benutzer ausgeführt wird, hindert es als administrative Benutzer ausgeführte böswillige Programme nicht daran, die erweiterten Prozesse des Benutzers zu öffnen, Code in diese Prozesse zu injizieren und in ihnen Threads zu starten, um den injizierten Code auszuführen.
Der Windows Vista-Schild für Fenstermeldungen wird Interface Privilege Isolation (UIPI) genannt. Er beruht auf dem neuen Windows Integrity Mechanism (WIM), den Windows Vista auch als Barriere verwendet, die die erweiterten Prozesse umgibt. In diesem neuen Sicherheitsmodell besitzen alle Prozesse und Objekte Integritätsstufen und kann die Integritätsrichtlinie eines Objekts die Zugriffe einschränken, die normalerweise gemäß dem DAC (Discretionary Access Control)-Sicherheitsmodell von Windows einem Prozess gestattet wären.
ILs (Integritätsstufen) werden durch SIDs (Sicherheits-IDs) repräsentiert, die auch Benutzer und Gruppen repräsentieren, wobei die Stufe in der RID (relative ID) der SID kodiert ist. Abbildung 14 zeigt den Anzeigenamen, die SID und die hexadezimale Version der RID der SID für die vier primären ILs. Die Hexadezimalzahlen lassen Lücken von 0x1000 zwischen jeder Stufe erkennen, die eine Verwendung dazwischen liegender Stufen durch Eingabehilfeanwendungen ermöglichen und eine zukünftige Ausweitung erlauben.
Figure 14 Primäre Integritätsstufen (Close Figure 14)

Name | SID | RID
Niedrige obligatorische Stufe | S-1-16-4096 | 0x1000
Mittlere obligatorische Stufe | S-1-16-8192 | 0x2000
Hohe obligatorische Stufe | S-1-16-12288 | 0x3000
Obligatorische Systemstufe | S-1-16-16384 | 0x4000
Abbildung 15 listet die Objekt-IL-Richtlinien und die durch sie eingeschränkten Zugriffsarten auf, die den für ein Objekt definierten generischen Zugriffen entsprechen. So verhindert beispielsweise No-Write-Up, dass ein Prozess einer niedrigeren Integritätsstufe einen der durch GENERIC_WRITE-Zugriffe repräsentierten Zugriffe erhält. Die Standardrichtlinie für die meisten Objekte einschließlich Dateien und Registrierungsschlüsseln ist No-Write-Up, die verhindert, dass ein Prozess Schreibzugriff auf ein Objekt erhält, das eine höhere Integritätsstufe als er selbst besitzt, selbst wenn die DACL (Discretionary Access Control List) des Objekts dem Benutzer einen derartigen Zugriff gewährt. Die einzigen Objekte, für die eine andere Richtlinie gilt, sind die Prozess- und Threadobjekte. Ihre Richtlinien (No-Write-Up und No-Read-Up) verhindern, dass ein Prozess einer niedrigeren Integritätsstufe Code in einen Prozess einer höheren Integritätsstufe injiziert oder Daten (z. B. Kennwörter) aus diesem Prozess liest.
Figure 15 Integritätsstufenrichtlinien (Close Figure 15)

Umgebung | Wirkung
No-Write-Up | Ein Prozess einer niedrigeren Integritätsstufe kann ein Objekt einer höheren Integritätsstufe nicht ändern.
No-Read-Up | Ein Prozess einer niedrigeren Integritätsstufe kann von einem Objekt einer höheren Integritätsstufe nicht lesen.
No-Execute-Up | Ein Prozess einer niedrigeren Integritätsstufe kann ein Objekt einer höheren Integritätsstufe nicht ausführen.
Windows weist jedem Prozess eine Integritätsstufe zu, die zusammen mit den SIDs der Gruppen, denen der Benutzer angehört, der den Prozess ausführt, im Token des Prozesses eingefügt wird. Abbildung 16 listet Beispiele von Prozessen unterschiedlicher Integritätsstufen auf. Prozesse erben ihre Integritätsstufen normalerweise von dem ihnen übergeordneten Prozess, aber ein Prozess kann auch einen Prozess einer anderen Integritätsstufe starten, wie dies beispielsweise AIS beim Starten eines erweiterten Prozesses tut. Sie können Prozessintegritätsstufen mit dem integrierten Dienstprogramm Whoami mit der Zusatzoption „/all“ oder mit Process Explorer oder AccessChk von Sysinternals anzeigen. Process Explorer kann Prozessintegritätsstufen durch Hinzufügen der Integritätsstufenspalte anzeigen.
Figure 16 Beispiel für die Zuweisung von Integritätsstufen zu Prozessen (Close Figure 16)

Integritätsstufe | Beispielprozesse
Niedrige obligatorische Stufe | Internet Explorer im geschützten Modus und von Internet Explorer im geschützten Modus gestartete Prozesse
Mittlere obligatorische Stufe | Standardbenutzer und nichterweiterte AAM-Prozesse
Hohe obligatorische Stufe | Mit Administratorrechten ausgeführte Prozesse
Obligatorische Systemstufe | „Lokales System“-, „Lokaler Dienst“- und „Netzwerkdienst“-Prozesse
Jedes sicherungsfähige Objekt besitzt eine Integritätsstufe, die entweder explizit oder implizit beschaffen ist. Prozess-, Thread- und Tokenobjekte besitzen immer eine explizit zugewiesene Integritätsstufe, die in der Regel mit der im entsprechenden Prozesstoken gespeicherten Integritätsstufe identisch ist. Die meisten Objekte besitzen keine explizite Integritätsstufe und darum wird ihnen die mittlere Integritätsstufe zugewiesen. Die einzigen Objekte, die mit einer anderen Integritätsstufe als der mittleren Integritätsstufe erstellt werden, sind die Objekte, die von einem auf der niedrigen Integritätsstufe ausgeführten Prozess erstellt werden und daher die niedrige Integritätsstufe besitzen. Sie können das integrierte Tool iCacls (%SystemRoot%\System32\iCacls.exe) verwenden, um die Integritätsstufen von Dateien anzuzeigen, und mit dem Dienstprogramm AccessChk von Sysinternals können Sie die Integritätsstufen von Dateien, Registrierungsschlüsseln, Diensten und Prozessen anzeigen. Abbildung 17 zeigt, dass ein Verzeichnis, das für Internet Explorer im geschützten Modus zugänglich sein muss, die niedrige Integritätsstufe besitzt.
Abbildung 17 AccessChk zeigt die Integritätsstufe des Favoritenverzeichnisses eines Benutzers.
Abbildung 17 AccessChk zeigt die Integritätsstufe des Favoritenverzeichnisses eines Benutzers.
Wenn ein Objekt eine explizite Integritätsstufe besitzt, ist diese in einem ACE (Access Control Entry, Zugriffssteuerungseintrag) von dem in Windows Vista neu hinzugekommenen Typ Label-ACE in der SACL (System Access Control List, Systemzugriffssteuerungsliste) des Sicherheitsdeskriptors dieses Objekts gespeichert (siehe Abbildung 18). Die SID im ACE entspricht der Integritätsstufe des Objekts und in den Kennzeichen des ACEs sind die Integritätsrichtlinien des Objekts kodiert. Vor Windows Vista wurden in SACLs nur Überwachungs-ACEs gespeichert, die die Berechtigung „Verwalten von Überwachungs- und Sicherheitsprotokollen“ (SeSecurityPrivilege) erfordern, aber das Lesen eines Label-ACEs erfordert nur Leseberechtigungszugriff (READ_CONTROL). Damit ein Prozess die Integritätsstufe eines Objekts ändern kann, muss er Änderungsbesitzerzugriff (WRITE_OWNER) auf das Objekt haben und eine Integritätsstufe besitzen, die der Integritätsstufe des Objekts entspricht oder höher ist, und der Prozess kann dann die Integritätsstufe des Objekts nur auf die Integritätsstufe des Prozesses oder eine niedrigere Integritätsstufe einstellen. Die neue Berechtigung zum Ändern eines Objektlabels (SeRelabelPrivilege) gibt einem Prozess die Möglichkeit, die Integritätsstufe jedes Objekts zu ändern, auf das der Prozess Zugriff hat, und für dieses Objekt eine Integritätsstufe einzustellen, die höher als die Integritätsstufe des Prozesses ist, aber standardmäßig wird diese Berechtigung keinem Konto zugewiesen.
Abbildung 18 Label-ACE eines Objekts
Abbildung 18 Label-ACE eines Objekts
Wenn ein Prozess versucht, ein Objekt zu öffnen, wird vor der standardmäßigen DACL-Überprüfung von Windows in der Funktion SeAccessCheck des Kernels eine Integritätsprüfung durchgeführt. Nach den standardmäßigen Integritätsrichtlinien kann ein Prozess ein Objekt nur dann für Schreibzugriff öffnen, wenn seine Integritätsstufe der Integritätsstufe des Objekts entspricht oder höher ist und die DACL dem Prozess die gewünschten Zugriffe gewährt. So kann beispielsweise ein Prozess der niedrigen Integritätsstufe keinen Prozess der mittleren Integritätsstufe für einen Schreibzugriff öffnen, selbst wenn die DACL dem Prozess Schreibzugriff gewährt.
Mit den standardmäßigen Integritätsrichtlinien können Prozesse jedes beliebige Objekt außer Prozess- und Threadobjekten öffnen, vorausgesetzt, die DACL des Objekts gewährt ihnen Lesezugriff. Dies bedeutet, dass ein Prozess, der auf der niedrigen Integritätsstufe ausgeführt wird, alle Dateien öffnen kann, die im Zugriff des Benutzerkontos stehen, in dem der Prozess ausgeführt wird. Internet Explorer verwendet im geschützten Modus Integritätsstufen, um zu verhindern, dass böswillige Programme, die IE infiziert haben, Benutzerkonteneinstellungen ändern, aber IE hindert böswillige Programme nicht daran, die Dokumente des Benutzers zu lesen.
Prozess- und Threadobjekte sind davon ausgenommen, da ihre Integritätsrichtlinien auch No-Read-Up enthalten. Dies bedeutet, dass die Integritätsstufe eines Prozesses der Integritätsstufe des Prozesses oder des Threads, den der Prozess öffnen möchte, entsprechen oder höher als dieser sein muss und die DACL diesem Prozess die von ihm gewünschten Zugriffe gewähren muss, damit der Prozess den Prozess oder den Thread öffnen kann. Abbildung 19 zeigt die Zugriffe, die die mit mittlerer und niedriger Integritätsstufe ausgeführten Prozesse auf andere Prozesse und Objekte haben, falls die DACLs den gewünschten Zugriff gestatten.
Abbildung 19 Objekt- und Prozesszugriffe
Abbildung 19 Objekt- und Prozesszugriffe
Das Windows Messaging Subsystem berücksichtigt Integritätsstufen auch beim Implementieren von UIPI, indem es verhindert, dass ein Prozess mehr als nur ein paar wenige informative Fenstermeldungen an die Fenster sendet, deren Besitzer ein Prozess einer höheren Integritätsstufe ist. Dies hindert Standardbenutzerprozesse daran, in die Fenster erweiterter Prozesse Eingabedaten zu pumpen oder einen erweiterten Prozess durch Senden fehlerhafter Meldungen zu unterbrechen, die interne Pufferüberläufe auslösen. Prozesse können durch Aufrufen der ChangeWindowMessageFilter-API wählen, zusätzliche Meldungen den Schutz passieren zu lassen. UIPI verhindert auch, dass sich Fensterhooks auf die Fenster von Prozessen einer höheren Integritätsstufe auswirken, was zur Folge hat, dass ein Standardbenutzerprozess beispielsweise nicht mehr in der Lage ist, die Tastatureingaben aufzuzeichnen, die der Benutzer in einer administrativen Anwendung vornimmt.

Erweiterungen und Sicherheitsgrenzen
Es ist wichtig, sich darüber im Klaren zu sein, dass UAC-Erweiterungen keine Sicherheitsgrenzen darstellen, sondern die Arbeit erleichtern sollen. Eine Sicherheitsgrenze erfordert, dass die Sicherheitsrichtlinien festlegen, was die Grenze passieren kann. Benutzerkonten sind ein Beispiel für eine Sicherheitsgrenze in Windows, weil ein Benutzer auf die Daten eines anderen Benutzers ohne dessen Erlaubnis nicht zugreifen kann.
Weil Erweiterungen keine Sicherheitsgrenzen sind, gibt es keine Garantie dafür, dass ein böswilliges Programm, das mit Standardbenutzerrechten im System ausgeführt wird, nicht in der Lage ist, einen erweiterten Prozess zu stören, um Administratorrechte zu erlangen. So identifizieren beispielsweise Erweiterungsdialogfelder nur die ausführbare Datei, die erweitert wird, sagen aber nichts darüber aus, was diese Datei tun wird, wenn sie ausgeführt wird. Die ausführbare Datei wird Befehlszeilenargumente verarbeiten, DLL-Dateien laden, Dateien öffnen und mit anderen Prozessen kommunizieren. Jede dieser Operationen könnte unter Umständen böswilligen Programmen ermöglichen, den erweiterten Prozess zu stören und dadurch Administratorrechte zu erlangen.
Sandkastenspiele in einer Sandbox mit niedriger Integritätsstufe
Internet Explorer wird im geschützten Modus mit niedriger Integritätsstufe ausgeführt, um böswillige Programme, die den Prozess von IE infizieren könnten, mit einem Zaun zu umgeben. Dies verhindert, dass böswillige Programme die Konteneinstellungen des Benutzers ändern und sich in einem Autostart-Speicherort installieren. Sie können das Dienstprogramm PsExec von Sysinternals mit dem Schalter „-l“ verwenden, um zur Untersuchung der Sandbox beliebige Prozesse in der niedrigen Integritätsstufe zu starten. Abbildung B zeigt, dass eine mit niedriger Integritätsstufe ausgeführte Befehlszeile keine Datei im temporären Verzeichnis des Benutzers erstellen kann, das die mittlere Integritätsstufe besitzt, dies aber im temporären Verzeichnis von Internet Explorer tun kann, das die niedrige Integritätsstufe besitzt.
Abbildung BDie Befehlszeile kann nur in ähnlichen Integritätsstufen Dateien erstellen.

Erweiterte AAM-Prozesse sind besonders anfällig, weil sie im gleichen Benutzerkonto wie die mit Standardrechten ausgestatteten Prozesse des AAM-Benutzers ausgeführt werden und dasselbe Benutzerprofil benutzen. Viele Anwendungen lesen Einstellungen und laden Erweiterungen, die im Profil eines Benutzers registriert sind, was böswilligen Programmen eine Gelegenheit zur Erweiterung bietet. So laden beispielsweise die allgemeinen Steuerungsdialogfelder Shellerweiterungen, die im Registrierungsschlüssel eines Benutzers (unter HKEY_CURRENT_USER) konfiguriert sind, und daher können böswillige Programme sich selbst als Erweiterung hinzufügen, um in jeden erweiterten Prozess geladen zu werden, der diese Dialogfelder verwendet.
Sogar Prozesse, die von Standardbenutzerkonten erweitert werden, können angegriffen werden, da sie mit gemeinsamer Nutzung arbeiten. Alle Prozesse, die in einer Anmeldungssitzung ausgeführt werden, nutzen gemeinsam den internen Namespace, in dem Windows Objekte wie z. B. Ereignisse, Mutexe, Semaphoren und gemeinsam genutzten Speicher ablegt. Wenn ein böswilliges Programm weiß, dass ein erweiterter Prozess beim Prozessstart versuchen wird, ein bestimmtes freigegebenes Speicherobjekt zu öffnen und zu lesen, könnte es dieses Objekt mit einem Inhalt erstellen, der einen Pufferüberlauf auslöst, um Code in den erweiterten Prozess zu injizieren. Diese Art von Angriff ist recht kompliziert, aber schon allein die Tatsache, dass dies möglich ist, hat zur Folge, dass OTS-Erweiterungen als Sicherheitsgrenze untauglich sind.
Erweiterungen wurden ja auch lediglich zur Vereinfachung des Umgangs mit Rechten eingeführt, um diejenigen Benutzer, die Zugriff auf Administratorrechte haben möchten, dazu zu ermutigen, standardmäßig mit Standardbenutzerrechten zu arbeiten. Benutzer, die die Garantien einer Sicherheitsgrenze haben möchten, können zugunsten einer Sicherheitsgrenze auf die Bequemlichkeit der Erweiterungen verzichten, indem sie für Routineaufgaben ein Standardbenutzerkonto verwenden und zum Durchführen administrativer Operationen mit der Funktion „Schnelle Benutzerumschaltung“ (Fast User Switching, FUS) zu einem dedizierten Administratorkonto wechseln. Auf der anderen Seite können Benutzer, denen Bequemlichkeit wichtiger als Sicherheit ist, in einem System über das Dialogfeld „Benutzerkonten“ der Systemsteuerung UAC deaktivieren, sollten sich dabei aber dessen bewusst sein, dass dadurch auch der geschützte Modus für Internet Explorer deaktiviert wird.

Schlussbemerkung
Die Ausführung als Standardbenutzer bietet zahlreiche Vorteile und hilft unter anderem auch dabei, Systeme vor versehentlicher oder absichtlicher Beschädigung zu bewahren und die Daten und die Integrität von Benutzern, die ein System gemeinsam nutzen, vor Zugriffen durch Unbefugte zu schützen. Die verschiedenen Änderungen und Technologien von UAC werden zu einer beträchtlichen Änderung des Windows-Nutzungsmodells führen. Mit Windows Vista können Windows-Benutzer zum ersten Mal mit Standardbenutzerrechten die meisten Routineaufgaben durchführen und die meisten Anwendungen ausführen und viele Unternehmen können jetzt Standardbenutzerkonten verwenden.

Mark Russinovich ist Technical Fellow in der Platform and Services Division von Microsoft. Er ist Mitautor von Microsoft Windows Internals (Microsoft Press, 2004) und hält häufig Vorträge bei IT- und Entwicklerkonferenzen. Er wechselte bei der kürzlichen Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er die Dienstprogramme „Process Explorer“, „Filemon“ und „Regmon“ veröffentlichte.
© 2007 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


 Sicherheit: Schl&#252;ssel zum Sch&#252;tzen von Daten durch BitLocker-Laufwerkverschl&#252;sselung
Sicherheit Byron Hynes

Schlüssel zum Schützen von Daten durch BitLocker-Laufwerkverschlüsselung
Kurz zusammengefasst:
  • Verschlüsselung ganzer Volumes
  • BitLocker-Schlüssel
  • Einrichten von BitLocker

Windows BitLocker-Laufwerkverschlüsselung ist mit Sicherheit eine der am meisten diskutierten Windows Vista-Features. Leider hatten die meisten Leute noch keine Gelegenheit zum Testen von BitLocker, um aus erster Hand herauszufinden,
was es kann und wie es funktioniert – vor allem nicht auf einem Computer mit einem TPM (Trusted Platform Module). In diesem Artikel stelle ich die Grundlagen von BitLocker™ vor, damit Sie das Potenzial dieses Features beurteilen und es in Ihre Aktualisierungsplanung einbeziehen können. Zunächst erhalten Sie einige Hintergrund- und Konzeptinformationen, und anschließend wird erörtert, wie BitLocker aktiviert wird, wie Datenwiederherstellungen durchgeführt werden, wie die Verwaltung funktioniert und wie BitLocker am Ende der Lebensdauer eines Computers eingesetzt werden kann. Sehen Sie sich die Randleiste „Datenträger und Volumes“ an, damit Sie die Fachbegriffe besser verstehen können.
Datenträger und Volumes
Die im Zusammenhang mit Datenträgern und Volumes verwendete Terminologie kann oft verwirrend sein. Zu Ihrer Information folgt hier ein kurzes Glossar.
Partition: Eine Partition ist ein Abschnitt einer physischen Festplatte. Sie ist eine logische Struktur, die in einer auf dem Datenträger gespeicherten Partitionstabelle definiert ist.
Volume: Ein Volume ist eine logische Struktur in Windows, die aus einer oder mehreren Partitionen besteht und durch eine Windows-Komponente namens „Volume-Manager“ definiert wird. Abgesehen vom Volume-Manager und den Systemstartkomponenten arbeiten die übrigen Betriebssystemkomponenten und Anwendungen nicht mit Partitionen, sondern mit Volumes. Im Fall von Windows-Clientbetriebssystemen einschließlich Windows Vista besteht zwischen Partitionen und Volumes normalerweise eine 1:1-Beziehung. Bei Servern besteht ein Volume oft aus mehreren Partitionen, z. B. in einer typischen RAID-Konfiguration.
Aktive Partition: Es kann immer nur eine einzige Partition als aktive Partition gekennzeichnet sein. Dies ist die Partition, die den Bootsektor enthält, der zum Starten des Betriebssystems verwendet wird. Die aktive Partition wird manchmal auch als Systempartition oder Systemvolume bezeichnet, aber diese Begriffe dürfen nicht mit dem Windows-BS-Volume verwechselt werden.
Windows-BS-Volume: Dieses Volume enthält die Windows-Installation einschließlich der Ordner „System“ und „System32“. Vor der Veröffentlichung von Windows Vista (und auch heute noch) wurde die Bezeichnung „Startpartition“ verwendet. Der Begriff „Windows-BS-Volume“ ist klarer und führt zu keiner Verwechslung zwischen Startpartition und Systempartition. Früher haben Schulungsleiter ihren Kursteilnehmern oft eingeprägt, dass sie „von der Systempartition starten und sich die Systemdateien auf der Startpartition befinden“.
Vor Windows Vista waren das Windows-BS-Volume (auch Startpartition genannt) und die aktive Partition (auch Systempartition genannt) identisch, weil bei den meisten Clientcomputern die Festplatten als eine einzige große Partition konfiguriert wurden. In Abbildung A sind die Funktionen zu sehen, die jeder Partition oder jedem Volume in der Datenträgerverwaltungskonsole in Windows Vista zugewiesen sind.
Abbildung A Partitionsfunktionen
Abbildung A Partitionsfunktionen

BitLocker führt zwei Aufgaben aus, die sich zwar ergänzen, aber trotzdem getrennt sind. Erstens stellt BitLocker eine vollständige Laufwerkverschlüsselung für das Windows®-BS-Laufwerk bereit. Zweitens bietet BitLocker auf Computern mit einem kompatiblen TPM eine Möglichkeit, die Integrität der frühen Systemstartkomponenten zu prüfen, bevor ein Start von Windows Vista™ erlaubt wird.
Um die gesamte BitLocker-Funktionalität nutzen zu können, muss Ihr Computer einen kompatiblen TPM-Mikrochip und ein kompatibles BIOS besitzen. Unter kompatibel ist dabei ein TMP und ein BIOS der Version 1.2 zu verstehen, die das TPM und die SRTM (Static Root of Trust Measurement) gemäß der von der Trusted Computing Group (TCG) vorgegebenen Definition unterstützen. Trotzdem können auch Computer ohne kompatibles TPM und BIOS die BitLocker-Verschlüsselung verwenden.

Verschlüsselung ganzer Volumes
BitLocker stellt eine vollständige Laufwerkverschlüsselung bereit, um sicherzustellen, dass alle Daten, die auf das Windows-BS-Laufwerk geschrieben werden, verschlüsselt werden. Dies ist der entscheidende Faktor zum Schutz vertraulicher Informationen auf den Computern Ihrer Organisation, insbesondere auf Laptops und anderen tragbaren Computern.
Täglich werden tragbare Computer gestohlen oder kommen abhanden. Da immer mehr tragbare Computer zum Einsatz kommen und die Arbeitskräfte immer mobiler werden, kann ein einziger Mitarbeiter Hunderte von Gigabyte an Geschäftsgeheimnissen, vertraulichen Dokumenten oder personenbezogenen Informationen (personally identifiable information, PII) von Kunden Ihrer Organisation bei sich tragen. Bei einer Suche in den Nachrichtenmedien wird sofort deutlich, dass viel zu viele dieser Daten verloren gehen. (Dem Privacy Rights Clearinghouse zufolge sind seit 2005 über 104 Millionen Datensätze, die persönliche Informationen enthalten, verloren gegangen oder veröffentlicht worden.)
Die meisten Organisationen sind bereits gesetzlich und firmenintern dazu verpflichtet, viele Arten privater Informationen zu schützen. Doch selbst dann, wenn Sie nicht bereits per Gesetz dazu verpflichtet sind, liegt es wahrscheinlich in Ihrem besten Geschäftsinteresse, dies zu tun.

Wozu das ganze Volume verschlüsseln?
Wenn Sie ein erfahrener Windows-Administrator sind, sind Sie wahrscheinlich bereits mit Windows-basierten Verschlüsselungsoptionen wie dem verschlüsselnden Dateisystem (Encrypting File System, EFS) und vielleicht auch der Verschlüsselung und dem Schutz, den Rechteverwaltungsdienste (Rights Management Services, RMS) bieten, vertraut. Der große Unterschied zwischen diesen Verschlüsselungsoptionen und BitLocker besteht darin, dass BitLocker nach der Aktivierung automatisch erfolgt, transparent arbeitet und das gesamte Volume erfasst.
Bei EFS müssen Sie beispielsweise genau angeben, welche Dateien und Ordner geschützt werden sollen. In Windows Vista gibt es einige neue Optionen, die EFS flexibler machen, und sowohl EFS als auch RMS eignen sich für manche Szenarios, für die BitLocker nicht geeignet ist. Doch EFS und RMS erfordern eine aufwändige Administratorkonfiguration und wurden nicht dafür entwickelt, alle auf dem Volume gespeicherten Informationen zu schützen.
Umgekehrt verschlüsselt BitLocker alles, was von Anwendungen auf ein von BitLocker geschütztes Volume geschrieben wird, einschließlich des Betriebssystems selbst, der Registrierung, der Ruhezustands- und Auslagerungsdateien, der Anwendungen und der von Anwendungen verwendeten Daten.
Drei Dinge werden nicht verschlüsselt: Der Bootsektor, alle bereits als unlesbar gekennzeichneten schlechten Sektoren und die Volumemetadaten. Die Volumemetadaten bestehen aus drei redundanten Kopien von Daten, die zur Verwaltung von BitLocker verwendet werden, einschließlich statistischer Informationen zum Volume, sowie Kopien einiger Entschlüsselungsschlüssel. Diese Elemente erfordern keine Verschlüsselung, da sie nicht einmalig, wertvoll oder personenbezogen sind.
Vollständige Laufwerkverschlüsselung schützt gegen Offlineangriffe, d. h. gegen die Art von Angriffen, bei denen versucht wird, das Betriebssystem zu umgehen. So besteht beispielsweise eine häufige Form der Offlineangriffe darin, einen Computer zu stehlen, die Festplatte zu entfernen und sie als zweites Laufwerk in einen anderen Computer einzubauen, auf dem eine andere Kopie von Windows oder ein anderes Betriebssystem ausgeführt wird, um NTFS-Berechtigungen und Benutzerkennwörter zu umgehen. Es ist unmöglich, durch diese Art von Angriff ein von BitLocker geschütztes Volume zu lesen.

So werden Daten in BitLocker verschlüsselt
BitLocker verwendet den AES-Algorithmus (Advanced Encryption Standard, erweiterter Verschlüsselungsstandard) mit 128-Bit-Schlüsseln. Um einen noch besseren Schutz zu bieten, können die Schlüssel mithilfe von Gruppenrichtlinien oder mit dem Windows-Verwaltungsinstrumentations-Anbieter (Windows Management Instrumentation, WMI) von BitLocker auf 256-Bit-Schlüssel erhöht werden.
Jeder Sektor auf dem Volume wird separat verschlüsselt, wobei ein Teil des Verschlüsselungsschlüssels aus der Sektorennummer selbst abgeleitet wird. Dies bedeutet, dass zwei Sektoren, die identische unverschlüsselte Daten enthalten, in Form unterschiedlich verschlüsselter Bytes auf den Datenträger geschrieben werden, wodurch es beträchtlich schwieriger wird, Schlüssel durch Erstellen und Verschlüsseln bekannter Daten zu knacken.
Bevor Daten mithilfe von AES verschlüsselt werden, verwendet BitLocker außerdem einen Algorithmus, der als Diffusor bezeichnet wird. Ohne auf das Spezialgebiet der Kryptografie einzugehen, kann über die Arbeitsweise des Diffusors vereinfachend gesagt werden, dass selbst geringfügige Änderungen am Nur-Text die Änderung des gesamten Sektors im verschlüsselten Text zur Folge hat. Dies erschwert es für einen Angreifer ebenfalls beträchtlich, Schlüssel oder Daten zu entdecken.
Wenn Sie sich für die Details des BitLocker-Verschlüsselungsalgorithmus interessieren, können Sie folgenden Artikel von Neil Ferguson zu diesem Thema lesen: „AES-CBC + Elephant Diffuser: Ein Datenträgerverschlüsselungsalgorithmus für Windows Vista“.

BitLocker-Schlüssel
Wenn Sie mit Verschlüsselung zu tun haben, müssen Sie über Schlüssel Bescheid wissen. Auch BitLocker bildet hier keine Ausnahme. BitLocker verwendet eine elegante, aber recht komplizierte Architektur von Schlüsseln.
Die Sektoren selbst werden mit einem Schlüssel verschlüsselt, der als Schlüssel zur vollständigen Volumeverschlüsselung (Full-Volume Encryption Key, FVEK) bezeichnet wird. Dieser FVEK wird jedoch nicht von Benutzern verwendet, und Benutzer können nicht auf ihn zugreifen. Der FVEK wiederum wird mit einem Schlüssel verschlüsselt, der als Volumehauptschlüssel (Volume Master Key, VMK) bezeichnet wird. Dieses Niveau der Abstraktion bietet entscheidende Vorteile, kann jedoch zur Folge haben, dass der Prozess nur schwer zu verstehen ist. Der FVEK ist streng geheim, denn wenn er bekannt würde, müssten alle Sektoren neu verschlüsselt werden. Da dies ein zeitaufwändiger Vorgang wäre, sollte dies möglichst vermieden werden. Stattdessen arbeitet das System mit dem VMK.
Der mit dem VMK verschlüsselte FVEK wird als Bestandteil der Volumemetadaten auf dem Datenträger selbst gespeichert. Obwohl der FVEK lokal gespeichert wird, wird er niemals unverschlüsselt auf einen Datenträger geschrieben.
Der VMK wird ebenfalls verschlüsselt oder „geschützt“, aber dazu werden ein oder mehrere mögliche Schlüsselprotektoren verwendet. Der Standardschlüsselprotektor ist das TPM. Die Verwendung eines TPM wird im folgenden Abschnitt über Integritätsprüfung behandelt. Für Notfälle wird auch ein Wiederherstellungskennwort als Schlüsselprotektor erstellt. Auf die Wiederherstellung wird ebenfalls später eingegangen.
Sie können das TPM mit einer numerischen PIN oder mit einem partiellen Schlüssel kombinieren, der auf einem USB-Laufwerk gespeichert wird, um die Sicherheit noch zu erhöhen. Jedes dieser Elemente stellt eine zweiteilige Authentifizierung dar. Wenn Ihr Computer keinen kompatiblen TPM-Chip und kein kompatibles BIOS besitzt, kann BitLocker dafür konfiguriert werden, einen Schlüsselprotektor vollständig auf einem USB-Laufwerk zu speichern. Dies wird als Systemstartschlüssel bezeichnet.
BitLocker kann deaktiviert werden, ohne die Daten zu entschlüsseln. In diesem Fall wird der VMK nur durch einen neuen Schlüsselprotektor geschützt, der unverschlüsselt gespeichert wird. Beachten Sie, dass dieser unverschlüsselte Schlüssel dem System ermöglicht, auf das Laufwerk zuzugreifen, als wäre es ungeschützt.
Beim Systemstart sucht das System nach einem geeigneten Schlüsselprotektor, indem es das TPM abfragt, die USB-Anschlüsse überprüft oder, falls erforderlich, eine Eingabeaufforderung an den Benutzer ausgibt (dies wird als Wiederherstellung bezeichnet). Wenn ein Schlüsselprotektor gefunden wird, entschlüsselt Windows den VMK, der den FVEK entschlüsselt, und der FVEK wiederum entschlüsselt die auf dem Datenträger gespeicherten Daten. Dieser Prozess wird in Abbildung 1 gezeigt.
Abbildung 1 Standardmäßiger BitLocker-Systemstartprozess
Abbildung 1 Standardmäßiger BitLocker-Systemstartprozess

Integritätsprüfung
Da die Komponenten im frühesten Teil des Systemstartprozesses unverschlüsselt verfügbar sein müssen, damit der Computer starten kann, könnte ein Angreifer den Code in diesen frühen Startkomponenten ändern (denken Sie etwa an ein Rootkit) und danach Zugriff auf den Computer erhalten, obwohl die Daten auf dem Datenträger verschlüsselt wurden.
Durch diese Art von Angriff könnte sich ein Angreifer möglicherweise Zugriff auf vertrauliche Informationen verschaffen, z. B. auf BitLocker-Schlüssel oder Benutzerkennwörter, und diese Informationen dazu einsetzen, andere Sicherheitsmaßnahmen zu umgehen.
Diese Art von Angriff zu verhindern, war eines der ursprünglichen Ziele des Programms und des Teams, das BitLocker entwickelt hat. In mancher Hinsicht war die Verschlüsselung eigentlich nur Mittel zum Zweck. Die vollständige Laufwerkverschlüsselung ermöglicht BitLocker, die Integrität des Systems zu schützen und den Start von Windows zu verhindern, falls die ersten Systemstartkomponenten geändert wurden.
Auf Computern, die mit einem kompatiblen TPM ausgestattet sind, untersucht bei jedem Start des Computers jede der frühen Systemstartkomponenten – z. B. das BIOS, der MBR (Master Boot Record), der Bootsektor und der Startmanagercode – den auszuführenden Code, errechnet einen Hashwert und speichert diesen Wert in bestimmten Registern des TPMs, den so genannten Plattformkonfigurationsregistern (Platform Configuration Registers, PCRs). Sobald ein Wert in einem PCR gespeichert wurde, kann dieser Wert weder ersetzt noch gelöscht werden, es sei denn, das System wird neu gestartet. BitLocker verwendet das TPM und die in PCRs gespeicherten Werte, um den VMK zu schützen.
Ein TPM kann einen Schlüssel erstellen, der an bestimmte PCR-Werte gebunden ist. Wenn diese Art von Schlüssel erstellt wird, verschlüsselt das TPM den Schlüssel so, dass nur dieses spezielle TPM ihn wieder entschlüsseln kann. Danach entschlüsselt das TPM den Schlüssel nur dann, wenn die aktuellen PCR-Werte den Werten entsprechen, die beim Erstellen des Schlüssels angegeben wurden. Dies wird als Versiegeln des Schlüssels an das TPM bezeichnet.
Standardmäßig werden Schlüssel von BitLocker mithilfe von CRTM (Core Root of Trust Measurement)-Werten, BIOS und Plattformerweiterungen, Options-ROM-Code, MBR-Code, NTFS-Bootsektor und Startmanager versiegelt. Wenn eines dieser Elemente unerwartet geändert wurde, sperrt BitLocker das Laufwerk und verhindert, dass darauf zugegriffen oder es entschlüsselt wird.
Standardmäßig wird BitLocker dafür konfiguriert, ein TPM zu suchen und zu verwenden. Sie können eine Gruppenrichtlinieneinstellung oder eine lokale Richtlinieneinstellung verwenden, um BitLocker zu ermöglichen, ohne ein TPM zu arbeiten und Speicherschlüssel auf einem externen USB-Flashlaufwerk zu speichern, aber ohne TPM kann BitLocker die Systemintegrität nicht überprüfen.

Erstmaliges Aktivieren von BitLocker
BitLocker ist in Windows Vista Enterprise und Windows Vista Ultima verfügbar. (BitLocker wird auch als optionale Komponente in der nächsten Version von Windows Server® (Codename „Longhorn“) enthalten sein.
Im folgenden Text wird davon ausgegangen, dass Ihnen ein Computer mit einem kompatiblen TPM zum Testen zur Verfügung steht. Wenn Sie BitLocker auf einem Computer ohne TPM aktivieren möchten, befolgen Sie die Schritte in der Randleiste „Verwenden von BitLocker ohne TPM“.
Verwenden von BitLocker ohne TPM
BitLocker ist standardmäßig dafür konfiguriert, ein TPM zu verwenden. Wenn Sie kein TPM besitzen, können Sie BitLocker mit einer gebrauchsfertigen Windows-Version nicht aktivieren. Das folgende Verfahren, das der Schritt-für-Schritt-Anleitung zur BitLocker-Laufwerkverschlüsselung entnommen wurde, ermöglicht Ihnen allerdings, BitLocker auch ohne ein TPM zu verwenden.
Um diese Schritte durchführen zu können, müssen Sie als Administrator angemeldet sein. Auch ohne ein TPM muss Ihr Computer das Lesen von einem USB-Flashlaufwerk während des Systemstartprozesses unterstützen. Darüber hinaus muss bei jeder Aktivierung von BitLocker und bei jedem Neustart des Computers ein USB-Flashlaufwerk verfügbar sein.
Gehen Sie folgendermaßen vor, um BitLocker-Laufwerkverschlüsselung auf einem Computer ohne kompatibles TPM zu aktivieren:
  1. Klicken Sie auf „Start“, geben Sie im Startsuchfeld „gpedit.msc“ ein, und drücken Sie danach die Eingabetaste.
  2. Wenn das Dialogfeld „Benutzerkontensteuerung“ angezeigt wird, überprüfen Sie, ob die gewünschte Aktion eingestellt ist, und klicken Sie anschließend auf „Weiter“.
  3. Klicken Sie in der Struktur des Gruppenrichtlinienobjekt-Editors auf „Richtlinie für "Lokaler Computer"“, „Administrative Vorlagen“, „Windows-Komponenten“, und doppelklicken Sie danach auf „BitLocker-Laufwerkverschlüsselung“.
  4. Doppelklicken Sie auf die Einstellung „Systemsteuerungssetup: Erweiterte Startoptionen aktivieren“. Das Dialogfeld „Systemsteuerungssetup: Erweiterte Startoptionen aktivieren“ wird angezeigt.
  5. Wählen Sie die Option „Aktiviert“ aus, wählen Sie das Kontrollkästchen „BitLocker ohne kompatibles TPM zulassen“ aus und klicken Sie anschließend auf „OK“. Sie haben die Richtlinieneinstellung so geändert, dass Sie statt eines TPMs einen Systemstartschlüssel verwenden können.
  6. Schließen Sie den Gruppenrichtlinienobjekt-Editor.
  7. Damit die Gruppenrichtlinie sofort angewendet wird, können Sie auf „Start“ klicken, im Startsuchfeld „gpupdate.exe /force“ eingeben und danach die Eingabetaste drücken. Warten Sie, bis der Prozess abgeschlossen ist.

Ein wichtiger Teil der Aktivierung von BitLocker besteht darin, sicherzustellen, dass Ihre Volumes richtig konfiguriert sind. BitLocker erfordert, dass die aktive Partition unverschlüsselt ist, damit der Bootsektor, der Startmanager und das Windows-Ladeprogramm gelesen werden können (diese Komponenten werden durch die zuvor beschriebenen Systemintegritätsschritte geschützt). Da andere Windows-Komponenten möglicherweise eine temporäre Verwendung der aktiven Partition erfordern, wird von Microsoft empfohlen, dass die aktive Partition mindestens 1,5 GB groß sein sollte. Es wäre auch eine gute Idee, entsprechende NTFS-Berechtigungen zu konfigurieren, damit Benutzer nicht versehentlich Daten auf dieses Volume schreiben können.
Windows selbst wird auf einem zweiten Volume installiert, das größer ist und verschlüsselt werden kann. Wenn Sie Windows auf einem neuen System installieren, können Sie die Volumes manuell konfigurieren, indem Sie die in der Schritt-für-Schritt-Anleitung zu Windows BitLocker-Laufwerkverschlüsselung verfügbaren Anweisungen befolgen.
Sie können das BitLocker-Laufwerkvorbereitungsprogramm verwenden, um Ihr System für BitLocker zu konfigurieren. Dieses Tool nimmt Ihnen die mühselige Laufwerkskonfiguration ab und ist als Zusatzkomponente von Windows Vista Ultima oder für Kunden verfügbar, die Windows Vista Enterprise einsetzen. Eine ausführliche Anleitung für das BitLocker-Laufwerkvorbereitungsprogramm finden Sie unter support.microsoft.com/kb/930063.
Das BitLocker-Laufwerkvorbereitungsprogramm verkleinert automatisch das Volume (falls Sie nur ein einziges Volume besitzen), erstellt die zweite Partition, macht sie aktiv, nimmt alle notwendigen Konfigurationsänderungen vor und verschiebt die Systemstartdateien an den richtigen Ort.
Wenn die Volumes erst einmal konfiguriert sind, lässt sich BitLocker ganz einfach aktivieren. Klicken Sie im Abschnitt „Sicherheit“ der Systemsteuerung auf das BitLocker-Laufwerkverschlüsselungssymbol. Wenn Sie die UAC-Zustimmungsaufforderung bestätigt haben, wird ein Fenster angezeigt, das dem in Abbildung 2 dargestellten Fenster ähnelt.
Abbildung 2 Aktivieren von BitLocker
Abbildung 2 Aktivieren von BitLocker
Die genaue Abfolge der nachfolgenden Schritte variiert je nach Zustand des TPM-Chips in Ihrem Computer. Wenn der TPM-Chip nicht initialisiert ist, wird der TPM-Initialisierungsassistent ausgeführt. Folgen Sie den Eingabeaufforderungen, um das TPM zu initialisieren, was auch einen Neustart des Computers erfordert.
Wenn das TPM initialisiert wurde, wird, wie in Abbildung 3 gezeigt, die Seite „Wiederherstellungskennwort speichern“ angezeigt. Um im Falle eines TPM-Fehlers oder eines anderen Problems die Daten wiederherstellen zu können, benötigen Sie ein Wiederherstellungskennwort. Diese Seite ermöglicht Ihnen, ein Wiederherstellungskennwort auf einem USB-Flashlaufwerk, einem lokalen Datenträger oder einem Netzwerkdatenträger zu speichern oder es zur sicheren Verwahrung auszudrucken. Sie müssen mindestens eine dieser Optionen auswählen und können bei Bedarf mehrere Kopien speichern. Sobald das Wiederherstellungskennwort gespeichert wurde, wird die Schaltfläche „Weiter“ aktiviert. Klicken Sie darauf.
Abbildung 3 Speichern des Wiederherstellungskennworts
Abbildung 3 Speichern des Wiederherstellungskennworts
Die Seite „Encrypt the selected disk volume“ (Ausgewähltes Datenträgervolume verschlüsseln) wird angezeigt, und Sie können auswählen, ob eine Systemüberprüfung ausgeführt werden soll, bevor die Verschlüsselung eingeleitet wird. Die Systemüberprüfung erfordert zwar einen Neustart, aber sie ist das beste Verfahren, um sicherzustellen, dass das TPM, BIOS und die USB-Anschlüsse wie vorgesehen mit BitLocker funktionieren. Falls dabei Probleme erkannt werden, wird nach dem Neustart eine Fehlermeldung angezeigt. Werden keine Probleme erkannt, wird die Statusleiste „Verschlüsselung wird durchgeführt“ angezeigt.
Das ist alles. Die Verschlüsselung wird im Hintergrund abgeschlossen, und Sie können mit der Verwendung des Computers fortfahren. Nach Abschluss der anfänglichen Verschlüsselung wird eine Meldung angezeigt, die Sie darüber informiert. Sie können den Fortschritt der Verschlüsselung des Datenträgervolumes auch überwachen, indem Sie mit dem Mauszeiger auf das BitLocker-Laufwerkverschlüsselungssymbol auf der Symbolleiste am unteren Bildschirmrand zeigen. Weitere Details finden Sie in der bereits erwähnten Schritt-für-Schritt-Anleitung.
Manche Benutzer hat es überrascht, dass BitLocker den Benutzer weder zu Benutzereingaben auffordert noch sonstige Unterbrechungen hervorruft, wenn der Computer gestartet wird. Dies liegt daran, dass sich BitLocker in der Standardkonfiguration darauf verlässt, dass das TPM die Systemintegrität bestätigt, bevor das Volume entsperrt wird. Dies erfolgt automatisch und in einer für den Benutzer transparenten Weise.
Sie können BitLocker so konfigurieren, dass beim Systemstart eine PIN eingegeben werden oder auf einem USB-Flashlaufwerk ein Schlüssel gespeichert sein muss. Dies erhöht die Sicherheit noch mehr und wird für Situationen empfohlen, in denen die Vorteile durch erhöhte Sicherheit den Nachteil der Unannehmlichkeit, eine PIN eingeben zu müssen, aufwiegt. Meiner Meinung nach ist das immer der Fall. (Daher verlangt mein Desktop die Eingabe einer PIN, und mein Laptop erfordert einen USB-Schlüssel.)

BitLocker-Wiederherstellung
Im Umgang mit Verschlüsselung, insbesondere in einer Betriebs- oder Unternehmensumgebung, ist es wichtig, dass Sie für einen autorisierten Benutzer eine Möglichkeit einrichten, Zugriff auf seine Daten zu erhalten, auch wenn die normalen Zugriffsmethoden oder die Schlüssel nicht verfügbar sind. BitLocker bezeichnet dies als Wiederherstellung.
Wenn sich in den frühen Systemstartkomponenten unerwartet etwas ändert, wenn Sie einen USB-Systemstartschlüssel verlieren oder wenn ein Benutzer seine PIN vergisst, kann BitLocker den normalen Systemstartprozess nicht abschließen. In diesem Fall lässt BitLocker das Volume gesperrt, und Windows kann nicht gestartet werden. Stattdessen zeigt der BitLocker-Code im Startmanager ein Textfenster an. Wenn ein Wiederherstellungskennwort auf einem USB-Flashlaufwerk gespeichert wurde (dies wird manchmal als Wiederherstellungsschlüssel bezeichnet), wird ein Fenster aufgerufen, das dem in Abbildung 4 gezeigten Fenster ähnelt.
Abbildung 4 Suche nach einem Wiederherstellungsschlüssel
Abbildung 4 Suche nach einem Wiederherstellungsschlüssel
BitLocker muss beim Systemstart angeschlossen sein, um ein USB-Flashlaufwerk lesen zu können. Wenn Sie also ein USB-Flashlaufwerk mit einem Wiederherstellungskennwort besitzen, legen Sie es ein und drücken die ESC-Taste. Wenn Sie kein derartiges USB-Flashlaufwerk besitzen, drücken Sie die Eingabetaste, worauf das in Abbildung 5 dargestellte Fenster angezeigt wird. Dieses Fenster wird auch dann angezeigt, wenn nie ein Wiederherstellungsschlüssel auf ein USB-Laufwerk gespeichert wurde.
Abbildung 5 Eingabe eines BitLocker-Kennworts
Abbildung 5 Eingabe eines BitLocker-Kennworts
BitLocker sucht jetzt nach einem aus 48 Ziffern bestehenden numerischen Kennwort, das das Laufwerk entsperren kann. Diese Zahl wird auf der Seite ausgegeben, wenn Sie auswählen, das Wiederherstellungskennwort drucken zu lassen, und auch in einer Datei gespeichert, wenn Sie das Wiederherstellungskennwort in einem Ordner gespeichert haben.
Die leichteste Methode, in einem Betrieb mit Wiederherstellungskennwörtern umzugehen, besteht in einer automatischen Speicherung in Active Directory®. Wie Sie dazu vorgehen müssen, erfahren Sie unter go.microsoft.com/fwlink/?LinkId=87067.
In einem späteren Artikel werde ich auf die Verwaltungsmöglichkeiten von BitLocker ausführlich eingehen, aber im Rahmen dieser Übersicht möchte ich anmerken, dass im Lieferumfang von BitLocker ein vollständiger WMI-Anbieter enthalten ist, der es erlaubt, BitLocker (und das TPM) in jedem mit WMI kompatiblen WBEM (Web-Based Enterprise Management)-System zu verwalten. Dies bedeutet auch, dass für BitLocker mit jeder Skriptsprache, die auf WMI-Objekte zugreifen kann (z. B. VBScript oder Windows PowerShell™), Skripts geschrieben werden können.
Im Lieferumfang von BitLocker ist auch ein Befehlszeilenprogramm namens „manage-bde.wsf“ enthalten, das den WMI-Anbieter verwendet, um ein Verwalten von BitLocker auf lokalen oder entfernten Computern zu ermöglichen. Weitere Informationen erhalten Sie, indem Sie ein erweitertes Eingabeaufforderungsfenster öffnen und „manage-bde.wsf /?“ eingeben.

Sichere Stilllegung
Für jeden Computer kommt ein Zeitpunkt, an dem er außer Betrieb genommen werden muss. Unternehmen geben in der Regel beträchtliche Gelder aus und betreiben einen großen Arbeitsaufwand, um sicherstellen, dass Festplattenlaufwerke vor der Entsorgung vollständig bereinigt sind. Die meisten Prozesse zum Entfernen vertraulicher Daten von Festplattenlaufwerken sind zeitaufwändig oder teuer bzw. führen zur permanenten Zerstörung der Hardware. BitLocker bietet andere kostengünstigere Möglichkeiten.
Statt Daten entfernen zu müssen, ermöglicht BitLocker, dass vertrauliche Daten erst gar nicht in einer riskanten Weise auf einer Festplatte gespeichert werden. Da alles, was auf die Festplatte geschrieben wird, verschlüsselt wird, kann jede Möglichkeit eines Zugriffs auf die Daten unwiderruflich zunichte gemacht werden, indem alle Kopien der Verschlüsselungsschlüssel vernichtet werden. Die Festplatte selbst bleibt völlig unversehrt und kann wiederverwendet werden.
Sie können unter einer Reihe von Methoden auswählen, um Volumes stillzulegen, die durch BitLocker geschützt wurden. So können Sie beispielsweise alle Kopien von Schlüsseln aus den Volumemetadaten löschen, sie aber weiterhin an einem sicheren zentralen Ort verwahren. Dies ermöglicht Ihnen, Systeme sicher zu transportieren oder sie vorübergehend stillzulegen, wenn sie für einen längeren Zeitraum unbeaufsichtigt bleiben. Dadurch wird sichergestellt, dass autorisierte Benutzer nach wie vor auf die Daten zugreifen können, aber unbefugte Benutzer, z. B. neue Besitzer der Hardware, dagegen nicht.
Sie können aber auch alle Kopien der Schlüssel aus den Volumemetadaten und aus allen Archiven wie Active Directory löschen, indem Sie etwa neue Schlüssel erstellen, die dabei nicht gespeichert werden. Da anschließend keine Entschlüsselungsschlüssel existieren, kann niemand die Daten wiederherstellen oder Daten abrufen.
In jedem dieser Fälle erfolgt das Entfernen und Zerstören der in den Volumemetadaten enthaltenen Schlüssel fast unmittelbar. Diese Vorgänge können von einem Administrator über mehrere Systeme hinweg durchgeführt werden. Dazu ist ein minimaler Zeit- und Arbeitsaufwand erforderlich, der ein extrem hohes Niveau an permanentem Schutz bietet. Das Formatierungsdienstprogramm in Windows Vista wurde so aktualisiert, dass ein Formatierungsbefehl die Volumemetadaten löscht und anschließend diese Sektoren überschreibt, wodurch alle BitLocker-Schlüssel sicher gelöscht werden.

Einige abschließende Punkte
BitLocker ist ein leistungsfähiges Tool zum Schutz gegen bestimmte Gefahren, das hervorragende Arbeit leistet. Es kann jedoch nicht erwartet werden, dass BitLocker gegen sämtliche Gefahren schützt. Daher ist es außerordentlich wichtig, dass Sie weiterhin geeignete Schutz- und Kontrollmaßnahmen ergreifen, indem Sie beispielsweise sichere Kennwörter verwenden.
Denken Sie daran, dass BitLocker zum Schutz gegen Offlineangriffe entwickelt wurde. Wenn Windows ausgeführt wird, hat BitLocker das Volume also entsperrt. Anders ausgedrückt: Während der Ausführung eines Systems bietet BitLocker keinen Schutz für dieses System. Technologien wie EFS und RMS ergänzen BitLocker durch Schutz von Informationen während der Ausführung des Betriebssystems.
Weitere Informationen zu BitLocker erhalten Sie auf der Microsoft-Website unter technet.microsoft.com/windowsvista/aa905065.aspx. Weitere Informationen über TPM-Spezifikationen und die TCG finden Sie im Abschnitt „TPM-Spezifikationen“ der TCG-Website unter go.microsoft.com/fwlink/?LinkId=72757.

Byron Hynes arbeitet in der Windows Server User Assistance-Gruppe bei Microsoft. In der Vergangenheit war er als Berater und Ausbilder tätig. Er ist unter bhynes@microsoft.com zu erreichen.


 Sicherheit: Im Blickpunkt: Die Windows-Firewall
Sicherheit Steve Riley

Im Blickpunkt: Die Windows-Firewall
Kurz zusammengefasst:
  • Eingehender Schutz – Ausgehender Schutz
  • Die Windows-Filterungsplattform
  • Die erweiterte Sicherheitsschnittstelle
  • Netzwerkprofile

Damals in der Computersteinzeit hat sich noch niemand Gedanken über die Installation von Firewalls auf einzelnen Computern gemacht. Warum auch? Kaum jemand hatte vom Internet gehört, TCP/IP war noch meilenweit entfernt, und LAN-Protokolle reichten nur bis zur Gebäude- oder Campusgrenze. Wichtige Daten befanden sich auf
dem Mainframe oder den Dateiserver. Die Daten, die die Mitarbeiter auf ihren Desktopcomputern speicherten, waren selten unternehmenswichtig, und durch das bloße Gewicht des Computers war schon ein gewisser physischer Schutz vor Diebstahl gewährleistet. Falls dann doch eine Verbindung zum Internet verfügbar war, standen wahrscheinlich einige Protokollkonvertierungsprogramme im Weg, und am Rand des firmeninternen Netzwerks stand ein Paketfilterungsrouter (ich meine, eine „Firewall“), der in der Regel mit Unmengen an Regeln und Ausnahmen überkonfiguriert war.
Moderne Computerumgebungen haben nichts mehr mit diesen altertümlichen Zuständen gemeinsam. Alles und jeder ist jetzt mit dem Internet verbunden (und nutzt TCP/IP), und mobile Geräte sind zum Standard geworden. Ihr Arbeitgeber hat Ihnen wahrscheinlich einen Laptop zur Verfügung gestellt. Nicht gerade, weil Sie ihm besonders wichtig sind, sondern weil Sie die größtmögliche Leistung erbringen sollen: Es wird tatsächlich von Ihnen erwartet, dass Sie immer dann arbeiten, wenn Sie gerade einmal fünf Minuten Zeit haben und eine Wi-Fi-Verbindung besteht. Laptops kosten vielleicht mehr als Desktops, aber diese Investition macht sich durch die höhere Produktivität in jedem Fall bezahlt. Gerade diese Mobilität macht die Geräte so anziehend – sowohl für Sie selbst als auch für ungünstig gesonnene Zeitgenossen.
Denken Sie einmal darüber nach: Vergleichen Sie die Gesamtzeit, in der Ihr Laptop eingeschaltet und mit einem Netzwerk verbunden ist, mit dem Zeitraum, in dem der Laptop eine Verbindung zum Unternehmensnetzwerk besitzt. Wie hoch ist der prozentuale Anteil dieses Zeitraums an der Gesamtzeit? Bei durchschnittlichen Benutzern dürfte der Wert bei maximal etwa 20 Prozent liegen. Das bedeutet, dass sich mein Laptop nur 20 Prozent der Zeit sicher innerhalb der Grenzen des Microsoft-Unternehmensnetzwerks befindet, das durch die Verteidigungsanlagen am Netzwerkperimeter vor Angriffen von außen geschützt wird. Aber was ist mit den verbleibenden 80 Prozent der Zeit, wenn mein Laptop direkt mit dem Internet verbunden ist? (Und ich bin ziemlich oft mit dem gefährlichsten Netzwerk der Welt verbunden: das hoteleigene LAN bei einer Computersicherheitskonferenz!) Und wie sieht es mit der Zeit aus, in der eine Verbindung zum Unternehmensnetzwerk besteht? Was ist mit den Bedrohungen, die von anderen Computern in dieser Umgebung ausgehen?
Sicherheitseinrichtungen entwickeln sich als Antwort auf die Bedrohungen. Und manchmal viel zu langsam. Viren waren ein Clientproblem, weil die Benutzer untereinander Disketten ausgetauscht haben. Antivirenprogramme wurden daher zuerst für Clients geschrieben. Als dann E-Mails einen immer größeren Stellenwert erlangten und die Malware zu Würmern wurde, die sich auf die Verteilung per E-Mail verließen, wurden Antimalwareprogramme entwickelt und auf E-Mail-Gateways bereitgestellt. Mit der immer stärkeren Nutzung des Internet wurde die Malware zu Trojanern, und Antimalwareprogramme erhielten auf Internetzugangs-Proxyservern ihren Platz. An diesem etablierten Entwicklungspfad krittelt niemand herum.
Nun zu den Firewalls, und zwar mit derselben Logik. Gestern konnte eine Firewall am Netzwerkrand die Bedrohungen noch wirksam abwehren. Heute sind die Bedrohungen anders; sie sind höher entwickelt, und sie sind weiter verbreitet. Ganz zu schweigen davon, dass die Geräte und die Arbeitsverfahren bedeutend von der Vergangenheit abweichen. Auf vielen Computern sind vertrauliche Informationen lokal gespeichert, und diese Computer befinden sich geraume Zeit nicht im Unternehmensnetzwerk (also außerhalb des Netzwerkrands). Aus diesem Grund muss sich die Firewall zu einem individuellen Schutzmechanismus für einzelne Clients entwickeln. Lassen Sie sich nicht täuschen: Clientfirewalls sind nicht mehr optional. Um Ihre Computer vor Ihrem eigenen, firmeninternen Netzwerk und vor dem Internet zu schützen, sind Clientfirewalls unabdingbar.

Clientsfirewalls und Sicherheitstheater
Viele Benutzer wussten nicht einmal, dass die erste Version von Windows® XP eine Clientfirewall enthielt. Das ist nicht weiter verwunderlich, weil die Firewall standardmäßig deaktiviert war und hinter unzähligen Mausklicks begraben lag. Auf ihre eigene, verstohlene Weise trat die Firewall einfach in Erscheinung, ohne dass ihr Zweck näher beschrieben oder gar Anweisungen gegeben wurden. Aber es hat funktioniert. Wenn Sie diese Firewall aktiviert hätten, dann wären Sie vor Nimda, Slammer, Blaster, Sasser, Zotob und anderen schädlichen Elementen geschützt gewesen, die Ihren Netzwerkport mit unerwünschtem Datenverkehr überfluten wollen. In Anbetracht der Bedeutung, die der Clientschutz mittlerweile erlangt hat, ist die Firewall in Windows XP Service Pack 2 (SP2) standardmäßig aktiviert, wobei zwei Profile erstellt („Internet“ und „corpnet“) und die Aktivierung von Gruppenrichtlinien ermöglicht wurden.
Die Akzeptanz der Firewall in Windows XP SP2 durch die Benutzer wurde leider von zwei Hindernissen gebremst: Bedenken im Hinblick auf die Anwendungen und ein wahres Sicherheitstheater. Viele Benutzer fürchteten, dass ihre Anwendungen aufgrund der Firewall nicht mehr richtig arbeiten würden. Aufgrund des Designs der Firewall war dies aber nur selten der Fall. Die Firewall ließ den gesamten ausgehenden Datenverkehr vom Computer passieren; eingehender Datenverkehr, der keine Antwort auf eine vorangegangene ausgehende Anfrage war, wurde dagegen blockiert. Dieses Design würde nur dann eine Anwendung auf einem Client außer Gefecht setzen, wenn die Anwendung einen Abhörsocket einrichtet und auf eingehende Anforderungen wartet. Bei der Windows XP-Firewall waren einfache Konfigurationen von Ausnahmen für Programme oder Ports möglich (leider jedoch nicht durch Gruppenrichtlinien).
Das größere Abschreckungsmittel war das Sicherheitstheater, das die Hersteller anderer Clientfirewalls aufführten. Einige Benutzer waren der Meinung, dass das Design der Windows XP-Firewall (ausgehender Datenverkehr darf ungehindert passieren) keinen ausreichenden Funktionsumfang für eine Clientfirewall bot. Die Hersteller brachten das Argument vor, dass eine angemessene Clientfirewall den gesamten Datenverkehr blockieren sollte, also sowohl eingehend als auch ausgehend, wenn der Benutzer nicht speziell eine Berechtigung für diesen Datenverkehr erteilt hat.
Dieser Punkt ist eine nähere Überlegung wert. Zwei Szenarios zeichnen sich ab.
  • Wenn Sie als lokaler Administrator angemeldet sind und Ihr Computer mit Malware infiziert ist, wird die Firewall durch diese Malware kurzerhand deaktiviert. Sie sind 0wn3d.
  • Wenn Sie nicht als lokaler Administrator angemeldet sind und der Computer mit Malware infiziert ist, bewirkt die Malware bei einer Drittanbieterfirewall, dass ein Dialogfeld in einer fremden Sprache geöffnet wird, in dem zahllose Ports und IP-Adressen aufgeführt werden und dazu eine schwerwiegende Frage: „Möchten Sie dies zulassen?“ Die einzige Antwort ist selbstverständlich: „Ja, du dummer Computer, nerv mich nicht!“ Und sobald das Dialogfeld verschwindet, ist auch Ihre Sicherheit futsch. Eine andere, häufigere Situation: Die Malware entführt quasi eine vorhandene Sitzung eines Programms, das Sie bereits autorisiert haben. In diesem Fall wird nicht einmal das Dialogfeld geöffnet. Noch einmal: Sie sind 0wn3d.
Es gibt einen wichtigen Sicherheitsgrundsatz, den Sie sich verinnerlichen müssen: Der Schutz gehört zu der Ressource, die geschützt werden soll, nicht zu der Sache, vor der geschützt werden soll. Die richtige Vorgehensweise besteht darin, die schlanke und doch wirksame Windows-Firewall auf jedem Computer in Ihrem Unternehmen auszuführen, um so jeden einzelnen Computer vor sämtlichen Computern in der ganzen Welt zu schützen. Angenommen, Sie versuchen, ausgehende Verbindungen von einem Computer zu blockieren, der bereits infiziert wurde: Wie können Sie da sicher sein, dass der Computer wirklich das tut, was Sie wollen? Die Antwort: Gar nicht. Der ausgehende Schutz ist pures Sicherheitstheater. Ein Kniff, der Ihnen nur vorspiegelt, dass Ihre Sicherheit erhöht würde, ohne dass tatsächlich auch nur eine einzige Aktion zur Erhöhung dieser Sicherheit ausgeführt wird. Genau deshalb gab es keinen Schutz für ausgehenden Datenverkehr in der Firewall von Windows XP, und genau deshalb gibt es diesen Schutz auch nicht in der Firewall bei Windows Vista™. (Ich werde später noch ausführlicher über die Kontrolle für den ausgehenden Datenverkehr sprechen.)

Neues in Windows Vista
Die Windows-Filterungsplattform, ein Bestandteil des neuen Netzwerkstapels, bildet die Grundlage für die Firewall von Windows Vista. Wie Windows XP blockiert auch Windows Vista standardmäßig den gesamten eingehenden Datenverkehr. Abhängig vom Profil auf Ihrem Computer bestehen ggf. einige Standardausnahmen für Netzwerkdienste. (Die Profile werden später näher erörtert.) Nach Wunsch können Sie Regeln schreiben, mit denen eingehende Verbindungen zugelassen werden. Ebenso wie bei Windows XP ist bei Windows Vista standardmäßig der gesamte ausgehende Datenverkehr von interaktiven Prozessen zulässig, während der ausgehende Datenverkehr von Diensten, die an der Diensteinschränkung beteiligt sind, eingeschränkt wird. Wiederum können Sie Regeln schreiben, um damit weitere ausgehende Verbindungen zu blockieren.
Der große Unterschied zwischen Windows XP und Windows Vista liegt in der neuen erweiterten Sicherheitsschnittstelle und in der vollen Gruppenrichtlinienunterstützung für Konfiguration und Regeln (siehe Abbildung 1). Die bisherige Benutzeroberfläche der Systemsteuerung ist immer noch vorhanden und ist größtenteils unverändert, mit Ausnahme der Protokolleinstellungen und der ICMP-Einstellungen (Internet Control Message-Protokoll), die sich jetzt in der neuen Benutzeroberfläche befinden. Diese neue Benutzeroberfläche, das MMC-Snap-In für die erweiterte Sicherheit, bietet alle neuen Funktionen und sorgt für eine ganz neue Flexibilität. Für den Befehl „netsh“ gibt es außerdem den neuen Kontext „netsh advfirewall“, mit dem Sie Skriptregeln hinzufügen und löschen, globale und profilspezifische Richtlinien festlegen und abrufen und auch den aktiven Zustand der Firewall ermitteln. Und für Entwickler: „FirewallAPI.dll“ und „Netfw.h“ bieten die programmgesteuerte Kontrolle über sämtliche Einstellungen der Firewall.
Abbildung 1 Windows Firewall mit erweiterter Sicherheit
Abbildung 1 Windows Firewall mit erweiterter Sicherheit
Das MMC für die erweiterte Sicherheit ist mit einem Assistenten ausgestattet. Beim Erstellen einer Regel können Sie unter vier Typen auswählen: Programm, Port, vordefiniert oder benutzerdefiniert. Diese Optionen sind in Abbildung 2 dargestellt.
Figure 2 Vier Arten von Regeln (Close Figure 2)

Typ | Zweck
Programm | Ermöglicht oder blockiert den Datenverkehr für ein bestimmtes Programm.
Port | Ermöglicht oder blockiert den Datenverkehr über bestimmte TCP- oder UDP-Ports.
Vordefiniert | Aktiviert den Windows-Funktionsumfang auf dem Netzwerk mithilfe einer Reihe bereits vorhandener Regeln (z. B. Datei- und Druckfreigaben oder Remoteunterstützung).
Benutzerdefiniert | Stellt alle Schaltflächen und Regler zur Verfügung, sodass Sie eine Regel ganz nach Ihren Wünschen konfigurieren können.
Wenn Sie Regeln schreiben, können Sie auf viele Elemente verweisen, wobei alle Elemente sowohl für lokale Regeln verfügbar sind als auch für Regeln, die über Gruppenrichtlinien angewendet werden. Dazu zählen: Benutzer- und Computerkonten und -gruppen in Active Directory®, Quell- und Ziel-IP-Adressen, Quell- und Ziel-TCP-/-UDP-Ports, IP-Protokollnummern, -programme und -dienste, Schnittstelltypen (drahtgebunden, drahtlos oder Remotezugriff), ICMP-Typen und -Codes.
Sobald die Firewall konfiguriert ist, werden die Regeln in der folgenden Reihenfolge verarbeitet:
Diensteinschränkungen Ein Teil der Dienste in Windows Vista erlegt sich selbst gewisse Einschränkungen auf, um so die Wahrscheinlichkeit eines Blaster-Angriffs zu vermindern. Zu diesen Einschränkungen gehört beispielsweise eine Liste der Ports, die für den Dienst erforderlich sind. Die Firewall setzt diese Ports durch und sorgt dafür, dass der Dienst keinen anderen Port verwendet (und auch nicht zur Verwendung eines anderen Ports angewiesen wird).
Verbindungssicherheitsregeln Die MMC für die erweiterte Sicherheit umfasst sowohl IPSec als auch die Firewall. Als Nächstes werden sämtliche Regeln mit IPSec-Richtlinien verarbeitet.
Authenticated Bypass Hiermit sind die angegebenen authentifizierten Computer in der Lage, andere Regeln zu umgehen.
Blockierungsregeln Hiermit wird eingehender oder ausgehender Datenverkehr explizit blockiert.
Zulassungsregeln Hiermit wird eingehender oder ausgehender Datenverkehr explizit zugelassen.
Die Firewallregeln sind in der Registrierung gespeichert, aber ich verrate nicht, wo. Na schön, weil Sie es sind:
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
Bearbeiten Sie die Regeln auf keinen Fall direkt in der Registrierung. Ansonsten finden wir Sie, und dann verkaufen wir Ihr Auto im Internet! Nein, keine Sorge, das machen wir nicht. Aber die einzige unterstützte Möglichkeit für die Bearbeitung von Regeln ist die MMC für die erweiterte Sicherheit.

Netzwerkprofile
In Windows Vista sind drei Netzwerkprofile definiert: Domäne, privat, öffentlich. Wenn der Computer einer Domäne angeschlossen ist und sich erfolgreich bei der Domäne angemeldet hat, wendet der Computer automatisch das Domänenprofil an. Sie können diese Auswahl nicht selbst treffen. Wenn der Computer eine Verbindung zu einem internen Netzwerk herstellt, das keine Domäne besitzt (z. B. ein Heimnetzwerk oder ein kleines Büronetzwerk), sollten Sie (oder ein Administrator) das private Profil anwenden. Sobald der Computer direkt mit dem Internet verbunden ist, sollten Sie dann das öffentliche Profil anwenden.
Wie entscheidet Windows Vista, wo Ihr Computer hingelangt? Wenn sich das Netzwerk ändert (das Netzwerk erhält eine neue IP-Adresse oder erkennt ein neues Standardgateway oder wird mit einer neuen Schnittstelle ausgestattet), wird diese Änderung im NLA-Dienst (Network Location Awareness) erkannt. Der Dienst erstellt ein Netzwerkprofil, das beispielsweise Informationen zu vorhandenen Schnittstellen oder die MAC-Adresse des Gateways enthält und aus dem auch hervorgeht, ob der Computer bei einem Domänencontroller authentifiziert ist, und weist diesem Profil eine GUID zu. Anschließend benachrichtigt der NLA die Firewall, und die Firewall wendet die zugehörige Richtlinie an. (Für jedes der drei Profile ist jeweils eine Richtlinie definiert.)
Wenn eine neue Schnittstelle vorliegt, die der Computer noch nicht erkannt hat, und wenn der NLA das Domänenprofil nicht ausgewählt hat, wird ein Dialogfeld geöffnet, in dem Sie aufgefordert werden, das Netzwerk anzugeben, zu dem eine Verbindung hergestellt werden soll. Interessanterweise stehen hier drei Optionen zur Auswahl: Privat, Arbeitsplatz, Öffentlich. Die Option für den Arbeitsplatz scheint dem Domänenprofil zu entsprechen; das stimmt allerdings nicht. Denken Sie daran: Das Domänenprofil ist für Sie nicht sichtbar, weil der NLA dieses Profil automatisch auswählt, sobald sich der Computer bei einer Domäne anmeldet. Sowohl „Privat“ als auch „Arbeitsplatz“ gehören zum privaten Profil. Praktisch sind diese Netzwerke gleichwertig, nur die Symbole sind anders. (Hinweis: Um das private Profil auswählen zu können, müssen Sie als lokaler Administrator angemeldet sein oder Ihre Berechtigung auf die Rechte eines lokalen Administrators zu erhöhen.) Wie zu erwarten war, steht „Öffentlich“ für das öffentliche Profil.
In Windows Vista gilt ein Netzwerkprofil für sämtliche Schnittstellen im Computer. Der folgende Überblick zeigt die NLA-Entscheidungsstruktur:
  1. Untersuchen Sie alle verbundenen Netzwerke.
  2. Ist eine Schnittstelle mit einem Netzwerk verbunden, das als öffentlich eingestuft ist? Wenn ja, aktivieren Sie das öffentliche Profil für den Computer, und beenden Sie den Dienst.
  3. Ist eine Schnittstelle mit einem Netzwerk verbunden, das als privat eingestuft ist? Wenn ja, aktivieren Sie das private Profil für den Computer, und beenden Sie den Dienst.
  4. Können alle Schnittstellen einen Domänencontroller erkennen, und wurde der Computer erfolgreich angemeldet? Wenn ja, aktivieren Sie das Domänenprofil für den Computer, und beenden Sie den Dienst.
  5. Ansonsten aktivieren Sie das öffentliche Profil für den Computer.
Das Ziel ist es, das Profil mit den größtmöglichen Einschränkungen auszuwählen. Allerdings gibt es hier zwei offensichtliche Nebeneffekte. Erstens: Wenn der Ethernet-Port des Computers mit dem corpnet verbunden ist und die drahtlose NIC mit dem Schnellrestaurant im Erdgeschoss verbunden ist, wählt der Computer das öffentliche Profil aus, nicht das Domänenprofil. Zweitens: Wenn der Computer direkt mit dem Internet (im öffentlichen Profil) oder mit dem privaten LAN (im privaten Profil) verbunden ist und Sie eine VPN-Verbindung zum corpnet herstellen, verbleibt der Computer jeweils im öffentlichen oder privaten Profil.
Was könnte dies bedeuten? Die Richtlinie der Firewall für das Domänenprofil umfasst Regeln für die Remoteunterstützung, die Remoteverwaltung, die Datei- und Druckfreigabe und vieles mehr. Wenn Sie mit diesen Regeln eine Remoteverbindung zu einem Client aufbauen möchten, kommen Sie nicht zum Ziel, wenn der Client ein anderes Profil ausgewählt hat. Aber keine Sorge: Sie können eigene Firewallregeln schreiben, mit denen Sie die jeweils notwendigen eingehenden Verbindungen zulassen, und diese Regeln dann ausschließlich auf VPN-Verbindungen anwenden. So können Sie die Clients selbst dann noch über das VPN verwalten, wenn sie sich nicht im Domänenprofil befinden.

Kontrollieren von ausgehenden Verbindungen
Weiter oben erwähnte ich, dass die normale Spielart für den ausgehenden Schutz in Clientfirewalls ein pures Sicherheitstheater ist. Eine bestimmte Spielart der Kontrolle für den ausgehenden Datenverkehr ist jedoch äußerst nützlich: die administrative Kontrolle bestimmter Datenverkehrsarten, die Sie auf keinen Fall zulassen wollen. Die Firewall in Windows Vista geht bei den Diensteinschränkungen bereits so vor. Die Firewall lässt die Kommunikation für einen Dienst nur über die Ports zu, die dieser Dienst explizit als notwendig meldet; alle anderen Aktivitäten des Dienstes werden blockiert. Und diesen Aspekt können Sie als Grundlage für weitere Regeln heranziehen, mit denen Sie bestimmten Datenverkehr gemäß der Sicherheitsrichtlinie Ihres Unternehmens zulassen oder blockieren (siehe Abbildung 3).
Abbildung 3 Assistent für neue eingehende Regeln
Abbildung 3 Assistent für neue eingehende Regeln
Angenommen, die Benutzer sollen einen bestimmten Instant Messaging-Client nicht ausführen dürfen. Sie können eine Regel erstellen (natürlich in den Gruppenrichtlinien), mit der Sie Verbindungen zu den Anmeldungsservern für diesen Client blockieren.
Bei dieser Methode gibt es allerdings einige Einschränkungen. Windows Live™ Messenger (früher als MSN® Messenger bezeichnet) kann sich beispielsweise bei verschiedenen Servern anmelden, und die Liste ändert sich ständig. Und wenn der Standardport 1863/Tcp blockiert ist, wird der Port 80/Tcp herangezogen. Eine Regel, mit der Windows Live Messenger von der Anmeldung bei den Anmeldungsservern abgehalten wird, wäre zu kompliziert und zudem ständig in Bewegung. Ich erwähne das, weil ich klarstellen möchte, dass die administrative Kontrolle des ausgehenden Datenverkehrs durchaus nützlich sein kann, aber auf keinen Fall einen Ersatz für die Richtlinien für Softwareeinschränkung darstellt, wenn Sie die strenge Kontrolle über die Software behalten wollen, die die Benutzern installieren und ausführen dürfen.

Schützen Sie Ihren Computer
Der Perimeter ist weg. Jeder Computer muss jetzt selbst die Verantwortung für den eigenen Schutz übernehmen. So wie Antimalwareprogramme vom Netzwerkrand zum Client gewandert sind, so müssen auch Firewalls vom Rand zum Client gelangen. Sie können sofort Gegenmaßnahmen ergreifen, einfach indem Sie die Firewall aktivieren, die Sie ohnehin schon installiert haben.
Ganz egal, ob auf Ihren Systemen noch Windows XP ausgeführt wird oder ob Sie schon auf Windows Vista umgestiegen sind: Die Windows-Firewall steht für alle Ihre Clients zur Verfügung und liefert dabei den Schutz, den Sie brauchen, um die Sicherheit innerhalb Ihres Unternehmens zu erhöhen, und das selbst dann, wenn Ihre mobilen Mitarbeiter Tausende von Kilometern vom Büro weg sind.

Weiterführende Informationen
  • Windows Vista TechCenter: Erste Schritte mit der Windows-Firewall mit erweiterter Sicherheit
  • Windows Vista TechCenter: Windows-Firewall mit erweiterter Sicherheit: Diagnose und Problembehandlung
  • TechEd Europe-Präsentation von Steve Riley: Verbesserungen bei der Firewall von Windows Vista und bei IPSec
  • The Cable Guy: Die neue Windows-Firewall in Windows Vista und Windows Server „Longhorn“
  • Virtual Lab für Windows Vista-Firewall

Steve Riley ist ein erfahrener Sicherheitsstratege in der Microsoft Trustworthy Computing Group und beitragender Redakteur des TechNet Magazins. Er reist um die Welt, um auf Konferenzen Vorträge zu halten, und unterstützt Kunden dabei, Sicherheitsvorkehrungen zu treffen und zu verbessern. Sein neues Buch heißt Protect Your Windows Network (Addison-Wesley, 2005). Er ist zu erreichen unter steve.riley@microsoft.com.


 Sicherheit: Neue ACLs erh&#246;hen die Sicherheit in Windows Vista
Sicherheit Jesper Johansson

Neue ACLs erhöhen die Sicherheit in Windows Vista
Kurz zusammengefasst:
  • Neuerungen bei ACLs
  • Strengere Kontrollen für Administratoren
  • Berechtigungen für vertrauenswürdige Installationsprogramme
  • Geänderte Benutzer und Gruppen

Die grundlegende Struktur von Zugriffskontrolllisten (Access Control Lists, ACLs) hat sich in Bezug auf Windows Vista nicht wesentlich geändert, aber es gibt einige geringfügige und dennoch wichtige Änderungen, die Sie kennen müssen. Einige Änderungen
waren notwendig, weil ACLs in Windows® XP bei verschiedenen Problemen eine Rolle spielen. Erstens werden die meisten Windows XP-Benutzer als Administrator ausgeführt. Das heißt, sie verwenden ein Konto, das Mitglied der integrierten Gruppe „ADMINISTRATOREN“ ist. Bei privaten Benutzern ist dies praktisch immer der Fall, da alle Konten, die bei der Installation hinzugefügt werden, als Administratoren eingerichtet werden. Daher werden alle Programme, die diese Benutzer starten, ebenfalls mit Administratorrechten ausgeführt, die ihnen uneingeschränkten Zugriff auf das Betriebssystem geben. Dies ist natürlich besonders problematisch, wenn es sich bei diesen Programmen um böswillige Programme handelt.
Das zweite Problem, das in Angriff genommen werden musste, bestand darin, dass die Standard-ACLs in früheren Versionen von Windows viele Benutzer nervös gemacht haben, weil sie ACL-Einträge (ACEs) für „ALLE“, „HAUPTBENUTZER“ und so weiter enthielten. So erteilte beispielsweise die Standard-ACL im Stammverzeichnis des Startvolumes (normalerweise C:\) in Windows XP Mitgliedern der Gruppe „ALLE“ Lesezugriff und die Berechtigung, Ordner für Mitglieder der Gruppe „BENUTZER“ zu erstellen. Außerdem gab es in Windows XP Einschränkungen dafür, was Sie mit ACLs ausführen konnten. So gab es in Windows XP beispielsweise keine Möglichkeit, dem aktuellen Besitzer eines Objekts Berechtigungen zuzuweisen. Dem Besitzer konnten zwar Berechtigungen erteilt werden, aber wenn sich der Besitzer änderte, wurden diese Berechtigungen nicht übertragen. In ähnlicher Weise verfügten Besitzer unabhängig davon, welche Berechtigungen ihnen für ein Objekt zugewiesen wurden, immer über implizite Rechte für dieses Objekt.
Mit Windows Vista™ hat Microsoft das Projekt in die Wege geleitet, viele dieser Probleme zu beheben und Unterstützung für weitere Funktionen wie die Benutzerkontensteuerung (User Account Control, UAC) bereitzustellen. Dieser Artikel konzentriert sich auf die wichtigsten Änderungen, die in Windows Vista in Bezug auf die Zugriffssteuerung vorgenommen wurden. Im nächsten Monat geht es dann um die Tools, mit denen die Zugriffssteuerung verwaltet werden kann.

Neue und geänderte Benutzer und Gruppen
Einige Benutzer und Gruppen in Windows Vista sind neu, und einige ältere Funktionen aus Windows XP wurden entfernt. Darüber hinaus wurde bei einigen die Funktionsweise geändert. Jede dieser Änderungen hat Auswirkungen auf die Verwaltung der Zugriffssteuerung.
Administrator – Standardmäßig deaktiviert Das integrierte ADMINISTRATOR-Konto mit der relativen ID (RID) 500 ist jetzt in den meisten Fällen standardmäßig deaktiviert. ADMINISTRATOR war als Notfallkonto vorgesehen, das zur Wiederherstellung des Computers verwendet werden sollte, wenn alle anderen Methoden fehlschlugen. In den meisten Fällen wurde es jedoch als Standardkonto für die Administration verwendet, was einen Verstoß gegen mehrere Sicherheitsprinzipien darstellte. Der Verstoß gegen das wichtigste dieser Prinzipien, das Prinzip der Verantwortlichkeit, hatte zur Folge, dass es nicht mehr möglich war nachzuverfolgen, wer Änderungen am System vornahm. Daher ist dieses Konto jetzt teilweise veraltet. Microsoft wird dieses Konto wahrscheinlich irgendwann völlig abschaffen, aber vorläufig ist es standardmäßig deaktiviert. Wenn Sie keine anderen lokalen Konten in der Gruppe „ADMINISTRATOREN“ besitzen, kann RID 500 weiterhin in der Wiederherstellungskonsole und im abgesicherten Modus verwendet werden, wenn dies aber nicht der Fall ist, kann und sollte es nicht verwendet werden.
Beachten Sie, dass zwischen dem integrierten ADMINISTRATOR-Konto und anderen Konten der Gruppe „ADMINISTRATOREN“ ein Unterschied besteht. Wir schreiben „ADMINISTRATOR“ in der Regel groß, wenn wir uns auf das Konto mit der RID 500 beziehen, um es von einem „Administrator“ abzuheben, der ein anderes Konto der integrierten Gruppe „ADMINISTRATOREN“ verwendet. Gruppennamen werden ebenfalls groß geschrieben.
In Windows XP verfügte das integrierte ADMINISTRATOR-Konto über mehrere spezielle Rechte und Berechtigungen, die kein anderer Administrator besaß. Viele dieser Rechte und Berechtigungen wurden in Windows Vista entfernt, aber es gibt zwei wichtige Ausnahmen: Erstens kann ein deaktiviertes ADMINISTRATOR-Konto in der Wiederherstellungskonsole verwendet werden, wenn es keine anderen lokalen Administratoren gibt. Zweitens unterliegt der ADMINISTRATOR nicht der Benutzerkontensteuerung (User Account Control, UAC), und er verfügt immer über ein vollständiges Administratortoken. Dasselbe gilt für den DOMÄNENADMINISTRATOR (RID 500 in einer Domäne).
HAUPTBENUTZER-Berechtigungen wurden entfernt Die alte HAUPTBENUTZER-Gruppe wurde aus praktischen Gründen abgeschafft. Die Gruppe ist zwar noch vorhanden, aber die meisten Berechtigungen, die sie früher hatte, wurden entfernt. Es war kein Geheimnis, dass ein Benutzer, der Mitglied der HAUPTBENUTZER-Gruppe war, im Grunde ein Administrator war, der sich lediglich noch nicht selbst zum Administrator gemacht hatte. Ich habe einmal einen Computer, auf dem alle Patches installiert waren und Windows XP Service Pack 2 (SP2) ausgeführt wurde, in weniger als 45 Minuten übernommen, indem ich mir selbst Administratorberechtigungen zuwies. In dieser Zeitspanne habe ich den Computer erkundet, ein kleines Programm in C++ geschrieben und mich ab- und wieder angemeldet, um die Übernahme abzuschließen, was möglich war, weil ich ein Mitglied der Gruppe „HAUPTBENUTZER“ war.
Da viele Organisationen der Gruppe „HAUPTBENUTZER“ gut durchdachte Berechtigungen zugewiesen haben und sich darauf verlassen, dass ihre Benutzer dieser Gruppe angehören, konnte diese Gruppe in Windows Vista nicht einfach abgeschafft werden. Es ist jedoch wahrscheinlich, dass Microsoft in einer zukünftigen Version die Gruppe „HAUPTBENUTZER“ vollständig entfernen wird. Sie sollten deshalb langsam Pläne dafür entwerfen, die Verwendung der Gruppe „HAUPTBENUTZER“ aufzugeben.
Vertrauenswürdiges Installationsprogramm Das vertrauenswürdige Installationsprogramm ist eigentlich kein Benutzer, sondern ein Dienst, obwohl Sie im gesamten Dateisystem Berechtigungen sehen können, die ihm zugewiesen sind. Diensthärtung ermöglicht, dass jeder Dienst als vollwertiger Sicherheitsprinzipal behandelt wird, dem wie jedem anderen Benutzer Berechtigungen zugewiesen werden können. Einen Überblick über diese Funktion finden Sie im TechNet Magazin in der Ausgabe vom Januar 2007. Im Buch Windows Vista Security (Grimes und Johansson, Wiley Press, 2007) wird die Diensthärtung einschließlich ihrer Nutzung durch andere Funktionen wie die Firewall und IPSec ausführlich behandelt.
Dienst-SIDs werden nicht von den bisher bekannten Autoritäten wie NT AUTHORITY oder einer Domäne zugewiesen. Der vollständige Name des virtuellen Kontos „TrustedInstaller“ lautet „NT SERVICE\TrustedInstaller“, und es besitzt folgende SID:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Sie können die SID jedes Diensts, sogar die SID von Diensten, die nicht existieren, anzeigen, indem Sie, wie in Abbildung 1 gezeigt, den Befehl „sc showsid“ ausführen.
Abbildung 1 „sc showsid“ zeigt die SID jedes Diensts, einschließlich der Dienste, die noch nicht existieren.
Abbildung 1 „sc showsid“ zeigt die SID jedes Diensts, einschließlich der Dienste, die noch nicht existieren.
Diese SID beginnt mit S-1-5-80. Beachten Sie hierbei, dass die erste Subautorität 80 ist, was für SECURITY_SERVICE_ID_BASE_RID steht und bedeutet, dass diese SID einem Dienst durch die Subautorität NT SERVICE erteilt wird. Dasselbe gilt für jeden anderen Dienst. Den übrigen Subautoritäten und den RIDs wird der Dienstname selbst zugrunde gelegt. Dies ermöglicht einem Entwickler, seinem Dienst Berechtigungen zu gewähren, ohne den Dienst zuerst erstellen und installieren zu müssen, da der Name deterministisch ist und sich von Computer zu Computer nicht unterscheidet.
Falls Sie den TrustedInstaller-Dienst im Dienstmanager nicht finden können: Sein Anzeigename lautet „Windows Modules Installer“.
Hilfs- und Supportkonten wurden entfernt Die Konten „Support_xxxxxx“ und „HelpAssistant“ wurden bei reinen Windows Vista-Installationen entfernt, sind jedoch weiterhin vorhanden, wenn die Installation durch Aktualisierung einer vorherigen Windows-Version erfolgt ist. Das Konto „Support_xxxxxx“ hatte dazu gedient, Skripts vom Supportcenter auszuführen. Einige OEMs, die eigene Hilfsinhalte bereitstellten, haben u. U. auch eigene Unterstützungskonten bereitgestellt. Es ist noch nicht klar, was mit OEM-Konten geschehen wird, aber höchstwahrscheinlich werden die OEMs einfach aufhören, sie zu erstellen. Genau genommen sind sie nicht mehr notwendig. Aus der Perspektive der Sicherheit betrachtet war es sowieso keine sehr gute Idee, Benutzern die Möglichkeit zu geben, Skripts vom Hilfecenter als ein anderer Benutzer auszuführen, und daher wäre es am besten, wenn diese Konten verschwinden würden. Windows Vista verfügt über einen neuen Mechanismus, um diese Aufgabe zu bewältigen.
Das HelpAssistant-Konto wurde während der Fernunterstützung verwendet. Wie beim Hilfecenter wurde auch die Fernunterstützungsfunktion neu konstruiert, um das HelpAssistant-Konto überflüssig zu machen, und daher wurde dieses Konto entfernt.
Neue Netzwerkspeicherort-SIDs Auf Windows NT® basierende Betriebssysteme besaßen schon immer einige auf Netzwerkspeicherorten basierende SIDs, z. B. NETWORK und INTERACTIVE, um Benutzer zu kennzeichnen, die sich über das Netzwerk und interaktiv anmelden. Es gibt auch eine REMOTE INTERACTIVE LOGON-SID, die Benutzern zugewiesen wird, die sich über Terminaldienste anmelden. (Beachten Sie, dass die Benutzer von Terminaldiensten in ihren Tokens sowohl REMOTE INTERACTIVE LOGON als auch INTERACTIVE LOGON besitzen.) In Windows Vista wurden zwei weitere SIDs hinzugefügt: DIALUP und INTERNET. Der genaue Grund für ein Konto, das eine Anmeldung über eine DFÜ-Verbindung kennzeichnet, ist ein wenig unklar, insbesondere, da immer mehr Benutzer nicht mehr online gehen, wenn eine Telefonleitung die einzige verfügbare Netzwerkverbindung ist, aber jetzt ist dieses Konto eben da. INTERNET soll offensichtlich jeden Benutzer kennzeichnen, der sich von einem Standort außerhalb des LANs anmeldet. NETWORK dagegen kennzeichnet jede Netzwerkanmeldung, einschließlich Benutzeranmeldungen aus dem Internet.
OWNER RIGHTS und Besitzerrechte Es gibt jetzt eine SID namens OWNER RIGHTS für Besitzerrechte, die für jeden Besitzer einer Datei gilt, sobald auf diese Datei zugegriffen wird. Sie dient in erster Linie zur Einschränkung der Funktionen, die der Besitzer mit der Datei ausführen kann. Im Vergleich zu Windows XP wurden zwei bedeutende Änderungen an den Besitzerrechten vorgenommen. Erstens haben dann, wenn Sie der Besitzer des Objekts sind, es für das Objekt aber einen für Sie geltenden Eintrag für die Zugriffssteuerung (Access Control Entry, ACE) gibt, die Rechte in der Zugriffssteuerung Vorrang vor der Tatsache, dass Sie der Besitzer sind. Dies ist eine wichtige Änderung, die sich gravierend auf bestimmte Aspekte der Systemverwaltung auswirkt, da wir daran gewöhnt sind, dass der Besitzer implizite Rechte besitzt. Zweitens kann die OWNER RIGHTS-SID dazu verwendet werden, stärker einzuschränken, welche Funktionen der Benutzer mit einem Objekt ausführen kann.
Nehmen wir beispielsweise einmal an, dass es einen Ordner gibt, für den die in Abbildung 2 gezeigte ACL gilt und dessen Besitzer der Benutzer Jesper ist. Obwohl der Benutzer Jesper der Besitzer dieses Ordners ist, verfügt er für den Ordner nur über Leseberechtigung. Wenn er versucht, eine Datei in den Ordner zu kopieren, schlägt dieser Versuch fehl, da er nicht die Berechtigung besitzt, in den Ordner zu schreiben. Dies ist jedoch aus den Fehlermeldungen nicht ganz klar zu ersehen. Wenn Sie versuchen, eine Datei in einen Ordner zu kopieren, dessen Besitzer Sie sind, aber nicht über Schreibberechtigungen zum Verwenden von Windows Explorer® verfügen, geschieht Folgendes: Zunächst teilt Explorer Ihnen mit, dass Sie Ihre Berechtigungen erweitern müssen, um diese Datei zu kopieren, aber in Wirklichkeit schlägt das Kopieren der Datei fehl, da Sie nicht das Recht besitzen, etwas in diesen Ordner zu kopieren. Sie erhalten die Fehlermeldung „Sie benötigen Berechtigungen zur Durchführung des Vorgangs.“, und es werden die beiden Schaltflächen „Wiederholen“ (als ob das helfen würde) und „Abbrechen“ angezeigt. Dies geschieht, obwohl Sie der Besitzer sind.
Abbildung 2 Nur „Lokales System“ und ein weiterer Benutzer haben Zugriff auf diesen Ordner.
Abbildung 2 Nur „Lokales System“ und ein weiterer Benutzer haben Zugriff auf diesen Ordner.
Wenn Jesper versucht, die ACL für die Datei zu ändern, wird er aufgefordert, dazu sein Token zu erweitern. Da er der Besitzer der Datei ist, kann er dies tun. Der Besitzer besitzt weiterhin implizite Rechte zum Lesen und Ändern der ACL (READ_CONTROL und WRITE_DAC), sofern es keinen ACE für OWNER RIGHTS gibt, der etwas anderes besagt.
Um die Wirkung der OWNER RIGHTS-SID verständlicher zu machen, fügen wir dies jetzt der oben gezeigten ACL hinzu. Jetzt gelten die in Abbildung 3 gezeigten Berechtigungen.
Abbildung 3 Durch das Hinzufügen von OWNER RIGHTS-Berechtigungen zum Ordner werden Jespers Berechtigungen geändert.
Abbildung 3 Durch das Hinzufügen von OWNER RIGHTS-Berechtigungen zum Ordner werden Jespers Berechtigungen geändert.
Wenn mit diesen Berechtigungen jetzt versucht wird, über das Jesper-Konto etwas in den Ordner zu kopieren, gelingt dies sofort, da Jesper der Besitzer ist und er die entsprechenden Rechte besitzt. Wenn Jesper jedoch versucht, die ACL für das Objekt zu ändern, schlägt dieser Versuch fehl! Der ACE für OWNER RIGHTS gibt an, dass der Besitzer nur die Änderungsberechtigung, aber nicht die Fähigkeit besitzen soll, die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL) zu ändern. Daher werden OWNER RIGHTS-Berechtigungen in erster Linie dazu verwendet, dem Besitzer WRITE_DAC (die Fähigkeit, den Sicherheitsdeskriptor zu ändern) zu nehmen.
Wenn ein Administrator den Besitzer des Objekts ändert, werden die OWNER RIGHTS-Berechtigungen nicht automatisch auf den neuen Besitzer übertragen. In diesem Fall wird der OWNER RIGHTS-ACE deaktiviert, indem er als IO (Inherit-Only, nur vererben)-ACE gekennzeichnet wird, aber weder auf Container noch auf Objekte angewendet wird, wodurch er also eigentlich auf gar nichts angewendet wird. Durch diese Aktion wird sichergestellt, dass Administratoren nicht vollständig vom Objekt ausgesperrt werden. Um den OWNER RIGHTS-ACE wieder zu aktivieren, muss der ADMINISTRATOR den ACE manuell aktivieren. Um dies zu tun, kennzeichnen Sie ihn je nach Bedarf dafür, auf diesen Ordner, auf Unterordner und auf Dateien angewendet zu werden.
Es gibt mehrere interessante Szenarios, in denen die OWNER RIGHTS-SID nützlich sein kann, z. B. dann, wenn der Administrator Benutzern die Möglichkeit erteilen will, auf einem Dateiserver Dateien und Ordner zu erstellen, er aber zugleich verhindern will, dass sie ACLs für diese Ordner ändern können. Eine andere denkbare Situation liegt vor, wenn Benutzer zu einem bestimmten Zeitpunkt Mitglieder einer Gruppe sind und möglicherweise aus betrieblichen Gründen einige Objekte erstellen, aber später aus dieser Gruppe entfernt werden. Zu diesem Zeitpunkt dürften sie nicht mehr in der Lage sein, die Einstellungen für diese Objekte zu ändern.
OWNER RIGHTS werden bei der Diensthärtung in hohem Maße eingesetzt. Wenn ein Dienst zur Laufzeit ein temporäres Objekt erstellt, ist der Ersteller des Objekts die primäre SID des Dienstprozesses (in der Regel LocalSystem, NetworkService oder LocalService) und nicht die SID für den Dienst selbst. Dies bedeutet, dass jeder andere Dienst, der im gleichen Prozesskontext ausgeführt wird, das Objekt ändern kann, was mit fast absoluter Sicherheit nicht wünschenswert ist. Durch Festlegen einer OWNER RIGHTS-SID für derartige Objekte kann das Betriebssystem verhindern, dass andere Dienste auf sie zugreifen.

Standard-ACLs
Die Standard-ACLs von Windows XP waren eigentlich recht gut. Abgesehen von einigen kleineren Problemen (z. B., dass sie den Benutzern erlaubten, Dateien im Stammverzeichnis des Startvolumes abzulegen) arbeiteten sie sehr vernünftig. Einige OEMs haben jedoch offenbar entschieden, dass sie besser wissen, wie Sicherheit vernünftigerweise auszusehen hat. Der Bildschirm in Abbildung 4 zeigt die ACL für das Windows-Verzeichnis eines Computers, auf dem von einem wichtigen OEM Windows XP Media Center Edition ausgeführt wird. Der OEM hat die Dateisystemsicherheit praktisch völlig deaktiviert.
Abbildung 4 Eine vom OEM konfigurierte ACL.
Abbildung 4 Eine vom OEM konfigurierte ACL.
Microsoft hat in Windows Vista einige Anpassungen an ACLs vorgenommen. Wenn Sie an Windows XP gewöhnt sind, wissen Sie, dass die ADMINISTRATOREN-Gruppe der Besitzer aller Betriebssystemdateien ist und dass die Administratoren die volle Kontrolle über diese Dateien haben. Als Mitglied dieser Gruppe hatten Sie folglich uneingeschränkten Zugriff auf diese Dateien. Dies ist in Windows Vista nicht der Fall.
Vertrauenswürdiges Installationsprogramm In Windows Vista ist der Besitzer der meisten Betriebssystemdateien die TrustedInstaller-SID, und nur diese SID verfügt über vollständige Kontrolle über diese Dateien. Dies ist Teil der Systemintegritätsmaßnahmen, die in Windows Vista eingeflossen sind, und dient speziell dazu, zu verhindern, dass die Dateien von einem als Administrator oder als „Lokales System“ ausgeführten Prozess automatisch ersetzt werden. Um eine Betriebssystemdatei zu löschen, müssen Sie daher Besitzer der betreffenden Datei werden und danach einen ACE für die Datei hinzufügen, der es Ihnen erlaubt, die Datei zu löschen. Dies bietet eine dünne Schutzschicht gegen einen Prozess, der als „Lokales System“ ausgeführt wird und ein Systemintegritätslabel besitzt. Ein Prozess mit einer niedrigeren Integrität soll nicht in der Lage sein, seine Integrität selbst zu erweitern, um die Besitzrechte ändern zu können. Einige Dienste können beispielsweise mit mittlerer Integrität ausgeführt werden, obwohl sie als „Lokales System“ ausgeführt werden. Da solche Dienste keine Systemdateien ersetzen können, kann es nicht passieren, dass durch Ausnutzung eines solchen Diensts Betriebssystemdateien ersetzt werden, wodurch es etwas schwerer wird, auf dem System ein Rootkit oder andere böswillige Programme zu installieren. Dies erschwert es auch für Systemadministratoren, die sich durch die Anwesenheit einer Systembinärdatei gestört fühlen, diese Binärdatei zu entfernen.
Verweigern-ACEs Sie werden feststellen, dass viele Objekte im Dateisystem Verweigern-ACEs für die Gruppe „ALLE“ besitzen, was unter Administratoren viel Unruhe ausgelöst hat. Wenn Sie die Option „Versteckte Dateien anzeigen“ aktivieren, sehen Sie das vertraute Verzeichnis „Dokumente und Einstellungen“. Wenn Sie darauf klicken, wird jedoch die Fehlermeldung „Zugriff verweigert“ ausgegeben. Damit Sie verstehen, was es mit „Dokumente und Einstellungen“ auf sich hat, sehen Sie sich die Verzeichnisliste in Abbildung 5 an.
Abbildung 5 „Dokumente und Einstellungen“ ist kein Verzeichnis, sondern ein Verknüpfungspunkt.
Abbildung 5 „Dokumente und Einstellungen“ ist kein Verzeichnis, sondern ein Verknüpfungspunkt.
„Dokumente und Einstellungen“ ist in Wirklichkeit gar kein Verzeichnis, sondern ein Verknüpfungspunkt! Denken Sie daran, dass Verknüpfungspunkte symbolischen Links ähneln, die ganz einfach zur Umleitung des Zugriffs dienen. In diesem Fall wird zu einem Verzeichnis namens „C:\Benutzer“ umgeleitet. Microsoft hat den Dateisystemnamespace in Windows Vista beträchtlich geändert und die Benutzerdaten in das Verzeichnis „C:\Benutzer“ verschoben. Andere Elemente unter dem früheren Namespace „C:\Dokumente und Einstellungen\<Benutzername>“ wurden ebenfalls verschoben. So wurde beispielsweise „C:\Dokumente und Einstellungen\<Benutzername>\Anwendungsdaten“ in das Verzeichnis „C:\Benutzer\<Benutzername>\appdata\roaming“ verschoben. Sie können diese Änderungen ganz deutlich erkennen, wenn Sie zu einer Befehlszeile wechseln und den Befehl „dir /a“ eingeben, wie das in Abbildung 5 erfolgt ist. Der Grund, aus dem der Namespace so drastisch geändert wurde, besteht darin, ihn für Benutzer verständlicher zu machen und Dokumente und Daten sauberer voneinander zu trennen. Statt alle Dateien unter dem Ordner „Eigene Dateien“ zu speichern, können Entwickler jetzt unter dem Profil des Benutzers ihre eigenen Ordner anlegen, die der Benutzer dort sehen kann. Anwendungsdaten für alle Benutzer kommen jetzt in einen ausgeblendeten Ordner namens „%systemroot%\ProgramData“, statt unter „Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten“ abgelegt zu werden.
Microsoft hat den Namespace „C:\Dokumente und Einstellungen“ nicht entfernt, weil in älteren Anwendungen möglicherweise dieser Name anstelle der bevorzugten Umgebungsvariablen wie %USERPROFILE% im Code verwendet wird. Diese Anwendungen würden blockieren, wenn „C:\Dokumente und Einstellungen“ nicht mehr vorhanden wäre. Stattdessen wird dieses Verzeichnis jetzt durch Verknüpfungspunkte oder so genannte „symlinks“ vertreten, um die Abwärtskompatibilität sicherzustellen. Anwendungen, in denen diese Pfade fest kodiert sind, können abhängig davon, wie sie auf die darin enthaltenen Daten zugreifen, weiterhin blockieren, aber diese Anwendungen blockieren bereits in Windows-Versionen anderer Sprachen als Englisch. Und dies ist ein wirklich wichtiger Punkt. Wenn eine Aktualisierung für Windows, z. B. Windows XP SP2 oder Windows Vista, dazu führt, dass Drittanbieterprogramme blockieren, liegt es fast immer daran, dass die Entwickler dieser Programme unzulässige Annahmen vorausgesetzt oder Windows auf eine unzulässige Weise verwendet haben.
Wenn Sie beispielsweise versuchen, eine Datei zu öffnen, indem Sie „C:\Dokumente und Einstellungen\<Benutzername>\Eigene Dateien\foo.txt“ eingeben, dann funktioniert dies, vorausgesetzt, dass sich an diesem Speicherort eine Datei namens „foo.txt“ befindet. Wenn Sie jedoch versuchen, zu „C:\Dokumente und Einstellungen\<Benutzername>\Eigene Dateien“ zu navigieren, erhalten Sie die Fehlermeldung „Zugriff verweigert“. Sehen Sie sich zur Klarstellung die ACL in Abbildung 6 an.
Abbildung 6 Es existiert ein Verweigern-ACE für „Dokumente und Einstellungen“.
Abbildung 6 Es existiert ein Verweigern-ACE für „Dokumente und Einstellungen“.
Betrachten Sie den ersten ACE in der Liste. Es handelt sich um einen Verweigern-ACE für die Gruppe „ALLE“ zum Auflisten der Ordnerinhalte. Programme können die Verknüpfungspunkte und offenen Dokumente mit absoluten Pfaden durchlaufen, weil die Gruppe „ALLE“ über die Berechtigung zum Umgehen der Traversierungsüberprüfung (auch unter dem Namen „SeChangeNotifyPrivilege“ bekannt) verfügt. Die Versuche eines Benutzers oder eines Prozesses, die von ihnen repräsentierten Verzeichnisse aufzuzählen, schlagen aufgrund des Verweigern-ACEs fehl. Aus diesem Grund kann der Benutzer weder tatsächlich sehen, was in „C:\Dokumente und Einstellungen“ enthalten ist, noch dieses „Verzeichnis“ löschen. Dieser Verweigern-ACE soll Benutzer in erster Linie daran hindern, die Verknüpfung zu löschen und ältere Anwendungen zu blockieren. Darüber hinaus soll er Entwickler daran erinnern, keine Anwendungen zu programmieren, die den alten Namespace verwenden, sondern stattdessen Umgebungsvariablen oder Registrierungszeichenfolgen zu verwenden, um eine Anwendung vor zukünftigen Änderungen und Sprachunterschieden zu isolieren.
Beachten Sie, dass alle diese Verknüpfungspunkte standardmäßig ausgeblendet sind und von den meisten Benutzern nie gesehen werden. Um ein Löschen der sichtbaren Verknüpfungspunkte zu verhindern, hat Microsoft einen Verweigern-ACE für „Ordner auflisten“ eingefügt.
Traversierungsüberprüfung umgehen Der Grund, weshalb Benutzer auf Dateien, für die sie Rechte haben, innerhalb von Ordnern (oder Verknüpfungspunkten) zugreifen können, für die sie keine Rechte haben, liegt darin, dass jeder über die Berechtigung „Traversierungsüberprüfung umgehen“ verfügt. Die Berechtigung „Traversierungsüberprüfung umgehen“ (oder SeChangeNotifyPrivilege) ist die grundlegendste Berechtigung in Windows und wird einem Prozess gewährt, bei dem alle anderen Berechtigungen entfernt wurden, es sei denn, der Prozess verlangt ausdrücklich, dass diese Berechtigung ebenfalls entfernt wird. Dies geschieht, wenn ein Prozess in Windows Vista mithilfe der Zeile „runas /trustlevel:0x10000“ < gestartet wird. Das durch <command> angegebene Programm wird mit einem beschränkten Token ausgeführt und alle Berechtigungen außer SeChangeNotifyPrivilege werden aus dem Prozesstoken entfernt.
Interessanterweise erhalten Sie durch trustlevel 0x20000 ein Token mit dem normalen Satz von SIDs, aber ohne Berechtigungen. Mit 0x40000 erhalten Sie ein völlig normales Token.

Standardberechtigungen
Die Standardberechtigungen für das Dateisystem haben sich in Windows Vista im Vergleich zu Windows XP geringfügig geändert. Wenn Sie die ACL für „%systemdrive%“ (normalerweise das Startvolume C:) in Windows XP oder Windows Server® 2003 betrachten, sehen Sie Folgendes (oder bei sehr frühen Versionen von Windows XP etwas sehr Ähnliches):
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Hier ist dieselbe ACL für dasselbe Verzeichnis in Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Es gibt eine Reihe wichtiger Unterschiede. Zunächst gibt es statt nur einem ACE jetzt zwei ACEs für BA (BUILTIN\Administrators). Das Endergebnis ist jedoch dasselbe. Ein ACE wird in Windows Vista nicht geerbt und gewährt vollen Zugriff auf das Stammverzeichnis und ein ACE ist ein IO (Inherit-Only, nur vererben)-ACE, der von Containern und Objekten geerbt wird und GA (Generic All, volle Kontrolle) gewährt. Dasselbe gilt für die Ersetzung des einzelnen ACEs für SY (LocalSystem) durch zwei ACEs in Windows Vista. In Windows XP hat der einzelne ACE vollen Zugriff gewährt und wurde von Objekten und Containern geerbt. Auch hier ist das Endergebnis dasselbe. Der Hauptgrund für die Änderung der ACL besteht darin, dass die Berechtigungen verdeutlicht und abgetrennt werden sollen, damit die ACL leichter verwaltet und möglicherweise sogar leichter wiederhergestellt werden kann.
Noch interessanter ist es, dass der ACE für CO (Creator/Owner, Ersteller/Besitzer) nicht mehr vorhanden ist. Wenn ein Benutzer also ein Objekt im Stammverzeichnis des Dateisystems erstellt, werden dem Ersteller nicht mehr besondere Berechtigungen erteilt.
Außerdem fällt auf, dass der ACE für WD (ALLE) entfernt wurde. Viele Leute, die sich für Sicherheit interessierten, die Implikationen ihrer Aktionen aber nicht völlig verstanden, waren wegen dieses ACEs grundlos besorgt. Microsoft hat jahrelang vergeblich zu erklären versucht, dass die Gruppe „ALLE“ funktional mit integrierten Benutzern praktisch identisch ist, aber am Ende diesen ACE dann doch ganz entfernt. Da es einen identischen ACE für BU (BUILTIN\Users) gibt, der ebenfalls sowohl von Containern als auch von Objekten geerbt wird, hat sich am Endergebnis im Grunde nichts geändert.
Darüber hinaus wurden zwei der ACEs für BU (integrierte Benutzer) durch ACEs für AU (authentifizierte Benutzer) ersetzt. Der Grund dafür ist, dass das Gastkonto ein Mitglied der integrierten Benutzer ist (weil INTERACTIVE ein Mitglied der integrierten Benutzer ist), GAST aber kein Mitglied der authentifizierten Benutzer ist. Um dem Gastkonto zu ermöglichen, Dateien zu lesen und auszuführen, wird dem BU weiterhin der ACE 0x1200a9 (praktisch gleichbedeutend mit Lesen und Ausführen) gewährt. Die ACEs dagegen, die Berechtigungen zum Erstellen von Dateien und Ordnern gewähren, werden authentifizierten Benutzern zugewiesen. Hier endet die Ähnlichkeit mit Windows XP. In Windows XP konnte ein GAST Dateien im Stammverzeichnis erstellen. In Windows Vista kann ein GAST solche Dateien nicht erstellen. Bedenken Sie jedoch, dass dies alles völlig irrelevant ist, es sei denn, das Gastkonto wird aktiviert und Gästen gelingt es, auf das Stammverzeichnis des Startvolumes zuzugreifen. Standardmäßig ist das Gastkonto deaktiviert.
Das Beste habe ich für den Schluss aufgehoben: In den beiden oben stehenden Listen sind ein paar sehr interessante und scheinbar problematische ACEs enthalten. In Windows XP gibt es einen ACE, der von Containern geerbt wird und für integrierte Benutzer 0x100004 lautet. Dieser ACE gewährt Benutzern das Recht, Unterordner, Unterordner von Unterordnern und so weiter zu erstellen, da er von Containern geerbt wird. Es gibt auch einen IO (Inherit-Only, nur vererben)-ACE, der von Unterordnern geerbt wird und 0x100002 lautet. Dieser ACE gewährt Benutzern das Recht, in Ordnern, die sie unterhalb des Stammverzeichnisses anlegen, Dateien und Unterordner zu erstellen. Anders ausgedrückt: diese beiden ACEs erlauben den Benutzern (einschließlich Gästen), Dateien und Ordner unter dem Stammverzeichnis zu erstellen, wie bereits weiter oben erwähnt.
In Windows Vista handelt es sich bei den entsprechenden ACEs um einen IO (Inherit-Only, nur vererben)-ACE, der sowohl von Containern als auch von Dateien geerbt wird und GR (Generic Read), GX (Generic Execute), GW (Generic Write) und SD (Read Security Descriptor) gewährt, sowie einen ACE, der nur für das Stammverzeichnis selbst gilt und die LC-Berechtigung gewährt. LC ist ein Begriff, der sich auf ACEs in Active Directory® bezieht. In Active Directory bedeutet LC, dass ein Benutzer untergeordnete Objekte auflisten kann. Der Hexadezimalwert von LC ist jedoch 0x4. 0x4 bedeutet für ein Verzeichnis FILE_ ADD_SUBDIRECTORY und ist in funktionaler Hinsicht praktisch gleichbedeutend mit 0x100004, da mit dem ACE 0x1200a9 bereits 0x100000 (die Möglichkeit, das Objekt zur Synchronisierung zu verwenden) vorliegt. Anders ausgedrückt, hat dies denselben Effekt wie in Windows XP: Benutzer können Unterverzeichnisse unter dem Stammverzeichnis erstellen.
Woher kommen die Hexadezimalwerte? Und was sind Hexadezimalwerte überhaupt? Wie Sie mittlerweile bemerkt haben, kommen in der Zugriffssteuerung ständig Hexadezimalzahlen (Zahlen mit der Basis 16) wie beispielsweise 0x1200a9 vor. Dabei handelt es sich um Bitmaskenrepräsentationen von Bits in einer Zugriffsmaske, die auf „on“ gesetzt sind, was bedeutet, dass sie im betreffenden ACE verwendet werden. Wenn Sie ein Tool wie icacls, sc oder secedit zum Auflisten einer ACL verwenden, werden die Bitmasken durch wesentlich leichter verständliche Textzeichenfolgen repräsentiert, sofern eine 1:1-Entsprechung vorliegt.
Um herauszufinden, was LC bedeutet, müssen Sie daher lediglich zur MSDN®-Website wechseln, die Zeichenfolge „LC“ suchen und in der Spalte der Zugriffsrechtswerte nach „ADS_RIGHT_ACTRL_DS_LIST“ suchen. Wenn Sie danach die Headerdatei „lads.h“ öffnen und nach dieser Zeichenfolge suchen, werden Sie feststellen, dass sie 0x4 entspricht. Bei Nicht-Active Directory-Zeichenfolgen (Zeichenfolgen, die nicht mit „ADS_RIGHT“ beginnen) finden Sie den Hexadezimalwert stattdessen normalerweise in der Datei „AccCtrl.h“. Wenn Sie den Hexadezimalwert erst einmal ermittelt haben, ist es ganz einfach, ihn in der Datei „WinNt.h“ oder „AccCtrl.h“ nachzuschlagen, um herauszufinden, was er bedeutet.
Wenn Sie dabei Hilfe benötigen, sollten Sie sich eine Ausgabe des Buchs „Protect Your Windows Network“ (von Jesper Johansson und Steve Riley, Addison-Wesley, 2005) besorgen. Darin wird in Kapitel 17 ausführlich darauf eingegangen, wie SDDL (Security Description Definition Language)-Zeichenfolgen und ACEs analysiert werden.
Die für diese Unterverzeichnisse gewährten Berechtigungen werden in Windows Vista ausschließlich vom (A;OICIIO;SDGXGWGR;;;AU)-ACE bestimmt, was den größten Unterschied zwischen Windows Vista und Windows XP ausmacht. Statt wie in Windows XP dem Ersteller von Unterverzeichnissen volle Kontrolle zu gewähren, gewährt Windows Vista authentifizierten Benutzern Änderungsberechtigungen.
Das Gesamtresultat dieser neuen ACL besteht darin, dass der Ersteller eines Objekts nicht mehr über Sonderrechte verfügt und die Dinge ein wenig klarer sind. Die vielleicht größte Änderung ist die, dass authentifizierte Benutzer sogar für Unterordner, die von Administratoren erstellt wurden, über Änderungsberechtigungen verfügen, was einen großen Unterschied zu Windows XP darstellt. In Windows XP haben Benutzer und authentifizierte Benutzer keine Rechte für Objekte, die von Administratoren unter dem Stammverzeichnis erstellt wurden. Obwohl diese ACEs auf den ersten Blick problematisch zu sein scheinen, unterscheiden sie sich in ihrer Wirkung nicht allzu sehr von der Arbeitsweise von Windows XP.
Zusammenfassend gesagt, kann in Windows Vista jeder (einschließlich des Gastbenutzers) Dateien, die sich im Stammverzeichnis befinden, lesen und ausführen. Nur authentifizierte Benutzer können neue Dateien und Ordner erstellen, und wenn Benutzer dies tun, erhalten sie Änderungsberechtigungen für diese Dateien und Ordner. Die Berechtigungen in Windows Vista sind also geringfügig strenger gefasst als in Windows XP, es sollte jedoch darauf hingewiesen werden, dass das Gastkonto standardmäßig deaktiviert ist.

Änderungen an Tokens
Wenn sich ein Benutzer anmeldet, der in Windows XP Mitglied der Gruppe „ADMINISTRATOREN“ ist, enthält sein Token die SID der Gruppe „ADMINISTRATOREN“, und er kann alles ausführen, was die Gruppe „ADMINISTRATOREN“ kann. In Windows Vista dagegen ist dies aufgrund der Benutzerkontensteuerung nicht mehr der Fall. Die Administratoren-SID ist zwar noch immer im Token enthalten, aber sie ist auf „DENY ONLY“ gesetzt, wie der Screenshot aus dem Process Explorer in Abbildung 7 zeigt.
Abbildung 7 Unter UAC wird die Administratoren-SID nur zum Verweigern des Zugriffs verwendet, es sei denn, sie wird von Ihnen erweitert.
Abbildung 7 Unter UAC wird die Administratoren-SID nur zum Verweigern des Zugriffs verwendet, es sei denn, sie wird von Ihnen erweitert.
Beim Durchführen von Zugriffssteuerung wird ein derartiger Eintrag im Token nur zum Verweigern eines Zugriffs verwendet und entspricht somit der Funktion von Verweigern-ACEs. Alle Zulassen-ACEs für diese SID werden ignoriert. Dies bedeutet, dass Sie nicht immer ein echter Administrator sind, auch wenn Sie sich als Administrator beim System anmelden.

Integritätsebenen
Windows unterstützt jetzt das Kennzeichnen von Prozessen und Objekten mit Integritätsebenen. Diese Integritätsebenen werden ebenfalls als ACEs repräsentiert, aber nicht in der DACL. Stattdessen sind sie Bestandteil der Systemzugriffssteuerungsliste (System Access Control List, SACL) und besitzen einige spezielle Flags. So wird beispielsweise das Flag NW verwendet, um anzugeben, dass ein Prozess auf einer niedrigeren Integritätsebene daran gehindert wird, in ein Objekt einer höheren Integritätsstufe zu schreiben (SDDL_NO_WRITE_UP). Mark Russinovich geht in seinem Artikel „Die Benutzerkontensteuerung von Windows Vista“ in dieser Ausgabe des TechNet Magazins ausführlicher auf dieses Thema ein.

Zusammenfassung
In Windows Vista wurde zwar keine einzige gravierende Änderung an der Zugriffssteuerung vorgenommen, wie dies bei Windows 2000 der Fall war, dafür sind zahlreiche kleinere Änderungen zu finden. Einzeln betrachtet, ist keine dieser Änderungen besonders krass. In ihrer Gesamtheit bedeuten sie aber, dass Sie die Verwaltung Ihres Systems ganz neu durchdenken müssen. Darüber hinaus unterstützen diese Änderungen eine Reihe anderer Initiativen, insbesondere die UAC und die Diensthärtung. Manche Administratoren sind zunächst sehr frustriert, wenn sie Windows Vista anfänglich verwenden. Ich habe bereits Kommentare wie „tyrannisches Betriebssystem“ gehört, da die Möglichkeit eingeschränkt wird, unerwünschte Teile des Systems zu löschen. Dennoch wurden alle Änderungen aus triftigen Gründen vorgenommen, deren Sinn bei einer genaueren Analyse des Systems offensichtlich wird.

Jesper Johansson arbeitet als Sicherheitsarchitekt für ein großes E-Commerce-Unternehmen, in dem er für Anwendungssicherheitsstrategie im Bereich Eigenschaften und Dienste zuständig ist. Er ist seit 20 Jahren im Bereich Sicherheit tätig und Autor von zahlreichen Artikeln und zwei Büchern über dieses Thema. Wenn er sich nicht gerade mit IT-Sicherheit beschäftigt, unterrichtet er Sporttauchen.


 Sicherheit: Verwalten von Hardwareeinschr&#228;nkungen &#252;ber Gruppenrichtlinien
Sicherheit Jeremy Moskowitz

Verwalten von Hardwareeinschränkungen über Gruppenrichtlinien
Kurz zusammengefasst:
  • Einschränken von Hardwareinstallationen
  • Einschränken bestimmter Geräte
  • Einschränken von Geräteklassen

Tatsache ist: USB-Sticks und Wechselmedien bieten privat viele Vorteile, erschweren jedoch das Arbeitsleben. Sie müssen kontrollieren können,
welche Hardwaregeräte installiert werden können und welche nicht. Erfreulicherweise haben Sie mit der Gruppenrichtlinie in Windows Vista™ und der nächsten Version von Windows Server® mit dem Codenamen „Longhorn“ die Option, USB-Mäuse zuzulassen, aber die Verwendung von USB-Sticks zu unterbinden, CD-ROM-Lesegeräte zuzulassen, aber DVD-Schreibgeräte zu unterbinden, oder Bluetooth zuzulassen, aber PCMCIA zu unterbinden.
Zwei Abschnitte in der Gruppenrichtlinie können Ihnen beim Sichern Ihrer Hardware behilflich sein: Computerkonfiguration | Administrative Vorlagen | System | Wechselmedienzugriff (siehe Abbildung 1) und Computerkonfiguration | Administrative Vorlagen | System | Geräteinstallation | Einschränkungen bei der Geräteinstallation (siehe Abbildung 2).
Abbildung 1 Vordefinierte Hardwareeinschränkungen in der Gruppenrichtlinie
Abbildung 1 Vordefinierte Hardwareeinschränkungen in der Gruppenrichtlinie
Abbildung 2 Anpassen der einzuschränkenden Hardwaretypen
Abbildung 2 Anpassen der einzuschränkenden Hardwaretypen
Der erste Abschnitt (Wechselmedienzugriff) erklärt sich praktisch von selbst: Wenn Sie eine Richtlinie für diese Art von Wechselmedien aktivieren (CD/DVD, Diskette usw.), können Sie das Lesen bzw. Schreiben nach Wunsch auf den gesamten Gerätetyp einschränken. Diese Funktion bietet jedoch keine so umfassende Leistung wie die Einschränkungen bei der Geräteinstallation.
Unter Wechselmedienzugriff gibt es die beiden Richtlinieneinstellungsgruppen „Benutzerdefinierte Klassen: Lesezugriff verweigern“ und „Benutzerdefinierte Klassen: Schreibzugriff verweigern“. Das klingt zwar gut, doch die Richtlinie „Wechselmedienzugriff“ verhindert im Grunde nicht, dass die Treiber installiert werden. Der Treiber für die Klasse ist bereits installiert, wenn die Hardware erkannt wird. Die Richtlinie verhindert einen Lese- oder Schreibvorgang auf dem Treiber. Im nächsten Abschnitt, in dem die Richtlinieneinstellungen für die Geräteinstallationseinschränkungen behandelt werden, wird die Verwendung des gesamten Treibers an sich gesperrt.

Abrufen eines Handles für Klassen und IDs
Zunächst einmal gilt: Sie müssen wissen, was Sie einschränken wollen. Sie können dies im Großen oder im Kleinen angehen. Das heißt, Sie können eine bestimmte „Klasse“ von Geräten einschränken oder sehr spezifisch vorgehen und einen einzigen Hardwaretyp einschränken. Umgekehrt können Sie beispielsweise lediglich bestimmte Geräteklassen, wie USB-Mäuse, zulassen. Hier ist der Trick dabei: Für eine wirklich effektive Vorgehensweise müssen Sie die einzuschränkende Hardware finden.
Wenn Sie also festlegen wollen, dass keine Joysticktreiber und nur USB-Mäuse installiert werden können, müssen ein Joystick und eine USB-Maus vorliegen. Die Alternative besteht darin, entweder die Hardware-ID, die kompatible ID oder die Geräteklasse über das Internet zu ermitteln. Es ist jedoch viel leichter, wenn Sie eines der entsprechenden Geräte vor Augen haben. So können Sie es an Ihren Computer anschließen und die Hardware-ID, die kompatible ID oder die Geräteklasse selbst feststellen. Wenn diese Informationen vorliegen, ist es einfach, Geräte einzuschränken oder zuzulassen.
Im folgenden Beispiel wird die Verwendung einer bestimmten Soundkartenfamilie unterbunden: Creative AutoPCI ES1371/ES1373. Wenn Sie andere Geräte einschränken möchten (z. B. bestimmte USB-Geräte, USB-Anschlüsse usw.), müssen Sie die folgenden Schritte einfach nur auf das entsprechende Gerät anwenden.
Starten Sie den Geräte-Manager auf einem Computer, auf dem bereits die Hardwareelemente installiert sind. Navigieren Sie zum gewünschten Gerät, klicken Sie mit der rechten Maustaste darauf, und wählen Sie „Eigenschaften“ und anschließend die Registerkarte „Details“ aus. Standardmäßig wird eine „Gerätebeschreibung“ angezeigt. Dies ist zwar interessant, aber nicht sehr hilfreich. Wählen Sie die Dropdownliste „Eigenschaften“ aus, und wählen Sie „Hardware-IDs“ aus, wie in Abbildung 3 dargestellt.
Abbildung 3 Die Registerkarte „Details“ des Geräts
Abbildung 3 Die Registerkarte „Details“ des Geräts
Auf der Seite „Hardware-IDs“ werden in absteigender Reihenfolge die spezifischsten bis hin zu den unspezifischsten Geräte-IDs angezeigt. Wenn Sie das oberste Element in der Liste der Hardware-IDs betrachten, sehen Sie, dass diese Soundkarte eine spezielle Rev 2 der ES1371-Soundkarte ist. Spezifischer geht es kaum mehr. Je weiter Sie in der Liste nach unten gehen, umso unspezifischer wird die Beschreibung, um die ganze Familie einzuschließen.
Außerdem können Sie die Eigenschaft auf kompatible IDs setzen. Diese beschreiben ebenfalls die Hardware und sind weniger spezifisch als das, was in Hardware-IDs zu finden ist. Sie könnten die Informationen in den kompatiblen IDs dazu verwenden, weitere ähnliche Hardware zu ermitteln und sie in die Liste der nicht zu verwendenden Elemente einzufügen. Diese Informationen sind nämlich weniger spezifisch und erzielen eventuell bessere Ergebnisse. Der Nachteil dabei ist natürlich, dass es zu unbeabsichtigten Einschränkungen kommen könnte.
Die am wenigsten spezifische Kategorie lässt sich durch Auswählen der Geräteklasse in der Dropdownliste „Eigenschaft“ ermitteln. In meinem Fall erscheint die Soundkarte einfach als Medien. Viele verschiedene Elemente können jedoch als Medien angesehen werden. Und auch hier gilt, je unspezifischer das Ganze wird, desto vorsichtiger müssen Sie vorgehen.
Wenn Sie sich für einen Wert entschieden haben, klicken Sie mit der rechten Maustaste darauf, wählen Sie „Kopieren“ aus, und fügen Sie den Wert zur sicheren Verwahrung in Editor ein. Es ist wichtig, den Wert genau zu kopieren, da er in den nächsten Schritten genau eingegeben werden muss. Die Groß- und Kleinschreibung aller Zeichen im Wert muss korrekt übertragen werden.
Wenn Sie statt des Geräte-Managers einen Befehl über die Befehlszeile verwenden wollen, um die Hardware-IDs oder Geräteklassen zu erfassen, werfen Sie einen Blick auf das Devcon-Befehlszeilen-Dienstprogramm unter support.microsoft.com/kb/311272. Beachten Sie, dass Microsoft eine Anzahl von Kennungen für gemeinsame Klassen hat, die hilfreich sein können, wenn Sie keinen physischen Zugriff auf das Gerät haben. Weitere Informationen finden Sie unter go.microsoft.com/fwlink/?LinkId=52665.

Hardwarezugriffssteuerung über die Gruppenrichtlinie
Im Folgenden werden zwar alle Richtlinieneinstellungen untersucht, die sich unter Computerkonfiguration | Administrative Vorlagen | System | Geräteinstallation | Einschränkungen bei der Geräteinstallation (siehe Abbildung 2) befinden, doch um das anfängliche Beispiel abzuschließen, ist lediglich eine Richtlinieneinstellung erforderlich.
Erstellen Sie zunächst ein Gruppenrichtlinienobjekt (Group Policy Object, GPO), und verknüpfen Sie es mit einer Organisationseinheit (oder Domäne usw.), die die Computer unter Windows Vista enthält, die Sie kontrollieren wollen. Bearbeiten Sie jetzt das GPO, und navigieren Sie zu Computerkonfiguration | Administrative Vorlagen | System | Geräteinstallation | Einschränkungen bei der Geräteinstallation | Installation von Geräten mit diesen Geräte-IDs verhindern. Wählen Sie in der Richtlinieneinstellung die Option „Aktiviert“ aus, klicken Sie auf „Anzeigen“ (ebenfalls in der Richtlinieneinstellung), und wählen Sie im Dialogfeld „Inhalt anzeigen“ die Option „Hinzufügen“ aus. Fügen Sie anschließend im Dialogfeld „Element hinzufügen“ die zuvor gespeicherten Geräteinformationen ein, wie in Abbildung 4 dargestellt.
Abbildung 4 Einfügen der Geräte-ID zur genauen Erfassung der Beschreibung
Abbildung 4 Einfügen der Geräte-ID zur genauen Erfassung der Beschreibung
Hierbei gibt es allerdings einen Haken. Wenn das Gerät bereits auf einem Computer installiert ist, deinstalliert der Computer es nicht ohne weiteres und schränkt auch den Zugriff nicht ein. Wenn Sie also Hardware einschränken wollen, muss dies frühzeitig in der Windows Vista-Bereitstellung erfolgen. Beachten Sie jedoch, dass Windows Vista dies jedes Mal, wenn ein Gerät entfernt und wieder neu installiert wird, nachkontrolliert. Elemente, wie USB-Sticks (die entfernt und später wieder eingesetzt werden), eignen sich deshalb hervorragend für diesen Prozess. Da Windows Vista nur dann nachkontrolliert, wenn das Gerät wieder eingeführt wird, wird das Gerät zu der Zeit eingeschränkt (selbst wenn der Gerätetreiber anfänglich auf dem Computer geladen wurde). Schwieriger wird es bei Geräten, die mit einem Computer geliefert werden und somit nicht entfernt und wieder eingeführt werden. Für diese Geräte gibt es keine sofort erkennbare Lösung.
Wenn Sie einen Computer einschalten, der ein Hardwaregerät zum ersten Mal erkennt, versucht Windows, den Treiber zu installieren, und stellt die laufenden Statusinformationen bereit. Wenn Sie eine Richtlinie festgelegt haben, um das Gerät einzuschränken, sieht das Ergebnis wie in Abbildung 5 aus.
Abbildung 5 Eine Geräteinstallation, die verhindert wird
Abbildung 5 Eine Geräteinstallation, die verhindert wird

Weitere Hardwareeinschränkungen
Im Beispiel oben wurde nur ein Gerät nicht zugelassen. Auf Wunsch könnten Sie auch umgekehrt vorgehen und alle Hardware standardmäßig einschränken, um dann nur bestimmte Hardware zuzulassen. Die Liste für diese Richtlinieneinstellungen sehen Sie in Abbildung 2, in der der folgende Zweig der Gruppenrichtlinie dargestellt wird: Computerkonfiguration | Administrative Vorlagen | System | Geräteinstallation | Einschränkungen bei der Geräteinstallation. Sie können aus einer Reihe verfügbarer Einstellungen auswählen.
Zunächst einmal gibt es die Einstellung „Administratoren das Außerkraftsetzen der Richtlinien unter "Einschränkungen bei der Geräteinstallation" erlauben“. Standardmäßig müssen lokale Administratoren, die unter Windows Vista arbeiten, die eingerichteten Einschränkungen beachten. Wenn Sie diese Einstellung aktivieren, können lokale Administratoren die Einschränkung außer Kraft setzen und beliebige Hardware installieren.
Als Nächstes gibt es die Einstellung „Installation von Geräten mit Treibern zulassen, die diesen Gerätesetupklassen entsprechen“. Durch Eingabe der Gerätebeschreibungen in dieser Richtlinieneinstellung erlauben Sie ausdrücklich, dass die Hardwaregeräte auf dem System installiert werden können. Beachten Sie, dass diese Richtlinieneinstellung nur Setupklassen berücksichtigt, nicht Geräte-IDs (wie die im Beispiel verwendeten).
Um die gegenteilige Wirkung zu erzielen, können Sie die Einstellung „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“ festlegen.
Die beiden Einstellungen „Benutzerdefinierte Meldung anzeigen, wenn Installation durch eine Richtlinie verhindert wird (Hinweistext)“ und „Benutzerdefinierte Meldung anzeigen, wenn Installation durch eine Richtlinie verhindert wird (Hinweistitel)“ unterstützen Sie beim Anpassen der Meldung (siehe Abbildung 5).
Wie bereits erwähnt, lässt sich Hardware am unspezifischsten über die Hardwareklasse beschreiben. Beachten Sie dabei, dass die Richtlinie „Installation von Geräten mit diesen Geräte-IDs zulassen“ die Klassen-ID-Beschreibungen nicht berücksichtigt. Für Klassen-ID-Beschreibungen müssen Sie entweder „Installation von Geräten mit Treibern zulassen, die diesen Gerätesetupklassen entsprechen“ oder „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“ verwenden. Letzteres wird am besten mit der Richtlinieneinstellung „Installation von Geräten verhindern, die nicht in anderen Richtlinien beschrieben sind“ verwendet. Wenn alles verhindert (Standardeinstellung) und dann diese Einstellung verwendet wird, können Sie genau festlegen, welche Geräte Sie zulassen wollen.
Im Beispiel wurde die Richtlinie „Installation von Geräten mit diesen Geräte-IDs verhindern“ verwendet, um aufgrund der Geräte-IDs einen bestimmten Hardwaretyp einzuschränken. Wenn Sie Einschränkungen mithilfe von Geräteklassen implementieren wollten, müssten Sie andere spezifische Richtlinieneinstellungen, wie „Installation von Geräten mit Treibern zulassen, die diesen Gerätesetupklassen entsprechen“ oder „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“, einsetzen.
„Installation von Wechselgeräten verhindern“ ist eine schnelle, generische Möglichkeit, um ein beliebiges Hardwaregerät einzuschränken, das als Wechselmedium gilt. Dazu gehören auch USB-Geräte. Diese Einstellung ist sehr allgemein. Deshalb ist es ratsam, sie nicht zu oft zu verwenden. Verwenden Sie stattdessen die weiter oben beschriebenen Verfahren, mit denen Sie mäßig beschränkte Geräte-IDS erhalten und dann spezifisch sperren.
Schließlich stellt „Installation von Geräten verhindern, die nicht in anderen Richtlinien beschrieben sind“ die umfassende Richtlinie dar, mit der die gesamte Hardware eingeschränkt wird, es sei denn, Sie haben eine Installation ausdrücklich zugelassen. In Verbindung mit den verschiedenen Zulassungsrichtlinien (z. B. „Installation von Geräten mit diesen Geräte-IDs zulassen“) bietet diese Richtlinie ein wirklich leistungsfähiges Tool, mit dem nur die in Ihrer Umgebung gewünschte Hardware zugelassen wird.

Schlussbemerkung
Die Gruppenrichtlinie in Windows Vista verfügt über eine Reihe neuer, extrem leistungsfähiger Funktionen, mit denen in Ihrer Umgebung nur bestimmte Hardware zulassen werden kann. Achten Sie nur darauf, dass Sie die Richtlinieneinstellungen frühzeitig im Bereitstellungsvorgang installieren, damit die auf dem Netzwerk unerwünschte Hardware erst gar nicht die Möglichkeit erhält, eine Verbindung herzustellen.
Interview mit Michael Dennis, dem leitenden Microsoft-Programmmanager für Gruppenrichtlinien
Ich hatte kürzlich die Gelegenheit, Michael Dennis zu interviewen, der das Gruppenrichtlinienprojekt bei Microsoft von Anfang an geleitet hat. Michael verlässt nun das Gruppenrichtlinienteam, um eine andere Rolle bei Microsoft einzunehmen. Ich habe mich mit ihm über die letzten neun Jahre des Projekts „Gruppenrichtlinie“ unterhalten, um zu erfahren, wie es sich entwickelt hat und wie die Zukunft aussieht.

Jeremy Moskowitz Viele Leute möchten sicherlich wissen, was Sie als Ihre größten Erfolge während Ihrer Zeit als Leiter des Gruppenrichtlinienteams bei Microsoft ansehen.

Michael Dennis Die größten Erfolge gab es in der Phase, in der die später so genannte Gruppenrichtlinie schwerpunktmäßig entwickelt wurde. Die Systemrichtlinie in Windows NT® 4.0 lag bereits vor. Wir entschieden uns dafür, die Vorteile und Probleme dieser Richtlinie genauer unter die Lupe zu nehmen. Da dies in die Entwicklungsphase von Active Directory® fiel, untersuchten wir, an welchen Stellen die Verwaltbarkeit von Clients und Servern verbessert werden konnte.
Die völlig neue Idee, dass eine Gruppenrichtlinie in eine Hierarchie integriert werden konnte, war eine große Entdeckung für uns. Also konzentrierten wir uns auf die Kerninfrastruktur, die Clientprozesse und die Integration in Active Directory.
Das Nebenprodukt unseres größten Erfolgs war gleichzeitig auch unser größter Misserfolg. Die grafische Benutzeroberfläche, die in Windows 2000 geliefert wurde, war nämlich problematisch. Die effektive Verwendung der Gruppenrichtlinie erforderte praktisch einen eigenen Studiengang, da Administratoren wissen mussten, wie alles funktioniert. Ich wünschte, wir hätten die Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC) und den Richtlinienergebnissatz (Resultant Set of Policy, RSoP) schon damals erstellen und bereitstellen können. Das Konzept bestand damals bereits.

JM Welche Elemente hätten Sie damals gern in die Gruppenrichtlinie eingebaut?

MD Die gute Neuigkeit ist, dass alles, was ich mir seit der Freigabe von Windows 2000 vorgenommen hatte, jetzt in Windows Vista vorliegt. Dazu gehört beispielsweise RSoP, die GPMC, die größere Anzahl von Einstellungen, und so weiter. Ich wünschte, wir hätten all dies schon viel früher erreicht.
Außerdem hatte ich mir vorgestellt, dass die Gruppenrichtlinieninfrastruktur leichter nach Partnern erweitert werden kann. Das server-/clientseitige Erweiterungsmodell erfordert viel Arbeit seitens der Entwickler. Andererseits lässt sich einwenden, dass die ADM/ADMX-Vorlagenstruktur ein leicht erweiterbares Framework bereitstellt. Noch besser wäre es, wenn dieser Teil des Systems die Erweiterung von weiteren Einstellungstypen ermöglicht.
Es wäre auch wünschenswert, die GPMC-Berichterstattung so zu gestalten, dass sie für Partner und Entwickler von Drittanbietertools in höherem Maße erweiterbar ist. Dies ist ein Bereich, auf den Hersteller von Drittanbietertools oft und deutlich hingewiesen haben.

JM Gibt es Dinge, die wir über das Gruppenrichtlinienteam wissen sollten?

MD Manchmal ist es schwer, das Team für Gruppenrichtlinien in das Gesamtbild einzuordnen. Aufgabe des Teams ist es, die Infrastruktur, den Transport, den Server und die clientbasierten Teile zu erstellen. Doch allein für Windows Vista haben wir mit etwa 120 verschiedenen Microsoft-Teams zusammengearbeitet, um die neuen Einstellungen für diese Veröffentlichung fertig zu stellen.
Benutzer sollten sich vor Augen halten, dass es nicht an der Gruppenrichtlinie liegt, wenn die Systemleistung beim Starten oder Anmelden abfällt. Diese Probleme treten aufgrund der Gruppenrichtliniennutzlast auf. Wenn Sie die Gruppenrichtlinie anweisen, eine schwierige Aufgabe auszuführen, führt sie sie aus. Die Anweisung, Microsoft Office auf einer computerspezifischen Basis zu installieren, ist beispielsweise kein Problem. Sie müssen sich nur darüber im Klaren sein, dass die Richtlinie genau das ausführt, was verlangt wird. Also installiert sie das gesamte Office-System, bevor eine Anmeldeaufforderung ausgegeben wird. Ist das eine Verlangsamung? Zweifelsohne, aber es ist genau das, was der Administrator, der die Richtlinie bereitstellte, verlangt hat.

JM Was führen Sie am liebsten mithilfe der Gruppenrichtlinie vor?

MD Derzeit zeige ich gern einige der neuen Einstellungen vor, die in Windows Vista eingeführt wurden. Die Wechselmedieneinstellungen beispielsweise (Einschränkungen von USB-Sticks usw.) wurden schon seit langem von den Benutzern verlangt. Es gibt ungefähr 2.400 Einstellungen in Windows Vista, die Administratoren bemerkenswerte Kontrollmöglichkeiten bieten. Ich frage Kunden gern, was sie kontrollieren wollen, und führe dann vor, wie dies gemacht wird.

JM Weshalb haben Sie von ADM- zu ADMX-Dateien gewechselt?

MD Technisch gesehen war dies nicht unbedingt erforderlich, um das neue zentrale Speicherfeature in Windows Vista zu erhalten. Die Konvertierung in ADMX, war dadurch begründet, dass mehrere Sprachen entsprechend unterstützt werden sollten.
Vorher kam es in mehrsprachigen Umgebungen oft vor, dass der Inhalt der ADM-Dateien innerhalb eines GPO versehentlich von einer anderen Sprache geschrieben wurde. Historisch gesehen haben wir das ADM-Format von Windows NT 4.0 verwendet, was Windows NT von Windows 98 und Windows 98 wiederum von Windows 95 übernommen hatte. Wenn XML damals schon existiert hätte, wäre es ein idealer Anwärter für das Dateiformat gewesen.
Aber jetzt haben wir XML, und es ist leichter geworden, mehrere Sprachen zu unterstützen. Außerdem bietet es Möglichkeiten, künftig Registrierungs- und Einstellungsverbesserungen mit unserer jetzt schematisierten Sprache vorzunehmen.

JM Was war die größte interne Herausforderung in Ihrer Zeit im Gruppenrichtlinienteam?

MD Das größte Problem für das Team besteht immer noch darin, andere Komponenten von Windows dazu zu bringen, ihre Features durch eine Richtlinie zu aktivieren.
Team X könnte beispielsweise entgegnen: „Wir haben dieses großartige neue Feature entwickelt. Es besteht wirklich kein Grund, es jemals deaktivieren zu wollen.“ Das können wir natürlich nachvollziehen. Doch wir haben schon viele derartige Probleme durchgearbeitet.
Es gibt auch technische Herausforderungen, was das Aktivieren über eine Richtlinie angeht. Dazu gehört zum Beispiel die neue Windows-Firewall mit erweiterter Sicherheit (Windows Firewall with Advanced Security, WFAS). Die Entwicklung von WFAS war zäh. Es ist nicht leicht, sie über eine Richtlinie ordnungsgemäß zu aktivieren. Die vom WFAS-Team für Windows Vista erstellte Oberfläche ist hervorragend, doch der Entwicklungsprozess war ganz schön hart.
In den Windows-Versionen vor Windows Vista haben die Produktteams nicht immer daran gedacht, ihre Komponenten über eine Richtlinie aktivieren zu lassen. Doch im Laufe der Windows Vista-Entwicklung haben uns relativ viele Teams gefragt, wie dies vor sich geht. Das war schon beachtlich!
JM Was steht für Sie als Nächstes an?

MD Ich werde zum Team „Mobile Information Worker“ wechseln, das für Smartphones, Pocket PCs usw. zuständig ist. Zu meinen Aufgaben gehört dann das Erweitern der Verwaltungstechnologien in Windows Server System auf Windows Mobile®-Geräte.
Ich werde versuchen, die gleichen Zielsetzungen im Bereich Verwaltbarkeit sowie meine persönliche Leidenschaft für dieses Gebiet auch auf meine neue Tätigkeit zu übertragen. Das Gruppenrichtlinienteam befindet sich zurzeit in einer hervorragenden Position für eine weitere erfolgreiche Entwicklung.

JM Möchten Sie unseren Lesern sonst noch etwas mitteilen?

MD Während der gesamten Entwicklung der Gruppenrichtlinie bestand ein wichtiger Schritt darin, sich persönlich mit Kunden auszutauschen und wirklich zu verstehen, wie sie arbeiten und was sie erreichen möchten. Wenn Kunden ihre Meinung zu Szenarios, die von der Gruppenrichtlinie abgedeckt werden sollten, auf strukturierte Weise darlegen können und ein Geschäftsmodell dafür vorliegt, freuen wir uns, wenn sie uns kontaktieren.
Hierfür steht ein guter Feedbackmechanismus unter WindowsServerFeedback.com zur Verfügung. Suchen Sie nach der Schaltfläche „Gruppenrichtlinie“.
Informationen wie „Ich habe folgendes Problem, so sieht mein Geschäftsmodell aus, ich brauche ein System, um dies und jenes ausführen zu können, und zwar aus diesem Grund“ sind äußerst wertvoll für uns. Jeder Eingang aus dieser Quelle wird von den künftigen Entscheidungsträgern für die Gruppenrichtlinie gelesen.
Teilen Sie uns also auf jeden Fall Ihre Anforderungen für die Gruppenrichtlinie mit. Allerdings reicht „Wir brauchen eine Richtlinieneinstellung, die X kann“ allein nicht aus. Sie müssen uns schon den Grund für die Anforderung mitteilen. Das „Wie“ ist unsere Aufgabe. Was das Gruppenrichtlinienteam wirklich wissen muss, ist das „Warum“.
JM Danke, dass Sie sich die Zeit genommen haben, uns über Ihre Erfahrungen im Gruppenrichtlinienteam bei Microsoft zu berichten. Alles Gute!
MD Vielen Dank, Jeremy.

Jeremy Moskowitz ist MCSE und MVP für Gruppenrichtlinien und leitet GPanswers.com, ein Gemeinschaftsforum zum Thema Gruppenrichtlinien. Außerdem organisiert er Intensivseminare zum Thema Gruppenrichtlinien. Sein aktuelles Buch heißt „Group Policy: Management, Troubleshooting, and Security“ (Sybex, 2007). Sie erreichen Jeremy Moskowitz unter www.GPanswers.com.


 Sicherheit: 4 Sicherheitstechnologien, die jedes IT-Unternehmen haben muss
Sicherheit Matt Clapham and Todd Thompson

4 Sicherheitstechnologien, die jedes IT-Unternehmen haben muss
Kurz zusammengefasst:
  • Risikomanagement-Dashboard
  • Antimalware
  • Erkennen von Netzwerkanomalien

Wenn es um IT-Sicherheit geht, haben die meisten Unternehmen so ziemlich die gleichen Probleme zu behandeln. Microsoft ist da keine Ausnahme. Wir haben zwei Jahre beim Risikomanagement- und Konformitätsteam für
Microsoft® Managed Solutions (MMS) verbracht. (Weitere Informationen zu MMS finden Sie unter Microsoft lädt Energizer-IT-Abteilung wieder auf.)
Aufgaben des Risikomanagement- und Konformitätsteams sind Definition, Überwachung und Korrektur der Risikosituation aller MMS-Umgebungen (sowohl für Dienste gegenüber Kunden als auch für die Infrastrukturkoordination). Schon frühzeitig hat unser Manager Arjuna Shunn erkannt, dass eine Technologielösung erforderlich war, die die gewünschte Steuerung und Überwachung in zentralisierter und zusammenhängender Form bereitstellte. Die hier erörterten Technologien sind ein direktes Ergebnis unserer frühen Ideen, gepaart mit zwei Jahren Erfahrung bei der Verwendung verschiedener Microsoft-Produkte und Produkte von Drittanbietern in unseren Betriebsvorgängen.
Zunächst brauchten wir Sicherheitstechnologien, die die drei primären Arten der Kontrolle, nämlich Vorbeugung, Nachweis und Abhilfe, abdecken und Überwachung und Berichte bereitstellen würden. Diese Toolsammlung ließ sich in vier Kategorien unterteilen: Risikomanagement-Dashboard, Antimalware, Erkennen von Netzwerkanomalien und Verwalten der gewünschten Konfiguration. Wir haben uns bemüht, mindestens einen Vertreter jeder Kategorie in unsere Risikomanagementvorgänge einzubeziehen. Dabei haben wir festgestellt, dass das IT-Sicherheitsteam durch die Nutzung von Technologien aus allen vier Bereichen ein vernünftiges Gleichgewicht zwischen Kosten und Effektivität erreichen kann.
Für die beiden primären Risikoverwaltungsvorgänge – Bekämpfung von Sicherheitsverletzungen und Konformitätsmanagement – war diese Vorgehensweise äußerst nützlich, aber wir sind noch weit davon entfernt, die Koordination zwischen den Tools zu erreichen, die wir letzten Endes wünschen. Ein zusammenhängender Satz von Technologien bietet erheblich mehr an betrieblicher Effizienz, doch leider verfügt die Branche noch nicht über dieses integrierte System.
Glücklicherweise ist für die IT-Sicherheitsteams nicht alles verloren. Es ist einfach eine Frage der Zeit, bis die vier Systeme beginnen, erfolgreicher zusammenzuarbeiten. Wenn diese Systeme erst einmal zusammenarbeiten, ermöglichen sie nicht nur die aktive Überwachung der Systemsicherheitslage, sondern werden sich auch bei anderen Überwachungsvorgängen oder dem routinemäßigem IT-Betrieb als praktisch erweisen. In diesem Artikel wird die ideale Funktion jedes Systems beschrieben, unter Einfügung einiger Beispiele aus unserer Laufzeitverwendung.

Risikomanagement-Dashboard
Unserer Meinung nach ist ein Risikomanagement-Dashboard (RMD) unbedingt erforderlich. Es ist die einzige unentbehrliche Technik für den Betrieb eines IT-Sicherheitsteams. Risiken in den Bereichen Vertraulichkeit, Integrität, Verfügbarkeit und Verantwortlichkeit (CIA2) werden in einem Unternehmen oft von unterschiedlichen Systemen und Prozessen ohne eine einzige Schnittstelle für die Zusammenführung und Korrelation von Daten und die Risikokorrektur überwacht. Außerdem steigen die gesetzlichen Anforderungen an die Transparenz von Unternehmensdaten immer mehr, und es gibt kein rationalisiertes System, um eine Richtlinie ohne weiteres von ihrer Aufstellung an bis zur Ausführung im Unternehmen nachzuverfolgen. Dies beweisen häufig auftretende Unternehmensschwierigkeiten bei Datenerfassung, Korrelation, Bewertung, Korrektur und Konformität. (Obwohl System Center Operations Manager 2007 keine vollständige RMD-Lösung ist, wie wir sie hier skizzieren, wird dadurch, wie in Abbildung 1 gezeigt, eine einzige Schnittstelle für die Überwachung mehrerer Ressourcen und die Sammlung zugehöriger Warnungen bereitgestellt.)
Abbildung 1 System Center Operations Manager 2007 stellt eine einzige Schnittstelle für die Anzeige von Warnungen und die Verwaltung von Ressourcen aus dem gesamten Netzwerk bereit.
Abbildung 1 System Center Operations Manager 2007 stellt eine einzige Schnittstelle für die Anzeige von Warnungen und die Verwaltung von Ressourcen aus dem gesamten Netzwerk bereit.
Die Datenerfassung wird dadurch beeinträchtigt, dass Daten aus unterschiedlichen Quellen nicht zusammengeführt und normalisiert werden können. Die Zusammenführung von Daten ist grundsätzlich eine Herausforderung, da dies ein Ausbrechen aus der allzu üblichen herkömmlichen Vorgehensweise bei der Sammlung von Daten und der Berichterstellung über Daten erfordert. Aber auch nach Abschluss der Zusammenführung von Daten stellt deren Normalisierung eine noch größere Herausforderung dar, da es äußerst schwierig ist, das erforderliche gemeinsame Framework zur Unterstützung der Datennormalisierung einzurichten. Ohne diese Normalisierung ist es unmöglich, von verschiedenen Systemen stammende sicherheits- und zustandsrelevante Ereignisse sinnvoll miteinander zu vergleichen.
Um die erforderliche Automatisierung durchzuführen, muss das Risikomanagement-Dashboard über Zugriff auf Datenfeeds aus anderen Quellen als den hier beschriebenen Sicherheitstechnologien verfügen. Es können bei der Bestimmung der Gesamtrisikosituation viele nicht sicherheitsrelevante Daten verwendet werden. Informationen wie Routerprotokolle, Ressourcenüberwachung, Patchstatus, derzeit angemeldete Benutzer, Leistungsberichte und Änderungsverwaltungsdaten können Informationen liefern, die für die Untersuchung des Vorfalls relevant sind. Folglich muss das Gesamtsystem auf alle diese Daten zugreifen können. Uns ist bewusst, dass auch zu den am stärksten Microsoft-zentrierten Unternehmensinfrastrukturen Technologien gehören, die nicht von Microsoft stammen, sodass das RMD über eine gemeinsame Schnittstelle Feeds von Nicht-Microsoft-Technologien annehmen muss.
Wenn Daten erfasst und normalisiert werden können, sind sie in einem nächsten Schritt zu korrelieren. Ziel ist es, eine Ereignissequenz, bestehend z. B. aus einem Netzwerkanomalieereignis, einem Antivirenberichtereignis und einem Abweichungsereignis von der gewünschten Konfiguration, zu einem Satz risikobezogener Daten zu korrelieren, die eine Grundlage für Aktionen bieten. Hierfür ist intensive manuelle Arbeit erforderlich, um die Korrelationslogik zu erstellen, die zu sinnvollen risikobasierten Warnungen führt. Ausgehend von den derzeit verfügbaren Technologien ist diese Korrelationslogik selbst im günstigsten Fall schwierig zu erzielen.
Auch die Datenbewertung erfordert intensive manuelle Arbeit. Selbst wenn Korrelation stattfindet, muss sich ein Analyst die korrelierten Daten noch anschauen, um ihre Wirksamkeit zu ermitteln. Die Wirksamkeit der korrelierten Daten ist nur so stark wie die Regeln, auf denen sie basieren. Dies führt zu weiterer menschlicher Analyse korrelierter Daten, um das Risiko für die IT-Umgebung zu bewerten. Ein klares und kodifiziertes Framework zur Risikoverwaltung könnte helfen, den Aufwand an manuellen Eingriffen zu verringern, die zum Erreichen einer Bewertungsebene erforderlich sind. Es ist schwierig, ohne dieses Framework in einer vorliegenden Implementierung einen praktikablen Satz von Korrelationsregeln zu entwickeln.
Wenn ein System den Punkt der Risikobewertung erreicht, ist der nächste Schritt die automatisierte Korrektur. Heute ist dies nur im Unternehmen wirklich verfügbar, und auch dann nur für einen begrenzten Satz von Technologien, z. B. Patchverwaltung oder Antivirusvorgänge. Eine automatisierte Korrektur, die vom RMD-System angeführt wird, gibt dem IT-Administrator beachtliche Möglichkeiten, ein akzeptables IT-Risikoniveau aufrechtzuerhalten. Wenn mehrere Risiken gleichzeitig erkannt werden, muss die Korrelationslogik aufgrund von Ressourcenklassifizierungsdaten bei der Priorisierung der Vorfallreaktion helfen können.
Schließlich ist der Nachweis der Einhaltung verschiedener gesetzlicher Anforderungen für IT-Abteilungen eine riesige Herausforderung, und dieses System muss, wie erwähnt, eine solche Funktionalität unterstützen. Ein zentralisiertes, in Richtlinien eingebundenes Risikoverwaltungssystem könnte bei Berichterstellung und Konformitätsnachweis sehr vorteilhaft sein. Die Richtlinie muss aber mehr beinhalten als die Frage nach dem Wo und Weshalb. Um die automatisierte Korrektur zu erleichtern, muss die Richtlinie in einen Satz von Standards übersetzt werden, den das Dashboard überwachen und erzwingen und über den es Feedback liefern kann.
Das ideale Risikomanagement-Dashboard kann also als eine Möglichkeit zusammengefasst werden, eine einheitliche Schnittstelle für Zustandsbewertung, Einhaltung gesetzlicher Vorschriften und Richtlinien sowie für den Prozess zur Verwaltung von Sicherheitsrisiken im Unternehmen bereitzustellen. Dies wird durch das Zusammenfassen von Informationen aus unterschiedlichen sicherheits- und zustandsbezogenen Produkten und Quellen in einer zusammenhängenden risikobezogenen Anzeige erreicht. Eine gute RMD-Lösung muss Folgendes können:
  • Daten aus unterschiedlichen Quellen zusammenführen, normalisieren und korrelieren
  • Automatisierte Informationssammlung und Risikoabschätzung bereitstellen
  • Den Richtlinien gesetzliche Anforderungen zuordnen und Überwachung und Berichterstellung unterstützen
  • Ein einheitliches Framework bereitstellen, das sich für die Anpassung an die Anforderungen eines Unternehmens modifizieren lässt
Das Dashboard muss die Anordnung und verständliche Anzeige von Daten ermöglichen, sodass zum Beispiel die wichtigsten Vorfälle geordnet nach Typ oder Quellsystem, ausstehende Vorfälle, gelöste Vorfälle und so weiter aufgeführt werden. Weiterhin muss dass Dashboard eine genaue Ansicht jedes einzelnen Berichtselements bieten. Der Benutzer muss beim Betrachten eines Ereignisses einfachen Zugriff auf alle etwaigen verwandten Daten haben. So können Entscheidungen verbessert und schneller getroffen werden.
Es muss darauf hingewiesen werden, dass das RMD auch für Administratoren nützlich ist, die nicht dem Sicherheitsteam angehören. Da das Dashboard eine ganzheitliche Ansicht der Umgebung umfasst, kann das RMD für alle Mitarbeiter als zentraler Punkt dienen, um den aktuellen Status anzuzeigen. Das Dashboard kann zum Beispiel das Messagingteam vor einem Denial-Of-Service-Angriff am SMTP-Gateway warnen. Dies stellt für das Risikomanagementteam zwar eine Sicherheitsverletzung dar, das Messagingteam betrachtet es jedoch als einen Verfügbarkeitsvorfall. Obwohl das Messagingteam möglicherweise nicht dafür verantwortlich ist, auf einen solchen Vorfall zu reagieren und ihn zu beheben, so will es doch wenigstens über derartige Vorfälle informiert sein, die sich auf die vom Team verwalteten Ressourcen auswirken.

Antimalwaretechnologien
Ein umfassendes Antimalwaresystem ist wichtig, um Ihre Infrastruktur gegen unvorhergesehene, in Code und Benutzeraktionen versteckte Bedrohungen zu schützen. Zurzeit gibt es generell zwei getrennte Arten von Tools für den Schutz gegen Malware: Antivirus und Antispyware. (Windows® Defender in Abbildung 2 fällt zum Beispiel in die zweite Kategorie.) Beide verhindern, erkennen und korrigieren effektiv verschiedene Infektionsarten. Es ist jedoch nur eine Frage der Zeit, bis diese zwei Schutztypen zu einer einzigen Lösung zusammengefasst werden, und es wird dann auf einem System nur noch einen einzigen Stapel Antimalware geben.
Abbildung 2 Windows Defender hilft beim Schutz des Client gegen Spyware
Abbildung 2 Windows Defender hilft beim Schutz des Client gegen Spyware
Eine gute Antimalwarelösung muss das System in Echtzeit überwachen und regelmäßig scannen. Sie muss bekannte Malware (einschließlich Viren, Spyware und Rootkits) sowie unbekannte Malware zentral melden, und zwar basierend auf typischem riskantem Verhalten. Stabile Antimalwaretechnologie überwacht alle klassischen Einstiegspunkte (einschließlich Dateisystem, Registrierung, Shell, Browser, E-Mail und verbundene Anwendungen) durch enge Integration in das Betriebssystem und die Anwendungen.
Außerdem muss eine Antimalwarelösung mehr leisten als nur das Hosten von Sicherheit. Sie muss allgemeine Messagingdienste sowie Dienste zur Zusammenarbeit überwachen, bei denen oft infizierte Dateien weitergeleitet werden, z. B. SharePoint® und Instant Messaging. Sie muss außerdem eine automatisierte Infektionsverhütung durch Beenden von (bekannten oder verdächtigen) Vorgängen sowie durch sorgfältiges Prüfen von Benutzerdaten bereitstellen, um beispielsweise Makroviren zu entfernen, die in Benutzerdokumenten versteckt sind und das System noch nicht infiziert haben.
Es versteht sich von selbst, dass Antimalware ohne Aktualisierungen nutzlos ist. Das System muss seine Signatur- und Entfernungssysteme auf dem jeweils neuesten Stand halten, um vor den aktuellsten Bedrohungen einen Vorsprung zu behalten. Wenn eine neue Bedrohung auftritt, muss der Lieferant vor den nächsten Zero-Day-Bedrohungslücken zusätzlichen Schutz einrichten. Eine einfach zu verwaltende Antimalwarelösung ist darüber hinaus zentral konfigurierbar und aktualisierbar.
Selbstverständlich darf dieser Schutz nicht auf Kosten der Leistung gehen. Wenn die Leistung leidet, leidet auch die Produktivität. Benutzer versuchen möglicherweise sogar, die Antimalwarelösung zu deaktivieren, sodass dann gar kein Schutz besteht.
Vergessen Sie schließlich nicht die Bedeutung von Hilfstechnologien, die das Antimalwaresystem unterstützen. Firewalls, eingeschränkte Benutzerrechte und sonstige Strategien verbessern ebenfalls den Schutz gegen schädlichen Code und Benutzeraktionen.

Erkennen von Netzwerkanomalien
Während Antimalware die Systeme im Auge behält, überwacht die Netzwerkanomalieerkennung (Network Anomaly Detection, NAD) die üblichen Wege, indem sie auf bekannte Indikatoren für verdächtiges Verhalten achtet und dem RMD diese Informationen zwecks Korrektur meldet. (Eine Firewall zum Beispiel würde wie in Abbildung 3 zu dieser Kategorie gehören.) Verdächtiges Verhalten besteht beispielsweise in bekanntem angreifendem Datenverkehr (z. B. einem Wurm oder Denial-Of-Service) oder in Daten, die in ein bestimmtes Muster passen (z. B. US-amerikanische Sozialversicherungsnummern) und über E-Mail versendet werden.
Abbildung 3 Eine Firewall ist ein wichtiger Teil einer Netzwerkanomalieerkennungslösung
Abbildung 3 Eine Firewall ist ein wichtiger Teil einer Netzwerkanomalieerkennungslösung
Trotz bester Bemühungen der IT-Verwaltung kommt es unvermeidlich in jedem großen Unternehmensnetzwerk hin und wieder zu einem Malwarevorfall. Die NAD stellt hierzu ein Frühwarnsystem bereit, das zu einer schnelleren Korrektur verhelfen kann. Darüber hinaus sind die Datenüberwachungsfunktionen der NAD und die Möglichkeit, vertrauliche Informationen zu erkennen und deren Durchsickern zu verhindern, praktische Tools für den Schutz von Informationen in einer Umgebung, in der Datenverlust und Einhaltung gesetzlicher Bestimmungen wichtig sind.
So wie Antimalwaretechnologien muss auch die NAD ständig an den aktuellsten Satz von Bedrohungen und die aktuellsten Typen vertraulicher Daten angepasst werden, um effektiv arbeiten zu können. Außerdem muss ein gutes NAD-System über ein bestimmtes Wissen zu den tatsächlichen Anomalien verfügen, um die Anzahl falscher Positivmeldungen zu minimieren. Ansonsten ignorieren Administratoren nach einer Weile womöglich die von der NAD kommenden Meldungen, weil sie annehmen, dass diese wieder nur ein falscher Alarm sind.
Nach einer gewissen Schulung bzw. Optimierung erkennt und überwacht das NAD-System typische Nutzungsmuster des Datenverkehrs. Dies ist wichtig, da sich neue Arten von Malware und anderen Angriffen möglicherweise durch eine Änderung der Nutzungsmuster bemerkbar machen. Netzwerkkomponenten spielen eine bedeutende Rolle im NAD-Gesamtsystem, da die Lösung Daten von Routern, Switches und Firewalls verarbeiten muss. Die NAD-Warnungen können dann vom Korrelationsmodul im RMD verarbeitet werden.
Eine interessante Möglichkeit besteht darin, die Erkennungsprogramme für Netzwerkanomalien in die Host-Antimalwaresoftware oder Firewall zu integrieren und somit ein Schutznetz zu schaffen, in dem alle einbezogenen Computer bei der Überwachung helfen und Angriffe möglicherweise abwehren, bevor sich Malware ausbreitet.

Verwalten der gewünschten Konfiguration
Eine der größten Herausforderungen für IT-Abteilungen in großen Unternehmen besteht darin, dass Systeme richtig konfiguriert bleiben. Es gibt viele Beweggründe, Systemkonfigurationen verwalten zu wollen: Erleichterung der Verwaltung, Vereinfachung der Skalierbarkeit, Sicherung der Konformität, Sperrung gegen verschiedene Angriffsformen sowie Förderung der Produktivität, um nur einige zu nennen. Viele dieser Gründe wirken sich auf die Sicherheit aus.
Das Verwalten der gewünschten Konfiguration wird in den meisten Unternehmen aus Gründen der Komplexität und der Startkosten weitgehend außer Acht gelassen. Studien zeigen jedoch, dass Systemverwaltung langfristig zu Kosteneinsparungen und erhöhter Zuverlässigkeit führt. Eine Überwachung der gewünschten Konfiguration (Desired Configuration Monitoring, DCM) kann hierbei helfen.
Ein gutes DCM-System muss automatisch das Netzwerk prüfen, um sicherzustellen, dass neue Systeme wie gewünscht bereitgestellt werden. Weiterhin muss überprüft werden, ob eingerichtete Systeme konform bleiben. Eine vollständige DCM-Lösung stellt sicher, dass der aktuellste Patch bereitgestellt oder die Anzahl der Benutzer mit Domänenberechtigung minimiert wird, vor allem aber muss sie Systeme konfigurieren, analysieren und Berichte darüber erstellen, wie nahe jede Konfiguration dem Ideal kommt. Die Korrekturen können einfach sein (z. B. das Patchen neuer Systeme bei Bereitstellung auf dem Netzwerk) oder zwangsweise erfolgen (z. B. das Erzwingen von E-Mail-Clienteinstellungen für Benutzer). Die Hauptsache ist, dass die Korrekturen nach den Richtlinien der Organisation und den gesetzlichen Vorschriften erfolgen. (DCM kann auch beim Erkennen und Entfernen von Malwareinfektionen helfen, da einfache Typen sofort in den Prüfergebnissen auffallen.)
DCM ist einer der primären Datenreporter an das Korrelationsmodul des RMD. DCM liefert wichtige Details über die Abweichung des fraglichen Hosts vom Normalzustand. Die Aktualität der zugehörigen Daten kann den Unterschied zwischen einer Sicherheitsverletzung mit einer einzigen Warnung und einer solchen mit fünf Warnungen ausmachen. Daher muss eine Ressource in einer Häufigkeit überprüft werden, die proportional zu ihrem Wert ist. So wird zum Beispiel eine Ressource von geringer Empfindlichkeit möglicherweise nur monatlich überprüft, während eine Ressource von mittlerer Empfindlichkeit wöchentlich und eine Ressource von hoher Empfindlichkeit mindestens einmal täglich überprüft wird.
Das Einrichten von DCM ist auch ein wesentlicher Teil eines guten Netzwerkzugriffsschutzmechanismus (Network Access Protection, NAP). Das System kann nämlich überprüfen, ob alle verbundenen Systeme richtig konfiguriert sind, und es kann neue oder unbekannte Systeme bis zu ihrer Überprüfung sperren. Außerdem muss DCM nach Sicherheitsrisiken der Konfiguration suchen (z. B. nach unsicheren Zugriffssteuerungslisten auf einer Freigabe), sodass Administratoren entsprechende Aktionen durchführen können.
Denken Sie nicht, DCM gilt nur für Hosts wie Clients oder Server. Netzwerkgeräte und sogar das Kernverzeichnis lassen sich sinnvoll in DCM einbeziehen. Wenn ein einigermaßen ausgereiftes Netzwerkdesign verfügbar ist, dürfte es für das ideale DCM-System ein Leichtes sein, Standards für zugeordnete Geräte zu erzwingen. Ungeahnte Möglichkeiten tun sich auf! Statt manueller Anpassung von Routerkonfigurationen kann DCM die Implementierung erledigen. Angenommen, ein Satz von Standardeinstellungen für Gruppenrichtlinien ist einem bestimmten Satz von Servern oder Clients zugeordnet. DCM überwacht diese Einstellungen und sendet eine Warnung, wenn sich die Domäneneinstellungen ändern.
Die von DCM gesammelten Daten müssen stabil genug sein, um in einer IT-Überwachung verwendet zu werden. Eine gute DCM-Lösung muss Hooks zu Steuerelementen der Änderungsverwaltung und den gesetzlichen Vorschriften haben, damit Überwachungsprobleme rechtzeitig und fortlaufend behandelt werden können. So besteht zum Beispiel eine unserer Routinekontrollen in der Überprüfung, ob sich die lokale Mitgliedschaft des Administrators auf MMS-Servern geändert hat. Der Zweck von DCM ist die Erzwingung dieser Regel!
Selbst wenn Ihre IT-Abteilung noch nicht für ein sich selbsttätig korrigierendes DCM-System geeignet ist, kann dennoch eine als Überwachung der gewünschten Konfiguration bekannte Variante bereitgestellt werden, die hervorragende Ergebnisse liefert. Auch diese bietet Berichte und Warnungen über Konfigurationsprobleme, es wird aber nicht unbedingt dieselbe Kosteneinsparung erreicht, da die Korrektur größtenteils manuell erfolgt. Wichtig aber ist, dass die Benachrichtigung und die Daten, die das RMD benötigt, für die Korrelation verfügbar sind.
Ein warnendes Wort allerdings. DCM muss in beiden soeben beschriebenen Formen auf ein Minimum der wichtigen Konfigurationselemente in Verbindung mit den Standard-Ressourcensammlungsdaten begrenzt werden. Ist dies nicht der Fall, wirkt sich DCM möglicherweise auf die Flexibilität aus, die das IT-Team benötigt. Falls die DCM-Konfigurationshandbücher veralten, wird man DCM schnell als eine Belastung für den Betrieb statt als nützliches Tool betrachten. Daher ist es wichtig, mit den neuesten Entwicklungen darüber, wie Ressourcen optimal zu konfigurieren sind, Schritt zu halten. Des Weiteren empfehlen wir, dass das DCM-System seine Konfigurationshandbücher gemäß den bewährten Methoden für die fragliche Ressource oder Anwendung um regelmäßige Aktualisierungen erweitert.

Schlussbemerkung
Das Dashboard ist für Ihr Team unentbehrlich, ob Sie es nun innerbetrieblich erstellen oder von einem zuverlässigen Lieferanten beziehen, da es als wichtigstes Tool für Vorfallreaktionen dient. Antimalware ist ebenfalls unerlässlich zum Schutz vor den täglich zunehmenden Bedrohungen. Die Netzwerkanomalieerkennung entwickelt sich zusehends von einer bloßen Erkennung von Malwaresignaturen und Hostangriffen zu einem System mit Datenverlusterkennung. Mithilfe dieser Funktion lässt sich möglicherweise der nächste Eindringversuch in Ihr Netzwerk verhindern. Obwohl das Verwalten der gewünschten Konfiguration eine relativ neue Funktion ist, wird sie mit Sicherheit bald unerlässlich für die Überwachung und Verwaltung von Konfigurationen sein. Unabhängig davon, wer diese Tools bereitstellt, brauchen Sie aus diesen vier Kategorien jeweils mindestens eines!
Bisher bietet kein einziger Lieferant (einschließlich Microsoft) eine einzige ganzheitliche Lösung an, die jeden der vier Bereiche abdeckt. Es bleibt Ihnen überlassen, die Produkte auszuwählen, die zu Ihren spezifischen Anforderungen passen. Dieser Artikel soll Ihnen einen Einblick dazu verschaffen, was Sie bei dieser Lösung bedenken müssen, welche Ziele sich damit erfüllen lassen und was die Ideallösung leisten kann.

Matt Clapham ist Security Engineer in der Infrastruktur- und Sicherheitsgruppe der Microsoft IT-Abteilung. Vorher arbeitete er zwei Jahre lang beim Risikomanagement- und Konformitätsteam für Microsoft Managed Solutions.
Todd Thompson ist Security Engineer in der Infrastruktur- und Sicherheitsgruppe der Microsoft IT-Abteilung. Vorher arbeitete er zwei Jahre lang beim Risikomanagement- und Konformitätsteam für Microsoft Managed Solutions.


 Sicherheit: Ein leistungsf&#228;higes neues Tool f&#252;r die Zertifikatsverwaltung
Sicherheit Kevin Dallmann

Ein leistungsfähiges neues Tool für die Zertifikatsverwaltung
Kurz zusammengefasst:
  • Architektur von ILM-CM
  • Verwaltung und Vorlagen
  • Erstellen eines Workflows

Es ist ein ruhiger Tag bei der Arbeit. Plötzlich erhalten Sie einen Aufruf von Ihrem Helpdesk-Supportteam: Auf einem der Produktionssysteme ist ein Zertifikat abgelaufen. Das System ist ausgefallen, und Ihr Unternehmen verliert Produktivität (und bares Geld), bis Sie das Zertifikat erneuern.
Wenn Sie für die Verwaltung einer PKI-Umgebung (Public Key Infrastructure) verantwortlich sind, dürfte das Ablaufen eines Zertifikats für Sie eher überraschend kommen. Der ruhige Tag ist damit auf alle Fälle beendet.
Als Microsoft die PKI-Dienste in Windows® 2000 und Windows Server® 2003 integrierte, erhielten die Unternehmen die fantastische, preiswerte Möglichkeit, eine firmeninterne PKI-Umgebung zu implementieren. Leider war es mit den Microsoft® PKI-Diensten nicht möglich, den Lebenszyklus der erzeugten Zertifikate zu verwalten. Vor kurzem konnte Microsoft jedoch ein Produkt für die Zertifikatsverwaltung erwerben, woraufhin Identity Lifecycle Manager (ILM) eingeführt wurde. Dieses Produkt vereint die Zertifikatsverwaltung mit der Identitätsbereitstellung und den Verwaltungsfunktionen von Microsoft® Identity Integration Server (MIIS). In diesem Artikel wird dargelegt, wie ILM dazu beiträgt, die Zertifikate und Smartcards in Ihrem Unternehmen zu verwalten.

Architektur von ILM-CM
Das Herzstück der Architektur von ILM-CM (ILM Certificate Management) ist der ILM-CM-Server und die zugehörigen Komponenten (siehe Abbildung 1). Der ILM-CM-Server kann auf einem einzigen Server installiert werden, der für den Datenaustausch mit einer oder mehreren Zertifizierungsstellen (CA) eingerichtet ist. ILM-CM erfordert SQL Server™; hier werden Zertifikatsinformationen, Richtlinien und andere zugehörige Daten gespeichert, die bei der Verwaltung der Zertifikatumgebung zum Einsatz kommen. Damit auch Benutzer und Sicherheitsberechtigungen verwaltet werden können, ist Active Directory® für ILM-CM-Server erforderlich. Die erforderlichen Komponenten und die jeweiligen Versionen finden Sie in Abbildung 2.
Figure 2 Unterstützung der ILM-CM-Infrastruktur (Close Figure 2)

Komponenten | Versionen
Active Directory | Windows Server 2003
Datenbankserver | SQL Server 2000 SP3 (oder höher) oder SQL Server 2005
Zertifizierungsstelle | Windows Server 2003 Enterprise Edition oder Data Center Edition
SMTP | SMTP-Server
Abbildung 1 Architektur von ILM-CM
Abbildung 1 Architektur von ILM-CM
Sobald Sie die ILM-CM-Umgebung vollständig installiert haben, kommunizieren alle Zertifikatsanforderungen mit dem ILM-CM-Server. Der ILM-CM-Server speichert alle zertifikatspezifischen Informationen in der SQL Server-Datenbank, wobei diese Informationen für die Zertifikatsberichterstellung, die Ausgabe von Warnungen und das Aufrechterhalten einer Workflowumgebung herangezogen werden.
Die ILM-CM-Softwarearchitektur besteht im Wesentlichen aus drei großen Teilen: ILM-CM-Server, Zertifizierungsstellen-Plug-Ins und clientseitige Komponenten. Die Serversoftware kann auf einer Zertifizierungsstelle oder auf einem Server installiert und ausgeführt werden, der hauptsächlich für ILM-CM vorgesehen ist. Der ILM-CM-Server kommuniziert dann mit den Zertifizierungsstellen, der SQL Server-Datenbank und Active Directory. Darüber hinaus stellt der Server ein Webportal bereit, in dem die Zertifikatsmananager die Zertifikatsrichtlinien und -Workflows konfigurieren und die Zertifikatsabonnenten ihre Softwarezertifikate anfordern und erneuern.
Damit die Zertifizierungsstellen mit dem ILM-CM-Server kommunizieren können, müssen die ILM-CM-Richtlinie und die Beendigungsmodule auf allen zu verwaltenden Zertifizierungsstellen installiert werden. Mit diesen beiden Modulen werden Zertifikatsinformationen in der Datenbank festgehalten. Wenn eine Zertifizierungsstelle ein Zertifikat ausgibt, sendet das Beendigungsmodul diese Informationen an den ILM-CM-Server, der wiederum die Zertifikatsinformationen in die Datenbank schreibt.
Sollen Smartcards in der Umgebung verwaltet werden, müssen Sie die ILM-CM-Smartcard-Clientsoftware installieren. Diese Software ist auf allen Clientcomputern erforderlich, die mit dem ILM-CM-Server interagieren.

Installation von ILM-CM
Die Installation des ILM-CM-Servers ist recht einfach. Sie werden mit einem Assistenten durch den Prozess geführt. Bevor Sie jedoch den Assistenten starten können, müssen vor der eigentlichen Installation zunächst einige Vorbereitungsschritte erledigt werden.
Als Erstes ist Active Directory und eine ILM-CM-Schemaerweiterung für ILM-CM erforderlich. Die Schemaerweiterung liefert einige zusätzliche Microsoft .NET Framework-Sicherheitsattribute. Diese Attribute sind notwendig, damit ILM-CM die Profilvorlagen implementieren kann.
Auch .NET Framework 2.0 müssen installiert werden, und die zuvor genannten Komponenten (SQL Server, Zertifizierungsstellen, SMTP Server) müssen sich an Ort und Stelle befinden. Wenn ILM-CM auf einem anderen Server installiert werden soll als die Zertifizierungsstelle, dann müssen Sie zur Installation der ILM-CM-Module auf den Zertifizierungsstellen jeweils den ILM-CM-Setupassistenten ausführen. Im Anschluss an die Installation sollten Sie in der Lage sein, über den Browser eine Verbindung zum ILM-CM-Portal herzustellen, indem Sie http://hostname/CLM eingeben.
Um das Ablaufdatum für ein Zertifikat und die Erneuerungsbenachrichtigung zu aktivieren, konfigurieren Sie den ILM-CM-Dienst auf dem ILM-CM-Server. Legen Sie als Erstes ein geeignetes Konto in Active Directory an. Wechseln Sie zu den ILM-CM-Diensten, und fügen Sie dieses Konto als Anmeldekonto hinzu. Nehmen Sie dann den betreffenden Benutzer in die Gruppe der lokalen Administratoren und in die IIS_WPG-Gruppe im ILM-CM-Server auf, und tragen Sie ihn mithilfe der Gruppenrichtlinien für die Berechtigungen „Als Teil des Betriebssystems agieren“, „Sicherheitsüberprüfung generieren“ und „Ein Prozessebenentoken ersetzen“ ein. Sobald der ILM-CM-Dienst eingerichtet ist, kann der ILM-CM-Server die SQL Server-Datenbank nach abgelaufenen Zertifikaten durchsuchen und den Inhabern oder Verwaltern dieser Zertifikate eine E-Mail-Benachrichtigung senden.

ILM-CM-Verwaltung
Die Verwaltung von ILM-CM erfolgt über eine Weboberfläche, die in mehrere Funktionsbereiche mit Verwaltungsaufgaben für Benutzer, Zertifikate und Smartcards gegliedert ist. Wenn eine Verbindung zum ILM-CM-Portal mit den notwendigen Administratorrechten vorliegt, wird hier eine Reihe von administrativen Aufgaben aufgeführt, mit denen Sie die ILM-CM-Umgebung verwalten (siehe Abbildung 3). Der Abschnitt mit den gemeinsamen Aufgaben enthält verschiedene Verwaltungsoptionen, beispielsweise zum Registrieren von Benutzern für eine neue Gruppe von Zertifikaten oder für eine Smartcard. Darüber hinaus können Sie auch Anforderungen verwalten und genehmigen.
Abbildung 3 Aufgaben im ILM-CM-Verwaltungsportal
Abbildung 3 Aufgaben im ILM-CM-Verwaltungsportal
Im Aufgabenbereich zum Verwalten von Benutzern und Zertifikaten können Sie nach Benutzern und Zertifikaten suchen. Hier finden Sie Aufgaben zum Suchen, Wiederherstellen, Sperren oder Erneuern von Zertifikaten. Auch eine Sperrliste wird hier angeboten.
Wenn Ihr Unternehmen Smartcards verwendet, ist der Abschnitt über die Verwaltung der Benutzersmartcards praktisch. Hat beispielsweise ein Benutzer seine Karte gesperrt, kann der Zertifikatsverwalter die Karte hier wieder entsperren. Hier können Sie außerdem Smartcards suchen und im lokalen Kartenlesegerät anzeigen.
Im Abschnitt über die Anforderungen in der Benutzeroberfläche können die Zertifikatsverwalter die Zertifikatsanforderungen der Benutzer überprüfen und genehmigen. Rufen Sie beispielsweise alle Zertifikate mit ausstehender Anforderung ab. Im Bereich für die Verwaltung können Sie Profilvorlagen erstellen und verwalten. Mit dem Bereich für die Berichte lassen sich Berichte über Benutzer und Zertifikate entwickeln und erstellen.
Wenn Sie sich beim ILM-CM-Portal anmelden und Ihr Konto nicht die erforderlichen Administratorrechte besitzt, wird eine Abonnentenseite geöffnet, auf der verschiedene benutzerverantwortliche Verwaltungsfunktionen für Zertifikate angeboten werden (siehe Abbildung 4). Von diesem Portal aus können die Benutzer ihre Zertifikate und Smartcards gemäß ihrer speziellen Richtlinienkonfiguration abrufen und verwalten. Gemeinsame Aufgaben sind beispielsweise die Anforderung von Zertifikaten oder Smartcards, die Überprüfung vorhandener Zertifikate oder die Änderung der Smartcard-PINs.
Abbildung 4 Abonnent Portalseite für Benutzer Selbstverwaltung
Abbildung 4 Abonnent Portalseite für Benutzer Selbstverwaltung
Die Bereitstellung eines qualitativ hochwertigen, delegierten Workflowprozesses für das Veröffentlichen, Erneuern, Ersetzen, Widerrufen und Ersetzen von Zertifikaten oder Smartcards kann für jedes Unternehmen eine bedeutende Herausforderung sein. Mit ILM-CM sind Sie nun in der Lage, diese Aufgaben zu delegieren, um so eine höhere Sicherheit zu erzielen. Angenommen, einer Ihrer Benutzer hat seine Smartcard-PIN vergessen. Mit dem Modul für die Workflowdelegierung könnte der Benutzer nun den Helpdesk-Support anrufen, und das Supportpersonal würde ihm einige Kontrollfragen stellen. Wurden die Fragen richtig beantwortet, könnte das Supportpersonal die Smartcard für den Benutzer wieder entsperren Ein weiteres Beispiel für den delegierten Workflow wäre die Wiederherstellung des EFS-Zertifikats (Encrypted File System) eines Benutzers, wenn dieses Zertifikat versehentlich gelöscht wurde oder sich auf einem verloren gegangenen Laptop befand.

Profilvorlagen
Eine Profilvorlage ist die grundlegende Komponente für den vollständigen Workflow-Verwaltungsprozess von ILM-CM. Eine Profilvorlage gilt als einzelnes administratives Objekt mit mindestens einer Zertifikatsvorlage. Profilvorlagen können je nach Bedarf erstellt und konfiguriert werden, um damit die Funktionsweise des Workflowprozesses in Ihrer Zertifikatumgebung zu verwalten. Der wichtigste Aspekt einer Profilvorlage besteht darin, dass diese Vorlage gleich mehrere Zertifikatsvorlagen enthalten kann, die sich als einzelnes Element verwalten lassen. Die Benutzer können also mit einer einzigen Vorlage verwaltet werden, die den Zertifikatsprozess über seine gesamte Dauer nachverfolgen kann.
Die Profilvorlagen können so konfiguriert werden, dass die Zertifikate auf einem Computer (softwaregestützt) oder auf einer Smartcard (hardwaregestützt) gespeichert werden. Sie können diese Vorlagen durch Duplizieren eines Beispiels aus dem ILM-CM-Administratorportal erstellen. Innerhalb der Profilvorlage können Sie mehrere verschiedene Verwaltungsrichtlinienkomponenten definieren (siehe Abbildung 5).
Abbildung 5 Eine Profilvorlage
Abbildung 5 Eine Profilvorlage
Viele der Richtlinienkomponenten gelten sowohl für Softwareprofile als auch für Smartcardprofile (siehe Abbildung 6). Ein Teil dieser Komponenten soll etwas näher beleuchtet werden. Während der Zertifikatsregistrierung können Sie mit der Registrierungsrichtlinienkomponente bestimmte Kriterien für den Ablauf des Registrierungsprozesses definieren. Richten Sie beispielsweise eine Datensammlung ein, sodass der Benutzer bestimmte Informationen eingeben müsste (z. B. Abteilungscodes, E-Mail-Adressen oder Manager). Sie könnten auch Definitionen erstellen, mit denen automatisch ein offizielles Dokument gedruckt wird, sobald der Benutzer ein Zertifikat registriert hat.
Figure 6 Richtlinien für Softwareprofile (Close Figure 6)

Komponente | Beschreibung
Profildetails | Enthält die allgemeinen Details der Profilvorlage. Hier können Sie der Profilvorlage eine oder mehr Zertifikatsvorlagen hinzufügen.
Duplizierungsrichtlinie | Definiert die Workflowentitäten für ein vorhandenes Zertifikat.
Registrierungsrichtlinie | Definiert den Registrierungsprozess-Workflow.
Onlineaktualisierungsrichtlinie | Ähnlich wie die Erneuerungsrichtlinie; kann jedoch ablaufende Zertifikate, den Zertifikatsinhalt, die Vorlagen und die Smartcardapplets aktualisieren.
Richtlinie für die Wiederherstellung im Auftrag | Stellt den privaten Schlüssel oder die Zertifikate eines Benutzers wieder her.
Erneuerungsrichtlinie | Definiert den Erneuerungsworkflow, wenn ein Zertifikat abläuft.
Wiedereinsetzungsrichtlinie | Definiert den Prozess zum Wiedereinsetzen eines Zertifikats.
Wiederherstellungsrichtlinie | Definiert den Workflow für die Wiederherstellung eines auf einem Computer gespeicherten Benutzerzertifikats, wenn dieses Zertifikat gelöscht oder neu erstellt oder der Computer gestohlen wurde.
Widerrufsrichtlinie | Definiert den Workflow zum Widerrufen aller Zertifikate innerhalb eines Profils.
Die Onlineaktualisierungsrichtlinie kann sich für Ihr Unternehmen als sehr nützlich erweisen. Diese Richtlinie ist ähnlich aufgebaut wie die Erneuerungsrichtlinie, mit dem Unterschied, dass Sie den Zertifikatsinhalt, die Zertifikatsvorlagen, die Applets auf den Smartcards und auch das Zertifikat selbst aktualisieren können, wenn das Ablaufdatum unmittelbar bevorsteht. Um diese Richtlinie vollständig nutzen zu können, müssen Sie den ILM-CM-Dienst und die Datei „web.config“ aktivieren, sodass der Zugriff auf ein Attribut mit mehreren Werten in Active Directory möglich wird. Darüber hinaus muss der Onlineaktualisierungsdienst auf dem Clientcomputer installiert werden.
Die Richtlinie für die Wiederherstellung im Auftrag empfiehlt sich, wenn in Ihrem Unternehmen die EFS-Verschlüsselung verwendet wird. Angenommen, ein Benutzer löscht unbeabsichtigt sein Verschlüsselungszertifikat. Mit dieser Richtlinienkomponente könnten Sie einen Workflow aufstellen, über den das Helpdesk-Sicherheitsteam den privaten Schlüssel des Benutzers anfordert. Der Benutzer könnte dann eine E-Mail mit einem geheimen Kennwort erhalten, das vom ILM-CM-Server generiert wurde, und könnte so seinen privaten Schlüssel erlangen. Anschließend würde er einen geheimen Weblink auf dem ILM-CM-Server öffnen und dort das Zertifikat mit seinen zugeordneten privaten Schlüsseln abrufen. Die Richtlinie für die Wiederherstellung im Auftrag leistet auch dann gute Dienste, wenn ein Mitarbeiter das Unternehmen verlässt und seine Daten zur Archivierung, gemäß gesetzlichen Vorschriften oder aus anderen Gründen wiederhergestellt werden müssen.
Um den Erneuerungsprozess sicherer zu gestalten, können Sie bei der Erneuerungsrichtlinie einen einmaligen, geheimen Kennwortschlüssel erzeugen und per E-Mail versenden, mit dem die Benutzer ihre Zertifikate erneuern müssen. Wenn Sie ein Zertifikat widerrufen und dann wiedereinsetzen und von der Zertifikatssperrliste (Certificate Revocation List, CRL) entfernen möchten, können Sie diesen Prozess mit der Wiedereinsetzungsrichtlinie definieren.
Zwei ganz besondere Richtlinienkomponenten, die nur für Softwarezertifikatsrichtlinien gelten (nicht für Smartcards), sind die Wiederherstellungsrichtlinie und die Widerrufsrichtlinie. Wenn ein auf einem Computer gespeichertes Benutzerzertifikat gelöscht oder der Computer selbst gestohlen wird, kann die Wiederherstellungsrichtlinie den Prozess zum Wiederherstellen des Zertifikats oder der Schlüssel definieren, wenn diese Angaben in der Zertifizierungsstelle archiviert wurden. Mit der Widerrufsrichtlinie kann der Administrator einen statischen Sperrungsgrund festlegen, oder er kann dem Benutzer, der die Sperrung angefordert hat, zum Zeitpunkt der Sperrung die Gelegenheit geben, den Grund für die Sperrung anzugeben.
Es gibt fünf zusätzliche Verwaltungsrichtlinien für Smartcard-Profilvorlagen (siehe Abbildung 7).
Figure 7 Richtlinien für Smartcardprofile (Close Figure 7)

Komponente | Beschreibung
Ersetzungsrichtlinie | Definiert das Profil für den Fall, dass die Smartcard eines Benutzers verloren oder gestohlen wird.
Deaktivierungsrichtlinie | Definiert den Prozess, mit dem Zertifikate auf einer Smartcard vor dem Ablaufen deaktiviert werden.
Außerkraftsetzungsrichtlinie | Definiert den Prozess zum Widerrufen aller Zertifikate auf einer Smartcard.
Entsperrungsrichtlinie | Definiert die Benutzer, die die Benutzer-PIN einer Smartcard entsperren können.
Richtlinie für vorläufige Karten | Definiert eine kurzfristig eingesetzte Ersatzsmartcard. Der Benutzer erhält neue Signaturenzertifikate, könnte jedoch ihre Daten entschlüsseln, wenn er die vorhandenen Profilverschlüsselungszertifikate aufruft.
Für die Außerkraftsetzungsrichtlinie können Sie verschiedene Vorgänge definieren, beispielsweise Löschen der Benutzerdaten auf der Smartcard, Sperren der Benutzer- und Administrator-PINs, Zurücksetzen der Administror-PIN. Die Entsperrungsrichtlinie kommt meist dann zum Einsatz, wenn ein Benutzer seine PIN vergessen hat oder eine neue Karte mit einer PIN von ILM-CM erhält. In diesem Fall sendet der Benutzer eine Anforderung, die Smartcard zu entsperren.
Wie alle administrativen Produkte ist die Berichterstellung eine äußerst nützliche Funktion. Die Möglichkeit, eine Momentaufnahme der Zertifikats- oder Smartcardumgebung festzuhalten, ist für jedes Unternehmen von großer Bedeutung. ILM-CM umfasst mehrere integrierte Berichte, beispielsweise Smartcardbestände, Anforderungsübersichten, Nutzung und Ablaufdatum der Zertifikate und vieles mehr. Sämtliche Daten sind in einer SQL Server-Datenbank gespeichert; wenn Sie also weitere Berichte benötigen, können Sie eine benutzerdefinierte Abfrage schreiben, wie bei allen Berichterstellungssystemen.

Entwickeln eines Workflows
Im Folgenden soll betrachtet werden, wie ILM-CM dazu beiträgt, einen produktiven Workflowprozess zu definieren. Angenommen, Sie beschäftigen mehrere Systemadministratoren, die für die Verwaltung und Pflege von SSL-Zertifikaten für ihre Systeme zuständig sind. Die erste Frage: Was sind die wichtigsten Aspekte im Prozess?
Je nach der Art des Systems kann der Prozess unterschiedliche Methoden zum Erstellen der Zertifikatsanforderungsdatei erfordern. Die erste Aufgabe besteht also darin, eine Intranetseite mit ausführlichen Anweisungen für die Erstellung der Zertifikatsanforderungen für sämtliche Systeme zu entwickeln.
Sobald der Administrator die Anforderungsdatei erstellt, kann er diese Datei zur Genehmigung des Zertifikats an das ILM-CM-Benutzerportal senden. Mit dem ILM-CM-Workflowprozess kann der Administrator mehrere Genehmiger definieren, die die einzelnen Zertifikatsanforderungen überprüfen und genehmigen sollen. Sobald ein Zertifikat genehmigt wurde, kann der Benutzer das Zertifikat vom ILM-CM abrufen. Der ILM-CM speichert die Zertifikatsinformationen in eine SQL Server-Datenbank, sodass die Administratoren auch Verlaufsdaten abrufen können.
Ein Jahr später, wenn das Zertifikat sich seinem Ablaufdatum nähert, sendet der ILM-CM dem anfordernden Benutzer eine E-Mail-Benachrichtigung, mit der er informiert wird, dass das Zertifikat in Kürze ablaufen wird und dass er das Zertifikat erneuern muss. Mit diesem Workflowprozess beugen Sie den unliebsamen Überraschungen vor, wenn Zertifikate unerwartet ablaufen und Ihren Arbeitstag verderben.

Zusammenfassung
Wenn Ihr Unternehmen eine Microsoft PKI-Umgebung nutzt, kann ILM-CM die Verwaltung erleichtern. Mit dem ILM-CM ist ein Unternehmen in der Lage, die Prozesse zur Sicherheitsauthentifizierung zu verbessern und so die Kosten und die Komplexität der digitalen Zertifikate und der Smartcardverwaltung zu verringern. Der ILM-CM bildet außerdem die Grundlage für die Entwicklung von Zertifikats- und Smartcard-Workflowprozessen, die in vielen Unternehmen heute noch fehlen.
Microsoft hat zudem die externe API-Unterstützung für den ILM-CM implementiert. Wenn Ihr Unternehmen benutzerdefinierte Anwendungen einsetzt, können Sie diese Anwendungen ggf. zusammenschließen und so die API-Unterstützung des ILM-CM nutzen.
Weitere Informationen zu ILM-CM finden Sie unter microsoft.com/technet/clm. Auch eine Kurzanleitung ist verfügbar (go.microsoft.com/fwlink/?LinkId=87336).

Kevin Dallmann ist Senior Systems Engineer-Berater bei Accenture und ist hauptsächlich für die Unterstützung von Active Directory- und PKI-Umgebungen in großen Unternehmensumgebungen zuständig. Dallman ist als MCSE und MCT zertifiziert und hält auch Microsoft-Kurse ab.


 Mitteilung der Redaktion: Sicherheitsaspekte
Mitteilung der Redaktion
Sicherheitsaspekte
Joshua Trupin

Ist Ihnen bereits aufgefallen, dass Sicherheitsaspekte in letzter Zeit etwas überschaubarer geworden sind? Natürlich würden wir hier beim TechNet Magazin gern alle Lorbeeren dafür einheimsen, doch es kommen dabei auch noch ein paar andere Faktoren ins Spiel. Die beiden wichtigsten Faktoren sind Sicherheitsbewusstsein und Stabilität.
Sicherheitsbewusstsein bedeutet, sich der potenziellen Bedrohungen und der Tricks des Social Engineering bewusst zu sein und mit den regelmäßigen Patches und Updates Schritt zu halten, um die installierte Software zu schützen. Stabilität ist die andere Komponente – die Idee, dass eine Software so erstellt werden kann, dass sie sicherer ist und ihre Angriffsfläche durch standardmäßiges Deaktivieren verfügbarer Features minimiert wird.
Ach ja, da fehlt noch ein Faktor, die regelmäßige Lektüre des TechNet Magazins. Das darf natürlich nicht fehlen! Sie lesen gerade unsere beinahe berühmte Sicherheitsausgabe. Diese Ausgabe enthält sieben Artikel, die Ihnen dabei helfen, in Ihrem Unternehmen zu einem erfahreneren Sicherheitsanalysten und -praktiker zu werden. Zur Einführung lesen Sie Mark Russinovichs Artikel zu UAC-Interna. Steve Riley beschäftigt sich eingehend mit der Windows-Firewall, und Jesper Johansson untersucht die ACL-Änderungen in Windows Vista. Außerdem erörtert Jeremy Moskowitz die Gruppenrichtlinie und Hardwaresperrungen, Michael Murgolo schreibt über PowerToys für die Skripterhöhung, und vieles mehr. Die vorliegende Ausgabe könnte ohne Übertreibung die beste Zeitschrift sein, die jemals veröffentlicht wurde.
Da Sicherheit bestimmt ganz oben auf Ihrer Liste steht, sollten Sie das neueste Sicherheitsangebot von Microsoft kennen lernen. Microsoft Forefront repräsentiert den „Stabilitätsfaktor“ und besteht aus einer Reihe von Sicherheitsprodukten, die Schutz in den folgenden drei Bereichen bieten: Clientbetriebssysteme, Anwendungsserver und Netzwerkrand. Es umfasst Sicherheitstools für Exchange Server und SharePoint sowie ISA Server und Intelligent Application Gateway für den Netzwerkverkehr. Microsoft System Center verkörpert das fehlende Stück „Bewusstsein“ im Puzzle, da es Ihnen Informationen über Ihre Systeme bietet, Vorgänge und Verwaltung optimiert, Berichte generiert und die Bereitstellung von Diensten verbessert. Es enthält unter anderem Tools für die nächste Generation der Konfigurationsverwaltung sowie Technologien zur Vorgangsüberwachung.
Weitere Informationen zu Forefront und System Center erhalten Sie auf der Microsoft-Infrastrukturwebsite unter Microsoft.com/infrastructure. Finden Sie die besten Lösungen für Ihre Sicherheitsfragen zu den Themen Sicherheitsbewusstsein und Stabilität im TechNet Magazin.
Joshua Trupin

Unser Dank gilt folgenden technischen Experten von Microsoft: Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher und Buck Woody.


 Toolbox: Neue Produkte f&#252;r IT-Profis
Toolbox Neue Produkte für IT-Profis and Greg Steen
myLittleAdmin zeichnet sich durch eine Schnittstelle mit anpassbarem Design aus
Die webbasierte Benutzeroberfläche unterstützt die meisten Datenbankvorgänge einschließlich der Erstellung neuer Datenbanken, der Verwaltung vorhandener Datenbanken und ihrer Inhalte sowie der Arbeit mit Snapshots und Schemas. Die Eigenschaften vorhandener Datenbankobjekte lassen sich einfach bearbeiten, und myLittleAdmin hat ein nützliches bearbeitungsfähiges Datenraster zum Ändern einzelner Zeilen in Ihren Tabellen. Die Schnittstelle der Strukturansicht ähnelt stark der Strukturansicht in SQL Server Management Studio. Daher erfordert die Anwendung etwas Lernaufwand. Der einzige Haken ist, dass einige vertraute Klicks mit der rechten Maustaste nicht das erwartete Kontextmenü anzeigen.
Sie können myLittleAdmin auch verwenden, um Anmeldungen, Serverrollen und Anmeldeinformationen Ihrer SQL-Instanz zu bearbeiten. Es lassen sich damit sogar Datensicherungsgeräte und verknüpfte Server erstellen und bearbeiten: nützliche Aufgaben, die das Arbeiten von einem Remotestandort aus ermöglichen.
Mit myLittleAdmin können Sie auch Aufgaben wie Ad-hoc-Abfragen, Anfügen und Trennen von Datenbanken, Sichern und Wiederherstellen, Importieren von CSV-Daten und Verkleinern von Datenbanken durchführen. Sie können sogar zum Fehlerprotokoll und Aktivitätsmonitor wechseln, um Problembehandlungen vorzunehmen.
Preis: Ab 590 $ für eine Einzelserverlizenz. Als Teil Ihres Webhosting-Toolsets für Kunden: ab 990 $ für eine Einzelserverlizenz.


 SQL&#160;– Fragen und Antworten: 64-Bit-Installationen, Zuweisen von Clusterspeicher und mehr
SQL – Fragen und Antworten 64-Bit-Installationen, Zuweisen von Clusterspeicher und mehr and Herausgegeben von Nancy Michell
Abbildung 1Suche in der SQL Server-Onlinedokumentation über Windows Live
Aber angenommen, der gesamte Arbeitsspeicher für SQL Server befindet sich auf einem einzigen Server, und eine neue Instanz von SQL Server wird gestartet. Was passiert mit dem Speicher der ursprünglichen SQL Server-Instanz? Ich sollte wohl für den schlimmsten Fall vorausplanen, also dass nur ein einziger Knoten noch funktionstüchtig ist und alle Instanzen von SQL Server am Ende auf diesem Knoten ausgeführt werden.
A: In der Regel sollte der maximale Serverspeicherwert unterhalb der gesamten verfügbaren Speichermenge im Computer liegen. Ein Drittel des gesamten Speichers dürfte in Ihrer Situation jedoch eher nicht die beste Konfiguration sein.
Sie machen sich Sorgen, dass drei der vier Server in Ihrem Cluster gleichzeitig ausfallen könnten und dass die drei SQL Server-Instanzen auf dem vierten Knoten landen würden. Dieses Szenario ist allerdings unwahrscheinlich.
In den meisten Fällen tun Sie besser daran, jede Instanz so zu konfigurieren, dass der größte Teil des verfügbaren Speichers auf den einzelnen Knoten verwendet wird. Angenommen, jeder Knoten ist mit 32 GB Arbeitsspeicher ausgestattet. Dann wäre eine maximale Serverspeichermenge von etwa 28 GB pro Instanz vernünftig.
Wenn nun ein Knoten ausfällt, würde das Failover für die auf diesem Knoten ausgeführte Instanz auf den passiven Knoten durchgeführt, und die Instanz könnte möglicherweise den Zugriff auf 28 GB des Speichers erhalten. Die anderen beiden Instanzen blieben unverändert und werden nach wie vor auf den anderen beiden Knoten im Cluster ausgeführt.
Sie erwähnten, dass Sie einen Failovercluster mit vier Knoten, fünf SQL Server-Instanzen und einer Analysis Services-Instanz betreiben. Wenn Sie SQL Server 2000 mit AWE (Address Windowing Extensions) einsetzen, müssen Sie einige sorgfältig ausgewählte Speicherbereiche für die Instanzen der relationalen Module reservieren, weil diese Module den einmal belegten Speicher nicht mehr freigeben. In der flexibleren Situation mit SQL Server 2005 und 64-Bit-Instanzen, die auf einen großen Adressbereich mit oder ohne AWE zugreifen können, sieht die Sache ganz anders aus. Selbst wenn Sie AWE hier nutzen würden, bleibt die Anwendung dynamisch, und auf Anforderung kann Speicher freigegeben werden. Die Antwort auf die Frage, was mit der ursprünglichen SQL Server-Instanz und dem zugehörigen Speicher in einer Failoversituation passiert, in der eine neue Instanz auf dem Computer gestartet wird, ist also davon abhängig, ob Sie SQL Server 2000 oder SQL Server 2005 ausführen und ob AWE zum Einsatz kommt.
Die Vorausplanung für den schlimmsten Fall ist im Grunde genommen eine gute Idee. Praktisch gesehen ist es allerdings eher unwahrscheinlich, dass drei von vier Knoten in einem Cluster mit fünf Instanzen des relationalen SQL Server-Moduls und einer Analysis Services-Instanz ausfallen, sofern Sie das System nicht „überzüchtet“ haben. Der verbleibende Knoten besitzt nicht genügend CPU-Ressourcen, um die ursprünglichen Instanzen mit vergleichbarer Leistung betreiben zu können. Und darum sollten Sie die Lösung besser so anlegen, dass die optimale Leistung beim Verlust eines einzigen Knotens erhalten bleibt, während beim Ausfall mehrerer Knoten ein manuelles Eingreifen erforderlich wird. Damit erzielen Sie in der Regel eine gute Kombination aus der Unterstützung der hohen Verfügbarkeit und der Möglichkeit, kostenintensive Ressourcen angemessen zu nutzen.
Und bei SQL Server 2005 sind die Endbenutzer in der Lage, den Cluster auf bis zu acht Knoten zu skalieren. Bei SQL Server 2000 konnte ein Server maximal vier Knoten umfassen.

Einschränkungen bei der Spiegelung
F: Ich habe mich über die Datenbankspiegelung bei SQL Server 2005 informiert, und dabei bin ich auf eine Einschränkung gestoßen, nach der die Datenbankspiegelung nur maximal zehn Datenbanken pro Serverinstanz unterstützen kann. Ich brauche zwei getrennte SQL Server-Instanzen mit separatem Speicher, mit automatischem Failover zwischen den beiden Instanzen und mit Datenredundanz.
Ich möchte die SQL Server 2005-P2P-Transaktionsreplikation (Peer-to-Peer) in Kombination mit Microsoft® Cluster Server (MSCS) nutzen, wobei eine Cluster-IP-Adresse auf einen der beiden Knoten verweist, so dass der gesamte Datenverkehr (Einfügen, Aktualisieren, Löschen, Lesen) über einen einzigen Knoten im Cluster läuft. Der sekundäre Knoten würde als passiver Knoten behandelt; die Transaktionen würden allerdings auf diesen Knoten repliziert. Bei einem Ausfall würde MSCS das Failover dieser IP-Adresse auf den anderen Knoten durchführen. Aufgrund der bidirektionalen P2P-Konfiguration müsste kein manueller Prozess erledigt werden, um die Transaktionen auf dem anderen Knoten zu veröffentlichen (sofern eine Sicherungskopie für den Knoten angelegt wurde). Mit der MNS-Konfiguration (Majority Node Set) in MSCS würde ich den Bedarf an einer freigegebenen Datenträgerressource für das Quorum verringern.
Die Spiegelung ist immer noch nicht vom Tisch. Wir haben die Anzahl der Datenbanken von 1000 auf 100 Datenbanken pro SQL Server-Cluster gesenkt. Sollte trotzdem dieselbe Ressourcenlast auf den Systemen verbleiben?
A: Weitere Informationen und Anweisungen zur SQL Server-Spiegelung finden Sie in BOL sowie beim SQL Server Tech Center unter microsoft.com/technet/prodtechnol/sql und msdn2.microsoft.com/sql.
Ihre Frage hat für viel Gesprächsstoff gesorgt. Nachdem die gutmütigen Neckereien verebbt waren, konnten die folgenden Antworten für Ihr Szenario zusammengestellt werden:
Antwort Nr. 1: Die Anzahl der Datenbanken, die in einer gegebenen Instanz gespiegelt werden kann, ist nicht explizit beschränkt. Ich nehme an, Sie haben einen Artikel gelesen, in dem steht, dass nicht mehr als 10 Datenbanken pro Instanz gespiegelt werden sollten. Dieser Wert ist allerdings nur ein Anhaltspunkt, und es werden keine Beschränkungen durchgesetzt. Alles steht und fällt mit den verfügbaren Ressourcen für das betreffende System.
Die Spiegelung wäre eine Möglichkeit, aber bei 1.000 Datenbanken artet die Sache jedoch aus, es sei denn, Sie nutzen einen ultrahochleistungsfähigen Server. Wenn Sie keinen freigegebenen Speicher verwenden möchten, aber die integrierten SQL Server-Technologien, können Sie unter Spiegelung, Protokollversand und Replikation wählen. Jedes Verfahren hat seine Vor- und Nachteile.
Antwort Nr. 2: Wenn Sie zahlreiche Datenbanken betreiben, keinen freigegebenen Speicher nutzen und eine Lösung zur Notfallwiederherstellung von Microsoft suchen, sollten Sie den Protokollversand mithilfe einer Reihe kleiner, benutzerdefinierter Hilfsprogramme in Erwägung ziehen, um so den Verwaltungsaufwand zu senken. Ein Programm kann der Reihe nach eine Sicherungskopie für alle Datenbanken erstellen und wiederherstellen, so dass Sie nicht mehrere Protokollversandagenten ausführen müssten. Hierbei besteht allerdings die Gefahr, dass Daten verloren gehen. Es gibt keine integrierte Lösung, bei der Sie nicht auf freigegebenen Speicher oder auf ein DBMS zugreifen müssen, um Datenverlust zu vermeiden.
Natürlich gibt es da noch das Problem, wie MSCS einen drohenden Ausfall erkennt und das Failover durchführt. MNS-Konfigurationen in einem Cluster machen freigegebenen Speicher normalerweise nicht völlig überflüssig; durch diese Konfigurationen entfällt einfach die Notwendigkeit, ein dediziertes freigegebenes LUN für das Quorum zu unterhalten. Dieser Plan funktioniert nur dann, wenn der Cluster so konfiguriert wird, dass ausschließlich die IP-Adressen und die Netzwerknamen verwaltet werden. SQL Server kann ohne freigegebenen Speicher nicht in einen Cluster aufgenommen werden, so dass Sie auch den SQL Dienst nicht clustern könnten. Das bedeutet, dass den Cluster nicht in der Lage ist, die SQL Server-Dienste in einer normalen Konfiguration zu erkennen und zu überwachen.
Sie könnten den SQL Server-Dienst als generischen zu überwachenden Dienst einfügen und so das Clustern auf Umwegen erzielen. In diesem Fall entsteht das Problem erst beim Failover: Wenn der Dienst in den Cluster aufgenommen würde, dann würde MSCS versuchen, den Dienst beim Failover auf dem passiven Knoten online zu schalten, wobei dort jedoch schon ein SQL-Dienst ausgeführt würde. Selbstverständlich könnten Sie damit einfach die IP-Adressen und die Netzwerknamen clustern und dann das Failover im Bedarfsfall manuell vornehmen. Dies gilt auch für den Netzwerklastenausgleich (Network Load Balancing, NLB), der an anderer Stelle erfolgt. Weitere Informationen finden Sie unter microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx.
In Anbetracht der Anzahl von Datenbanken, die unterstützt werden sollen, dürfte eine Protokollversandlösung bessere Dienste leisten. Sie müssten den Prozess natürlich mit einem DTS/SSIS-Paket (Data Transformation Services/SQL Server Integration Services) automatisieren, weil sonst wohl zu lange dauern würde, die aktiven Protokolle bei einem Ausfall manuell zu sichern, zu verschieben und anzuwenden.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci; Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren und ganz besonders Buck Woody.


 Schwerpunkt Dienstprogramme: Skripterh&#246;hungs-PowerToys f&#252;r Windows Vista
Schwerpunkt Dienstprogramme Skripterhöhungs-PowerToys für Windows Vista and Michael Murgolo
Laden Sie den Code für diesen Artikel herunter: Utility2007_06.exe (159KB)
Während die Benutzerkontensteuerung für eine wichtige Verbesserung der Sicherheit sorgt, ist die Möglichkeit zum Erhöhen der Berechtigungen für die Durchführung bestimmter Verwaltungsaufgaben und Funktionen unerlässlich. Im Folgenden werden einige Elevation PowerToys vorgestellt, die diese Erhöhung flexibler und leistungsfähiger gestalten.
Unter den zahlreichen neuen Features, die zur Behandlung von Sicherheitsaspekten in Windows Vista eingeführt wurden, nimmt die Benutzerkontensteuerung (User Account Control, UAC) eine der höchsten Positionen ein. Mit der Benutzerkontensteuerung können sogar Benutzer, die als Administratoren fungieren, die meisten Anwendungen mit Standardberechtigungen ausführen, erhalten jedoch ein „Erhöhungspotential“ für bestimmte Verwaltungsaufgaben und
Anwendungsfunktionen. Ich nutze Windows Vista™ seit mehreren Monaten, und das Erhöhen einer Aufgabe oder Anwendung nach Bedarf ist mir in Fleisch und Blut übergegangen. Bei einigen Aufgaben in Windows Vista stolperte ich allerdings über einige Mängel, als ich diese Aufgaben erhöhen wollte, und das wurde wirklich frustrierend.
Ganz im Geiste der alten Windows® PowerToys habe ich daher einige Script Elevation PowerToys erstellt, die diese Einschränkungen überwinden. Alle im Folgenden vorgestellten PowerToys befinden sich im Codedownloadbereich unter technetmagazine .com/code07.aspx. Im Artikel vom November 2006 mit dem Titel „Mit User Account Control sind Programme ohne Administratorrechte kein Traum mehr“ von Alex Heaton (siehe Randleiste „Zusätzliche Ressourcen“) können Sie lesen, wie die UAC funktioniert.

Elevate Command PowerToy
Der erste ärgerliche Punkt lag darin, dass es keine Methode gab, um eine Anwendung über die Befehlszeile oder über das Dialogfeld „Ausführen“ zu erhöhen. Nachdem ich mich ein wenig bei Microsoft umgehört hatte, stieß ich auf ein Beispielskript von John Stephens (Softwareentwickler bei Microsoft) mit genau den Informationen, die ich brauchte. Wenn Sie das Verb „runas“ an die ShellExecute-API senden oder auch an das COM-Gegenstück, die Methode „ShellExecute“ von „Shell.Application“, werden Sie durch die gestartete Anwendung aufgefordert, die Erhöhung vorzunehmen (siehe Randleiste). Damit konnte ich das erste Elevation PowerToy erstellen, nämlich das Elevate Command PowerToy.
Dieses Tool (bestehend aus den Dateien „ElevateCommand.inf“, „elevate.cmd“ und „elevate.vbs“) ergänzt das System um einen Erhöhungsbefehl. Damit können Sie Anwendungen starten, bei denen Sie über eine Befehlszeile, über ein Skript oder über das Dialogfeld „Ausführen“ zur Erhöhung aufgefordert werden. Mit dem folgenden Befehl öffnen Sie beispielsweise die Datei „Win.ini“ im Editor (nach der Aufforderung zur Erhöhung):
elevate notepad c:\Windows\Win.ini
Wenn Sie den Befehl „elevate“ in Windows Script Host (WSH), Windows PowerShell™ oder andere Skripts einsetzen, müssen Sie die ausführbare Datei des Skripthosts (z. B. „wscript“, „cscript“ oder „powershell“) als Anwendung angeben. So würden Sie beispielsweise ein vbs ausführen:
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
Abbildung 2Eingabeaufforderungen mit erhöhter Berechtigung

Installation und Implementierung
Um diese PowerToys zu installieren, klicken Sie mit der rechten Maustaste auf eine INF-Datei, wählen Sie die Option „Installieren“, und genehmigen Sie die Erhöhung. Zur Deinstallation verwenden Sie das Dienstprogramm für Programme und Features in der Systemsteuerung.
Falls Sie einen eingehenden Blick in die INF-Dateien werfen und sich dabei fragen, warum die Dateien „elevate.cmd“ und „elevate.vbs“ von drei PowerToys in verschiedenen Pfaden installiert werden, folgt hier eine kurze Erklärung. Bei den meisten PowerToys wird der Unterschlüssel „runas“ in den Schlüssel HKEY_CLASSES_ROOT\objecttype\Shell“ für den Objekttyp in der Registrierung eingefügt.
Einige PowerToys besitzen allerdings Objekttypen, für die ich zwei Kontextmenüeinträge für die Erhöhung erzielen wollte („CMD Prompt Here as Administrator“ und „PowerShell Prompt Here as Administrator“ für Laufwerks- und Verzeichnisobjekttypen, „Ausführen als Administrator“ und „Run as Administrator with Command Prompt für alle WSH-Objekttypen). Ein Objekttyp kann nur einen einzigen Schlüssel mit „runas“ umfassen. Ich musste also die zweite Aktion durch einen Aufruf des Befehls „elevate“ implementieren. Doch weil ich erreichen wollte, dass jede INF für sich allein installiert und deinstalliert werden kann, musste ich die zugehörigen Kopien „elevate.cmd“ und „elevate.vbs“ an verschiedenen Speicherorten ablegen. (Es ist nicht möglich, den Zähler für die Dateinutzung über eine INF-Rohdatei zu inkrementieren. MSI-Installationsprogramme wären sicherlich besser geeignet, aber ich wollte Installationsprogramme realisieren, die in einem Texteditor erstellt und geändert werden können.) Als Nebeneffekt zeigen nur die Kontextmenüeinträge, die mit dem Schlüssel „runas“ implementiert wurden, ein Schild im Menü.

Zusammenfassung
Ich hoffe, dass Sie diese Tools nützlich finden und dass Sie Ihnen bei Ihrer Arbeit mit UAC helfen. Vielleicht lassen Sie sich sogar dazu anregen, selbst PowerToys zu entwickeln. (Benutzer, die andere Skriptsprachen wie Perl oder Python unter Windows Vista nutzen, sollten mühelos in der Lage sein, ein PowerToy „Elevate Script“ für diese Sprachen zu erstellen.) Wie bei allen PowerToys gilt: Diese Tools werden nicht unterstützt, und die Nutzung dieser Tools erfolgt auf Ihr eigenes Risiko. So oder so: Viel Spaß beim Erhöhen!
Zusätzliche Ressourcen
  • Mit User Account Control sind Programme ohne Administratorrechte kein Traum mehr
  • Übersicht über die Benutzerkontensteuerung
  • Erhöhung über ShellExecute
  • ShellExecute-Methode
  • Verben und Dateizuordnungen
  • An Old PowerToy Is New Again


 The Cable Guy: Das Secure Socket Tunneling-Protokoll
The Cable Guy Das Secure Socket Tunneling-Protokoll and Joseph Davies
Dieser Artikel basiert auf einer Vorabversion von Windows Server mit dem Codenamen „Longhorn“. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.
VPN-Protokolle in Windows XP und Windows Server 2003 funktionieren für einige Konfigurationen nicht. Verschaffen Sie sich einen gründlichen Einblick in die verschiedenen Probleme und erfahren Sie, wie Windows Server „Longhorn“ und Windows Vista mit Service Pack 1 das Secure Socket Tunneling-Protokoll verwenden, um diese Probleme zu lösen.
Die Unterstützung virtueller privater Netzwerke (VPN) in Windows XP und Windows Server 2003 ermöglicht Ihnen, über das Internet eine Verbindung zu Ihrem privaten Intranet herzustellen, so als wäre Ihr Computer an einem lokalen Ethernetport angeschlossen. VPN-Protokolle in Windows XP und Windows Server 2003 funktionieren allerdings nicht für einige Firewallkonfigurationen
sowie für einige indirekte Konfigurationen – wenn sich z. B. Ihr Computer hinter einem NAT-Gerät (Übersetzer für Netzwerkadressen) oder einem Webproxyserver befindet – in denen der Datenverkehr für VPN-Verbindungen gesperrt ist. Um diese Schwierigkeiten zu beseitigen, umfassen die nächste Version von Windows Server® mit dem Codenamen „Longhorn“ und Windows Vista™ mit Service Pack 1 (beide in der Betatestversion) Unterstützung für das neue Secure Socket Tunneling-Protokoll (SSTP).

VPN-Zugriffsprobleme
Die VPN-Protokolle, die in Windows® XP und Windows Server 2003 Remotezugriffsverbindungen zu einem Intranet über das Internet aktivieren, sind das Point-to-Point-Tunneling-Protokoll (PPTP) und das Layer-Two-Tunneling-Protokoll mit Internetprotokollsicherheit (L2TP/IPsec). Sie stellen die Kapselung der Pakete bereit, die zwischen einem Remotezugriffsclient und dem Intranet gesendet werden, mit dem er verbunden ist.
PPTP-basierter VPN-Datenverkehr besteht aus einer TCP-Verbindung zum TCP-Port 1723 auf dem VPN-Server, um den Tunnel zu verwalten, und aus GRE (Generic Routing Encapsulation)-gekapselten Paketen für die VPN-Daten. PPTP-Datenverkehr kann jedoch Probleme mit Firewalls, NATs und Webproxys haben. Um Probleme zu vermeiden, müssen Firewalls so konfiguriert werden, dass sie sowohl die TCP-Verbindung als auch GRE-gekapselte Daten ermöglichen. Obwohl GRE eine Standardmethode zur Kapselung von IP-Paketen ist, löschen viele Internetdienstanbieter (ISPs) diese Pakete, was Datenverluste zur Folge hat. Außerdem sind die in Hotels und Cafés vorhandenen Verbindungen üblicherweise für normalen Web- und E-Mail-Datenverkehr konfiguriert und erlauben möglicherweise keinen PPTP-Datenverkehr. Wenn sich Ihr Computer darüber hinaus hinter einem NAT-Gerät befindet, muss das NAT-Gerät den GRE-Datenverkehr übersetzen können. Wenn es das nicht kann, können Sie zwar die TCP-Verbindung herstellen, nicht aber GRE-gekapselte Daten senden oder empfangen. Letzter Punkt: PPTP-Datenverkehr kann nicht durch einen Webproxy fließen.
Das andere in Windows XP und Windows Server 2003 verfügbare VPN-Protokoll, L2TP/IPsec, verwendet Internetschlüsselaustausch (IKE), um den Schutz des VPN-Datenverkehrs durch IPSec ESP (Encapsulating Security Payload) auszuhandeln, und auch bei diesem können Probleme mit Firewalls, NATs und Webproxys auftreten.
In diesem Setup müssen Firewalls so konfiguriert werden, dass sie sowohl den IKE-Datenverkehr als auch ESP-gekapselte Daten ermöglichen. Wenn sich der VPN-Clientcomputer hinter einem NAT-Gerät befindet, müssen sowohl der VPN-Client als auch der VPN-Server IPSec NAT-Traversal (NAT-T) unterstützen. Beachten Sie jedoch, dass sich der VPN-Server nicht hinter einem NAT-Gerät befinden darf, und dass L2TP/IPsec-Datenverkehr nicht durch einen Webproxy fließen kann.

Die neue VPN-Lösung
Wie Sie sehen, gibt es eine Reihe von Problemen bei der Ausführung des VPN-Protokolls in Windows XP und Windows Server 2003. Die gute Nachricht ist, dass SSTP in Windows Vista mit Service Pack 1 und Windows Server „Longhorn“ diese VPN-Konnektivitätsprobleme mithilfe von HTTPS über SSL (Secure Sockets Layer) löst. SSL wird auch Transport Layer Security (TLS) genannt. HTTP über SSL auf TCP-Port 443 ist das Protokoll, das seit einer gewissen Zeit im Internet zum Erfassen von Kreditkartennummern und anderer privater Daten verwendet wird. Immer wenn Sie eine Verbindung zu einer Webadresse herstellen, die mit „https:“ beginnt, verwenden Sie HTTP über SSL.
Die Verwendung von HTTP über SSL löst viele Konnektivitätsprobleme des VPN-Protokolls: Firewalls, NATs und Webproxys ermöglichen normalerweise diese Art des Datenverkehrs, weil diese so weit verbreitet ist.
SSTP verwendet eine HTTP-über-SSL-Sitzung zwischen VPN-Clients und -Servern, um gekapselte IPv4- oder IPv6-Pakete auszutauschen. Beachten Sie, dass eine HTTP-über-SSL-basierte RAS-VPN-Verbindung anders ist als die Verbindung, die von einer Anwendung hergestellt wird, die HTTP über SSL verwendet. Mit Outlook® Web Access (OWA) können Sie beispielsweise in Ihrem Unternehmen über das Internet auf Ihre Microsoft Exchange-E-Mails zugreifen. OWA verwendet eine HTTP-über-SSL-verschlüsselte Sitzung, aber diese ist nicht identisch mit einer Remotezugriffsverbindung. Obwohl Sie Ihre E-Mails mit OWA anzeigen können, können Sie nicht auf den Speicherort einer Intranet-URL zugreifen, die in eine Exchange-E-Mail-Nachricht eingebettet ist.
(SSTP unterstützt keine authentifizierten Webproxykonfigurationen, in denen der Proxy während der HTTPS-Verbindungsanforderung irgendeine Form von Authentifizierung verlangt.)
Eine HTTP-über-SSL-Implementierung in Windows kann die Verwaltungskosten für eine Remotezugriffslösung erheblich senken. HTTP über SSL verringert zum Beispiel Helpdesksupport-Probleme und beseitigt Probleme im Zusammenhang mit VPN-Servern, die sich hinter NATs befinden. SSTP funktioniert nahezu überall und führt so zu erhöhter Benutzerzufriedenheit und -produktivität.
Da SSTP in Windows integriert ist, müssen Sie sich weder mit Installation und Verwaltung der VPN-Clientsoftware von Drittanbietern befassen noch mit der Installation zusätzlicher Software auf dem VPN-Server. Außerdem kann SSTP einen besseren Lastenausgleich für VPN-Verbindungen durch verfügbare SSL-Lastenausgleichsmodule bereitstellen.
Neue SSTP-Features
  • In SSTP ist die Unterstützung für Network Access Protection (NAP) integriert, womit sich der Netzwerkbestand besser schützen lässt, indem die Einhaltung von Systemintegritätsanforderungen erzwungen wird. Weitere Informationen zu NAP finden Sie unter microsoft.com/nap.
  • SSTP unterstützt auch systemeigenen IPv6-Datenverkehr, der innerhalb des SSTP-Tunnels und der IPv6-basierten SSTP-Verbindungen über das IPv6-Internet gesendet wird.
  • Ferner richtet SSTP eine einzige HTTP-über-SSL-Sitzung vom SSTP-Client zum SSTP-Server ein. Andere SSL-basierte VPN-Lösungen von Drittanbietern verwenden zwei HTTP-über-SSL-Sitzungen. Die Verwendung einer einzigen HTTP-über-SSL-Sitzung bedeutet geringere Netzwerkauslastung und besseren Lastenausgleich.
  • Schließlich ist SSTP vollständig in die VPN-Clientkomponenten von Windows Vista mit Service Pack 1 und in Windows Server „Longhorn“ sowie in den Routing- und RAS-Dienst in Windows Server „Longhorn“ integriert. SSTP ist ebenfalls ein VPN-Protokoll und kann dieselben Authentifizierungsprotokolle und Konfigurationsmethoden – z. B. den Ordner „Netzwerkverbindungen“ und den Verbindungs-Manager – verwenden, wie sie für PPTP- oder L2TP/IPsec-basierte Verbindungen verwendet werden.
Im Unterschied zu den PPTP- und L2TP/IPsec-Protokollen in Windows XP und Windows Server 2003 unterstützt SSTP keine Standort-zu-Standort-VPN-Verbindungen.

SSTP in Windows
Ein Computer, der Windows Server „Longhorn“ und den Routing- und RAS-Dienst ausführt, ist ein SSTP-basierter VPN-Server. Sie brauchen IIS nicht zu installieren, da der Routing- und RAS-Dienst eingehende Verbindungen auf der spezifischen URI /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/ überwacht. Es können jedoch gleichzeitig sowohl Routing- und RAS-Dienst als auch IIS auf demselben Server vorhanden sein.
Ein Computer, der Windows Vista (mit den im bevorstehenden Service Pack 1 geplanten Verbesserungen, die später in diesem Jahr veröffentlich werden sollen) oder Windows Server „Longhorn“ ausführt, ist ein SSTP-basierter VPN-Client, der zum Initiieren von SSTP-Verbindungen zu einem SSTP-basierten VPN-Server fähig ist. Auf dem SSTP-Server muss ein Computerzertifikat mit der Serverauthentifizierung oder der Universaleigenschaft „Erweiterte Schlüsselverwendung“ (Enhanced Key Usage, EKU) installiert sein. Dieses Computerzertifikat wird vom SSTP-Client verwendet, um den SSTP-Server zu authentifizieren, wenn die SSL-Sitzung eingerichtet wird. Der SSTP-Client überprüft das Computerzertifikat des SSTP-Servers. Um dem Computerzertifikat zu vertrauen, muss die Stammzertifizierungsstelle (CA) der CA, die das Computerzertifikat des SSTP-Servers ausgestellt hat, auf dem SSTP-Client installiert sein.
Abbildung 1 zeigt einen Vergleich der Attribute der verschiedenen VPN-Protokolle in Windows Server „Longhorn“ und Windows Vista mit Service Pack 1. In der Randleiste „Neue SSTP-Features“ werden die SSTP-Features beschrieben.
Figure 1 Vergleich der verschiedenen VPN-Protokolle (Close Figure 1)
Abbildung 2Struktur von SSTP-Paketen
Ein IPv4- oder IPv6-Paket wird zunächst zusammen mit einem PPP-Header und einem SSTP-Header gekapselt. Die Kombination aus dem IPv4- oder IPv6-Paket, dem PPP-Header und dem SSTP-Header wird durch die SSL-Sitzung verschlüsselt. Ein TCP-Header und ein IPv4-Header (für SSTP-Verbindungen über das IPv4-Internet) oder ein IPv6-Header (für SSTP-Verbindungen über das IPv6-Internet) werden hinzugefügt, um das Paket zu vervollständigen.
Weitere Informationen zu SSTP finden Sie im Blog zum Routing und Remotezugriff unter blogs.technet.com/rrasblog.


 Windows PowerShell: Arbeiten mit Active Directory
Windows PowerShell Arbeiten mit Active Directory and Don Jones Obwohl Windows PowerShell kein Get-ADSIObject-Cmdlet bereitstellt, steht das einer leistungsstarken ADSI-Unterstützung nicht im Wege. Lesen Sie eine Einführung zum Schreiben von Adaptern und erfahren Sie, wie Sie mithilfe von Windows PowerShell mit Verzeichnisobjekten arbeiten können.
Wenn Sie schon eine gewisse Zeit lang mit Windows PowerShell gearbeitet haben, werden Sie wahrscheinlich das Get-WMIObject-Cmdlet ausprobiert haben – auch bekannt unter dem bequemen Alias „gwmi“. Wie ich im vergangenen Monat in der Rubrik erläutert habe, verdeutlicht dieses Cmdlet die wesentlichen Vorzüge von Windows PowerShell gegenüber früheren Skriptsprachen und Befehlszeilenshells
(siehe technetmagazine.com/issues/2007/05/PowerShell). Gwmi ermöglicht einen schnellen und einfachen Zugriff auf die Windows®-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) und gestattet Ihnen dadurch eine unglaubliche Anzahl an Dingen zu tun, ohne komplizierte Skripts schreiben zu müssen.
Get-WMIObject ist ein hervorragendes Beispiel dafür, was Windows PowerShell™ alles tun kann, und immer, wenn ich dieses Beispiel in einem Kurs anführe, extrapolieren die Lernenden seine Funktionalität ausnahmslos auf andere Gebiete der Verwaltung von Windows. Eine der ersten Fragen, die ich oft zu hören bekomme, lautet in etwa: „Gibt es ein Get-ADSIObject-Cmdlet?“

ADSI-Unterstützung in Windows PowerShell
ADSI steht für Active Directory® Services Interface. Trotz des Namens bezieht sich ADSI nicht wirklich nur auf Active Directory. Eine genauere Möglichkeit, den Namen zu deuten, wäre „Active (Pause) Directory Services Interface“, da ADSI eine Verbindung zu verschiedenen Verzeichnisdiensten, einschließlich zu Verzeichnissen in Windows NT® herstellen kann – nicht nur zu Domänen von Windows NT, wohlgemerkt, sondern auch zum lokalen Security Accounts Manager (SAM) auf eigenständigen Computern und Mitgliedercomputern. Mit einer derartigen Flexibilität wäre ein Get-ADSIObject-Cmdlet sicherlich äußerst nützlich. Leider ist das ein Cmdlet, das vom Windows PowerShell-Team nicht in die erste Version eingepasst werden konnte.
Trotzdem kann nicht gesagt werden, dass Windows PowerShell nicht über ADSI-Unterstützung verfügt. Tatsache ist, dass die ADSI-Unterstützung in Windows PowerShell so gut ist, dass Sie den Mangel an einem Get-ADSIObject-Cmdlet nicht bemerken werden!
Es beginnt alles mit dem Typadapter [ADSI]. Zu Typadaptern ist eine kurze Erklärung notwendig. Bedenken Sie, dass Windows PowerShell auf Microsoft® .NET Framework aufbaut (2.0 oder höher, um genau zu sein). Daher wird beinahe alles in Windows PowerShell – von WMI-Objekten über Dateien bis zu Ordnern – als ein Objekt vom Framework repräsentiert. Das Windows PowerShell-Team hat sich jedoch nicht damit zufrieden gegeben, lediglich rohe Framework-Objekte für die Administratoren von Windows bereitzustellen. So funktionieren z. B. einige Framework-Objekte etwas inkonsistent, und Konsistenz war ein wesentliches Entwurfsziel für Windows PowerShell. Ein weiterer Grund ist, dass einige Framework-Objekte bezüglich der Verwaltung von Windows zu viel des Guten sind, und Einfachheit war ebenfalls ein wesentlicher Aspekt beim Entwurf von Windows PowerShell. Aus diesem Grund wurden Typadapter entwickelt.
Wie der Name schon sagt, „passt“ ein Typadapter einen Objekttyp von .NET Framework an ein konsistentes und manchmal einfacheres Format „an“. Stellen Sie sich z. B. vor, dass Sie eine neue Zeichenfolgenvariable wie diese erstellen:
[string]$var = “Hello”
Sie haben eine Instanz des System.String-Typs verwendet, der vom .NET-Adapter behandelt wird. Der Typadapter [ADSI] ist mit den DirectoryServices-Klassen von .NET Framework verbunden, zu dem auch der DirectoryEntry-Typ gehört.

Abrufen von Objekten aus dem Verzeichnis
Eine Verbindung zu Verzeichnisobjekten herzustellen, ist recht einfach. Um z. B. eine Verbindung zu einem Benutzer mit dem Namen Don in der IT-Organisationseinheit mit der Domäne „Contoso.com“ herzustellen, würden Sie etwa diese ausführen:
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
Wenn Sie sich bereits mit ADSI in VBScript oder einer anderen Sprache beschäftigt haben, wird Ihnen dies recht vertraut vorkommen. Es handelt sich hierbei um eine standardmäßige Abfragezeichenfolge von Lightweight Directory Access-Protokoll (LDAP), dem systemeigenen Mittel für den Zugriff auf Active Directory. Sie müssen keinen Namen für einen Domänencontroller (DC) oder sonstige Details vorgeben. Dieser vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) enthält ausreichende Informationen, um den DC zu ermitteln und das Objekt abzurufen (natürlich unter der Voraussetzung, dass Sie über die entsprechenden Berechtigungen verfügen).
Beim Umgang mit lokalen Sicherheitskonten kommt ein nahezu identischer Prozess zum Einsatz. Der einzige Unterschied besteht darin, dass der WinNT-Anbieter statt des LDAP-Anbieters verwendet wird:
$user = [ADSI]”WinNT://don-pc/don”
Abbildung 1Abrufen einer Liste der Eigenschaften eines Objekts
Das Abrufen von Objekten ist hauptsächlich eine Frage der Kenntnis, wie eine Abfragezeichenfolge zu erstellen ist. Die Verwendung des WinNT-Anbieters ist recht einfach. Geben Sie einfach einen Computer- oder Domänennamen, einen Schrägstrich und dann einen Objektnamen an. Dieses Verfahren funktioniert mit Domänen von Active Directory recht gut (die letzten Endes mit Windows NT-Domänen abwärtskompatibel sind). Und tatsächlich kann die Verwendung des WinNT-Anbieters für das Abrufen von Objekten von Active Directory in einigen Fällen der einfachste Weg sein, da Ihnen der WinNT-Anbieter eine pauschale Ansicht der Domäne bietet. Das bedeutet, dass Sie nicht wissen müssen, in welcher Organisationseinheit sich ein Objekt befindet, da der WinNT-Anbieter die Organisationseinheiten nicht sieht.
Das Abrufen von LDAP-Objekten erfordert etwas mehr Präzision. Beginnen Sie mit möglichst exakten Informationen wie z. B. dem kanonischen Namen eines Objekts oder dem Namen der Organisationseinheit. Anschließend geben Sie den vollständigen Pfad zum Objekt vor, beginnend mit dem übergeordneten Container und bis ihn zur eigentlichen Domäne. So sähe z. B. der Benutzer Don in der Organisationseinheit „Sales“, die sich in der Organisationseinheit „West“ der Domäne „Contoso.com“ befindet, folgendermaßen aus:
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
Dieses Format benötigt ein wenig Übung und erfordert, dass Sie wissen, wo sich das Objekt befindet. Abbildung 2 zeigt die verschiedenen Komponenten eines FQDN im Überblick.
Figure 2 FQDN-Komponenten (Close Figure 2)

Komponente | Zweck | Beispiel
cn | Kanonischer Name eines Objekts. Auch verwendet für Container, die keine Organisationseinheiten sind, wie z. B. Benutzer und Computer. | cn=Don
ou | Organisationseinheit. | ou=Sales
dc | Komponente Domänenname. Jede Komponente einer DNS-Domäne erhält ihre eigene „dc=“-Komponente. | dc=domain, dc=com

Etwas Hilfe von einem Freund
Das Erstellen und das Löschen von Objekten erfordert meist, dass Sie zuerst eine Verbindung zum Container des Objekts herstellen, z. B. zu einer Organisationseinheit, und anschließend den Container mit dem Erstellen bzw. Löschen des Objekts beauftragen. Ich vergesse immer die richtige Syntax, aber glücklicherweise können mir die Scripting Guys von Microsoft mit ADSI Scriptomatic aus der Klemme helfen.
Obwohl ursprünglich für VBScript erstellt, ist ADSI Scriptomatic immer noch ein nützliches Handbuch für Windows PowerShell, da sich die eigentliche ADSI-Syntax nicht geändert hat. Nach dem Herunterladen des Tools wähle ich z. B. die Option für das Erstellen eines neuen Benutzers aus. Ich ignoriere den gesamten vom Tool erzeugten Skriptcode bis zum Code „end connect to a container“, der so aussieht:
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
Die Übersetzung zu Windows PowerShell ist einfach. Zuerst stelle ich eine Verbindung zum Container her, in dem der Benutzer erstellt werden soll. Um konsistent mit dem Code von Scriptomatic zu bleiben, werde ich die Organisationseinheit mithilfe der $objContainer-Variablen repräsentieren. Außerdem werde ich eine $strName-Variable erstellen, die den Namen des neuen Benutzers aufnehmen wird:
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
Anschließend kopiere ich über den Code von Scriptomatic, lösche alle Spuren von VBScript Set-Anweisungen und füge das Zeichen $ den Variablennamen hinzu:
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
Das ist schon alles – in der Organisationseinheit „Test“ der Domäne „Contoso.com“ wurde ein neuer Benutzer angelegt.

Modifizieren von Verzeichnisobjekten
Nachdem Sie eine Verbindung zu einem Objekt hergestellt haben – z. B. zu einem Benutzer oder einer Gruppe – können Sie dieses Objekt modifizieren. Mit dem WinNT-Anbieter können Sie viele Eigenschaften direkt ändern, z. B. jene in Abbildung 1 dargestellten. Um z. B. die Description-Eigenschaft eines Benutzers anzuzeigen und anschließend zu ändern, würden Sie dies ausführen:
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
Das Wichtigste, das Sie dabei beachten müssen, ist, dass diese Änderungen von Eigenschaften am lokalen Eigenschaftencache vorgenommen werden, einem temporären Speicherort von ADSI auf dem Computer. Durch Aufrufen der SetInfo-Methode wird der Cache zurück in die Domäne oder auf den Computer geschrieben, von der bzw. dem Sie das Objekt abgerufen haben, wodurch die vorgenommenen Änderungen tatsächlich zurück in das Verzeichnis gespeichert werden.
Objekte von Active Directory stellen für die meisten Objektattribute keine direkten Eigenschaften bereit. Stattdessen verwenden Sie die Methoden „Get“ und „Put“:
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
WinNT-Objekte neigen zu einer gewissen Einfachheit, da Verzeichnisdienste von Windows NT nicht viele Informationen über Objekten wie Benutzer und Gruppen enthalten. Active Directory andererseits speichert eine breite Palette an Informationen, und das Erkennen der richtigen Attributnamen kann recht schwierig sein. Wenn Sie z. B. den Nachnamen eines Benutzers ändern möchten, müssen Sie die Sn-Eigenschaft ändern. Warum Sn? Sn bedeutet Surname (Familienname).
Glücklicherweise stellt Microsoft einen guten Querverweis bereit, der online unter msdn2.microsoft.com/de-de/library/ms677286.aspx verfügbar ist. Dieser Verweis zeigt die Attributnamen für jeden Hauptbereich der Active Directory-Benutzer- & Computerkonsolen, wenn Sie wissen, was Sie in der Konsole ändern möchten, können Sie den zugrunde liegenden Attributnamen ermitteln. Beachten Sie, dass ein vollständigerer Konsole-zu-Attribut-Querverweis im Buch „ADSI Scripting: TFM von Cade Fassett (SAPIEN Press, 2007) aufgeführt ist.

Was Sie nicht machen können
Leider ist die ADSI-Unterstützung in Windows PowerShell nicht so leistungsfähig wie für andere Technologien wie z. B. WMI. So ist es z. B. etwas schwierig, die Mitglieder der Gruppen eines lokalen Computers durchzuzählen. Auch beim Umgang mit Active Directory tritt eine Anzahl von schwierigen Situationen auf. Meine Erfahrung besagt, dass die grundlegenden Mechanismen für das Abrufen, das Anlegen und das Löschen von Objekten gut funktionieren. Das Modifizieren von Objekteigenschaften funktioniert ganz gut, obwohl auf einige Eigenschaften kein Zugriff möglich ist. Die meisten Schwierigkeiten traten auf, als ich versuchte, mit lokalen Objekten und Gruppen über den WinNT-Anbieter zu arbeiten.
Es soll damit nicht gesagt werden, dass da nichts zu machen ist. Einige Dinge sind nur schwieriger oder weniger intuitiv zu bewerkstelligen. Betrachten wir folgendes Beispiel:
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
In diesem Beispiel wird der Gruppe „Techs“ ein Benutzer mit dem Namen „User1“ hinzugefügt. Das beginnt sehr direkt. Zuerst wird mithilfe des FQDN die Gruppe abgerufen. Anschließend wird mit der Sammlung „Member“ der Gruppe – genauer gesagt mit der Add-Methode der Sammlung – der FQDN des gewünschten Benutzers hinzugefügt. Der letzte Schritt ist jedoch keineswegs intuitiv. In diesem Schritt wird die CommitChanges-Methode der verborgenen PSBase-Klasse aufgerufen, um die Änderungen zu speichern.
PSBase ist eine spezielle Klasse, die direkt das Basis-.NET Framework-Objekt vertritt. In diesem Fall wird CommitChanges nicht direkt in Windows PowerShell zur Verfügung gestellt (Tatsache ist, dass vom ADSI-Adapter keinerlei Methoden zur Verfügung gestellt werden), deshalb müssen Sie auf die zugrunde liegende Klasse zurückgreifen. Dies ist zwar nicht unmöglich, jedoch auch nicht sonderlich intuitiv. Dies zeigt auch, dass Verzeichnisdienstfunktionen noch nicht vollständig in Windows PowerShell integriert wurden.
Dafür gibt es eine Anzahl von Gründen. Der erste Grund ist, dass das Windows PowerShell-Team die aktuelle Version für die ADSI-Unterstützung zu einem recht späten Zeitpunkt der Shell hinzugefügt hat. Wie Jeffrey Snover, der Architekt der Shell, oft zu sagen pflegt: „Wer liefern muss, muss sich entscheiden.“ Das Team hatte eine eng bemessene Zeitspanne für Entwicklung und Lieferung der Shell zur Verfügung, und es musste daher entschieden werden, welche Funktionen bis zur nächsten Version warten mussten. Anderenfalls könnte das Team problemlos Jahre mit dem Einfügen von Features verbringen und würde dabei doch nie bei der Freigabe eines unterstützten Produkts angelangen.
Ein weiterer Grund ist jedoch das zugrunde liegende .NET Framework. Die DirectoryServices-Klasse ist recht komplex und die Einpassung dieser Komplexität in Windows PowerShell wird viel Zeit und eine sorgfältige Planung benötigen. Die Framework-Klassen sind außerdem, meiner Meinung nach, ein wenig auf Active Directory ausgerichtet und bieten keine sonderlich brillante Unterstützung für den WinNT-Anbieter – Windows PowerShell erbt selbstverständlich derartige Einschränkungen vom Framework.
Ich erwarte, dass Windows PowerShell möglicherweise eine beträchtlich erweiterte Unterstützung für Verzeichnisdienste haben wird – eine Unterstützung, die nicht durch die Schicht von ADSI erfolgt, sondern stattdessen über grundlegende Verbesserungen in .NET Framework. Bis zu diesem Zeitpunkt können Sie mithilfe der in Windows Powershell verfügbaren ADSI-Unterstützung die große Mehrheit von Verwaltungsaufgaben ausführen, wie z. B. das Erstellen von Benutzern, das Ändern allgemeiner Benutzereigenschaften usw.
Bedenken Sie außerdem, dass viele Verzeichnisdienstaufgaben durch WMI ausgeführt werden können. Befassen Sie sich mit den unter microsoft.com/technet/scriptcenter/scripts verfügbaren Skripts. Diese stellen ausgezeichnete Beispiele für die Verwendung von WMI zur Gewinnung umfangreicherer Informationen über eine lokale Gruppe dar, als mit ADSI selbst möglich ist.


 Hey, Scripting Guy!: Skripterstellung entlang der roten Wellenlinie
Hey, Scripting Guy! Skripterstellung entlang der roten Wellenlinie and Die Scripting Guys von Microsoft
Laden Sie den Code für diesen Artikel herunter: Heyscriptingguy2007_06.exe (151KB)
Suchen Sie eine leichtere Möglichkeit, Begriffe in das Microsoft Word-Wörterbuch einzufügen? Nicht mehr manuell, ein Wort nach dem anderen? Wer täte das nicht? In diesem Monat zeigen Ihnen die Scripting Guys, wie Sie benutzerdefinierte Wörterbücher in Microsoft Word erstellen und wie Sie Word programmgesteuert so konfigurieren, dass diese Wörterbücher auch tatsächlich verwendet werden.
Abbildung 1Dokument in Word mit Rechtschreibfehlern
Etwas Ungewöhnliches bemerkt? Stimmt: Word hat unter Skriptingbegriffen wie Msgbox Wellenlinien gezogen. Warum? Weil Word diese Begriffe nicht erkennt. Diese Begriffe nicht erkennt? Nach all den Jahren, in denen die Scripting Guys den Begriff Msgbox mehrere Millionen Mal eingegeben haben? Mehrere Millionen Mal öfter haben sie die Rechtschreibprüfung ausgeführt und Word mitgeteilt, dass Msgbox richtig geschrieben wurde. Und immer noch markiert Word Begriffe wie Msgbox, StrReverse und LTrim als falsch buchstabierte Wörter? Wie kommt das?
Bevor Sie nun zur Verteidigung von Word eilen: Ja, wir wissen, dass wir diese Begriffe manuell in das Wörterbuch von Microsoft Word einfügen können. Aber wir sind die Scripting Guys. Was haben wir mit manueller Arbeit am Hut? Außerdem ist es gelinde gesagt ein bisschen mühsam, VBScript-Funktionen und WMI-Klassennamen (Windows® Management Instrumentation) und ADSI-Objektattribute (Active Directory® Security Interfaces) manuell einzufügen. Was ist, wenn wir das auf allen unseren Computern machen wollen? Was ist, wenn wir diese richtigen Schreibweisen an unsere treuen Leser weitergeben wollen? Was ist, wenn ... nun, Sie verstehen, worauf wir hinauswollen.
Der springende Punkt: Es muss ganz sicher eine leichtere Möglichkeit geben, Begriffe aus der Skripterstellung (oder überhaupt irgendwelche Begriffe) in das Wörterbuch aufzunehmen, ohne jedes Wort einzeln manuell einzutragen.
Aber leider gibt es keine Möglichkeit. Bis zum nächsten Monat.
Nein, wir machen doch nur Spaß. Natürlich gibt es eine leichtere Möglichkeit, Begriffe in das Wörterbuch einzutragen. Gleich werden wir Ihnen auch zeigen, wie das geht. Als Erstes wollen wir jedoch kurz über Wörterbücher im Allgemeinen sprechen.
Wo wir gerade dabei sind: Es gibt einige interessante Tatsachen im Zusammenhang mit Wörterbüchern. Warum schreiben die Amerikaner das englische Wort für Farbe ohne „u“ („color“ statt „colour“)? Warum schreiben die Amerikaner das englische Wort für „Mitte“ als „center“ und nicht als „centre“? Wir wissen, warum: Weil Noah Webster, der das erste amerikanische Wörterbuch zusammengestellt hat, die englischen Rechtschreibregeln nicht mochte und darum die Schreibweise vieler Wörter willkürlich geändert hat.
Na gut, einverstanden. Nicht gerade spannend. Aber wir wollten etwas Interessantes zu Wörterbüchern sagen!
Neben dem Standardwörterbuch, das in die Anwendung integriert ist, können Sie bei Microsoft Word auch beliebig viele benutzerdefinierte Wörterbücher anlegen. Standardmäßig ist Word mit dem benutzerdefinierten Wörterbuch „Custom.dic“ ausgestattet, das im Pfad „Anwendungsdaten\Microsoft\Proof“ in Ihrem Benutzerprofilordner gespeichert ist (bei Windows XP „\Dokumente und Einstellungen\Benutzername“). Wenn Sie mit der rechten Maustaste auf ein falsch geschriebenes Wort klicken und die Option „Hinzufügen zum Wörterbuch“ wählen, wird dieses Wort in die Datei „Custom.dic“ aufgenommen.
Die Datei „Custom.dic“ ist allerdings nur eine ganz gewöhnliche Textdatei. Wenn Sie die Datei im Editor öffnen, sehen Sie eine simple Wortliste, ähnlich wie in diesem Beispiel:
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
Genau so können wir Begriffe aus der Skripterstellung in das Wörterbuch von Microsoft Word einbinden. Wir müssen nur eine Textdatei mit den Begriffen erstellen und dann Word so konfigurieren, dass diese Datei als ein benutzerdefiniertes Wörterbuch verwendet wird. Wie schwer ist das wohl? Nun, nachdem wir Scripting Guys bereit sind, dies selbst zu tun, ist das wohl überhaupt nicht schwer.
Aber Moment mal: Wir müssen noch einen kurzen Abstecher machen. Im Microsoft Word-Objektmodell werden Angaben zu benutzerdefinierten Wörterbüchern in der Sammlung „CustomDictionaries“ gespeichert. Um auf diese Sammlung programmgesteuert zuzugreifen, verweisen Sie auf das Objekt „Word.Application“ und die Eigenschaft „CustomDictionaries“. Abbildung 2 zeigt ein Skriptbeispiel, mit dem Informationen zu allen benutzerdefinierten Wörterbüchern zurückgegeben werden, die mit Ihrer Kopie von Microsoft Word verbunden sind.
Figure 2 Skript, mit dem Angaben zum benutzerdefinierten Wörterbuch abgerufen werden (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
Wenn Sie das Skript aus Abbildung 2 ausführen, erhalten Sie einige Informationen, ähnlich wie in diesem Beispiel:
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
Das Abrufen von Informationen zu vorhandenen Wörterbüchern ist natürlich nicht so ganz dasselbe wie das Erstellen eines neuen benutzerdefinierten Wörterbuchs. Der Unterschied ist ungefähr so groß wie der Unterschied zwischen jemandem, der etwas über einen Millionär liest, und jemandem, der tatsächlich ein Millionär ist. Lassen Sie uns daher herausfinden, wie wir ein neues benutzerdefiniertes Wörterbuch in Word erstellen.
Als Erstes werden wir alle VBScript-Funktionen in ein neues Wörterbuch mit dem Namen „Scripting.dic“ einfügen. Wir fangen mit den VBScript-Funktionen an, weil es hier ein gutes Stück Arbeit gibt. Anschließend zeigen wir Ihnen, wie Sie WMI-Klassen, ADSI-Attribute und Windows PowerShell™-Cmdlets quasi im Vorbeigehen dem Wörterbuch hinzufügen. (Wenn es darum geht, die Arbeit auf ein Mindestmaß zu beschränken, macht den Scripting Guys natürlich so leicht niemand etwas vor.)
Ein benutzerdefiniertes Wörterbuch lässt sich ganz einfach in Microsoft Word anlegen:
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
Wie Sie sehen, erstellen wir als Erstes eine Instanz des Objekts „Word.Application“. Wir legen für die Eigenschaft „Sichtbar“ nicht den Wert „Wahr“ fest, so dass Word nicht auf dem Bildschirm sichtbar wird. Warum nicht? Nun ja, weil dieses Skript nur etwa eine Sekunde dauert. Deshalb sehen wir keine Veranlassung, Word kurz auf dem Bildschirm auftauchen und dann gleich wieder schließen zu lassen. Wenn Sie jedoch möchten, dass Word kurz geöffnet wird (und sei es nur, um festzustellen, ob das Skript tatsächlich arbeitet), dann nehmen Sie einfach den nachfolgenden Code als zweite Zeile in das Skript auf:
objWord.Visible = True
Nach dem Erstellen des Objekts „Word.Application“ erstellen wir mit dieser Codezeile einen Objektverweis auf die Sammlung „CustomDictionaries“:
Set colDictionaries = _
  objWord.CustomDictionaries
Anschließend fügen wir das benutzerdefinierte Wörterbuch mit der Methode „Add“ hinzu. Beachten Sie dabei, dass diese Datei überhaupt nicht vorhanden sein muss. Wenn Word keine Datei mit dem Namen „Scripting.dic“ findet, dann wird einfach eine neue, leere Datei mit diesem Namen angelegt. Mit dem folgenden Code fügen Sie das benutzerdefinierte Wörterbuch hinzu:
colDictionaries.Add “Scripting.dic”
Für das neue Wörterbuch haben wir auch keinen Pfad angegeben. Stattdessen haben wir einfach den Dateinamen („Scripting.dic“) an die Methode „Add“ übergeben. Das ist in Ordnung. In diesem Fall wird die Datei „Scripting.dic“ im Standardordner für Wörterbücher und andere Korrekturtools angelegt (beispielsweise „C:\Dokumente und Einstellungen\kenmyer\Anwendungsdaten\Microsoft\Proof“).
Was ist, wenn das Wörterbuch in einem anderen Pfad gespeichert werden soll? Kein Problem. Mit diesem Befehl wird die Datei „Scripting.dic“ im Ordner „C:\Scripts“ erstellt:
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
Was ist, wenn wir dieses benutzerdefinierte Wörterbuch später wieder löschen wollen? Auch das ist kein Problem. In diesem Fall stellen wir einfach eine Bindung zum Wörterbuch her und entsorgen es mit der Methode „Delete“:
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Abbildung 3Dokument in Word nach Einfügen eines benutzerdefinierten Wörterbuchs
Dies ist recht handlich, wenn wir so sagen dürfen, besonders in Anbetracht der Tatsache, dass Sie die Datei „Scripting.dic“ und Ihr Skript für die Erstellung des benutzerdefinierten Wörterbuchs an andere Benutzer weitergeben können. Dann gilt Msgbox auch in den Word-Versionen dieser Benutzer endlich als richtig geschriebenes Wort. Wenn wir Scripting Guys so richtig faul wären, könnten wir nun unsere Rubrik für diesen Monat beenden, und Sie hätten trotzdem etwas Nützliches erfahren. Aber wie heißt es doch so schön: Das war doch noch gar nichts.
Hinweis: Wir sind tatsächlich faul. Aber irgendwie mussten wir ja den leeren Platz in dieser Rubrik füllen. Deshalb haben wir uns entschieden, ein oder zwei Skripte als Bonus einzubringen.
Wie Sie wahrscheinlich wissen, sind sowohl VBScript als auch Windows Script Host ein bisschen schüchtern; sie sprechen nicht gern über sich. Bei WMI, ADSI und Windows PowerShell ist die Sache schon anders. Wenn Sie nachfragen, geben Ihnen diese Technologien bereitwillig Auskunft über ihre Klassen, Eigenschaften und Methoden, also quasi über alles, was Sie wissen wollen.
Nehmen Sie beispielsweise ADSI. Abbildung 4 zeigt ein Skript, das an das Active Directory-Schema gebunden wird und sämtliche Attribute aus dem Benutzerkontoobjekt abruft. Anschließend werden diese Attribute in die Datei „C:\Scripts\Scripting.dic“ geschrieben.
Figure 4 ADSI-Attributnamen in ein benutzerdefiniertes Wörterbuch aufnehmen (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
Sehen Sie, wie einfach das ist? Mit einigen wenigen Codezeilen haben wir ein Wörterbuch mit allen Attributen aus dem Active Directory-Benutzerobjekt angelegt. Geben Sie diesen Code an andere Skriptersteller weiter, und Attributnamen wie „streetAddress“ oder „givenName“ werden nie mehr als falsch geschriebene Wörter markiert. Das lässt sich natürlich beliebig erweitern. Sie wollen die Eigenschaften für die Computerklasse hinzufügen? Dann bauen Sie die nachfolgende Codezeile ein:
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
Wie sieht es mit WMI-Klassen aus? Abbildung 5 zeigt ein Skript, mit dem eine Liste aller WMI-Klassen im Namespace „root\cimV2 abgerufen und in die Datei „C:\Scripts\Scripting.dic“ geschrieben wird.
Figure 5 WMI-Klassennamen in ein benutzerdefiniertes Wörterbuch aufnehmen (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Haben wird die Windows PowerShell-Benutzer vergessen? Das würden wir Scripting Guys doch nie tun. Nun ja, zugegeben, wir haben Sie tatsächlich vergessen. Aber immerhin haben wir das folgende einzeilige Skript zu bieten, mit dem alle Cmdlet-Namen zurückgegeben und dann in die Datei „C:\Scripts\Scripting.dic“ geschrieben werden:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
Das Schöne an der Rubrik in diesem Monat ist es, dass wir alle etwas dazugelernt haben. Sie haben erfahren, wie Sie benutzerdefinierte Wörterbücher in Microsoft Word erstellen und wie Sie Word programmgesteuert so konfigurieren, dass diese Wörterbücher auch tatsächlich verwendet werden. Die Scripting Guys haben auch etwas gelernt: Wenn man will, dass etwas gut erledigt wird, nun ja, dann ist es immer noch besser, jemand anders für die Arbeit einzuspannen. Wenn alles andere schiefgeht, können Sie immer noch selbst Hand anlegen.


 Die Desktopdateien: So behalten Sie Ihre Daten
Die Desktopdateien So behalten Sie Ihre Daten and Wes Miller Es überraschend, wie oft wichtige Daten verloren gehen. Tatsache ist jedoch, dass Informationen verloren gehen, weil Benutzer versäumen, ihre Daten zu schützen. Machen Sie sich daher mit den wichtigen Schritten vertraut, die Sie für den Schutz der Daten Ihrer Organisation ausführen können und müssen.
Informationen sehnen sich nach Freiheit. Es ist völlig egal, wem Sie sich anvertrauen oder wie ernsthaft Sie versuchen, diese Nullen und Einsen festzumachen, die werden immer die dünne Stelle im Brett finden. Jeden Tag erfahren wir aus den Nachrichten von geringfügigen und gewaltigen Datenverlusten. Es ist doch ein riesiger Witz, dass wichtige Daten
Abbildung 2Schlechte Wahl für ein Kennwort, auch wenn Sie Ihre Mutter sehr mögen
Kennwortintegrität und lokale Authentifizierung sind kritische Angelegenheiten, aber selbstverständlich handelt es sich bei den Daten auf dem lokalen System immer noch um Daten, die immer noch auf dem Spiel stehen, bis sie physisch gesichert oder verschlüsselt sind. Kennwörter allein sind nicht die Lösung. Das Kennwort eines Benutzers ist lediglich ein Mittel, um sicherzustellen, dass Angreifer versagen, die lediglich ohne sonstige Mittel über den direkten interaktiven Zugriff in das System eindringen möchten.

Physische Sicherheit
Kritische Daten dürfen sich nicht auf einem System befinden, zu dem ein physischer Zugang besteht oder das aus dem Büro verbracht werden kann. Wenn Sie über Systeme verfügen, von denen Sie befürchten, dass Datendiebstähle möglich sind, indem jemand Windows PE startet und Daten abruft, haben Sie andere Probleme. Windows PE ist unschuldig. Die Wahrheit besteht stattdessen in einer oder mehrerer der folgenden Tatsachen. Ihre Systeme sind physisch nicht ausreichend gesichert. Die Systeme sind gesichert, aber Sie vertrauen den Benutzern nicht, die Zugriff auf diese Systeme haben, Ihre Daten befinden sich auf einem System, das nicht physisch gesichert ist (oder nicht physisch gesichert werden kann), oder die Systeme können nicht physisch gesichert werden und Sie verwenden keine Tools zur Verschlüsselung von Volumes, wie z. B. den BitLocker™ von Windows Vista, um sich gegen physische Angriffe zu schützen. (Detaillierte Informationen über BitLocker finden Sie in dem Artikel von Byron Hynes in dieser Ausgabe des TechNet Magazins.)
Überdenken Sie, welches Ihrer Systeme gefährdet sein kann. Können Sie diese Systeme physisch sichern? Warum platzieren Sie diese Systeme nicht in ein Datencenter oder in einen anderen Bereich mit eingeschränktem Zugang? Wenn das nicht möglich ist, oder wenn es sich um ein mobiles System handelt, verwenden Sie Volumeverschlüsselungssoftware? Wenn Sie keine dieser Maßnahmen ergreifen können, verschieben Sie die Daten auf ein System, das entweder gesichert oder verschlüsselt werden kann. Im oben erwähnten Fall des gestohlenen Laptops, wären bei Verwendung eines Tools für die sichere Verschlüsselung von Volumes die Daten nahezu vollständig vor Missbrauch geschützt gewesen.
Nur weil ein System in einem Datencenter lebt, bedeutet das nicht, dass es sicher ist. Wenn Sie eine Handvoll T1-Leitungen aus dem Internet haben, besteht immer noch eine Gefährdung. Durch einen Internetzugang gelangen schlechte Menschen dem physischem Zugriff einen Schritt näher, überdenken Sie daher sorgfältig die Bedrohungen, denen Ihr System ausgesetzt ist. Ziehen Sie eine Verlagerung der Daten in ein getrenntes Segment Ihres Netzwerks in Betracht, in dem Sie über mindestens eine weitere Ebene des Netzwerkschutzes zwischen dem Internet und den betreffenden Systemen verfügen.

Beschränkung des Risikos für Daten
Eine weitere Sicherheitsmaßnahme, die Sie nutzen können, besteht darin, den Benutzern den Zugriff über Anwendungen oder Tools für dünne Clients zu gewähren, durch welche die Daten auf einem physisch gesicherten Server isoliert werden. Dies kann das Bereitstellen von Zugriff über ein VPN beinhalten, damit Benutzer auch von außerhalb des Standorts Zugriff erhalten können. Sie sollen sich nie durch die physischen Einschränkungen eines Benutzers diktieren lassen, wie Daten zu behandeln sind. Nur weil ein Benutzer einen Zugriff benötigt und sich an einem Ort ohne Breitband- oder sonstigen Hochgeschwindigkeitszugriff aufhält, bedeutet dies nicht, dass Sie die Daten einfach zu einer lokalen Instanz auf dem Computer des Benutzers verschieben sollten. Wenn Sie das System unter keinen Umständen umlagern können es sich an einem unsicheren Ort befinden muss, sichern Sie die Daten mithilfe der Volumeverschlüsselung.

Sicherheit innerhalb des Systems
Sie sollten auf die Möglichkeit vorbereitet sein, dass, trotz all Ihrer besten Bemühungen, jemand in das System einbrechen und die Festplatte stehlen und in ein anderes Windows-System installieren kann, in dem die NTFS-ACLs zurückgesetzt werden können.
Um sich für diesen Fall zu wappnen, verwenden Sie die in Windows Vista enthaltene Volumeverschlüsselung. Für die meisten anderen Versionen von Windows stehen zahlreiche Tools von Drittanbietern zur Verfügung. Diese Tools unterscheiden sich in der Komplexität ihrer Verwendung sowie in ihren Möglichkeiten zur Verschlüsselung vollständiger Volumes und/oder zur Verschlüsselung einzelner Dateien oder Verzeichnisse dahingehend, was das verschlüsselnde Dateisystem (Encrypting File System, EFS) zulässt. Wenn das Volume verschlüsselt ist, sind die Daten gegen nahezu jeden Diebstahl, mit Ausnahme von hoch komplizierten Methoden, geschützt.

Sicherheit von Archiven
Auch Sicherungsdaten müssen geschützt werden. Die meisten Leute geben zwei Gründe für eine nicht geschützte Anfertigung von Sicherungsdaten ihrer Systeme an: Das Verschlüsseln während des Erstellens der Sicherungsdaten dauert zu lang und/oder wird von der Sicherungssoftware nicht unterstützt
Wenn Sie jedoch eine Sicherungskopie von Systemen erstellen, und besonders wenn Sie der Best Practice folgen und die Sicherungsdaten nicht vor Ort aufbewahren, müssen Sie die in Datensicherungen gespeicherten Daten schützen. Verschlüsseln Sie entweder die Daten mithilfe von EFS, falls verfügbar, oder mit anderer Software für die Volumeverschlüsselung (wie z. B. das BitLocker-Feature in Windows Vista oder andere Software von Drittanbietern), oder erwerben Sie eine Sicherungssoftware, die über Verschlüsselungsfunktionen verfügt und ein annehmbares Leistungsvermögen erreicht. Nur weil Daten ein wenig auf einem Sicherungsband versteckt oder über eine auf Datenträgern basierende Sicherungslösung verstreut sind, werden diese Daten keineswegs geschützt. Gehen Sie davon aus, dass der Transportmechanismus selbst gefährdet ist.

Sicherheit bei der Übertragung
Alle Daten, die über den Draht transportiert werden, müssen geschützt werden. Verwenden Sie ausschließlich sichere Protokolle für den Zugriff auf das Remotesystem. Verwenden Sie verschlüsselte Versionen von Protokollen und gehen Sie immer davon aus, dass ein Man-in-the-Middle-Angriff (MITM wahrscheinlich ist. Verwenden Sie keine schwach verschlüsselnden oder unverschlüsselten Protokolle, und nutzen Sie bei Einsatz einer Verschlüsselung keine schwache Verschlüsselungslänge und keinen schwachen Verschlüsselungsalgorithmus. Sie, oder jemand in Ihrer Organisation, müssen sich mit allen zwischen den Systemen Ihrer Infrastruktur verwendeten Kommunikationsprotokollen und Verschlüsselungsalgorithmen auskennen.

Sicheres Löschen
Wir haben schon alle Geschichten von Festplatten oder anderen Speichergeräten gehört, die von eBay oder vom Flohmarkt vor Ort gekauft und anschließend einer Bearbeitung mit professioneller kriminaltechnischer Software oder sogar ganz gewöhnlichen Dienstprogrammen für die Datenwiederherstellung unterzogen wurden, um den dunkelsten Geheimnissen auf die Spur zu kommen – Daten, die vor dem Verkauf der Laufwerke vollständig hätten gelöscht werden sollen.
Wenn Sie UFDs in Ihrer Organisation nutzen, sollten Sie Dienstprogramme für eine zwangsweise Verschlüsselung in Betracht ziehen. Datenträger, die risikoreiche Daten enthalten, sollten verschlüsselt werden. Im Gegensatz zur allgemeinen Auffassung stimme ich nicht überein, dass ein einfaches Verschlüsseln von Volumes vor der Entsorgung eine risikolose Art der Entsorgung von Datenträgern ist. Erinnern Sie sich an den oben genannten Vergleich mit medizinischem Sondermüll? Betrachten Sie die Daten auf diesen Systemen als Sondermüll und sichere Dienstprogramme für das Löschen von Daten als Behandlungsmethode. Verwenden Sie für das Löschen von Daten ein Tool, das der Spezifikation DoD 5220.22-M genügt, z. B. SDelete von Mark Russinovich, bevor Sie Ihre Datenträger und Systeme für den Wiederverkauf in die wilden Welt freigeben, oder sogar vor dem Umsetzen innerhalb Ihrer Organisation. Anderenfalls wird der nächste Benutzer in die geheimen Daten des Vorbesitzers eingeweiht.

Überwachung
Eine weitere Schlüsselkomponente der Datensicherheit sind die Überwachung und sogar die Modellierung von Bedrohungen, der Lebenszyklus der Daten in Ihrer Organisation. Ermitteln Sie die Schwachpunkte, an denen Ihre Daten nach außen dringen können, und behalten Sie diese Punkte sorgfältig im Auge. Windows stellt mehrere integrierte Tools für die Überwachung bereit. Durch die Überwachen können Sie jedoch leicht eine Datenschwemme erleben. Stellen Sie sicher, dass Sie die richtigen Bereiche beobachten und dass Sie nicht von Daten überflutet werden. Achten Sie auf Schwachpunkte und schließen Sie diese hinreichend durch geeignete schadensbegrenzende Maßnahmen – verspachteln Sie den Datendamm nicht mit nervenden Maßnahmen. Stellen Sie außerdem sicher, dass Ihre Benutzer gründlich über den Umgang mit Daten belehrt werden. Benutzer sind das schwache Glied auf so vielen Ebenen in Ihrer Organisation. Weitere Anleitungen finden Sie in der Randleiste „Zusätzliche Ressourcen“. Vergessen Sie nicht, all den hier aufgeführten Vorschlägen zu folgen. Sie werden dadurch nachts besser schlafen können.
Zusätzliche Ressourcen
Im „The Core Infrastructure Optimization Implementer Resource Guide—Basic to Standardized“ erfahren Sie, wie Sie Ihre IT-Infrastruktur von einem hauptsächlich manuellen und reaktiven Grundniveau auf ein standardisiertes Niveau mit hoher Automatisierung, erzwungenen Konfigurationsstandards und verbesserten Vorgängen bringen können. Laden Sie das Handbuch von go.microsoft.com/?linkid=5795711 herunter. „Additional Infrastructure Optimization Implementer Resource Guides“ finden Sie unter microsoft.com/io. Noch mehr Sicherheitstipps finden Sie außerdem im Artikel „10 Unveränderliche Gesetze zur Sicherheit“.


 Berichte aus der Praxis: Kommunikation mit Entwicklern
Berichte aus der Praxis Kommunikation mit Entwicklern and David Aiken Entwickler zur Erstellung überschaubarerer Anwendungen zu bewegen, ist leichter als Sie denken. Alles beginnt mit der Kommunikation. Entwickler sehen Software anders als Administratoren. Erst im Gespräch mit Entwicklern können Administratoren erläutern, was ihnen wichtig ist, sodass die Entwickler entsprechend besseren Code entwickeln können.
Es ist schon merkwürdig, dass Entwickler und Administratoren Software aus einem völlig unterschiedlichen Blickwinkel betrachten. Entwickler arbeiten mit Code, Ablaufverfolgungen, XML-Konfigurationsdateien, GUIDs und Assemblys. Administratoren arbeiten mit Skripts und Snap-Ins der Microsoft® Management Console (MMC) (oder würden es zumindest gern tun).
Gehen wir einen Schritt zurück. Manchmal scheint mir der gesamte Softwareentwicklungsprozess irgendwo unterbrochen zu sein. Wir investieren Unmengen von Ressourcen, um herauszufinden, was der Endbenutzer will. Wir erstellen Prototypen, führen Benutzerfreundlichkeitsstudien und Interviews durch und vieles mehr, doch wenn es darum geht, eine einfache, konsistente und benutzerfreundliche Verwaltung zu liefern, scheitern wir. Wir scheitern sogar deutlich.
Ich war immer der Meinung, dass Xcopy, Regedit und Editor die besten Möglichkeiten seien, Software zu installieren. Jetzt weiß ich, dass dies am besten mit einem Microsoft Installer (MSI) geht, der installiert, angepasst und deinstalliert werden kann. Es ist wahrscheinlich nicht die genialste Idee, von einem Administrator zu erwarten, dass er mithilfe von Editor einen Webdienst konfiguriert, um XML zu bearbeiten, und dass ein MMC-Snap-In (oder ein Windows PowerShell™-Skript) eine weitaus bessere Wahl ist. Mir ist bewusst, dass eine Stapelüberwachung dem Benutzer oder Administrator nicht hilft, die Hauptursache und möglichen Lösungen für ein Problem anzugeben, sondern dass ein gut in die Anwendungsprotokolle geschriebenes Ereignis nützlicher ist. Mir ist weiterhin bewusst, dass Administratoren beim Erstellen von Software als Benutzer behandelt werden müssen, da sie die Software verwalten und bedienen.
Wenn der Administrator als Benutzer angesehen wird, können Anwendungsfälle definiert, Prototypen erstellt, Nutzbarkeitsstudien durchgeführt werden und so weiter. Dies versetzt mich in die Lage, Administratoren die bestmögliche Erfahrung bereitzustellen. Anders gesagt hilft es Administratoren, die Software zu installieren, zu konfigurieren, zu überwachen, Probleme zu behandeln und zu beheben, ohne den Entwickler rufen zu müssen. Bei Verwendung von Verwaltungsfunktionen in einem Betriebssystem, mit dem der Administrator vertraut ist, können die Kosten für die Ausführung der Anwendung erheblich gesenkt (weniger Problemeskalationen), die Kundenzufriedenheit verbessert (die Anwendung fällt seltener aus und Probleme können schnell behoben werden) und die Wahrscheinlichkeit erhöht werden, dass diese Kunden eher die von mir entwickelte Software kaufen und nicht eine andere (Endergebnis: eine Luxusyacht in der Karibik).
Also gut, das Boot ist nur ein Traum. Aber Entwickler dazu zu bewegen, dass sie leichter zu verwaltende Anwendungen erstellen, ist nicht nur ein Traum, sondern ein erreichbares Ziel. Dabei können auch Sie helfen. Wenn nächstes Mal etwas schief geht, leiten Sie die E-Mail-Nachricht nicht bloß einfach weiter und ärgern sich dabei still vor sich hin. Schlagen Sie dem Entwickler stattdessen vor, ein Ereignis in das Anwendungsprotokoll zu schreiben bzw. einen Leistungsindikator oder einen anderen Hinweis auf das Problem bereitzustellen. Noch besser ist es, wenn Sie eine mögliche Ursache und Lösung vorschlagen. Bitten Sie den Entwickler, ein Windows PowerShell-Skript oder eine MMC-Konsole zu erstellen, um die Anwendung zu konfigurieren. Entwickler wissen nämlich nicht immer, dass es Sie gibt oder was Ihre Anforderungen sind. Teilen Sie ihnen also Ihre Bedürfnisse mit.


 Windows Confidential: Was neue Benutzer im Startmen&#252; sehen
Windows Confidential Was neue Benutzer im Startmenü sehen and Raymond Chens Stellen Sie sich vor, Sie kaufen einen neuen Computer, starten Windows, klicken auf die Schaltfläche „Start“ und sehen ein leeres Menü. Es gibt einen guten Grund dafür, warum das Startmenü Anwendungen als die am meisten verwendeten auflistet, noch bevor Sie irgendetwas verwendet haben, nämlich eine gute Benutzererfahrung. Finden Sie heraus, wie diese Anwendungen ausgewählt werden.
Wir dachten weiterhin daran, dieses anfänglich leere Startmenü mit Text zu versehen. Der Inhalt sollte etwa so lauten: „Noch ist dieser Bereich leer, doch sowie Programme ausgeführt werden, werden sie hier aufgelistet.“ Und schon wirkte der Bereich nicht mehr albern. Er wirkte jetzt albern und noch dazu unschön.
Das Experimentieren dauerte seine Zeit, doch letzten Endes haben wir uns für das entschieden, was Sie in Windows XP sehen. Im letzten Monat haben Sie erfahren, dass die Liste der häufig verwendeten Programme auf einem Punktsystem beruht. Die Programme mit den meisten Punkten erscheinen in dieser dynamischen Liste. Für neue Benutzer wurden bestimmte Punkte für verschiedene Programme künstlich eingerichtet. Demzufolge zeigt das anfängliche Startmenü eine Auswahl von Programmen an, um Benutzern eine Vorstellung davon zu geben, was der Computer kann.
Die Anzahl der künstlichen Punkte wurde sorgfältig festgelegt, sodass genügend Punkte vorhanden sind, um das gewünschte Programm in die Liste der häufig verwendeten Programme einzureihen, aber nicht so viele, dass sie im Gegensatz zu den echten Punkten, die sich die Programme bei jedem Benutzerstart verdienen, überwiegen.
Diese künstlichen Punkte werden jedoch nicht vergeben, wenn der Benutzer von Windows 2000 aktualisiert hat. In diesem Fall bilden die Punkte, die das Windows 2000-Startmenü für Intellimenus verwendet hat, die Basis für das Windows XP-Punktesystem. Auf diese Weise spiegelte das Startmenü für eine aktualisierte Installation von Windows XP die Programme wider, die unter Windows 2000 am häufigsten zur Anwendung kamen.
In der ersten Veröffentlichung von Windows XP wurden die künstlichen Punkte so zugewiesen, dass die ersten drei der sechs Ränge in der Liste der am häufigsten verwendeten Programme von Windows ausgewählt wurden und die letzten drei vom Computerhersteller. Bei einer Einzelhandelsversion (nicht vorinstallierten Version) von Windows XP füllte Windows zwei der drei Ränge und ließ den letzten Rang leer. Dementsprechend wurde das allererste von Ihnen ausgeführte Programm sofort im Startmenü angezeigt.
Diese sechs Ränge wurden in Windows XP Service Pack 1 überarbeitet, sodass zwei der Ränge von Windows, einer vom US-amerikanischen Justizministerium und die letzten drei vom Computerhersteller ausgewählt wurden. Bei Windows XP-Exemplaren aus dem Einzelhandel galt nach wie vor, dass zwei der Ränge von Windows zugewiesen wurden und der letzte Rang leer gelassen wurde.
Das Startmenü ist einer der auffälligsten Bereiche der Windows-Benutzeroberfläche, und wie Sie sehen, ist der Versuch, diesen Bereich so natürlich und intuitiv wie möglich zu gestalten, mit viel Arbeit verbunden.


 Briefe: Antworten auf Ihre Fragen
Briefe Antworten auf Ihre Fragen
Erste Schritte mit Windows PE
Nach der Lektüre des Artikels „Erste Schritte mit Windows PE“ von Wes Miller in der Ausgabe vom September 2006 des TechNet Magazins habe ich ein Menü mit dem HTA-basierten Assistenten (HTML für Anwendungen) erstellt. Ich habe mehrere Fragen dazu, wie das Menü mit Windows® PE 2.0 zusammenarbeitet.
– Andy

Nachfolgend finden Sie die Fragen und Wes' Antworten dazu:

Wie stelle ich fest, ob die optionalen Softwarekomponenten HTA und Windows Script Host (WSH) von meiner ISO-Datei aus laufen?
Wenn Sie optionale Komponenten in Ihrer ISO-Datei gemäß den von der Dokumentation bereitgestellten Anweisungen installiert haben, müssten sie funktionieren. Mir sind zwei häufige Szenarios bekannt, bei denen das nicht der Fall ist: Wenn Sie peimg/prep zur Vorbereitung des Abbilds nicht ausgeführt haben, oder wenn Sie den Parameter „/commit“ nicht mit ImageX verwendet haben, um beim Bereitstellen die Änderungen wirklich auf das Windows PE-Abbild zu übertragen.

Muss bei mir Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) installiert sein? Die Assistentendateien aus dem Artikel ergeben bei mir einen Internet Explorer®-Fehler.
Die Assistentendateien müssten funktionieren, solange HTAs installiert sind. Sie sind äußerst elementar. WMI ist für sie nicht nur nicht erforderlich, sie wurden sogar geschrieben, bevor WMI Windows PE hinzugefügt werden konnte.

Wie soll ich meiner startnet.cm-Datei OC.bat hinzufügen?
Es ist nicht erforderlich, OC.bat zu verwenden, wenn Sie Windows PE 2.0 verwenden. Dies ist nur für 1.x erforderlich. Windows PE 2.0 ermöglicht das Hinzufügen von Komponenten ohne das von OC.bat verwendete Shimming.

Kann ich in meinem Menü etwas von Wes' Code verwenden, wenn das Menü vollständig funktioniert?
Selbstverständlich. Suchen Sie sich beliebige Codebeispiele aus, um sie ganz nach Wunsch wiederzuverwenden. Sie dürfen sie jedoch nicht wiederverkaufen oder als Teil eines Beispielcodepakets weitervertreiben. Ausführlichere Informationen hierzu finden Sie im Lizenzvertrag auf der TechNet Magazin-Website.

Wo befindet sich Windows PE?
Wo finde ich die Windows PE-Buildtools? Kann ich sie herunterladen, oder muss ich sie kaufen?
– Franklin
Die Windows PE-Buildtools für Windows Vista™ sind Teil des Windows Automated Installation Kit (WAIK). Sie finden diesen Download unter go.microsoft.com/fwlink/?LinkId=85377.
Das WAIK ist nur für die Windows Vista-Betriebssystemfamilie bestimmt. Für die Bereitstellung von Windows XP sind viele ähnliche Tools im Business Desktop Deployment Solution Accelerator verfügbar. Allerdings hat sich die Lizenzierung für Windows PE mit Windows Vista geändert. Früher (für Windows XP) war Windows PE nur über Software Assurance-Lizenzierung verfügbar (ausführlichere Informationen hierzu finden Sie unter microsoft.com/licensing/sa/benefits/winpe.mspx).

Ressourcen-Manager für Dateiserver
Wird das Ressourcen-Manager-Paket für Dateiserver als offizieller Download für die Verwendung mit der ursprünglichen Version von Windows Server® 2003 zur Verfügung gestellt? Oder ist dieses Paket nur mit der Version R2 kompatibel?
– Dan
Der Ressourcen-Manager für Dateiserver ist ein Feature von Windows Server 2003 R2. Aufgrund von Abhängigkeiten in dieser Version ist derzeit nicht vorgesehen, ihn für frühere Versionen verfügbar zu machen.

Einblick in den Kernel
Nach Lektüre des Artikels von Mark Russinovich „Einblick in den Windows Vista-Kernel: Teil 3“ habe ich zwei Fragen. Erstens: mir fiel auf, dass Process Explorer anzeigt, wo sich EXE- oder DLL-Dateien zufällig bei jeder Startsitzung befinden. Könnte Malware möglicherweise denselben Mechanismus verwenden, um den Speicherort von Code festzustellen und diesen dann auszunutzen? Zweitens: wenn es 256 Positionen gibt, von denen aus die zufällige Anordnung starten kann (wenn ich den Artikel richtig verstehe), was verhindert dann „Brute-Force“-Angriffe von Malware, wenn der Zielcode für die Sitzung statisch bleibt?
– Joe

Mark Russinovich kann beide Fragen beantworten:

Process Explorer legt eine Huhn-Ei-Situation an den Tag: Die Malware kann nicht herausfinden, wo die DLLs sind, weil sie nicht herausfinden kann, wo sich die API befindet, die diese Informationen zurückgibt. „Brute-Force“-Angriffe durch Malware haben wenig Aussicht auf Erfolg, denn wenn die Malware falsch rät, wird sie höchstwahrscheinlich die Anwendung zum Absturz bringen, die sie zu infizieren versucht. Im ungünstigsten Fall verlangsamt die zufällige Anordnung die Ausbreitung eines Virus. Im besten Fall hindert sie die Malware daran, ein System zu infizieren.

Kontakt
Sie möchten uns etwas mitteilen? Nur zu! Wir hören gern von unseren Lesern. Senden Sie uns eine E-Mail unter tnmag@microsoft.com.