Sicherheit auf dem PrüfstandBereitstellen von EFS: Teil 2

John Morello

Jede Bereitstellung des verschlüsselnden Dateisystems (Encrypting File System, EFS) besteht hauptsächlich aus zwei Teilen: dem Back-End-Entwurfsanteil mit Schwerpunkt auf Zertifikatsverwaltung und Wiederherstellungs-Agents und dem an die Benutzer gerichteten EFS-Bereitstellungsanteil. Im Beitrag des letzten Monats wurde der Back-End-Anteil behandelt, und es wurden Optionen für die Daten- und Schlüsselwiederherstellung erörtert.

Außerdem wurden die Optionen für das Ausstatten von Clients mit Zertifikaten behandelt. Im vorliegenden Artikel werden die Aspekte der Bereitstellung behandelt, die Ihre Endbenutzer betreffen. Dazu gehören Verbesserungen von Windows® Explorer, das Auswählen der zu verschlüsselnden Dateisystemspeicherorte und das Verwalten von Verschlüsselungsoptionen mittels Gruppenrichtlinien.

Ermitteln des Verwendungsstatus von EFS

Wenn Sie sich dafür entschieden haben, EFS bereitzustellen, besteht der erste Schritt darin, den aktuellen Verwendungsstatus von EFS innerhalb Ihrer Organisation festzustellen. Denken Sie daran, dass EFS in eigenständigem Modus verwendet werden kann, in dem allein der Endbenutzer für die Erstellung und Sicherung der Verschlüsselungsschlüssel verantwortlich ist. Möglicherweise befinden sich in Ihrer Organisation fortgeschrittene Benutzer, die bereits EFS in diesem Modus verwendet haben. Es ist deshalb wichtig zu wissen, wer diese Benutzer sind, um einen reibungslosen Wechsel zu einer besser überschaubaren Bereitstellung zu gewährleisten.

Das erste Mal, wenn EFS von einem Benutzer auf einem Computer bereitgestellt wird, erstellt Windows den folgenden Registrierungseintrag in HKEY_CURRENT_USER:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash 

Mit Microsoft® Systems Management Server (SMS), Active Directory-Anmeldeskripts oder anderen Tools kann geprüft werden, ob dieser Eintrag auf den Computern in Ihrem Unternehmen vorhanden ist. Wenn dieser Registrierungswert auf dem Computer eines Benutzers vorhanden ist, dann hat er/sie EFS schon einmal verwendet. Dieser Wert zeigt jedoch nicht unbedingt an, dass jemand derzeit EFS verwendet oder dass Daten dieses Benutzers verschlüsselt wurden. Deshalb sollte ein Computer näher untersucht werden, um zu bestimmen, ob er derzeit verschlüsselte Daten enthält, falls dieser Registrierungswert auf dem Computer eines Benutzers festgestellt wird.

Durch die Verwendung von cipher.exe und die Übergabe der /U- und /N-Schalter wird die Verschlüsselung angewiesen, einen Bericht über den Verschlüsselungsstatus der Dateien und Verzeichnisse auf einem Computer zu erstellen. Wenn Sie zum Beispiel bestimmen wollen, ob Daten auf einem System verschlüsselt wurden, können Sie den folgenden Befehl ausführen:

cipher /U /N

Die Registrierungsüberprüfung und der Verschlüsselungsbericht könnten in einem einzigen Skript kombiniert werden, sodass sie prüfen, ob der Registrierungswert vorhanden ist, und falls er vorhanden ist, einen Bericht über derzeit verschlüsselte Dateien auf dem Computer generieren. Nachdem diese Berichte generiert sind, wissen Sie, welche Dateien von welchen Benutzern verschlüsselt wurden, und Sie sind bereit, sie zu einem zentral verwalteten Entwurf zu migrieren.

Um die Anwendung von Gruppenrichtlinien während der Bereitstellung zu steuern, ist es nützlich, zwei Sicherheitsgruppen in Ihrer Domäne zu erstellen, um die Computer, auf denen EFS verwendet wird, von denjenigen zu trennen, auf denen EFS nicht verwendet wird. Zum Beispiel würde „SG-ComputersUsingEFS“ die Computerkonten der Computer enthalten, auf denen EFS bereits verwendet wird, während „SG-ComputersNotUsingEFS“ alle Computer enthalten würde, auf denen EFS derzeit nicht verwendet wird.

