Compartilhar via

CSP HealthAttestation

  • Artigo

Logótipo do Windows Insider.

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 fornecedor de serviços de configuração do Device HealthAttestation (DHA-CSP) permite que os administradores de TI da empresa avaliem se um dispositivo é efetuado num estado fidedigno e em conformidade e que realizem ações de política empresarial.

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

  • Recolhe registos de arranque de dispositivos, registos de auditoria do Trusted Platform Module (TPM) e o certificado TPM (DHA-BootData) de um dispositivo gerido
  • Reencaminha DHA-BootData para um Serviço de Atestado de Estado de Funcionamento do Dispositivo (DHA-Service)
  • Recebe um blob encriptado (DHA-EncBlob) do DHA-Service e armazena-o numa cache local no dispositivo
  • Recebe pedidos de atestado (DHA-Requests) de um DHA-Enabled MDM e respostas com dados do Atestado de Estado de Funcionamento do Dispositivo (DHA-Data)

A lista seguinte mostra os nós do fornecedor de serviços de configuração HealthAttestation:

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 11, versão 22H2 com KB5046732 [10.0.22621.4541] e posterior
✅Windows 11, versão 24H2 com KB5046617 [10.0.26100.2314] e posterior
✅Windows Insider Preview		 
./Vendor/MSFT/HealthAttestation/AttestErrorMessage

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

Propriedades da estrutura de descrição:

Nome da propriedade Valor de propriedade
Formato chr (cadeia)
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 status de êxito ou falha da última sessão de atestado.

O status é sempre limpo antes de efetuar a chamada de serviço de atestado.

Propriedades da estrutura de descrição:

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

Exemplo:

  • Chamada SyncML Templated:

    <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

Indica ao DHA-CSP para reencaminhar DHA-Data para o servidor MDM.

O tipo de valor é uma cadeia base64.

Propriedades da estrutura de descrição:

Nome da propriedade Valor de propriedade
Formato chr (cadeia)
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 estado de funcionamento do dispositivo exclusiva. CorrelationId é utilizado para correlacionar DHA-Service registos com os eventos do servidor MDM e os registos de eventos do Cliente para depuração e resolução de problemas.

Propriedades da estrutura de descrição:

Nome da propriedade Valor de propriedade
Formato chr (cadeia)
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 atual do protocolo que o cliente está a utilizar para comunicar com o Serviço de Atestado de Estado de Funcionamento.

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 um novo pedido ao DHA-Service e a obter uma nova DHA-EncBlob (um resumo do estado de arranque emitido pelo DHA-Service). Esta opção só deve ser utilizada se o servidor MDM impor uma política de atualização de certificados, que tem de forçar um dispositivo a obter um novo blob encriptado 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
falso (Predefinição) Falso.
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

Obtenha o relatório de sessão de atestado, se existir.

O relatório é armazenado numa chave de registo no respetivo arquivo de inscrição MDM.

Propriedades da estrutura de descrição:

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

Exemplo:

  • Chamada SyncML Templated:

    <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

Obtenha os IDs de correlação do serviço, se existirem.

Se existir mais do que um ID de correlação, estes são separados por ";" na cadeia.

Propriedades da estrutura de descrição:

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

Exemplo:

  • Chamada SyncML Templated:

    <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 nome de domínio completamente qualificado (FQDN) do DHA-Service atribuído para executar o atestado. Se não for atribuído um FQDN, DHA-Cloud (serviço cloud operado e propriedade da Microsoft) serão utilizados como o serviço de atestado predefinido.

Propriedades da estrutura de descrição:

Nome da propriedade Valor de propriedade
Formato chr (cadeia)
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

Devolve a versão máxima do protocolo que este cliente pode suportar.

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 estado de funcionamento do dispositivo contra ataques do tipo man-in-the-middle (MITM) com um valor aleatório protegido por cript que é gerado pelo Servidor MDM. O nonce está no formato hexadecima, 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)
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 do protocolo preferencial que o cliente está configurado para comunicar. Se for superior às versões de protocolo suportadas pelo cliente, utilizará a versão de protocolo mais elevada disponível para o mesmo.

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 a status atual do pedido de estado de funcionamento do dispositivo. Para obter a lista completa de valores de status, veja HealthAttestation CSP status and error codes (Códigos de erro e status do HealthAttestation).

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

Devolve uma máscara de bits de informações que descrevem o estado do TPM. Indica se o TPM do dispositivo está num estado pronto e fidedigno.

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 acionar uma sessão de atestado de forma assíncrona.

Se o processo de atestado for iniciado com êxito, este nó devolverá o código 202 que indica que o pedido foi recebido e processado. Caso contrário, será devolvido um erro.

Propriedades da estrutura de descrição:

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

Exemplo:

  • Chamada SyncML Templated:

    <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 da Entidade Confiadora): este campo contém um identificador que pode ser utilizado para ajudar a determinar o autor da chamada.
    • serviceEndpoint: este campo contém o URL completo da instância do fornecedor do Microsoft Atestado do Azure a ser utilizada para avaliação.
    • nonce: este campo contém um número arbitrário que só pode ser utilizado uma vez numa comunicação criptográfica. Muitas vezes, é um número aleatório ou pseudo-aleatório emitido num protocolo de autenticação para garantir que as comunicações antigas não podem ser reutilizadas em ataques de repetição.
    • aadToken: o token de Microsoft Entra a ser utilizado para autenticação no serviço microsoft Atestado do Azure.
    • cv: este campo contém um identificador (Vetor de Correlação) que será transmitido à chamada de serviço e que pode ser utilizado para diagnóstico fins.

  • 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 um pedido de verificação do estado de funcionamento do dispositivo.

