CSP HealthAttestation

Importante

Questo CSP contiene alcune impostazioni in fase di sviluppo e applicabili solo per le compilazioni Windows Insider Preview. Queste impostazioni sono soggette a modifiche e potrebbero avere dipendenze da altre funzionalità o servizi in anteprima.

Il provider di servizi di configurazione Device HealthAttestation (DHA-CSP) consente agli amministratori IT aziendali di valutare se un dispositivo viene avviato in uno stato attendibile e conforme e di eseguire azioni dei criteri aziendali.

L'elenco seguente contiene una descrizione delle funzioni eseguite da Device HealthAttestation CSP:

• Raccoglie i log di avvio dei dispositivi, i percorsi di controllo TPM (Trusted Platform Module) e il certificato TPM (DHA-BootData) da un dispositivo gestito
• Inoltra DHA-BootData a un servizio di attestazione dell'integrità del dispositivo (DHA-Service)
• Riceve un BLOB crittografato (DHA-EncBlob) da DHA-Service e lo archivia in una cache locale nel dispositivo
• Riceve richieste di attestazione (richieste DHA) da un DHA-Enabled MDM e risponde con i dati di attestazione dell'integrità del dispositivo (DHA-Data)

L'elenco seguente mostra i nodi del provider di servizi di configurazione HealthAttestation:

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

AttestErrorMessage

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows Insider Preview

./Vendor/MSFT/HealthAttestation/AttestErrorMessage

AttestErrorMessage mantiene il messaggio di errore per l'ultima sessione di attestazione, se restituito dal servizio di attestazione.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Ottieni

AttestStatus

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 11 versione 21H2 [10.0.22000] e versioni successive

./Vendor/MSFT/HealthAttestation/AttestStatus

AttestStatus mantiene il codice di stato di esito positivo o negativo per l'ultima sessione di attestazione.

Lo stato viene sempre cancellato prima di effettuare la chiamata al servizio attest.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	int
Tipo accesso	Ottieni

Esempio:

• Chiamata SyncML modello:

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

• Risposta di esempio:

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

Certificato

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/Certificate

Indica a DHA-CSP di inoltrare DHA-Data al server MDM.

Il tipo di valore è una stringa base64.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Ottieni

Correlationid

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/CorrelationID

Identifica una sessione di attestazione dell'integrità del dispositivo univoca. CorrelationId viene usato per correlare i log DHA-Service con gli eventi del server MDM e i log eventi client per il debug e la risoluzione dei problemi.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Ottieni

CurrentProtocolVersion

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10, versione 1709 [10.0.16299] e versioni successive

./Vendor/MSFT/HealthAttestation/CurrentProtocolVersion

Fornisce la versione del protocollo corrente usata dal client per comunicare con il servizio di attestazione dell'integrità.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	int
Tipo accesso	Ottieni

ForceRetrieve

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/ForceRetrieve

Indica al client di avviare una nuova richiesta a DHA-Service e ottenere un nuovo DHA-EncBlob (un riepilogo dello stato di avvio emesso da DHA-Service). Questa opzione deve essere usata solo se il server MDM applica un criterio di aggiornamento del certificato, che deve forzare un dispositivo a ottenere un NUOVO BLOB crittografato da DHA-Service.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	bool
Tipo accesso	Get, Replace
Valore predefinito	False

Valori consentiti:

Value	Descrizione
false (impostazione predefinita)	False.
true	Vero.

GetAttestReport

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 11 versione 21H2 [10.0.22000] e versioni successive

./Vendor/MSFT/HealthAttestation/GetAttestReport

Recuperare il report della sessione di attestazione, se esistente.

Il report viene archiviato in una chiave del Registro di sistema nel rispettivo archivio di registrazione MDM.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Ottieni

Esempio:

• Chiamata SyncML modello:

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

• Dati di esempio:

  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

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 11 versione 21H2 [10.0.22000] e versioni successive

./Vendor/MSFT/HealthAttestation/GetServiceCorrelationIDs

Recuperare gli ID di correlazione del servizio, se esistenti.

Se sono presenti più ID di correlazione, sono separati da ";" nella stringa.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Ottieni

Esempio:

• Chiamata SyncML modello:

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

• Dati di esempio:

  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

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/HASEndpoint

Identifica il nome di dominio completo (FQDN) del DHA-Service assegnato per eseguire l'attestazione. Se non viene assegnato un FQDN, DHA-Cloud (servizio cloud di proprietà e gestito da Microsoft) verrà usato come servizio di attestazione predefinito.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Get, Replace
Valore predefinito	has.spserv.microsoft.com.

MaxSupportedProtocolVersion

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10, versione 1709 [10.0.16299] e versioni successive

./Vendor/MSFT/HealthAttestation/MaxSupportedProtocolVersion

Restituisce la versione massima del protocollo supportata da questo client.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	int
Tipo accesso	Ottieni

Nonce

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/Nonce

Consente agli MDM di proteggere le comunicazioni di attestazione dell'integrità del dispositivo da attacchi di tipo man-in-the-middle (MITM) con un valore casuale protetto da crittografia generato dal server MDM. Il nonce è in formato esadecimale, con una dimensione minima di 8 byte e una dimensione massima di 32 byte.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Get, Replace
Valore predefinito	\0

PreferredMaxProtocolVersion

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10, versione 1709 [10.0.16299] e versioni successive

./Vendor/MSFT/HealthAttestation/PreferredMaxProtocolVersion

Fornisce la versione massima del protocollo preferita su cui il client è configurato per comunicare. Se è superiore alle versioni del protocollo supportate dal client, userà la versione del protocollo più alta disponibile.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	int
Tipo accesso	Get, Replace
Valore predefinito	3

Stato

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/Status

Fornisce lo stato corrente della richiesta di integrità del dispositivo. Per l'elenco completo dei valori di stato, vedere HealthAttestation CSP status and error codes.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	int
Tipo accesso	Ottieni

TpmReadyStatus

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1607 [10.0.14393] e versioni successive

./Vendor/MSFT/HealthAttestation/TpmReadyStatus

Restituisce una maschera di bit di informazioni che descrivono lo stato di TPM. Indica se il TPM del dispositivo è pronto e attendibile.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	int
Tipo accesso	Ottieni

TriggerAttestation

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 11 versione 21H2 [10.0.22000] e versioni successive

./Vendor/MSFT/HealthAttestation/TriggerAttestation

