Comentários

CSP HealthAttestation do dispositivo

  • Artigo
  • 24 minutos para ler

A tabela a seguir mostra a aplicabilidade de Windows:

Edição Windows 10 Windows 11
Home Sim Sim
Pro Sim Sim
Windows SE Não Sim
Negócios Sim Sim
Enterprise Sim Sim
Educação Sim Sim

O provedor de serviços de configuração de Estação de Integridade do Dispositivo (DHA-CSP) permite que os administradores de TI empresariais avaliem se um dispositivo é inicializado para um estado confiável e compatível e executem ações de política corporativa.

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

  • Coleta logs de inicialização do dispositivo, trilhas de auditoria do TPM (Trusted Platform Module) e o certificado TPM (DHA-BootData) de um dispositivo gerenciado
  • Encaminha DHA-BootData 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 (solicitações de DHA) de um MDM do DHA-Enabled e responde com dados de Atestado de Integridade do Dispositivo (DHA-Data)

Windows 11 atestado de integridade do dispositivo

Windows 11 apresenta uma atualização para o recurso de atestado de integridade do dispositivo. Essa atualização ajuda a adicionar suporte para insights mais profundos Windows segurança de inicialização, dando suporte a uma abordagem de confiança zero para a segurança do dispositivo. O atestado de integridade do dispositivo Windows pode ser acessado usando o CSP HealthAttestation. Esse CSP ajuda a avaliar se um dispositivo é inicializado para um estado confiável e em conformidade e, em seguida, para executar a ação apropriada. Windows 11 apresenta mais nós filho ao nó HealthAttestation para que os provedores de MDM se conectem ao serviço de Atestado do Microsoft Azure, que fornece uma abordagem simplificada para o 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 ligarem. O resultado do atestado de integridade pode ser usado para permitir ou negar o acesso a redes, aplicativos ou serviços, dependendo da integridade do dispositivo.

Termos

  • 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úmero aleatório, 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 (TPM) por meio de um canal de comunicação resistente a adulterações e adulterações.

  • Sessão MAA (sessão healthAttestation baseada no serviço de atestado do Microsoft Azure): a sessão de HealthAttestation do dispositivo baseado em serviço de atestado do Microsoft 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 (provedor de serviços de configuração baseados em atestado Microsoft Azure): os nós do Provedor de Serviços de Configuração adicionados ao Windows 11 para integração com o Microsoft Azure de Atestado.

    A lista de operações a seguir é executada pelo MAA-CSP:

    • Recebe solicitações de gatilho de atestado de um provedor de MDM habilitado para HealthAttestation.
    • O dispositivo coleta a Evidência de Atestado (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 do serviço Atestado do Azure conforme configurado pelo provedor de MDM.
    • Recebe um relatório assinado da instância Atestado do Azure Service e o armazena em um cache local no dispositivo.

  • Ponto de extremidade MAA: Microsoft Azure de atestado é um recurso do Azure e cada instância do serviço obtém a URL configurada pelo administrador. O URI gerado é exclusivo por natureza e, para fins de atestado de integridade do dispositivo, é conhecido como o ponto de extremidade MAA.

  • JWT (Token Web JSON): JWT (Token Web JSON) é um método RFC7519 padrão aberto para transmitir informações com segurança entre partes como um objeto JSON (JavaScript Object Notation). 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ública/privada.

Atestado Flow com o serviço Microsoft Azure atestado

Atestado Flow com o serviço Microsoft Azure atestado

O fluxo de atestado pode ser amplamente em três etapas principais:

  • 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 de MDM dispara uma chamada para o serviço de atestado; em seguida, o dispositivo executa uma verificação de atestado mantendo o relatório pronto para ser recuperado.
  • O provedor MDM depois de verificar se o token é proveniente 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 o Protocolo de Atestado.

Nós do Provedor de Serviços de Configuração

Windows 11 apresenta adições ao nó CSP healthAttestation para integração com o serviço Microsoft Azure atestado.

./Vendor/MSFT
HealthAttestation
----...
----TriggerAttestation                    |
----AttestStatus                          | Added in Windows 11
----GetAttestReport                       |
----GetServiceCorrelationIDs              |
----VerifyHealth
----Status
----ForceRetrieve
----Certificate
----Nonce
----CorrelationID
----HASEndpoint
----TpmReadyStatus
----CurrentProtocolVersion
----PreferredMaxProtocolVersion
----MaxSupportedProtocolVersion

./Vendor/MSFT/HealthAttestation

O nó raiz do provedor de serviços de configuração HealthAttestation do dispositivo.

TriggerAttestation (obrigatório)

Tipo de nó: EXECUTE

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

Chamada SyncML com 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 Terceira Parte Confiável): esse campo contém um identificador que pode ser usado para ajudar a determinar o chamador.
  • serviceEndpoint: esse campo contém a URL completa da instância do provedor de atestado Microsoft Azure a ser usada para avaliação.
  • nonce: esse campo contém um número arbitrário que pode ser usado apenas 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 reutilizadas em ataques de reprodução.
  • aadToken: o token Azure Active Directory a ser usado para autenticação no serviço Microsoft Azure atestado.
  • 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 de diagnóstico.