Propriedades da estrutura de descrição:

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

atestado de estado de funcionamento do dispositivo Windows 11

Windows 11 apresenta uma atualização da funcionalidade de atestado de estado de funcionamento do dispositivo. Esta atualização ajuda a adicionar suporte para obter informações mais aprofundadas sobre a segurança de arranque do Windows, suportando uma abordagem de confiança zero à segurança do dispositivo. O atestado de estado de funcionamento do dispositivo no Windows pode ser acedido através do HealthAttestation CSP. Este CSP ajuda a avaliar se um dispositivo é arrancado para um estado fidedigno e conforme e, em seguida, para tomar as medidas adequadas. Windows 11 introduz mais nós subordinados no nó HealthAttestation para que os fornecedores de MDM se liguem ao serviço microsoft Atestado do Azure, que fornece uma abordagem simplificada ao atestado.

O relatório de atestado fornece uma avaliação do estado de funcionamento das propriedades de tempo de arranque do dispositivo para garantir que os dispositivos são automaticamente seguros assim que são ligados. O resultado do atestado de estado de funcionamento pode ser utilizado para permitir ou negar o acesso a redes, aplicações ou serviços, consoante o estado de funcionamento do dispositivo.

Termos utilizados:

  • TPM (Trusted Platform Module): 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, encriptação e assinatura.
  • Funcionalidade DHA (Device HealthAttestation): a funcionalidade Device HealthAttestation (DHA) permite que os administradores de TI empresariais monitorizem remotamente a postura de segurança dos dispositivos geridos através da utilização remota de dados protegidos e atestados por TPM através de um canal de comunicação inviolável e resistente a adulteração.
  • MAA-Session (sessão HealthAttestation do dispositivo baseado no serviço microsoft Atestado do Azure): a sessão HealthAttestation (MAA-Session) baseada no serviço do Microsoft Atestado do Azure descreve o fluxo de comunicação ponto a ponto que é executado numa sessão de atestado de estado de funcionamento do dispositivo.
  • Nós MAA-CSP (Fornecedor de Serviços de Configuração baseado no Microsoft Atestado do Azure): os nós do Fornecedor de Serviços de Configuração adicionados ao Windows 11 para integrar com o Serviço microsoft Atestado do Azure. A seguinte lista de operações é efetuada pelo MAA-CSP:
    • Recebe pedidos de acionador de atestado de um fornecedor de MDM compatível com HealthAttestation.
    • O dispositivo recolhe Provas de Atestado (registos de arranque do dispositivo, registos de auditoria do TPM e o certificado TPM) de um dispositivo gerido.
    • Reencaminha a Prova de Atestado para a instância do Serviço Atestado do Azure, conforme configurado pelo fornecedor de MDM.
    • Recebe um relatório assinado da instância do Serviço Atestado do Azure e armazena-o numa cache local no dispositivo.
  • Ponto final do MAA: o serviço de atestado do Microsoft Azure é um recurso do Azure e cada instância do serviço obtém o URL configurado pelo administrador. O URI gerado é exclusivo por natureza e para efeitos do atestado de estado de funcionamento do dispositivo é conhecido como o ponto final do MAA.
  • JWT (JSON Web Token): O JSON Web Token (JWT) é um método de RFC7519 padrão aberto para transmitir informações de forma segura entre partes como um objeto JSON (JavaScript Object Notation). Estas informações podem ser verificadas e fidedignas porque estão assinadas digitalmente. Os JWTs podem ser assinados com um segredo ou um par de chaves públicas/privadas.

Fluxo de Atestado com o Serviço microsoft Atestado do Azure

Fluxo de Atestado com o Serviço microsoft Atestado do Azure

O fluxo de atestado pode ser geralmente em três passos main:

  • Uma instância do serviço Atestado do Azure é configurada com uma política de atestado adequada. A política de atestado permite ao fornecedor de MDM atestar eventos específicos no arranque, bem como funcionalidades de segurança.
  • O fornecedor de MDM aciona uma chamada para o serviço de atestado e, em seguida, executa um atestado marcar mantendo o relatório pronto para ser obtido.
  • O fornecedor de MDM após verificar se o token é proveniente do serviço de atestado, pode analisar o token de atestado para refletir sobre o estado atestado do dispositivo.

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

Passos de Integração do MAA CSP

  1. Configurar uma instância de fornecedor do MAA: a instância do MAA pode ser criada ao seguir os passos em Início Rápido: Configurar Atestado do Azure com o portal do Azure.

  2. Atualizar o fornecedor com uma política adequada: a instância do MAA deve ser atualizada com uma política adequada. Para obter mais informações, veja 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 o seu rpide Azure Active Directory token o attestURI: Utilize o URL de Atestado gerado no passo 1 e acrescente a versão de API adequada que pretende obter. Para obter mais informações sobre a versão da API, veja Atestado – Atteest Tpm – API REST.

  4. Chame GetAttestReport e descodifica e analise o relatório para garantir que o relatório atestado contém as propriedades necessárias: GetAttestReport devolve o token de atestado assinado como um JWT. O JWT pode ser descodificado 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

Pode encontrar mais informações sobre o atestado TPM aqui: Microsoft Atestado do Azure.

Windows 10 Device HealthAttestation

