Wird der neue Befehlszeilenparameter "/ReflectDrivers" von Windows 10 Anniversary Update für ein direktes Upgrade unterstützt?
Ja. Microsoft hat in Windows 10 Anniversary Update eine neue Funktion eingeführt, die mit einer /ReflectDrivers-Option ein direktes Betriebssystem-Upgrade über ISO und SCCM ermöglicht.
Diese Befehlszeilenoption gibt den Pfad zu einem Ordner an, der Verschlüsselungstreiber für einen Computer enthält, auf dem Drittanbieter-Verschlüsselung aktiviert ist. PnP-Treiber werden installiert, und der Upgrade-Vorgang kann fortgesetzt werden.

HINWEIS: Die Option "/ReflectDrivers" wird auch für DE 7.1.3 HotFix 1148978 (und höher) unterstützt, der Prozess wird jedoch mit DE 7.2.0 dank der im Produktinstallationsprogramm eingeführten Änderungen weiter vereinfacht.

Ausführliche Informationen zu einem direkten Windows 10-Upgrade bei installiertem Drive Encryption finden Sie in KB87909.
 

Welche Version von DE wird von Windows 10 unterstützt?
DE 7.1 Patch 3 (7.1.3) ist die erste Version, die Windows 10 unterstützt, sie wurde jedoch vor der allgemeinen Veröffentlichung von Windows 10 veröffentlicht. Daher gelten bei der Bereitstellung und Verwendung von DE 7.1.3 in Windows 10-Systemen möglicherweise Sicherheitsmaßnahmen. Weitere Informationen hierzu finden Sie in KB85784.

HINWEIS: EEPC-Versionen und DE 7.1.x-Versionen vor DE 7.1.3 unterstützen Windows 10 nicht.

Wird Windows 10 Enterprise Long-Term Servicing Branch (LTSB) für DE unterstützt?
Nein. Derzeit bietet DE lediglich Unterstützung für alle offiziellen Windows 10-Builds, einschließlich von Current Branch (CB) und Current Branch for Business (CBB).

HINWEIS: LTSB ist die Microsoft-Bezeichnung für einen Wartungs-Build, der nur Sicherheits-Patches und keine neuen Funktionen enthält.


Kann ich eine Betriebssystemaktualisierung von Windows 7 oder 8 auf Windows 10 durchführen?
Ja, mit DE 7.1.3 und späteren Versionen. Weitere Informationen zum Durchführen eines Upgrades des Betriebssystems auf Windows 10 mit installiertem DE 7.1 Patch 3 finden Sie in KB84962. Beim dokumentierten Prozess werden die erforderlichen DE-Treiber in den Microsoft-Upgrade-Prozess eingeschleust.


Kann ich das Windows 10 November Update / Threshold 2 (TH2) auf den Computer anwenden, wenn DE 7.1.3 bereits installiert ist?
Ja. Da es sich hierbei um eine umfassende Aktualisierung handelt, ist es unerlässlich, müssen Sie unbedingt die in KB84962 beschriebene Vorgehensweise befolgen.


Wird die Windows 10-Option "Zum vorherigen Build zurückkehren" mit installiertem und aktivem DE unterstützt?
Ja.

• "Windows OS Refresh Recommended Process Guide for Master Boot Record Systems Only" (Empfohlene Vorgehensweise für das Upgrade von Windows-Betriebssystemen für MBR-Systeme) in PD24854.
• "Windows OS Refresh Recommended Process Guide for UEFI Systems Only" (Empfohlene Vorgehensweise für das Upgrade von Windows-Betriebssystemen für UEFI-Systeme) in PD24855.

• Mit den Vor-Aktivierungsprüfungen wird festgestellt, dass BitLocker aktiv ist. Wie bereits erwähnt ist die Microsoft-Geräteverschlüsselung lediglich eine nicht verwaltete Version von BitLocker.
• Die DE-Aktivierung schlägt fehl, da der Datenträger bereits mit der Microsoft-Geräteverschlüsselung verschlüsselt wurde.
• Dieser Status wird an ePO zurückgemeldet.

Für welche EEPC-Versionen kann ein Upgrade auf DE 7.1 durchgeführt werden?
Die folgenden Upgrades sind möglich:

• EEPC 7
  Für Systeme mit einer Installation von EEPC 7.0.x kann ein Upgrade auf DE 7.1 durchgeführt werden. Sie müssen jedoch zuerst ein Upgrade der EEPC-Erweiterung auf EEPC 7.0 Patch 2 (7.0.2) oder Patch 3 (7.0.3) durchführen.
  Führen Sie die im Drive Encryption 7.1 Product Guide (PD24867, Produkthandbuch zu Drive Encryption 7.1) ausführlich beschriebenen Schritte aus. Korrekturen der Dokumentation finden Sie in KB79912.
• EEPC 6
  Wenn Sie mit EEPC 6.1.2 oder höher arbeiten, müssen Sie zuerst ein Upgrade aller Erweiterungen auf EEPC 7.0 Patch 2 oder Patch 3 durchführen. Für Client-Systeme, in denen EEPC 6.1.2 oder höher ausgeführt wird, kann ein direktes Upgrade auf DE 7.1 durchgeführt werden. Für ePO-Installationen mit eingecheckten EEPC 7.0 Patch 2 oder 3-Erweiterungen kann ein direktes Upgrade auf DE 7.1 durchgeführt werden. McAfee empfiehlt dringend, vor der Durchführung eines Upgrades von EEPC 6.1.x- oder 6.2.x-Clients auf DE 7.1, KB81522 durchzulesen, um weitere Einzelheiten zu erfahren.
  Führen Sie die im Drive Encryption 7.1 Product Guide (PD24867, Produkthandbuch zu Drive Encryption 7.1) ausführlich beschriebenen Schritte aus.
• EEPC 5
  Systeme, die mit EEPC 5.2.x installiert wurden, können direkt zu DE 7.1 migriert werden.
  Führen Sie die im Drive Encryption 7.1 Migration Guide (Migrationshandbuch zu Drive Encryption 7.1, PD24870) ausführlich beschriebenen Schritte aus. Korrekturen der Dokumentation finden Sie in KB79912.

Welche älteren EEPC-Versionen können zu DE 7.1 migriert werden?
Eine direkte Migration zu DE 7.1 kann für die älteren Versionen EEPC 5.2.6, 5.2.12 und 5.2.13 ausgeführt werden.


Welche Maßnahmen sind zu ergreifen, wenn bei mir EEPC 6.x ausgeführt wird?
Wenn Sie EEPC 6.1.2 oder höher verwenden, müssen Sie zunächst ein Upgrade aller Erweiterungen auf EEPC 7.0.2 oder 7.0.3 durchführen. Sie müssen kein Upgrade der EEPC 6.1.2-Clients (oder höher) durchführen, bevor Sie den DE 7.1-Upgrade-Prozess initiieren.

McAfee empfiehlt dringend, vor der Durchführung eines Upgrades von EEPC 6.1.x- oder 6.2.x-Clients auf DE 7.1, KB81522 durchzulesen, um weitere Einzelheiten zu erfahren.

Befolgen Sie die ausführliche Anleitung im Drive Encryption 7.1 Product Guide (Produkthandbuch zu Drive Encryption 7.1, PD24867). Lesen Sie aber unbedingt den entsprechenden Dokumentationskorrektur-Artikel KB79912, um sich über Aktualisierungen und Korrekturen im Inhalt des Produkthandbuchs zu informieren. Hier werden die erforderlichen Schritte zum Durchführen eines Upgrades auf DE 7.1 beschrieben. Bei diesem Prozess muss auch die EEAdmin 7.0.4-Erweiterung installiert werden.


Welche Schritte muss ich ausführen, wenn ich ein Upgrade auf die aktuelle Version von DE 7.1.x durchführen möchte, jedoch bereits eine frühere DE 7.1-Version installiert ist?
Wenn eine frühere Version installiert ist (z. B. DE 7.1.1), Sie jedoch ein Upgrade auf eine spätere Version von DE 7.1.x durchführen möchten, führen Sie die folgenden Schritte aus:

1. Vergewissern Sie sich, dass keine LDAP-Synchronisierungs-Tasks ausgeführt werden. Falls gerade solche Tasks ausgeführt werden, warten Sie, bis diese abgeschlossen sind.
2. Deaktivieren Sie alle LDAP-Synchronisierungs-Tasks, bevor Sie das Upgrade starten.
3. Installieren Sie die DE 7.1.3-Erweiterungen.
4. Checken Sie die DE 7.1.3 Agent- und PC-Software-Pakete ein.
5. Aktivieren Sie alle LDAP-Synchronisierungs-Tasks.
6. Stellen Sie die DE 7.1.3-Software-Pakete im Client-System bereit.
7. Starten Sie das System nach Abschluss des Bereitstellungs-Tasks neu.
    

Muss ich ein Upgrade der Version des McAfee Agent (MA) auf allen meinen Clients durchführen?
Dies ist nur der Fall, wenn nicht die mindestens unterstützte MA-Version installiert ist. Informationen dazu, wie Sie die von DE 7.1.x unterstützte Mindestversion von MA ermitteln, finden Sie in KB79422.