Dados de 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" 
}
</Data>

AttestStatus

Tipo de nó: GET

Esse nó recuperará o status (valor HRESULT) armazenado no Registro atualizado pelo processo de atestado disparado na etapa anterior. O status é sempre limpo antes de fazer a chamada de serviço de atestado.

Chamada SyncML com modelo:

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

Dados de exemplo:

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

GetAttestReport

Tipo de nó: GET

Esse nó recuperará o relatório de atestado de acordo com a chamada feita pela TriggerAttestation, se houver, para o provedor de MDM fornecido. O relatório é armazenado em uma chave do Registro no respectivo repositório de registro do MDM.

Chamada SyncML com 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 not cached report available.

GetServiceCorrelationIDs

Tipo de nó: GET

Esse nó recuperará as IDs de correlação geradas pelo serviço para o provedor de MDM fornecido. Se houver mais de uma ID de correlação, elas serão separadas por ";" na cadeia de caracteres.

Chamada SyncML com 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.

Observação

Os nós CSP do MAA estão disponíveis no arm64, mas não têm suporte no momento.

Etapas de integração do CSP do MAA

  1. Configurar uma instância do provedor MAA: a instância do MAA pode ser criada seguindo as etapas em [Início Rápido: Configurar o Atestado do Azure usando o portal do Azure](/azure/attestation/quickstart-portal].

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

    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 token rpid, Azure Active Directory e o atestado: use a URL de Atestado gerada na etapa 1 e acrescente a versão de API apropriada que você deseja atingir. Para obter mais informações sobre a versão da API, consulte Atestado – Attest Tpm – API REST.

  4. Chame GetAttestReport e decodificar e analisar o relatório para garantir que o relatório atestado contenha as propriedades necessárias: GetAttestReport retorna 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 do TPM podem ser encontradas aqui: Microsoft Azure atestado.

Windows 10 HealthAttestation do dispositivo