Termos utilizados:

  • TPM (Trusted Platform Module): 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, encriptação e assinatura.

  • Funcionalidade DHA (Device HealthAttestation): a funcionalidade Device HealthAttestation (DHA) permite que os administradores de TI empresariais monitorizem remotamente a postura de segurança dos dispositivos geridos através da utilização remota de dados protegidos e atestados por TPM através de um canal de comunicação inviolável e resistente a adulteração.

  • Dispositivo compatível com DHA (Dispositivo Com o HealthAttestation ativado): um dispositivo com o HealthAttestation ativado para DHA é um dispositivo de computação (telemóvel, ambiente de trabalho, portátil, tablet, servidor) que executa Windows 10 e suporta a versão 1.2 ou 2.0 do TPM.

  • DHA-Session (Device HealthAttestation session): a sessão Device HealthAttestation (DHA-Session) descreve o fluxo de comunicação ponto a ponto que é executado numa sessão de atestado de estado de funcionamento do dispositivo. A seguinte lista de transações é efetuada numa Sessão DHA:

    Diagrama de sessão healthattestation da sessão de DHA

    • DHA-CSP e comunicação DHA-Service:
      • DHA-CSP reencaminha dados de arranque do dispositivo (DHA-BootData) para DHA-Service
      • DHA-Service respostas com um blob de dados encriptados (DHA-EncBlob)
    • DHA-CSP e comunicação MDM-Server:
      • MDM-Server envia um pedido de verificação do estado de funcionamento do dispositivo para DHA-CSP
      • O DHA-CSP responde com um payload chamado DHA-Data que inclui um blob de dados encriptado (DHA-EncBlob) e um blob de dados assinado (DHA-SignedBlob)
    • comunicação MDM-Server e DHA-Service:
      • MDM-Server publica dados recebidos de dispositivos para DHA-Service
      • DHA-Service analisa os dados que recebe e responde com um relatório de estado de funcionamento do dispositivo (DHA-Report)

  • Dados de sessão de DHA (Dados de sessão do Device HealthAttestation): a seguinte lista de dados é produzida ou consumida numa Transação DHA:

    • DHA-BootData: os dados de arranque do dispositivo (registos TCG, valores PCR, certificado de dispositivo/TPM, arranque e contadores TPM) necessários para validar o estado de funcionamento do arranque do dispositivo.
    • DHA-EncBlob: um relatório de resumo encriptado que DHA-Service problemas a um dispositivo depois de rever o DHA-BootData recebe dos dispositivos.
    • DHA-SignedBlob: é um snapshot assinado do estado atual do runtime de um dispositivo capturado pelo DHA-CSP no momento do atestado de estado de funcionamento do dispositivo.
    • DHA-Data: um blob de dados formatado xML que os dispositivos reencaminham para a validação do estado de funcionamento do dispositivo para DHA-Service através do MDM-Server. DHA-Data tem duas partes:
      • DHA-EncBlob: o blob de dados encriptados que o dispositivo recebe de DHA-Service
      • DHA-SignedBlob: uma snapshot atual do estado de segurança atual do dispositivo gerado pelo DHA-CSP
    • DHA-Report: o relatório emitido por DHA-Service para MDM-Server
    • Nonce: um número criptografo protegido que é gerado pelo MDM-Server, que protege o DHA-Session contra ataques do tipo "man-in-the-middle"

  • MDM ativada para DHA (Solução de gestão de dispositivos ativada pelo Device HealthAttestation): A solução de gestão de dispositivos ativada para O Estado de Funcionamento do Dispositivo (Ativada para DHA) é uma ferramenta de gestão de dispositivos integrada com a funcionalidade DHA. DHA-Enabled soluções de gestão de dispositivos permitem que os gestores de TI empresariais elevem a barra de proteção de segurança para os respetivos dispositivos geridos com base em dados protegidos por hardware (TPM) que podem ser considerados fidedignos, mesmo que um dispositivo seja comprometido por ameaças de segurança avançadas ou pela execução de um sistema operativo malicioso (jailbreak). A seguinte lista de operações é efetuada pela DHA-Enabled-MDM:

    • Ativa a funcionalidade DHA num dispositivo DHA-Enabled
    • Problemas com pedidos de atestado de estado de funcionamento do dispositivo para dispositivos inscritos/geridos
    • Recolhe dados do atestado de estado de funcionamento do dispositivo (DHA-Data) e envia-os para o Serviço de Atestado de Estado de Funcionamento do Dispositivo (DHA-Service) para verificação
    • Obtém o relatório de estado de funcionamento do dispositivo (DHA-Report) do DHA-Service, que aciona a ação de conformidade

  • DHA-CSP (Device HealthAttestation Configuration Service Provider): O Fornecedor de Serviços de Configuração da Estação de Funcionamento do Dispositivo (DHA-CSP) utiliza o TPM e firmware de um dispositivo para medir as propriedades de segurança críticas do BIOS e do arranque do Windows do dispositivo, de modo a que, mesmo num sistema infetado com software maligno ao nível do kernel ou um rootkit, estas propriedades não possam ser falsificadas. A seguinte lista de operações é efetuada pelo DHA-CSP:

    • Recolhe dados de arranque do dispositivo (DHA-BootData) de um dispositivo gerido
    • Reencaminha DHA-BootData para o Serviço de Atestado de Estado de Funcionamento do Dispositivo (DHA-Service)
    • Recebe um blob encriptado (DHA-EncBlob) do DHA-Service e armazena-o numa cache local no dispositivo
    • Recebe pedidos de atestado (DHA-Requests) de um DHA-Enabled MDM e respostas com dados do Atestado de Estado de Funcionamento do Dispositivo (DHA-Data)

  • DHA-Service (Device HealthAttestation Service): o Serviço HealthAttestation do Dispositivo (DHA-Service) valida os dados que recebe do DHA-CSP e emite um relatório protegido por hardware (DHA-Report) de alta confiança (DHA-Report) para DHA-Enabled soluções de gestão de dispositivos através de um canal de comunicação inviolável e resistente a adulteração. DHA-Service está disponível em dois tipos: "DHA-Cloud" e "DHA-Server2016". DHA-Service suporta vários cenários de implementação, incluindo cenários de cloud, no local, com disponibilidade de ar e híbridos. A seguinte lista de operações é efetuada pelo DHA-Service:

    • Recebe dados de arranque do dispositivo (DHA-BootData) de um dispositivo DHA-Enabled
    • Reencaminha DHA-BootData para o Serviço de Atestado de Estado de Funcionamento do Dispositivo (DHA-Service)
    • Recebe um blob encriptado (DHA-EncBlob) do DHA-Service e armazena-o numa cache local no dispositivo
    • Recebe pedidos de atestado (DHA-Requests) de um DHA-Enabled-MDM e responde com um relatório de estado de funcionamento do dispositivo (DHA-Report)

