Sicherheit auf dem PrüfstandBereitstellen von EFS: Teil 1

John Morello

Sicher hat heute schon jeder Berichte zum Verlust persönlicher oder vertraulicher Daten durch den Diebstahl oder Verlust von Laptops gehört. Es kommt häufig vor, dass Laptops verloren gehen. Mit dem Anstieg im Bereich des Identitätsdiebstahls und immer strengeren gesetzlich vorgeschriebenen Konformitätsvorgaben ist der eingehende Schutz von Daten auf mobilen Computersystemen unerlässlich.

Eine Möglichkeit bietet die Nutzung des verschlüsselnden Dateisystems (Encrypting File System, EFS) das in Windows® seit der Version Windows 2000 enthalten ist und eine integrierte, leistungsstarke und datenträgerbasierte Verschlüsselung bereitstellt. EFS ist nahtlos in Windows-Explorer integriert, sodass es die Endbenutzer oft gar nicht bemerken, wenn es sich bei einer von ihnen verwendeten Datei um eine verschlüsselte Datei handelt. Darüber hinaus funktioniert EFS ebenso gut mit den systemeigenen Authentifizierungs- und Zugriffssteuerungstechnologien von Windows. Die Benutzer müssen sich daher nicht mehrere Kennwörter merken, um auf ihre Daten zugreifen zu können. Nicht zuletzt stellt EFS auch verwaltbare Optionen für die Wiederherstellung von Daten in Situationen bereit, in denen ein Benutzer den Zugriff auf seine Verschlüsselungsschlüssel verloren hat (z. B. wenn sein Benutzerprofil gelöscht wurde oder beschädigt ist oder wenn die Smartcard des Benutzers nicht auffindbar ist).

EFS nutzt unter Windows die integrierte Kryptografietechnologie, um leistungsstarke Verschlüsselungsschlüssel zum Schutz von Daten zu generieren, zu speichern und bereitzustellen. Unter Windows XP Service Pack 1 (SP1) und späteren Versionen verwendet EFS den Algorithmus des erweiterten Verschlüsselungsstandards (Advanced Encryption Standard, AES) mit einem 256-Bit-Schlüssel, um Daten auf Datenträgern zu verschlüsseln. Diese symmetrischen Schlüssel werden dann durch ein asymmetrisches (RSA-)Schlüsselpaar geschützt. EFS verschlüsselt jede Datei mit seinem AES-Schlüssel, verschlüsselt dann diesen Schlüssel mit dem RSA-Schlüssel des Benutzers und speichert das Ergebnis in der Datei. Weitere Informationen zur EFS-Kryptografie, finden Sie in der Randleiste „EFS-Ressourcen“. Vorläufig werde ich mich nicht auf die technischen Grundlagen von EFS konzentrieren, sondern auf dessen Bereitstellung und Umsetzung in Ihrer Umgebung. Daher wird in diesem Artikel davon ausgegangen, dass Vorkenntnisse zur EFS-Kryptografie bestehen.

Hinweis zur EFS-Sicherheit

Von einigen Anwendungen wird behauptet, sie könnten die EFS-Verschlüsselung knacken oder entschlüsseln. Keine dieser Anwendungen entschlüsselt tatsächlich den durch AES (oder Data Encryption Standard, DES, oder Expanded Data Encryption Standard, DESX) verschlüsselten Text. Die Anwendung erhält vielmehr Zugriff auf den privaten EFS-Schlüssel des Benutzers, indem ein Brute-Force-Angriff auf das Benutzerkennwort ausgeübt wird. Bei der EFS-Verschlüsselung ist unbedingt zu berücksichtigen, dass die privaten Schlüssel, die zum Generieren und zum Schutz der verschlüsselten Daten verwendet werden, die DPAPI (Data Protection API) einsetzen. DPAPI verwendet Ableitungen der Anmeldeinformationen eines Benutzers zum Schutz von Daten, was dazu führt, dass der Schutz von Daten mit EFS nur so gut wie das Kennwort des Benutzers sein kann. Mit Windows Vista™ können Sie jetzt EFS-Verschlüsselungszertifikate auf Smartcards speichern, um dieses Paradigma aufzuheben und die relative Sicherheit von durch EFS geschützten Daten deutlich zu erhöhen.

