CSP HealthAttestation

Importante

Esse CSP contém algumas configurações que estão em desenvolvimento e só se aplicam Windows Insider Preview builds. Essas configurações estão sujeitas a alterações e podem ter dependências de outros recursos ou serviços em versão prévia.

O provedor de serviços de configuração do Device HealthAttestation (DHA-CSP) permite que os administradores de TI corporativos avaliem se um dispositivo é inicializado em um estado confiável e compatível e tomem ações de política corporativa.

A lista a seguir é uma descrição das funções executadas pelo CSP do Device HealthAttestation:

• Coleta logs de inicialização de dispositivo, trilhas de auditoria do TPM (Trusted Platform Module) e o certificado TPM (DHA-BootData) de um dispositivo gerenciado
• Encaminha DHA-BootData para um Serviço de Atestado de Integridade do Dispositivo (DHA-Service)
• Recebe um blob criptografado (DHA-EncBlob) do DHA-Service e o armazena em um cache local no dispositivo
• Recebe solicitações de atestado (DHA-Requests) de um MDM DHA-Enabled e responde com dados de Atestado de Integridade do Dispositivo (DHA-Data)

A lista a seguir mostra os nós do provedor de serviços de configuração healthAttestation:

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

AttestErrorMessage

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows Insider Preview

./Vendor/MSFT/HealthAttestation/AttestErrorMessage

AttestErrorMessage mantém a mensagem de erro para a última sessão de atestado, se retornada pelo serviço de atestado.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter

AttestStatus

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 11, versão 21H2 [10.0.22000] e posterior

./Vendor/MSFT/HealthAttestation/AttestStatus

AttestStatus mantém o código de êxito ou falha status para a última sessão de atestado.

O status é sempre limpo antes de fazer a chamada de serviço de atestar.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	int
Tipo de acesso	Obter

Exemplo:

• Chamada SyncML modelo:

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

• Resposta de exemplo:

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

Certificado

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/Certificate

Instrui o DHA-CSP a encaminhar DHA-Data para o servidor MDM.

O tipo de valor é uma cadeia de caracteres base64.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter

Correlationid

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/CorrelationID

Identifica uma sessão de atestado de integridade do dispositivo exclusiva. CorrelationId é usado para correlacionar os logs de DHA-Service com os eventos do servidor MDM e os logs de eventos do cliente para depuração e solução de problemas.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter

CurrentProtocolVersion

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1709 [10.0.16299] e posterior

./Vendor/MSFT/HealthAttestation/CurrentProtocolVersion

Fornece a versão do protocolo atual que o cliente está usando para se comunicar com o Serviço de Atestado de Integridade.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	int
Tipo de acesso	Obter

ForceRetrieve

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/ForceRetrieve

Instrui o cliente a iniciar uma nova solicitação ao DHA-Service e obter um novo DHA-EncBlob (um resumo do estado de inicialização emitido pelo DHA-Service). Essa opção só deve ser usada se o servidor MDM impor uma política de frescor de certificado, que precisa forçar um dispositivo a obter um blob criptografado novo do DHA-Service.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	bool
Tipo de acesso	Obter, Substituir
Valor Padrão	False

Valores Permitidos:

Valor	Descrição
false (Padrão)	False.
true	Verdade.

GetAttestReport

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 11, versão 21H2 [10.0.22000] e posterior

./Vendor/MSFT/HealthAttestation/GetAttestReport

Recupere o relatório da sessão de atestado se existir.

O relatório é armazenado em uma chave de registro no respectivo repositório de registro de MDM.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter

Exemplo:

• Chamada SyncML modelo:

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

• Dados de exemplo:

  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

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 11, versão 21H2 [10.0.22000] e posterior

./Vendor/MSFT/HealthAttestation/GetServiceCorrelationIDs

Recuperar IDs de correlação de serviço se existirem.

Se houver mais de uma ID de correlação, elas serão separadas por ";" na cadeia de caracteres.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter

Exemplo:

• Chamada SyncML modelo:

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

• Dados de exemplo:

  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

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/HASEndpoint

Identifica o FQDN (nome de domínio totalmente qualificado) do DHA-Service atribuído para executar o atestado. Se um FQDN não for atribuído, DHA-Cloud (serviço de nuvem operado e de propriedade da Microsoft) será usado como o serviço de atestado padrão.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter, Substituir
Valor Padrão	has.spserv.microsoft.com.

MaxSupportedProtocolVersion

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1709 [10.0.16299] e posterior

./Vendor/MSFT/HealthAttestation/MaxSupportedProtocolVersion

Retorna a versão máxima do protocolo que esse cliente pode dar suporte.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	int
Tipo de acesso	Obter

Nonce

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/Nonce

Permite que os MDMs protejam as comunicações de atestado de integridade do dispositivo contra ataques do MITM (tipo de homem no meio) com um valor aleatório protegido por cripta gerado pelo Servidor MDM. O nó está no formato hex, com um tamanho mínimo de 8 bytes e um tamanho máximo de 32 bytes.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Obter, Substituir
Valor Padrão	\0

PreferredMaxProtocolVersion

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1709 [10.0.16299] e posterior

./Vendor/MSFT/HealthAttestation/PreferredMaxProtocolVersion

Fornece a versão máxima de protocolo preferencial pela qual o cliente está configurado para se comunicar. Se isso for maior do que as versões de protocolo suportadas pelo cliente, ele usará a versão de protocolo mais alta disponível para ele.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	int
Tipo de acesso	Obter, Substituir
Valor Padrão	3

Status

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/Status

Fornece o status atual da solicitação de integridade do dispositivo. Para obter a lista completa de valores status, consulte Status de CSP do HealthAttestation e códigos de erro.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	int
Tipo de acesso	Obter

TpmReadyStatus

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1607 [10.0.14393] e posterior

./Vendor/MSFT/HealthAttestation/TpmReadyStatus

Retorna um bitmask de informações que descrevem o estado do TPM. Ele indica se o TPM do dispositivo está em um estado pronto e confiável.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	int
Tipo de acesso	Obter

TriggerAttestation

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 11, versão 21H2 [10.0.22000] e posterior

