Teil 1 - Technische Eckdaten des EFSEFS Recovery – oder: Vorsorge ist allesTeil 3 - Fazit und Empfehlungen

Teil 2 - Einrichtung von Data Recovery Agents

Autor: olc, MCSEboard.de

 

Workgroup Clients

Auf Clients, die nicht Mitglied einer Domäne sind, können Data Recovery Agents wie folgt eingerichtet werden. Der angemeldete Benutzer ist dabei nicht relevant, da der private Schlüssel des erzeugten Data Recovery Agents Zertifikat in jedes beliebige Profil importiert werden kann. Dementsprechend hat jeder, der Zugriff auf diesen privaten Schlüssel hat, die Möglichkeit, Dateien anderer Benutzer zu entschlüsseln(!).

C:\> cipher /R:dra

Der Name der Datei ist frei wählbar – im Beispiel wurde „dra“ verwendet. Nach Angabe des Kennworts, welches zum Schutz des privaten Schlüssels verwendet wird, finden sich im gleichen Verzeichnis, von dem aus man den Befehl abgesetzt hat, zwei Dateien: „dra.pfx“ (privater Schlüssel) und „dra.cer“ (öffentlicher Schlüssel).

Abb. 01

Der öffentlichen Schlüssel „dra.cer“ ist nun der lokalen Gruppenrichtlinie des Workgroup Systems hinzuzufügen, damit dieser in den verschlüsselten Dateien aller lokalen Benutzer eingetragen wird. Hierzu öffnet man über „Start“ --> „Ausführen“ --> „gpedit.msc“ die Gruppenrichtlinienverwaltung. In der Gruppenrichtlinienverwaltung wählt man nun die „Computerkonfiguration“ --> „Windows Einstellungen“ --> „Sicherheitseinstellungen“ --> „Richtlinien öffentlicher Schlüssel“ --> Rechtsklick auf „Verschlüsselndes Dateisystem“ --> „Datenwiederherstellungs-Agenten hinzufügen“ (siehe Abb. 01).

Nach einem Klick auf „Weiter“ durchsucht man die lokalen Ordner nach dem soeben erstellen Data Recovery Zertifikat, genauer gesagt dem öffentlichen Schlüssel mit der Endung „*.cer“ und fügt diesen als Wiederherstellungsagenten hinzu. Die Warnung, dass nicht ermittelt werden konnte, ob das Zertifikat gesperrt wurde, kann ignoriert werden – da das Zertifikat selbst erzeugt und nicht von einer CA ausgestellt wurde, kann auch keine Zertifikatkette geprüft werden. Man bestätigt in diesem Fall den Dialog mit „Ja“. Nachdem das Zertifikat hinzugefügt wurde (siehe Abb. 02) klickt man auf „Weiter“ und „Fertig stellen“. Es wird nun der neue Data Recovery Agent im Gruppenrichtlinien-Editor angezeigt (siehe Abb. 03).

Abb. 02
Abb. 03

Sollen weitere Data Recovery Agents hinzugefügt werden, kann man dies mit dem gleichen Vorgehen für jedes neue Zertifikat wiederholen. Dies ist jedoch eher in größeren Umgebungen sinnvoll, wenn die DRAs auf verschiedene Ebenen innerhalb einer AD-Struktur eingebunden werden: So kann ein DRA z.B. für die Geschäftsführung zugewiesen werden, während ein anderer DRA nur die Dateien von anderen Angestellten öffnen darf. Für eine Workgroup Umgebung sind mehrere DRAs meist nicht sinnvoll.

Jedes DRA-Zertifikat bzw. der dazugehörige private Schlüssel muss besonders gut gesichert werden – schließlich ist der jeweilige Data Recovery Agent in der Lage, jede verschlüsselte Datei des gerade konfigurierten Systems zu öffnen. Das heißt also, dass man nun die zweite von „cipher.exe“ erzeugte Datei (den privaten Schlüssel, in unserem Beispiel „dra.pfx“), vom System entfernen und auf einem sicheren Medium in einem Safe o.ä. „wegsperren“ sollte. Neben dem Aufbewahrungsort, dem Medium, welches nicht nach 30 Tagen einen Defekt aufweisen sollte, sollte auch  das Kennwort  aus den genannten Gründen gut überlegt sein.