Termos

  • 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úmero aleatório, 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 (TPM) por meio de um canal de comunicação resistente a adulterações e adulterações.

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

  • Sessão DHA (sessão HealthAttestation do dispositivo): a sessão DHA-Session (Sessão de HealthAtte do Dispositivo) descreve o fluxo de comunicação de ponta a ponta que é executado em uma sessão de atestado de integridade do dispositivo.

    A lista de transações a seguir é executada em uma sessão DHA:

    • DHA-CSP e DHA-Service comunicação:

      • O DHA-CSP encaminha dados de inicialização do dispositivo (DHA-BootData) para DHA-Service
      • DHA-Service respostas com um blob de dados criptografado (DHA-EncBlob)

    • DHA-CSP e MDM-Server comunicação:

      • MDM-Server envia uma solicitação de verificação de integridade do dispositivo para 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)

    • MDM-Server e DHA-Service comunicação:

      • MDM-Server postagem de dados recebidos de dispositivos para DHA-Service
      • DHA-Service revisa os dados recebidos e responde com um relatório de integridade do dispositivo (DHA-Report)

    Diagrama de sessão healthattestation da sessão DHA

  • Dados de sessão de DHA (dados de 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 do 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 a um dispositivo depois de examinar o DHA-BootData que ele recebe dos dispositivos.

    • DHA-SignedBlob: é um instantâneo assinado do estado atual do runtime de um dispositivo capturado pelo DHA-CSP no momento do atestado de integridade do dispositivo.

    • DHA-Data: um blob de dados formatado xml que os dispositivos encaminham para validação de integridade do dispositivo para DHA-Service via MDM-Server. DHA-Data tem duas partes:

      • DHA-EncBlob: o blob de dados criptografados 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

    • DHA-Report: 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 man-in-the-middle

  • MDM habilitado para DHA (solução de gerenciamento de dispositivos habilitado para HealthAttestation): a solução de gerenciamento de dispositivos habilitada para DHA (HealthAttestation) do dispositivo é uma ferramenta de gerenciamento de dispositivo integrada ao recurso DHA.

    DHA-Enabled soluções de gerenciamento de dispositivos permitem que os gerentes de TI empresariais gereçam a barra de proteção de segurança para seus dispositivos gerenciados com base em dados protegidos por hardware (TPM) que podem ser confiáveis, mesmo que um dispositivo seja comprometido por ameaças de segurança avançadas ou executando um sistema operacional mal-intencionado (desbloqueado por jailbreak).

    A lista de operações a seguir é executada por DHA-Enabled-MDM

    • Habilita o recurso DHA em um DHA-Enabled dispositivo
    • Emite solicitações de atestado de integridade do dispositivo para dispositivos registrados/gerenciados
    • Coleta dados de atestado de integridade do dispositivo (DHA-Data) e os envia 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 Dispositivo HealthAttestation): o Provedor de Serviços de Configuração de HealthAttestation do Dispositivo (DHA-CSP) usa o TPM e o firmware de um dispositivo para medir as propriedades de segurança críticas do BIOS e da inicialização do Windows, 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 lista de operações a seguir é executada pelo DHA-CSP:

    • Coleta dados de inicialização do 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 (solicitações de DHA) de um MDM do DHA-Enabled e responde com dados de Atestado de Integridade do Dispositivo (DHA-Data)

  • Serviço DHA (Serviço de HealthAttestation de Dispositivo): o DHA-Service (Serviço de HealthAttestation do Dispositivo) valida os dados recebidos do DHA-CSP e emite um relatório protegido por TPM (hardware altamente confiável) (DHA-Report) para DHA-Enabled soluções de gerenciamento de dispositivos por meio de um canal de comunicação resistente a adulterações e adulterações evidentes.

    DHA-Service está disponível em dois tipos: "DHA-Cloud" e "DHA-Server2016". DHA-Service dá suporte a vários cenários de implementação, incluindo cenários de nuvem, locais, mapeados por ar e híbridos.

    A lista de operações a seguir é executada pelo DHA-Service:

    • Recebe dados de inicialização do dispositivo (DHA-BootData) de um DHA-Enabled dispositivo
    • 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 habilitado para DHA e responde com um relatório de integridade do dispositivo (DHA-Report)

Diagrama do serviço atestado de integridade para os diferentes serviços DHS