Notifica al dispositivo di attivare una sessione di attestazione in modo asincrono.

Se il processo di attestazione viene avviato correttamente, questo nodo restituirà il codice 202 che indica che la richiesta viene ricevuta ed elaborata. In caso contrario, verrà restituito un errore.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	chr (stringa)
Tipo accesso	Exec

Esempio:

• Chiamata SyncML modello:

  <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>
  

• Campi dati:

  • rpID (Relying Party Identifier): questo campo contiene un identificatore che può essere usato per determinare il chiamante.
  • serviceEndpoint: questo campo contiene l'URL completo dell'istanza del provider microsoft attestazione di Azure da usare per la valutazione.
  • nonce: questo campo contiene un numero arbitrario che può essere usato una sola volta in una comunicazione crittografica. Si tratta spesso di un numero casuale o pseudo-casuale emesso in un protocollo di autenticazione per garantire che le comunicazioni precedenti non possano essere riutilizzate negli attacchi di riproduzione.
  • aadToken: token Microsoft Entra da usare per l'autenticazione nel servizio Microsoft attestazione di Azure.
  • cv: questo campo contiene un identificatore (vettore di correlazione) che verrà passato alla chiamata al servizio e che può essere usato a scopo di diagnostica.

• Esempio <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

Ambito	Edizioni	Sistema operativo applicabile
✅ dispositivo ❌ utente	✅ Pro ✅ Enterprise ✅ Education ✅Windows SE ✅ IoT Enterprise / IoT Enterprise LTSC	✅Windows 10 versione 1511 [10.0.10586] e versioni successive

./Vendor/MSFT/HealthAttestation/VerifyHealth

Notifica al dispositivo di preparare una richiesta di verifica dell'integrità del dispositivo.

Proprietà del framework di descrizione:

Nome della proprietà	Valore proprietà
Formato	null
Tipo accesso	Exec

Windows 11 Attestazione dell'integrità del dispositivo

Windows 11 introduce un aggiornamento alla funzionalità di attestazione dell'integrità del dispositivo. Questo aggiornamento consente di aggiungere il supporto per informazioni più approfondite sulla sicurezza di avvio di Windows, supportando un approccio zero trust alla sicurezza dei dispositivi. È possibile accedere all'attestazione dell'integrità dei dispositivi in Windows usando il CSP HealthAttestation. Questo provider di servizi di configurazione consente di valutare se un dispositivo viene avviato in uno stato attendibile e conforme e quindi di intraprendere le azioni appropriate. Windows 11 introduce più nodi figlio al nodo HealthAttestation per consentire ai provider MDM di connettersi al servizio Microsoft attestazione di Azure, che offre un approccio semplificato all'attestazione.

Il report di attestazione fornisce una valutazione dell'integrità delle proprietà del tempo di avvio del dispositivo per garantire che i dispositivi siano protetti automaticamente non appena si accedono. Il risultato dell'attestazione dell'integrità può quindi essere usato per consentire o negare l'accesso a reti, app o servizi, a seconda dell'integrità del dispositivo.

Termini usati:

• TPM (Trusted Platform Module):TPM è una logica specializzata protetta da hardware che esegue una serie di operazioni di sicurezza protette dall'hardware, tra cui l'archiviazione protetta, la generazione di numeri casuali, la crittografia e la firma.
• Funzionalità DHA (Device HealthAttestation): la funzionalità Device HealthAttestation (DHA) consente agli amministratori IT aziendali di monitorare il comportamento di sicurezza dei dispositivi gestiti in remoto usando dati hardware (TPM) protetti e attestati tramite un canale di comunicazione resistente alle manomissioni ed evidente.
• MAA-Session (Microsoft attestazione di Azure service based device HealthAttestation session): la sessione HealthAttestation del dispositivo basata sul servizio Microsoft attestazione di Azure (MAA-Session) descrive il flusso di comunicazione end-to-end eseguito in una sessione di attestazione dell'integrità del dispositivo.
• Nodi MAA-CSP (Provider di servizi di configurazione basato su Microsoft attestazione di Azure): i nodi del provider di servizi di configurazione aggiunti a Windows 11 da integrare con il servizio microsoft attestazione di Azure. L'elenco di operazioni seguente viene eseguito da MAA-CSP:
  • Riceve le richieste di trigger di attestazione da un provider MDM abilitato per HealthAttestation.
  • Il dispositivo raccoglie prove di attestazione (log di avvio del dispositivo, audit trail TPM e certificato TPM) da un dispositivo gestito.
  • Inoltra l'evidenza di attestazione all'istanza del servizio attestazione di Azure configurata dal provider MDM.
  • Riceve un report firmato dall'istanza del servizio attestazione di Azure e lo archivia in una cache locale nel dispositivo.
• Endpoint MAA: il servizio di attestazione di Microsoft Azure è una risorsa di Azure e ogni istanza del servizio ottiene l'URL configurato dall'amministratore. L'URI generato è di natura univoca e ai fini dell'attestazione dell'integrità del dispositivo è noto come endpoint MAA.
• JWT (token Web JSON):JSON Web Token (JWT) è un metodo di RFC7519 standard aperto per la trasmissione sicura di informazioni tra parti come oggetto JSON (JavaScript Object Notation). Queste informazioni possono essere verificate e attendibili perché firmate digitalmente. I JWT possono essere firmati usando un segreto o una coppia di chiavi pubblica/privata.

Flusso di attestazione con il servizio Microsoft attestazione di Azure

Il flusso di attestazione può essere in tre passaggi principali:

• Un'istanza del servizio attestazione di Azure viene configurata con un criterio di attestazione appropriato. I criteri di attestazione consentono al provider MDM di attestare eventi specifici nell'avvio e funzionalità di sicurezza.
• Il provider MDM attiva una chiamata al servizio di attestazione, il dispositivo esegue quindi un controllo di attestazione mantenendo il report pronto per essere recuperato.
• Il provider MDM dopo aver verificato che il token provenga dal servizio di attestazione può analizzare il token di attestazione per riflettere sullo stato attestato del dispositivo.

Per altre informazioni, vedere Protocollo di attestazione.

Passaggi di integrazione di MAA CSP

1. Configurare un'istanza del provider MAA: è possibile creare un'istanza MAA seguendo la procedura descritta in Avvio rapido: Configurare attestazione di Azure usando il portale di Azure.