./Vendor/MSFT/HealthAttestation/TriggerAttestation

Notifica o dispositivo para disparar uma sessão de atestado de forma assíncrona.

Se o processo de atestado for iniciado com êxito, esse nó retornará o código 202 indicando que a solicitação será recebida e processada. Caso contrário, um erro será retornado.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	chr (cadeia de caracteres)
Tipo de acesso	Exec

Exemplo:

• Chamada SyncML modelo:

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

• Campos de dados:

  • rpID (Identificador de Parte Confiável): este campo contém um identificador que pode ser usado para ajudar a determinar o chamador.
  • serviceEndpoint : este campo contém a URL completa da instância do provedor do Microsoft Atestado do Azure a ser usada para avaliação.
  • nonce: este campo contém um número arbitrário que só pode ser usado uma vez em uma comunicação criptográfica. Geralmente, é um número aleatório ou pseudo-aleatório emitido em um protocolo de autenticação para garantir que as comunicações antigas não possam ser reutilizados em ataques de reprodução.
  • aadToken: o token Microsoft Entra a ser usado para autenticação no serviço microsoft Atestado do Azure.
  • cv: esse campo contém um identificador (Vetor de Correlação) que será passado para a chamada de serviço e que pode ser usado para fins diagnóstico.

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

Escopo	Edições	Sistema operacional aplicável
Dispositivo ✅ Usuário ❌	Pro ✅ Corporativo ✅ Educação ✅ Windows SE ✅ Empresa de Internet das Coisas / LTSC Empresa Internet das Coisas ✅	✅Windows 10, versão 1511 [10.0.10586] e posterior

./Vendor/MSFT/HealthAttestation/VerifyHealth

Notifica o dispositivo para preparar uma solicitação de verificação de integridade do dispositivo.

Propriedades da estrutura de descrição:

Nome da propriedade	Valor de propriedade
Formato	null
Tipo de acesso	Exec

atestado de integridade do dispositivo Windows 11

Windows 11 apresenta uma atualização para o recurso de atestado de integridade do dispositivo. Essa atualização ajuda a adicionar suporte para informações mais profundas sobre a segurança de inicialização do Windows, dando suporte a uma abordagem de confiança zero para a segurança do dispositivo. O atestado de integridade do dispositivo no Windows pode ser acessado usando o CSP healthattestation. Esse CSP ajuda a avaliar se um dispositivo é inicializado em um estado confiável e compatível e, em seguida, a tomar as medidas apropriadas. Windows 11 apresenta mais nós filho ao nó HealthAttestation para os provedores de MDM se conectarem ao serviço microsoft Atestado do Azure, que fornece uma abordagem simplificada para atestado.

O relatório de atestado fornece uma avaliação de integridade das propriedades de tempo de inicialização do dispositivo para garantir que os dispositivos sejam automaticamente seguros assim que eles ligarem. O resultado do atestado de integridade pode então ser usado para permitir ou negar acesso a redes, aplicativos ou serviços, dependendo da integridade do dispositivo.

Termos usados:

• TPM (Módulo de Plataforma Confiável): O TPM é uma lógica especializada protegida por hardware que executa uma série de operações de segurança protegidas por hardware, incluindo o fornecimento de armazenamento protegido, geração de números aleatórios, criptografia e assinatura.
• Recurso DHA (Device HealthAttestation): o recurso DHA (Device HealthAttestation) permite que os administradores de TI corporativos monitorem a postura de segurança de dispositivos gerenciados remotamente usando dados protegidos e atestados de hardware por meio de um canal de comunicação resistente a adulterações e adulteração evidente.
• MAA-Session (sessão HealthAttestation do dispositivo baseado em serviço da Microsoft Atestado do Azure): a sessão de healthattestation de dispositivo baseada em serviço da Microsoft Atestado do Azure (MAA-Session) descreve o fluxo de comunicação de ponta a ponta que é executado em uma sessão de atestado de integridade do dispositivo.
• Nós MAA-CSP (Microsoft Atestado do Azure provedor de serviços de configuração baseados): os nós do Provedor de Serviços de Configuração adicionados a Windows 11 para integrar ao Microsoft Atestado do Azure Service. A seguinte lista de operações é executada pelo MAA-CSP:
  • Recebe solicitações de gatilho de atestado de um provedor de MDM habilitado para HealthAttestation.
  • O dispositivo coleta Attestation Evidence (logs de inicialização do dispositivo, trilhas de auditoria do TPM e o certificado TPM) de um dispositivo gerenciado.
  • Encaminha a Evidência de Atestado para a instância Atestado do Azure Serviço, conforme configurado pelo provedor MDM.
  • Recebe um relatório assinado da instância Atestado do Azure Serviço e o armazena em um cache local no dispositivo.
• Ponto de extremidade MAA: o serviço de atestado do Microsoft Azure é um recurso do Azure e cada instância do serviço obtém a URL configurada pelo administrador. O URI gerado é de natureza exclusiva e para fins de atestado de integridade do dispositivo é conhecido como ponto de extremidade MAA.
• JWT (JSON Web Token): JSON Web Token (JWT) é um método de RFC7519 padrão aberto para transmitir informações com segurança entre partes como um objeto JSON (Notação de Objeto JavaScript). Essas informações podem ser verificadas e confiáveis porque são assinadas digitalmente. Os JWTs podem ser assinados usando um segredo ou um par de chaves público/privado.

Fluxo de Atestado com o Microsoft Atestado do Azure Service

O fluxo de atestado pode estar amplamente em três main etapas:

• Uma instância do serviço Atestado do Azure é configurada com uma política de atestado apropriada. A política de atestado permite que o provedor de MDM ateste eventos específicos na inicialização, bem como recursos de segurança.
• O provedor MDM dispara uma chamada para o serviço de atestado, o dispositivo executa um atestado marcar mantendo o relatório pronto para ser recuperado.
• O provedor MDM depois de verificar se o token está vindo do serviço de atestado, ele pode analisar o token de atestado para refletir sobre o estado atestado do dispositivo.

Para obter mais informações, consulte Protocolo de Atestado.

Etapas de integração do CSP do MAA