Wie lang muss ein Kennwort sein, um diesen Angriffen zu widerstehen? Mit den heutigen Hardwarefunktionen und modernen Kennwortangriffsalgorithmen werden für ein Kennwort (oder, genauer gesagt, für die Passphrase) elf Zeichen oder mehr empfohlen. Eine Passphrase mit elf oder mehr Zeichen bietet einen guten Widerstand gegenüber den heutzutage angewendeten ausgefeilten Methoden, einschließlich vorausberechneter Hashangriffe (wie z. B. Rainbow Table; in der Randleiste „Ressourcen“ im Blog „Why you shouldn’t be using passwords of any kind on your Windows networks“ finden Sie weitere Informationen dazu).

PKI oder keine PKI?

In einer der häufigsten falschen Annahmen zu EFS wird davon ausgegangen, dass für EFS eine PKI (Public Key Infrastructure) erforderlich ist. Obwohl EFS einfach in eine PKI integriert werden und deren Vorteile nutzen kann (sofern Ihre Organisation über eine PKI verfügt), ist eine PKI nicht unbedingt erforderlich. Die Entscheidung, ob eine PKI in Ihrer EFS-Bereitstellung verwendet wird oder nicht, wirkt sich jedoch auf viele zukünftige Bereitstellungsentscheidungen aus. Daher sollte eine solche Entscheidung an erster Stelle stehen.

Der wichtigste Vorteil bei der Verwendung einer PKI mit EFS besteht in der Möglichkeit, Schlüssel zu archivieren und wiederherzustellen. Während EFS nur Administratoren die Durchführung einer Datenwiederherstellung ermöglicht, ist eine automatische Schlüsselwiederherstellung nur mit einer PKI verfügbar und auch nur dann, wenn Windows Server® 2003 Enterprise Edition als Zertifizierungsstelle (Certification Authority, CA) ausgeführt wird. Bei der Datenwiederherstellung handelt es sich um den Prozess, bei dem ein Benutzer, der den Zugriff auf seinen Verschlüsselungsschlüssel verliert, einem bestimmten Administrator, der als Datenwiederherstellungs-Agent (Data Recovery Agent, DRA) bezeichnet wird, seine verschlüsselten Daten bereitstellen kann. Der Agent kann diese Daten dann entschlüsseln und an den Benutzer zurückgeben oder sie für die Verwendung mit einem neuen privaten Schlüssel erneut verschlüsseln. Der DRA arbeitet im Hintergrund des Verschlüsselungsprozesses des Benutzers, wobei sämtliche Daten, die der Benutzer mit seinem Schlüssel verschlüsselt, auch mit einer Kopie des DRA-Schlüssels verschlüsselt werden. Wenn also der Schlüssel des Benutzers verloren geht, kann der DRA eingreifen, die Daten des verschlüsselten Texts abrufen, den DRA-Schlüssel zur Entschlüsselung (oder erneuten Verschlüsselung) darauf anwenden und anschließend die Daten an den Benutzer zurückgeben. Der DRA-Ansatz ist ein gut funktionierendes Verfahren, kann jedoch Schwierigkeiten bei der Verwaltung bereiten, wenn der Benutzer große Datenmengen verschlüsselt hat oder keine lokalen IT-Mitarbeiter die Rolle von DRAs übernehmen können.