2. Aggiornare il provider con un criterio appropriato: l'istanza MAA deve essere aggiornata con un criterio appropriato. Per altre informazioni, vedere Come creare un criterio di attestazione di Azure.

   Un criterio di attestazione di esempio:

   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. Chiamare TriggerAttestation con rpide Azure Active Directory tokenattestURI: usare l'URL di attestazione generato nel passaggio 1 e aggiungere la versione dell'API appropriata che si vuole raggiungere. Per altre informazioni sulla versione dell'API, vedere Attest Tpm - API REST.

4. Chiamare GetAttestReport e decodificare e analizzare il report per assicurarsi che il report attestato contenga le proprietà necessarie: GetAttestReport restituisce il token di attestazione firmato come JWT. Il codice JWT può essere decodificato per analizzare le informazioni in base ai criteri di attestazione.

       {
         "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]
   

Altre informazioni

Altre informazioni sull'attestazione TPM sono disponibili qui: Microsoft attestazione di Azure.

Windows 10 Device HealthAttestation

Termini usati:

• TPM (Trusted Platform Module):TPM è una logica specializzata protetta da hardware che esegue una serie di operazioni di sicurezza protette dall'hardware, tra cui l'archiviazione protetta, la generazione di numeri casuali, la crittografia e la firma.

• Funzionalità DHA (Device HealthAttestation): la funzionalità Device HealthAttestation (DHA) consente agli amministratori IT aziendali di monitorare il comportamento di sicurezza dei dispositivi gestiti in remoto usando dati hardware (TPM) protetti e attestati tramite un canale di comunicazione resistente alle manomissioni ed evidente.

• Dispositivo abilitato per DHA (dispositivo abilitato per Device HealthAttestation):un dispositivo abilitato per Device HealthAttestation (abilitato per DHA) è un dispositivo informatico (telefono, desktop, portatile, tablet, server) che esegue Windows 10 e supporta TPM versione 1.2 o 2.0.

• DHA-Session (Device HealthAttestation session): la sessione Device HealthAttestation (DHA-Session) descrive il flusso di comunicazione end-to-end eseguito in una sessione di attestazione dell'integrità del dispositivo. L'elenco di transazioni seguente viene eseguito in una sessione DHA:

  

  • Comunicazione DHA-CSP e DHA-Service:
    • DHA-CSP inoltra i dati di avvio del dispositivo (DHA-BootData) a DHA-Service
    • DHA-Service risponde con un BLOB di dati crittografati (DHA-EncBlob)
  • Comunicazione DHA-CSP e MDM-Server:
    • MDM-Server invia una richiesta di verifica dell'integrità del dispositivo a DHA-CSP
    • DHA-CSP risponde con un payload denominato DHA-Data che include un BLOB di dati crittografato (DHA-EncBlob) e un BLOB di dati firmato (DHA-SignedBlob)
  • comunicazione MDM-Server e DHA-Service:
    • MDM-Server pubblica i dati ricevuti dai dispositivi in DHA-Service
    • DHA-Service esamina i dati ricevuti e risponde con un report sull'integrità del dispositivo (DHA-Report)

• Dati sessione DHA (Dati sessione Device HealthAttestation): l'elenco di dati seguente viene prodotto o utilizzato in una transazione DHA:

  • DHA-BootData: i dati di avvio del dispositivo (log TCG, valori PCR, certificato del dispositivo/TPM, avvio e contatori TPM) necessari per convalidare l'integrità dell'avvio del dispositivo.
  • DHA-EncBlob: report di riepilogo crittografato che DHA-Service problemi a un dispositivo dopo aver esaminato il DHA-BootData ricevuto dai dispositivi.
  • DHA-SignedBlob: è uno snapshot firmato dello stato corrente del runtime di un dispositivo acquisito da DHA-CSP in fase di attestazione dell'integrità del dispositivo.
  • DHA-Data: BLOB di dati in formato XML che i dispositivi inoltrano per la convalida dell'integrità del dispositivo a DHA-Service tramite MDM-Server. DHA-Data è costituito da due parti:
    • DHA-EncBlob: BLOB di dati crittografati ricevuto dal dispositivo da DHA-Service
    • DHA-SignedBlob: uno snapshot corrente dello stato di sicurezza corrente del dispositivo generato da DHA-CSP
  • DHA-Report: report emesso da DHA-Service per MDM-Server
  • Nonce: un numero protetto da crittografia generato da MDM-Server, che protegge il DHA-Session da attacchi di tipo man-in-the-middle

• DHA-Enabled MDM (Device HealthAttestation enabled device management solution): Device HealthAttestation enabled (DHA-Enabled) device management solution è uno strumento di gestione dei dispositivi integrato con la funzionalità DHA. DHA-Enabled soluzioni di gestione dei dispositivi consentono ai responsabili IT aziendali di alzare la barra di protezione della sicurezza per i dispositivi gestiti in base a dati protetti hardware (TPM) che possono essere considerati attendibili anche se un dispositivo è compromesso da minacce di sicurezza avanzate o esegue un sistema operativo dannoso (jailbroken). L'elenco di operazioni seguente viene eseguito da DHA-Enabled-MDM:

  • Abilita la funzionalità DHA in un dispositivo DHA-Enabled
  • Invia richieste di attestazione dell'integrità dei dispositivi ai dispositivi registrati/gestiti
  • Raccoglie i dati di attestazione dell'integrità dei dispositivi (DHA-Data) e lo invia al servizio di attestazione dell'integrità del dispositivo (DHA-Service) per la verifica
  • Ottiene il report sull'integrità del dispositivo (DHA-Report) da DHA-Service, che attiva l'azione di conformità

• DHA-CSP (Device HealthAttestation Configuration Service Provider): il provider di servizi di configurazione Device HealthAttestation (DHA-CSP) usa il TPM e il firmware di un dispositivo per misurare le proprietà di sicurezza critiche del BIOS del dispositivo e dell'avvio di Windows, in modo che anche in un sistema infettato da malware a livello di kernel o un rootkit, queste proprietà non possano essere spoofed. L'elenco di operazioni seguente viene eseguito da DHA-CSP:

  • Raccoglie i dati di avvio del dispositivo (DHA-BootData) da un dispositivo gestito
  • Inoltra DHA-BootData al servizio di attestazione dell'integrità del dispositivo (DHA-Service)
  • Riceve un BLOB crittografato (DHA-EncBlob) da DHA-Service e lo archivia in una cache locale nel dispositivo
  • Riceve richieste di attestazione (richieste DHA) da un DHA-Enabled MDM e risponde con i dati di attestazione dell'integrità del dispositivo (DHA-Data)

• DHA-Service (Device HealthAttestation Service): Device HealthAttestation Service (DHA-Service) convalida i dati ricevuti da DHA-CSP ed emette un report protetto hardware (TPM) altamente attendibile (DHA-Report) per DHA-Enabled soluzioni di gestione dei dispositivi tramite un canale di comunicazione evidente resistente alle manomissioni e manomissione. DHA-Service è disponibile in due versioni: "DHA-Cloud" e "DHA-Server2016". DHA-Service supporta vari scenari di implementazione, tra cui scenari cloud, locali, air-gapped e ibridi. L'elenco di operazioni seguente viene eseguito da DHA-Service:

  • Riceve i dati di avvio del dispositivo (DHA-BootData) da un dispositivo DHA-Enabled
  • Inoltra DHA-BootData al servizio di attestazione dell'integrità del dispositivo (DHA-Service)
  • Riceve un BLOB crittografato (DHA-EncBlob) da DHA-Service e lo archivia in una cache locale nel dispositivo
  • Riceve richieste di attestazione (richieste DHA) da un DHA-Enabled-MDM e risponde con un report sull'integrità del dispositivo (DHA-Report)

tipo DHA-Service	Descrizione	Costo dell'operazione
Attestazione dell'integrità dei dispositivi - Cloud (DHA-Cloud)	DHA-Cloud è un DHA-Service di proprietà e gestito da Microsoft che è: Disponibile gratuitamente in Windows Esecuzione in un'infrastruttura cloud a disponibilità elevata e con bilanciamento geografico Supportato dalla maggior parte delle soluzioni di gestione dei dispositivi DHA-Enabled come provider di servizi di attestazione del dispositivo predefinito Accessibile a tutti i dispositivi gestiti dall'organizzazione tramite: FQDN = porta has.spserv.microsoft.com Porta = 443 Protocol = TCP	Nessun costo
Attestazione dell'integrità del dispositivo - Locale (DHA-OnPrem)	DHA-OnPrem si riferisce a DHA-Service in esecuzione in locale: Offerto al cliente Windows Server 2016 (nessun costo di licenza aggiuntivo per l'abilitazione/esecuzione del servizio DHA) Ospitato in un dispositivo/hardware server gestito e di proprietà dell'organizzazione Supportato da provider di soluzioni di gestione dei dispositivi di prima e terza parte DHA-Enabled che supportano scenari di attestazione hardware locali e ibridi (Cloud + OnPrem) Accessibile a tutti i dispositivi gestiti dall'organizzazione tramite le impostazioni seguenti: FQDN = (organizzazione assegnata) Porta = (assegnata dall'organizzazione) Protocol = TCP	Costo dell'operazione per l'esecuzione di una o più istanze di Server 2016 in locale.
Attestazione dell'integrità dei dispositivi - cloud Enterprise-Managed (DHA-EMC)	DHA-EMC si riferisce a un DHA-Service gestito dall'organizzazione in esecuzione come host/servizio virtuale in un servizio cloud compatibile con Windows Server 2016- gestito dall'organizzazione, ad esempio Microsoft Azure. Offerto ai clienti Windows Server 2016 senza costi aggiuntivi per le licenze (nessun costo aggiuntivo per l'abilitazione/esecuzione del servizio DHA) Supportato da provider di soluzioni di gestione dei dispositivi di prima e terza parte DHA-Enabled che supportano scenari di attestazione hardware locali e ibridi (Cloud + OnPrem) Accessibile a tutti i dispositivi gestiti dall'organizzazione tramite le impostazioni seguenti: FQDN = (organizzazione assegnata) Porta = (assegnata dall'organizzazione) Protocol = TCP	Costo operativo dell'esecuzione di Server 2016 in un servizio cloud compatibile, ad esempio Microsoft Azure.