1. Configurar uma instância do provedor MAA: a instância MAA pode ser criada seguindo as etapas em Início Rápido: Configurar Atestado do Azure usando o portal do Azure.

2. Atualize o provedor com uma política apropriada: a instância MAA deve ser atualizada com uma política apropriada. Para obter mais informações, consulte Como criar uma política de Atestado do Azure.

   Uma política de atestado de exemplo:

   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. Chame TriggerAttestation com seu rpide Azure Active Directory token o attestURI: Use a URL de Atestado gerada na etapa 1 e anexe a versão de api apropriada que você deseja atingir. Para obter mais informações sobre a versão da api, consulte Atestado – Atestar Tpm – API REST.

4. Chame GetAttestReport e decodize e analise o relatório para garantir que o relatório atestado contenha as propriedades necessárias: GetAttestReport retornar o token de atestado assinado como um JWT. O JWT pode ser decodificado para analisar as informações de acordo com a política de atestado.

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

Saiba mais

Mais informações sobre o atestado TPM podem ser encontradas aqui: Microsoft Atestado do Azure.

Windows 10 Device HealthAttestation

Termos usados:

• TPM (Módulo de Plataforma Confiável): O TPM é uma lógica especializada protegida por hardware que executa uma série de operações de segurança protegidas por hardware, incluindo o fornecimento de armazenamento protegido, geração de números aleatórios, criptografia e assinatura.

• Recurso DHA (Device HealthAttestation): o recurso DHA (Device HealthAttestation) permite que os administradores de TI corporativos monitorem a postura de segurança de dispositivos gerenciados remotamente usando dados protegidos e atestados de hardware por meio de um canal de comunicação resistente a adulterações e adulteração evidente.

• Dispositivo habilitado para DHA (dispositivo habilitado para Device HealthAttestation): um dispositivo habilitado para HealthAttestation de Dispositivo (habilitado para DHA) é um dispositivo de computação (telefone, desktop, laptop, tablet, servidor) que executa Windows 10 e dá suporte ao TPM versão 1.2 ou 2.0.

• DHA-Session (sessão do Device HealthAttestation): A sessão DHA-Session (Device HealthAttestation) descreve o fluxo de comunicação de ponta a ponta que é executado em uma sessão de atestado de integridade do dispositivo. A seguinte lista de transações é executada em uma sessão DHA:

  

  • Comunicação DHA-CSP e DHA-Service:
    • O DHA-CSP encaminha dados de inicialização de dispositivo (DHA-BootData) para DHA-Service
    • DHA-Service responde com um blob de dados criptografado (DHA-EncBlob)
  • Comunicação DHA-CSP e MDM-Server:
    • MDM-Server envia uma solicitação de verificação de integridade do dispositivo para o DHA-CSP
    • O DHA-CSP responde com uma carga chamada DHA-Data que inclui um blob de dados criptografado (DHA-EncBlob) e um blob de dados assinado (DHA-SignedBlob)
  • comunicação MDM-Server e DHA-Service:
    • MDM-Server posta dados que recebe de dispositivos para DHA-Service
    • DHA-Service revisa os dados recebidos e responde com um relatório de integridade do dispositivo (DHA-Report)

• Dados da sessão DHA (dados da sessão do Device HealthAttestation): A seguinte lista de dados é produzida ou consumida em uma transação DHA:

  • DHA-BootData: os dados de inicialização do dispositivo (logs TCG, valores de PCR, certificado de dispositivo/TPM, inicialização e contadores TPM) necessários para validar a integridade da inicialização do dispositivo.
  • DHA-EncBlob: um relatório de resumo criptografado que DHA-Service problemas para um dispositivo depois de revisar o DHA-BootData que ele recebe de dispositivos.
  • DHA-SignedBlob: é um instantâneo assinado do estado atual do runtime de um dispositivo que é capturado pelo DHA-CSP na hora do atestado de integridade do dispositivo.
  • DHA-Data: um blob de dados formatado XML que os dispositivos encaminham para a validação da integridade do dispositivo para DHA-Service via MDM-Server. DHA-Data tem duas partes:
    • DHA-EncBlob: o blob de dados criptografado que o dispositivo recebe de DHA-Service
    • DHA-SignedBlob: um instantâneo atual do estado de segurança atual do dispositivo gerado pelo DHA-CSP
  • Relatório DHA: o relatório emitido pelo DHA-Service para MDM-Server
  • Nonce: um número protegido por criptografia gerado pelo MDM-Server, que protege o DHA-Session contra ataques de tipo homem no meio

• Solução de gerenciamento de dispositivo habilitada para MDM habilitada para DHA (Device HealthAttestation habilitado para dispositivo): a solução de gerenciamento de dispositivo habilitado para DHA (habilitado para DHA) é uma ferramenta de gerenciamento de dispositivos integrada ao recurso DHA. DHA-Enabled soluções de gerenciamento de dispositivos permitem que os gerentes de TI corporativos aumentem a barra de proteção de segurança para seus dispositivos gerenciados com base em dados protegidos de hardware (TPM) que podem ser confiáveis mesmo que um dispositivo seja comprometido por ameaças avançadas de segurança ou executando um sistema operacional mal-intencionado (jailbroken). A seguinte lista de operações é executada pelo DHA-Enableed-MDM:

  • Habilita o recurso DHA em um dispositivo DHA-Enabled
  • Emite solicitações de atestado de integridade do dispositivo para dispositivos registrados/gerenciados
  • Coleta dados de atestado de integridade do dispositivo (DHA-Data) e envia-os ao Serviço de Atestado de Integridade do Dispositivo (DHA-Service) para verificação
  • Obtém o relatório de integridade do dispositivo (DHA-Report) do DHA-Service, que dispara a ação de conformidade