Warum ist der Upgrade-Prozess so kompliziert?
Der Grund hierfür sind Abhängigkeiten zu neu eingeführten ePO-Funktionen, die für die neuen Funktionen "LDAPSync" und "Benutzerverzeichnis" erforderlich sind.


Welche ePO-Versionen werden mindestens von DE 7.1.x unterstützt?
ePO 4.6.7 und ePO 5.1.0.


Weshalb muss ich ein Upgrade auf eine neuere ePO-Version durchführen, um DE 7.1.x ausführen zu können?
Weil dies die einzige Möglichkeit ist, die Vorteile der neuen Funktionen "LDAPSync" und "Benutzerverzeichnis" zu nutzen, die erstmalig in ePO 4.6.7 und ePO 5.1.0 implementiert wurden.


Muss ich ein Upgrade auf ePO 4.6.7 oder 5.1.x durchführen, wenn ich die Funktion "Benutzerverzeichnis" nicht verwenden möchte?
Ja. Sie müssen ein Upgrade Ihrer ePO-Version durchführen, egal, ob Sie diese Funktion nutzen möchten oder nicht.


Bedeutet die Einführung der neuen Benutzerverzeichnisstruktur, dass die Benutzerdaten aktualisiert werden müssen?
Ja. Wenn Sie über vorhandene Benutzerdaten verfügen, müssen Sie den Prozess "Benutzerdaten-Upgrade" ausführen, um ein Upgrade aller vorhandenen Benutzerdaten auf die neuen internen Strukturen durchzuführen.
Ein Video zur Funktion "Benutzerverzeichnis" finden Sie hier: https://communitym.trellix.com/videos/1700

 

Weshalb ist eine EEPC 7.0.4 EEAdmin-Erweiterung im Paket der DE 7.1-Version enthalten, und warum ist sie erforderlich?
Aufgrund der Änderungen an LDAPSync und dem Benutzerverzeichnis müssen die vorhandenen verschlüsselungsbezogenen Benutzerdaten in die neuen Strukturen migriert werden. EEPC 7.0.4 enthält einen Task "Benutzerdaten-Upgrade", der vorhandene Daten in die neuen Strukturen verschiebt.


Ist dies lediglich eine ePO-Erweiterung, oder gibt es auch Client-Upgrades?
Dies ist lediglich eine ePO-Erweiterung. Für EEPC 7.0.4 sind keinerlei Client-Aktualisierungen erforderlich.

 

Ist diese EEPC 7.0.4-Erweiterung abwärtskompatibel, sodass Clients verwaltet werden können, die mit früheren EEPC-Client-Versionen ausgeführt werden?
Ja, Verwaltung und Berichterstellung für vorhandene EEPC 7.0.x- oder 6.x-Clients (EEPC 6.1.2 oder höher) sind immer noch möglich, wenn die 7.0.4 ePO-Erweiterung installiert ist. Ein solches Szenario sollte jedoch nur vorliegen, wenn der Task "Benutzerdaten-Upgrade" – gleich aus welchen Gründen – fehlgeschlagen ist, sodass der Abschluss des Upgrades auf ePO 4.6.7 oder 5.1 verhindert wurde.
 

 

Welche ePO-Versionen werden von dieser EEPC 7.0.4 EEAdmin-Erweiterung unterstützt?
Die ePO-Versionen von 4.6.4 bis 4.6.7 sowie ePO 5.0.1 bis 5.1. Die Hauptfunktionen und -Tasks der EEPC 7.0.4 EEAdmin-Erweiterung funktionieren jedoch nur unter ePO 4.6.7 und ePO 5.1.x.

 

Wie lange sollte ich die EEPC 7.0.4-Erweiterung verwenden?
Der Zeitraum sollte so kurz wie möglich sein. Sie verwenden die EEPC 7.0.4-Erweiterung nur so lange, bis der Task "Benutzerdaten-Upgrade" ausgeführt wurde. Nach Abschluss des Tasks sollten Sie sofort ein Upgrade auf DE 7.1 durchführen.


Was geschieht, wenn ich versuche, sofort zu DE 7.1 zu wechseln, ohne zuvor die EEPC 7.0.4 EEAdmin-Erweiterung einzuchecken?
Erstens schlägt die Installation der DE 7.1-Erweiterung fehl, da sie unter Ihrer ePO-Version nicht ausgeführt wird. Zweitens können Sie ePO nicht auf die Mindestversion aktualisieren, da keine Unterstützung durch die vorhandenen ePO-Erweiterungen für Verschlüsselung vorliegt. Drittens können Sie kein Upgrade durchführen, da festgestellt wird, dass der Task "Benutzerdaten-Upgrade" nicht erfolgreich ausgeführt wurde. Die EEPC 7.0.4 EEAdmin-Erweiterung ist beim Durchführen eines Upgrades auf DE 7.1 ein obligatorischer Schritt.


Was ist das Benutzerdaten-Upgrade?
Das Benutzerdaten-Upgrade ist ein Server-Prozess, bei dem alle vorhandenen Benutzerinformationen für die Verschlüsselung in die neuen internen Benutzerverzeichnis- und LDAPSync-Strukturen migriert werden.


Warum muss dieser Task ausgeführt werden?
Die vorhandenen Benutzerdaten müssen auf die neuen Datenstrukturen aktualisiert werden, die von den Erweiterungen "Benutzerverzeichnis" und "LDAPSync" verwendet werden. Dies ist ein einmaliger Prozess, der vor dem Durchführen des Upgrades auf DE 7.1 durchgeführt werden muss.
 

 

In welchen ePO-Versionen kann ich den Task "Benutzerdaten-Upgrade" ausführen?
Der Task kann nur in ePO 4.6.7 und ePO v5.1.x ausgeführt werden. Die EEPC 7.0.4-Erweiterung kann zwar für frühere Versionen von ePO installiert werden, Sie können diesen Task jedoch erst ausführen, wenn Sie ein Upgrade des ePO-Servers auf ePO 4.6.7 oder ePO 5.1.x durchgeführt haben.


Kann ich den Task "Benutzerdaten-Upgrade" nur mit eingecheckter EEPC 7.0.4 EEAdmin-Erweiterung ausführen, oder kann ich den Task in einer früheren Version von EEPC ausführen?
Nein. Die Funktionalität ist nur in der 7.0.4 EEAdmin-Erweiterung verfügbar, und der Task kann nur in ePO 4.6.7 oder 5.1 ausgeführt werden.


Ist dies ausschließlich ein ePO-Task, oder muss ich weitere Vorgänge auf den Clients ausführen?
Dies ist ein reiner ePO-Task. Durch den Task wird Software ausgeführt, die einfach Daten in die internen SQL-Server-Strukturen verschiebt. Die Daten werden in die neuen Strukturen verschoben und vor Abschluss des Vorgangs auf Genauigkeit und Vollständigkeit überprüft.
 

 

Muss ich zum Ausführen des Tasks den ePO-Server herunterfahren?
Nein, er kann auf einem aktiven ePO-Server ausgeführt werden.


Wie lange dauert die Ausführung des Tasks "Benutzerdaten-Upgrade"?
Dies hängt davon ab, wie viele Benutzerinformationen in der Datenbank vorhanden sind. Eine grob geschätzte Angabe:

• 2.000 Benutzer dauern etwa fünf Minuten.
• 10.000 Benutzer dauern etwa acht Minuten.

HINWEIS: Die Leistung variiert in Abhängigkeit von der Spezifikation des SQL-Servers und seiner aktuellen Arbeitslast. Diese Werte wurden anhand eines Testsystems mit einem i5-Prozessor mit 4 GB RAM gewonnen. Andere Aspekte, die sich auf die Dauer des Vorgangs auswirken können, sind andere Elemente von Benutzer-Token-Daten wie SSO (Single Sign On)-Daten und Daten mit Selbstwiederherstellung.


Wie kann ich feststellen, ob beim Benutzerdaten-Upgrade ein Fehler aufgetreten ist?
Im ePO Server-Task-Protokoll wird der Fehlerstatus für die Ausführung des Upgrade-Tasks angezeigt. Zudem wird der Audit-Protokolleintrag mit Fehlerstatus für denselben Task angezeigt. Die EEPC 7.0.4 EEAdmin-Erweiterung kann nicht zurückgesetzt werden, vorhandene EEPC-Client-Systeme können jedoch mit installierter EEPC 7.0.4 EEAdmin-Erweiterung verwaltet werden.


Kann ich "Benutzerdaten-Upgrade" erneut ausführen, wenn der Task fehlschlägt?
Ja. Wenn der Task fehlschlägt, wird automatisch ein Rollback der Daten ausgeführt, und alle benutzerbezogenen Funktionen werden automatisch erneut aktiviert. Der Task kann so oft wie nötig ausgeführt werden, bis er erfolgreich abgeschlossen wurde.


Kann ich benutzerbezogene Verschlüsselungsaktionen ausführen, während der Task "Benutzerdaten-Upgrade" ausgeführt wird?
Nein. Während der Task "Benutzerdaten-Upgrade" ausgeführt wird, sind alle benutzerbezogenen Aktionen in ePO deaktiviert.