Passaggi di integrazione DHA-CSP

L'elenco seguente di attività di convalida e sviluppo è necessario per l'integrazione della funzionalità Microsoft Device Health Attestation con una soluzione di gestione dei dispositivi Windows Mobile (MDM):

1. Verificare l'accesso HTTPS
2. Assegnare un servizio DHA attendibile aziendale
3. Indicare al client di preparare i dati DHA per la verifica
4. Intervenire in base alla risposta dei client
5. Indicare al client di inoltrare i dati DHA per la verifica
6. Post DHA-data to DHA-service
7. Ricevere risposta dal servizio DHA
8. Analizzare i dati DHA-Report. Intraprendere un'azione di criteri appropriata in base ai risultati della valutazione

Ogni passaggio è descritto in dettaglio nelle sezioni seguenti di questo argomento.

Passaggio 1: Verificare l'accesso HTTPS

Verificare che sia il server MDM che il dispositivo (client MDM) possano accedere a has.spserv.microsoft.com usando il protocollo TCP sulla porta 443 (HTTPS).

È possibile usare OpenSSL per convalidare l'accesso a DHA-Service. Ecco un comando OpenSSL di esempio e la risposta generata da DHA-Service:

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)

Passaggio 2: Assegnare un DHA-Service attendibile aziendale

Esistono tre tipi di DHA-Service:

• Attestazione dell'integrità dei dispositivi - Cloud (di proprietà e gestita da Microsoft)
• Attestazione dell'integrità dei dispositivi - Locale (di proprietà e gestita da un'azienda, viene eseguita in Windows Server 2016 locale)
• Attestazione dell'integrità dei dispositivi : Enterprise-Managed Cloud (di proprietà e gestito da un'azienda, viene eseguito in Windows Server 2016 cloud gestito dall'organizzazione compatibile)

DHA-Cloud è l'impostazione predefinita. Se un'organizzazione prevede di usare Microsoft DHA-Cloud come provider di DHA-Service attendibile, non sono necessarie altre azioni.

Per DHA-OnPrem & scenari DHA-EMC, inviare un comando SyncML al nodo HASEndpoint per indicare a un dispositivo gestito di comunicare con il servizio DHA-Service aziendale attendibile.

Nell'esempio seguente viene illustrata una chiamata di esempio che indica a un dispositivo gestito di comunicare con un servizio DHA-Service gestito dall'organizzazione.

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