• DHA-CSP (Provedor de Serviços de Configuração do Device HealthAttestation): o Provedor de Serviços de Configuração do Device HealthAttestation (DHA-CSP) usa o TPM de um dispositivo e firmware para medir propriedades de segurança críticas da inicialização BIOS e Windows do dispositivo, de modo que mesmo em um sistema infectado com malware no nível do kernel ou um rootkit, essas propriedades não podem ser falsificadas. A seguinte lista de operações é executada pelo DHA-CSP:

  • Coleta dados de inicialização de dispositivo (DHA-BootData) de um dispositivo gerenciado
  • Encaminha DHA-BootData para o Serviço de Atestado de Integridade do Dispositivo (DHA-Service)
  • Recebe um blob criptografado (DHA-EncBlob) do DHA-Service e o armazena em um cache local no dispositivo
  • Recebe solicitações de atestado (DHA-Requests) de um MDM DHA-Enabled e responde com dados de Atestado de Integridade do Dispositivo (DHA-Data)

• DHA-Service (Serviço de HealthAttestation de Dispositivo): o Serviço de HealthAttestation de Dispositivo (DHA-Service) valida os dados recebidos do DHA-CSP e emite um relatório protegido por hardware altamente confiável (DHA-Report) para DHA-Enabled soluções de gerenciamento de dispositivos por meio de um canal de comunicação evidente resistente a adulterações e adulteração. DHA-Service está disponível em dois sabores: "DHA-Cloud" e "DHA-Server2016". DHA-Service dá suporte a vários cenários de implementação, incluindo nuvem, local, ar-gapped e cenários híbridos. A seguinte lista de operações é executada pelo DHA-Service:

  • Recebe dados de inicialização de dispositivo (DHA-BootData) de um dispositivo DHA-Enabled
  • Encaminha DHA-BootData para o Serviço de Atestado de Integridade do Dispositivo (DHA-Service)
  • Recebe um blob criptografado (DHA-EncBlob) do DHA-Service e o armazena em um cache local no dispositivo
  • Recebe solicitações de atestado (DHA-Requests) de um DHA-Enableed-MDM e responde com um relatório de integridade do dispositivo (DHA-Report)

DHA-Service tipo	Descrição	Custo da operação
Atestado de integridade do dispositivo – Nuvem (DHA-Cloud)	DHA-Cloud é um DHA-Service operado e de propriedade da Microsoft que é: Disponível no Windows gratuitamente Em execução em uma infraestrutura de nuvem com alta disponibilidade e balanceamento geográfico Com suporte na maioria das DHA-Enabled soluções de gerenciamento de dispositivos como o provedor de serviços de atestado de dispositivo padrão Acessível a todos os dispositivos gerenciados pela empresa por meio do seguinte: FQDN = porta has.spserv.microsoft.com Porta = 443 Protocolo = TCP	Sem custo
Atestado de integridade do dispositivo – Local(DHA-OnPrem)	DHA-OnPrem refere-se a DHA-Service que está em execução no local: Oferecido para Windows Server 2016 cliente (sem custo de licenciamento adicional para habilitar/executar o DHA-Service) Hospedado em um dispositivo/hardware de servidor gerenciado e de propriedade da empresa Com suporte por provedores de solução de gerenciamento de dispositivos de 1º e 3º DHA-Enabled que dão suporte a cenários de atestado de hardware locais e híbridos (Cloud + OnPrem) Acessível a todos os dispositivos gerenciados pela empresa por meio das seguintes configurações: FQDN = (empresa atribuída) Porta = (empresa atribuída) Protocolo = TCP	O custo de operação da execução de uma ou mais instâncias do Server 2016 local.
Atestado de integridade do dispositivo – Enterprise-Managed Cloud(DHA-EMC)	O DHA-EMC refere-se a um DHA-Service gerenciado pela empresa que está sendo executado como um host/serviço virtual em um serviço de nuvem Windows Server 2016 compatível com a empresa, como o Microsoft Azure. Oferecido para Windows Server 2016 clientes sem custo extra de licenciamento (sem custo adicional de licenciamento para habilitar/executar o DHA-Service) Com suporte por provedores de solução de gerenciamento de dispositivos de 1º e 3º DHA-Enabled que dão suporte a cenários de atestado de hardware locais e híbridos (Cloud + OnPrem) Acessível a todos os dispositivos gerenciados pela empresa por meio das seguintes configurações: FQDN = (empresa atribuída) Porta = (empresa atribuída) Protocolo = TCP	O custo de operação da execução do Server 2016 em um serviço de nuvem compatível, como o Microsoft Azure.

Etapas de integração DHA-CSP

A lista a seguir de tarefas de validação e desenvolvimento são necessárias para integrar o recurso de Atestado de Integridade do Dispositivo Microsoft com uma Solução de gerenciamento de dispositivos Windows Mobile (MDM):

1. Verificar o acesso https
2. Atribuir um DHA-Service confiável à empresa
3. Instruir o cliente a preparar dados DHA para verificação
4. Agir com base na resposta dos clientes
5. Instruir o cliente a encaminhar dados DHA para verificação
6. Postar dados DHA no serviço DHA
7. Receber resposta do serviço DHA
8. Analisar dados DHA-Report. Tomar as medidas políticas apropriadas com base nos resultados da avaliação

Cada etapa é descrita em detalhes nas seções a seguir deste tópico.

Etapa 1: verificar o acesso https

Valide se o servidor MDM e o dispositivo (cliente MDM) podem acessar has.spserv.microsoft.com usando o protocolo TCP na porta 443 (HTTPS).

Você pode usar o OpenSSL para validar o acesso ao DHA-Service. Aqui está um exemplo de comando OpenSSL e a resposta gerada pelo 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)

Etapa 2: atribuir uma DHA-Service confiável da empresa

Há três tipos de DHA-Service:

• Atestado de Integridade do Dispositivo – Nuvem (de propriedade e operado pela Microsoft)
• Atestado de integridade do dispositivo – Local (de propriedade e operado por uma empresa, é executado em Windows Server 2016 local)
• Atestado de integridade do dispositivo – Enterprise-Managed Cloud (de propriedade e operado por uma empresa, é executado em Windows Server 2016 nuvem gerenciada por empresas compatível)

DHA-Cloud é a configuração padrão. Nenhuma ação adicional será necessária se uma empresa estiver planejando usar a Microsoft DHA-Cloud como provedor de DHA-Service confiável.

Para DHA-OnPrem & cenários DHA-EMC, envie um comando SyncML para o nó HASEndpoint para instruir um dispositivo gerenciado a se comunicar com o DHA-Service confiável da empresa.