DHA-Service tipo Descrição Custo da operação
Atestado de Integridade do Dispositivo – Nuvem (DHA-Cloud) DHA-Cloud é uma empresa de propriedade da Microsoft DHA-Service ou seja:
  • Disponível no Windows gratuitamente
  • Em execução em uma infraestrutura de nuvem de alta disponibilidade e com balanceamento geográfica
  • Compatível com a maioria das DHA-Enabled de gerenciamento de dispositivos como o provedor de serviços de atestado de dispositivo padrão
  • Acessível para todos os dispositivos gerenciados pela empresa por meio do seguinte:
    • FQDN = has.spserv.microsoft.com porta
    • Porta = 443
    • Protocolo = TCP
    		•  Sem custo
    Atestado de Integridade do Dispositivo – Local(DHA-OnPrem) DHA-OnPrem refere-se DHA-Service que está em execução no local:
  • Oferecido para Windows Server 2016 cliente (sem custo de licenciamento adicional para habilitar/executar o serviço DHA)
  • Hospedado em um dispositivo/hardware de servidor gerenciado e corporativo
  • Compatível com provedores de solução de gerenciamento de dispositivos DHA-Enabled de terceiros que dão suporte a cenários de atestado de hardware locais e híbridos (Nuvem + OnPrem)
  • Acessível a todos os dispositivos gerenciados pela empresa por meio das seguintes configurações:
    • FQDN = (atribuído à empresa)
    • Porta = (atribuída pela empresa)
    • Protocolo = TCP
    		•  O custo da 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) A 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 compatível com Windows Server 2016 – gerenciado pela empresa, como Microsoft Azure.
  • Oferecido para Windows Server 2016 clientes sem custo adicional de licenciamento (sem custo de licenciamento adicional para habilitar/executar o DHA-Service)
  • Compatível com provedores de solução de gerenciamento de dispositivos DHA-Enabled de terceiros que dão suporte a cenários de atestado de hardware locais e híbridos (Nuvem + OnPrem)
  • Acessível a todos os dispositivos gerenciados pela empresa por meio das seguintes configurações:
    • FQDN = (atribuído à empresa)
    • Porta = (atribuída pela empresa)
    • Protocolo = TCP
    		•  O custo da operação da execução do Server 2016 em um serviço de nuvem compatível, como Microsoft Azure.

    Diagrama do CSP e descrições de nó

    O exemplo a seguir mostra o provedor de serviços de configuração HealthAttestation do dispositivo no formato de árvore.

    ./Vendor/MSFT