Steuern der EFS-Verwendung mittels Gruppenrichtlinien

Nachdem erst einmal bekannt ist, von wem EFS verwendet bzw. nicht verwendet wird, besteht der nächste Schritt in Ihrer Clientbereitstellung darin, die eigenständige EFS-Verwendung für alle Benutzer, die EFS derzeit nicht verwenden, zu deaktivieren. Dies ist ein wichtiger Schritt im Bereitstellungsprozess, weil es leichter ist, EFS beim ersten Mal ordnungsgemäß zu aktivieren und zu konfigurieren, statt Benutzer zu migrieren, die selbstsignierte Zertifikate verwenden. Dieser Schritt sollte nur dann ausgeführt werden, nachdem feststeht, welche Benutzer EFS bereits verwenden, denn dadurch, dass EFS durch Gruppenrichtlinien deaktiviert wird, können die Benutzer auf keine derzeit verschlüsselten Dateien mehr zugreifen. Sie finden diese Richtlinie im Gruppenrichtlinienobjekt-Editor unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien öffentlicher Schlüssel\Verschlüsselndes Dateisystem.

Wie bereits erwähnt sollte dieser Wert nur auf Computern aktiviert werden, auf denen EFS derzeit nicht verwendet wird, um die Arbeit derjenigen, die bereits mit EFS arbeiten, nicht zu unterbrechen. In diesem Beispiel wird deshalb von der Zugriffssteuerungsliste (ACL) des Gruppenrichtlinienobjekts (GPO), von dem das EFS deaktiviert wird, nur die Gruppe „SG-ComputersNotUsingEFS“ dazu berechtigt, die Gruppenrichtlinie anzuwenden.

Verschlüsseln: Ja oder Nein?

Nachdem erst einmal feststeht, welche Systeme derzeit EFS verwenden, und nachdem Sie EFS auf allen anderen Systemen deaktiviert haben, bis die verwaltete Bereitstellung erfolgt ist, müssen Sie als Nächstes festlegen, was in der verwalteten Bereitstellung verschlüsselt werden soll. Je nachdem, wie Ihre Clientsysteme verwaltet werden, kann sich der Verlauf dieses Prozesses einfach oder aber auch recht schwierig gestalten.

Bei der Frage, welche Dateien verschlüsselt werden sollen, muss als Erstes die Überlegung angestellt werden, ob Ihre Benutzer die Administratoren ihrer Systeme sind. Falls Ihre Benutzer lokale Administratoren sind, können Sie sie eigentlich nur darin schulen und dazu ermutigen, vertrauliche Daten zu verschlüsseln. Sie können dies jedoch nicht wirklich in einer verwalteten Weise kontrollieren. Der Grund dafür ist einfach: Ein lokaler Administrator kann Dateien und Verzeichnisse an einem beliebigen Ort auf dem Dateisystem erstellen. Folglich können Sie allgemein verwendete Speicherorte verschlüsseln, wie z. B. „Eigene Dateien“. Wenn der Benutzer jedoch ein neues Verzeichnis an einem anderen Speicherort erstellt und vertrauliche Informationen dort speichert, ist es sehr schwer sicherzustellen, dass diese Daten ebenfalls geschützt werden. Abgesehen von allen anderen Sicherheitsvorteilen, die erzielt werden, wenn es sich bei Endbenutzern nicht um lokale Administratoren handelt, trägt dies außerdem dazu bei, dass EFS weit überschaubarer und sicherer wird.

Als nächsten wichtigen Aspekt müssen Sie bei ESF bedenken, dass es sich um eine benutzerspezifische Verschlüsselung handelt. Mit anderen Worten kann alles, was von einem bestimmten Benutzer verschlüsselt wird, nur von demselben Benutzer und keinem anderen entschlüsselt werden, einschließlich des Systemkontos. Davon ist der Datenwiederherstellungs-Agent (Data Recovery Agent, DRA) natürlich ausgenommen. Das heißt: Wenn eine EXE- oder DLL-Datei mit dem Schlüssel eines Benutzers verschlüsselt wurde und ein anderer Prinzipal auf dem System versucht, darauf zuzugreifen, erhält der andere Prinzipal eine Fehlermeldung, dass der Zugriff verweigert wurde. Im Allgemeinen sollen Sie deshalb Dateien oder Verzeichnisse mit ausführbarem Code, auf den möglicherweise mehrere Prinzipale auf einem System zugreifen müssen, nicht verschlüsseln. Windows verhindert die Verschlüsselung von Dateien in %SystemRoot% oder von Dateien, die das Systemattribut aufweisen, doch es kommt oft vor, dass Softwarehersteller für Dienste, die möglicherweise vom Systemkonto ausgeführt werden, Binärdateien in %ProgramFiles% installieren. Dies ist zum Beispiel ein Verfahren, das Laptophersteller allgemein anwenden, wenn sie eine als ein Dienst ausgeführte Leistungs- und Geräteverwaltungssoftware installieren.