O exemplo a seguir mostra uma chamada de exemplo que instrui um dispositivo gerenciado a se comunicar com um DHA-Service gerenciado pela empresa.

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

Etapa 3: instruir o cliente a preparar dados de integridade para verificação

Envie uma chamada SyncML para iniciar a coleta do DHA-Data.

O exemplo a seguir mostra uma chamada de exemplo que dispara a coleta e a verificação de dados de atestado de integridade de um dispositivo gerenciado.

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

Etapa 4: agir com base na resposta do cliente

Depois que o cliente recebe a solicitação de atestado de integridade, ele envia uma resposta. A lista a seguir descreve as respostas, juntamente com uma ação recomendada a ser tomada.

• Se a resposta for HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE (3), vá para a próxima seção.
• Se a resposta for HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) ou HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) aguardar um alerta, vá para a próxima seção.

Aqui está um alerta de exemplo emitido pelo 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 a resposta ao nó status não for 0, 1 ou 3, resolva o problema. Para obter a lista completa de códigos status, consulte Status de CSP do HealthAttestation e códigos de erro.

Etapa 5: instruir o cliente a encaminhar dados de atestado de integridade para verificação

Crie uma chamada para os nós Nonce, Certificate e CorrelationId e pegue uma carga criptografada que inclua um certificado de integridade e dados relacionados do dispositivo.

Veja um exemplo:

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

Etapa 6: encaminhar dados de atestado de integridade do dispositivo para o serviço DHA

Em resposta à solicitação enviada na etapa anterior, o cliente MDM encaminha um blob formatado XML (resposta do nó ./Vendor/MSFT/HealthAttestation/Certificate) e um identificador de chamada chamado CorrelationId (resposta ao nó ./Vendor/MSFT/HealthAttestation/CorrelationId).

Quando o MDM-Server recebe os dados acima, ele deve:

• Registre o Log do CorrelationId que ele recebe do dispositivo (para solução de problemas/referência futura), correlacionado à chamada.

• Decodificar o blob de dados formatado XML que ele recebe do dispositivo

• Adicione o nó gerado pelo serviço MDM (adicione o nó que foi encaminhado ao dispositivo na Etapa 5) à estrutura XML que foi encaminhada pelo dispositivo no seguinte formato:

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

• Encaminhar (HTTP Post) o struct de dados XML (incluindo o nó que foi acrescentado na etapa anterior) para o DHA-Service atribuído em que é executado:

  • DHA-Cloud cenário (DHA-Service de propriedade da Microsoft e operado): https://has.spserv.microsoft.com/DeviceHealthAttestation/ValidateHealthCertificate/v3
  • DHA-OnPrem ou DHA-EMC: https://FullyQualifiedDomainName-FDQN/DeviceHealthAttestation/ValidateHealthCertificate/v3

Etapa 7: receber resposta do serviço DHA

Quando o Serviço de Atestado de Integridade de Dispositivos da Microsoft recebe uma solicitação de verificação, ele executa as seguintes etapas:

• Descriptografa os dados criptografados recebidos.
• Valida os dados recebidos.
• Cria um relatório e compartilha os resultados da avaliação para o servidor MDM por meio do SSL no formato XML.

Etapa 8: tomar as medidas políticas apropriadas com base nos resultados da avaliação

Depois que o servidor MDM receber os dados verificados, as informações poderão ser usadas para tomar decisões de política avaliando os dados. Algumas ações possíveis seriam:

• Permitir o acesso ao dispositivo.
• Permitir que o dispositivo acesse os recursos, mas sinalize o dispositivo para uma investigação mais aprofundada.
• Impedir que um dispositivo acesse recursos.

DHA-Report esquema 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>

A lista a seguir de pontos de dados é verificada pelo DHA-Service no DHA-Report versão 3.

• Emitido: o relatório DHA de data e hora foi avaliado ou emitido para MDM.

• AIKPresent: quando um AIK (Chave de Identidade de Atestado) está presente em um dispositivo, ele indica que o dispositivo tem um certificado EK (chave de endosso). Ele pode ser confiável mais do que um dispositivo que não tem um certificado EK.

  Se AIKPresent = True (1), permita o acesso.

  Se AIKPresent = False (0), tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Permitir acesso condicional com base em outros pontos de dados presentes no momento da avaliação. Por exemplo, outros atributos no certificado de integridade ou nas atividades passadas de um dispositivo e no histórico de confiança.
  • Tome uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

• ResetCount (relatado apenas para dispositivos que dão suporte ao TPM 2.0): esse atributo relata o número de vezes que um dispositivo pc hiberna ou é retomado.

• RestartCount (relatado apenas para dispositivos que dão suporte ao TPM 2.0): esse atributo relata o número de vezes que um dispositivo pc foi reiniciado.

• DEPPolicy: um dispositivo pode ser mais confiável se a Política DEP estiver habilitada no dispositivo.

  A política DEP (Prevenção de Execução de Dados) define um conjunto de tecnologias de hardware e software que executam verificações extras na memória para ajudar a impedir que o código mal-intencionado seja executado em um sistema. A inicialização segura permite uma lista limitada em x86/amd64 e no ARM NTOS a bloqueia.

  O DEPPolicy pode ser desabilitado ou habilitado usando os seguintes comandos no WMI ou em um script do PowerShell:

  • Para desabilitar o DEP, digitebcdedit.exe /set {current} nx AlwaysOff
  • Para habilitar o DEP, digitebcdedit.exe /set {current} nx AlwaysOn

  Se DEPPolicy = 1 (Ativado), permita o acesso.

  Se DEPPolicy = 0 (Off), execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Permitir acesso condicional com base em outros pontos de dados presentes no momento da avaliação. Por exemplo, outros atributos no certificado de integridade ou nas atividades passadas de um dispositivo e no histórico de confiança.
  • Tome uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

  A avaliação da política DEP é um status não binário quando consultado. Em seguida, ele é mapeado para um estado de ativação/desativação.

  Nível de política DEP	Descrição	Nível relatado de atestado	Valor de propriedade
  OptIn (configuração padrão)	Somente os componentes e serviços do sistema Windows têm DEP aplicado.	0	2
  OptOut	O DEP está habilitado para todos os processos. Os administradores podem criar manualmente uma lista de aplicativos específicos que não têm DEP aplicado.	1	3
  AlwaysOn	O DEP está habilitado para todos os processos.	3	1
  AlwaysOff	O DEP não está habilitado para nenhum processo.	2	0