Bei der Schlüsselwiederherstellung muss dagegen die Zertifizierungsstelle während des Schlüsselerstellungsprozesses eine Kopie des Verschlüsselungsschlüssels des Benutzers erstellen und diese sicher in der Datenbank der Zertifizierungsstelle speichern. Wenn ein Benutzer den Zugriff auf verschlüsselte Dateien verliert, muss der Zertifizierungsstellenadministrator lediglich auf diese Datenbank zugreifen und den Schlüssel des Benutzers abrufen. Der Benutzer erhält dann wieder umgehend den Zugriff auf seine Daten, ohne dass diese für ihn vom DRA wiederhergestellt werden müssen. Auf diese Weise kann die Schlüsselwiederherstellung schneller und effizienter ablaufen. Beachten Sie jedoch, dass gemäß der bewährten Methode stets DRAs vorhanden sein sollten, auch wenn eine Schlüsselwiederherstellung eingesetzt wird, um für den Fall des Verlusts von Schlüsseln einen Sicherungsmechanismus bereitzustellen. So können auch große Organisationen über ein verteiltes Wiederherstellungssystem verfügen, in dem lokale IT-Administratoren die Daten von Benutzern wiederherstellen können, ohne die PKI-Administratorengruppe einbeziehen zu müssen.

Ein anderer möglicher Vorteil bei der Verwendung einer PKI mit EFS besteht in der einfacheren Freigabe verschlüsselter Dateien. Denken Sie daran, dass EFS nicht nur auf Laptopsysteme beschränkt ist, sondern auch in Situationen wertvolle Unterstützung bietet, in denen die physische Sicherheit eines Computers nicht garantiert werden kann. In solchen Situationen kann es beispielsweise erforderlich sein, dass mehrere Benutzer auf dieselben verschlüsselten Daten zugreifen. Obwohl bei der Windows-Unterstützung Einschränkungen für freigegebene Dateien bestehen, da nur die Freigabe von einzelnen Dateien statt von Verzeichnissen zulässig ist, kann Windows ein nützliches Tool darstellen. Um die Freigabe von EFS-Dateien zu erleichtern, muss der Benutzer, der die Datei freigibt, über Zugriff auf die öffentlichen Schlüssel der Benutzer verfügen, für die die Freigabe erfolgt (dies ist am einfachsten, wenn die Benutzer ein gültiges EFS-Zertifikat besitzen, das in Active Directory® für ihre Konten veröffentlicht wurde). Diese Veröffentlichung kann manuell durchgeführt werden kann. Durch die Verwendung einer Windows-Zertifizierungsstelle, die im Enterprise-Mode (Active Directory-integriert) installiert wurde, wird der Prozess jedoch vollständig automatisiert.

EFS-Schlüsselverwaltung

Wenn eine PKI, die auf Windows Server 2003 basiert, für die Verwendung verfügbar ist, ist die Generierung von EFS-Zertifikaten für Benutzer ein einfacher Prozess. Eine Zertifizierungsstelle von Windows Server 2003 enthält einen Standardsatz von Zertifikatsvorlagen, einschließlich einer Vorlage mit der Bezeichnung „Basis-EFS“. Bei dieser Vorlage handelt es sich jedoch um eine Vorlage der Version 1, die keine Schlüsselarchivierung unterstützt. Daher sollten Sie die Vorlage duplizieren, bevor Sie diese auf Ihrer Zertifizierungsstelle bereitstellen, um eine neue Vorlage der Version 2 zu erstellen (z. B. könnten Sie dieser die Bezeichnung „EFS with Key Archive“ zuweisen, wie in Abbildung 1 dargestellt). Wechseln Sie auf dieser neuen Vorlage zur Registerkarte „Anforderungsverarbeitung“, und wählen Sie die Option zur Archivierung des Verschlüsselungsschlüssels des Benutzers aus. Beachten Sie, dass die Schlüsselarchivierung ordnungsgemäß auf der Zertifizierungsstelle konfiguriert sein muss, bevor Sie diese Option aktivieren. Der Abschnitt mit Ressourcen umfasst eine ausgezeichnete exemplarische Anleitung für den Prozess. Sie sollten diese Vorlage entsprechend einstellen, sodass die Basis-EFS-Vorlage ersetzt wird, um sicherzustellen, dass die Clients die neue Version verwenden (siehe Abbildung 2).