Wann werden die benutzerbezogenen Aktionen wieder aktiviert?
Sie werden erst wieder aktiviert, wenn der Task "Benutzerdaten-Upgrade" erfolgreich abgeschlossen wurde und ein Upgrade der ePO-Erweiterungen auf DE 7.1 durchgeführt wurde. Schlägt der Task fehl und erfolgt ein Rollback der Datenvorgänge, werden auch die benutzerbezogenen Aktionen wieder aktiviert.


Werden weitere Funktionen in ePO deaktiviert, während der Task "Benutzerdaten-Upgrade" ausgeführt wird?
Es gilt Folgendes:

• Durch "Benutzer der lokalen Domäne hinzufügen" werden keine neuen Benutzer verarbeitet.
• Es werden keine benutzerbezogenen Aufgaben (d. h. bezüglich neuer Kennwörter oder anderer Benutzer-Token-Informationen) ausgeführt.
• Benutzerbezogene Web-APIs sind ebenfalls deaktiviert.

Folgendes ist jedoch weiterhin verfügbar:

• Exportieren von Computer-Schlüsseln
• Abfrage/Rückmeldung (nur Computer)
• Alle nicht benutzerbezogenen Wiederherstellungsfunktionen (AMT oder Nicht-AMT)
   

Werden während des Tasks "Benutzerdaten-Upgrade" Änderungen am Client vorgenommen?
Auf dem Client findet Folgendes statt:

• Die vorhandene empfangene Richtlinie auf dem Client wird weiterhin erzwungen.
• Neue Richtlinien gehen während der Ausführung des Tasks "Benutzerdaten-Upgrade" auf dem Client ein, sie werden jedoch nicht erzwungen.
• Neu erfasste Kennwörter oder sonstige Token-Daten können nicht an ePO gesendet und an andere Systeme weitergegeben werden, während der Upgrade-Task ausgeführt wird.

HINWEIS: Im Fall einer Wiederherstellung ist eine Computer-Wiederherstellung wie auch eine Selbstwiederherstellung immer noch verfügbar, Abfrage/Rückmeldung zum Zurücksetzen eines Kennworts ist hingegen nicht verfügbar.


Was geschieht, wenn ich während dieser Zeit eine der oben angegebenen Aktionen auf dem Client oder in ePO ausführe?
Alle diese Client-Aktionen schlagen ordnungsgemäß fehl, oder sie sind in der ePO-Benutzeroberfläche deaktiviert/blockiert.


Ich richte einen neuen ePO-Server ein und möchte DE-Clients dorthin verschieben. Wird dies unterstützt?
Ja. Dies wird in DE 7.1.3 unterstützt.

Bei jeder Version von EEPC oder früheren Versionen von DE werden beim Übertragen eines Systems von einem ePO-Server auf einen anderen die Benutzerzuweisungen und Benutzer-Token-Daten im System durch die Daten vom Ziel-Server ersetzt, wobei potenziell Benutzerzuweisungen verloren gehen und Benutzeranmeldeinformationen in der Pre-Boot-Umgebung geändert werden.

In Drive Encryption 7.1.3 wird eine neue Client-Übertragungsfunktion eingeführt, mit welcher ePO-Administratoren über einen Mechanismus verfügen, mit dem Systeme von einem ePO-Server auf einen anderen übertragen werden können und gleichzeitig Benutzerzuweisungen und Benutzerdaten erhalten bleiben. Wenn die Funktion aktiviert ist, erkennt ein DE 7.1.3-System einen Server-Wechsel und fordert, dass der neue DE 7.1.3-Verwaltungs-Server Benutzer dem System automatisch im Kontext des Verwaltungs-Servers zuweist. Bei erfolgreicher Zuweisung sendet das System seine Benutzer-Token-Daten an den neuen Verwaltungs-Server. Alle Systeme, deren Systemübertragung fehlgeschlagen ist, werden auf dem Ziel-Server in einem intuitiven vordefinierten Bericht hervorgehoben.

In dieser Version ist ein spezielles DE 7.1.3-Client-Systemübertragungshandbuch enthalten, in dem dieser Systemübertragungsprozess ausführlich beschrieben wird. Ausführliche Informationen hierzu finden Sie in PD25905.

Zurück zum Inhalt

• Über die DE-Richtlinie können Sie die Verwendung des Standardkennworts untersagen. Dadurch wird der Benutzer gezwungen, ein selbst gewähltes Kennwort einzugeben.
• Verwenden Sie eine Richtlinienzuweisungsregel mit einer anderen benutzerbasierten Richtlinie (UBP), in der Sie ein anderes Standardkennwort für die Benutzer definieren, denen die UBP zugewiesen ist.

Kann ich DE in einem System installieren und ein RAW- Image (Sektor für Sektor) aufzeichnen, das für neue Computer verwendet wird?
Nein. Diese Vorgehensweise wird nicht unterstützt. Dadurch würde ein Sicherheitsproblem entstehen, da jedes System den gleichen Sicherheitsschlüssel aufweisen würde.

Zurück zum Inhalt

Antworten auf häufig gestellte Fragen zu neuen Funktionen, die sich ausschließlich auf DE 7.2.0 beziehen

Wie nutzt DE 7.2.0 Intel Software Guard Extensions (SGX)?
Intel SGX ist eine Erweiterung der Intel-Architektur, die mit Intel Core-Prozessoren der 6. Generation eingeführt wurde. Diese soll die Sicherheit der Software über einen umgekehrten Sandbox-Mechanismus erhöhen. Bei diesem Ansatz wird nicht versucht, alle potenziellen Bedrohungen und Angriffsflächen der Plattform zu ermitteln und zu isolieren; stattdessen kann zulässige Software in einer Enklave versiegelt und vor derartigen Bedrohungen geschützt werden, wobei die Berechtigungsstufe der jeweiligen Bedrohung irrelevant ist.

Die Verwendung von Intel SGX mit Drive Encryption erhöht darüber hinaus den Schutz vor speicherbasierten Angriffen (z. B. Kaltstart-Angriffen), ohne dass die Leistung von Systemen beeinträchtigt wird, die SGX unterstützen und in denen eine dementsprechende Richtlinie angewendet ist.

Wie aktiviere ich SGX für DE 7.2.0?
Um sicherzustellen, dass DE SGX (sofern verfügbar) verwendet, muss die Unterstützung von SGX aktiviert werden, bevor DE 7.2.0 in einem Zielsystem bereitgestellt wird.
Weitere Informationen zu technologischen Anforderungen für diese neue Funktion finden Sie in KB87256.
 

Antworten auf häufig gestellte Fragen zu neuen Funktionen, die sich ausschließlich auf DE 7.1 und höher beziehen

Wird DE auf Computern unterstützt, wenn der BIOS für die Verwendung von RAID konfiguriert ist?
Im Allgemeinen funktioniert DE im RAID-Modus, sofern das BIOS des betreffenden Computers den Datenträger erkennt.
HINWEISE:

• Im älteren bzw. MBR-BIOS-Modus stützt sich DE auf Int13-Aufrufe, um auf die Festplatte des Computers zuzugreifen.
• Im UEFI-Modus (Unified Extensible Firmware Interface) stützt sich DE auf das E/A-Protokoll des Systems, daher erkennt DE den BIOS SATA-Modus. Hierbei gilt als einzige Einschränkung: Wenn es sich beim Datenträger um ein OPAL-Laufwerk, ein selbstverschlüsselndes Laufwerk oder eine Festplatte handelt, muss für DE der AHCI (Advanced Host Controller Interface)-Modus festgelegt werden, da DE über einen eigenen Controller-Treiber verfügt und sich beim Festplattenzugriff nicht auf das BIOS stützt. 
  HINWEIS: Die Einschränkung gilt nur für Hardware-Verschlüsselung eines OPAL- oder SED-Laufwerks und nicht, wenn die OPAL-Festplatte für Software-Verschlüsselung konfiguriert ist.

Ist es möglich, einen über einen USB-Anschluss angeschlossenen Wechseldatenträger zu verschlüsseln?
Nein. DE erkennt und verschlüsselt das Laufwerk nur, wenn es am SATA-Anschluss erkannt wird.


Was ist das Benutzerverzeichnis?
Damit wird Ihr ePO-verwaltetes DE auf Systeme mit nicht verwalteten Benutzern außerhalb der Domäne ausgeweitet. Neben in Active Directory verwalteten Benutzern kann DE nun auch diese ePO-verwalteten Benutzer für die Pre-Boot-Authentifizierung verwenden.

Benutzerdaten werden nun aus Active Directory synchronisiert und lokal in ePO zwischengespeichert. Dadurch müssen nicht mehr laufend Roundtrips von ePO zu Active Directory ausgeführt werden, und dies bringt erhebliche Leistungsverbesserungen bei benutzerbasierten Richtlinienprüfungen mit sich.


Wird durch dieses Benutzerverzeichnis die Abhängigkeit von Active Directory aufgehoben?
Ja.


Muss ich als Administrator bestimmte Aktionen ausführen, um das Benutzerverzeichnis zu aktivieren?
Ja. Sie müssen die Erweiterung "Benutzerverzeichnis" installieren. Sie können dies vor oder nach dem Durchführen des Upgrades auf DE 7.1.x durchführen, solange die ePO-Voraussetzungen (ePO 4.6.7 oder ePO 5.1.0) erfüllt sind.