Was sind also die Best Practices für EFS-Verschlüsselungsziele, wenn diese beiden Aspekte in Betracht gezogen werden? Die Antwort ist darin zu finden, wie die Systeme Ihrer Benutzer normalerweise konfiguriert sind. In einer gut verwalteten Umgebung mit einem standardisierten Abbild des Betriebssystems können Sie wahrscheinlich den Verschlüsselungsprozess für Benutzer aufgrund der vordefinierten Datenspeicherorte in Ihrem Abbild automatisieren. Wenn Benutzer zum Beispiel nur Daten in %userprofile%\Eigene Dateien speichern können, müssen Sie möglicherweise nur dieses Verzeichnis verschlüsseln. (Hinweis: Gehen Sie beim Verschlüsseln von „Eigene Dateien“ vorsichtig vor, wenn Sie die Ordnerumleitung verwenden. Wenn „Eigene Dateien“ zu einem Server umgeleitet wird, muss für den Server die Option „Für Delegierungszwecke vertraut“ aktiviert und die Zugriffsberechtigung für das Benutzerprofil erteilt werden. In solchen Fällen ist es gewöhnlich leichter, einfach nur den Offlinedateien-Cache zu verschlüsseln (dies wird weiter unten behandelt).

In einer weniger überschaubaren Umgebung (in der Benutzer möglicherweise an viele Orte auf dem Dateisystem schreiben) können Sie die Verschlüsselung von ein paar gemeinsamen Speicherorten automatisieren und anschließend die Benutzer darin schulen, wie sie andere Orte selbst verschlüsseln. Ganz unabhängig von Ihrer Umgebung sollen Sie statt auf Dateiebene immer auf Verzeichnisebene verschlüsseln. Dadurch wird gewährleistet, dass alle Dateien, die in diesem Verzeichnis erstellt werden, einschließlich temporärer Dateien, immer verschlüsselt sind.

Empfohlene Verschlüsselungsorte

Im Allgemeinen sollten folgende Orte verschlüsselt werden: %userprofile%\Eigene Dateien, %userprofile%\Anwendungsdaten\Microsoft\Outlook (es wird davon ausgegangen, dass Sie Microsoft Office Outlook® als Ihren Messaging-Client verwenden) und %userprofile%\Desktop. Das Verschlüsseln von „Eigene Dateien“ schützt den Standardspeicherort für Dateien unter Windows XP. Das Sichern des Outlook-Verzeichnisses stellt sicher, dass vertrauliche E-Mails, die lokal zwischengespeichert werden, ebenfalls verschlüsselt werden. Dies ist insbesondere für Benutzer wichtig, die Outlook 2003 standardmäßig im Cachemodus ausführen. Abschließend ist anzumerken, dass der Desktop oft als eine Art temporäres Verzeichnis verwendet wird, in dem die Benutzer derzeit bearbeitete Dokumente oder oft benutzte Präsentationen ablegen können. Es kann natürlich sein, dass Sie in Ihrer Organisation die Standardorte einiger dieser Verzeichnisse geändert haben, deshalb sollten Ihre Entscheidungen in puncto EFS-Verschlüsselung die normalerweise in Ihrer Organisation verwendeten Speicherorte widerspiegeln.

Zusätzlich zu diesen allgemeinen Best Practices empfiehlt es sich zu untersuchen, ob Anwendungen vorhanden sind, in denen vertrauliche Informationen an alternativen Orten gespeichert sein könnten. Einige Anwendungen speichern Benutzerinformationen zum Beispiel in %ProgramFiles%\AppName statt im Benutzerprofil. Es ist wichtig festzustellen, ob solche Anwendungen auf Ihren Clientsystemen vorhanden sind, damit Sie alle Daten, die diese Systeme verwenden, ordnungsgemäß schützen können. Bestenfalls könnte die Anwendung so konfiguriert werden, dass die Änderungen in einem anderen benutzerprofilspezifischen Pfad (wie z. B. „Eigene Dateien“) gespeichert werden, in dem keine weiteren EFS-Änderungen erforderlich sind. Schlimmstenfalls, d. h. wenn die Anwendung erfordert, dass Daten im Verzeichnis „Programme“ gespeichert werden, könnte EFS dazu verwendet werden, um nur dieses eine Unterverzeichnis von „Programme“ zu verschlüsseln.

Abschließend ist Folgendes anzumerken: Gehen Sie vorsichtig vor, falls Sie planen, das temporäre Verzeichnis (%TMP% und %TEMP%) zu verschlüsseln. Viele Anwendungsinstallationsprogramme verwenden dieses Verzeichnis für die Erweiterung des Installationspaketinhalts und führen dann Dateiverschiebungen für die erweiterten Dateien aus, um sie im richtigen Pfad in %ProgramFiles% zu platzieren. Da eine auf dem gleichen Volume verschobene Datei ihre ursprünglichen Attribute beibehält, ist die Datei weiterhin verschlüsselt, nachdem sie nach %ProgramFiles% verschoben wurde. Wenn ein anderer als der das Installationsprogramm ausführende Benutzer versucht, diese Datei zu verwenden, wird der Zugriff verweigert. Oft treten solche Probleme nicht in Form von deutlichen Anwendungsfehlermeldungen auf, in denen die Hauptursache angezeigt wird. Deshalb empfiehlt sich im Allgemeinen, dass %TMP% nur in gut verwalteten Umgebungen verschlüsselt wird, in denen die Endbenutzer die Anwendungen nicht eigenständig installieren.

Schützen von Offlinedateien

„Offlinedateien“ ist ein Feature in Windows 2000 und höher, mit dem die Benutzer eine lokale Kopie der Daten, die auf einem Dateiserver gespeichert sind, erstellen können. Es ermöglicht das Bearbeiten dieser Daten, wenn keine Verbindung zum Server besteht, und das Synchronisieren von Änderungen mit dem Server, sobald er wieder verbunden wird. Bei Offlinedateien handelt es sich jedoch nicht einfach um ein Verzeichnis, das vom Server stammende Kopien der Dateien enthält. Vielmehr ist es eine Datenbank, die systemübergreifend freigegeben ist und im Kontext des Systemkontos ausgeführt wird. In Windows XP kann diese Datenbank mit EFS geschützt werden. Bedenken Sie, was dies angesichts des weiter oben behandelten Aspekts, dass EFS benutzerspezifisch ist, bedeutet. Wie kann EFS, das benutzerspezifisch ist, eine Datenbank verschlüsseln, die von mehreren Sicherheitsprinzipalen verwendet wird?

Wenn ein Benutzer, der Windows XP ausführt, die Option in Windows Explorer zur Verschlüsselung von Offlinedateien auswählt, unterscheidet sich die Verschlüsselungsroutine von derjenigen, die der Benutzer möglicherweise für andere Verschlüsselungsvorgänge verwendet. Statt für den Prozess das persönliche EFS-Schlüsselpaar des Benutzers zu verwenden (was den Zugriff des Systems auf die Dateien verhindern würde), generiert das Systemkonto selbst ein Schlüsselpaar für die Verwendung mit EFS und verwendet dieses Schlüsselpaar, um den clientseitigen Cache zu verschlüsseln. Dies hat eine ernsthafte Sicherheitsimplikation zur Folge, denn wenn jemand nachträglich einen Code abrufen kann, um das System auszuführen, können die Daten im Cache entschlüsselt werden. Nach dem Diebstahl eines Laptops ist es für einen Angreifer einfach, das Administratorkennwort zurückzusetzen und sich als Administrator anzumelden. Wenn jemand sich bereits als Administrator angemeldet hat, ist es ebenso einfach, einen Code zur Ausführung als System durchzusetzen und dann auf den Cache zuzugreifen. (Beachten Sie, dass dieses Verhalten in Windows Vista™ geändert wurde. Windows Vista verwendet jetzt den Schlüssel der einzelnen Benutzer, um benutzerspezifische Offlinedateien zu verschlüsseln.)

Um sich gegen diese Art von Angriff zu schützen, kann der Laptop so konfiguriert werden, dass der Verschlüsselungsschlüssel für die Datenbank der Sicherheitskontenverwaltung (Security Accounts Manager, SAM) offline gespeichert wird, und zwar entweder als Kennworteingabe zur Startzeit (Modus 2) oder auf einer Diskette während des Startvorgangs (Modus 3). Beide Methoden können umständlich sein, da sie eine nicht automatisierbare Interaktion mit dem Computer während des Startvorgangs erfordern, was möglicherweise zu Problemen mit einer automatisierten Verwaltung von Systemen führt. Wenn EFS jedoch auf einem Computer mit Offlinedateien verwendet werden soll, ist es wichtig, dass eine dieser Optionen verwendet wird, um die Daten im Cache zu sichern. Normalerweise empfiehlt sich die Verwendung der Kennworteingabe zur Startzeit (siehe Abbildung 1). Der Grund ist: Wenn ein Laptop samt Tasche gestohlen wird, befindet sich der Datenträger entweder bereits im Laptop oder aber mit großer Wahrscheinlichkeit zusammen mit dem Laptop in der Tasche.

Abbildung 1** Automatisieren der EFS-Vorgänge **

Aktivieren von EFS

Wenn feststeht, was auf Ihrem Client verschlüsselt werden soll, wird als Nächstes der eigentliche Verschlüsselungsvorgang durchgeführt. Dieser Prozess kann durch ein Anmeldeskript oder einen anderen Prozess erzielt werden, bei dem ein Skript auf dem Client ausgeführt wird, das cipher.exe zum Durchführen des Verschlüsselungsvorgangs aufruft. Falls sich in Ihrer Umgebung eigenständige EFS-Benutzer befinden, empfiehlt sich wie weiter oben ausgeführt, dass sie zuerst migriert werden.

Zum Migrieren dieser eigenständigen Benutzer müssen die Clientsysteme als Erstes mit verwalteten Zertifikaten ausgestattet werden (siehe Artikel dieser Rubrik vom Februar 2007 unter https://www.microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch/). Nachdem sich alle Systeme für diese verwalteten Zertifikate registriert haben, sollte die Verschlüsselung mit dem /U-Schalter ausgeführt werden, um alle vorhandenen Dateien mit der neuen Verschlüsselung und den Schlüsseln der Wiederherstellungs-Agents zu aktualisieren. An diesem Punkt nutzen alle Systeme in der SG-ComputersUsingEFS-Gruppe EFS im verwalteten Modus, einschließlich zentral veröffentlichter (und möglicherweise archivierter) Schlüssel und zentral verwalteter Wiederherstellungs-Agents.

Zum Bereitstellen von EFS für die Benutzer, die EFS derzeit nicht verwenden, müssen Sie zuerst die Gruppenrichtlinie, die die EFS-Verwendung verhindert, entfernen. Sobald dies abgeschlossen ist und die Benutzer sich für verwaltete Zertifikate registriert haben, kann ein Anmeldeskript ausgeführt werden, um die weiter oben behandelten Schlüsselpfade zu verschlüsseln. Hier ist ein vereinfachtes Skriptbeispiel:

cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"

Nachdem Sie EFS für die gewünschten Verzeichnisse aktiviert haben, sollten Sie erwägen, zwei zusätzliche Optionen festzulegen, um die Sicherheit Ihrer EFS-Bereitstellung zu erhöhen. Beide Optionen beziehen sich auf Daten, die vom Speicher auf Datenträger ausgelagert werden. Beachten Sie, dass bei jedem dieser Szenarios die Datenmenge, die von einem Angreifer gegebenenfalls wiederhergestellt werden kann, sich darauf beschränkt, was bei legitimer Verwendung im Speicher enthalten war bzw. auf Datenträger umgelagert wurde. Anders gesagt, wenn ein Benutzer vertrauliche EFS-geschützte Daten auf dem Computer hat, die er/sie noch nicht angezeigt hat (und die sich deshalb noch nicht im Speicher befinden), dann sind diese Daten durch diese Angriffsmethoden nicht gefährdet.

Die Auslagerungsdatei wird von Windows als virtueller Arbeitspeicher verwendet (in anderen Betriebssystemen oft Auslagerungsbereich genannt) und enthält unverarbeitete speicherinterne Daten, die als Klartext auf die Festplatte geschrieben werden. Dies kann vertrauliche Daten auf einem EFS-geschützten System gefährden. Denn wenn ein Angreifer die Auslagerungsdatei wiederherstellen kann, können mit forensischen Tools aus dieser Datei brauchbare Daten extrahiert werden. Da die Auslagerungsdatei selbst in Windows XP nicht verschlüsselt werden kann (beachten Sie, dass sie in Windows Vista verschlüsselt werden kann) ist die beste Option, dass Windows gezwungen wird, sie beim Herunterfahren zu löschen. Dies kann über eine Gruppenrichtlinie erreicht werden (siehe Abbildung 2).

Abbildung 2** Einstellen einer Gruppenrichtlinie **(Klicken Sie zum Vergrößern auf das Bild)

Der Nachteil dieser Einstellung ist die beachtliche zeitliche Verzögerung beim Herunterfahren eines Computers, insbesondere wenn der Computer über viel Speicherplatz verfügt. (Standardmäßig bezieht sich die Größe der Auslagerungsdatei direkt auf die Größe des physischen Speichers im Computer.) Dies liegt daran, dass Windows vor dem Herunterfahren physisch in jede Seite auf dem Datenträger schreiben muss, um die Auslagerungsdatei zu löschen.

Die Ruhezustanddatei in Windows enthält ein Speicherabbild des physischen Speichers des Computers, wenn der Energieverwaltungsmodus so eingestellt ist, dass er den Ruhezustand aktiviert. Wenn der Ruhezustand eintritt, schreibt Windows den vollständigen Inhalt des physischen Speichers auf Datenträger in der Ruhezustanddatei, sodass der Computer in genau dem gleichen Zustand wiederhergestellt werden kann, wenn der Benutzer bereit ist, die Arbeit fortzusetzen. Ebenso wie die Auslagerungsdatei kann die Ruhezustanddatei in Windows XP nicht verschlüsselt werden. Im Unterschied zur Auslagerungsdatei kann der Ruhezustand jedoch nicht direkt von einem GPO aus deaktiviert werden. Es muss stattdessen ein Skript verwendet werden, um powercfg.exe mit dem /HIBERNATE-Schalter aufzurufen, um den Ruhezustand zu deaktivieren (bzw. zu aktivieren).

Nach dem Abschließen Ihrer anfänglichen Verschlüsselungs- und Konfigurationsaufgaben sollten Sie erwägen, den Pufferbereich auf Datenträgern in Ihrer Bereitstellung zu löschen. Dieser Prozess kann sehr aufwändig sein und zu Ausfallzeiten führen, hat jedoch einen Sicherheitsvorteil in Hochsicherheitsumgebungen. Der Pufferbereich ist der Bereich auf dem Datenträger, der keine aktuell im System verwendete Dateien enthält, jedoch aufgrund der Funktionsweise von Festplatten einige vertrauliche Informationen von zuvor verwendeten Dateien enthalten kann. Das heißt: Da beim Löschen einer Datei nicht wirklich alle Sektoren überschrieben werden, die diese Datei auf dem Datenträger beansprucht (es wird nur der Zeiger aus der Dateitabelle entfernt), sind die gelöschten Daten möglicherweise weiterhin auf diesem Datenträger vorhanden. In solch einem Fall können die Daten durch forensische Tools den Pufferbereich lesen und die Dateien daraus wieder zusammensetzen können, wiederhergestellt werden. Führen Sie die Verschlüsselung mit dem /W-Schalter aus, um diese Restdaten sicher zu löschen. Dies zwingt die Verschlüsselung, alle Sektoren, die auf dem Datenträger als verfügbar gekennzeichnet sind, wiederholt zu überschreiben. Solange alle zukünftigen Dateivorgänge im Hinblick auf vertrauliche Daten in EFS-geschützten Verzeichnissen stattfinden, ist es nicht notwendig, diesen Befehl regelmäßig auszuführen.

Verbesserungen in Windows Explorer bezüglich EFS

Standardmäßig sind die Verschlüsselungs- und Entschlüsselungsoptionen für Dateien und Verzeichnisse sozusagen in den erweiterten Eigenschaftenmenüs in Windows Explorer vergraben. Sie können die Benutzerfreundlichkeit von EFS verbessern, indem Sie „Verschlüsseln“ und „Entschlüsseln“ im Kontextmenü von Windows Explorer platzieren (wird durch Klicken mit der rechten Maustaste eingeblendet). Außerdem kann Windows Explorer so konfiguriert werden, dass EFS-geschützte Dateien und Verzeichnisse in einer anderen Farbe (Grün) als andere Dateien angezeigt werden. So werden Benutzer darüber informiert, ob eine Datei bzw. ein Verzeichnis verschlüsselt ist, ohne bis zum erweiterten Eigenschaftenmenü navigieren zu müssen. Abschließend ist anzumerken, dass Sie bei Bedarf eine Option hinzufügen können, um zu definieren, welche Benutzer über eine Zugriffsberechtigung für die Datei oder das Verzeichnis verfügen. Um diese Optionen zu aktivieren, nehmen Sie

following changes in the registry via a script calling reg.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]  
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS in Windows Vista

EFS hat eine Anzahl wichtiger Verbesserungen in Windows Vista erfahren, die seine Bereitstellung und Verwaltung vereinfachen und zudem seine Sicherheit erhöhen. Eine der wichtigsten Verbesserungen ist die volle Unterstützung der Speicherung von EFS-Schlüsseln auf Smartcards. Dies ist ein besonders wertvolles Feature für Organisationen, die bereits eine Smartcardanmeldung verwenden, weil dieselbe Karte außerdem dazu verwendet werden kann, die EFS-Schlüssel von Benutzern zu speichern. Diese Unterstützung für Smartcards umfasst auch Zertifikate der Wiederherstellungs-Agents, sodass die vertraulichen DRA-Zertifikate gleichermaßen auf Karten gespeichert werden können.

Windows Vista unterstützt zudem die Verschlüsselung der Elemente, deren Verschlüsselung bisher in Windows XP entweder nicht möglich oder nur schwer durchführbar war. Windows Vista kann die Auslagerungsdatei verschlüsseln, was die Einstellung der Option „Auslagerungsdatei des virtuellen Arbeitspeichers löschen“ überflüssig macht. Der gesamte Entwurf von Offlinedateien ist in Windows Vista neu gestaltet worden. Abgesehen von der verbesserten Leistung und Stabilität (sowie einer allgemein benutzerfreundlicheren Oberfläche) ist das clientseitige Zwischenspeichern jetzt benutzerspezifisch, d. h. es ist möglich, den Cache ohne die Verwendung des SYSKEY-Modus 2 oder 3 zu verschlüsseln. Diese beiden Verbesserungen beseitigen die größten Bereitstellungsprobleme für die Windows XP-basierten Umgebungen von heute.

Abschließend ist anzumerken, dass Windows Vista Administratoren ermöglicht, die Verschlüsselung des Ordners „Eigene Dateien“ direkt durch eine Gruppenrichtlinie zu konfigurieren, ohne ein separates Skript verwenden zu müssen. Abbildung 3 illustriert die neuen EFS-Eigenschaften, die über GPO in Windows Vista verfügbar sind.

Abbildung 3** EFS-Eigenschaften in Windows Vista **(Klicken Sie zum Vergrößern auf das Bild)

Zusammenfassung

EFS bietet Windows-Administratoren eine sehr sichere Option zum Schutz mobiler Daten. EFS ist skalierbar, verwaltbar und stellt flexible Methoden zur Datenwiederherstellung bereit. In Windows Vista wurde EFS mit erweiterten Funktionen für die leichtere Verwaltung und Bereitstellung sowie mit der Unterstützung für smartcardbasierte Schlüsselspeicherung weiter verbessert. Für Organisationen, die Daten sogar dann, wenn ein Computer physisch verloren gegangen ist, schützen wollen, stellt EFS eine starke Lösung bereit, die bereits Teil Ihrer vorhandenen Windows-Plattform ist.

Informationsquellen

Weitere Informationen zu den Themen, die in diesem Artikel behandelt werden, erhalten Sie in den folgenden Ressourcen:

• Rubrik „Sicherheit auf dem Prüfstand“ vom Februar 2007
• Encrypting File System in Windows XP and Windows Server 2003 (auf Englisch)
• How to Use the SysKey Utility to Secure the Windows Security Accounts Manager Database (auf Englisch)

John Morello hat seine Promotion an der LSU mit Summa cum Laude abgeschlossen und ist seit sechs Jahren in verschiedenen Funktionen für Microsoft tätig. Als leitender Berater hat er Sicherheitslösungen für Fortune 100-Firmen sowie für US-amerikanische Kunden aus dem zivilen Bereich und dem Verteidigungswesen entworfen. Derzeit arbeitet er als Programm-Manager in der Windows Server Group an Sicherheits- und Remotezugriffstechnologien.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.