Teil 2 - Einrichtung von Data Recovery AgentsEFS Recovery – oder: Vorsorge ist alles

Teil 3 - Fazit und Empfehlungen

Autor: olc, MCSEboard.de

 

Abb. 05

Nur bei korrekter Vorsorge sollte man Benutzern die Möglichkeit geben, EFS zu nutzen. Kann oder will man die privaten Schlüssel der DRAs nicht entsprechend anlegen, pflegen und sichern, sollte man Benutzern nicht erlauben, EFS Verschlüsselung zu nutzen. Hierzu kann man in der lokalen Gruppenrichtlinie bei Workgroup Clients als auch in der „Default Domain Policy“ in Domänen über einen Rechtsklick auf den entsprechenden Policy Ordner „Verschlüsselndes Dateisystem“ --> „Eigenschaften“ die Nutzung des EFS untersagen (siehe Abb. 05).

Sorgt man nicht frühzeitig vor, sind im schlimmsten Fall unternehmenskritische Daten verloren – denn meist werden Benutzer gerade die Dateien verschlüsseln, die sie als besonders wichtig bzw. vertrauenswürdig halten. Es kommt dann nicht selten einem unternehmerischen Super-GAU gleich, sollten diese Daten verloren gehen. Es ist also dringendst anzuraten, gleich bei Installation eines Workgroups Clients oder nach dem Promoten einer neuen Domäne die beschriebenen Sicherheitsvorkehrungen zu treffen – später lässt sich bei Problemen meist nichts mehr „drehen“ – die Daten sind dann verloren.

Viele Datenrettungsunternehmen versprechen dann Abhilfe mit Ihren Programmen – in den meisten Fällen ist dies jedoch nur Marketing dieser Firmen: Ohne privaten Schlüssel des entsprechenden Benutzers läuft in der Praxis fast nichts. Man sollte hier genau prüfen, ob die Firma wirklich das halten kann, was sie verspricht.

„Vielversprechender“ sind da die Ansätze, in der Pagefile oder dem Hibernate-File nach den Daten zu forschen – wurde hier jedoch vom Benutzer oder Systembetreuer aufgeräumt und vorgesorgt, ist auch das kaum möglich. Solange eine Datei nicht in einem verschlüsselten Ordner liegt, kann man theoretisch über die angelegten temporären Dateien an die Daten kommen. In der Praxis ist jedoch selbst dies fast nie von Erfolg gekrönt – wer einmal versucht hat eine unverschlüsselte Datei wiederzubekommen weiß, welchen Aufwand man dafür betreiben muss. Versucht man es mit einer verschlüsselten Datei, potenziert sich der Aufwand entsprechend. Spätestens wenn der ganze Ordner über der Datei verschlüsselt wurde, kommt man auch hier kaum noch an die Daten. Das entsprechende Verschlüsselungsflag greift nämlich in diesem Fall auch auf die temporären Dateien…

Es macht in jedem Fall Sinn vor dem Neuinstallieren eines Client PCs oder aber auch dem Verändern von Einstellungen der GPOs zu EFS zu prüfen, ob verschlüsselte Dateien auf den Systemen vorliegen. Um alle verschlüsselten Dateien eines Verzeichnisses oder Volumes anzuzeigen, kann man beispielsweise folgende Kommandozeile verwenden:

C:\>cipher.exe /i /h /s:C:\ | findstr /c:"^E "/r

HINWEIS: Bei der Kommandozeile nicht das Leerzeichen zwischen dem “/C:“^E ” und dem darauf folgendem Anführungszeichen vergessen – sonst werden unter Umständen  zu viele Dateien angezeigt. Es werden mit diesem Befehl alle verschlüsselten Dateien angezeigt, da diese beim Aufruf von “cipher.exe” mit einem “E” zum Zeilenanfang gekennzeichnet sind. Aber Achtung: In einigen Windows Versionen wird vor dem „E“ ein Punkt mit angegeben – hier würde die findstr-Option /c:“^.E“ lauten. Im besten Fall also vor dem produktiven Einsatz einmal testen.

Möchte man sich Informationen zu den verschlüsselten Dateien anzeigen lassen, wie zum Beispiel die entschlüsselungsberechtigten Benutzer und den Data Recovery Agent, kann man beispielsweise „efsinfo.exe“ aus den Windows Support Tools verwenden:

C:\>efsinfo /r /u /c /S:"C:\Daten"

C:\Daten

.: Not Encrypted

Neuer Ordner: Encrypted
  Users who can decrypt:
    TESTDOM\user1 [user1(user1@testdom.intern)]
    Certificate thumbprint: 2A77 E829 44EB DEA4 638F D61B 4BB2 2E93 95F9 9E02
  Recovery Agents:
    Administrator
    Certificate thumbprint: DD6B E6AC 3A67 C012 7630 EA69 6B7E BCEA 46BD 87CA

C:\Daten\Neuer Ordner\

Neu Textdokument.txt: Encrypted
  Users who can decrypt:
    TESTDOM\user1 [user1(user1@testdom.intern)]
    Certificate thumbprint: 2A77 E829 44EB DEA4 638F D61B 4BB2 2E93 95F9 9E02
  Recovery Agents:
    Administrator
    Certificate thumbprint: DD6B E6AC 3A67 C012 7630 EA69 6B7E BCEA 46BD 87CA

Ein weiteres, sehr gutes Tool dafür von Sysinternals heißt „EFSDump“ [4]. Es stellt die Informationen der verschlüsselten Dateien sehr übersichtlich dar. Achtung: Setzt man hinter den Verzeichnispfad einen Backslash „\“, muss auch ein „*.*“  folgen, sonst wird das Verzeichnis nicht komplett durchsucht.

C:\>efsdump.exe -q -s C:\Daten

EFS Information Dumper v1.02
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

C:\Daten\Neuer Ordner\Neu Textdokument.txt:
DDF Entry:
    TESTDOM\user1:
        user1(user1@testdom.intern)
DRF Entry:
    Unknown user:
        Administrator

Weiterhin macht es Sinn, regelmäßig die Profile von EFS Benutzern zu sichern – so kommt man im Worst Case Szenario noch an die privaten Schlüssel der Benutzer und kann mit diesem angemeldet ggf. die Daten wiederherstellen. Hier muss jedoch das Kennwort auf den Wert gesetzt werden, den das Profil zum Zeitpunkt der Sicherung hatte. Sonst wird der Zugriff auf den Master Key des Benutzers verweigert. Es gilt auch zu beachten, dass die Benutzer ggf. mehrere Profile auf unterschiedlichen Rechnern haben, sollten keine Roaming Profiles eingesetzt werden. Hier hat also jedes System seinen eigenen privaten Schlüssel des Benutzers, der zur Entschlüsselung ohne DRA genutzt werden muss. Kann man die Profile nicht sichern, sollten rechtzeitig die privaten Schlüssel der Benutzer exportiert werden – dabei kann so vorgegangen werden, wie oben in Bezug auf den Data Recovery Agent beschrieben.

 

 

© MCSEboard.de, olc

Teil 2 - Einrichtung von Data Recovery AgentsEFS Recovery – oder: Vorsorge ist alles