Abbildung 1** EFS mit Schlüsselarchiv **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 2** Ersetzen der Basis-EFS-Vorlage **(Klicken Sie zum Vergrößern auf das Bild)

Im nächsten Schritt müssen Sie in der Vorlage die geeigneten Berechtigungen festlegen, um dem richtigen Benutzersatz Registrierungszugriff auf die Vorlage zuzuweisen. Da die EFS-Komponente unter Windows bei der ersten Verwendung von EFS automatisch ein Zertifikat anfordert, müssen Sie den Benutzern in der Regel keine automatische Registrierung für die EFS-Vorlage erlauben. Es empfiehlt sich vielmehr, keine Aktivierung der automatischen Registrierung für EFS-Zertifikate vorzunehmen, sofern Sie nicht sicher sind, dass alle Benutzer, die eine automatische Registrierung vornehmen können, EFS verwenden. In Abbildung 3 sind die EFS-Registrierungseinstellungen dargestellt. Durch das Ausstellen von Zertifikaten für Benutzer, die wahrscheinlich nie EFS verwenden, wird lediglich die Größe der Zertifizierungsstellendatenbank erhöht, ohne dass ein Nutzen daraus gezogen wird. Auch wenn die Zertifizierungsstellendatenbank selbst keiner Größenbeschränkung unterliegt, kann die Verwaltung der Datenbank bei einer größeren Anzahl an ausgegebenen Zertifikaten erschwert werden (insbesondere bei Verwendung der Microsoft Management Console oder MMC).

Abbildung 3** Einstellen von EFS-Benutzerberechtigungen **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie die Freigabe verschlüsselter Dateien unterstützen müssen, sollten Sie veranlassen, dass die Zertifizierungsstelle das Zertifikat des Benutzers automatisch in Active Directory veröffentlicht.

Sobald Sie die Vorlage ordnungsgemäß auf Ihrer Zertifizierungsstelle konfiguriert haben, erhält ein Benutzer bei der ersten Verschlüsselung einer Datei mit EFS sein Zertifikat von Ihrer Zertifizierungsstelle, und Ihre Zertifizierungsstelle archiviert automatisch seinen privaten Schlüssel.

DRA-Schlüsselverwaltung

Wenn eine PKI vorhanden ist, sollten Sie überlegen, ob Sie durch eine Zertifizierungsstelle generierte DRA-Zertifikate verwenden möchten oder nicht. Was spricht gegen die Verwendung von DRA-Zertifikaten von Ihrer PKI? Betrachten Sie als Beispiel ein Szenario, in dem eine Zertifizierungsstelle mit einem recht kurzen Gültigkeitszeitraum (zwei Jahre oder weniger) Zertifikate ausgibt. Diese Zertifizierungsstelle kann keine Zertifikate ausgeben, deren Gültigkeitsdauer die eigene überschreitet, sodass der Gültigkeitszeitraum Ihrer DRA-Zertifikate (höchstens) bei zwei Jahren liegt. Das kann zu einem erheblich komplizierteren Datenwiederherstellungsszenario führen. Dieses hypothetische Beispiel ist im folgenden Szenario dargestellt.

1. Ein Benutzer verschlüsselt eine Datei im Januar 2006. Die DRA-Zertifikate, die auf ihren Computer über eine Gruppenrichtlinie übertragen wurden, verfügen über einen Gültigkeitszeitraum von zwei Jahren (sie laufen im Januar 2008 ab).
2. Der Benutzer arbeitet weiterhin mit EFS zum Verschlüsseln neuer Dateien.
3. Im Januar 2008 laufen die DRA-Zertifikate ab, und der Administrator verschiebt neue Zertifikate über eine Gruppenrichtlinie auf den Computer.
4. Sämtliche Verschlüsselungsvorgänge verwenden von diesem Zeitpunkt an die neuen DRA-Zertifikate (einschließlich sämtlicher vom Benutzer geöffneter Dateien, die mit den alten DRAs verschlüsselt wurden und für die beim Speichern die neuen DRAs verwendet werden). Alle Dateien, die im weiteren Verlauf nicht vom Benutzer verwendet werden, werden jedoch weiterhin durch die alten DRAs geschützt.
5. Der Benutzer beschädigt versehentlich sein Profil, sodass eine Datenwiederherstellung erforderlich ist.
6. Der IT-Administrator muss jetzt über zwei Sätze von DRA-Zertifikaten verfügen: Den neuen für alle Dateien, die seit Schritt 3 verwendet wurden, und den alten für alle Dateien, die seit diesem Zeitpunkt nicht angetastet wurden.