Ist DE das einzige Produkt, welches das Benutzerverzeichnis verwendet, oder kann es auch von anderen McAfee-Produkten verwendet werden?
Derzeit wird es nur von DE verwendet, künftig ist jedoch auch die Verwendung durch andere McAfee-Einzelprodukte möglich.


Wo finde ich weitere Informationen zum Benutzerverzeichnis?
Schauen Sie sich das in der Community veröffentlichte Video an: https://communitym.trellix.com/videos/1700

Besteht ein konzeptioneller Unterschied zwischen den eigenständigen Benutzern in EEPC 5.x und den Benutzern im Benutzerverzeichnis?
Nein, es gibt keinen konzeptionellen Unterschied.


Kann ich eigenständige EEPC 5.x-Benutzer in das Benutzerverzeichnis migrieren?
Ja.

 

Kann ich im Benutzerverzeichnis Benutzer erstellen?
Ja.


Kann ich im Benutzerverzeichnis Benutzer löschen, deaktivieren oder bearbeiten?
Ja.


Kann ich Benutzer nach dem Deaktivieren wieder aktivieren?
Ja.


Kann ich einem Benutzer ein Zertifikat zuweisen?
Nein.


Weshalb empfiehlt es sich, einem Benutzer ein Zertifikat zuzuweisen?
Ein Beispiel ist die Verwendung einer PKI-basierten Smartcard.


Kann ich Organisationseinheiten im Benutzerverzeichnis erstellen?
Ja.


Kann ich Benutzer einer Organisationseinheit hinzufügen oder Benutzer aus einer Organisationseinheit entfernen?
Ja.


Kann ein Benutzer mehreren Organisationseinheiten angehören?
Nein.


Kann ich einen Benutzer aus einer Organisationseinheit in eine andere Organisationseinheit verschieben?
Ja.


Können Organisationseinheiten geschachtelt werden?
Ja.


Wenn ich eine Organisationseinheit auswähle, werden alle Benutzer der betreffenden Organisationseinheit angezeigt (auch die aus geschachtelten Organisationseinheiten)?
Es werden alle Benutzer aus untergeordneten Organisationseinheiten, jedoch nicht alle geschachtelten Organisationseinheiten angezeigt. Anhand des eindeutigen Namens können Sie feststellen, aus welcher untergeordneten Organisationseinheit der jeweilige Benutzer stammt.


Kann ich in Bezug auf ePO-Berechtigungen eine Einschränkung für die Aktionen festlegen, die einzelne Administratoren im Benutzerverzeichnis ausführen können?
In ePO sind Berechtigungen in Berechtigungssätze zusammengefasst. Benutzer sind den einzelnen Berechtigungssätzen zugewiesen. Wenn Administratoren unterschiedlichen Berechtigungssätzen zugewiesen sind, können sie über unterschiedliche Berechtigungen verfügen.


Auf welcher Stufe von ePO-Berechtigungen kann ich das Benutzerverzeichnis angeben?
Das Benutzerverzeichnis unterstützt Lese-/Schreibberechtigungen und reine Leseberechtigungen. Es ist nicht möglich, den Zugriff auf bestimmte Aktionen zu beschränken. Sie können lediglich reinen Lesezugriff gewähren oder sämtliche Berechtigungen entziehen.


Werden die Benutzer in Bezug auf die DE-Verwendung in EEPC 7.0 und in DE 7.1 auf die gleiche Weise verwaltet?
Ja, der Workflow ist identisch. Es gibt es keinerlei Änderungen in Bezug auf den Workflow.


Wird beim Verwalten von Benutzern eine vollständige Liste der Benutzer angezeigt, ungeachtet dessen, ob diese aus Active Directory oder dem Benutzerverzeichnis stammen?
Ja.


Wenn ich eine Verschlüsselungsaktion für einen Benutzer ausführe, spielt es dabei eine Rolle, ob der Benutzer aus Active Directory oder dem Benutzerverzeichnis stammt?
Nein. Der Workflow ist in beiden Fällen gleich.


Kann ich Benutzer und/oder Organisationseinheiten aus dem Benutzerverzeichnis einem Computer für die Pre-Boot-Authentifizierung zuweisen?
Ja.


Was geschieht, wenn ein Benutzer im Benutzerverzeichnis deaktiviert wird?
Dabei geschieht dasselbe wie beim Deaktivieren eines Benutzers in Active Directory.


Was geschieht, wenn ein Benutzer aus dem Benutzerverzeichnis gelöscht wird?
Dabei geschieht das gleiche wie beim Löschen des Benutzers aus Active Directory.
 

 

Ändert sich die ePO-WebAPI für "User: Machine assignments" (Benutzer: Computer-Zuweisungen) bei der Skripterstellung?
Nein.


Können die Aktionen im Benutzerverzeichnis durch Skripts gesteuert werden?
Ja.


Was ist TPM-AutoBoot (Trusted Platform Module AutoBoot)?
TPM-AutoBoot ist eine neue Option in DE 7.1, welche bei vorhandener Hardware die herkömmliche AutoBoot-Funktion durch ein TPM stärkt. Das Ziel besteht im Schützen des Schlüssels.


Wodurch unterscheidet sich TPM-AutoBoot von der herkömmlichen AutoBoot-Funktion?
Die herkömmliche AutoBoot-Funktion bietet keine Sicherheit für das System. Der Schlüssel zum Verschlüsseln des Datenträgers wird in Klartext auf den Datenträger geschrieben. Mit TPM-AutoBoot wird der Schlüssel gesichert, indem er mit dem TPM verschlüsselt wird; er liegt nicht mehr in Klartext vor.


Wie trägt das TPM zum Sichern des Schlüssels bei?
Der Schlüssel kann nur dann vom TPM entschlüsselt werden, wenn sich der Systemstatus nicht geändert hat. Wenn sich der Systemstatus laut Ansicht des TPM geändert hat oder wenn ein neuer TPM-Chip vorhanden ist (z. B. bei einer neuen Hauptplatine), wird der Schlüssel nicht entschlüsselt. Wenn der Schlüssel nicht entschlüsselt werden kann, schlägt die AutoBoot-Funktion fehl, und die Pre-Boot-Authentifizierung wird angezeigt.


Wird mein System mit TPM-AutoBoot weiterhin automatisch gestartet?
Ja, jedoch nur, wenn laut Ansicht des TPM keine Fehler vorliegen. In dieser Situation wird die Pre-Boot-Umgebung für den Benutzer nicht angezeigt, und Windows wird einfach gestartet.


Gibt es Mindestanforderungen für TPM-AutoBoot?
Ja. Es gelten die folgenden Mindestanforderungen:

• DE 7.1 unterstützt TPM-AutoBoot nur in TPM 2.0-Systemen (alle Systeme mit verbundenem Standby-Modus unterstützen TPM 2.0). HINWEIS: Die Funktion wird von älteren Systemen mit TPM 1.2 nicht unterstützt.
• DE 7.1 Patch 1 (7.1.1) bietet Unterstützung für TPM 1.2-Chipsätze (nur UEFI-Systeme).
• Der TPM-Besitzer-Schlüssel muss lokal und nicht in Active Directory verwaltet werden.
• Das System muss das TPM-UEFI-Protokoll in der UEFI-Implementierung des OEM enthalten (eine Anforderung für Systeme mit verbundenem Standby-Modus).
   

Welche Richtlinieneinstellungen gelten für TPM-AutoBoot?
Die Richtlinienoptionen finden sich unter dem Titel "Verwendung des TPM für den automatischen Boot"; hier sind die folgenden drei Optionen vorhanden:

• Nie: Der Datenträgerschlüssel wird in Klartext auf den Datenträger geschrieben. Dies ist die AutoBoot-Originalfunktion.
• Falls verfügbar: Wenn das System ein verwendbares TPM aufweist, wird der Schlüssel mithilfe des TPM verschlüsselt. Ist kein TPM verfügbar oder kann es nicht verwendet werden, lässt das im System vorhandene TPM gemäß der AutoBoot-Originalfunktion den Schlüssel in Klartext auf den Datenträger schreiben.
• Erforderlich: AutoBoot funktioniert nur, wenn das System über ein verwendbares TPM verfügt. In Systemen ohne TPM wird die DE-Pre-Boot-Umgebung angezeigt.
   

Kann TPM-AutoBoot in Verbindung mit reaktivem AutoBoot verwendet werden?
Ja.


Können TPM-AutoBoot und reaktives AutoBoot in Verbindung mit dem neu unterstützten verbundenen Standby-Modus und Funktionen zum Härten von Systemen gegen Kaltstart-Angriffe verwendet werden?
Ja.


Was geschieht, wenn das TPM den Schlüssel nicht entschlüsseln kann?
Die Pre-Boot-Umgebung wird angezeigt, und der Benutzer wird aufgefordert, sich zu authentifizieren. Sollte das TPM im Zweifel sein, wird das System nicht automatisch gestartet; stattdessen zeigt es die Pre-Boot-Umgebung an und wartet auf die Authentifizierung.