• BitLockerStatus (relata se o BitLocker foi habilitado durante a inicialização inicial.):

  Quando o BitLocker é relatado "ativado" na hora da inicialização, o dispositivo é capaz de proteger os dados armazenados na unidade contra acesso não autorizado, quando o sistema é desativado ou vai para hibernação.

  O Windows BitLocker Drive Encryption criptografa todos os dados armazenados no volume do sistema operacional Windows. O BitLocker usa o TPM para ajudar a proteger o sistema operacional Windows e os dados do usuário e ajuda a garantir que um computador não seja adulterado, mesmo que ele seja deixado autônomo, perdido ou roubado.

  Se o computador estiver equipado com um TPM compatível, o BitLocker usará o TPM para bloquear as chaves de criptografia que protegem os dados. Como resultado, as chaves não podem ser acessadas até que o TPM tenha verificado o estado do computador.

  Se BitLockerStatus = 1 (Ativado), permitirá o acesso.

  Se BitLockerStatus = 0 (Off), tome uma das seguintes ações que se alinham com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Permitir acesso condicional com base em outros pontos de dados presentes no momento da avaliação. Por exemplo, outros atributos no certificado de integridade ou nas atividades passadas de um dispositivo e no histórico de confiança.
  • Tome uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

• BootManagerRevListVersion: esse atributo indica a versão do Boot Manager que está em execução no dispositivo, para permitir que você acompanhe e gerencie a segurança da sequência/ambiente de inicialização.

  Se BootManagerRevListVersion = [CurrentVersion], permita o acesso.

  Se BootManagerRevListVersion != [CurrentVersion], execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI e MBI.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.
  • Acione uma ação corretiva, como informar a equipe de suporte técnico a entrar em contato com o proprietário para investigar o problema.

• CodeIntegrityRevListVersion: esse atributo indica a versão do código que está executando verificações de integridade durante a sequência de inicialização. O uso desse atributo pode ajudá-lo a detectar se o dispositivo está executando a versão mais recente do código que executa verificações de integridade ou se ele está exposto a riscos de segurança (revogado) e impor uma ação política apropriada.

  Se CodeIntegrityRevListVersion = [CurrentVersion], permita o acesso.

  Se CodeIntegrityRevListVersion != [CurrentVersion], execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI e MBI.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.
  • Acione uma ação corretiva, como informar a equipe de suporte técnico a entrar em contato com o proprietário para investigar o problema.

• SecureBootEnabled: quando a Inicialização Segura está habilitada, os componentes principais usados para inicializar o computador devem ter assinaturas criptográficas corretas confiáveis pela organização que fabricou o dispositivo. O firmware UEFI verifica esse requisito antes de permitir que o computador comece. Se algum arquivo tiver sido adulterado, quebrando sua assinatura, o sistema não será inicializado.

  Se SecureBootEnabled = 1 (True), permita o acesso.

  Se SecurebootEnabled = 0 (False), tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Permitir acesso condicional com base em outros pontos de dados presentes no momento da avaliação. Por exemplo, outros atributos no certificado de integridade ou nas atividades passadas de um dispositivo e no histórico de confiança.
  • Tome uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

• BootDebuggingEnabled: inicializar pontos habilitados para depuração para um dispositivo que é usado em desenvolvimento e teste. Os dispositivos usados para teste e desenvolvimento normalmente são menos seguros: o dispositivo pode executar código instável ou ser configurado com menos restrições de segurança necessárias para testes e desenvolvimento.

  A depuração de inicialização pode ser desabilitada ou habilitada usando os seguintes comandos no WMI ou em um script do PowerShell:

  • Para desabilitar a depuração de inicialização, digitebcdedit.exe /set {current} bootdebug off.
  • Para habilitar a depuração de inicialização, digitebcdedit.exe /set {current} bootdebug.

  Se BootdebuggingEnabled = 0 (False), permita o acesso.

  Se BootDebuggingEnabled = 1 (True), execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.
  • Disparar uma ação corretiva, como habilitar o VSM usando o WMI ou um script do PowerShell.

• OSKernelDebuggingEnabled: OSKernelDebuggingEnabled aponta para um dispositivo usado em desenvolvimento e teste. Os dispositivos usados para teste e desenvolvimento normalmente são menos seguros: eles podem executar código instável ou ser configurados com menos restrições de segurança necessárias para testes e desenvolvimento.

  Se OSKernelDebuggingEnabled = 0 (False), permitirá o acesso.

  Se OSKernelDebuggingEnabled = 1 (True), tome uma das seguintes ações que se alinham com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.
  • Acione uma ação corretiva, como informar a equipe de suporte técnico a entrar em contato com o proprietário para investigar o problema.

• CodeIntegrityEnabled: quando a integridade do código está habilitada, a execução de código fica restrita ao código verificado pela integridade.

  A integridade do código é um recurso que valida a integridade de um driver ou arquivo do sistema sempre que ele é carregado na memória. A integridade do código detecta se um driver não assinado ou um arquivo do sistema está sendo carregado no kernel ou se um arquivo do sistema foi modificado por software mal-intencionado que está sendo executado por uma conta de usuário com privilégios de administrador.

  Em versões baseadas em x64 do sistema operacional, os drivers do modo kernel devem ser assinados digitalmente.

  Se CodeIntegrityEnabled = 1 (True), permita o acesso.

  Se CodeIntegrityEnabled = 0 (False), tome uma das seguintes ações que se alinham com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Permitir acesso condicional com base em outros pontos de dados presentes no momento da avaliação. Por exemplo, outros atributos no certificado de integridade ou nas atividades passadas de um dispositivo e no histórico de confiança.
  • Tome uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