HealthAttestation
----VerifyHealth
----Status
----ForceRetrieve
----Certificate
----Nonce
----CorrelationID
----HASEndpoint
----TpmReadyStatus
----CurrentProtocolVersion
----PreferredMaxProtocolVersion
----MaxSupportedProtocolVersion

    ./Vendor/MSFT/HealthAttestation

    O nó raiz do provedor de serviços de configuração HealthAttestation do dispositivo.

    VerifyHealth (Obrigatório)

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

    A operação com suporte é Execute.

    Status (Obrigatório)

    Fornece o status atual da solicitação de integridade do dispositivo.

    A operação com suporte é Get.

    A lista a seguir mostra alguns exemplos de valores com suporte. Para obter a lista completa de status, consulte status e códigos de erro do CSP healthAttestation do dispositivo.

    • 0 - (HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED): O DHA-CSP está preparando uma solicitação para obter uma nova DHA-EncBlob de DHA-Service
    • 1 - (HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED): O DHA-CSP está aguardando o DHA-Service responder e emitir um DHA-EncBlob para o dispositivo
    • 2 - (HEALTHATTESTATION_CERT_RETRIEVAL_FAILED): não foi possível recuperar um DHA-EncBlob válido do DHA-Service por motivos diferentes dos discutidos nos códigos de erro/status de DHA
    • 3 - (HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE): DHA-Data está pronto para retirada

    ForceRetrieve (opcional)

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

    $True. A operação com suporte é Replace.

    Certificado (Obrigatório)

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

    O tipo de valor é b64. A operação com suporte é Get.

    Nonce (obrigatório)

    Permite que os MDMs protejam as comunicações de atestado de integridade do dispositivo contra ataques MITM (tipo man-in-the-middle) com um valor aleatório protegido por criptografia gerado pelo Servidor MDM.

    O nonce está no formato hexadecimal, com um tamanho mínimo de 8 bytes e um tamanho máximo de 32 bytes.

    As operações com suporte são Get e Replace.

    CorrelationId (obrigatório)

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

    O tipo de valor é inteiro, o valor mínimo é - 2.147.483.648 e o valor máximo é 2.147.483.647. A operação com suporte é Get.

    HASEndpoint (opcional)

    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.

    Tipo de valor é cadeia de caracteres. As operações com suporte são Get e Replace. O valor padrão é has.spserv.microsoft.com.

    TpmReadyStatus (Obrigatório)

    Adicionado no Windows 10, versão 1607 do serviço de março. Retorna uma máscara de bits de informações que descrevem o estado do TPM. Ele indica se o TPM do dispositivo está em um estado pronto e confiável.

    Tipo de valor é número inteiro. A operação com suporte é Get.

    Etapas de integração de DHA-CSP

    A lista a seguir de tarefas de validação e desenvolvimento é necessária para integrar o recurso atestado de integridade do dispositivo da Microsoft com uma solução de gerenciamento de dispositivo móvel (MDM) do Windows:

    1. Verificar o acesso HTTPS
    2. Atribuir uma empresa confiável DHA-Service
    3. Instruir o cliente a preparar dados DHA para verificação
    4. Executar uma ação 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 DHA-Report dados. Executar a ação de política apropriada 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 pela 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 que foi gerada pelo serviço DHA:

    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 empresa confiável DHA-Service

    Há três tipos de serviço de DHA:

    • 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 Windows Server 2016 local)
    • Atestado de Integridade do Dispositivo – Enterprise-Managed Cloud (de propriedade e operado por uma empresa, é executado Windows Server 2016 nuvem gerenciada pela empresa)

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

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

    O exemplo a seguir mostra uma chamada de exemplo que instrui um dispositivo gerenciado a se comunicar com um serviço DHA 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 de dados DHA.

    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: Executar uma ação 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), prossiga para a próxima seção.
    • Se a resposta for HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) ou HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) aguardar um alerta, prossiga para a próxima seção.

    Aqui está um alerta de exemplo que é 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>

    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 inclui 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 que foi enviada na etapa anterior, o cliente MDM encaminha um blob formatado em 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 a CorrelationId que ele recebe do dispositivo (para solução de problemas/referência futura), correlacionada à chamada.

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

    • Acrescente o nonce gerado pelo serviço MDM (adicione o nonce 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 nonce que foi acrescentado na etapa anterior) ao DHA-Service atribuído em que é executado:

      • DHA-Cloud cenário de 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 do Dispositivo 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 de SSL no formato XML.

    Etapa 8: Executar a ação de política apropriada com base nos resultados da avaliação

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

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

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

    * Somente TPM 2.0
    ** Relata se o BitLocker foi habilitado durante a inicialização inicial.
    *** O "Currículo Híbrido" deve ser desabilitado no dispositivo. Relata que o ELAM "Defender" de primeira parte foi carregado durante a inicialização.

    Cada um desses pontos de dados é descrito mais detalhadamente nas seções a seguir, juntamente com as ações recomendadas a serem tomadas.

    Emitido

    A data e a hora em que o relatório DHA foi avaliado ou emitido para o MDM.

    AIKPresent

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

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

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

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de 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 atividades anteriores de um dispositivo e histórico de confiança.
    • Execute uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.

    ResetCount (relatado somente 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 somente para dispositivos que dão suporte ao TPM 2.0)

    Esse atributo relata o número de vezes que um dispositivo pc foi reinicializado.

    DEPPolicy

    Um dispositivo poderá ser mais confiável se a Política de DEP estiver habilitada no dispositivo.

    A Política de Prevenção de Execução de Dados (DEP) define um conjunto de tecnologias de hardware e software que executam verificações extras na memória para ajudar a impedir que código mal-intencionado seja executado em um sistema. A inicialização segura permite uma lista limitada em x86/amd64 e o 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 (Desativado), execute uma das seguintes ações que se alinham com suas políticas corporativas:

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de 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 atividades anteriores de um dispositivo e histórico de confiança.
    • Execute uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.

    BitLockerStatus (no momento da inicialização)

    Quando o BitLocker é relatado como "ativado" no momento da inicialização, o dispositivo é capaz de proteger os dados armazenados na unidade contra acesso não autorizado, quando o sistema é desativado ou entra em hibernação.

    Windows criptografia de unidade do BitLocker, criptografa todos os dados armazenados no Windows do sistema operacional. 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 verifique o estado do computador.

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

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

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de 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 atividades anteriores de um dispositivo e histórico de confiança.
    • Execute uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.

    BootManagerRevListVersion

    Esse atributo indica a versão do Gerenciador de Inicialização 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 que se alinham com suas políticas corporativas:

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de HBI e MBI.
    • Coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.
    • Dispare uma ação corretiva, como informar a equipe de suporte técnico para 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 de política apropriada.

    Se CodeIntegrityRevListVersion = [CurrentVersion], permita o acesso.

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

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de HBI e MBI.
    • Coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.
    • Dispare uma ação corretiva, como informar a equipe de suporte técnico para 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 para a organização que fabricou o dispositivo. O firmware UEFI verifica esse requisito antes de permitir que o computador seja iniciado. 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), execute uma das seguintes ações que se alinham com suas políticas corporativas:

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de 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 atividades anteriores de um dispositivo e histórico de confiança.
    • Execute uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.

    BootDebuggingEnabled

    A inicialização habilitada para depuração aponta 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 teste 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 on**.

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

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

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

    OSKernelDebuggingEnabled

    OSKernelDebuggingEnabled aponta para um dispositivo que é 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 teste e desenvolvimento.

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

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

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de HBI.
    • Coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a possíveis riscos.
    • Dispare uma ação corretiva, como informar a equipe de suporte técnico para 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 é 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 ou arquivo do sistema não assinado 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 de modo kernel devem ser assinados digitalmente.

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

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

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de 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 atividades anteriores de um dispositivo e histórico de confiança.
    • Execute uma das ações anteriores e, além disso, coloque o dispositivo em uma lista de inspeção para monitorar o dispositivo mais de perto quanto a 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 on**.

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

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

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

    Safemode

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

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

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

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

    WinPE

    Windows pe Windows (ambiente de pré-instalação) é um sistema operacional mínimo com serviços limitados que é usado para preparar um computador para instalação do Windows, para copiar imagens de disco de um servidor de arquivos de rede e para iniciar a Instalação do Windows.

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

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

    ELAMDriverLoaded (Windows Defender)

    Para usar esse recurso de relatório, você deve desabilitar o "Currículo Híbrido" no dispositivo. O ELAM (antimalware de início antecipado) fornece proteção para os computadores em sua rede quando eles são iniciados e antes da inicialização de drivers de terceiros.

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

    Se for esperado 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), execute uma das seguintes ações que se alinham com suas políticas corporativas:

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

    Bcdedit.exe /set {current} vsmlaunchtype auto

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

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

    • Não permitir todo o acesso.
    • Não permitir acesso a ativos de HBI.
    • Dispare uma ação corretiva, como informar a equipe de suporte técnico para 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 todas as agente 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), execute uma das seguintes ações que se alinham com suas políticas corporativas:

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

    PCRHashAlgorithmID

    Esse atributo é um atributo informativo que identifica o algoritmo HASH que foi usado pelo TPM; nenhuma ação de conformidade é necessária.

    BootAppSVN

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

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

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

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

    BootManagerSVN

    Esse atributo identifica o número de 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, execute uma das seguintes ações que se alinham com suas políticas corporativas:

    • Não permitir todo o acesso.
    • Direcione o dispositivo para um honeypot corporativo 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 respostas "1" e "2":

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

    Com base na resposta recebida do nó TPMVersion:

    • Se 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 que se alinham com suas políticas corporativas:
      • Não permitir todo o acesso
      • Direcione o dispositivo para um honeypot corporativo para monitorar ainda mais as atividades do dispositivo.

    PCR0

    A medida capturada em PCR[0] normalmente representa uma exibição consistente da Plataforma de Host entre os ciclos de inicialização. Ele contém uma medida dos componentes fornecidos pelo fabricante da plataforma host.

    os gerentes do Enterprise podem criar uma lista de permitidos de valores PCR[0] confiáveis, comparar o valor PCR[0] dos dispositivos gerenciados (o valor verificado e relatado por HAS) com a lista de permitidos 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 permitidos de valores PCR[0] aceitos, não execute nenhuma ação. Se PCR[0] for igual a um valor de lista de permitidos aceito, permita o acesso.

    Se PCR[0] não for igual a qualquer valor listado aceito, execute uma das seguintes ações que se alinham com suas políticas corporativas:

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

    SBCPHash

    SBCPHash é a impressão digital da SBCP (Política de Configuração de Inicialização Segura Personalizada) que foi carregada durante a inicialização em Windows dispositivos, exceto computadores.

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

    Se O SBCPHash estiver presente no DHA-Report e não for um valor permitido na lista de permitidos, execute uma das seguintes ações que se alinham com suas políticas corporativas:

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

    CIPolicy

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

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

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

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

    BootRevListInfo

    Esse atributo identifica a Lista de Revisão de Inicialização que foi 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 de BootRevListInfo relatada não for igual a um valor aceito, execute uma das seguintes ações que se alinham com suas políticas corporativas:

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

    OSRevListInfo

    Esse atributo identifica a Lista de Revisão do Sistema Operacional que foi carregada durante a inicialização inicial no dispositivo atestado.

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

    Se a versão osRevListInfo relatada não for igual a um valor aceito, execute uma das seguintes ações que se alinham com suas políticas corporativas:

    • Não permitir todo o acesso.
    • Direcione o dispositivo para um honeypot corporativo 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 que 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.

    Status e códigos de erro do CSP healthAttestation do dispositivo

    Código de erro: 0 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED
    Descrição do erro: esse estado é o estado inicial para dispositivos que nunca participaram de uma sessão DHA.

    Código de erro: 1 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED
    Descrição do erro: 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.

    Código de erro: 2 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED
    Descrição do erro: esse estado significa que o dispositivo falhou ao recuperar DHA-EncBlob do DHA-Server.

    Código de erro: 3 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE
    Descrição do erro: esse estado significa que o dispositivo recuperou com DHA-EncBlob do servidor DHA.

    Código de erro: 4 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL
    Descrição do erro: preterido no Windows 10, versão 1607.

    Código de erro: 5 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL
    Descrição do erro: O DHA-CSP não conseguiu obter uma citação de declaração.

    Código de erro: 6 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY
    Descrição do erro: O DHA-CSP falhou ao abrir um identificador para o Provedor de Criptografia da Plataforma Microsoft.

    Código de erro: 7 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL
    Descrição do erro: falha de DHA-CSP ao recuperar Windows AIK

    Código de erro: 8 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL
    Descrição do erro: preterido no Windows 10, versão 1607.

    Código de erro: 9 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION
    Descrição do erro: versão inválida do TPM (a versão do TPM não é 1.2 ou 2.0)

    Código de erro: 10 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL
    Descrição do erro: Nonce não foi encontrado no registro.

    Código de erro: 11 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL
    Descrição do erro: A ID de correlação não foi encontrada no Registro.

    Código de erro: 12 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL
    Descrição do erro: preterido no Windows 10, versão 1607.

    Código de erro: 13 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL
    Descrição do erro: preterido no Windows 10, versão 1607.

    Código de erro: 14 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL
    Descrição do erro: falha nas funções de codificação. (Cenário extremamente improvável)

    Código de erro: 15 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL
    Descrição do erro: preterido no Windows 10, versão 1607.

    Código de erro: 16 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML
    Descrição do erro: O DHA-CSP falhou ao carregar a carga recebida do DHA-Service

    Código de erro: 17 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML
    Descrição do erro: O DHA-CSP recebeu uma resposta corrompida do serviço DHA.

    Código de erro: 18 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_XML
    Descrição do erro: O DHA-CSP recebeu uma resposta vazia do DHA-Service.

    Código de erro: 19 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK
    Descrição do erro: O DHA-CSP falhou ao descriptografar a chave AES do desafio EK.

    Código de erro: 20 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK
    Descrição do erro: O DHA-CSP falhou ao descriptografar o certificado de integridade com a chave AES.

    Código de erro: 21 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB
    Descrição do erro: O DHA-CSP falhou ao exportar a chave pública AIK.

    Código de erro: 22 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY descrição do erro: falha do DHA-CSP ao tentar criar uma declaração com dados de atestado do AIK.

    Código de erro: 23 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB descrição do erro: falha do DHA-CSP ao acrescentar o AIK Pub ao blob de solicitação.

    Código de erro: 24 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT descrição do erro: falha do DHA-CSP ao acrescentar o Certificado AIK ao blob de solicitação.

    Código de erro: 25 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE descrição do erro: falha do DHA-CSP ao obter um identificador de sessão.

    Código de erro: 26 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE descrição do erro: falha do DHA-CSP ao se conectar ao serviço DHA.

    Código de erro: 27 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND Descrição do erro: falha do DHA-CSP ao criar um identificador de solicitação HTTP.

    Código de erro: 28 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION descrição do erro: falha do DHA-CSP ao definir opções.

    Código de erro: 29 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS descrição do erro: falha do DHA-CSP ao adicionar cabeçalhos de solicitação.

    Código de erro: 30 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST descrição do erro: falha do DHA-CSP ao enviar a solicitação HTTP.

    Código de erro: 31 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE descrição do erro: O DHA-CSP falhou ao receber uma resposta do serviço DHA.

    Código de erro: 32 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS descrição do erro: falha do DHA-CSP ao consultar cabeçalhos ao tentar obter o código de status HTTP.

    Código de erro: 33 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE descrição do erro: DHA-CSP recebeu uma resposta vazia de DHA-Service mesmo que o status HTTP estivesse OK.

    Código de erro: 34 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE descrição do erro: DHA-CSP recebeu uma resposta vazia juntamente com um código de erro HTTP do DHA-Service.

    Código de erro: 35 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER descrição do erro: falha do DHA-CSP ao representar o usuário.

    Código de erro: 36 | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR Descrição do erro: O DHA-CSP falhou ao adquirir os ativadores PDC necessários para a comunicação de rede quando o dispositivo está no modo de espera conectado.

    Código de erro: 0xFFFF | Nome do erro: HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN descrição do erro: falha de DHA-CSP devido a um motivo desconhecido, esse erro é altamente improvável de ocorrer.

    Código de erro: 400 | Nome do erro: Bad_Request_From_Client descrição do erro: DHA-CSP recebeu uma solicitação de atestado incorreta (malformada).

    Código de erro: 404 | Nome do erro: Endpoint_Not_Reachable descrição do erro: DHA-Service não está acessível pelo DHA-CSP

    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>

    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>

    Considerações sobre segurança

    O DHA ancora sua confiança no TPM e suas medidas. Se as medidas do TPM puderem ser falsificadas ou adulteradas, a 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 pc.

    Tópicos relacionados

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