Wenn ich die Hauptplatine austausche, oder sich die Boot-Messwerte ändern, wird der Pre-Boot-Authentifizierungsbildschirm für den Benutzer angezeigt. Wie muss der Benutzer nun vorgehen?
In dieser Situation muss der Benutzer eine Abfrage-/Rückmeldungswiederherstellung ausführen, um Zugriff auf Windows zu erlangen.
Wenn gültige Pre-Boot-Benutzeranmeldeinformationen bekannt sind, kann sich der Benutzer einfach authentifizieren und Windows starten. Da sich der Benutzer jedoch in diesem AutoBoot-Modus befand, ist es wenig wahrscheinlich, dass ihm gültige Benutzeranmeldeinformationen bekannt sind.


Wenn sich ein Benutzer in Windows befindet, muss er bestimmte Aktionen ausführen?
Nein. Benutzer, Supportmitarbeiter und Administratoren müssen keine Aktionen ausführen. Das Produkt verschlüsselt den Schlüssel mithilfe der neuen Informationen automatisch neu, und ab diesem Punkt ist ein normales Startverhalten zu beobachten.


Führen Sie über die Aufforderung an das TPM zum Verschlüsseln des Schlüssels hinaus weitere Vorgänge aus?
Ja. Wir messen auch den Startpfad. Bei jedem Start des Systems erfassen wir einen entsprechenden Daten-Hash im TPM. Das heißt, dass das TPM den Schlüssel nur entschlüsselt, wenn der Startpfad nicht geändert wurde.

Sobald der Datenträger durch TPM-AutoBoot entsperrt wird, ist es also nicht mehr möglich, unter einem anderen Startpfad zu starten. Wird eine andere Startoption beim Systemstart ausgewählt, schlägt die AutoBoot-Funktion fehl, und die Pre-Boot-Umgebung wird angezeigt.


Wie funktioniert TPM-AutoBoot?
Das TPM bietet einen Versiegelungsmechanismus, durch den Daten nur entschlüsselt werden können, wenn sich das System in einem vordefinierten Zustand befindet. Während des Systemstarts werden die Firmware sowie alle Startkomponenten vom TPM gemessen. Bei der Messung wird ein in einem TPM-Register gespeicherter Hash mit dem auszuführenden Code erweitert. Messungen werden durch Firmware ausgeführt, und sie können nicht umgangen werden. Effektiv lässt das TPM den Entschlüsselung des Schlüssels nur zu, wenn sich das System in genau demselben Zustand befindet wie zum Zeitpunkt der Versiegelung. Jede Änderung, egal wie geringfügig, bewirkt das Fehlschlagen der Entschlüsselung.


Was geschieht, wenn Microsoft den Windows BootLoader während einer Windows-Aktualisierung aktualisiert?
Das heißt, dass sich die Boot-Messungen geändert haben. Demzufolge kann das TPM den Schlüssel nicht entschlüsseln, und Sie müssen einen Wiederherstellungsprozess (Anruf beim Helpdesk) durchlaufen, um das System erfolgreich starten zu können.


Da sich die DE-Pre-Boot-Umgebung ebenfalls im Startpfad befindet, was geschieht, wenn ich ihn aktualisiere?
Wenn ein Administrator eine neue DE-Version (HotFix, Patch oder neue Version) implementiert und dabei die DE-Pre-Boot-EFI-Anwendung aktualisiert wird, ändern sich auch die Boot-Messungen.


Müssen Benutzer wie beim Windows-Aktualisierungs-Szenario beim Helpdesk anrufen, um nach der Push-Bereitstellung einer Aktualisierung durch DE wieder auf das System zugreifen zu können?
Ja.


Kann ich die neue Smartphone-Funktion (Endpoint Assistant) verwenden, um dieses Problem zu beheben, ohne beim Helpdesk anzurufen?
Nein. Endpoint Assistant kann nur für Anwendungsfälle mit Zurücksetzen von Kennwörtern verwendet werden.


Kann ich nun in der Pre-Boot-Umgebung eine größere Anzahl von Benutzern verwalten?
Die Pre-Boot-Umgebung wurde verbessert und unterstützt nun mehr als 5.000 Benutzer ohne spürbare Leistungseinbußen während der Pre-Boot-Authentifizierung. Früher galt eine Beschränkung auf maximal 250 Benutzer während des Pre-Boot-Vorgangs. Sie können nun auf sichere Weise für alle Benutzer die gemeinsame Nutzung von Desktops einrichten, wodurch die einzelnen Benutzer jedes System nutzen können.


Welche Empfehlung gibt es bezüglich der Anzahl von Benutzern, die für die Pre-Boot-Authentifizierung zugewiesen sind?
An der allgemeinen Empfehlung ändert sich nichts. Es sollte lediglich die minimale Anzahl von Benutzern für die Pre-Boot-Authentifizierung zugewiesen werden.


Gibt es Einbußen, wenn ich 5.000 Benutzern die Anmeldung in der Pre-Boot-Umgebung an einem Computer gestatte?
Ja. Die Aktivierung dauert länger, da dabei sämtliche Informationen zu den 5.000 Benutzern heruntergeladen werden müssen. Das Synchronisieren von Benutzerinformationen dauert länger, und die Arbeitslast des ePO-Servers nimmt zu.

Zudem dauert die Verarbeitung anderer Aktionen länger, die Benutzerinformationen beinhalten. Ein Beispiel hierfür ist das Speichern der Computerinformationen auf einem Client, da auch hierbei Benutzerinformationen eingeschlossen sind.


Kann dies die Skalierbarkeit meines ePO-Servers beeinträchtigen?
Ja. Ihr ePO-Server führt mehr Aufgaben pro Agent-Server-Kommunikationsintervall (ASKI) durch, um sicherzustellen, dass alle Informationen aktuell sind.


Was geschieht, wenn ich über 100 Systeme verfüge, denen jeweils 5.000 Benutzer zugewiesen sind?
Betrachten wir das gängigste Beispiel: ein geändertes Kennwort. Für einen Benutzer wird dies in einem System erfasst, in ePO hochgeladen und anschließend an die anderen 99 Systeme übermittelt, wenn eine Synchronisierung mit ePO stattfindet.

Wenn Sie erzwingen, dass Benutzer alle 90 Tage ihr Kennwort ändern müssen, aktualisieren 5.000 Benutzer ihr Kennwort. Das bedeutet, es gibt 500.000 Aktualisierungen (5.000 Benutzer x 100 Systeme), die vom ePO-Server zu verschiedenen Zeitpunkten verarbeitet werden müssen, wenn die Systeme mit ePO synchronisiert werden.


Liegt ein erhöhter/zusätzlicher Datenverkehr im Netzwerk vor?
Ja. Alle diese Vorgänge werden über das Netzwerk verarbeitet. Auch wenn die Datenmenge für die einzelnen Benutzer gering ist (im Allgemeinen < 20 Kilobyte), erfolgt doch eine Multiplikation mit der Anzahl der Transaktionen. Weist eines Ihrer Systeme eine langsame Verbindung auf, kann es ziemlich lange dauern, bis alle Änderungen empfangen wurden. Wenn der Server Benutzeraktualisierungen für viele Clients verarbeitet, kann daher auch der Netzwerkverkehr beträchtlich sein. Im schlimmsten Fall werden möglicherweise nicht alle Aktualisierungen in einem Synchronisierungszeitraum empfangen.


Wie härtet DE Systeme gegen Kaltstart-Angriffe?
Simpel ausgedrückt: Moderne Windows-Plattformen, die den neuen verbundenen Standby-Modus unterstützen, bieten den Benutzern eine iPad-ähnliche Erfahrung. Diese Systeme sind stets eingeschaltet, d. h. der Verschlüsselungsschlüssel muss sich stets im RAM befinden; dadurch sind sie anfällig gegenüber Memory Scrubbing-Angriffen, bei denen der Verschlüsselungsschlüssel aus dem RAM entfernt werden kann.

 

DE kann im Hintergrund betrieben werden, wodurch der Endbenutzer keinen Unterschied zu Windows merkt. Wenn das Gerät in den verbundenen Standby-Modus wechselt, löscht DE den Verschlüsselungsschlüssel aus dem RAM und verschiebt ihn in einen sicheren Bereich in Intel-Systemen zum Härten der Hardware, um den Schutz gegen Kaltstart- und Memory Scrubbing-Angriffe sicherzustellen. Wenn das Gerät in einen aktiven Status wechselt, wird der Verschlüsselungsschlüssel nach einer erfolgreichen Authentifizierung bei Windows transparent zurück in den RAM verschoben.
 

 

Was ist ein Kaltstart-Angriff?
Ein Kaltstart-Angriff eröffnet die Möglichkeit, vertrauliche Daten aus dem Systemspeicher zu extrahieren, wenn das System eingeschaltet ist oder sich in einem Standby-Modus befindet, selbst wenn es durch ein Windows-Kennwort geschützt ist. Der Angriff schließt entweder einen harten Neustart und das Ausführen eines kleinen Programms beim nächsten Startzyklus des Systems ein, bei dem der Systemspeicher auf vertrauliche Informationen gescannt wird, oder das Entfernen des RAM aus einem eingeschalteten System und seine Übersetzung in ein anderes System zu Scan-Zwecken.
 

 