Passaggio 3: Indicare al client di preparare i dati di integrità per la verifica

Inviare una chiamata SyncML per avviare la raccolta di DHA-Data.

Nell'esempio seguente viene illustrata una chiamata di esempio che attiva la raccolta e la verifica dei dati di attestazione dell'integrità da un dispositivo gestito.

<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>

Passaggio 4: Intervenire in base alla risposta del client

Dopo che il client riceve la richiesta di attestazione dell'integrità, invia una risposta. L'elenco seguente descrive le risposte, insieme a un'azione consigliata da eseguire.

• Se la risposta è HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE (3), passare alla sezione successiva.
• Se la risposta è HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) o HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) attendere un avviso, passare alla sezione successiva.

Ecco un avviso di esempio emesso da DHA_CSP:

<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>

• Se la risposta al nodo di stato non è 0, 1 o 3, risolvere il problema. Per l'elenco completo dei codici di stato, vedere HealthAttestation CSP status and error codes.for the complete list of status codes, see HealthAttestation CSP status and error codes.

Passaggio 5: Indicare al client di inoltrare i dati di attestazione dell'integrità per la verifica

Creare una chiamata ai nodi Nonce, Certificate e CorrelationId e selezionare un payload crittografato che include un certificato di integrità e i dati correlati dal dispositivo.

Ecco un esempio:

<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>

Passaggio 6: Inoltrare i dati di attestazione dell'integrità del dispositivo al servizio DHA

In risposta alla richiesta inviata nel passaggio precedente, il client MDM inoltra un BLOB formattato XML (risposta dal nodo ./Vendor/MSFT/HealthAttestation/Certificate) e un identificatore di chiamata denominato CorrelationId (risposta al nodo ./Vendor/MSFT/HealthAttestation/CorrelationId).

Quando il MDM-Server riceve i dati precedenti, deve:

• Registrare il CorrelationId ricevuto dal dispositivo (per la risoluzione dei problemi/riferimenti futuri), correlato alla chiamata.

• Decodificare il BLOB di dati formattato XML ricevuto dal dispositivo

• Aggiungere il nonce generato dal servizio MDM (aggiungere il nonce inoltrato al dispositivo nel passaggio 5) alla struttura XML inoltrata dal dispositivo nel formato seguente:

  <?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>
  

• Inoltrare (HTTP Post) lo struct di dati XML (incluso il nonce aggiunto nel passaggio precedente) al DHA-Service assegnato in esecuzione in:

  • DHA-Cloud (scenario DHA-Service di proprietà e gestito da Microsoft): https://has.spserv.microsoft.com/DeviceHealthAttestation/ValidateHealthCertificate/v3
  • DHA-OnPrem o DHA-EMC: https://FullyQualifiedDomainName-FDQN/DeviceHealthAttestation/ValidateHealthCertificate/v3

Passaggio 7: Ricevere risposta dal servizio DHA

Quando il servizio Di attestazione integrità dispositivi Microsoft riceve una richiesta di verifica, esegue la procedura seguente:

• Decrittografa i dati crittografati ricevuti.
• Convalida i dati ricevuti.
• Crea un report e condivide i risultati della valutazione al server MDM tramite SSL in formato XML.

Passaggio 8: Intraprendere un'azione dei criteri appropriata in base ai risultati della valutazione

Dopo che il server MDM ha ricevuto i dati verificati, è possibile usare le informazioni per prendere decisioni sui criteri valutando i dati. Alcune possibili azioni sono:

• Consentire l'accesso al dispositivo.
• Consentire al dispositivo di accedere alle risorse, ma contrassegnare il dispositivo per ulteriori indagini.
• Impedire a un dispositivo di accedere alle risorse.

DHA-Report schema V3

<?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>

L'elenco di punti dati seguente viene verificato dalla DHA-Service in DHA-Report versione 3.

• Emesso: data e ora in cui il report DHA è stato valutato o emesso in MDM.

• AIKPresent: quando una chiave di identità di attestazione (AIK) è presente in un dispositivo, indica che il dispositivo ha un certificato di chiave di verifica dell'autenticità (EK). Può essere considerato attendibile più di un dispositivo che non ha un certificato EK.

  Se AIKPresent = True (1), consentire l'accesso.

  Se AIKPresent = False (0), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Consentire l'accesso condizionale in base ad altri punti dati presenti in fase di valutazione. Ad esempio, altri attributi nel certificato di integrità o le attività passate e la cronologia di attendibilità di un dispositivo.
  • Eseguire una delle azioni precedenti e inserire inoltre il dispositivo in un elenco di watch per monitorare il dispositivo più da vicino per potenziali rischi.

• ResetCount (segnalato solo per i dispositivi che supportano TPM 2.0): questo attributo indica il numero di volte in cui un dispositivo PC è stato ibernato o ripreso.

• RestartCount (segnalato solo per i dispositivi che supportano TPM 2.0): questo attributo indica il numero di volte in cui un dispositivo PC è stato riavviato.

• DEPPolicy: un dispositivo può essere considerato più attendibile se i criteri DEP sono abilitati nel dispositivo.

  I criteri di prevenzione dell'esecuzione dei dati (DEP) definiscono un set di tecnologie hardware e software che eseguono controlli aggiuntivi sulla memoria per impedire l'esecuzione di codice dannoso in un sistema. L'avvio protetto consente un elenco limitato in x86/amd64 e in ARM NTOS lo blocca.

  DEPPolicy può essere disabilitato o abilitato usando i comandi seguenti in WMI o in uno script di PowerShell:

  • Per disabilitare DEP, digitare bcdedit.exe /set {current} nx AlwaysOff
  • Per abilitare DEP, digitare bcdedit.exe /set {current} nx AlwaysOn

  Se DEPPolicy = 1 (Attivato), consentire l'accesso.

  Se DEPPolicy = 0 (Off), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Consentire l'accesso condizionale in base ad altri punti dati presenti in fase di valutazione. Ad esempio, altri attributi nel certificato di integrità o le attività passate e la cronologia di attendibilità di un dispositivo.
  • Eseguire una delle azioni precedenti e inserire inoltre il dispositivo in un elenco di watch per monitorare il dispositivo più da vicino per potenziali rischi.

  La valutazione dei criteri DEP è uno stato non binario quando viene eseguita una query. Viene quindi mappato a uno stato On/Off.

  Livello di criteri DEP	Descrizione	Livello di attestazione segnalato	Valore proprietà
  OptIn (configurazione predefinita)	Sono stati applicati solo i componenti e i servizi di sistema Windows.	0	2
  OptOut	DEP è abilitato per tutti i processi. Gli amministratori possono creare manualmente un elenco di applicazioni specifiche a cui non è stato applicato DEP.	1	3
  AlwaysOn	DEP è abilitato per tutti i processi.	3	1
  AlwaysOff	DEP non è abilitato per alcun processo.	2	0