Auch wenn der IT-Administrator nach Schritt 3 ein Skript ausführen kann, um alle Dateien mit dem neuen DRA zu aktualisieren (mithilfe von cipher.exe /u), kann dies ein zeitaufwändiger Prozess sein. Darüber hinaus sind die DRA-Schlüsselpaare nach ihrem Ablaufdatum weiterhin nützlich, auch wenn die EFS-Komponente keine neuen Verschlüsselungsvorgänge erlaubt, wenn ein abgelaufenes DRA-Zertifikat in der entsprechenden Wiederherstellungsrichtlinie enthalten ist. Alte Dateien, die mit abgelaufenen DRA-Schlüsselpaaren verschlüsselt wurden, können natürlich weiterhin über diese wiederhergestellt werden. Daher sollten DRA-Schlüsselpaare nie verworfen werden, auch wenn deren Gültigkeitszeitraum überschritten wurde. Sie wissen schließlich nie genau, wann Sie diese wieder verwenden müssen.

Aus diesem Grund empfiehlt sich für Umgebungen, die Zertifizierungsstellen mit einer kurzen Gültigkeitsdauer für Zertifikate umfassen, die Bereitstellung von selbstsignierten DRA-Zertifikaten mit einer längeren Gültigkeitsdauer. Das Verschlüsselungsdienstprogramm umfasst einen Schalter (cipher.exe /r), der automatisch Schlüsselpaare für den EFS-Wiederherstellungs-Agent erstellt, die über eine Gültigkeitsdauer von 100 Jahren verfügen (siehe Abbildung 4). Das Zertifikat dieses Schlüsselpaars kann dann an Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) angehängt werden und als DRA in Ihrer gesamten Organisation verwendet werden. Da die EFS-Komponente keine Prüfung der Vertrauenskette von DRA-Zertifikaten vornimmt, funktionieren diese selbstsignierten Zertifikate, ohne dass auf Ihren Systemen Änderungen an der Liste der vertrauenswürdigen Stammzertifizierungsstellen vorgenommen werden müssen. Unabhängig von der Gültigkeitsdauer der Zertifizierungsstelle einer Organisation, empfiehlt sich die Erstellung von mindestens einem DRA-Zertifikat mit langer Gültigkeit, das an ein domänenweites Gruppenrichtlinienobjekt angehängt werden sollte. Dabei sollte die Option zur Fallbackdatenwiederherstellung verwendet werden, für den Fall, dass alle anderen Optionen fehlschlagen. Das ist insbesondere dann von Bedeutung, wenn Sie DRA-Schlüssel verwenden, die von einer Zertifizierungsstelle generiert wurden, und kein Zertifizierungsschlüsselarchiv vorhanden ist. Für den Fall, dass ein DRA-Zertifikat manipuliert wird, können Sie das Gruppenrichtlinienobjekt mit einem neuen Zertifikat aktualisieren und cipher.exe /u verwenden, wie zuvor für die Aktualisierung von Dateien erläutert.

Abbildung 4** Ausführen von Cipher /R **(Klicken Sie zum Vergrößern auf das Bild)

EFS-Ressource

Auf den folgenden Websites erhalten Sie eine Vielzahl weiterer Informationen zu Einzelheiten und bewährten Methoden für EFS.

