HealthAttestation-Konfigurationsdienstanbieter

Wichtig

Dieser CSP enthält einige Einstellungen, die sich in der Entwicklung befinden und nur für Windows Insider Preview Builds gelten. Diese Einstellungen können geändert werden und können Abhängigkeiten von anderen Features oder Diensten in der Vorschau aufweisen.

Der Device HealthAttestation-Konfigurationsdienstanbieter (DHA-CSP) ermöglicht IT-Administratoren des Unternehmens, zu bewerten, ob ein Gerät in einem vertrauenswürdigen und konformen Zustand gestartet wird, und Unternehmensrichtlinienaktionen zu ergreifen.

Die folgende Liste enthält eine Beschreibung der Funktionen, die vom Device HealthAttestation-CSP ausgeführt werden:

• Erfasst Gerätestartprotokolle, TPM-Überwachungspfade (Trusted Platform Module) und das TPM-Zertifikat (DHA-BootData) von einem verwalteten Gerät
• Leitet DHA-BootData an einen Device Health Attestation Service (DHA-Service) weiter.
• Empfängt ein verschlüsseltes Blob (DHA-EncBlob) von DHA-Service und speichert es in einem lokalen Cache auf dem Gerät.
• Empfängt Nachweisanforderungen (DHA-Requests) von einem DHA-Enabled MDM und antwortet mit Geräteintegritätsnachweisdaten (DHA-Data)

In der folgenden Liste sind die HealthAttestation-Konfigurationsdienstanbieterknoten aufgeführt:

• ./Vendor/MSFT/HealthAttestation
  • AttestErrorMessage
  • AttestStatus
  • Zertifikat
  • Correlationid
  • CurrentProtocolVersion
  • ForceRetrieve
  • GetAttestReport
  • GetServiceCorrelationIDs
  • HASEndpoint
  • MaxSupportedProtocolVersion
  • Nonce
  • PreferredMaxProtocolVersion
  • Status
  • TpmReadyStatus
  • TriggerAttestation
  • VerifyHealth

AttestErrorMessage

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows Insider Preview

./Vendor/MSFT/HealthAttestation/AttestErrorMessage

AttestErrorMessage verwaltet die Fehlermeldung für die letzte Nachweissitzung, wenn sie vom Nachweisdienst zurückgegeben wird.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	„Abrufen“

AttestStatus

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, Version 21H2 [10.0.22000] und höher

./Vendor/MSFT/HealthAttestation/AttestStatus

AttestStatus verwaltet den Erfolg oder Fehler status Code für die letzte Nachweissitzung.

Die status wird vor dem Aufruf des Nachweisdiensts immer gelöscht.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	int
Zugriffstyp	„Abrufen“

Beispiel:

• SyncML-Aufruf mit Vorlagen:

  <SyncML xmlns="SYNCML:SYNCML1.2">
      <SyncBody>
      <Get>
          <Item>
          <Target>
              <LocURI>
              ./Device/Vendor/MSFT/HealthAttestation/AttestStatus
              </LocURI>
          </Target>
          </Item>
      </Get>
      <Final/>
      </SyncBody>
  </SyncML>
  

• Beispielantwort:

  If Successful: 0
  If Failed: A corresponding HRESULT error code. Example: 0x80072efd,  WININET_E_CANNOT_CONNECT
  

Zertifikat

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/Certificate

Weist den DHA-CSP an, DHA-Data an den MDM-Server weiterzuleiten.

Der Werttyp ist eine base64-Zeichenfolge.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	„Abrufen“

Correlationid

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/CorrelationID

Identifiziert eine eindeutige Sitzung zum Nachweis der Geräteintegrität. CorrelationId wird verwendet, um DHA-Service Protokolle mit den MDM-Serverereignissen und Clientereignisprotokollen zum Debuggen und Zur Problembehandlung zu korrelieren.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	„Abrufen“

CurrentProtocolVersion

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1709 [10.0.16299] und höher

./Vendor/MSFT/HealthAttestation/CurrentProtocolVersion

Stellt die aktuelle Protokollversion bereit, die der Client für die Kommunikation mit dem Integritätsnachweisdienst verwendet.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	int
Zugriffstyp	„Abrufen“

ForceRetrieve

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/ForceRetrieve

Weist den Client an, eine neue Anforderung an DHA-Service zu initiieren und eine neue DHA-EncBlob zu erhalten (eine Zusammenfassung des Startstatus, der von DHA-Service ausgegeben wird). Diese Option sollte nur verwendet werden, wenn der MDM-Server eine Richtlinie für die Aktualität von Zertifikaten erzwingt, die ein Gerät erzwingen muss, um ein neues verschlüsseltes Blob von DHA-Service abzurufen.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	bool
Zugriffstyp	Abrufen, Ersetzen
Standardwert	False

Zulässige Werte:

Wert	Beschreibung
false (Standard)	FALSE.
true	STIMMT.

GetAttestReport

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, Version 21H2 [10.0.22000] und höher

./Vendor/MSFT/HealthAttestation/GetAttestReport

Ruft den Bericht zur Nachweissitzung ab, falls vorhanden.

Der Bericht wird in einem Registrierungsschlüssel im entsprechenden MDM-Registrierungsspeicher gespeichert.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	„Abrufen“

Beispiel:

• SyncML-Aufruf mit Vorlagen:

  <SyncML xmlns="SYNCML:SYNCML1.2">
  <SyncBody>
      <Get>
      <Item>
          <Target>
          <LocURI>
              ./Device/Vendor/MSFT/HealthAttestation/GetAttestReport
          </LocURI>
          </Target>
      </Item>
      </Get>
      <Final/>
  </SyncBody>
  </SyncML>
  

• Beispieldaten:

  If Success: JWT token: aaaaaaaaaaaaa.bbbbbbbbbbbbb.cccccccccc
  If failed: Previously cached report if available (the token may have already expired per the attestation policy).
             OR Sync ML 404 error if no cached report available.
  

GetServiceCorrelationIDs

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, Version 21H2 [10.0.22000] und höher

./Vendor/MSFT/HealthAttestation/GetServiceCorrelationIDs

Abrufen von Dienstkorrelations-IDs (sofern vorhanden).

Wenn mehr als eine Korrelations-ID vorhanden ist, werden diese in der Zeichenfolge durch ";" getrennt.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	„Abrufen“

Beispiel:

• SyncML-Aufruf mit Vorlagen:

  <SyncML xmlns="SYNCML:SYNCML1.2">
    <SyncBody>
      <Get>
      <Item>
        <Target>
        <LocURI>
          ./Device/Vendor/MSFT/HealthAttestation/GetServiceCorrelationIDs
        </LocURI>
        </Target>
      </Item>
      </Get>
      <Final/>
    </SyncBody>
  </SyncML>
  

• Beispieldaten:

  If success: GUID returned by the attestation service: 1k9+vQOn00S8ZK33;CMc969r1JEuHwDpM
  If Trigger Attestation call failed and no previous data is present: The field remains empty.
  Otherwise, the last service correlation id will be returned.
  In a successful attestation there are two calls between client and MAA and for each call the GUID is separated by semicolon.
  

HASEndpoint

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/HASEndpoint

Identifiziert den vollqualifizierten Domänennamen (FQDN) des DHA-Service, dem der Nachweis zugewiesen ist. Wenn kein FQDN zugewiesen ist, wird DHA-Cloud (von Microsoft betriebener Clouddienst) als Standardnachweisdienst verwendet.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	Abrufen, Ersetzen
Standardwert	has.spserv.microsoft.com.

MaxSupportedProtocolVersion

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1709 [10.0.16299] und höher

./Vendor/MSFT/HealthAttestation/MaxSupportedProtocolVersion

Gibt die maximale Protokollversion zurück, die dieser Client unterstützen kann.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	int
Zugriffstyp	„Abrufen“

Nonce

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/Nonce

Ermöglicht MDMs, die Geräteintegritätsnachweiskommunikation vor Man-in-the-Middle-Angriffen (MITM) mit einem verschlüsselten Zufallswert zu schützen, der vom MDM-Server generiert wird. Die Nonce ist im hexadiellen Format mit einer Mindestgröße von 8 Bytes und einer maximalen Größe von 32 Bytes.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	Abrufen, Ersetzen
Standardwert	\0

PreferredMaxProtocolVersion

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1709 [10.0.16299] und höher

./Vendor/MSFT/HealthAttestation/PreferredMaxProtocolVersion

Stellt die maximal bevorzugte Protokollversion bereit, über die der Client für die Kommunikation konfiguriert ist. Wenn diese höher als die vom Client unterstützten Protokollversionen ist, wird die höchste verfügbare Protokollversion verwendet.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	int
Zugriffstyp	Abrufen, Ersetzen
Standardwert	3

Status

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/Status

Stellt die aktuelle status der Geräteintegritätsanforderung bereit. Eine vollständige Liste der status Werte finden Sie unter HealthAttestation CSP status und Fehlercodes.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	int
Zugriffstyp	„Abrufen“

TpmReadyStatus

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1607 [10.0.14393] und höher

./Vendor/MSFT/HealthAttestation/TpmReadyStatus

Gibt eine Bitmaske mit Informationen zurück, die den Zustand des TPM beschreiben. Es gibt an, ob sich das TPM des Geräts in einem bereit und vertrauenswürdigen Zustand befindet.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	int
Zugriffstyp	„Abrufen“

TriggerAttestation

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, Version 21H2 [10.0.22000] und höher

./Vendor/MSFT/HealthAttestation/TriggerAttestation

Benachrichtigt das Gerät, eine Nachweissitzung asynchron auszulösen.

Wenn der Nachweisprozess erfolgreich gestartet wurde, gibt dieser Knoten code 202 zurück, der angibt, dass die Anforderung empfangen und verarbeitet wird. Andernfalls wird ein Fehler zurückgegeben.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	chr (Zeichenfolge)
Zugriffstyp	Exec

Beispiel:

• SyncML-Aufruf mit Vorlagen:

  <SyncML xmlns="SYNCML:SYNCML1.2">
      <SyncBody>
          <Exec>
              <CmdID>VERIFYHEALTHV2</CmdID>
              <Item>
                  <Target>
                      <LocURI>
                          ./Vendor/MSFT/HealthAttestation/TriggerAttestation
                      </LocURI>
                  </Target>
                  <Data>
                      {
                      rpID : "rpID", serviceEndpoint : "MAA endpoint",
                      nonce : "nonce", aadToken : "aadToken", "cv" : "CorrelationVector"
                      }
                  </Data>
              </Item>
          </Exec>
          <Final/>
      </SyncBody>
  </SyncML>
  

• Datenfelder:

  • rpID (Bezeichner der vertrauenden Seite): Dieses Feld enthält einen Bezeichner, der verwendet werden kann, um den Aufrufer zu bestimmen.
  • serviceEndpoint: Dieses Feld enthält die vollständige URL des Microsoft Azure Attestation-Anbieters instance für die Auswertung verwendet werden soll.
  • nonce: Dieses Feld enthält eine beliebige Zahl, die nur einmal in einer kryptografischen Kommunikation verwendet werden kann. Es handelt sich häufig um eine zufällige oder pseudo zufällige Zahl, die in einem Authentifizierungsprotokoll ausgegeben wird, um sicherzustellen, dass alte Kommunikationen nicht bei Replay-Angriffen wiederverwendet werden können.
  • aadToken: Das Microsoft Entra Token, das für die Authentifizierung beim Microsoft Azure Attestation-Dienst verwendet werden soll.
  • cv: Dieses Feld enthält einen Bezeichner (Korrelationsvektor), der an den Dienstaufruf übergeben wird und für Diagnose Zwecke verwendet werden kann.