Wie härtet DE 7.1.x diese Systeme gegen einen Kaltstart-Angriff?
Wenn das System in einen der Standby-Modi wechselt, entfernt DE 7.1.x den Schlüssel aus dem Speicher. Er wird an einem sicheren Speicherort gespeichert, der im verbundenen Standby-Modus immer noch zugänglich ist. Das System funktioniert weiterhin entsprechend den Erwartungen des Endbenutzers, es ist jedoch weniger anfällig gegenüber Kaltstart-Angriffen, da sich der Schlüssel nicht mehr im Speicher befindet.


Garantiert McAfee, dass der Schlüssel vollständig aus dem Speicher entfernt wird?
Diese Funktionalität härtet das System gegen speicherbezogene Angriffe. Es wurden zwar alle Maßnahmen ergriffen, um sicherzustellen, dass der Schlüssel aus dem Speicher entfernt wird, aufgrund der Speicherverwaltung in Windows kann McAfee jedoch nicht garantieren, dass er vollständig entfernt wird. In künftigen Versionen werden weitere Härtungsmaßnahmen in dieser Hinsicht ergriffen.


Was ist AOAC?
AOAC bedeutet "Always On, Always Connected" (Immer eingeschaltet, immer verbunden). Von Microsoft wird dieses Konzept als "verbundener Standby-Modus " und von Intel als "Smart Connect" bezeichnet. Im Wesentlichen bezeichnen alle diese Begriffe die gleiche allgemeine Funktionalität. Dabei handelt es sich um die Fähigkeit, ein System im Energie sparenden Ruhezustand zu halten, es regelmäßig zu aktivieren, um Daten abzurufen (E-Mails, Facebook-Aktualisierungen usw.) und anschließend wieder in den Ruhezustand zu versetzen, ohne dass der Benutzer dies bemerkt oder Maßnahmen ergreifen muss. Die Funktionsweise ähnelt der Ihres Mobiltelefons.


Wie ändert AOAC die vollständige Datenträgerverschlüsselung?
Bei der vollständigen Datenträgerverschlüsselung ging es traditionell immer um den Schutz von ruhenden Daten (bei ausgeschaltetem System). AOAC-Funktionen werden von diversen Unternehmen angeboten; damit werden Erwartungen der Benutzer befeuert, dass ihr System ständig aktuelle Inhalte enthält.


Wenn sich mein System im Ruhezustand befindet, bedeutet dies nicht, dass die Daten ohnehin ruhend sind?
Nein. Die Daten sind beim AOAC-Modell nie ruhend. Die Systeme sind nicht ausgeschaltet, sie befinden sich lediglich im Standby-Modus. Das AOAC-Modell erfordert, dass die Datenträger "entsperrt" bleiben. Dies hat folgende Gründe:

• Systeme können in regelmäßigen Abständen oder über eine Push-Benachrichtigung aktiviert werden.
• Anwendungen und Dienste können während dieses Aktivierungszeitraums Zugriff auf den Datenträger benötigen.
   

Gibt es Probleme mit dem AOAC-Modell?
Beim AOAC-Modell müssen das System und die Dienste in der Lage sein, auf den Datenträger zuzugreifen. Das heißt, der Verschlüsselungsschlüssel für den Datenträger verbleibt jederzeit im Speicher. Dies macht Systeme mit AOAC-Unterstützung anfälliger gegenüber Kaltstart-Angriffen, da sich der Schlüssel immer im Speicher befindet. Es wird nochmals darauf hingewiesen, dass das System nie eingeschaltet wird und sich lediglich im Standby-Modus befindet.


Unterstützt DE 7.1.x ein AOAC-Modell?
Ja. Die Unterstützung wird durch den verbundenen Standby-Modus gewährleistet. In diesem Standby-Modus werden die Daten durch die Windows-Anmeldung vor unbefugtem Zugriff geschützt.
 

Funktionieren alle AOAC-Funktion und der verbundene Standby-Modus noch, wenn ich diese Funktion aktiviere?
Ja.

Kann ich diese Funktion mit der Pre-Boot- und/oder AutoBoot-Funktion verwenden?
Diese Funktion kann unabhängig von der ausgewählten Authentifizierungsmethode verwendet werden. McAfee empfiehlt jedoch, dass Sie eine der folgenden Optionen verwenden:

• Pre-Boot
• Wenn AutoBoot ausgewählt wird, aktivieren Sie TPM-AutoBoot mit reaktivem AutoBoot oder die Integration mit der Active Management Technology von Intel.

Wann befindet sich der Schlüssel nicht im Speicher, wenn ich diese Funktion verwende?
Der Schlüssel kann aus dem Speicher entfernt werden, wenn eines der folgenden Ereignisse eintritt:

• Das System wird ausgeschaltet.
• Der Benutzer meldet sich ab.
• Der Benutzer sperrt die Arbeitsstation.
• Das System wartet, bis sich ein Benutzer an der Eingabeaufforderung der Windows-Anmeldung authentifiziert.
• Anschließend wird das System aus dem Standby-Modus oder Ruhezustand aktiviert.

Eine andere Betrachtungsweise: Wenn Benutzer sich authentifiziert haben und an ihrem Desktop befinden, befindet sich der Schlüssel im Speicher. Wenn Benutzer sich nicht authentifiziert haben oder nicht an ihrem Desktop befinden, ist der Schlüssel nicht im Speicher.

HINWEIS: Ein Administrator kann über eine Richtlinie auswählen, unter welchen Bedingungen der Schlüssel entfernt werden soll.


Unter welchen Bedingungen wird der Schlüssel wieder im Speicher abgelegt?
Erst nachdem ein Benutzer sich erfolgreich bei Windows authentifiziert hat. Durch die einfache Ausführung von Windows wird der Schlüssel nicht zurück in den Speicher verschoben.


Wo wird der Schlüssel gespeichert, wenn er sich nicht im Speicher befindet?
Der Schlüssel wird in einem sicheren Speicherbereich außerhalb des Speichers aufbewahrt.


Sind mehrere Treiber vorhanden, die den Schlüssel im Speicher verarbeiten?
Nein. Der Betrieb erfolgt jedoch in einem von zwei Modi. Dies sind die zwei Modi:

• Standardverschlüsselung
• Verschlüsselung mit erhöhter Sicherheit
   

Was ist der Standardverschlüsselungsmodus?
In diesem Zustand des Verschlüsselungstreibers gilt Folgendes:

• Der Verschlüsselungsschlüssel wird im RAM gespeichert.
• Es besteht kein Schutz gegen RAM-basierte oder Kaltstart-Angriffe.
• Höchste Optimierung in Bezug auf die Leistung.
• Es wird die Implementierung des gleichen Algorithmus wie in früheren EEPC 7.x-Versionen verwendet.
   

Was ist der Verschlüsselungsmodus mit erhöhter Sicherheit?
In diesem Zustand des Verschlüsselungstreibers gilt Folgendes:

• Es wird eine neue Implementierung des AES256-CBC-Verschlüsselungsalgorithmus verwendet.
• Der Verschlüsselungsschlüssel wird an einem sicheren Speicherort und nicht im RAM gespeichert.
• Es besteht keine Anfälligkeit gegenüber RAM-basierten oder Kaltstart-Angriffen.
• Dieser Status bringt eine erhebliche Leistungseinbuße mit sich.
• Richtlinienerzwingungen sind in diesem Status deaktiviert.
   

Welche Schlüssellänge wird vom Verschlüsselungsalgorithmus AES256 verwendet?
Es wird die Schlüssellänge128 Bit verwendet.


In welchen Fällen wechselt der Treiber zwischen den beiden Modi?
Dies wird durch eine Richtlinie definiert. DE 7.1 kann beispielsweise in den Verschlüsselungsmodus mit erhöhter Sicherheit wechseln, wenn für das System Folgendes gilt:

• Gesperrt
• Abgemeldet
• Ist in den Standby-Modus gewechselt
   

Wann wird zurück in den Standardverschlüsselungsmodus gewechselt?
Der Standardverschlüsselungsmodus wird fortgesetzt, wenn sich der Benutzer erfolgreich bei Windows authentifiziert hat.


Der Verschlüsselungsmodus mit erhöhter Sicherheit bringt Leistungseinbußen mit sich, spielt dies jedoch eine Rolle, wenn der Benutzer sein System nicht aktiv nutzt?
Nein. Bei Aktualisierungen aus dem verbundenen Standby-Modus wird langsamer auf die Datenträger zugegriffen, wenn der Verschlüsselungsmodus mit erhöhter Sicherheit aktiv ist. Da der Benutzer jedoch zu diesem Zeitpunkt sein System nicht aktiv nutzt, bemerkt er hiervon im Allgemeinen nichts.


Wenn ich einen Task mit starker Beanspruchung des Datenträgers ausführe und meine Arbeitsstation sperre und später zurückkehre, bedeutet dies, dass die Ausführung langsamer ist?
Ja. Da Sie Ihre Arbeitsstation gesperrt haben und das System im Verschlüsselungsmodus mit erhöhter Sicherheit ausgeführt wird, bei dem sich der Schlüssel nicht im Speicher befindet, sind beim Ausführen des Tasks Leistungseinbußen festzustellen.