• TestSigningEnabled: quando a assinatura de teste está habilitada, o dispositivo não impõe a validação de assinatura durante a inicialização e permite que os drivers não assinados (como módulos UEFI não assinados) carreguem durante a inicialização.

  A assinatura de teste pode ser desabilitada ou habilitada usando os seguintes comandos no WMI ou em um script do PowerShell:

  • Para desabilitar a depuração de inicialização, digitebcdedit.exe /set {current} testsigning off.
  • Para habilitar a depuração de inicialização, digitebcdedit.exe /set {current} testsigning.

  Se TestSigningEnabled = 0 (False), permita o acesso.

  Se TestSigningEnabled = 1 (True), execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI e MBI.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.
  • Disparar uma ação corretiva, como habilitar a assinatura de teste usando o WMI ou um script do PowerShell.

• SafeMode: o modo seguro é uma opção de solução de problemas para Windows que inicia seu computador em um estado limitado. Somente os arquivos básicos e os drivers necessários para executar o Windows são iniciados.

  Se SafeMode = 0 (False), permita o acesso.

  Se SafeMode = 1 (True), execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Acione uma ação corretiva, como informar a equipe de suporte técnico a entrar em contato com o proprietário para investigar o problema.

• WinPE: o Windows Pre-installation Environment (Windows PE) é um sistema operacional mínimo com serviços limitados que é usado para preparar um computador para instalação do Windows, copiar imagens de disco de um servidor de arquivo de rede e iniciar a Instalação do Windows.

  Se WinPE = 0 (False), permita o acesso.

  Se WinPE = 1 (True), limite o acesso a recursos remotos necessários para a instalação do sistema operacional Windows.

• ELAMDriverLoaded (Windows Defender): Para usar esse recurso de relatório, você deve desabilitar "Currículo Híbrido" no dispositivo. O ELAM (anti-malware de inicialização antecipada) fornece proteção para os computadores em sua rede quando eles iniciam e antes da inicialização de drivers de terceiros.

  Na versão atual, esse atributo só monitora/relata se um ELAM de primeira parte da Microsoft (Windows Defender) foi carregado durante a inicialização inicial.

  Se espera-se que um dispositivo use um programa antivírus de terceiros, ignore o estado relatado.

  Se espera-se que um dispositivo use Windows Defender e ELAMDriverLoaded = 1 (True), permita o acesso.

  Se espera-se que um dispositivo use Windows Defender e ELAMDriverLoaded = 0 (False), tome uma das seguintes ações que se alinham com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Acione uma ação corretiva, como informar a equipe de suporte técnico a entrar em contato com o proprietário para investigar o problema.

• VSMEnabled: O VSM (Modo de Segurança Virtual) é um contêiner que protege ativos de alto valor de um kernel comprometido. O VSM requer cerca de 1 GB de memória – ele tem capacidade suficiente para executar o serviço LSA usado para toda a intermediação de autenticação.

  O VSM pode ser habilitado usando o seguinte comando no WMI ou em um script do PowerShell:

  bcdedit.exe /set {current} vsmlaunchtype auto

  Se VSMEnabled = 1 (True), permita o acesso. Se VSMEnabled = 0 (False), tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Não permite o acesso a ativos HBI.
  • Disparar uma ação corretiva, como informar a equipe de suporte técnico a entrar em contato com o proprietário para investigar o problema

• PCRHashAlgorithmID: esse atributo é um atributo informativo que identifica o algoritmo HASH usado pelo TPM; nenhuma ação de conformidade necessária.

• BootAppSVN: esse atributo identifica o número da versão de segurança do Aplicativo de Inicialização que foi carregado durante a inicialização inicial no dispositivo atestado

  Se o BootAppSVN relatado for igual a um valor aceito, permita o acesso.

  Se o BootAppSVN relatado não for igual a um valor aceito, tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Direcione o dispositivo para um honeypot empresarial, para monitorar ainda mais as atividades do dispositivo.

• BootManagerSVN: esse atributo identifica o número da versão de segurança do Gerenciador de Inicialização que foi carregado durante a inicialização inicial no dispositivo atestado.

  Se o BootManagerSVN relatado for igual a um valor aceito, permita o acesso.

  Se o BootManagerSVN relatado não for igual a um valor aceito, tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Direcione o dispositivo para um honeypot empresarial, para monitorar ainda mais as atividades do dispositivo.

• TPMVersion: esse atributo identifica a versão do TPM que está em execução no dispositivo atestado. O nó TPMVersion fornece as respostas "1" e "2":

  • 1 significa especificação TPM versão 1.2
  • 2 significa especificação TPM versão 2.0

  Com base na resposta recebida do nó TPMVersion:

  • Se o TPMVersion relatado for igual a um valor aceito, permita o acesso.
  • Se o TPMVersion relatado não for igual a um valor aceito, execute uma das seguintes ações alinhadas com suas políticas corporativas:
    • Não permitir todo o acesso
    • Direcione o dispositivo para um honeypot empresarial, para monitorar ainda mais as atividades do dispositivo.

• PCR0: a medida capturada no PCR[0] normalmente representa uma exibição consistente da Plataforma host entre ciclos de inicialização. Ele contém uma medida de componentes fornecidos pelo fabricante da plataforma host.

  Os gerentes empresariais podem criar uma lista de permissões de valores confiáveis de PCR[0], comparar o valor PCR[0] dos dispositivos gerenciados (o valor verificado e relatado pelo HAS) com a lista de permissões e, em seguida, tomar uma decisão de confiança com base no resultado da comparação.

  Se sua empresa não tiver uma lista de permissões de valores pcr[0] aceitos, não tome nenhuma ação. Se PCR[0] for igual a um valor de lista de permissões aceito, permita o acesso.

  Se o PCR[0] não for igual a nenhum valor listado aceito, tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Direcione o dispositivo para um honeypot empresarial, para monitorar ainda mais as atividades do dispositivo.

• SBCPHash: SBCPHash é a impressão digital da SBCP (Custom Secure Boot Configuration Policy) carregada durante a inicialização em dispositivos Windows, exceto PCs.

  Se o SBCPHash não estiver presente ou for um valor aceito listado por permissão, permita o acesso.

  Se o SBCPHash estiver presente no DHA-Report e não for um valor permitido, tome uma das seguintes ações que se alinham às suas políticas corporativas:

  • Não permitir todo o acesso.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