Zukünftig wird jede verschlüsselte Datei durch den Recovery Agent entschlüsselbar sein, sobald dieser in das DRF eingetragen wurde (auch die schon vorhandenen - siehe jedoch Hinweise dazu weiter oben). Dazu importiert man im Problemfall den privaten Schlüssel per Doppelklick auf die *.pfx Datei oder manuell über die Zertifikate MMC den privaten Schlüssel im besten Fall auf ein alleinstehendes Data Recovery System. Es sollte kein Internetzugang oder ähnliches möglich sein – aus Sicherheitsgründen. Ist der private Schlüssel im lokalen Store des angemeldeten Benutzers auf dem Recovery Systems importiert, kann man die auf dieses Recovery System kopierten „Problemdaten“ entschlüsseln und dem Benutzer wieder zur Verfügung stellen. Danach entfernt man das Zertifikat wieder von diesem System. Das gleiche Vorgehen gilt auch für Domänen Clients.

Das Kopieren der Daten bietet noch einen Stolperstein: Da man keinen Zugriff auf verschlüsselte Dateien hat, können diese so einfach nicht kopiert werden. Hier helfen Backupapplikationen (wie das mitgelieferte NTBackup) die Daten auf den Recovery Client zu übertragen – sie werden vom Quellsystem gesichert und auf dem Recovery System mittels Backup wiederhergestellt.

 

Domänen Clients

In einer Domäne ist das Vorgehen im Grunde analog zu dem oben genannten Vorgehen – mit einigen „kleinen“ Unterschieden:

  • Ein Data Recovery Agent wird in einer Domänenumgebung nicht auf jedem Client lokal festgelegt, sondern zum Beispiel zentral über die „Default Domain Policy“.
  • Dieser Recovery Agent greift für alle verschlüsselten Dateien innerhalb einer Domäne, d.h. auf allen Clients und Servern, die unterhalb der entsprechenden Policy als Domänenmember liegen.
  • Standardmäßig wird automatisch der erste Administrator einer Domäne zum Data Recovery Agent erklärt und auch automatisch in der „Default Domain Policy“ als Data Recovery Agent eingetragen.

Besonders der letzte Punkt ist sehr wichtig und interessant: Beim Erstellen einer Domäne innerhalb eines Forests (oder auch als erste Domäne eines neuen Forests), wird der lokale Administrator-Account der Maschine, auf der das DCPROMO durchgeführt wird, zum Domänen-Administrator. Es wird nun ein EFS Data Recovery Agent Zertifikat automatisch vom Windows Server System erzeugt, welches 3 Jahre Gültigkeit besitzt. Ändert man nichts an der standardmäßigen Konfiguration, wird der öffentliche EFS DRA Schlüssel des ersten Administrators der Domäne also in allen verschlüsselten Dateien auf den Membern der Domäne eingetragen.

Läuft dieser Schlüssel nach 3 Jahren ab, ist es nicht mehr möglich, neue Dateien zu verschlüsseln. Die alten Dateien können auch nach Ablauf des EFS DRA Zertifikats entschlüsselt werden – auch vom Data Recovery Agent, dessen Zertifikat abgelaufen ist. Will man weiterhin Dateien verschlüsseln, muss man das DRA Zertifikat in der Default Domain Policy durch ein neues ersetzen oder das alte entfernen. Im letzteren Fall steht jedoch kein Data Recovery Agent mehr zur Verfügung – diesen Weg sollte man also vermeiden und die erste Variante, einen neuen DRA zu definieren bzw. das Zertifikat ggf. zu verlängern, wählen.