• Beispiel <Data>:

  {
    "rpid" : "https://www.contoso.com/attestation",
    "endpoint" : "https://contoso.eus.attest.azure.net/attest/tpm?api-version=2020-10-01",
    "nonce" : "5468697320697320612054657374204e6f6e6365",
    "aadToken" : "dummytokenstring",
    "cv" : "testonboarded"
  }
  

VerifyHealth

Bereich	Editionen	Anwendbares Betriebssystem
✅ Gerät ❌ Benutzer	✅ Pro ✅ Enterprise ✅ Bildung ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, Version 1511 [10.0.10586] und höher

./Vendor/MSFT/HealthAttestation/VerifyHealth

Benachrichtigt das Gerät, eine Anforderung zur Überprüfung der Geräteintegrität vorzubereiten.

Eigenschaften des Beschreibungsframeworks:

Eigenschaftenname	Eigenschaftenwert
Format	null
Zugriffstyp	Exec

Windows 11 Geräteintegritätsnachweis

Windows 11 wird ein Update für das Feature zum Nachweis der Geräteintegrität eingeführt. Dieses Update unterstützt tiefere Einblicke in die Windows-Startsicherheit und unterstützt einen Zero-Trust-Ansatz für die Gerätesicherheit. Auf den Geräteintegritätsnachweis unter Windows kann mithilfe des HealthAttestation-CSP zugegriffen werden. Dieser CSP hilft dabei, zu bewerten, ob ein Gerät in einem vertrauenswürdigen und konformen Zustand gestartet wird, und dann geeignete Maßnahmen zu ergreifen. Windows 11 führt mehr untergeordnete Knoten in den Knoten HealthAttestation ein, damit die MDM-Anbieter eine Verbindung mit dem Microsoft Azure Attestation-Dienst herstellen können. Dies bietet einen vereinfachten Nachweisansatz.

Der Nachweisbericht enthält eine Integritätsbewertung der Startzeiteigenschaften des Geräts, um sicherzustellen, dass die Geräte nach dem Einschalten automatisch geschützt sind. Das Ergebnis des Integritätsnachweises kann dann verwendet werden, um den Zugriff auf Netzwerke, Apps oder Dienste zuzulassen oder zu verweigern, je nach Integrität des Geräts.

Verwendete Begriffe:

• TPM (Trusted Platform Module): TPM ist eine spezielle hardwaregeschützte Logik, die eine Reihe von hardwaregeschützten Sicherheitsvorgängen ausführt, einschließlich der Bereitstellung von geschütztem Speicher, Zufälliger Zahlengenerierung, Verschlüsselung und Signierung.
• DHA-Feature (Device HealthAttestation): Das Feature Device HealthAttestation (DHA) ermöglicht IT-Administratoren im Unternehmen die Remoteüberwachung des Sicherheitsstatus verwalteter Geräte mithilfe von hardwaregeschützten und bestätigten Daten (TPM) über einen manipulationssicheren und manipulationssicheren Kommunikationskanal.
• MAA-Session (Microsoft Azure Attestation dienstbasierte HealthAttestation-Sitzung): Die Microsoft Azure Attestation dienstbasierte HealthAttestation-Sitzung (MAA-Session) beschreibt den End-to-End-Kommunikationsfluss, der in einer Sitzung zum Nachweis der Geräteintegrität ausgeführt wird.
• MAA-CSP-Knoten (Microsoft Azure Attestation-basierter Konfigurationsdienstanbieter): Die Knoten des Konfigurationsdienstanbieters, die Windows 11 hinzugefügt werden, um sie in Microsoft Azure Attestation Service zu integrieren. Die folgende Liste der Vorgänge wird von MAA-CSP ausgeführt:
  • Empfängt Nachweistriggeranforderungen von einem HEALTHAttestation-fähigen MDM-Anbieter.
  • Das Gerät sammelt Nachweise (Gerätestartprotokolle, TPM-Überwachungspfade und das TPM-Zertifikat) von einem verwalteten Gerät.
  • Leitet den Nachweisnachweis wie vom MDM-Anbieter konfiguriert an den Azure Attestation Service instance weiter.
  • Empfängt einen signierten Bericht vom Azure Attestation Service instance und speichert ihn in einem lokalen Cache auf dem Gerät.
• MAA-Endpunkt: Der Microsoft Azure-Nachweisdienst ist eine Azure-Ressource, und jede instance des Diensts erhält die vom Administrator konfigurierte URL. Der generierte URI ist eindeutig und wird für die Zwecke des Geräteintegritätsnachweises als MAA-Endpunkt bezeichnet.
• JWT (JSON Web Token):JSON Web Token (JWT) ist eine offene Standard-RFC7519 Methode zum sicheren Übertragen von Informationen zwischen Parteien als JSON-Objekt (JavaScript Object Notation). Diese Informationen können überprüft und als vertrauenswürdig eingestuft werden, da sie digital signiert sind. JWTs können mit einem Geheimnis oder einem Paar aus öffentlichem und privatem Schlüssel signiert werden.

Nachweisfluss mit Microsoft Azure Attestation Service

Der Nachweisfluss kann in drei Standard Schritten erfolgen:

• Eine instance des Azure Attestation-Diensts wird mit einer entsprechenden Nachweisrichtlinie eingerichtet. Die Nachweisrichtlinie ermöglicht es dem MDM-Anbieter, bestimmte Ereignisse beim Start sowie Sicherheitsfeatures zu bestätigen.
• Der MDM-Anbieter löst einen Aufruf des Nachweisdiensts aus, und das Gerät führt dann eine Nachweisüberprüfung durch, damit der Bericht für den Abruf bereit ist.
• Nachdem der MDM-Anbieter überprüft hat, dass das Token vom Nachweisdienst stammt, kann er das Nachweistoken analysieren, um den bestätigten Zustand des Geräts widerzuspiegeln.

Weitere Informationen finden Sie unter Nachweisprotokoll.

MAA CSP-Integrationsschritte

1. Einrichten eines MAA-Anbieters instance: MAA-instance können anhand der Schritte unter Schnellstart: Einrichten von Azure Attestation mithilfe des Azure-Portal erstellt werden.