Diagrama do serviço de Atestado de Estado de Funcionamento para os diferentes serviços do DHS

tipo de DHA-Service Descrição Custo da operação
Atestado de Estado de Funcionamento do Dispositivo – Cloud (DHA-Cloud) DHA-Cloud é uma DHA-Service operada e detida pela Microsoft que é:
  • Disponível no Windows gratuitamente
  • Em execução numa infraestrutura de cloud com elevada disponibilidade e com balanceamento geográfico
  • Suportado pela maioria das soluções de gestão de dispositivos DHA-Enabled como o fornecedor de serviços de atestado de dispositivos predefinido
  • Acessível a todos os dispositivos geridos pela empresa através do seguinte:
    • FQDN = porta has.spserv.microsoft.com
    • Porta = 443
    • Protocolo = TCP
    		•  Sem custos
    Atestado de Estado de Funcionamento do Dispositivo – No Local (DHA-OnPrem) DHA-OnPrem refere-se a DHA-Service em execução no local:
  • Oferecido para Windows Server 2016 cliente (sem custos de licenciamento adicionados para ativar/executar o DHA-Service)
  • Alojado num dispositivo/hardware de servidor gerido e pertencente à empresa
  • Suportado por fornecedores de soluções de gestão de dispositivos de 1.º e 3.º DHA-Enabled que suportam cenários de atestado de hardware no local e híbrido (Cloud + OnPrem)
  • Acessível a todos os dispositivos geridos pela empresa através das seguintes definições:
    • FQDN = (empresa atribuída)
    • Porta = (empresa atribuída)
    • Protocolo = TCP
    		•  O custo da operação de execução de uma ou mais instâncias do Server 2016 no local.
    Atestado de Estado de Funcionamento do Dispositivo - cloud do Enterprise-Managed (DHA-EMC) O DHA-EMC refere-se a um DHA-Service gerido pela empresa que está a ser executado como um anfitrião/serviço virtual num Windows Server 2016 compatível - serviço cloud gerido pela empresa, como o Microsoft Azure.
  • Oferecido para Windows Server 2016 clientes sem custos adicionais de licenciamento (sem custos de licenciamento adicionais para ativar/executar o DHA-Service)
  • Suportado por fornecedores de soluções de gestão de dispositivos de 1.º e 3.º DHA-Enabled que suportam cenários de atestado de hardware no local e híbrido (Cloud + OnPrem)
  • Acessível a todos os dispositivos geridos pela empresa através das seguintes definições:
    • FQDN = (empresa atribuída)
    • Porta = (empresa atribuída)
    • Protocolo = TCP
    		•  O custo da operação de execução do Server 2016 num serviço cloud compatível, como o Microsoft Azure.

    Passos de integração DHA-CSP

    A seguinte lista de tarefas de validação e desenvolvimento é necessária para integrar a funcionalidade Deteção do Estado de Funcionamento do Dispositivo Microsoft com uma solução de gestão de dispositivos Windows Mobile (MDM):

    1. Verificar o acesso HTTPS
    2. Atribuir um DHA-Service fidedigno empresarial
    3. Instruir o cliente para preparar dados DHA para verificação
    4. Tomar medidas com base na resposta dos clientes
    5. Instruir o cliente para reencaminhar dados DHA para verificação
    6. Publicar dados de DHA no serviço DHA
    7. Receber resposta do serviço DHA
    8. Analisar DHA-Report dados. Tomar as medidas de política adequadas com base nos resultados da avaliação

    Cada passo é descrito em detalhe nas secções seguintes deste tópico.

    Passo 1: Verificar o acesso HTTPS

    Confirme que tanto o servidor MDM como o dispositivo (cliente MDM) podem aceder has.spserv.microsoft.com através do protocolo TCP através da porta 443 (HTTPS).

    Pode utilizar o OpenSSL para validar o acesso ao DHA-Service. Eis um comando OpenSSL de exemplo e a resposta que foi 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)

    Passo 2: Atribuir um DHA-Service fidedigno da empresa

    Existem três tipos de DHA-Service:

    • Atestado de Estado de Funcionamento do Dispositivo – Cloud (propriedade e operado pela Microsoft)
    • Atestado de Estado de Funcionamento do Dispositivo – no Local (propriedade e operado por uma empresa, é executado no Windows Server 2016 no local)
    • Atestado de Estado de Funcionamento do Dispositivo – Enterprise-Managed Cloud (pertencente e operado por uma empresa, é executado em Windows Server 2016 cloud gerida por empresas compatível)

    DHA-Cloud é a predefinição. Não é necessária mais nenhuma ação se uma empresa estiver a planear utilizar o Microsoft DHA-Cloud como fornecedor de DHA-Service fidedigno.

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

    O exemplo seguinte mostra uma chamada de exemplo que instrui um dispositivo gerido a comunicar com um DHA-Service gerido pela empresa.

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

    Passo 3: Instruir o cliente para preparar os dados de estado de funcionamento para verificação

    Envie uma chamada SyncML para iniciar a recolha de DHA-Data.

    O exemplo seguinte mostra uma chamada de exemplo que aciona a recolha e verificação de dados do atestado de estado de funcionamento a partir de um dispositivo gerido.

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

    Passo 4: tomar medidas com base na resposta do cliente

    Depois de o cliente receber o pedido de atestado de estado de funcionamento, envia uma resposta. A lista seguinte descreve as respostas, juntamente com uma ação recomendada a tomar.

    • Se a resposta for HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE (3), avance para a secção seguinte.
    • Se a resposta for HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) ou HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) aguardar um alerta, avance para a secção seguinte.

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

    Passo 5: Instruir o cliente para reencaminhar os dados do atestado de estado de funcionamento para verificação

    Crie uma chamada para os nós Nonce, Certificate e CorrelationId e recolha um payload encriptado que inclua um certificado de estado de funcionamento 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>

    Passo 6: reencaminhar os dados do atestado de estado de funcionamento do dispositivo para o serviço DHA

    Em resposta ao pedido que foi enviado no passo anterior, o cliente MDM reencaminha um blob formatado XML (resposta do nó ./Vendor/MSFT/HealthAttestation/Certificate) e um identificador de chamada denominado CorrelationId (resposta ao nó ./Vendor/MSFT/HealthAttestation/CorrelationId).

    Quando o MDM-Server recebe os dados acima, tem de:

    • Registe o CorrelationId que recebe do dispositivo (para resolução de problemas/referência futura), correlacionado com a chamada.

    • Descodificar o blob de dados formatados XML que recebe do dispositivo

    • Acrescente o nonce que foi gerado pelo serviço MDM (adicione o nonce que foi reencaminhado para o dispositivo no Passo 5) à estrutura XML que foi reencaminhada 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>

    • Reencaminhar (HTTP Post) a estrutura de dados XML (incluindo o nonce que foi acrescentado no passo anterior) para o DHA-Service atribuído que é executado em:

      • DHA-Cloud (serviço DHA-Service da Microsoft: https://has.spserv.microsoft.com/DeviceHealthAttestation/ValidateHealthCertificate/v3
      • DHA-OnPrem ou DHA-EMC: https://FullyQualifiedDomainName-FDQN/DeviceHealthAttestation/ValidateHealthCertificate/v3

    Passo 7: Receber resposta do serviço DHA

    Quando o Serviço de Atestado do Estado de Funcionamento do Dispositivo microsoft recebe um pedido de verificação, executa os seguintes passos:

    • Desencripta os dados encriptados que recebe.
    • Valida os dados que recebeu.
    • Cria um relatório e partilha os resultados da avaliação com o servidor MDM através de SSL no formato XML.

    Passo 8: Tomar as medidas de política adequadas com base nos resultados da avaliação

    Depois de o servidor MDM receber os dados verificados, as informações podem ser utilizadas para tomar decisões de política ao avaliar os dados. Algumas ações possíveis seriam:

    • Permitir o acesso ao dispositivo.
    • Permita que o dispositivo aceda aos recursos, mas sinalize o dispositivo para uma investigação mais aprofundada.
    • Impedir que um dispositivo aceda a 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 seguinte lista de pontos de dados é verificada pela DHA-Service na DHA-Report versão 3.

    • Emitido: a data e hora em que o DHA-report foi avaliado ou emitido para a MDM.

    • AIKPresent: quando uma Chave de Identidade de Atestado (AIK) está presente num dispositivo, indica que o dispositivo tem um certificado de chave de endossamento (EK). Pode ser considerado fidedigno mais do que um dispositivo que não tem um certificado EK.

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

      Se AIKPresent = Falso (0), efetue uma das seguintes ações que se alinham com as políticas da sua empresa:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Permitir o acesso condicional com base noutros pontos de dados que estão presentes no momento da avaliação. Por exemplo, outros atributos no certificado de estado de funcionamento ou as atividades anteriores e o histórico de confiança de um dispositivo.
      • Efetue uma das ações anteriores e coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

    • ResetCount (Comunicado apenas para dispositivos que suportam o TPM 2.0): este atributo comunica o número de vezes que um dispositivo PC hibernado ou retomado.

    • RestartCount (Comunicado apenas para dispositivos que suportam o TPM 2.0): este atributo reporta o número de vezes que um dispositivo PC foi reiniciado.

    • DEPPolicy: um dispositivo pode ser mais fidedigno se a Política de DEP estiver ativada no dispositivo.

      A Política de Prevenção de Execução de Dados (DEP) define um conjunto de tecnologias de hardware e software que efetuam verificações adicionais na memória para ajudar a impedir a execução de código malicioso num sistema. O arranque seguro permite uma lista limitada em x86/amd64 e no ARM NTOS bloqueia-a.

      O DEPPolicy pode ser desativado ou ativado através dos seguintes comandos no WMI ou num script do PowerShell:

      • Para desativar o DEP, escreva bcdedit.exe /set {current} nx AlwaysOff
      • Para ativar o DEP, escreva bcdedit.exe /set {current} nx AlwaysOn

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

      Se DEPPolicy = 0 (Desativado), efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Permitir o acesso condicional com base noutros pontos de dados que estão presentes no momento da avaliação. Por exemplo, outros atributos no certificado de estado de funcionamento ou as atividades anteriores e o histórico de confiança de um dispositivo.
      • Efetue uma das ações anteriores e coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

      A avaliação da política DEP é uma status não binária quando consultada. Em seguida, é mapeado para um estado Ativado/Desativado.

      Nível de política de DEP Descrição Nível reportado do atestado Valor de propriedade
      OptIn (configuração predefinida) Apenas os componentes e serviços do sistema Windows têm o DEP aplicado. 0 2
      OptOut O DEP está ativado para todos os processos. Os administradores podem criar manualmente uma lista de aplicações específicas que não têm o DEP aplicado. 1 3
      AlwaysOn O DEP está ativado para todos os processos. 3 1
      AlwaysOff O DEP não está ativado para qualquer processo. 2 0

    • BitLockerStatus (Comunica se o BitLocker foi ativado durante o arranque inicial.):

      Quando o BitLocker é comunicado como "ligado" no momento do arranque, o dispositivo é capaz de proteger os dados armazenados na unidade contra acesso não autorizado, quando o sistema está desativado ou entra em hibernação.

      A Encriptação de Unidade BitLocker do Windows encripta todos os dados armazenados no volume do sistema operativo Windows. O BitLocker utiliza o TPM para ajudar a proteger o sistema operativo Windows e os dados do utilizador e ajuda a garantir que um computador não é adulterado, mesmo que seja deixado sem vigilância, perdido ou roubado.

      Se o computador estiver equipado com um TPM compatível, o BitLocker utiliza o TPM para bloquear as chaves de encriptação que protegem os dados. Como resultado, as chaves não podem ser acedidas até que o TPM verifique o estado do computador.

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

      Se BitLockerStatus = 0 (Desativado), efetue uma das seguintes ações que se alinham com as políticas da empresa:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Permitir o acesso condicional com base noutros pontos de dados que estão presentes no momento da avaliação. Por exemplo, outros atributos no certificado de estado de funcionamento ou as atividades anteriores e o histórico de confiança de um dispositivo.
      • Efetue uma das ações anteriores e coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

    • BootManagerRevListVersion: este atributo indica a versão do Gestor de Arranque que está em execução no dispositivo, para permitir que controle e faça a gestão da segurança da sequência/ambiente de arranque.

      Se BootManagerRevListVersion = [CurrentVersion], permita o acesso.

      Se BootManagerRevListVersion != [CurrentVersion], efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso aos recursos do HBI e do MBI.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.
      • Acione uma ação corretiva, como informar a equipa de suporte técnico para contactar o proprietário para investigar o problema.

    • CodeIntegrityRevListVersion: este atributo indica a versão do código que está a realizar verificações de integridade durante a sequência de arranque. A utilização deste atributo pode ajudá-lo a detetar se o dispositivo está a executar a versão mais recente do código que efetua verificações de integridade ou se está exposto a riscos de segurança (revogado) e a impor uma ação de política adequada.

      Se CodeIntegrityRevListVersion = [CurrentVersion], permita o acesso.

      Se CodeIntegrityRevListVersion != [CurrentVersion], efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso aos recursos do HBI e do MBI.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.
      • Acione uma ação corretiva, como informar a equipa de suporte técnico para contactar o proprietário para investigar o problema.

    • SecureBootEnabled: quando o Arranque Seguro está ativado, os componentes principais utilizados para arrancar a máquina têm de ter assinaturas criptográficas corretas que sejam consideradas fidedignas pela organização que fabricou o dispositivo. O firmware UEFI verifica este requisito antes de permitir o arranque do computador. Se algum ficheiro tiver sido adulterado, quebrando a assinatura, o sistema não arranca.

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

      Se SecurebootEnabled = 0 (Falso), efetue uma das seguintes ações que se alinham com as políticas da empresa:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Permitir o acesso condicional com base noutros pontos de dados que estão presentes no momento da avaliação. Por exemplo, outros atributos no certificado de estado de funcionamento ou as atividades anteriores e o histórico de confiança de um dispositivo.
      • Efetue uma das ações anteriores e coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

    • BootDebuggingEnabled: o arranque com depuração ativada aponta para um dispositivo que é utilizado em desenvolvimento e teste. Normalmente, os dispositivos utilizados para teste e desenvolvimento 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 arranque pode ser desativada ou ativada com os seguintes comandos no WMI ou num script do PowerShell:

      • Para desativar a depuração de arranque, escrevabcdedit.exe /set {current} bootdebug off.
      • Para ativar a depuração de arranque, escrevabcdedit.exe /set {current} bootdebug ativado.

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

      Se BootDebuggingEnabled = 1 (Verdadeiro), efetue uma das seguintes ações que se alinham com as políticas da empresa:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.
      • Acione uma ação corretiva, como ativar o VSM com o WMI ou um script do PowerShell.

    • OSKernelDebuggingEnabled: OSKernelDebuggingEnabled aponta para um dispositivo que é utilizado em desenvolvimento e teste. Normalmente, os dispositivos utilizados para teste e desenvolvimento são menos seguros: 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 (Falso), permita o acesso.

      Se OSKernelDebuggingEnabled = 1 (Verdadeiro), efetue uma das seguintes ações alinhadas com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.
      • Acione uma ação corretiva, como informar a equipa de suporte técnico para contactar o proprietário para investigar o problema.

    • CodeIntegrityEnabled: quando a integridade do código está ativada, a execução do código é restringida ao código verificado de integridade.

      A integridade do código é uma funcionalidade que valida a integridade de um controlador ou ficheiro de sistema sempre que é carregado para a memória. A integridade do código deteta se um ficheiro de sistema ou controlador não assinado está a ser carregado para o kernel ou se um ficheiro de sistema foi modificado por software malicioso que está a ser executado por uma conta de utilizador com privilégios de administrador.

      Nas versões baseadas em x64 do sistema operativo, os controladores de modo kernel têm de estar assinados digitalmente.

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

      Se CodeIntegrityEnabled = 0 (Falso), efetue uma das seguintes ações que se alinham com as políticas da empresa:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Permitir o acesso condicional com base noutros pontos de dados que estão presentes no momento da avaliação. Por exemplo, outros atributos no certificado de estado de funcionamento ou as atividades anteriores e o histórico de confiança de um dispositivo.
      • Efetue uma das ações anteriores e coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

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

      A assinatura de teste pode ser desativada ou ativada com os seguintes comandos no WMI ou num script do PowerShell:

      • Para desativar a depuração de arranque, escrevabcdedit.exe /set {current} testsigning off.
      • Para ativar a depuração de arranque, escrevabcdedit.exe /set {current} testsigning on.

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

      Se TestSigningEnabled = 1 (Verdadeiro), efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso aos recursos do HBI e do MBI.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.
      • Acione uma ação corretiva, como ativar a assinatura de teste com o WMI ou um script do PowerShell.

    • Modo seguro: o modo de segurança é uma opção de resolução de problemas para o Windows que inicia o computador num estado limitado. Apenas os ficheiros e controladores básicos necessários para executar o Windows são iniciados.

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

      Se SafeMode = 1 (Verdadeiro), efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Acione uma ação corretiva, como informar a equipa de suporte técnico para contactar o proprietário para investigar o problema.

    • WinPE: o Ambiente de pré-instalação do Windows (Windows PE) é um sistema operativo mínimo com serviços limitados que é utilizado para preparar um computador para a instalação do Windows, para copiar imagens de disco de um servidor de ficheiros de rede e para iniciar a Configuração do Windows.

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

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

    • ELAMDriverLoaded (Windows Defender): para utilizar esta funcionalidade de relatório, tem de desativar o "Currículo Híbrido" no dispositivo. O antimalware de início antecipado (ELAM) fornece proteção para os computadores na sua rede quando iniciam e antes da inicialização de controladores de terceiros.

      Na versão atual, este atributo apenas monitoriza/reporta se um ELAM (Windows Defender) de primeira entidade da Microsoft tiver sido carregado durante o arranque inicial.

      Se se espera que um dispositivo utilize um programa antivírus de terceiros, ignore o estado comunicado.

      Se se espera que um dispositivo utilize o Windows Defender e o ELAMDriverLoaded = 1 (Verdadeiro), permita o acesso.

      Se se espera que um dispositivo utilize o Windows Defender e o ELAMDriverLoaded = 0 (Falso), efetue uma das seguintes ações que se alinham com as políticas da sua empresa:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Acione uma ação corretiva, como informar a equipa de suporte técnico para contactar o proprietário para investigar o problema.

    • VSMEnabled: o Modo De Segurança Virtual (VSM) é um contentor que protege os recursos de valor elevado de um kernel comprometido. O VSM requer cerca de 1 GB de memória – tem capacidade suficiente para executar o serviço LSA utilizado para toda a mediação de autenticação.

      O VSM pode ser ativado com o seguinte comando no WMI ou num script do PowerShell:

      bcdedit.exe /set {current} vsmlaunchtype auto

      Se VSMEnabled = 1 (Verdadeiro), permita o acesso. Se VSMEnabled = 0 (Falso), efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Não permitir o acesso a recursos HBI.
      • Acionar uma ação corretiva, como informar a equipa de suporte técnico para contactar o proprietário para investigar o problema

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

    • BootAppSVN: este atributo identifica o número da versão de segurança da Aplicação de Arranque que foi carregada durante o arranque inicial no dispositivo atestado

      Se o BootAppSVN reportado for igual a um valor aceite, permita o acesso.

      Se o BootAppSVN reportado não for igual a um valor aceite, efetue uma das seguintes ações alinhadas com as políticas empresariais:

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

    • BootManagerSVN: este atributo identifica o número da versão de segurança do Gestor de Arranque que foi carregado durante o arranque inicial no dispositivo atestado.

      Se bootManagerSVN reportado for igual a um valor aceite, permita o acesso.

      Se bootManagerSVN comunicado não for igual a um valor aceite, efetue uma das seguintes ações alinhadas com as políticas empresariais:

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

    • TPMVersion: este atributo identifica a versão do TPM que está a ser executada no dispositivo com atestado. O nó TPMVersion fornece às 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 que recebe do nó TPMVersion:

      • Se tPMVersion reportado for igual a um valor aceite, permita o acesso.
      • Se a TPMVersion reportada não for igual a um valor aceite, efetue uma das seguintes ações que se alinham com as políticas da empresa:
        • Não permitir todo o acesso
        • Direcione o dispositivo para um honeypot empresarial, para monitorizar ainda mais as atividades do dispositivo.

    • PCR0: a medição capturada em PCR[0] normalmente representa uma vista consistente da Plataforma Anfitriã entre ciclos de arranque. Contém uma medição dos componentes fornecidos pelo fabricante da plataforma anfitriã.

      Os gestores empresariais podem criar uma lista de permissões de valores DE PCR fidedignos[0], comparar o valor PCR[0] dos dispositivos geridos (o valor verificado e comunicado por 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 a sua empresa não tiver uma lista de permissões de valores PCR[0] aceites, não efetue qualquer ação. Se PCR[0] for igual a um valor de lista de permissões aceite, permita o acesso.

      Se PCR[0] não for igual a qualquer valor listado aceite, efetue uma das seguintes ações alinhadas com as suas políticas empresariais:

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

    • SBCPHash: SBCPHash é a impressão com o dedo da Política de Configuração de Arranque Seguro Personalizado (SBCP) que foi carregada durante o arranque em dispositivos Windows, exceto PCs.

      Se o SBCPHash não estiver presente ou se for um valor aceite na lista de permissões, permita o acesso.

      Se o SBCPHash estiver presente no DHA-Report e não for um valor na lista de permissões, efetue uma das seguintes ações alinhadas com as políticas empresariais:

      • Não permitir todo o acesso.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

    • CIPolicy: este atributo indica a política de Integridade do Código que está a controlar a segurança do ambiente de arranque.

      Se CIPolicy não estiver presente ou for um valor aceite na lista de permissões, permita o acesso.

      Se CIPolicy estiver presente e não for um valor listado na lista de permissões, efetue uma das seguintes ações que se alinham com as suas políticas empresariais:

      • Não permitir todo o acesso.
      • Coloque o dispositivo numa lista de watch para monitorizar o dispositivo mais detalhadamente quanto a potenciais riscos.

    • BootRevListInfo: este atributo identifica a Lista de Revisão de Arranque que foi carregada durante o arranque inicial no dispositivo com atestado.

      Se a versão de BootRevListInfo reportada for igual a um valor aceite, permita o acesso.

      Se a versão de BootRevListInfo reportada não for igual a um valor aceite, efetue uma das seguintes ações alinhadas com as políticas da empresa:

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

    • OSRevListInfo: este atributo identifica a Lista de Revisão do Sistema Operativo que foi carregada durante o arranque inicial no dispositivo atestado.

      Se a versão reportada de OSRevListInfo for igual a um valor aceite, permita o acesso.

      Se a versão osRevListInfo reportada não for igual a um valor aceite, efetue uma das seguintes ações alinhadas com as suas políticas empresariais:

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

    • HealthStatusMismatchFlags: o atributo HealthStatusMismatchFlags é apresentado se DHA-Service detetar um problema de integridade (erro de correspondência) no DHA-Data recebe das soluções de gestão de dispositivos, para validação.

      Se for detetado um problema, será apresentada uma lista dos elementos de relatório DHA afetados 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>

    HealthAttestation CSP status e códigos de erro

    Código de Erro Nome do Erro Descrição do erro
    0 HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED Este estado é o estado inicial dos dispositivos que nunca participaram numa DHA-Session.
    1 HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED Este estado significa que a chamada Exec do cliente MDM no nó VerifyHealth foi acionada e agora o SO está a tentar obter DHA-EncBlob do DHA-Server.
    2 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED Este estado significa que o dispositivo não conseguiu obter DHA-EncBlob do DHA-Server.
    3 HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE Este estado significa que o dispositivo obteve DHA-EncBlob com êxito 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 cotação de afirmação.
    6 HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY O DHA-CSP falhou ao abrir um identificador para o Fornecedor de Criptografia da Plataforma Microsoft.
    7 HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL O DHA-CSP falhou na obtençã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 TPM inválida (a versão TPM não é 1.2 ou 2.0)
    10 HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL Nonce não foi encontrado no registo.
    11 HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL O ID de Correlação não foi encontrado no registo.
    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 o payload que recebeu do DHA-Service.
    17 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML O DHA-CSP recebeu uma resposta danificada 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 desencriptar a chave AES do desafio EK.
    20 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK O DHA-CSP falhou ao desencriptar o certificado de estado de funcionamento com a chave AES.
    21 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB O DHA-CSP falhou ao exportar a Chave Pública do AIK.
    22 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY O DHA-CSP falhou ao tentar criar uma afirmação com dados de atestado do AIK.
    23 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB O DHA-CSP falhou ao acrescentar o AIK Pub ao blob de pedidos.
    24 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT O DHA-CSP falhou ao acrescentar o Certificado AIK ao blob de pedidos.
    25 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE O DHA-CSP não conseguiu obter um Identificador de sessão.
    26 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE O DHA-CSP não conseguiu ligar ao DHA-Service.
    27 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND O DHA-CSP não conseguiu criar um identificador de pedido HTTP.
    28 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION O DHA-CSP não conseguiu definir opções.
    29 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS O DHA-CSP não conseguiu adicionar cabeçalhos de pedido.
    30 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST O DHA-CSP não conseguiu enviar o pedido HTTP.
    31 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE O DHA-CSP não conseguiu receber uma resposta do DHA-Service.
    32 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS O DHA-CSP não conseguiu consultar os cabeçalhos ao tentar obter código http status.
    33 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE O DHA-CSP recebeu uma resposta vazia de DHA-Service, apesar de a status HTTP estar bem.
    34 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE O DHA-CSP recebeu uma resposta vazia juntamente com um código de erro HTTP do DHA-Service.
    35 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER O DHA-CSP não conseguiu representar o utilizador.
    36 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR O DHA-CSP não conseguiu adquirir os ativadores PDC necessários para a comunicação de rede quando o dispositivo está no modo de espera Ligado.
    0xFFFF HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN O DHA-CSP falhou devido a um motivo desconhecido. É altamente improvável que este erro ocorra.
    400 Bad_Request_From_Client O DHA-CSP recebeu um pedido de atestado incorreto (mal formado).
    404 Endpoint_Not_Reachable DHA-Service não está acessível pelo DHA-CSP

    Considerações sobre segurança

    A DHA ancora a sua confiança no TPM e nas suas medidas. Se as medições do TPM puderem ser falsificadas ou adulteradas, o DHA não pode fornecer qualquer garantia de estado de funcionamento do dispositivo para esse dispositivo.

    Para obter mais informações, veja Certificação TPM de Cliente do PC.

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