Hier liegt also ein zentraler Punkt in der Verwaltung EFS verschlüsselter Dateien und damit dem EFS Recovery: Da private Schlüssel standardmäßig nur auf der Maschine liegen, auf dem der private Schlüssel erzeugt wurde (in dem konkreten Fall spätestens beim DCPROMO des ersten DCs der Domäne), bedeutet ein Verlust des Administratoren-Profils dieses DCs auch den Verlust des privaten Schlüssels des Data Recovery Agents. Tritt nun wiederum ein Problem mit verschlüsselten Dateien auf, können diese nicht mehr durch den DRA entschlüsselt werden – er ist nicht im Besitz des benötigten privaten Schlüssels zum öffentlichen Schlüssel in der „Default Domain Policy“.

Man muss also vorsorgen: Direkt nach dem DCPROMO des ersten DCs einer Domäne sollte also der private Schlüssel des Administrators für dieses DRA Zertifikat exportiert werden. Ist dies nicht geschehen, sollte man auch nachträglich schauen, ob dies noch möglich ist. Dazu loggt man sich mit dem ersten Administrator-Account der Domäne auf dem ersten DC der Domäne ein und prüft entweder über „certutil.exe“ oder über die Zertifikate MMC, ob der private Schlüssel für das DRA Zertifikat verfügbar ist. Beispielhaft gehen wir den MMC Weg: „Start“ --> „Ausführen“ --> „mmc.exe“

Abb. 04

In der sich öffnenden MMC fügt man über „Datei“ --> „Snap-In hinzufügen/entfernen“ --> „Hinzufügen“ --> „Zertifikate“ --> „Eigenes Benutzerkonto“ das Snap-In für die eigenen Zertifikate hinzu. Wählt man nun unter „Zertifikate – Aktueller Benutzer“ --> „Eigene Zertifikate“ --> „Zertifikate“ das aufgeführte Zertifikat des Administrators aus, kann man bei vorhandenem privaten Schlüssel diesen auch exportieren, was auf jeden Fall geschehen sollte, um für zukünftige Probleme gewappnet zu sein. Ist der private Schlüssel vorhanden, wird dies im Reiter „Allgemein“ des geöffneten Zertifikats angezeigt (siehe Abb. 04).

Hat man diesen privaten Schlüssel nicht mehr (und auch nicht das alte Profil des Administrators mit dem privaten Schlüssel), gibt es keine Chance, im Fehlerfall mit Bordmitteln „Problemdateien“ von Benutzern wieder zu öffnen. Sind noch keine Probleme aufgetreten, sollte man wie bei Workgroup Clients ein Zertifikat erzeugen (oder eines von einer ggf. vorhandenen CA beantragen) und dieses Zertifikat in der „Default Domain Policy“ importieren. So können zumindest die Dateien im Problemfall geöffnet werden, die zum derzeitigen Zeitpunkt noch vom Benutzer oder den Benutzern zugreifbar sind.

Will man den privaten Schlüssel des EFS DRA Zertifikats nun sichern, wählt man auf dem Reiter „Details“ --> „In Datei kopieren“  --> „Weiter“ --> „Ja, privaten Schlüssel exportieren“ und „Weiter“ --> „Privater Informationsaustausch – PKCS #12 (.PFX)“ und bei Bedarf die ersten beiden Haken „Wenn möglich, alle Zertifikate im Zertifizierungspfad mit einbeziehen“ und „Verstärkte Sicherheit aktivieren (IE 5.0, NT 4.0 SP4 oder höher erforderlich)“ und gibt nach einem Klick auf „Weiter“ ein starkes Kennwort zur Sicherung des privaten Schlüssels mit an. Nach der Angabe des Dateinamens und des Speicherorts und dem Fertigstellen des Exports kann der private Schlüssel entsprechend den festgelegten Sicherheitsbestimmungen verwahrt werden. Auch hier gelten die Maßnahmen, die im Teil „Workgroup Clients“ genannt wurden. Nur ein sicherer privater Schlüssel garantiert die Vertraulichkeit der verschlüsselten Daten.

 

© MCSEboard.de, olc

Teil 1 - Technische Eckdaten des EFSEFS Recovery – oder: Vorsorge ist allesTeil 3 - Fazit und Empfehlungen