• Why you shouldn’t be using passwords of any kind on your Windows networks (in englischer Sprache)
• Implementing Key Archival Walkthrough (in englischer Sprache)
• Encrypting File System in Windows XP and Windows Server 2003 (in englischer Sprache)

KRA- und DRA-Bereitstellung

Die Schlüsselarchivierung bietet Administratoren von Zertifizierungsstellen die Möglichkeit, hinterlegte Verschlüsselungsschlüssel für den Benutzer wiederherzustellen. Dabei handelt es sich um eine äußerst sensible und leistungsstarke Funktion, da ein Zertifizierungsstellenadministrator so alle Daten in der Organisation entschlüsseln kann, für die ein Schlüssel verwendet wird, der von der Zertifizierungsstelle signiert wurde. Daher sollte die Schlüsselarchivierung und -wiederherstellung sehr sorgfältig behandelt werden, und nur einer geringen Anzahl an vertrauenswürdigen Sicherheitsmitarbeitern sollte eine Berechtigung dazu erteilt werden. Da die Schlüsselwiederherstellung ein sensibler Vorgang ist, ist eine eindeutige Definition eines Eskalationsprozesses für Wiederherstellungsanforderungen, die an Ihr Zertifizierungsstellenverwaltungsteam zu senden sind, unabdingbar, wenn Sie sich auf die Schlüsselwiederherstellung als primären Mechanismus verlassen möchten, um erneut Zugriff auf EFS-verschlüsselte Daten zu erlangen. Erst nach einer sorgfältigen Prüfung der Anforderung sollte der Wiederherstellungsprozess initiiert werden. Sobald die eigentliche Schlüsselwiederherstellung erfolgt ist, sollte der Schlüssel dem Benutzer über eine sichere Methode (also nicht über E-Mail) bereitgestellt werden, da der wiederhergestellte Schlüssel Zugriff auf sämtliche EFS-geschützte Daten des Benutzers ermöglicht.

Die Schlüssel des Schlüsselwiederherstellungs-Agent (Key Recovery Agent, KRA) werden von Zertifizierungsstellenadministratoren generiert und von diesen aufbewahrt und nicht über eine Gruppenrichtlinie bekannt gegeben. EFS selbst kann nicht feststellen, ob ein von ihm verwendeter Schlüssel archiviert wurde oder nicht. Es führt lediglich wie üblich die Verschlüsselungsvorgänge aus. Darüber hinaus sind die auf der Zertifizierungsstelle erstellten KRA-Schlüssel in keiner Weise für EFS spezifisch. Eine Zertifizierungsstelle, die eine Schlüsselarchivierung verwendet, verfügt über eine Anzahl von n KRA-Schlüsseln. Diese werden an die Zertifizierungsstelle auf der Zertifizierungsstellenebene angehängt, die zum Schutz aller von der Zertifizierungsstelle archivierten Schlüssel verwendet wird. Zu diesen Schlüsseln können die Schlüssel gehören, die mit EFS, sicherer E-Mail oder allen anderen Zertifizierungszwecken verwendet werden, bei denen eine Verschlüsselung vorgenommen wird. KRA-Schlüssel sollten sicher von den jeweiligen Schlüsselwiederherstellungs-Agents gespeichert werden, und es sollten mindestens zwei KRAs eingesetzt werden, um ein Fallback bereitzustellen, falls einer der Schlüssel verloren geht.