• CIPolicy: Esse atributo indica a política de Integridade do Código que está controlando a segurança do ambiente de inicialização.

  Se CIPolicy não estiver presente ou for um valor aceito listado por permissão, permita o acesso.

  Se CIPolicy estiver presente e não for um valor listado por permissão, execute uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Coloque o dispositivo em uma lista de watch para monitorar o dispositivo mais de perto para possíveis riscos.

• BootRevListInfo: esse atributo identifica a Lista de Revisão de Inicialização carregada durante a inicialização inicial no dispositivo atestado.

  Se a versão de BootRevListInfo relatada for igual a um valor aceito, permita o acesso.

  Se a versão do BootRevListInfo relatada não for igual a um valor aceito, tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Direcione o dispositivo para um honeypot empresarial, para monitorar ainda mais as atividades do dispositivo.

• OSRevListInfo: esse atributo identifica a Lista de Revisão do Sistema Operacional carregada durante a inicialização inicial no dispositivo atestado.

  Se a versão relatada do OSRevListInfo for igual a um valor aceito, permita o acesso.

  Se a versão relatada do OSRevListInfo não for igual a um valor aceito, tome uma das seguintes ações alinhadas com suas políticas corporativas:

  • Não permitir todo o acesso.
  • Direcione o dispositivo para um honeypot empresarial, para monitorar ainda mais as atividades do dispositivo.

• HealthStatusMismatchFlags: o atributo HealthStatusMismatchFlags será exibido se DHA-Service detectar um problema de integridade (incompatibilidade) no DHA-Data ele recebe de soluções de gerenciamento de dispositivo, para validação.

  Se um problema for detectado, uma lista de elementos de relatório DHA afetados será listada no atributo HealthStatusMismatchFlags.

DHA-Report exemplo

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

Códigos de erro e status de CSP do HealthAttestation

Código de Erro	Nome do erro	Descrição do erro
0	HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED	Esse estado é o estado inicial para dispositivos que nunca participaram de uma DHA-Session.
1	HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED	Esse estado significa que a chamada exec do cliente MDM no nó VerifyHealth foi disparada e agora o sistema operacional está tentando recuperar DHA-EncBlob do DHA-Server.
2	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED	Esse estado significa que o dispositivo não conseguiu recuperar DHA-EncBlob do DHA-Server.
3	HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE	Esse estado significa que o dispositivo recuperou com êxito DHA-EncBlob do DHA-Server.
4	HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL	Preterido no Windows 10, versão 1607.
5	HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL	O DHA-CSP não conseguiu obter uma citação de declaração.
6	HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY	O DHA-CSP falhou ao abrir um identificador para o Provedor de Criptografia da Plataforma Microsoft.
7	HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL	Falha do DHA-CSP na recuperação do Windows AIK
8	HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL	Preterido no Windows 10, versão 1607.
9	HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION	Versão inválida do TPM (a versão do TPM não é 1.2 ou 2.0)
10	HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL	Nonce não foi encontrado no registro.
11	HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL	A ID de correlação não foi encontrada no registro.
12	HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL	Preterido no Windows 10, versão 1607.
13	HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL	Preterido no Windows 10, versão 1607.
14	HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL	Falha nas funções de codificação. (Cenário extremamente improvável)
15	HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL	Preterido no Windows 10, versão 1607.
16	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML	O DHA-CSP não conseguiu carregar a carga recebida do DHA-Service.
17	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML	O DHA-CSP recebeu uma resposta corrompida do DHA-Service.
18	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY	O DHA-CSP recebeu uma resposta vazia do DHA-Service.
19	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK	O DHA-CSP falhou ao descriptografar a chave AES do desafio EK.
20	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK	Falha do DHA-CSP na descriptografação do certificado de integridade com a chave AES.
21	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB	Falha no DHA-CSP na exportação da Chave Pública do AIK.
22	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY	Falha no DHA-CSP ao tentar criar uma declaração com dados de atestado AIK.
23	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB	Falha no DHA-CSP ao acrescentar o AIK Pub ao blob de solicitação.
24	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT	Falha no DHA-CSP ao acrescentar o AIK Cert ao blob de solicitação.
25	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE	O DHA-CSP falhou ao obter um identificador de sessão.
26	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE	O DHA-CSP não conseguiu se conectar ao DHA-Service.
27	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND	O DHA-CSP falhou ao criar um identificador de solicitação HTTP.
28	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION	O DHA-CSP não conseguiu definir opções.
29	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS	Falha no DHA-CSP ao adicionar cabeçalhos de solicitação.
30	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST	O DHA-CSP não enviou a solicitação HTTP.
31	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE	O DHA-CSP não recebeu uma resposta do DHA-Service.
32	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS	O DHA-CSP falhou ao consultar cabeçalhos ao tentar obter o código http status.
33	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE	O DHA-CSP recebeu uma resposta vazia de DHA-Service mesmo que o STATUS HTTP estivesse OK.
34	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE	O DHA-CSP recebeu uma resposta vazia junto com um código de erro HTTP do DHA-Service.
35	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER	O DHA-CSP falhou ao representar o usuário.
36	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR	O DHA-CSP não conseguiu adquirir os ativadores PDC necessários para comunicação de rede quando o dispositivo está no modo de espera conectado.
0xffff	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN	Falha no DHA-CSP devido a um motivo desconhecido, é altamente improvável que esse erro ocorra.
400	Bad_Request_From_Client	O DHA-CSP recebeu uma solicitação de atestado ruim (malformada).
404	Endpoint_Not_Reachable	DHA-Service não é acessível pelo DHA-CSP

Considerações sobre segurança

A DHA ancora sua confiança no TPM e em suas medidas. Se as medidas TPM puderem ser falsificadas ou adulteradas, o DHA não poderá fornecer nenhuma garantia de integridade do dispositivo para esse dispositivo.

Para obter mais informações, consulte Certificação TPM do cliente do computador.

Artigos relacionados

Referência de provedor de serviços de configuração