• BitLockerStatus (segnala se BitLocker è stato abilitato durante l'avvio iniziale):

  Quando BitLocker viene segnalato "attivato" al momento dell'avvio, il dispositivo è in grado di proteggere i dati archiviati nell'unità dall'accesso non autorizzato, quando il sistema è spento o passa all'ibernazione.

  Crittografia unità BitLocker di Windows, crittografa tutti i dati archiviati nel volume del sistema operativo Windows. BitLocker usa il TPM per proteggere i dati utente e del sistema operativo Windows e garantisce che un computer non venga manomesso, anche se viene lasciato incustodito, smarrito o rubato.

  Se il computer è dotato di un TPM compatibile, BitLocker usa il TPM per bloccare le chiavi di crittografia che proteggono i dati. Di conseguenza, non è possibile accedere alle chiavi finché il TPM non verifica lo stato del computer.

  Se BitLockerStatus = 1 (Attivato), consentire l'accesso.

  Se BitLockerStatus = 0 (Disattivato), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Consentire l'accesso condizionale in base ad altri punti dati presenti in fase di valutazione. Ad esempio, altri attributi nel certificato di integrità o le attività passate e la cronologia di attendibilità di un dispositivo.
  • Eseguire una delle azioni precedenti e inserire inoltre il dispositivo in un elenco di watch per monitorare il dispositivo più da vicino per potenziali rischi.

• BootManagerRevListVersion: questo attributo indica la versione di Boot Manager in esecuzione nel dispositivo, per consentire di tenere traccia e gestire la sicurezza della sequenza o dell'ambiente di avvio.

  Se BootManagerRevListVersion = [CurrentVersion], consentire l'accesso.

  Se BootManagerRevListVersion != [CurrentVersion], eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI e MBI.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.
  • Attivare un'azione correttiva, ad esempio informare il team di supporto tecnico di contattare il proprietario per analizzare il problema.

• CodeIntegrityRevListVersion: questo attributo indica la versione del codice che esegue controlli di integrità durante la sequenza di avvio. L'uso di questo attributo consente di rilevare se il dispositivo esegue la versione più recente del codice che esegue controlli di integrità o se è esposto a rischi per la sicurezza (revocati) e applicare un'azione di criteri appropriata.

  Se CodeIntegrityRevListVersion = [CurrentVersion], consentire l'accesso.

  Se CodeIntegrityRevListVersion != [CurrentVersion], eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI e MBI.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.
  • Attivare un'azione correttiva, ad esempio informare il team di supporto tecnico di contattare il proprietario per analizzare il problema.

• SecureBootEnabled: quando l'avvio protetto è abilitato, i componenti di base usati per avviare il computer devono avere firme crittografiche corrette attendibili dall'organizzazione che ha prodotto il dispositivo. Il firmware UEFI verifica questo requisito prima che consenta l'avvio del computer. Se i file sono stati manomessi, interrompendo la firma, il sistema non verrà avviato.

  Se SecureBootEnabled = 1 (True), consentire l'accesso.

  Se SecurebootEnabled = 0 (False), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Consentire l'accesso condizionale in base ad altri punti dati presenti in fase di valutazione. Ad esempio, altri attributi nel certificato di integrità o le attività passate e la cronologia di attendibilità di un dispositivo.
  • Eseguire una delle azioni precedenti e inserire inoltre il dispositivo in un elenco di watch per monitorare il dispositivo più da vicino per potenziali rischi.

• BootDebuggingEnabled: l'avvio abilitato per il debug punta a un dispositivo usato per lo sviluppo e il test. I dispositivi usati per il test e lo sviluppo sono in genere meno sicuri: il dispositivo può eseguire codice instabile o essere configurato con meno restrizioni di sicurezza necessarie per il test e lo sviluppo.

  Il debug di avvio può essere disabilitato o abilitato usando i comandi seguenti in WMI o in uno script di PowerShell:

  • Per disabilitare il debug di avvio, digitare bcdedit.exe /set {current} bootdebug off.
  • Per abilitare il debug di avvio, digitare bcdedit.exe /set {current} bootdebug on.

  Se BootdebuggingEnabled = 0 (False), consentire l'accesso.

  Se BootDebuggingEnabled = 1 (True), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.
  • Attivare un'azione correttiva, ad esempio l'abilitazione di VSM tramite WMI o uno script di PowerShell.

• OSKernelDebuggingEnabled: OSKernelDebuggingEnabled punta a un dispositivo usato per lo sviluppo e il test. I dispositivi usati per il test e lo sviluppo sono in genere meno sicuri: possono eseguire codice instabile o essere configurati con meno restrizioni di sicurezza necessarie per il test e lo sviluppo.

  Se OSKernelDebuggingEnabled = 0 (False), consentire l'accesso.

  Se OSKernelDebuggingEnabled = 1 (True), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.
  • Attivare un'azione correttiva, ad esempio informare il team di supporto tecnico di contattare il proprietario per analizzare il problema.

• CodeIntegrityEnabled: quando l'integrità del codice è abilitata, l'esecuzione del codice è limitata al codice verificato per l'integrità.

  L'integrità del codice è una funzionalità che convalida l'integrità di un driver o di un file di sistema ogni volta che viene caricato in memoria. L'integrità del codice rileva se un driver non firmato o un file di sistema viene caricato nel kernel o se un file di sistema è stato modificato da software dannoso eseguito da un account utente con privilegi di amministratore.

  Nelle versioni basate su x64 del sistema operativo, i driver in modalità kernel devono essere firmati digitalmente.

  Se CodeIntegrityEnabled = 1 (True), consentire l'accesso.

  Se CodeIntegrityEnabled = 0 (False), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Consentire l'accesso condizionale in base ad altri punti dati presenti in fase di valutazione. Ad esempio, altri attributi nel certificato di integrità o le attività passate e la cronologia di attendibilità di un dispositivo.
  • Eseguire una delle azioni precedenti e inserire inoltre il dispositivo in un elenco di watch per monitorare il dispositivo più da vicino per potenziali rischi.

• TestSigningEnabled: quando la firma di test è abilitata, il dispositivo non applica la convalida della firma durante l'avvio e consente il caricamento dei driver non firmati, ad esempio moduli UEFI non firmati, durante l'avvio.

  La firma di test può essere disabilitata o abilitata usando i comandi seguenti in WMI o in uno script di PowerShell:

  • Per disabilitare il debug di avvio, digitare bcdedit.exe /set {current} testsigning off.
  • Per abilitare il debug di avvio, digitare bcdedit.exe /set {current} testsigning on.

  Se TestSigningEnabled = 0 (False), consentire l'accesso.

  Se TestSigningEnabled = 1 (True), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI e MBI.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.
  • Attivare un'azione correttiva, ad esempio l'abilitazione della firma di test tramite WMI o uno script di PowerShell.

• SafeMode: la modalità provvisoria è un'opzione di risoluzione dei problemi per Windows che avvia il computer in uno stato limitato. Vengono avviati solo i file e i driver di base necessari per eseguire Windows.

  Se SafeMode = 0 (False), consentire l'accesso.

  Se SafeMode = 1 (True), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Attivare un'azione correttiva, ad esempio informare il team di supporto tecnico di contattare il proprietario per analizzare il problema.

• WinPE: Windows Pre-installation Environment (Windows PE) è un sistema operativo minimo con servizi limitati che viene usato per preparare un computer per l'installazione di Windows, per copiare immagini del disco da un file server di rete e per avviare l'installazione di Windows.

  Se WinPE = 0 (False), consentire l'accesso.

  Se WinPE = 1 (True), limitare l'accesso alle risorse remote necessarie per l'installazione del sistema operativo Windows.

• ELAMDriverLoaded (Windows Defender): per usare questa funzionalità di creazione di report, è necessario disabilitare "Hybrid Resume" nel dispositivo. L'antimalware di avvio anticipato (ELAM) fornisce protezione per i computer nella rete all'avvio e prima dell'inizializzazione dei driver di terze parti.

  Nella versione corrente questo attributo monitora/segnala solo se è stato caricato un ELAM di prima parte (Windows Defender) Microsoft durante l'avvio iniziale.

  Se è previsto che un dispositivo usi un programma antivirus di terze parti, ignorare lo stato segnalato.

  Se è previsto che un dispositivo usi Windows Defender e ELAMDriverLoaded = 1 (True), consenti l'accesso.

  Se si prevede che un dispositivo usi Windows Defender e ELAMDriverLoaded = 0 (False), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Attivare un'azione correttiva, ad esempio informare il team di supporto tecnico di contattare il proprietario per analizzare il problema.

• VSMEnabled: la modalità di protezione virtuale (VSM) è un contenitore che protegge gli asset di valore elevato da un kernel compromesso. VSM richiede circa 1 GB di memoria: ha funzionalità sufficienti per eseguire il servizio LSA usato per tutte le negoziazioni di autenticazione.

  È possibile abilitare VSM usando il comando seguente in WMI o uno script di PowerShell:

  bcdedit.exe /set {current} vsmlaunchtype auto

  Se VSMEnabled = 1 (True), consentire l'accesso. Se VSMEnabled = 0 (False), eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Non consentire l'accesso agli asset HBI.
  • Attivare un'azione correttiva, ad esempio informare il team di supporto tecnico di contattare il proprietario per indagare sul problema

• PCRHashAlgorithmID: questo attributo è un attributo informativo che identifica l'algoritmo HASH usato da TPM; non è necessaria alcuna azione di conformità.

• BootAppSVN: questo attributo identifica il numero di versione di sicurezza dell'applicazione di avvio caricata durante l'avvio iniziale nel dispositivo attestato

  Se BootAppSVN segnalato è uguale a un valore accettato, consentire l'accesso.

  Se BootAppSVN segnalato non equivale a un valore accettato, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Indirizzare il dispositivo a un honeypot aziendale, per monitorare ulteriormente le attività del dispositivo.

• BootManagerSVN: questo attributo identifica il numero di versione di sicurezza di Boot Manager caricato durante l'avvio iniziale nel dispositivo attestato.

  Se BootManagerSVN segnalato è uguale a un valore accettato, consentire l'accesso.

  Se BootManagerSVN segnalato non equivale a un valore accettato, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Indirizzare il dispositivo a un honeypot aziendale, per monitorare ulteriormente le attività del dispositivo.

• TPMVersion: questo attributo identifica la versione del TPM in esecuzione nel dispositivo attestato. Il nodo TPMVersion fornisce le risposte "1" e "2":

  • 1 indica la versione 1.2 della specifica TPM
  • 2 significa specifica TPM versione 2.0

  In base alla risposta ricevuta dal nodo TPMVersion:

  • Se TPMVersion segnalato è uguale a un valore accettato, consentire l'accesso.
  • Se TPMVersion segnalato non equivale a un valore accettato, eseguire una delle azioni seguenti in linea con i criteri aziendali:
    • Non consentire l'accesso
    • Indirizzare il dispositivo a un honeypot aziendale, per monitorare ulteriormente le attività del dispositivo.

• PCR0: la misurazione acquisita in PCR[0] rappresenta in genere una visualizzazione coerente della piattaforma host tra i cicli di avvio. Contiene una misurazione dei componenti forniti dal produttore della piattaforma host.

  I responsabili aziendali possono creare un elenco di valori PCR[0] attendibili, confrontare il valore PCR[0] dei dispositivi gestiti (il valore verificato e segnalato da HAS) con l'elenco consentiti e quindi prendere una decisione di attendibilità in base al risultato del confronto.

  Se l'organizzazione non dispone di un elenco di valori PCR[0] accettati, non eseguire alcuna azione. Se PCR[0] è uguale a un valore allowlist accettato, consentire l'accesso.

  Se PCR[0] non equivale a qualsiasi valore elencato accettato, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Indirizzare il dispositivo a un honeypot aziendale, per monitorare ulteriormente le attività del dispositivo.

• SBCPHash: SBCPHash è la stampa tramite dito dei criteri di configurazione dell'avvio protetto personalizzati caricati durante l'avvio nei dispositivi Windows, ad eccezione dei PC.

  Se SBCPHash non è presente o è un valore consentito accettato, consentire l'accesso.

  Se SBCPHash è presente in DHA-Report e non è un valore consentito, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.

• CIPolicy: questo attributo indica i criteri di integrità del codice che controllano la sicurezza dell'ambiente di avvio.

  Se CIPolicy non è presente o è un valore consentito accettato, consentire l'accesso.

  Se CIPolicy è presente e non è un valore consentito, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Inserire il dispositivo in un elenco di watch per monitorare più attentamente il dispositivo per potenziali rischi.

• BootRevListInfo: questo attributo identifica l'elenco di revisioni di avvio caricato durante l'avvio iniziale nel dispositivo attestato.

  Se la versione di BootRevListInfo segnalata è uguale a un valore accettato, consentire l'accesso.

  Se la versione di BootRevListInfo segnalata non è uguale a un valore accettato, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Indirizzare il dispositivo a un honeypot aziendale, per monitorare ulteriormente le attività del dispositivo.

• OSRevListInfo: questo attributo identifica l'elenco di revisioni del sistema operativo caricato durante l'avvio iniziale nel dispositivo attestato.

  Se la versione di OSRevListInfo segnalata è uguale a un valore accettato, consentire l'accesso.

  Se la versione di OSRevListInfo segnalata non è uguale a un valore accettato, eseguire una delle azioni seguenti in linea con i criteri aziendali:

  • Non consentire alcun tipo di accesso.
  • Indirizzare il dispositivo a un honeypot aziendale, per monitorare ulteriormente le attività del dispositivo.

• HealthStatusMismatchFlags: l'attributo HealthStatusMismatchFlags viene visualizzato se DHA-Service rileva un problema di integrità (mancata corrispondenza) nel DHA-Data riceve dalle soluzioni di gestione dei dispositivi per la convalida.

  Se viene rilevato un problema, nell'attributo HealthStatusMismatchFlags verrà elencato un elenco di elementi del report DHA interessati.

DHA-Report esempio

<?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 and error codes

Codice di errore	Nome errore	Descrizione errore
0	HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED	Questo stato è lo stato iniziale per i dispositivi che non hanno mai partecipato a una sessione DHA.
1	HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED	Questo stato indica che la chiamata Exec del client MDM sul nodo VerifyHealth è stata attivata e ora il sistema operativo sta tentando di recuperare DHA-EncBlob da DHA-Server.
2	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED	Questo stato indica che il dispositivo non è riuscito a recuperare DHA-EncBlob da DHA-Server.
3	HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE	Questo stato indica che il dispositivo ha recuperato correttamente DHA-EncBlob da DHA-Server.
4	HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL	Deprecato in Windows 10 versione 1607.
5	HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL	DHA-CSP non è riuscito a ottenere un'offerta di attestazione.
6	HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY	DHA-CSP non è riuscito ad aprire un handle al provider di crittografia della piattaforma Microsoft.
7	HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL	DHA-CSP non è riuscito nel recupero di Windows AIK
8	HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL	Deprecato in Windows 10 versione 1607.
9	HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION	Versione TPM non valida (la versione TPM non è 1.2 o 2.0)
10	HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL	Nonce non è stato trovato nel Registro di sistema.
11	HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL	ID correlazione non trovato nel Registro di sistema.
12	HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL	Deprecato in Windows 10 versione 1607.
13	HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL	Deprecato in Windows 10 versione 1607.
14	HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL	Errore nelle funzioni di codifica. (Scenario estremamente improbabile)
15	HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL	Deprecato in Windows 10 versione 1607.
16	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML	DHA-CSP non è riuscito a caricare il payload ricevuto da DHA-Service.
17	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML	DHA-CSP ha ricevuto una risposta danneggiata da DHA-Service.
18	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY	DHA-CSP ha ricevuto una risposta vuota da DHA-Service.
19	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK	DHA-CSP non è riuscito a decrittografare la chiave AES dalla richiesta EK.
20	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK	DHA-CSP non è riuscito a decrittografare il certificato di integrità con la chiave AES.
21	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB	DHA-CSP non è riuscito nell'esportazione della chiave pubblica AIK.
22	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY	DHA-CSP non è riuscito a creare un'attestazione con i dati di attestazione AIK.
23	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB	DHA-CSP non è riuscito ad aggiungere il pub AIK al BLOB della richiesta.
24	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT	DHA-CSP non è riuscito ad aggiungere il certificato AIK al BLOB della richiesta.
25	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE	DHA-CSP non è riuscito a ottenere un handle di sessione.
26	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE	DHA-CSP non è riuscito a connettersi al servizio DHA.
27	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND	DHA-CSP non è riuscito a creare un handle di richiesta HTTP.
28	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION	DHA-CSP non è riuscito a impostare le opzioni.
29	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS	DHA-CSP non è riuscito ad aggiungere intestazioni di richiesta.
30	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST	DHA-CSP non è riuscito a inviare la richiesta HTTP.
31	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE	DHA-CSP non è riuscito a ricevere una risposta dal servizio DHA.
32	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS	DHA-CSP non è riuscito a eseguire query sulle intestazioni quando si tenta di ottenere il codice di stato HTTP.
33	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE	DHA-CSP ha ricevuto una risposta vuota da DHA-Service anche se lo stato HTTP era OK.
34	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE	DHA-CSP ha ricevuto una risposta vuota insieme a un codice di errore HTTP da DHA-Service.
35	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER	DHA-CSP non è riuscito a rappresentare l'utente.
36	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR	DHA-CSP non è riuscito ad acquisire gli attivatori PDC necessari per la comunicazione di rete quando il dispositivo è in modalità standby connesso.
0xFFFF	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN	DHA-CSP non è riuscito a causa di un motivo sconosciuto, questo errore è altamente improbabile che si verifichi.
400	Bad_Request_From_Client	DHA-CSP ha ricevuto una richiesta di attestazione non valida (non valida).
404	Endpoint_Not_Reachable	DHA-Service non è raggiungibile da DHA-CSP

Considerazioni sulla sicurezza

DHA ancora la propria attendibilità nel TPM e nelle relative misurazioni. Se le misure TPM possono essere falsificati o manomessi, DHA non può fornire alcuna garanzia di integrità del dispositivo per il dispositivo.

Per altre informazioni, vedere Certificazione TPM del client PC.

Articoli correlati

Riferimento del provider di servizi di configurazione