2. Aktualisieren des Anbieters mit einer geeigneten Richtlinie: Die MAA-instance sollte mit einer entsprechenden Richtlinie aktualisiert werden. Weitere Informationen finden Sie unter Erstellen einer Azure Attestation Richtlinie.

   Eine Beispielnachweisrichtlinie:

   version=1.2;
   
   configurationrules{
   };
   
   authorizationrules {
       => permit();
   };
   
   issuancerules {
   
       // SecureBoot enabled
       c:[type == "events", issuer=="AttestationService"] => add(type = "efiConfigVariables", value = JmesPath(c.value, "Events[?EventTypeString == 'EV_EFI_VARIABLE_DRIVER_CONFIG' && ProcessedData.VariableGuid == '8BE4DF61-93CA-11D2-AA0D-00E098032B8C']"));
       c:[type == "efiConfigVariables", issuer=="AttestationPolicy"]=> issue(type = "secureBootEnabled", value = JsonToClaimValue(JmesPath(c.value, "[?ProcessedData.UnicodeName == 'SecureBoot'] | length(@) == `1` && @[0].ProcessedData.VariableData == 'AQ'")));
       ![type=="secureBootEnabled", issuer=="AttestationPolicy"] => issue(type="secureBootEnabled", value=false);
   
       // Retrieve bool properties
       c:[type=="events", issuer=="AttestationService"] => add(type="boolProperties", value=JmesPath(c.value, "Events[? EventTypeString == 'EV_EVENT_TAG' && (PcrIndex == `12` || PcrIndex == `13` || PcrIndex == `19` || PcrIndex == `20`)].ProcessedData.EVENT_TRUSTBOUNDARY"));
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="codeIntegrityEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_CODEINTEGRITY")));
       c:[type=="codeIntegrityEnabledSet", issuer=="AttestationPolicy"] => issue(type="codeIntegrityEnabled", value=ContainsOnlyValue(c.value, true));
       ![type=="codeIntegrityEnabled", issuer=="AttestationPolicy"] => issue(type="codeIntegrityEnabled", value=false);
   
       // Bitlocker Boot Status, The first non zero measurement or zero.
       c:[type=="events", issuer=="AttestationService"] => add(type="srtmDrtmEventPcr", value=JmesPath(c.value, "Events[? EventTypeString == 'EV_EVENT_TAG' && (PcrIndex == `12` || PcrIndex == `19`)].ProcessedData.EVENT_TRUSTBOUNDARY"));
       c:[type=="srtmDrtmEventPcr", issuer=="AttestationPolicy"] => issue(type="bitlockerEnabledValue", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_BITLOCKER_UNLOCK | @[? Value != `0`].Value | @[0]")));
       [type=="bitlockerEnabledValue"] => issue(type="bitlockerEnabled", value=true);
       ![type=="bitlockerEnabledValue"] => issue(type="bitlockerEnabled", value=false);
   
       // Elam Driver (windows defender) Loaded
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="elamDriverLoaded", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_LOADEDMODULE_AGGREGATION[] | [? EVENT_IMAGEVALIDATED == `true` && (equals_ignore_case(EVENT_FILEPATH, '\\windows\\system32\\drivers\\wdboot.sys') || equals_ignore_case(EVENT_FILEPATH, '\\windows\\system32\\drivers\\wd\\wdboot.sys'))] | @ != `null`")));
       [type=="elamDriverLoaded", issuer=="AttestationPolicy"] => issue(type="WindowsDefenderElamDriverLoaded", value=true);
       ![type=="elamDriverLoaded", issuer=="AttestationPolicy"] => issue(type="WindowsDefenderElamDriverLoaded", value=false);
   
       // Boot debugging
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="bootDebuggingEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_BOOTDEBUGGING")));
       c:[type=="bootDebuggingEnabledSet", issuer=="AttestationPolicy"] => issue(type="bootDebuggingDisabled", value=ContainsOnlyValue(c.value, false));
       ![type=="bootDebuggingDisabled", issuer=="AttestationPolicy"] => issue(type="bootDebuggingDisabled", value=false);
   
       // Kernel Debugging
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="osKernelDebuggingEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_OSKERNELDEBUG")));
       c:[type=="osKernelDebuggingEnabledSet", issuer=="AttestationPolicy"] => issue(type="osKernelDebuggingDisabled", value=ContainsOnlyValue(c.value, false));
       ![type=="osKernelDebuggingDisabled", issuer=="AttestationPolicy"] => issue(type="osKernelDebuggingDisabled", value=false);
   
       // DEP Policy
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => issue(type="depPolicy", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_DATAEXECUTIONPREVENTION.Value | @[-1]")));
       ![type=="depPolicy"] => issue(type="depPolicy", value=0);
   
       // Test Signing
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="testSigningEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_TESTSIGNING")));
       c:[type=="testSigningEnabledSet", issuer=="AttestationPolicy"] => issue(type="testSigningDisabled", value=ContainsOnlyValue(c.value, false));
       ![type=="testSigningDisabled", issuer=="AttestationPolicy"] => issue(type="testSigningDisabled", value=false);
   
       // Flight Signing
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="flightSigningEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_FLIGHTSIGNING")));
       c:[type=="flightSigningEnabledSet", issuer=="AttestationPolicy"] => issue(type="flightSigningNotEnabled", value=ContainsOnlyValue(c.value, false));
       ![type=="flightSigningNotEnabled", issuer=="AttestationPolicy"] => issue(type="flightSigningNotEnabled", value=false);
   
       // VSM enabled
       c:[type=="events", issuer=="AttestationService"] => add(type="srtmDrtmEventPcr", value=JmesPath(c.value, "Events[? EventTypeString == 'EV_EVENT_TAG' && (PcrIndex == `12` || PcrIndex == `19`)].ProcessedData.EVENT_TRUSTBOUNDARY"));
       c:[type=="srtmDrtmEventPcr", issuer=="AttestationPolicy"] => add(type="vbsEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_VBS_VSM_REQUIRED")));
       c:[type=="srtmDrtmEventPcr", issuer=="AttestationPolicy"] => add(type="vbsEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_VBS_MANDATORY_ENFORCEMENT")));
       c:[type=="vbsEnabledSet", issuer=="AttestationPolicy"] => issue(type="vbsEnabled", value=ContainsOnlyValue(c.value, true));
       ![type=="vbsEnabled", issuer=="AttestationPolicy"] => issue(type="vbsEnabled", value=false);
       c:[type=="vbsEnabled", issuer=="AttestationPolicy"] => issue(type="vbsEnabled", value=c.value);
   
       // HVCI
       c:[type=="srtmDrtmEventPcr", issuer=="AttestationPolicy"] => add(type="hvciEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_VBS_HVCI_POLICY | @[?String == 'HypervisorEnforcedCodeIntegrityEnable'].Value")));
       c:[type=="hvciEnabledSet", issuer=="AttestationPolicy"] => issue(type="hvciEnabled", value=ContainsOnlyValue(c.value, 1));
       ![type=="hvciEnabled", issuer=="AttestationPolicy"] => issue(type="hvciEnabled", value=false);
   
       // IOMMU
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="iommuEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_VBS_IOMMU_REQUIRED")));
       c:[type=="iommuEnabledSet", issuer=="AttestationPolicy"] => issue(type="iommuEnabled", value=ContainsOnlyValue(c.value, true));
       ![type=="iommuEnabled", issuer=="AttestationPolicy"] => issue(type="iommuEnabled", value=false);
   
       // Find the Boot Manager SVN, this is measured as part of a sequence and find the various measurements
       // Find the first EV_SEPARATOR in PCR 12, 13, Or 14
       c:[type=="events", issuer=="AttestationService"] => add(type="evSeparatorSeq", value=JmesPath(c.value, "Events[? EventTypeString == 'EV_SEPARATOR' && (PcrIndex == `12` || PcrIndex == `13` || PcrIndex == `14`)] | @[0].EventSeq"));
       c:[type=="evSeparatorSeq", value != "null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value=AppendString(AppendString("Events[? EventSeq < `", c.value), "`"));
       [type=="evSeparatorSeq", value=="null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value="Events[? `true` ");
   
       // Find the first EVENT_APPLICATION_SVN.
       c:[type=="beforeEvSepClause", issuer=="AttestationPolicy"] => add(type="bootMgrSvnSeqQuery", value=AppendString(c.value, " && EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `12` && ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_APPLICATION_SVN] | @[0].EventSeq"));
       c1:[type=="bootMgrSvnSeqQuery", issuer=="AttestationPolicy"] && c2:[type=="events", issuer=="AttestationService"] => add(type="bootMgrSvnSeq", value=JmesPath(c2.value, c1.value));
       c:[type=="bootMgrSvnSeq", value!="null", issuer=="AttestationPolicy"] => add(type="bootMgrSvnQuery", value=AppendString(AppendString("Events[? EventSeq == `", c.value), "`].ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_APPLICATION_SVN | @[0]"));
   
       // The first EVENT_APPLICATION_SVN. That value is the Boot Manager SVN
       c1:[type=="bootMgrSvnQuery", issuer=="AttestationPolicy"] && c2:[type=="events", issuer=="AttestationService"] => issue(type="bootMgrSvn", value=JsonToClaimValue(JmesPath(c2.value, c1.value)));
   
       // OS Rev List Info
       c:[type=="events", issuer=="AttestationService"] => issue(type="osRevListInfo", value=JsonToClaimValue(JmesPath(c.value, "Events[? EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `13`].ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_OS_REVOCATION_LIST.RawData | @[0]")));
   
       // Safe mode
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="safeModeEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_SAFEMODE")));
       c:[type=="safeModeEnabledSet", issuer=="AttestationPolicy"] => issue(type="notSafeMode", value=ContainsOnlyValue(c.value, false));
       ![type=="notSafeMode", issuer=="AttestationPolicy"] => issue(type="notSafeMode", value=true);
   
       // Win PE
       c:[type=="boolProperties", issuer=="AttestationPolicy"] => add(type="winPEEnabledSet", value=JsonToClaimValue(JmesPath(c.value, "[*].EVENT_WINPE")));
       c:[type=="winPEEnabledSet", issuer=="AttestationPolicy"] => issue(type="notWinPE", value=ContainsOnlyValue(c.value, false));
       ![type=="notWinPE", issuer=="AttestationPolicy"] => issue(type="notWinPE", value=true);
   
       // CI Policy
       c:[type=="events", issuer=="AttestationService"] => issue(type="codeIntegrityPolicy", value=JsonToClaimValue(JmesPath(c.value, "Events[? EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `13`].ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_SI_POLICY[].RawData")));
   
       // Secure Boot Custom Policy
       c:[type=="events", issuer=="AttestationService"] => issue(type="secureBootCustomPolicy", value=JsonToClaimValue(JmesPath(c.value, "Events[? EventTypeString == 'EV_EFI_VARIABLE_DRIVER_CONFIG' && PcrIndex == `7` && ProcessedData.UnicodeName == 'CurrentPolicy' && ProcessedData.VariableGuid == '77FA9ABD-0359-4D32-BD60-28F4E78F784B'].ProcessedData.VariableData | @[0]")));
   
       // Find the first EV_SEPARATOR in PCR 12, 13, Or 14
       c:[type=="events", issuer=="AttestationService"] => add(type="evSeparatorSeq", value=JmesPath(c.value, "Events[? EventTypeString == 'EV_SEPARATOR' && (PcrIndex == `12` || PcrIndex == `13` || PcrIndex == `14`)] | @[0].EventSeq"));
       c:[type=="evSeparatorSeq", value != "null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value=AppendString(AppendString("Events[? EventSeq < `", c.value), "`"));
       [type=="evSeparatorSeq", value=="null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value="Events[? `true` "); // No restriction of EV_SEPARATOR in case it's not present
   
       //Finding the Boot App SVN
       // Find the first EVENT_TRANSFER_CONTROL with value 1 or 2 in PCR 12 which is before the EV_SEPARATOR
       c1:[type=="beforeEvSepClause", issuer=="AttestationPolicy"] && c2:[type=="bootMgrSvnSeq", value != "null", issuer=="AttestationPolicy"] => add(type="beforeEvSepAfterBootMgrSvnClause", value=AppendString(AppendString(AppendString(c1.value, "&& EventSeq >= `"), c2.value), "`"));
       c:[type=="beforeEvSepAfterBootMgrSvnClause", issuer=="AttestationPolicy"] => add(type="tranferControlQuery", value=AppendString(c.value, " && EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `12`&& (ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_TRANSFER_CONTROL.Value == `1` || ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_TRANSFER_CONTROL.Value == `2`)] | @[0].EventSeq"));
       c1:[type=="tranferControlQuery", issuer=="AttestationPolicy"] && c2:[type=="events", issuer=="AttestationService"] => add(type="tranferControlSeq", value=JmesPath(c2.value, c1.value));
   
       // Find the first non-null EVENT_MODULE_SVN in PCR 13 after the transfer control.
       c:[type=="tranferControlSeq", value!="null", issuer=="AttestationPolicy"] => add(type="afterTransferCtrlClause", value=AppendString(AppendString(" && EventSeq > `", c.value), "`"));
       c1:[type=="beforeEvSepClause", issuer=="AttestationPolicy"] && c2:[type=="afterTransferCtrlClause", issuer=="AttestationPolicy"] => add(type="moduleQuery", value=AppendString(AppendString(c1.value, c2.value), " && EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `13` && ((ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_LOADEDMODULE_AGGREGATION[].EVENT_MODULE_SVN | @[0]) || (ProcessedData.EVENT_LOADEDMODULE_AGGREGATION[].EVENT_MODULE_SVN | @[0]))].EventSeq | @[0]"));
       c1:[type=="moduleQuery", issuer=="AttestationPolicy"] && c2:[type=="events", issuer=="AttestationService"] => add(type="moduleSeq", value=JmesPath(c2.value, c1.value));
   
       // Find the first EVENT_APPLICATION_SVN after EV_EVENT_TAG in PCR 12.
       c:[type=="moduleSeq", value!="null", issuer=="AttestationPolicy"] => add(type="applicationSvnAfterModuleClause", value=AppendString(AppendString(" && EventSeq > `", c.value), "`"));
       c1:[type=="beforeEvSepClause", issuer=="AttestationPolicy"] && c2:[type=="applicationSvnAfterModuleClause", issuer=="AttestationPolicy"] => add(type="bootAppSvnQuery", value=AppendString(AppendString(c1.value, c2.value), " && EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `12`].ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_APPLICATION_SVN | @[0]"));
       c1:[type=="bootAppSvnQuery", issuer=="AttestationPolicy"] && c2:[type=="events", issuer=="AttestationService"] => issue(type="bootAppSvn", value=JsonToClaimValue(JmesPath(c2.value, c1.value)));
   
       // Finding the Boot Rev List Info
       c:[type=="events", issuer=="AttestationService"] => issue(type="bootRevListInfo", value=JsonToClaimValue(JmesPath(c.value, "Events[? EventTypeString == 'EV_EVENT_TAG' && PcrIndex == `13`].ProcessedData.EVENT_TRUSTBOUNDARY.EVENT_BOOT_REVOCATION_LIST.RawData | @[0]")));
   
   };
   

3. Rufen Sie TriggerAttestation mit Ihrem rpidauf, Azure Active Directory token und attestURI: Verwenden Sie die in Schritt 1 generierte Nachweis-URL, und fügen Sie die entsprechende API-Version an, die Sie erreichen möchten. Weitere Informationen zur API-Version finden Sie unter Attestation – Attestation – Attest tpm – REST API.

4. Rufen Sie GetAttestReport auf, decodieren und analysieren Sie den Bericht, um sicherzustellen, dass der attestierte Bericht die erforderlichen Eigenschaften enthält: GetAttestReport gibt das signierte Nachweistoken als JWT zurück. Das JWT kann decodiert werden, um die Informationen gemäß der Nachweisrichtlinie zu analysieren.

       {
         "typ": "JWT",
         "alg": "RS256",
         "x5c": [
           "MIIE.....=",
           "MIIG.....=",
           "MIIF.....="
         ],
         "kid": "8FUer20z6wzf1rod044wOAFdjsg"
       }.{
         "nbf": 1633664812,
         "exp": 1634010712,
         "iat": 1633665112,
         "iss": "https://contosopolicy.eus.attest.azure.net",
         "jti": "2b63663acbcafefa004d20969991c0b1f063c9be",
         "ver": "1.0",
         "x-ms-ver": "1.0",
         "rp_data": "AQIDBA",
         "nonce": "AQIDBA",
         "cnf": {
           "jwk": {
             "kty": "RSA",
             "n": "yZGC3-1rFZBt6n6vRHjRjvrOYlH69TftIQWOXiEHz__viQ_Z3qxWVa4TfrUxiQyDQnxJ8-f8tBRmlunMdFDIQWhnew_rc3-UYMUPNcTQ0IkrLBDG6qDjFFeEAMbn8gqr0rRWu_Qt7Cb_Cq1upoEBkv0RXk8yR6JXmFIvLuSdewGs-xCWlHhd5w3n1rVk0hjtRk9ZErlbPXt74E5l-ZZQUIyeYEZ1FmbivOIL-2f6NnKJ-cR4cdhEU8i9CH1YV0r578ry89nGvBJ5u4_3Ib9Ragdmxm259npH53hpnwf0I6V-_ZhGPyF6LBVUG_7x4CyxuHCU20uI0vXKXJNlbj1wsQ",
             "e": "AQAB"
           }
         },
         "x-ms-policy-hash": "GiGQCTOylCohHt4rd3pEppD9arh5mXC3ifF1m1hONh0",
         "WindowsDefenderElamDriverLoaded": true,
         "bitlockerEnabled": true,
         "bitlockerEnabledValue": 4,
         "bootAppSvn": 1,
         "bootDebuggingDisabled": true,
         "bootMgrSvn": 1,
         "bootRevListInfo": "gHWqR2F-1wEgAAAACwBxrZXHbaiuTuO0PSaJ7WQMF8yz37Z2ATgSNTTlRkwcTw",
         "codeIntegrityEnabled": true,
         "codeIntegrityPolicy": [
           "AAABAAAAAQBWAAsAIAAAAHsAOABmAGIANAA4ADYANQBlAC0AZQA5ADAAYgAtADQANAA0AGYALQBiADUAYgA1AC0AZQAyAGEAYQA1ADEAZAA4ADkAMABmAGQAfQAuAEMASQBQAAAAVnW86ERqAg5n9QT1UKFr-bOP2AlNtBaaHXjZODnNLlk", "AAAAAAAACgBWAAsAIAAAAHsAYgBjADQAYgBmADYAZAA3AC0AYwBjADYAMAAtADQAMABmADAALQA4ADYANAA0AC0AMQBlADYANAA5ADEANgBmADgAMQA4ADMAfQAuAEMASQBQAAAAQ7vOXuAbBRIMglSSg7g_LHNeHoR4GrY-M-2W5MNvf0o", "AAAAAAAACgBWAAsAIAAAAHsAYgAzADEAOAA5ADkAOQBhAC0AYgAxADMAZQAtADQANAA3ADUALQBiAGMAZgBkAC0AMQBiADEANgBlADMAMABlADYAMAAzADAAfQAuAEMASQBQAAAALTmwU3eadNtg0GyAyKIAkYed127RJCSgmfFmO1jN_aI", "AAAAAAAACgBWAAsAIAAAAHsAZgBlADgAMgBkADUAOAA5AC0ANwA3AGQAMQAtADQAYwA3ADYALQA5AGEANABhAC0AZQA0ADUANQA0ADYAOAA4ADkANAAxAGIAfQAuAEMASQBQAAAA8HGUwA85gHN_ThItTYtu6sw657gVuOb4fOhYl-YJRoc", "AACRVwAACgAmAAsAIAAAAEQAcgBpAHYAZQByAFMAaQBQAG8AbABpAGMAeQAuAHAANwBiAAAAYcVuY0HdW4Iqr5B-6Sl85kwIXRG9bqr43pVhkirg4qM"
         ],
         "depPolicy": 0,
         "flightSigningNotEnabled": false,
         "hvciEnabled": true,
         "iommuEnabled": true,
         "notSafeMode": true,
         "notWinPE": true,
         "osKernelDebuggingDisabled": true,
         "osRevListInfo": "gHLuW2F-1wEgAAAACwDLyDTUQILjdz_RfNlShVgNYT9EghL7ceMReWg9TuwdKA",
         "secureBootEnabled": true,
         "testSigningDisabled": true,
         "vbsEnabled": true
       }.[Signature]
   

Weitere Informationen

Weitere Informationen zum TPM-Nachweis finden Sie hier: Microsoft Azure Attestation.

Windows 10 Device HealthAttestation

Verwendete Begriffe:

• TPM (Trusted Platform Module): TPM ist eine spezielle hardwaregeschützte Logik, die eine Reihe von hardwaregeschützten Sicherheitsvorgängen ausführt, einschließlich der Bereitstellung von geschütztem Speicher, Zufälliger Zahlengenerierung, Verschlüsselung und Signierung.

• DHA-Feature (Device HealthAttestation): Das Feature Device HealthAttestation (DHA) ermöglicht IT-Administratoren im Unternehmen die Remoteüberwachung des Sicherheitsstatus verwalteter Geräte mithilfe von hardwaregeschützten und bestätigten Daten (TPM) über einen manipulationssicheren und manipulationssicheren Kommunikationskanal.

• DHA-fähiges Gerät (Device HealthAttestation-fähiges Gerät): Ein Gerät mit aktivierter Integritätsstation (DHA-fähig) ist ein Computergerät (Telefon, Desktop, Laptop, Tablet, Server), das Windows 10 ausführt und TPM-Version 1.2 oder 2.0 unterstützt.

• DHA-Session (Device HealthAttestation-Sitzung):Die Sitzung Device HealthAttestation (DHA-Session) beschreibt den End-to-End-Kommunikationsfluss, der in einer Sitzung zum Nachweis der Geräteintegrität ausgeführt wird. Die folgende Liste der Transaktionen wird in einer DHA-Sitzung ausgeführt:

  

  • DHA-CSP und DHA-Service Kommunikation:
    • DHA-CSP leitet Gerätestartdaten (DHA-BootData) an DHA-Service
    • DHA-Service Antworten mit einem verschlüsselten Datenblob (DHA-EncBlob)
  • DHA-CSP und MDM-Server Kommunikation:
    • MDM-Server sendet eine Anforderung zur Überprüfung der Geräteintegrität an DHA-CSP.
    • DHA-CSP antwortet mit einer Nutzlast namens DHA-Data, die ein verschlüsseltes (DHA-EncBlob) und ein signiertes Datenblob (DHA-SignedBlob) enthält.
  • MDM-Server und DHA-Service Kommunikation:
    • MDM-Server postet Daten, die von Geräten empfangen werden, in DHA-Service
    • DHA-Service überprüft die empfangenen Daten und antwortet mit einem Geräteintegritätsbericht (DHA-Report)

• DHA-Sitzungsdaten (Device HealthAttestation-Sitzungsdaten): Die folgende Liste der Daten wird in einer DHA-Transaktion erzeugt oder genutzt:

  • DHA-BootData: Die Gerätestartdaten (TCG-Protokolle, PCR-Werte, Geräte-/TPM-Zertifikat, Start und TPM-Leistungsindikatoren), die für die Überprüfung der Integrität des Gerätestarts erforderlich sind.
  • DHA-EncBlob: Ein verschlüsselter Zusammenfassender Bericht, der Probleme auf einem Gerät DHA-Service, nachdem die DHA-BootData überprüft wurden, die es von Geräten erhält.
  • DHA-SignedBlob: Es handelt sich um einen signierten Momentaufnahme des aktuellen Zustands der Laufzeit eines Geräts, der von DHA-CSP zum Zeitpunkt des Geräteintegritätsnachweises erfasst wird.
  • DHA-Data: Ein XML-formatiertes Datenblob, das Geräte zur Überprüfung der Geräteintegrität über MDM-Server an DHA-Service weiterleiten. DHA-Data umfasst zwei Teile:
    • DHA-EncBlob: Das verschlüsselte Datenblob, das das Gerät von DHA-Service
    • DHA-SignedBlob: eine aktuelle Momentaufnahme des aktuellen Sicherheitsstatus des Geräts, das von DHA-CSP generiert wird
  • DHA-Report: Der Bericht, der von DHA-Service an MDM-Server
  • Nonce: eine kryptografisch geschützte Nummer, die von MDM-Server generiert wird und die DHA-Session vor Man-in-the-Middle-Angriffen schützt

• DHA-fähige MDM-Lösung (Device HealthAttestation-fähige Geräteverwaltungslösung): Die Geräteverwaltungslösung device HealthAttestation enabled (DHA-Enabled) ist ein Geräteverwaltungstool, das in das DHA-Feature integriert ist. DHA-Enabled Lösungen für die Geräteverwaltung ermöglichen IT-Managern von Unternehmen, die Sicherheitsschutzleiste für ihre verwalteten Geräte basierend auf hardwaregeschützten Daten (TPM) zu erhöhen, die auch dann vertrauenswürdig sind, wenn ein Gerät durch erweiterte Sicherheitsbedrohungen kompromittiert wird oder ein böswilliges Betriebssystem (jailbreakken) ausgeführt wird. Die folgende Liste der Vorgänge wird von DHA-Enabled-MDM ausgeführt:

  • Aktiviert das DHA-Feature auf einem DHA-Enabled Gerät
  • Stellt Anforderungen zum Nachweis der Geräteintegrität an registrierte/verwaltete Geräte aus
  • Erfasst Daten zum Nachweis der Geräteintegrität (DHA-Data) und sendet sie zur Überprüfung an den Device Health Attestation Service (DHA-Service).
  • Ruft den Geräteintegritätsbericht (DHA-Report) von DHA-Service ab, der eine Konformitätsaktion auslöst.

• DHA-CSP (Device HealthAttestation Configuration Service Provider): Der Device HealthAttestation Configuration Service Provider (DHA-CSP) verwendet das TPM und die Firmware eines Geräts, um kritische Sicherheitseigenschaften des BIOS und des Windows-Starts des Geräts zu messen, sodass diese Eigenschaften selbst auf einem System, das mit Schadsoftware auf Kernelebene oder rootkit infiziert ist, nicht spooft werden können. Die folgende Liste der Vorgänge wird von DHA-CSP ausgeführt:

  • Erfasst Gerätestartdaten (DHA-BootData) von einem verwalteten Gerät
  • Leitet DHA-BootData an den Device Health Attestation Service (DHA-Service) weiter.
  • Empfängt ein verschlüsseltes Blob (DHA-EncBlob) von DHA-Service und speichert es in einem lokalen Cache auf dem Gerät.
  • Empfängt Nachweisanforderungen (DHA-Requests) von einem DHA-Enabled MDM und antwortet mit Geräteintegritätsnachweisdaten (DHA-Data)

• DHA-Service (Device HealthAttestation Service): Device HealthAttestation Service (DHA-Service) überprüft die von DHA-CSP empfangenen Daten und gibt einen hoch vertrauenswürdigen Hardwarebericht (DHA-Report) an DHA-Enabled Geräteverwaltungslösungen über einen manipulationssicheren und manipulationssicheren Kommunikationskanal aus. DHA-Service ist in zwei Varianten erhältlich: "DHA-Cloud" und "DHA-Server2016". DHA-Service unterstützt verschiedene Implementierungsszenarien, einschließlich Cloud-, lokal-, Air-Gap- und Hybridszenarien. Die folgende Liste der Vorgänge wird von DHA-Service ausgeführt:

  • Empfängt Gerätestartdaten (DHA-BootData) von einem DHA-Enabled Gerät
  • Leitet DHA-BootData an den Device Health Attestation Service (DHA-Service) weiter.
  • Empfängt ein verschlüsseltes Blob (DHA-EncBlob) von DHA-Service und speichert es in einem lokalen Cache auf dem Gerät.
  • Empfängt Nachweisanforderungen (DHA-Requests) von einem DHA-Enabled-MDM und antwortet mit einem Geräteintegritätsbericht (DHA-Report)

DHA-Service Typ	Beschreibung	Betriebskosten
Geräteintegritätsnachweis – Cloud (DHA-Cloud)	DHA-Cloud ist ein im Besitz von Microsoft befindlicher und betriebener DHA-Service, der folgendes ist: Kostenlos in Windows verfügbar Ausführung in einer Cloudinfrastruktur mit hoher Verfügbarkeit und geobalanciertem Gleichgewicht Unterstützt von den meisten DHA-Enabled Geräteverwaltungslösungen als Standardanbieter für den Gerätenachweis Zugriff auf alle unternehmensverwalteten Geräte über folgendes: FQDN = has.spserv.microsoft.com Port Port = 443 Protokoll = TCP	Keine Kosten
Geräteintegritätsnachweis – Lokal (DHA-OnPrem)	DHA-OnPrem bezieht sich auf DHA-Service, die lokal ausgeführt werden: Angeboten für Windows Server 2016 Kunden (keine zusätzlichen Lizenzkosten für die Aktivierung/Ausführung des DHA-Diensts) Gehostet auf einem unternehmenseigenen und verwalteten Servergerät/-hardware Unterstützt von drittanbietern DHA-Enabled Lösungsanbietern für die Geräteverwaltung, die lokale und hybride Hardwarenachweisszenarien (Cloud + OnPrem) unterstützen Zugriff für alle unternehmensverwalteten Geräte über die folgenden Einstellungen: FQDN = (enterprise assigned) Port = (enterprise assigned) Protokoll = TCP	Die Betriebskosten für die lokale Ausführung einer oder mehrerer Instanzen von Server 2016.
Geräteintegritätsnachweis – Enterprise-Managed Cloud (DHA-EMC)	DHA-EMC bezieht sich auf eine unternehmensseitig verwaltete DHA-Service, die als virtueller Host/Dienst auf einem Windows Server 2016 kompatibel ausgeführt wird – unternehmensseitig verwalteter Clouddienst wie Microsoft Azure. Angeboten für Windows Server 2016 Kunden ohne zusätzliche Lizenzierungskosten (keine zusätzlichen Lizenzkosten für die Aktivierung/Ausführung des DHA-Diensts) Unterstützt von drittanbietern DHA-Enabled Lösungsanbietern für die Geräteverwaltung, die lokale und hybride Hardwarenachweisszenarien (Cloud + OnPrem) unterstützen Zugriff für alle unternehmensverwalteten Geräte über die folgenden Einstellungen: FQDN = (enterprise assigned) Port = (enterprise assigned) Protokoll = TCP	Die Betriebskosten für die Ausführung von Server 2016 in einem kompatiblen Clouddienst, z. B. Microsoft Azure.

DHA-CSP-Integrationsschritte

Die folgende Liste der Validierungs- und Entwicklungsaufgaben ist für die Integration des Microsoft Device Health Attestation-Features in eine Windows Mobile-Geräteverwaltungslösung (MDM) erforderlich:

1. Überprüfen des HTTPS-Zugriffs
2. Zuweisen eines vertrauenswürdigen DHA-Diensts im Unternehmen
3. Weisen Sie den Client an, DHA-Daten für die Überprüfung vorzubereiten.
4. Ausführen einer Aktion basierend auf der Clientantwort
5. Weisen Sie den Client an, DHA-Daten zur Überprüfung weiterzuleiten.
6. Post DHA-data to DHA-service
7. Empfangen einer Antwort vom DHA-Dienst
8. Analysieren DHA-Report Daten. Ergreifen geeigneter Richtlinienaktionen basierend auf auswertungsergebnissen

Jeder Schritt wird in den folgenden Abschnitten dieses Themas ausführlich beschrieben.

Schritt 1: Überprüfen des HTTPS-Zugriffs

Überprüfen Sie, ob sowohl der MDM-Server als auch das Gerät (MDM-Client) mithilfe des TCP-Protokolls über Port 443 (HTTPS) auf has.spserv.microsoft.com zugreifen können.

Sie können OpenSSL verwenden, um den Zugriff auf den DHA-Service zu überprüfen. Hier sehen Sie einen OpenSSL-Beispielbefehl und die Antwort, die von DHA-Service generiert wurde:

PS C:\openssl> ./openssl.exe s_client -connect has.spserv.microsoft.com:443
CONNECTED(000001A8)
---
Certificate chain
 0 s:/CN=*.spserv.microsoft.com
   i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
 1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGOTCCBCGgAwIBAgITWgAA1KJb40tpukQoewABAADUojANBgkqhkiG9w0BAQsFA4ICAQCJaKewFQuqQwR5fkAr9kZOmtq5fk03p82eHWLaftXlc4RDvVFp4a2ciSjZL8f3f+XWPVdUj9DAi3bCSddlrcNOPRXNepFC1OEmKtE9jM0r7M8qnqFkIfbNrVNUtPxHoraQeMIgbk0SHEOlShY2GXETVBqZdDZ5Rmk4rA+3ggoeV8hNzm2dfNp0iGSrZzawbLzWU1D2Tped1k5IV63yb+cU/TmM ……………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………………………
……………2RXXwogn1UM8TZduCEjz+b05mAkvytugzzaI4wXkCP4OgNyy8gul2z5Gj/51pCTN
-----END CERTIFICATE-----
subject=/CN=*.spserv.microsoft.com
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
---
No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3681 bytes and written 561 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol: TLSv1.2
    Cipher: ECDHE-RSA-AES256-SHA384
    Session-ID: B22300009621370F84A4A3A7D9FC40D584E047C090604E5226083A02ED239C93
    Session-ID-ctx:
    Master-Key: 9E3F6BE5B3D3B55C070470CA2B62EF59CC1D5ED9187EF5B3D1BBF4C101EE90BEB04F34FFD748A13C92A387104B8D1DE7
    Key-Arg: None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432078420
    Timeout: 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

Schritt 2: Zuweisen eines vertrauenswürdigen unternehmensweiten DHA-Service

Es gibt drei Arten von DHA-Service:

• Device Health Attestation – Cloud (im Besitz und betrieben von Microsoft)
• Device Health Attestation – On Premise (im Besitz und betrieben von einem Unternehmen, wird auf Windows Server 2016 lokal ausgeführt)
• Device Health Attestation – Enterprise-Managed Cloud (im Besitz eines Unternehmens und betrieben von diesem, wird in Windows Server 2016 kompatiblen unternehmensverwalteten Cloud ausgeführt)

DHA-Cloud ist die Standardeinstellung. Wenn ein Unternehmen plant, Microsoft DHA-Cloud als vertrauenswürdigen DHA-Service anbieter zu verwenden, ist keine weitere Aktion erforderlich.

Senden Sie für DHA-OnPrem & DHA-EMC-Szenarien einen SyncML-Befehl an den HASEndpoint-Knoten, um ein verwaltetes Gerät anzuweisen, mit dem vertrauenswürdigen DHA-Service des Unternehmens zu kommunizieren.

Das folgende Beispiel zeigt einen Beispielaufruf, der ein verwaltetes Gerät anweist, mit einem unternehmensverwalteten DHA-Dienst zu kommunizieren.

<Replace>
    <CmdID>1</CmdID>
    <Item>
      <Target>
          <LocURI>./Vendor/MSFT/HealthAttestation/HASEndpoint</LocURI>
      </Target>
      <Data> www.ContosoDHA-Service</Data>
    </Item>
</Replace>

Schritt 3: Anweisen des Clients, Integritätsdaten für die Überprüfung vorzubereiten

Senden Sie einen SyncML-Aufruf, um die Sammlung der DHA-Daten zu starten.

Das folgende Beispiel zeigt einen Beispielaufruf, der die Sammlung und Überprüfung von Integritätsnachweisdaten von einem verwalteten Gerät auslöst.

<Exec>
    <CmdID>1</CmdID>
    <Item>
      <Target>
          <LocURI>./Vendor/MSFT/HealthAttestation/VerifyHealth</LocURI>
      </Target>
    </Item>
</Exec>

<Get>
    <CmdID>2</CmdID>
    <Item>
      <Target>
          <LocURI>./Vendor/MSFT/HealthAttestation/Status</LocURI>
      </Target>
    </Item>
</Get>

Schritt 4: Ausführen einer Aktion basierend auf der Antwort des Clients

Nachdem der Client die Integritätsnachweisanforderung empfangen hat, sendet er eine Antwort. In der folgenden Liste werden die Antworten zusammen mit einer empfohlenen Aktion beschrieben.

• Wenn die Antwort HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE (3) lautet, fahren Sie mit dem nächsten Abschnitt fort.
• Wenn die Antwort HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) oder HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) lautet, warten Sie auf eine Warnung, fahren Sie mit dem nächsten Abschnitt fort.

Hier sehen Sie eine Beispielwarnung, die von DHA_CSP ausgegeben wird:

<Alert>
    <CmdID>1</CmdID>
    <Data>1226</Data>
    <Item>
        <Source>
            <LocURI>./Vendor/MSFT/HealthAttestation/VerifyHealth</LocURI>
        </Source>
        <Meta>
            <Type xmlns="syncml:metinf">com.microsoft.mdm:HealthAttestation.Result</Type>
            <Format xmlns="syncml:metinf">int</Format>
        </Meta>
        <Data>3</Data>
    </Item>
</Alert>

• Wenn die Antwort auf den status Knoten nicht 0, 1 oder 3 lautet, beheben Sie das Problem. Eine vollständige Liste der status Codes finden Sie unter HealthAttestation CSP status und Fehlercodes.

Schritt 5: Weisen Sie den Client an, Integritätsnachweisdaten zur Überprüfung weiterzuleiten.

Erstellen Sie einen Aufruf der Knoten Nonce, Certificate und CorrelationId , und rufen Sie eine verschlüsselte Nutzlast ab, die ein Integritätszertifikat und zugehörige Daten vom Gerät enthält.

Beispiel:

<Replace>
    <CmdID>1</CmdID>
    <Item>
        <Target>
            <LocURI>./Vendor/MSFT/HealthAttestation/Nonce</LocURI>
        </Target>
        <Data>AAAAAAAAAFFFFFFF</Data>
    </Item>
</Replace>

<Get>
    <CmdID>2</CmdID>
    <Item>
        <Target>
            <LocURI>./Vendor/MSFT/HealthAttestation/Certificate</LocURI>
        </Target>
    </Item>
</Get>

<Get>
    <CmdID>3</CmdID>
    <Item>
        <Target>
            <LocURI>./Vendor/MSFT/HealthAttestation/CorrelationId </LocURI>
        </Target>
    </Item>
</Get>

Schritt 6: Weiterleiten von Daten zum Nachweis der Geräteintegrität an den DHA-Dienst

Als Reaktion auf die Anforderung, die im vorherigen Schritt gesendet wurde, leitet der MDM-Client ein XML-formatiertes Blob (Antwort vom Knoten ./Vendor/MSFT/HealthAttestation/Certificate) und einen Aufrufbezeichner namens CorrelationId (Antwort auf den Knoten ./Vendor/MSFT/HealthAttestation/CorrelationId) weiter.

Wenn der MDM-Server die oben genannten Daten empfängt, muss folgendes erforderlich sein:

• Protokollieren Sie die CorrelationId, die es vom Gerät empfängt (für zukünftige Problembehandlung/Referenz), die mit dem Aufruf korreliert ist.

• Decodieren des XML-formatierten Datenblobs, das vom Gerät empfangen wird

• Fügen Sie die vom MDM-Dienst generierte Nonce (fügen Sie die Nonce hinzu, die in Schritt 5 an das Gerät weitergeleitet wurde) an die XML-Struktur, die vom Gerät im folgenden Format weitergeleitet wurde:

  <?xml version='1.0' encoding='utf-8' ?>
  <HealthCertificateValidationRequest ProtocolVersion='1' xmlns='http://schemas.microsoft.com/windows/security/healthcertificate/validation/request/v1'>
      <Nonce>[INT]</Nonce>
      <Claims> [base64 blob, eg ‘ABc123+/…==’] </Claims>
      <HealthCertificateBlob> [base64 blob, eg ‘ABc123+/...==’]
      </HealthCertificateBlob>
  </HealthCertificateValidationRequest>
  

• Weiterleiten (HTTP Post) der XML-Datenstruktur (einschließlich der Nonce, die im vorherigen Schritt angefügt wurde) an die zugewiesene DHA-Service, die ausgeführt wird:

  • DHA-Cloud Szenario (microsofteigener und betriebener DHA-Service): https://has.spserv.microsoft.com/DeviceHealthAttestation/ValidateHealthCertificate/v3
  • DHA-OnPrem oder DHA-EMC: https://FullyQualifiedDomainName-FDQN/DeviceHealthAttestation/ValidateHealthCertificate/v3

Schritt 7: Empfangen einer Antwort vom DHA-Dienst

Wenn der Microsoft Device Health Attestation Service eine Anforderung zur Überprüfung empfängt, führt er die folgenden Schritte aus:

• Entschlüsselt die empfangenen verschlüsselten Daten.
• Überprüft die empfangenen Daten.
• Erstellt einen Bericht und gibt die Auswertungsergebnisse über SSL im XML-Format für den MDM-Server frei.

Schritt 8: Ergreifen geeigneter Richtlinienaktionen basierend auf den Auswertungsergebnissen

Nachdem der MDM-Server die überprüften Daten empfangen hat, können die Informationen verwendet werden, um Richtlinienentscheidungen zu treffen, indem die Daten ausgewertet werden. Einige mögliche Aktionen wären:

• Lassen Sie den Zugriff auf das Gerät zu.
• Lassen Sie dem Gerät den Zugriff auf die Ressourcen zu, kennzeichnen Sie das Gerät jedoch zur weiteren Untersuchung.
• Verhindern, dass ein Gerät auf Ressourcen zugreift.

DHA-Report V3-Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3"
           targetNamespace="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3"
           elementFormDefault="qualified">

    <xs:element name="HealthCertificateValidationResponse" type="HealthCertificateValidationResponse_T"/>
    <xs:complexType name="ResponseCommon_T">
        <xs:attribute name="ErrorCode" type="xs:int" use="required"/>
        <xs:attribute name="ErrorMessage" type="xs:string" use="required"/>
        <xs:attribute name="ProtocolVersion" use="required">
          <xs:simpleType>
            <xs:restriction base="xs:int">
              <xs:minInclusive value="3"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>
    </xs:complexType>
    <xs:complexType name="HealthCertificatePublicProperties_T">
        <xs:annotation>
            <xs:documentation>Health certificate non machine identifiable properties </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="Issued"                       type="xs:dateTime"/>
            <xs:element name="AIKPresent"                   type="Boolean_T" />
            <xs:element name="ResetCount"                   type="xs:unsignedInt"/>
            <xs:element name="RestartCount"                 type="xs:unsignedInt"/>
            <xs:element name="DEPPolicy"                    type="xs:unsignedInt"/>
            <xs:element name="BitlockerStatus"              type="xs:unsignedInt"/>
            <xs:element name="BootManagerRevListVersion"    type="xs:unsignedInt"/>
            <xs:element name="CodeIntegrityRevListVersion"  type="xs:unsignedInt"/>
            <xs:element name="SecureBootEnabled"            type="Boolean_T"/>
            <xs:element name="BootDebuggingEnabled"         type="Boolean_T"/>
            <xs:element name="OSKernelDebuggingEnabled"     type="Boolean_T"/>
            <xs:element name="CodeIntegrityEnabled"         type="Boolean_T"/>
            <xs:element name="TestSigningEnabled"           type="Boolean_T"/>
            <xs:element name="SafeMode"                     type="Boolean_T"/>
            <xs:element name="WinPE"                        type="Boolean_T"/>
            <xs:element name="ELAMDriverLoaded"             type="Boolean_T"/>
            <xs:element name="VSMEnabled"                   type="Boolean_T"/>
            <xs:element name="PCRHashAlgorithmID"           type="xs:unsignedInt"/>
            <xs:element name="BootAppSVN"                   type="xs:unsignedInt"/>
            <xs:element name="BootManagerSVN"               type="xs:unsignedInt"/>
            <xs:element name="TpmVersion"                   type="xs:unsignedInt"/>
            <xs:element name="PCR0"                         type="xs:hexBinary"/>
            <xs:element name="CIPolicy"                     type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>
            <xs:element name="SBCPHash"                     type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>
            <xs:element name="BootRevListInfo"              type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>
            <xs:element name="OSRevListInfo"                type="xs:hexBinary" minOccurs ="0" maxOccurs ="1"/>

          <!--
<xs:element name="PCRCount"                     type="xs:unsignedInt"/>
<xs:element name="PCRSize"                      type="xs:unsignedShort"/>
<xs:element name="PCRHashAlgorithmID"           type="xs:unsignedShort"/>

<xs:element name="PCR"                          type="xs:hexBinary"/>
            -->
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="HealthStatusMismatchFlags_T">
        <xs:annotation>
            <xs:documentation>If there's a status mismatch, these flags will be set</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <!-- Hibernate/Resume count -->
            <xs:element name="ResumeCount"                   type="Boolean_T"/>
            <!-- Reboot count -->
            <xs:element name="RebootCount"                   type="Boolean_T"/>
            <xs:element name="PCR"                           type="Boolean_T"/>
            <xs:element name="BootAppSVN"                   type="Boolean_T"/>
            <xs:element name="BootManagerSVNChain"           type="Boolean_T"/>
            <xs:element name="BootAppSVNChain"              type="Boolean_T"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="HealthCertificateValidationResponse_T" >
        <xs:annotation>
            <xs:documentation>Health certificate validation response </xs:documentation>
        </xs:annotation>
        <xs:complexContent>
            <xs:extension base="ResponseCommon_T">
<xs:sequence>
    <!--Optional element, present only when the certificate can be verified and decrypted-->
    <xs:element name="HealthCertificateProperties"  type="HealthCertificatePublicProperties_T"  minOccurs="0"/>
    <!--Optional element, present only when the reason for a validation failure is a mismatch between the
                    current health state and the certificate health state-->
    <xs:element name="HealthStatusMismatchFlags"       type="HealthStatusMismatchFlags_T"             minOccurs="0"/>
</xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:simpleType name="Boolean_T">
        <xs:restriction base="xs:boolean">
            <xs:pattern value="true|false"/>
        </xs:restriction>
    </xs:simpleType>
</xs:schema>

Die folgende Liste der Datenpunkte wird vom DHA-Service in DHA-Report Version 3 überprüft.

• Ausgestellt: Datum und Uhrzeit der Auswertung oder Ausgabe des DHA-Berichts an MDM.

• AIKPresent: Wenn ein Nachweisidentitätsschlüssel (Attestation Identity Key, AIK) auf einem Gerät vorhanden ist, gibt dies an, dass das Gerät über ein Endorsement Key (EK)-Zertifikat verfügt. Es kann mehr als ein Gerät vertrauenswürdig sein, das kein EK-Zertifikat hat.

  Wenn AIKPresent = True (1) ist, lassen Sie den Zugriff zu.

  Wenn AIKPresent = False (0) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Zulassen des bedingten Zugriffs basierend auf anderen Datenpunkten, die zur Auswertungszeit vorhanden sind. Beispielsweise andere Attribute im Integritätszertifikat oder die vergangenen Aktivitäten und den Vertrauensverlauf eines Geräts.
  • Führen Sie eine der vorherigen Aktionen aus, und platzieren Sie das Gerät zusätzlich in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

• ResetCount (Nur für Geräte gemeldet, die TPM 2.0 unterstützen): Dieses Attribut gibt an, wie oft ein PC-Gerät in den Ruhezustand versetzt oder fortgesetzt wurde.

• RestartCount (Nur für Geräte gemeldet, die TPM 2.0 unterstützen): Dieses Attribut gibt an, wie oft ein PC-Gerät neu gestartet wurde.

• DEPPolicy: Ein Gerät kann mehr vertrauenswürdig sein, wenn die DEP-Richtlinie auf dem Gerät aktiviert ist.

  Die Datenausführungsverhinderungsrichtlinie (Data Execution Prevention, DEP) definiert eine Reihe von Hardware- und Softwaretechnologien, die zusätzliche Speicherüberprüfungen durchführen, um zu verhindern, dass schädlicher Code auf einem System ausgeführt wird. Der sichere Start lässt eine eingeschränkte Liste für x86/amd64 zu, und unter ARM NTOS wird die Liste aktiviert.

  DEPPolicy kann mithilfe der folgenden Befehle in WMI oder einem PowerShell-Skript deaktiviert oder aktiviert werden:

  • Um DEP zu deaktivieren, geben Sie bcdedit.exe /set {current} nx AlwaysOff ein.
  • Um DEP zu aktivieren, geben Sie bcdedit.exe /set {current} nx AlwaysOn ein.

  Wenn DEPPolicy = 1 (Ein) ist, lassen Sie den Zugriff zu.

  Wenn DEPPolicy = 0 (Aus) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Zulassen des bedingten Zugriffs basierend auf anderen Datenpunkten, die zur Auswertungszeit vorhanden sind. Beispielsweise andere Attribute im Integritätszertifikat oder die vergangenen Aktivitäten und den Vertrauensverlauf eines Geräts.
  • Führen Sie eine der vorherigen Aktionen aus, und platzieren Sie das Gerät zusätzlich in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

  Die DEP-Richtlinienauswertung ist eine nicht binäre status, wenn sie abgefragt wird. Es wird dann einem Ein/Aus-Zustand zugeordnet.

  DEP-Richtlinienebene	Beschreibung	Gemeldete Nachweisebene	Eigenschaftenwert
  OptIn (Standardkonfiguration)	DeP wurde nur auf Windows-Systemkomponenten und -Dienste angewendet.	0	2
  Optout	DEP ist für alle Prozesse aktiviert. Administratoren können manuell eine Liste mit bestimmten Anwendungen erstellen, für die DEP nicht angewendet wurde.	1	3
  AlwaysOn	DEP ist für alle Prozesse aktiviert.	3	1
  AlwaysOff	DEP ist für keinen Prozess aktiviert.	2	0

• BitLockerStatus (Meldet, ob BitLocker während des ersten Starts aktiviert wurde.):

  Wenn BitLocker zum Startzeitpunkt als "aktiviert" gemeldet wird, kann das Gerät daten, die auf dem Laufwerk gespeichert sind, vor unbefugtem Zugriff schützen, wenn das System ausgeschaltet wird oder in den Ruhezustand wechselt.

  Die Windows BitLocker-Laufwerkverschlüsselung verschlüsselt alle Daten, die auf dem Windows-Betriebssystemvolume gespeichert sind. BitLocker verwendet das TPM, um das Windows-Betriebssystem und die Benutzerdaten zu schützen und sicherzustellen, dass ein Computer nicht manipuliert wird, auch wenn er unbeaufsichtigt bleibt, verloren geht oder gestohlen wird.

  Wenn der Computer mit einem kompatiblen TPM ausgestattet ist, verwendet BitLocker das TPM, um die Verschlüsselungsschlüssel zu sperren, die die Daten schützen. Daher kann erst auf die Schlüssel zugegriffen werden, wenn das TPM den Zustand des Computers überprüft hat.

  Wenn BitLockerStatus = 1 (Ein) ist, lassen Sie den Zugriff zu.

  Wenn BitLockerStatus = 0 (Aus) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Zulassen des bedingten Zugriffs basierend auf anderen Datenpunkten, die zur Auswertungszeit vorhanden sind. Beispielsweise andere Attribute im Integritätszertifikat oder die vergangenen Aktivitäten und den Vertrauensverlauf eines Geräts.
  • Führen Sie eine der vorherigen Aktionen aus, und platzieren Sie das Gerät zusätzlich in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

• BootManagerRevListVersion: Dieses Attribut gibt die Version des Start-Managers an, die auf dem Gerät ausgeführt wird, damit Sie die Sicherheit der Startsequenz/-umgebung nachverfolgen und verwalten können.

  Wenn BootManagerRevListVersion = [CurrentVersion], dann den Zugriff zulassen.

  Wenn BootManagerRevListVersion != [CurrentVersion], dann führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI- und MBI-Ressourcen nicht zulassen.
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Technische Supportteam darüber zu informieren, dass der Besitzer das Problem untersucht.

• CodeIntegrityRevListVersion: Dieses Attribut gibt die Version des Codes an, der während der Startsequenz Integritätsprüfungen durchführt. Mithilfe dieses Attributs können Sie erkennen, ob auf dem Gerät die neueste Version des Codes ausgeführt wird, der Integritätsprüfungen durchführt, oder ob es Sicherheitsrisiken ausgesetzt (widerrufen) ist, und eine entsprechende Richtlinienaktion erzwingen.

  Wenn CodeIntegrityRevListVersion = [CurrentVersion], dann den Zugriff zulassen.

  Wenn CodeIntegrityRevListVersion != [CurrentVersion], dann führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI- und MBI-Ressourcen nicht zulassen.
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Technische Supportteam darüber zu informieren, dass der Besitzer das Problem untersucht.

• SecureBootEnabled: Wenn sicherer Start aktiviert ist, müssen die Kernkomponenten, die zum Starten des Computers verwendet werden, über korrekte kryptografische Signaturen verfügen, denen die organization vertrauen, die das Gerät hergestellt hat. Die UEFI-Firmware überprüft diese Anforderung, bevor der Computer gestartet werden kann. Wenn Dateien manipuliert wurden und deren Signatur zerbricht, wird das System nicht gestartet.

  Wenn SecureBootEnabled = 1 (True) ist, lassen Sie den Zugriff zu.

  Wenn SecurebootEnabled = 0 (False) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Zulassen des bedingten Zugriffs basierend auf anderen Datenpunkten, die zur Auswertungszeit vorhanden sind. Beispielsweise andere Attribute im Integritätszertifikat oder die vergangenen Aktivitäten und den Vertrauensverlauf eines Geräts.
  • Führen Sie eine der vorherigen Aktionen aus, und platzieren Sie das Gerät zusätzlich in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

• BootDebuggingEnabled: Startdebugging-aktiviert verweist auf ein Gerät, das für Entwicklung und Tests verwendet wird. Geräte, die für Tests und Entwicklung verwendet werden, sind in der Regel weniger sicher: Das Gerät kann instabilen Code ausführen oder mit weniger Sicherheitseinschränkungen konfiguriert werden, die für Tests und Entwicklung erforderlich sind.

  Das Startdebuggen kann mithilfe der folgenden Befehle in WMI oder einem PowerShell-Skript deaktiviert oder aktiviert werden:

  • Geben Sie zum Deaktivieren des Startdebuggens bcdedit.exe /set {current} bootdebug off ein.
  • Geben Sie zum Aktivieren des Startdebuggens bcdedit.exe /set {current} bootdebug ein.

  Wenn BootdebuggingEnabled = 0 (False) ist, lassen Sie den Zugriff zu.

  Wenn BootDebuggingEnabled = 1 (True) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Aktivieren von VSM mithilfe von WMI oder einem PowerShell-Skript.

• OSKernelDebuggingEnabled: OSKernelDebuggingEnabled verweist auf ein Gerät, das für Entwicklung und Tests verwendet wird. Geräte, die für Tests und Entwicklung verwendet werden, sind in der Regel weniger sicher: Sie können instabilen Code ausführen oder mit weniger Sicherheitseinschränkungen konfiguriert werden, die für Tests und Entwicklung erforderlich sind.

  Wenn OSKernelDebuggingEnabled = 0 (False) ist, lassen Sie den Zugriff zu.

  Wenn OSKernelDebuggingEnabled = 1 (True) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Technische Supportteam darüber zu informieren, dass der Besitzer das Problem untersucht.

• CodeIntegrityEnabled: Wenn die Codeintegrität aktiviert ist, ist die Codeausführung auf integritätsgeprüften Code beschränkt.

  Codeintegrität ist ein Feature, das die Integrität eines Treibers oder einer Systemdatei bei jedem Laden in den Arbeitsspeicher überprüft. Die Codeintegrität erkennt, ob ein nicht signierter Treiber oder eine Systemdatei in den Kernel geladen wird oder ob eine Systemdatei durch Schadsoftware geändert wurde, die von einem Benutzerkonto mit Administratorrechten ausgeführt wird.

  In x64-basierten Versionen des Betriebssystems müssen Kernel-Modus-Treiber digital signiert sein.

  Wenn CodeIntegrityEnabled = 1 (True) ist, lassen Sie den Zugriff zu.

  Wenn CodeIntegrityEnabled = 0 (False) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Zulassen des bedingten Zugriffs basierend auf anderen Datenpunkten, die zur Auswertungszeit vorhanden sind. Beispielsweise andere Attribute im Integritätszertifikat oder die vergangenen Aktivitäten und den Vertrauensverlauf eines Geräts.
  • Führen Sie eine der vorherigen Aktionen aus, und platzieren Sie das Gerät zusätzlich in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

• TestSigningEnabled: Wenn die Testsignatur aktiviert ist, erzwingt das Gerät keine Signaturüberprüfung während des Starts und lässt das Laden der nicht signierten Treiber (z. B. unsignierte UEFI-Module) während des Startvorgangs zu.

  Die Testsignatur kann mithilfe der folgenden Befehle in WMI oder einem PowerShell-Skript deaktiviert oder aktiviert werden:

  • Um das Startdebuggen zu deaktivieren, geben Siebcdedit.exe /set {current} testsigning off ein.
  • Geben Sie zum Aktivieren des Startdebuggens bcdedit.exe /set {current} testsigning on ein.

  Wenn TestSigningEnabled = 0 (False) ist, lassen Sie den Zugriff zu.

  Wenn TestSigningEnabled = 1 (True) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI- und MBI-Ressourcen nicht zulassen.
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Aktivieren der Testsignatur mithilfe von WMI oder einem PowerShell-Skript.

• SafeMode: Abgesicherter Modus ist eine Problembehandlungsoption für Windows, die Ihren Computer in einem eingeschränkten Zustand startet. Es werden nur die grundlegenden Dateien und Treiber gestartet, die zum Ausführen von Windows erforderlich sind.

  Wenn SafeMode = 0 (False) ist, lassen Sie den Zugriff zu.

  Wenn SafeMode = 1 (True) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Technische Supportteam darüber zu informieren, dass der Besitzer das Problem untersucht.

• WinPE: Windows Pre-Installation Environment (Windows PE) ist ein minimales Betriebssystem mit eingeschränkten Diensten, das zur Vorbereitung eines Computers für die Windows-Installation, zum Kopieren von Datenträgerimages von einem Netzwerkdateiserver und zum Initiieren von Windows Setup verwendet wird.

  Wenn WinPE = 0 (False) ist, lassen Sie den Zugriff zu.

  Wenn WinPE = 1 (True) ist, beschränken Sie den Zugriff auf Remoteressourcen, die für die Installation des Windows-Betriebssystems erforderlich sind.

• ELAMDriverLoaded (Windows Defender): Um dieses Berichterstellungsfeature verwenden zu können, müssen Sie "Hybrid Resume" auf dem Gerät deaktivieren. Early Launch Anti-Malware (ELAM) bietet Schutz für die Computer in Ihrem Netzwerk, wenn sie gestartet werden und bevor Treiber von Drittanbietern initialisiert werden.

  In der aktuellen Version überwacht/meldet dieses Attribut nur, wenn ein Microsoft-Erstanbieter-ELAM (Windows Defender) beim ersten Start geladen wurde.

  Wenn von einem Gerät erwartet wird, dass ein Antivirenprogramm eines Drittanbieters verwendet wird, ignorieren Sie den gemeldeten Zustand.

  Wenn von einem Gerät erwartet wird, dass es Windows Defender und ELAMDriverLoaded = 1 (True) verwendet, lassen Sie den Zugriff zu.

  Wenn von einem Gerät erwartet wird, dass Windows Defender und ELAMDriverLoaded = 0 (False) verwendet wird, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Technische Supportteam darüber zu informieren, dass der Besitzer das Problem untersucht.

• VSMEnabled: Virtual Secure Mode (VSM) ist ein Container, der hochwertige Ressourcen vor einem kompromittierten Kernel schützt. VSM benötigt etwa 1 GB Arbeitsspeicher – es verfügt über genügend Funktionen zum Ausführen des LSA-Diensts, der für alle Authentifizierungsbroker verwendet wird.

  VSM kann mithilfe des folgenden Befehls in WMI oder einem PowerShell-Skript aktiviert werden:

  bcdedit.exe /set {current} vsmlaunchtype auto

  Wenn VSMEnabled = 1 (True) ist, lassen Sie den Zugriff zu. Wenn VSMEnabled = 0 (False) ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Zugriff auf HBI-Ressourcen nicht zulassen.
  • Lösen Sie eine Korrekturmaßnahme aus, z. B. das Technische Supportteam darüber zu informieren, dass der Besitzer das Problem untersucht.

• PCRHashAlgorithmID: Dieses Attribut ist ein Informationsattribut, das den hash-Algorithmus identifiziert, der von TPM verwendet wurde. Keine Complianceaktion erforderlich.

• BootAppSVN: Dieses Attribut identifiziert die Sicherheitsversionsnummer der Startanwendung, die beim ersten Start auf dem bestätigten Gerät geladen wurde.

  Wenn die gemeldete BootAppSVN einem akzeptierten Wert entspricht, lassen Sie den Zugriff zu.

  Wenn die gemeldete BootAppSVN nicht mit einem akzeptierten Wert übereinstimmt, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Leiten Sie das Gerät an einen Unternehmenshopot weiter, um die Aktivitäten des Geräts weiter zu überwachen.

• BootManagerSVN: Dieses Attribut identifiziert die Sicherheitsversionsnummer des Start-Managers, der beim ersten Start auf dem bestätigten Gerät geladen wurde.

  Wenn der gemeldete BootManagerSVN einem akzeptierten Wert entspricht, lassen Sie den Zugriff zu.

  Wenn der gemeldete BootManagerSVN nicht mit einem akzeptierten Wert übereinstimmt, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Leiten Sie das Gerät an einen Unternehmenshopot weiter, um die Aktivitäten des Geräts weiter zu überwachen.

• TPMVersion: Dieses Attribut identifiziert die Version des TPM, das auf dem bestätigten Gerät ausgeführt wird. Der TPMVersion-Knoten stellt die Antworten "1" und "2" bereit:

  • 1 bedeutet TPM-Spezifikation, Version 1.2
  • 2 bedeutet TPM-Spezifikationsversion 2.0

  Basierend auf der Antwort, die Sie vom TPMVersion-Knoten erhalten:

  • Wenn die gemeldete TPMVersion einem akzeptierten Wert entspricht, lassen Sie den Zugriff zu.
  • Wenn die gemeldete TPMVersion nicht mit einem akzeptierten Wert übereinstimmt, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:
    • Alle Zugriffe nicht zulassen
    • Leiten Sie das Gerät an einen Unternehmenshopot weiter, um die Aktivitäten des Geräts weiter zu überwachen.

• PCR0: Die in PCR[0] erfasste Messung stellt in der Regel eine konsistente Ansicht der Hostplattform zwischen Startzyklen dar. Es enthält eine Messung von Komponenten, die vom Hostplattformhersteller bereitgestellt werden.

  Unternehmensmanager können eine Positivliste mit vertrauenswürdigen PCR[0]-Werten erstellen, den PCR[0]-Wert der verwalteten Geräte (der wert, der von HAS überprüft und gemeldet wird) mit der Positivliste vergleichen und dann basierend auf dem Ergebnis des Vergleichs eine Vertrauensentscheidung treffen.

  Wenn Ihr Unternehmen keine Zulassungsliste mit akzeptierten PCR[0]-Werten hat, führen Sie keine Maßnahmen aus. Wenn PCR[0] einem zulässigen Positivlistenwert entspricht, lassen Sie den Zugriff zu.

  Wenn PCR[0] keinem akzeptierten aufgelisteten Wert entspricht, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Leiten Sie das Gerät an einen Unternehmenshopot weiter, um die Aktivitäten des Geräts weiter zu überwachen.

• SBCPHash: SBCPHash ist der Fingerabdruck der benutzerdefinierten Richtlinie für die Konfiguration für den sicheren Start (SBCP), die beim Start auf Windows-Geräten mit Ausnahme von PCs geladen wurde.

  Wenn SBCPHash nicht vorhanden ist oder ein akzeptierter Zulässiger Wert ist, lassen Sie den Zugriff zu.

  Wenn SBCPHash in DHA-Report vorhanden ist und kein Positivlistewert ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

• CIPolicy: Dieses Attribut gibt die Codeintegritätsrichtlinie an, die die Sicherheit der Startumgebung steuert.

  Wenn CIPolicy nicht vorhanden ist oder ein akzeptierter Zulässiger Wert ist, dann lassen Sie den Zugriff zu.

  Wenn CIPolicy vorhanden ist und kein zulässiger Wert ist, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Platzieren Sie das Gerät in einer watch Liste, um das Gerät genauer auf potenzielle Risiken zu überwachen.

• BootRevListInfo: Dieses Attribut identifiziert die Startrevisionsliste, die beim ersten Start auf dem bestätigten Gerät geladen wurde.

  Wenn die gemeldete BootRevListInfo-Version einem akzeptierten Wert entspricht, lassen Sie den Zugriff zu.

  Wenn die gemeldete BootRevListInfo-Version nicht mit einem akzeptierten Wert übereinstimmt, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Leiten Sie das Gerät an einen Unternehmenshopot weiter, um die Aktivitäten des Geräts weiter zu überwachen.

• OSRevListInfo: Dieses Attribut identifiziert die Betriebssystemrevisionsliste, die beim ersten Start auf dem bestätigten Gerät geladen wurde.

  Wenn die gemeldete OSRevListInfo-Version einem akzeptierten Wert entspricht, lassen Sie den Zugriff zu.

  Wenn die gemeldete OSRevListInfo-Version nicht mit einem akzeptierten Wert übereinstimmt, führen Sie eine der folgenden Aktionen aus, die ihren Unternehmensrichtlinien entsprechen:

  • Sämtlichen Zugriff verweigern
  • Leiten Sie das Gerät an einen Unternehmenshopot weiter, um die Aktivitäten des Geräts weiter zu überwachen.

• HealthStatusMismatchFlags: Das HealthStatusMismatchFlags-Attribut wird angezeigt, wenn DHA-Service ein Integritätsproblem (Konflikt) in der DHA-Data erkennt, die es zur Überprüfung von Geräteverwaltungslösungen empfängt.

  Wenn ein Problem erkannt wird, wird eine Liste der betroffenen DHA-report-Elemente unter dem HealthStatusMismatchFlags-Attribut aufgeführt.

DHA-Report Beispiel

<?xml version="1.0" encoding="utf-8"?>
<HealthCertificateValidationResponse xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ErrorCode="0" ProtocolVersion="0"
xmlns="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3">
<HealthCertificateProperties>
     <Issued>2016-10-21T02:12:58.6656577Z</Issued>
     <AIKPresent>false</AIKPresent>
     <ResetCount>2107533174</ResetCount>
     <RestartCount>2749041230</RestartCount>
     <DEPPolicy>0</DEPPolicy>
     <BitlockerStatus>0</BitlockerStatus>
     <BootManagerRevListVersion>0</BootManagerRevListVersion>
     <CodeIntegrityRevListVersion>0</CodeIntegrityRevListVersion>
     <SecureBootEnabled>false</SecureBootEnabled>
     <BootDebuggingEnabled>false</BootDebuggingEnabled>
     <OSKernelDebuggingEnabled>false</OSKernelDebuggingEnabled>
     <CodeIntegrityEnabled>true</CodeIntegrityEnabled>
     <TestSigningEnabled>true</TestSigningEnabled>
     <SafeMode>false</SafeMode>
     <WinPE>false</WinPE>
     <ELAMDriverLoaded>true</ELAMDriverLoaded>
     <VSMEnabled>false</VSMEnabled>
     <PCRHashAlgorithmID>0</PCRHashAlgorithmID>
     <BootAppSVN>1</BootAppSVN>
     <BootManagerSVN>1</BootManagerSVN>
     <TpmVersion>2</TpmVersion>
     <PCR0>4ACCBE0ADB9627FFD6285C2E06EC5AC59ABF62C7</PCR0>
     <CIPolicy>00000000000001001A000B00200000005300690050006F006C006900630079002E007000370062000000A4BF7EF05585876A61CBFF7CAE8123BE756D58B1BBE04F9719D15D6271514CF5</CIPolicy>
     <BootRevListInfo>005D447A7CC6D101200000000B00CBB56E8B19267E24A2986C4A616CCB58B4D53F6020AC8FD5FC205C20F2AB00BC</BootRevListInfo>
     <OSRevListInfo>8073EEA7F8FAD001200000000B00A8285B04DE618ACF4174C59F07AECC002D11DD7D97FA5D464F190C9D9E3479BA</OSRevListInfo>
 </HealthCertificateProperties>
</HealthCertificateValidationResponse>

HealthAttestation-CSP-status und Fehlercodes

Fehlercode	Fehlername	Fehlerbeschreibung
0	HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED	Dieser Zustand ist der Ausgangszustand für Geräte, die noch nie an einer DHA-Sitzung teilgenommen haben.
1	HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED	Dieser Zustand gibt an, dass der Exec-Aufruf des MDM-Clients auf dem Knoten VerifyHealth ausgelöst wurde und das Betriebssystem nun versucht, DHA-EncBlob von DHA-Server abzurufen.
2	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED	Dieser Zustand bedeutet, dass das Gerät DHA-EncBlob nicht vom DHA-Server abrufen konnte.
3	HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE	Dieser Zustand bedeutet, dass das Gerät erfolgreich DHA-EncBlob vom DHA-Server abgerufen hat.
4	HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL	Veraltet in Windows 10 Version 1607.
5	HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL	DHA-CSP konnte kein Anspruchsangebot erhalten.
6	HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY	DHA-CSP konnte beim Öffnen eines Handles für den Kryptografieanbieter der Microsoft-Plattform nicht geöffnet werden.
7	HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL	DHA-CSP beim Abrufen von Windows AIK fehlgeschlagen
8	HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL	Veraltet in Windows 10 Version 1607.
9	HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION	Ungültige TPM-Version (TPM-Version ist nicht 1.2 oder 2.0)
10	HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL	Nonce wurde in der Registrierung nicht gefunden.
11	HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL	Die Korrelations-ID wurde in der Registrierung nicht gefunden.
12	HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL	Veraltet in Windows 10 Version 1607.
13	HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL	Veraltet in Windows 10 Version 1607.
14	HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL	Fehler in Codierungsfunktionen. (Äußerst unwahrscheinliches Szenario)
15	HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL	Veraltet in Windows 10 Version 1607.
16	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML	DHA-CSP konnte die nutzlast nicht laden, die es vom DHA-Service empfangen hat.
17	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML	DHA-CSP hat eine beschädigte Antwort vom DHA-Service erhalten.
18	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY	DHA-CSP hat eine leere Antwort vom DHA-Service erhalten.
19	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK	DHA-CSP konnte beim Entschlüsseln des AES-Schlüssels aus der EK-Herausforderung nicht erfolgreich sein.
20	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK	DHA-CSP ist beim Entschlüsseln des Integritätszertifikats mit dem AES-Schlüssel fehlgeschlagen.
21	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB	DHA-CSP ist beim Exportieren des öffentlichen AIK-Schlüssels fehlgeschlagen.
22	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY	DHA-CSP ist beim Erstellen eines Anspruchs mit AIK-Nachweisdaten fehlgeschlagen.
23	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB	DHA-CSP ist beim Anfügen des AIK Pub an das Anforderungsblob fehlgeschlagen.
24	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT	DHA-CSP ist beim Anfügen des AIK-Zertifikats an das Anforderungsblob fehlgeschlagen.
25	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE	DHA-CSP konnte kein Sitzungshandle abrufen.
26	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE	DHA-CSP konnte keine Verbindung mit dem DHA-Dienst herstellen.
27	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND	DHA-CSP konnte kein HTTP-Anforderungshandle erstellen.
28	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION	DHA-CSP konnte keine Optionen festlegen.
29	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS	DHA-CSP konnte keine Anforderungsheader hinzufügen.
30	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST	DHA-CSP konnte die HTTP-Anforderung nicht senden.
31	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE	DHA-CSP konnte keine Antwort vom DHA-Dienst empfangen.
32	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS	DHA-CSP konnte Header nicht abfragen, wenn versucht wurde, HTTP-status Code abzurufen.
33	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE	DHA-CSP hat eine leere Antwort von DHA-Service erhalten, obwohl die HTTP-status in Ordnung war.
34	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE	DHA-CSP hat eine leere Antwort zusammen mit einem HTTP-Fehlercode vom DHA-Service erhalten.
35	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER	DHA-CSP konnte die Identität eines Benutzers nicht annehmen.
36	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR	DHA-CSP konnte die PDC-Aktivatoren, die für die Netzwerkkommunikation benötigt werden, nicht abrufen, wenn sich das Gerät im verbundenen Standbymodus befindet.
0xffff	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN	DHA-CSP ist aus einem unbekannten Grund fehlgeschlagen. Dieser Fehler ist sehr unwahrscheinlich.
400	Bad_Request_From_Client	DHA-CSP hat eine ungültige (falsch formatierte) Nachweisanforderung erhalten.
404	Endpoint_Not_Reachable	DHA-Service ist von DHA-CSP nicht erreichbar

Sicherheitsüberlegungen

DHA verankert sein Vertrauen in das TPM und seine Messungen. Wenn TPM-Messungen gespooft oder manipuliert werden können, kann DHA keine Garantie für die Geräteintegrität für dieses Gerät bieten.

Weitere Informationen finden Sie unter TPM-Zertifizierung für PC-Clients.

Verwandte Artikel

Referenz zum Konfigurationsdienstanbieter