Wenn sich der Administrator zum ersten Mal in einer neu erstellten Domäne beim Domänencontroller anmeldet, wird auf Domänenebene eine standardmäßige Wiederherstellungsrichtlinie erstellt, wobei ein selbstsigniertes Zertifikat und Schlüsselpaar verwendet werden, die im Profil des Administrators auf dem DC gespeichert werden. Für dieses DRA-Zertifikat besteht eine Gültigkeitsdauer von drei Jahren. Es empfiehlt sich, dieses Standardzertifikat zu entfernen und durch selbstsignierte Zertifikate mit einer längeren Gültigkeitsdauer oder durch Zertifikate, die von Ihrer PKI ausgegeben wurden, zu ersetzen. Wenn Sie dieses selbstsignierte Standardzertifikat nicht entfernen, wird drei Jahre nach dessen Erstellung die Verschlüsselung neuer Dateien in Ihrer gesamten Domäne durch EFS gestoppt. Das liegt daran, dass das Zertifikat abgelaufen ist und EFS die Verschlüsselung von allen weiteren Daten verhindert, wenn ein abgelaufenes DRA-Zertifikat in der entsprechenden Wiederherstellungsrichtlinie enthalten ist. Auch wenn Windows XP und neuere Systeme ohne Richtlinie für Wiederherstellungs-Agents betrieben werden können, wird davon stark abgeraten. Wenn ein Benutzer aus irgendeinem Grund den Zugriff auf seinen Verschlüsselungsschlüssel verliert und keine Schlüsselwiederherstellung möglich ist, sind die Daten unwiderruflich verloren.

Wie bereits erwähnt, können DRA-Schlüssel entweder selbstsigniert sein oder von einer Zertifizierungsstelle ausgegeben werden. In den meisten Fällen stellt ein kombinierter Ansatz die optimale Methode dar, bei dem als letztes Mittel mindestens zwei selbstsignierte DRAs mit langer Gültigkeitsdauer unternehmensweit zur Verfügung stehen. Da DRA-Zertifikate über Gruppenrichtlinienobjekte bereitgestellt werden, verfügen sie über dieselben Vererbungsfunktionen wie andere GPOs. Mit anderen Worten, das standardmäßige Gebietsschema, die Site, die Domäne, die GPO-Ansammlung der Organisationseinheit (Organizational Unit, OU) und der Anwendungsalgorithmus, der die Anwendung von anderen GPO-Einstellungen steuert, gilt ebenfalls für DRAs. Daher kann eine Organisation einfach einen Stufenansatz für DRAs implementieren, bei dem die zentrale IT-Gruppe in allen Teilen des Unternehmens über einen DRA-Zugriff verfügt, die lokale IT-Gruppe jedoch darüber hinaus weiterhin ihre bestimmten Verantwortungsbereiche beibehält. Das stellt insbesondere in großen, geografisch verstreuten Organisationen eine wertvolle Hilfestellung dar, da so der Bedarf an der Übertragung großer verschlüsselter Datenmengen über WAN-Verbindungen reduziert wird, um die Datenwiederherstellung zu vereinfachen. In Abbildung 5 ist eine typische DRA-Bereitstellung in mehreren Stufen dargestellt.

Abbildung 5** Mehrstufige DRA-Bereitstellung **

In diesem Falle wäre das Ergebnis für einen Benutzer in der Baton Rouge-OU sechs DRAs für jede verschlüsselte Datei: Zwei von seinen lokalen Administratoren, zwei von der North America-IT-Gruppe und zwei von der Domänenebene. Wenn der Benutzer den Zugriff auf seine verschlüsselten Daten verliert, kann er daher für diese eine Wiederherstellung von einem lokalen DRA in Baton Rouge oder von der North America-IT-Gruppe veranlassen. Als letztes Fallback können auch die DRAs auf Domänenebene die Wiederherstellung der Daten übernehmen, wenn diese vier DRAs nicht oder nicht mehr verfügbar sind. Unabhängig davon, welcher DRA die Wiederherstellung durchgeführt hat, bleibt der Prozessverlauf im Wesentlichen gleich. Der Benutzer stellt die Daten zunächst dem DRA zur Verfügung. Es ist äußerst wichtig, dass der DRA die notwendigen Schritte vornimmt, um sicherzustellen, dass die Anforderung legitim ist und vom tatsächlichen Besitzer der Daten stammt. Sobald eine solche Prüfung erfolgt ist, lädt der DRA das DRA-Zertifikat, entschlüsselt die Daten (und verschlüsselt diese im Idealfall erneut) und sendet dann die Daten zurück an den Endbenutzer. Einige Organisationen entscheiden sich für eine lokale Wiederherstellung, bei der der DRA den Benutzer, bei dem das Problem besteht, vor Ort besucht, sein DRA-Schlüsselpaar in das Profil lädt, die Daten dann entschlüsselt und das Schlüsselpaar entfernt. Der Benutzer kann dann auf die Daten im Nur-Text-Format zugreifen und diese mit einem neuen Schlüssel erneut verschlüsseln. Dabei ist zu beachten, dass dieser Ansatz eine weitaus geringere Sicherheit bietet, da das DRA-Schlüsselpaar (wenn auch temporär) auf den lokalen Computer kopiert wird. Andererseits kann dieser Ansatz Zeit sparen, insbesondere dann, wenn eine große Datenmenge wiederhergestellt werden muss.