Bedeutet dies auch, dass im Verschlüsselungsmodus mit erhöhter Sicherheit die Startdauer länger ist?
Ja. Ab dem anfänglichen Start wird der Schlüssel erst im Speicher abgelegt, wenn sich der Benutzer erfolgreich bei Windows authentifiziert hat. Wenn Sie ein Tablet verwenden, fahren Sie dieses wahrscheinlich nur selten vollständig herunter, sodass Sie dieses Verhalten nicht unbedingt bemerken.


Wird im Verschlüsselungsmodus mit erhöhter Sicherheit ein Kompromiss zwischen Sicherheit und Leistung eingegangen?
Ja. Sie erhalten eine viel höhere Sicherheit, nur geht diese mit Leistungseinbußen einher. Es ist unbedingt Folgendes zu beachten: Wenn ein Benutzer sein System aktiv nutzt, erhält er die normale, volle Leistung. Die Leistungseinbußen machen sich für den Benutzer nur in Phasen bemerkbar, wenn die Authentifizierung noch aussteht.


Von welchen Leistungseinbußen ist auszugehen, wenn sich der Treiber im Verschlüsselungsmodus mit erhöhter Sicherheit befindet?
In Bezug auf die RAW-Algorithmusleistung:

AES-NI-fähiger 64-Bit-Prozessor:

• Standardverschlüsselung = 1 CPU-Taktzyklus/Byte
• Verschlüsselung mit erhöhter Sicherheit = 15 CPU-Taktzyklen/Byte

Nicht AES-NI-fähiger 32-Bit-Prozessor:

• Standardverschlüsselung = 35 CPU-Taktzyklen/Byte
• Verschlüsselung mit erhöhter Sicherheit = 133 CPU-Taktzyklen/Byte

HINWEIS: Die Einbußen können erheblich höher als der obige RAW-Algorithmus sein, da die Tests mit deaktivierten Interrupts ausgeführt werden. Ein Beispiel mit einer anderen Betrachtungsweise: Ein System mit einem Durchsatz von 208 MB/s im Standardverschlüsselungsmodus kann im Verschlüsselungsmodus mit erhöhter Sicherheit bis auf eine Leistung von 20 MB/s abfallen.

 

Gibt es spezielle Hardware-Anforderungen für die Verwendung dieses Verschlüsselungsmodus mit erhöhter Sicherheit?
Ja. Diese Informationen finden Sie in KB79291.
HINWEIS: Das System muss den verbundenen Standby-Modus unterstützen, und es muss sich um ein Clover Trail-Tablet oder ein Haswell-System handeln.


Kann diese Funktion in Verbindung mit TPM-AutoBoot verwendet werden?
Ja.
 

 

Besteht ein Unterschied zwischen dem "verbundenen Standby-Modus" und "Smart Connect"?
Ja. Smart Connect ist als Technologie/Design insofern älter, als ein Treiber vorhanden ist, der das System in regelmäßigen Abständen aktiviert und sich bei einem Server einwählt, um Benachrichtigungen abzurufen. Der verbundene Standby-Modus ist hingegen eine neue Technologie, bei der das System auf der CPU in einen neuen Energiezustand wechselt.

Der verbundene Standby-Modus erfordert neue Hardware; bei Smart Connect ist dies nicht der Fall. Sie können Smart Connect also in einem Windows 7-System mit älterer CPU und Hardware betreiben. Aus technischer Sicht verwendet Smart Connect den Energiezustand S3, d. h. den Ruhezustand. Der verbundene Standby-Modus verwendet den Energiezustand RTD3 (ein Ruhemodus der CPU).


Was ist der verbundene Standby-Modus?
Der verbundene Standby-Modus ist nicht im eigentlichen Sinn ein Ruhezustand. Die Funktion wird in einem neuen Energiezustand ausgeführt, in dem einige Dienste weiter ausgeführt werden, die Benachrichtigungen vom Server empfangen können. Demzufolge gelten spezielle Hardware-Anforderungen, und die Funktion ist nur für Windows 8.x-Systeme verfügbar.


Welche Hardware-Anforderungen gelten für den verbundenen Standby-Modus?
Windows 8 nutzt die Vorteile des verbundenen Standby-Modus, wenn die folgenden Hardware-Anforderungen erfüllt sind:

• Es muss eine Firmware-Kennzeichnung vorhanden sein, die die Unterstützung des Standards angibt.
• Das Start-Volume darf keine rotierende Festplatte verwenden.
• Alle Netzwerkgeräte müssen NDIS 6.30 unterstützen.
• Passive Abkühlung im verbundenen Standby-Modus.

HINWEIS: Es bestehen zusätzliche sicherheitsspezifische Anforderungen. Der Speicher muss beispielsweise mit der Hauptplatine verlötet sein, um Kaltstart-Angriffsvektoren zu verhindern, die das Abtrennen des Speichers vom Computer beinhalten; zudem muss das sichere Hochfahren unterstützt werden.


Kann ich einen mit DE verschlüsselten Datenträger neu partitionieren?
Nein. Die Partitionierung eines bereits verschlüsselten Datenträgers kann nicht geändert werden. Sie müssen den Datenträger vollständig entschlüsseln und DE deinstallieren, bevor Sie den Datenträger neu partitionieren können.


Zurück zum Inhalt

• Ein UEFI (Unified Extensible Firmware Interface)-Startvorgang
• GPT-Datenträgerpartitionierung
• Sicheres Hochfahren
• Hybrid-Boot
• Moderne Windows 8-Benutzeroberfläche
• Windows 8-Tablet-PCs
   

• Die Pre-Boot-Authentifizierung wird automatisch aktiviert, und AutoBoot wird deaktiviert.
• Windows wird direkt heruntergefahren, und das System wird neu gestartet.
• Während des Neustarts des Computers wird der Pre-Boot-Authentifizierungsbildschirm angezeigt, und der Benutzer muss sich erfolgreich authentifizieren, um Zugriff auf Windows zu erhalten.

• Auf einem Client-System, das den reaktiven AutoBoot verwendet, wird die AMT-Funktion im Pre-Boot nicht verwendet. Wenn die Authentifizierung eines Benutzers wiederholt fehlschlägt, aktiviert der reaktive AutoBoot den Pre-Boot und startet das System neu.
• Der Pre-Boot verwendet AMT, kontaktiert ePO und erhält die Berechtigung zum Starten. Wenn ePO nicht oder negativ reagiert, befindet sich der Benutzer in derselben Lage wie mit dem herkömmlichen reaktiven AutoBoot ohne AMT.
• Der Benutzer gelangt zurück zum Windows-Anmeldebildschirm, und der reaktive AutoBoot wird aktiviert, da das System Windows gestartet hat. Der Benutzer kann so lange falsche Kennwörter eingeben, bis Windows den Benutzer deaktiviert.
• In diesem Fall ist höchstwahrscheinlich ein Anruf beim Helpdesk erforderlich. Beim reaktiven AutoBoot handelt es sich um eine Aktivität auf dem Client. Es erfolgt keine Kommunikation mit dem ePO-Server, und es bleibt keine Zeit zur Kommunikation mit dem Server, wenn die Funktion auf fehlgeschlagene Anmeldeversuche reagiert.

• Die UEFI wird durch das UEFI-Forum verwaltet, einer Gruppe von Chip-Satz-, Hardware-, System-, Firmware- und Betriebssystemanbietern. Das Forum pflegt und verwaltet Spezifikationen, Test-Tools und Referenzimplementierungen, die auf zahlreichen UEFI-Computern verwendet werden.
• Durch die UEFI soll eine standardisierte Kommunikation des Betriebssystems mit der Plattform-Firmware während des Startvorgangs definiert werden. Vor der UEFI waren Software-Interrupts der primäre Mechanismus zur Kommunikation mit der Hardware während des Startvorgangs. Moderne PCs können eine schnellere und effizientere Blockeingabe und -ausgabe zwischen Hardware und Software ausführen, und dank UEFI kann das Potential der Hardware optimal genutzt werden.
• Die UEFI ermöglicht ein modulares Firmware-Design, das Hardware- und Systementwicklern mehr Flexibilität bei der Firmware-Entwicklung für anspruchsvolle moderne Computer-Umgebungen bietet. Während die Ein- und Ausgabe bei Software-Interrupts eingeschränkt war, fördert die UEFI das Konzept der ereignisorientierten, architekturneutralen Codierungs-Standards.

• Alle biometrischen Token
• USB-Token für eToken von SafeNet

Die unterstützten Token für die Authentifizierung in Drive Encryption 7.1.x sind in KB79787 aufgelistet.
Die unterstützten Lesegeräte für die Authentifizierung in Drive Encryption 7.1.x sind in KB79788 aufgelistet.

• Tablet-PCs mit Intel-Prozessoren
• Tablet-PCs mit ARM-Prozessoren

• CPU-Leistung
• Touchscreen-Unterstützung

• Interne Bereitstellung
• Bereitstellung durch eine Drittpartei
• Ein Remote-System, das nie eine Verbindung mit ePO herstellt

• Ein Administrator erstellt ein Offline-Paket auf dem ePO-Server. Dieses Paket enthält die erste Richtlinie, die erstellt werden muss, und eine Liste der Offline-Benutzer.
• Nach der Erstellung kann das Paket zusammen mit den zur Installation von EEPC erforderlichen MSIs an die nötigen Clients verteilt werden. Sobald EEPC erfolgreich installiert wurde, wird das Offline-Paket ausgeführt und die Richtlinie angewendet und erzwungen.
• Sie können sich jetzt mit den Offline-Benutzern im Pre-Boot anmelden.
   

• McAfee Agent
• McAfee Endpoint Encryption-Agent
• DE
• Das vom Administrator erstellte Offline-Paket
   

• Das System verwirft sowohl die erzwungene Offline-Richtlinie als auch alle Offline-Benutzer. Dabei werden wie bei einer normalen Aktivierung die geltende Richtlinie von ePO und die Liste der zugewiesenen Benutzer abgerufen und der Verschlüsselungsschlüssel in ePO gespeichert. Dies ist sozusagen eine zweite Aktivierung, die jedoch automatisch erfolgt.
• WICHTIG: Beachten Sie, dass alle Offline-Informationen verworfen werden, wenn der Offline-Benutzer dem ePO-Server vor dem Verbinden nicht bekannt ist. Wenn der Offline-Benutzer dem ePO-Server bekannt ist, werden die ePO-Richtlinien angewendet, die vom Offline-Benutzer im Offline-Modus gespeicherten Daten werden jedoch nicht verworfen.

• Sicherung des Geräteschlüsseln
• Pfad zum Wiederherstellungsschlüssel
• Temporären AutoBoot aktivieren
• AutoBoot aktivieren
• Vorherigen Benutzernamen nicht anzeigen
• SSO aktivieren
• Boot-Manager aktivieren
• PBFS-Größe
• Opal PBFS-Größe
• Benutzer müssen das Kennwort ändern
• Benutzername muss mit Windows-Anmeldebenutzernamen übereinstimmen
• Selbstwiederherstellung aktivieren
• Benutzer-Smartcard-PIN
• USB im Pre-Boot aktivieren
  
  WICHTIG: Wenn der Computer mit einem Opal-Laufwerk ausgestattet ist, wird bei einer Offline-Aktivierung zuerst die Opal-Verschlüsselung verwendet. OPAL-Voreinstellungen sind in den Offline-Aktivierungspaketen hartcodiert, sodass keine benutzerdefinierten Richtlinieneinstellungen berücksichtigt werden.

• Sie deaktivieren die PBSC über die Richtlinie
• Sie haben folgenden Registrierungswert gelöscht: Software\McAfee Full Disk Encryption\MfeEpePc\SafeFailStatus\Status

• Kennwort zurücksetzen
• Kontextbezogene Sicherheit
• Reaktivieren und mit Patch versehen
• Remote-Behebung
  HINWEIS: In den folgenden häufig gestellten Fragen werden diese Anwendungsfälle ausführlich dargestellt.

• Zurücksetzen des Benutzerkennworts
• Eine bestimmte Anzahl von Entsperrungen
• Entsperrung für einen bestimmten Zeitraum
• Notfall-Bootvorgang
• Wiederherstellung von MBR

• Entsperrungsplan
• Dauerhaft entsperren

• Der Remote-Zugriff muss aktiviert sein.
• Aktivieren Sie CILA (Client Initiated Local Access, vom Client initiierter lokaler Zugriff). Wählen Sie den richtigen Agenten-Handler aus.
• Wählen Sie als Verbindungstyp BIOS und das Betriebssystem aus.
• Wenn Sie CIRA (Client Initiated Remote Access, vom Client initiierter Remote-Zugriff) wünschen, muss Folgendes konfiguriert sein:
  • Stammdomänensuffix
  • DMZ-Agenten-Handler
  • Von Benutzer initiierten Tunnel zulassen

• Der Endbenutzer startet seinen Computer, kann sich nicht anmelden und ruft den Helpdesk an.
• Der Endbenutzer ruft im Pre-Boot den Wiederherstellungsbereich auf und nennt dem Helpdesk-Benutzer seinen ePO-Benutzernamen.
• Der Helpdesk-Benutzer lokalisiert das System, das der Benutzer in ePO verwendet.
• Der Helpdesk-Benutzer setzt mithilfe der Intel AMT-Funktion das Kennwort auf ein temporäres Einmalkennwort zurück.
• Damit das angegebene System die neuen Token-Daten erhält, schreibt ePO das Element in die Verarbeitungswarteschlange. Der Pre-Boot liest dann die Verarbeitungswarteschlange und ruft den Schlüssel über den durch Intel AMT bereitgestellten Netzwerk-Stack ab.
• Der Client erhält die neuen Token-Daten und verlässt automatisch den Wiederherstellungsbildschirm und wechselt zurück zum Kennwortbildschirm. Daran kann der Endbenutzer erkennen, dass das neue Kennwort angekommen ist. Der Endbenutzer wird zusätzlich durch einen Piepton darauf hingewiesen, dass die neuen Token-Daten eingetroffen sind.
• Der Endbenutzer authentifiziert sich dann mit dem Einmalkennwort und legt ein neues Kennwort fest.

• Wenn der Endbenutzer den Wiederherstellungsbildschirm verlassen und auf den Empfang des aktualisierten Kennworts gewartet hat, sieht er möglicherweise, dass der Anmeldebildschirm verschwindet und kurz darauf wieder angezeigt wird.
• Zusätzlich hört der Endbenutzer beim Eingang der neuen Token-Daten einen Piepton.

• Kunden, die nicht möchten, dass die Pre-Boot-Umgebung angezeigt wird, während sich ihre Endbenutzer im Büro befinden, diese jedoch angezeigt werden soll, wenn sich die Endbenutzer außerhalb des Büros befinden oder das System verloren geht bzw. gestohlen wird.
• Kunden, die ein System verschlüsseln möchten, das sich dauerhaft im Büro befindet, und den Endbenutzer nicht mit dem Pre-Boot belasten möchten, weshalb für diesen die Authentifizierung automatisch über ePO und AMT erfolgt. Zudem soll der Pre-Boot angezeigt werden, wenn der Computer aus dem Büro gestohlen wird.
• Kunden mit Computern, die von vielen Einzelpersonen gemeinsam genutzt werden. Denken Sie beispielsweise an Meeting-Räume, Schulungsräume, Laptops und Desktop-PCs in einer Klinik usw.
• Kunden, die Probleme bei der Kennwortsynchronisierung verhindern möchten, indem der Pre-Boot nie angezeigt wird, während der Computer gleichzeitig bei Verlust oder Diebstahl geschützt ist. Benutzer authentifizieren sich zuerst bei Windows, obwohl DE im Hintergrund automatisch eine Authentifizierung über ePO und AMT durchführt.

• Ein oder mehrere Neustarts
• Startdatum/-zeit und Enddatum/-zeit
• Einen Wochenplan für blockierte und verfügbare Zeiten

• Er könnte fünf Minuten warten, bis der nächste Versuch gestartet wird, ePO zu erreichen. Dies ist möglich, da es sich um eine CILA-Anfrage (lokal) handelt.
• Er könnte sein System aus- und wieder einschalten. Der Pre-Boot versucht dann beim Neustart sofort, ePO zu kontaktieren.
• Der Benutzer kann sich schließlich auch jederzeit authentifizieren, indem er den Benutzernamen und das Kennwort eines anderen bekannten Benutzers eingibt, der sich beim Pre-Boot authentifizieren kann, sofern die Umstände dies zulassen.

1. Der Benutzer startet das System und bemerkt, dass es nicht funktioniert.
2. Der Benutzer bittet den Administrator um Hilfe.
3. Der Administrator wählt die entsprechende Behebungsaktion aus, die sofort startet. Dies wird auch als SILA (Server Initiated Local Access, Vom Server initiierter lokaler Zugriff) bezeichnet.
4. Wenn das Client-System gefunden wird und eine Verbindung hergestellt werden kann, startet die Umleitung, und das System wird automatisch repariert.
   Wenn das Client-System im lokalen Netzwerk jedoch nicht gefunden werden kann, tritt bei der Aktion ein Fehler auf, und der Status verbleibt als "Ausstehend" in der Warteschlange. Eine Verarbeitung ist nur dann möglich, wenn sich das System meldet. In dieser Situation ist dies nicht möglich, da im Pre-Boot ein Fehler aufgetreten ist. Daher kann ein ähnlicher Ablauf wie im nächsten Szenario beschrieben verwendet werden.

1. Der Benutzer startet das System und bemerkt, dass es nicht funktioniert.
2. Der Benutzer bittet den Administrator um Hilfe.
3. Der Administrator wählt die entsprechende Behebungsaktion aus, die sofort startet. Die Aktion schlägt in diesem Fall jedoch fehl, da das System im Unternehmensnetzwerk nicht gefunden werden kann.
4. Der Administrator bittet den Benutzer einen "Hilferuf" über das BIOS einzuleiten. Dies ist von OEM zu OEM unterschiedlich, befindet sich jedoch üblicherweise in den Startoptionen, und bei einigen Systemen kann auch einfach STRG+ALT+F1 gedrückt werden.
5. Das System stellt daraufhin eine Verbindung mit STunnel (Deep Command Gateway Services) her, und der Agenten-Handler erkennt dies und sendet eine Nachricht an Deep Command.
6. Deep Command verarbeitet die dem System zugeordnete Aktion. In diesem Fall ist dies die Behebungsaktion.