Bei der Bereitstellung einer Wiederherstellung für einen Benutzer über eine Schlüsselarchivierung und -wiederherstellung ist darauf zu achten, dass die Wiederherstellungsanforderung vollständig getrennt von diesem Prozess behandelt wird. Ohne den Einsatz eines DRA richtet sich die Wiederherstellungsanforderung des Benutzers an die Zertifizierungsstellenadministratoren, die die Anforderung überprüfen müssen und dann den privaten Schlüssel des Benutzers aus dem Archiv abrufen. Sie stellen dem Benutzer dann diesen privaten Schlüssel über eine sichere Methode zur Verfügung, z. B. durch Bereitstellen des Schlüssels zum Download auf einer sicheren Website. (Wenn der Benutzer zum Speichern seines EFS-Schlüssels eine Smartcard, die mit Windows Vista verfügbar ist, verwendet hat, sollte dieser Schlüssel ebenfalls erneut ausgegeben werden.) Der Benutzer lädt diesen Schlüssel in sein Profil und verfügt dann sofort über den Zugriff auf seine sämtlichen verschlüsselten Daten.

Da die DRA- und KRA-Schlüsselpaare zum Entschlüsseln von vertraulichen Daten verwendet werden können, ist ein ausreichender Schutz dieser Daten äußerst wichtig. DRA- und KRA-Schlüsselpaare sollten nicht in den normalen Desktopprofilen der Administratoren gespeichert werden (die Profile, in denen diese ihre normalen täglichen Aufgaben ausführen). Stattdessen sollten diese Schlüsselpaare sicher offline auf einer Diskette bzw. einem optischen oder Flash-Medium gespeichert werden, das an einem physisch sicheren Ort aufgewahrt wird. Wenn eine Wiederherstellung erforderlich ist, kann der Wiederherstellungs-Agent dann das Schlüsselpaar von diesem Medium auf eine Wiederherstellungsarbeitsstation laden, den Wiederherstellungsvorgang durchführen und das Schlüsselpaar entfernen. In einigen Organisationen, in denen eine besonders hohe Sicherheit gewährt werden muss, sind bestimmte Arbeitsstationen speziell für die Wiederherstellung vorgesehen, um die Sicherheit für diese Schlüsselpaare weiter zu erhöhen. Dies ist jedoch keine Anforderung für alle Organisationen.

Ausblick

Nachdem nun die EFS-Planung aus dem Blickwinkel der Schlüsselverwaltung und der Datenwiederherstellung sowie aus der Sicht von Active Directory untersucht wurde, werde ich mich in Teil 2 dieses Themas im nächsten Monat auf clientbasierte Bereitstellungsfragen konzentrieren. In diesem Zusammenhang werden unter anderem die folgenden Themen behandelt werden: die Steuerung der EFS-Verwendung über Gruppenrichtlinien, die Entscheidung darüber, was verschlüsselt werden sollte, die automatische Datenverschlüsselung durch Anmeldeskripts und clientbasierte Verbesserungen für Windows-Explorer, um die Arbeit mit EFS-geschützten Daten noch einfacher zu gestalten.

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.