HealthAttestation CSP

Artículo
01/31/2024

Logotipo de Windows Insider.

Importante

Este CSP contiene algunas configuraciones que están en desarrollo y que solo se aplican a las compilaciones de Windows Insider Preview. Esta configuración está sujeta a cambios y puede tener dependencias en otras características o servicios en versión preliminar.

El proveedor de servicios de configuración de Device HealthAttestation (DHA-CSP) permite a los administradores de TI empresariales evaluar si un dispositivo se inicia en un estado de confianza y compatible, y realizar acciones de directiva empresarial.

La lista siguiente es una descripción de las funciones realizadas por el CSP de Device HealthAttestation:

Recopila registros de arranque del dispositivo, seguimientos de auditoría del módulo de plataforma segura (TPM) y el certificado TPM (DHA-BootData) de un dispositivo administrado
Reenvía DHA-BootData a un servicio de atestación de estado de dispositivo (DHA-Service)
Recibe un blob cifrado (DHA-EncBlob) de DHA-Service y lo almacena en una caché local en el dispositivo.
Recibe solicitudes de atestación (dha-requests) de un DHA-Enabled MDM y respuestas con datos de atestación de estado del dispositivo (DHA-Data)

En la lista siguiente se muestran los nodos del proveedor de servicios de configuración healthAttestation:

./Vendor/MSFT/HealthAttestation

AttestErrorMessage

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows Insider Preview

./Vendor/MSFT/HealthAttestation/AttestErrorMessage

AttestErrorMessage mantiene el mensaje de error de la última sesión de atestación, si lo devuelve el servicio de atestación.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener

AttestStatus

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, versión 21H2 [10.0.22000] y versiones posteriores

./Vendor/MSFT/HealthAttestation/AttestStatus

AttestStatus mantiene el código de estado correcto o de error para la última sesión de atestación.

El estado siempre se borra antes de realizar la llamada de servicio atestiguada.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`int`
Tipo de acceso	Obtener

Ejemplo:

Llamada SyncML con plantilla:

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

Respuesta de ejemplo:

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

Certificado

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/Certificate

Indica al DHA-CSP que reenvíe DHA-Data al servidor MDM.

El tipo de valor es una cadena base64.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener

CorrelationID

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/CorrelationID

Identifica una sesión de atestación de estado de dispositivo única. CorrelationId se usa para correlacionar los registros de DHA-Service con los eventos del servidor MDM y los registros de eventos de cliente para la depuración y solución de problemas.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener

CurrentProtocolVersion

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1709 [10.0.16299] y versiones posteriores

./Vendor/MSFT/HealthAttestation/CurrentProtocolVersion

Proporciona la versión del protocolo actual que el cliente usa para comunicarse con el servicio de atestación de estado.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`int`
Tipo de acceso	Obtener

ForceRetrieve

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/ForceRetrieve

Indica al cliente que inicie una nueva solicitud a DHA-Service y obtenga un nuevo DHA-EncBlob (un resumen del estado de arranque emitido por DHA-Service). Esta opción solo debe usarse si el servidor MDM aplica una directiva de actualización de certificados, que debe forzar a un dispositivo a obtener un blob cifrado actualizado de DHA-Service.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`bool`
Tipo de acceso	Obtener, reemplazar
Valor predeterminado	Falso

Valores permitidos:

Valor	Descripción
false (valor predeterminado)	Falso.
true	Verdad.

GetAttestReport

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, versión 21H2 [10.0.22000] y versiones posteriores

./Vendor/MSFT/HealthAttestation/GetAttestReport

Recupere el informe de sesión de atestación si existe.

El informe se almacena en una clave del Registro en el almacén de inscripción de MDM correspondiente.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener

Ejemplo:

Llamada SyncML con plantilla:

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

Datos de ejemplo:

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

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, versión 21H2 [10.0.22000] y versiones posteriores

./Vendor/MSFT/HealthAttestation/GetServiceCorrelationIDs

Recupere los identificadores de correlación de servicio si existen.

Si hay más de un identificador de correlación, se separan por ";" en la cadena.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener

Ejemplo:

Llamada SyncML con plantilla:

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

Datos de ejemplo:

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

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/HASEndpoint

Identifica el nombre de dominio completo (FQDN) del DHA-Service asignado para realizar la atestación. Si no se asigna un FQDN, se usará DHA-Cloud (servicio en la nube operado y propiedad de Microsoft) como servicio de atestación predeterminado.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener, reemplazar
Valor predeterminado	has.spserv.microsoft.com.

MaxSupportedProtocolVersion

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1709 [10.0.16299] y versiones posteriores

./Vendor/MSFT/HealthAttestation/MaxSupportedProtocolVersion

Devuelve la versión máxima del protocolo que este cliente puede admitir.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`int`
Tipo de acceso	Obtener

Nonce

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/Nonce

Permite que los MDM protejan las comunicaciones de atestación de estado del dispositivo frente a ataques de tipo man in the middle (MITM) con un valor aleatorio protegido por cripta generado por el servidor MDM. El nonce está en formato hexadecimal, con un tamaño mínimo de 8 bytes y un tamaño máximo de 32 bytes.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Obtener, reemplazar
Valor predeterminado	\0

PreferredMaxProtocolVersion

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1709 [10.0.16299] y versiones posteriores

./Vendor/MSFT/HealthAttestation/PreferredMaxProtocolVersion

Proporciona la versión de protocolo preferida máxima que el cliente está configurado para comunicarse. Si es mayor que las versiones de protocolo admitidas por el cliente, usará la versión de protocolo más alta disponible.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`int`
Tipo de acceso	Obtener, reemplazar
Valor predeterminado	3

Estado

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/Status

Proporciona el estado actual de la solicitud de estado del dispositivo. Para obtener una lista completa de los valores de estado, consulte Estado y códigos de error de CSP de HealthAttestation.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`int`
Tipo de acceso	Obtener

TpmReadyStatus

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1607 [10.0.14393] y versiones posteriores

./Vendor/MSFT/HealthAttestation/TpmReadyStatus

Devuelve una máscara de bits de información que describe el estado de TPM. Indica si el TPM del dispositivo está en un estado listo y de confianza.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`int`
Tipo de acceso	Obtener

TriggerAttestation

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 11, versión 21H2 [10.0.22000] y versiones posteriores

./Vendor/MSFT/HealthAttestation/TriggerAttestation

Notifica al dispositivo que desencadene una sesión de atestación de forma asincrónica.

Si el proceso de atestación se inicia correctamente, este nodo devolverá el código 202 que indica que la solicitud se recibe y se procesa. De lo contrario, se devolverá un error.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`chr` (cadena)
Tipo de acceso	Exec

Ejemplo:

Llamada SyncML con plantilla:

<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 datos:
- rpID (identificador de usuario de confianza): este campo contiene un identificador que se puede usar para ayudar a determinar el autor de la llamada.
- serviceEndpoint: este campo contiene la dirección URL completa de la instancia del proveedor de Microsoft Azure Attestation que se va a usar para la evaluación.
- nonce: este campo contiene un número arbitrario que solo se puede usar una vez en una comunicación criptográfica. A menudo es un número aleatorio o pseudoaleativo emitido en un protocolo de autenticación para garantizar que las comunicaciones antiguas no se puedan reutilizar en los ataques de reproducción.
- aadToken: token de Microsoft Entra que se va a usar para la autenticación en el servicio Microsoft Azure Attestation.
- cv: este campo contiene un identificador (vector de correlación) que se pasará a la llamada de servicio y que se puede usar con fines de diagnóstico.

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

Ámbito	Ediciones	Sistema operativo aplicable
Dispositivo ✅ ❌ Usuario	✅ Pro ✅ Empresa ✅ Educación ✅ Windows SE ✅ IoT Enterprise/IoT Enterprise LTSC	✅Windows 10, versión 1511 [10.0.10586] y versiones posteriores

./Vendor/MSFT/HealthAttestation/VerifyHealth

Notifica al dispositivo que prepare una solicitud de comprobación de estado del dispositivo.

Propiedades del marco de descripción:

Nombre de la propiedad	Valor de propiedad
Formato	`null`
Tipo de acceso	Exec

atestación de estado del dispositivo Windows 11

Windows 11 presenta una actualización de la característica de atestación de estado del dispositivo. Esta actualización ayuda a agregar compatibilidad con información más detallada sobre la seguridad de arranque de Windows, lo que admite un enfoque de confianza cero para la seguridad del dispositivo. Se puede acceder a la atestación de estado del dispositivo en Windows mediante healthAttestation CSP. Este CSP ayuda a evaluar si un dispositivo se inicia en un estado de confianza y compatible y, a continuación, a realizar las acciones adecuadas. Windows 11 introduce más nodos secundarios en el nodo HealthAttestation para que los proveedores de MDM se conecten al servicio Microsoft Azure Attestation, lo que proporciona un enfoque simplificado para la atestación.

El informe de atestación proporciona una evaluación del estado de las propiedades de tiempo de arranque del dispositivo para asegurarse de que los dispositivos se protegen automáticamente en cuanto se encienden. A continuación, el resultado de la atestación de estado se puede usar para permitir o denegar el acceso a redes, aplicaciones o servicios, en función del estado del dispositivo.

Términos usados:

TPM (módulo de plataforma segura): TPM es una lógica especializada protegida por hardware que realiza una serie de operaciones de seguridad protegidas por hardware, incluido el almacenamiento protegido, la generación aleatoria de números, el cifrado y la firma.
Característica DHA (Device HealthAttestation): la característica Device HealthAttestation (DHA) permite a los administradores de TI empresariales supervisar la posición de seguridad de los dispositivos administrados de forma remota mediante el uso de datos protegidos por hardware (TPM) y atestiguados a través de un canal de comunicación anti alteraciones y evidente.
MAA-Session (sesión de mantenimiento del dispositivo basado en el servicio de Microsoft Azure Attestation) : la sesión healthAttestation del dispositivo basado en el servicio de Microsoft Azure Attestation (MAA-Session) describe el flujo de comunicación de un extremo a otro que se realiza en una sesión de atestación de estado del dispositivo.
Nodos de MAA-CSP (proveedor de servicios de configuración basado en Microsoft Azure Attestation): los nodos del proveedor de servicios de configuración agregados a Windows 11 para integrarse con Microsoft Azure Attestation Service. MAA-CSP realiza la siguiente lista de operaciones:
- Recibe solicitudes de desencadenador de atestación de un proveedor de MDM habilitado para HealthAttestation.
- El dispositivo recopila evidencia de atestación (registros de arranque del dispositivo, seguimientos de auditoría de TPM y el certificado TPM) de un dispositivo administrado.
- Reenvía la evidencia de atestación a la instancia del servicio Azure Attestation según lo configurado por el proveedor de MDM.
- Recibe un informe firmado de la instancia de Azure Attestation Service y lo almacena en una caché local en el dispositivo.
Punto de conexión de MAA: el servicio de atestación de Microsoft Azure es un recurso de Azure y cada instancia del servicio obtiene la dirección URL configurada por el administrador. El URI generado es único por naturaleza y, a efectos de la atestación de estado del dispositivo, se conoce como punto de conexión de MAA.
JWT (JSON Web Token): JSON Web Token (JWT) es un método de RFC7519 estándar abierto para transmitir información de forma segura entre partes como un objeto de notación de objetos JavaScript (JSON). Esta información se puede comprobar y confiar porque está firmada digitalmente. Los JWT se pueden firmar mediante un secreto o un par de claves pública y privada.

Flujo de atestación con microsoft Azure Attestation Service

El flujo de atestación puede estar ampliamente en tres pasos principales:

Una instancia del servicio Azure Attestation se configura con una directiva de atestación adecuada. La directiva de atestación permite que el proveedor de MDM atestigua determinados eventos en las características de arranque y seguridad.
El proveedor de MDM desencadena una llamada al servicio de atestación y, a continuación, el dispositivo realiza una comprobación de atestación que mantiene el informe listo para recuperarse.
El proveedor de MDM después de comprobar que el token procede del servicio de atestación, puede analizar el token de atestación para reflejar el estado atestiguado del dispositivo.

Para obtener más información, consulte Protocolo de atestación.

Pasos de integración de CSP de MAA

Configuración de una instancia de proveedor de MAA: la instancia de MAA se puede crear siguiendo los pasos descritos en Inicio rápido: Configuración de Azure Attestation mediante el Azure Portal.

Actualizar el proveedor con una directiva adecuada: la instancia de MAA debe actualizarse con una directiva adecuada. Para obtener más información, consulte Creación de una directiva de Azure Attestation.

Una directiva de atestación de ejemplo:

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]")));

};

Llame a TriggerAttestation con rpidy Azure Active Directory tokenattestURI: use la dirección URL de atestación generada en el paso 1 y anexe la versión de api adecuada que quiera alcanzar. Para obtener más información sobre la versión de la API, consulte Attestation - Attest Tpm - REST API.

Llame a GetAttestReport y descódifique y analice el informe para asegurarse de que el informe atestiguado contiene las propiedades necesarias: GetAttestReport devuelve el token de atestación firmado como JWT. El JWT se puede descodificar para analizar la información según la directiva de atestación.

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

Más información

Puede encontrar más información sobre la atestación de TPM aquí: Microsoft Azure Attestation.

Windows 10 Device HealthAttestation

Términos usados:

TPM (módulo de plataforma segura): TPM es una lógica especializada protegida por hardware que realiza una serie de operaciones de seguridad protegidas por hardware, incluido el almacenamiento protegido, la generación aleatoria de números, el cifrado y la firma.
Característica DHA (Device HealthAttestation): la característica Device HealthAttestation (DHA) permite a los administradores de TI empresariales supervisar la posición de seguridad de los dispositivos administrados de forma remota mediante el uso de datos protegidos por hardware (TPM) y atestiguados a través de un canal de comunicación anti alteraciones y evidente.
Dispositivo habilitado para DHA (dispositivo habilitado para Device HealthAttestation): un dispositivo habilitado para Device HealthAttestation (habilitado para DHA) es un dispositivo informático (teléfono, escritorio, portátil, tableta, servidor) que ejecuta Windows 10 y admite tpm versión 1.2 o 2.0.
Sesión DHA (sesión de device healthAttestation): la sesión device healthAttestation (DHA-Session) describe el flujo de comunicación de un extremo a otro que se realiza en una sesión de atestación de estado del dispositivo. La siguiente lista de transacciones se realiza en una sesión dha:
- DHA-CSP y comunicación DHA-Service:
  - DHA-CSP reenvía los datos de arranque del dispositivo (DHA-BootData) a DHA-Service
  - DHA-Service respuestas con un blob de datos cifrado (DHA-EncBlob)
- DHA-CSP y comunicación MDM-Server:
  - MDM-Server envía una solicitud de comprobación del estado del dispositivo a DHA-CSP
  - Respuestas de DHA-CSP con una carga denominada DHA-Data que incluye un blob de datos cifrado (DHA-EncBlob) y un blob de datos firmado (DHA-SignedBlob)
- MDM-Server y DHA-Service comunicación:
  - MDM-Server publica los datos que recibe de los dispositivos en DHA-Service
  - DHA-Service revisa los datos que recibe y responde con un informe de estado del dispositivo (DHA-Report)
Datos de sesión de DHA (datos de sesión de Device HealthAttestation): la siguiente lista de datos se genera o se consume en una transacción DHA:
- DHA-BootData: los datos de arranque del dispositivo (registros TCG, valores de PCR, certificado de dispositivo/TPM, arranque y contadores tpm) necesarios para validar el estado de arranque del dispositivo.
- DHA-EncBlob: un informe de resumen cifrado que DHA-Service problemas a un dispositivo después de revisar el DHA-BootData que recibe de los dispositivos.
- DHA-SignedBlob: es una instantánea firmada del estado actual del entorno de ejecución de un dispositivo que captura DHA-CSP en el momento de la atestación del estado del dispositivo.
- DHA-Data: un blob de datos con formato XML que los dispositivos reenvía para que la validación del estado del dispositivo DHA-Service a través de MDM-Server. DHA-Data tiene dos partes:
  - DHA-EncBlob: el blob de datos cifrado que el dispositivo recibe de DHA-Service
  - DHA-SignedBlob: una instantánea actual del estado de seguridad actual del dispositivo generado por DHA-CSP
- DHA-Report: informe emitido por DHA-Service para MDM-Server
- Nonce: un número protegido criptográfico generado por MDM-Server, que protege el DHA-Session frente a ataques de tipo man-in-the-middle
MDM habilitado para DHA (solución de administración de dispositivos habilitados para Device HealthAttestation): La solución de administración de dispositivos habilitada para device HealthAttestation (habilitada para DHA) es una herramienta de administración de dispositivos que se integra con la característica DHA. DHA-Enabled soluciones de administración de dispositivos permiten a los administradores de TI empresariales aumentar la barra de protección de seguridad de sus dispositivos administrados en función de los datos protegidos por hardware (TPM) que pueden ser de confianza incluso si un dispositivo está en peligro por amenazas de seguridad avanzadas o si ejecuta un sistema operativo malintencionado (liberado). Dha-Enabled-MDM realiza la siguiente lista de operaciones:
- Habilita la característica DHA en un dispositivo DHA-Enabled
- Problemas de las solicitudes de atestación de estado del dispositivo a dispositivos inscritos o administrados
- Recopila datos de atestación de estado del dispositivo (DHA-Data) y los envía al Servicio de atestación de estado del dispositivo (DHA-Service) para su verificación.
- Obtiene el informe de estado del dispositivo (DHA-Report) de DHA-Service, que desencadena la acción de cumplimiento.
DHA-CSP (proveedor de servicios de configuración de device HealthAttestation): el proveedor de servicios de configuración de device HealthAttestation (DHA-CSP) usa el TPM y el firmware de un dispositivo para medir las propiedades de seguridad críticas del BIOS del dispositivo y el arranque de Windows, de modo que incluso en un sistema infectado con malware de nivel de kernel o un rootkit, estas propiedades no se pueden suplantar. DHA-CSP realiza la siguiente lista de operaciones:
- Recopila datos de arranque del dispositivo (DHA-BootData) de un dispositivo administrado.
- Reenvía DHA-BootData al servicio de atestación de estado del dispositivo (DHA-Service)
- Recibe un blob cifrado (DHA-EncBlob) de DHA-Service y lo almacena en una caché local en el dispositivo.
- Recibe solicitudes de atestación (dha-requests) de un DHA-Enabled MDM y respuestas con datos de atestación de estado del dispositivo (DHA-Data)
DHA-Service (Device HealthAttestation Service): Device HealthAttestation Service (DHA-Service) valida los datos que recibe de DHA-CSP y emite un informe protegido de hardware (TPM) de alta confianza (DHA-Report) para DHA-Enabled soluciones de administración de dispositivos a través de un canal de comunicación evidente y resistente a alteraciones. DHA-Service está disponible en dos tipos: "DHA-Cloud" y "DHA-Server2016". DHA-Service admite varios escenarios de implementación, incluidos los escenarios de nube, locales, de aire y híbridos. Dha-Service realiza la siguiente lista de operaciones:
- Recibe datos de arranque del dispositivo (DHA-BootData) de un dispositivo DHA-Enabled
- Reenvía DHA-BootData al servicio de atestación de estado del dispositivo (DHA-Service)
- Recibe un blob cifrado (DHA-EncBlob) de DHA-Service y lo almacena en una caché local en el dispositivo.
- Recibe solicitudes de atestación (dha-requests) de un DHA-Enabled-MDM y respuestas con un informe de estado del dispositivo (DHA-Report)

Diagrama del servicio de atestación de estado para los diferentes servicios DHS

DHA-Service tipo	Descripción	Costo de la operación
Atestación del estado del dispositivo: nube (DHA-Cloud)	DHA-Cloud es un DHA-Service propiedad y operado de Microsoft que es: Disponible en Windows de forma gratuita Ejecución en una infraestructura de nube de alta disponibilidad y equilibrio geográfico Compatible con la mayoría de las soluciones de administración de dispositivos DHA-Enabled como proveedor de servicios de atestación de dispositivos predeterminado Accesible para todos los dispositivos administrados por la empresa a través de lo siguiente: FQDN = puerto has.spserv.microsoft.com Puerto = 443 Protocolo = TCP	Sin costo
Atestación de estado del dispositivo: local(DHA-OnPrem)	DHA-OnPrem hace referencia a DHA-Service que se ejecuta en el entorno local: Se ofrece a Windows Server 2016 cliente (sin costo de licencia adicional por habilitar o ejecutar DHA-Service) Hospedado en un hardware o dispositivo de servidor administrado y propiedad de la empresa Compatible con los proveedores de soluciones de administración de dispositivos DHA-Enabled de 1ª y 3ª parte que admiten escenarios de atestación de hardware locales e híbridos (Nube + OnPrem) Accesible para todos los dispositivos administrados por la empresa mediante la siguiente configuración: FQDN = (asignado por la empresa) Port = (asignado por la empresa) Protocolo = TCP	El costo de operación de ejecutar una o varias instancias de Server 2016 local.
Atestación del estado de los dispositivos: Enterprise-Managed Cloud(DHA-EMC)	DHA-EMC hace referencia a un DHA-Service administrado por la empresa que se ejecuta como un host o servicio virtual en un servicio en la nube administrado por la empresa compatible con Windows Server 2016, como Microsoft Azure. Se ofrece a Windows Server 2016 clientes sin costo adicional de licencia (sin costo de licencia adicional por habilitar/ejecutar DHA-Service) Compatible con los proveedores de soluciones de administración de dispositivos DHA-Enabled de 1ª y 3ª parte que admiten escenarios de atestación de hardware locales e híbridos (Nube + OnPrem) Accesible para todos los dispositivos administrados por la empresa mediante la siguiente configuración: FQDN = (asignado por la empresa) Port = (asignado por la empresa) Protocolo = TCP	El costo de operación de ejecutar Server 2016 en un servicio en la nube compatible, como Microsoft Azure.

Pasos de integración de DHA-CSP

La siguiente lista de tareas de validación y desarrollo es necesaria para integrar la característica de atestación de estado de dispositivos de Microsoft con una solución de administración de dispositivos (MDM) de Windows Mobile:

Comprobación del acceso HTTPS
Asignación de un servicio DHA de confianza empresarial
Indicar al cliente que prepare los datos dha para la comprobación
Realizar acciones basadas en la respuesta de los clientes
Indicar al cliente que reenvíe datos DHA para la comprobación
Post DHA-data to DHA-service
Recepción de respuesta de DHA-service
Analizar DHA-Report datos. Tomar las medidas de directiva adecuadas en función de los resultados de la evaluación

Cada paso se describe con detalle en las secciones siguientes de este tema.

Paso 1: Comprobar el acceso HTTPS

Valide que tanto el servidor MDM como el dispositivo (cliente MDM) pueden acceder a has.spserv.microsoft.com mediante el protocolo TCP a través del puerto 443 (HTTPS).

Puede usar OpenSSL para validar el acceso a DHA-Service. Este es un comando OpenSSL de ejemplo y la respuesta generada por 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)

Paso 2: Asignar una DHA-Service de confianza empresarial

Hay tres tipos de DHA-Service:

Atestación de estado del dispositivo: nube (propiedad y operada por Microsoft)
Atestación de estado del dispositivo: local (propiedad y operado por una empresa, se ejecuta en Windows Server 2016 local)
Atestación de Device Health: Enterprise-Managed Cloud (propiedad y operado por una empresa, se ejecuta en Windows Server 2016 nube administrada por la empresa compatible)

DHA-Cloud es la configuración predeterminada. No se requiere ninguna acción adicional si una empresa planea usar Microsoft DHA-Cloud como proveedor de DHA-Service de confianza.

Para DHA-OnPrem & escenarios de DHA-EMC, envíe un comando SyncML al nodo HASEndpoint para indicar a un dispositivo administrado que se comunique con el DHA-Service de confianza empresarial.

En el ejemplo siguiente se muestra una llamada de ejemplo que indica a un dispositivo administrado que se comunique con un dha-service administrado por la empresa.

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

Paso 3: Indicar al cliente que prepare los datos de estado para la verificación

Envíe una llamada SyncML para iniciar la recopilación de los datos DHA.

En el ejemplo siguiente se muestra una llamada de ejemplo que desencadena la recopilación y comprobación de datos de atestación de estado desde un dispositivo administrado.

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

Paso 4: Realizar acciones en función de la respuesta del cliente

Una vez que el cliente recibe la solicitud de atestación de estado, envía una respuesta. En la lista siguiente se describen las respuestas, junto con una acción recomendada.

Si la respuesta es HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE (3), continúe con la sección siguiente.
Si la respuesta se HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) o HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) esperar una alerta, continúe con la sección siguiente.

Esta es una alerta de ejemplo emitida por 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>

Si la respuesta al nodo de estado no es 0, 1 o 3, solucione el problema. Para obtener la lista completa de códigos de estado, consulte HealthAttestation CSP status and error codes (Estado y códigos de error de CSP de HealthAttestation).

Paso 5: Indicar al cliente que reenvíe los datos de atestación de estado para la comprobación

Cree una llamada a los nodos Nonce, Certificate y CorrelationId y seleccione una carga cifrada que incluya un certificado de estado y datos relacionados del dispositivo.

A continuación te mostramos un ejemplo:

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

Paso 6: Reenvío de datos de atestación de estado del dispositivo al servicio DHA

En respuesta a la solicitud que se envió en el paso anterior, el cliente MDM reenvía un blob con formato XML (respuesta del nodo ./Vendor/MSFT/HealthAttestation/Certificate) y un identificador de llamada denominado CorrelationId (respuesta al nodo ./Vendor/MSFT/HealthAttestation/CorrelationId).

Cuando el MDM-Server recibe los datos anteriores, debe:

Registre el CorrelationId que recibe del dispositivo (para futura solución de problemas o referencia), correlacionado con la llamada.
Descodificación del blob de datos con formato XML que recibe del dispositivo

Anexe el nonce generado por el servicio MDM (agregue el nonce que se reenvió al dispositivo en el paso 5) a la estructura XML reenviada por el dispositivo en el siguiente 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>

Reenvíe (HTTP Post) la estructura de datos XML (incluido el nonce que se anexó en el paso anterior) al DHA-Service asignado que se ejecuta en:
- escenario de DHA-Cloud (dha-service administrado y propiedad de Microsoft): https://has.spserv.microsoft.com/DeviceHealthAttestation/ValidateHealthCertificate/v3
- DHA-OnPrem o DHA-EMC: https://FullyQualifiedDomainName-FDQN/DeviceHealthAttestation/ValidateHealthCertificate/v3

Paso 7: Recibir respuesta del servicio DHA

Cuando el Servicio de atestación de Estado de dispositivos de Microsoft recibe una solicitud de verificación, realiza los pasos siguientes:

Descifra los datos cifrados que recibe.
Valida los datos que ha recibido.
Crea un informe y comparte los resultados de la evaluación con el servidor MDM a través de SSL en formato XML.

Paso 8: Tomar las medidas de directiva adecuadas en función de los resultados de la evaluación

Una vez que el servidor MDM recibe los datos comprobados, la información se puede usar para tomar decisiones de directiva mediante la evaluación de los datos. Algunas acciones posibles serían:

Permitir el acceso al dispositivo.
Permitir que el dispositivo acceda a los recursos, pero marque el dispositivo para una investigación más detallada.
Impedir que un dispositivo acceda a los recursos.

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

La DHA-Service comprueba la siguiente lista de puntos de datos en DHA-Report versión 3.

Emitido: el informe DHA de fecha y hora se evaluó o emitió a MDM.
AIKPresent: cuando hay una clave de identidad de atestación (AIK) en un dispositivo, indica que el dispositivo tiene un certificado de clave de aprobación (EK). Puede ser de confianza más que un dispositivo que no tenga un certificado EK.

Si AIKPresent = True (1), permita el acceso.

Si AIKPresent = False (0), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Permitir el acceso condicional en función de otros puntos de datos que estén presentes en el momento de la evaluación. Por ejemplo, otros atributos del certificado de estado o las actividades anteriores y el historial de confianza de un dispositivo.
- Realice una de las acciones anteriores y coloque el dispositivo en una lista de watch para supervisar más estrechamente el dispositivo en busca de posibles riesgos.
ResetCount (notificado solo para dispositivos que admiten TPM 2.0): este atributo notifica el número de veces que un dispositivo de PC ha hibernado o reanudado.
RestartCount (solo se notifica para dispositivos que admiten TPM 2.0): este atributo notifica el número de veces que se ha reiniciado un dispositivo de PC.

DEPPolicy: se puede confiar más en un dispositivo si la directiva de DEP está habilitada en el dispositivo.

La directiva de prevención de ejecución de datos (DEP) define un conjunto de tecnologías de hardware y software que realizan comprobaciones adicionales en la memoria para ayudar a evitar que el código malintencionado se ejecute en un sistema. El arranque seguro permite una lista limitada en x86/amd64 y en ARM NTOS la bloquea.

DEPPolicy se puede deshabilitar o habilitar mediante los siguientes comandos en WMI o un script de PowerShell:

Para deshabilitar DEP, escriba bcdedit.exe /set {current} nx AlwaysOff
Para habilitar DEP, escriba bcdedit.exe /set {current} nx AlwaysOn

Si DEPPolicy = 1 (Activado), permita el acceso.

Si DEPPolicy = 0 (Desactivado), realice una de las siguientes acciones que se alineen con las directivas empresariales:

Impedir todo acceso.
No permitir el acceso a los recursos de HBI.
Permitir el acceso condicional en función de otros puntos de datos que estén presentes en el momento de la evaluación. Por ejemplo, otros atributos del certificado de estado o las actividades anteriores y el historial de confianza de un dispositivo.
Realice una de las acciones anteriores y coloque el dispositivo en una lista de watch para supervisar más estrechamente el dispositivo en busca de posibles riesgos.

La evaluación de directivas DEP es un estado no binario cuando se consulta. A continuación, se asigna a un estado Activado/Desactivado.

Nivel de directiva de DEP	Descripción	Nivel notificado de atestación	Valor de propiedad
OptIn (configuración predeterminada)	Solo los componentes y servicios del sistema de Windows tienen aplicado DEP.	0	2
OptOut	DEP está habilitado para todos los procesos. Los administradores pueden crear manualmente una lista de aplicaciones específicas que no tienen deP aplicado.	1	3
AlwaysOn	DEP está habilitado para todos los procesos.	3	1
AlwaysOff	DEP no está habilitado para ningún proceso.	2	0

BitLockerStatus (notifica si BitLocker se ha habilitado durante el arranque inicial):

Cuando BitLocker se notifica "activado" en el momento del arranque, el dispositivo puede proteger los datos almacenados en la unidad contra el acceso no autorizado, cuando el sistema está apagado o entra en hibernación.

Cifrado de unidad de Windows BitLocker cifra todos los datos almacenados en el volumen del sistema operativo Windows. BitLocker usa el TPM para ayudar a proteger el sistema operativo Windows y los datos de usuario y ayuda a garantizar que un equipo no se manipule, incluso si se deja desatendido, perdido o robado.

Si el equipo está equipado con un TPM compatible, BitLocker usa el TPM para bloquear las claves de cifrado que protegen los datos. Como resultado, no se puede acceder a las claves hasta que el TPM haya comprobado el estado del equipo.

Si BitLockerStatus = 1 (Activado), permita el acceso.

Si BitLockerStatus = 0 (Desactivado), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Permitir el acceso condicional en función de otros puntos de datos que estén presentes en el momento de la evaluación. Por ejemplo, otros atributos del certificado de estado o las actividades anteriores y el historial de confianza de un dispositivo.
- Realice una de las acciones anteriores y coloque el dispositivo en una lista de watch para supervisar más estrechamente el dispositivo en busca de posibles riesgos.
BootManagerRevListVersion: este atributo indica la versión del Administrador de arranque que se ejecuta en el dispositivo, para permitirle realizar un seguimiento y administrar la seguridad de la secuencia de arranque o el entorno.

Si BootManagerRevListVersion = [CurrentVersion], permita el acceso.

Si BootManagerRevListVersion !es = [CurrentVersion], realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos HBI y MBI.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
- Desencadene una acción correctiva, como informar al equipo de soporte técnico para que se ponga en contacto con el propietario para investigar el problema.
CodeIntegrityRevListVersion: este atributo indica la versión del código que realiza comprobaciones de integridad durante la secuencia de arranque. El uso de este atributo puede ayudarle a detectar si el dispositivo ejecuta la versión más reciente del código que realiza comprobaciones de integridad o si está expuesto a riesgos de seguridad (revocado) y aplicar una acción de directiva adecuada.

Si CodeIntegrityRevListVersion = [CurrentVersion], permita el acceso.

Si CodeIntegrityRevListVersion !es = [CurrentVersion], realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos HBI y MBI.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
- Desencadene una acción correctiva, como informar al equipo de soporte técnico para que se ponga en contacto con el propietario para investigar el problema.
SecureBootEnabled: cuando se habilita el arranque seguro, los componentes principales que se usan para arrancar la máquina deben tener firmas criptográficas correctas de confianza para la organización que fabricó el dispositivo. El firmware UEFI comprueba este requisito antes de permitir que se inicie la máquina. Si se ha manipulado algún archivo, rompiendo su firma, el sistema no arrancará.

Si SecureBootEnabled = 1 (True), permite el acceso.

Si SecurebootEnabled = 0 (False), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Permitir el acceso condicional en función de otros puntos de datos que estén presentes en el momento de la evaluación. Por ejemplo, otros atributos del certificado de estado o las actividades anteriores y el historial de confianza de un dispositivo.
- Realice una de las acciones anteriores y coloque el dispositivo en una lista de watch para supervisar más estrechamente el dispositivo en busca de posibles riesgos.
BootDebuggingEnabled: puntos habilitados para depuración de arranque a un dispositivo que se usa en el desarrollo y las pruebas. Los dispositivos que se usan para pruebas y desarrollo suelen ser menos seguros: el dispositivo puede ejecutar código inestable o configurarse con menos restricciones de seguridad necesarias para las pruebas y el desarrollo.

La depuración de arranque se puede deshabilitar o habilitar mediante los siguientes comandos en WMI o un script de PowerShell:
- Para deshabilitar la depuración de arranque, escriba bcdedit.exe /set {current} bootdebug off.
- Para habilitar la depuración de arranque, escriba bcdedit.exe /set {current} bootdebug on.
Si BootdebuggingEnabled = 0 (False), permite el acceso.

Si BootDebuggingEnabled = 1 (True), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
- Desencadene una acción correctiva, como habilitar VSM mediante WMI o un script de PowerShell.
OSKernelDebuggingEnabled: OSKernelDebuggingEnabled apunta a un dispositivo que se usa en el desarrollo y las pruebas. Los dispositivos que se usan para pruebas y desarrollo suelen ser menos seguros: pueden ejecutar código inestable o configurarse con menos restricciones de seguridad necesarias para las pruebas y el desarrollo.

Si OSKernelDebuggingEnabled = 0 (False), permita el acceso.

Si OSKernelDebuggingEnabled = 1 (True), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
- Desencadene una acción correctiva, como informar al equipo de soporte técnico para que se ponga en contacto con el propietario para investigar el problema.
CodeIntegrityEnabled: cuando se habilita la integridad del código, la ejecución de código está restringida al código comprobado de integridad.

La integridad del código es una característica que valida la integridad de un controlador o archivo del sistema cada vez que se carga en la memoria. La integridad del código detecta si se está cargando un archivo de sistema o controlador sin signo en el kernel o si un archivo del sistema ha sido modificado por software malintencionado que está siendo ejecutado por una cuenta de usuario con privilegios de administrador.

En las versiones basadas en x64 del sistema operativo, los controladores en modo kernel deben estar firmados digitalmente.

Si CodeIntegrityEnabled = 1 (True), permite el acceso.

Si CodeIntegrityEnabled = 0 (False), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Permitir el acceso condicional en función de otros puntos de datos que estén presentes en el momento de la evaluación. Por ejemplo, otros atributos del certificado de estado o las actividades anteriores y el historial de confianza de un dispositivo.
- Realice una de las acciones anteriores y coloque el dispositivo en una lista de watch para supervisar más estrechamente el dispositivo en busca de posibles riesgos.
TestSigningEnabled: cuando la firma de prueba está habilitada, el dispositivo no aplica la validación de firmas durante el arranque y permite que los controladores sin signo (como los módulos UEFI sin firmar) se carguen durante el arranque.

La firma de prueba se puede deshabilitar o habilitar mediante los siguientes comandos en WMI o un script de PowerShell:
- Para deshabilitar la depuración de arranque, escriba bcdedit.exe /set {current} testsigning off .
- Para habilitar la depuración de arranque, escriba bcdedit.exe /set {current} testsigning on.
Si TestSigningEnabled = 0 (False), permita el acceso.

Si TestSigningEnabled = 1 (True), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos HBI y MBI.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
- Desencadene una acción correctiva, como habilitar la firma de prueba mediante WMI o un script de PowerShell.
SafeMode: el modo seguro es una opción de solución de problemas para Windows que inicia el equipo en un estado limitado. Solo se inician los archivos básicos y los controladores necesarios para ejecutar Windows.

Si SafeMode = 0 (False), permita el acceso.

Si SafeMode = 1 (True), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Desencadene una acción correctiva, como informar al equipo de soporte técnico para que se ponga en contacto con el propietario para investigar el problema.
WinPE: El entorno de preinstalación de Windows (Windows PE) es un sistema operativo mínimo con servicios limitados que se usa para preparar un equipo para la instalación de Windows, copiar imágenes de disco desde un servidor de archivos de red e iniciar el programa de instalación de Windows.

Si WinPE = 0 (False), permita el acceso.

Si WinPE = 1 (True), limite el acceso a los recursos remotos necesarios para la instalación del sistema operativo Windows.
ELAMDriverLoaded (Windows Defender): para usar esta característica de informes, debe deshabilitar "Reanudación híbrida" en el dispositivo. El antimalware de inicio temprano (ELAM) proporciona protección para los equipos de la red cuando se inician y antes de que se inicialicen los controladores de terceros.

En la versión actual, este atributo solo supervisa o informa si se cargó un ELAM de microsoft (Windows Defender) durante el arranque inicial.

Si se espera que un dispositivo use un programa antivirus de terceros, omita el estado notificado.

Si se espera que un dispositivo use Windows Defender y ELAMDriverLoaded = 1 (True), permita el acceso.

Si se espera que un dispositivo use Windows Defender y ELAMDriverLoaded = 0 (False), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Desencadene una acción correctiva, como informar al equipo de soporte técnico para que se ponga en contacto con el propietario para investigar el problema.
VSMEnabled: el modo seguro virtual (VSM) es un contenedor que protege los recursos de alto valor de un kernel en peligro. VSM requiere aproximadamente 1 GB de memoria: tiene suficiente capacidad para ejecutar el servicio LSA que se usa para toda la intermediación de autenticación.

VSM se puede habilitar mediante el siguiente comando en WMI o un script de PowerShell:

bcdedit.exe /set {current} vsmlaunchtype auto

Si VSMEnabled = 1 (True), permita el acceso. Si VSMEnabled = 0 (False), realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- No permitir el acceso a los recursos de HBI.
- Desencadenar una acción correctiva, como informar al equipo de soporte técnico para que se ponga en contacto con el propietario para investigar el problema.
PCRHashAlgorithmID: este atributo es un atributo informativo que identifica el algoritmo HASH que usó TPM; no se requiere ninguna acción de cumplimiento.
BootAppSVN: este atributo identifica el número de versión de seguridad de la aplicación de arranque que se cargó durante el arranque inicial en el dispositivo atestiguado.

Si bootAppSVN notificado es igual a un valor aceptado, permita el acceso.

Si bootAppSVN notificado no es igual a un valor aceptado, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Dirija el dispositivo a una honeypot empresarial para supervisar aún más las actividades del dispositivo.
BootManagerSVN: este atributo identifica el número de versión de seguridad del Administrador de arranque que se cargó durante el arranque inicial en el dispositivo atestiguado.

Si bootManagerSVN notificado es igual a un valor aceptado, permita el acceso.

Si bootManagerSVN notificado no es igual a un valor aceptado, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Dirija el dispositivo a una honeypot empresarial para supervisar aún más las actividades del dispositivo.
TPMVersion: este atributo identifica la versión del TPM que se ejecuta en el dispositivo atestiguado. El nodo TPMVersion proporciona las respuestas "1" y "2":
- 1 significa la versión 1.2 de especificación de TPM
- 2 significa la versión 2.0 de especificación de TPM
En función de la respuesta que reciba del nodo TPMVersion:
- Si TPMVersion notificado es igual a un valor aceptado, permita el acceso.
- Si TPMVersion notificado no es igual a un valor aceptado, realice una de las siguientes acciones que se alineen con las directivas empresariales:
  - No permitir todo el acceso
  - Dirija el dispositivo a una honeypot empresarial para supervisar aún más las actividades del dispositivo.
PCR0: la medida que se captura en PCR[0] normalmente representa una vista coherente de la plataforma host entre ciclos de arranque. Contiene una medición de los componentes proporcionados por el fabricante de la plataforma host.

Los administradores de empresa pueden crear una lista de permitidos de valores de PCR de confianza[0], comparar el valor de PCR[0] de los dispositivos administrados (el valor comprobado y notificado por HAS) con la lista de permitidos y, a continuación, tomar una decisión de confianza en función del resultado de la comparación.

Si la empresa no tiene una lista de permitidos de valores de PCR aceptados[0], no realice ninguna acción. Si PCR[0] es igual a un valor de allowlist aceptado, permita el acceso.

Si PCR[0] no es igual a ningún valor enumerado aceptado, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Dirija el dispositivo a una honeypot empresarial para supervisar aún más las actividades del dispositivo.
SBCPHash: SBCPHash es la impresión dedo de la directiva de configuración de arranque seguro personalizado (SBCP) que se cargó durante el arranque en dispositivos Windows, excepto en equipos.

Si SBCPHash no está presente o es un valor permitido aceptado, permita el acceso.

Si SBCPHash está presente en DHA-Report y no es un valor permitido, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
CIPolicy: este atributo indica la directiva de integridad de código que controla la seguridad del entorno de arranque.

Si CIPolicy no está presente o es un valor permitido aceptado, permita el acceso.

Si CIPolicy está presente y no es un valor de la lista de permitidos, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Coloque el dispositivo en una lista de watch para supervisar el dispositivo más estrechamente en busca de posibles riesgos.
BootRevListInfo: este atributo identifica la lista de revisiones de arranque que se cargó durante el arranque inicial en el dispositivo atestiguado.

Si la versión bootRevListInfo notificada es igual a un valor aceptado, permita el acceso.

Si la versión BootRevListInfo notificada no es igual a un valor aceptado, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Dirija el dispositivo a una honeypot empresarial para supervisar aún más las actividades del dispositivo.
OSRevListInfo: este atributo identifica la lista de revisiones del sistema operativo que se cargó durante el arranque inicial en el dispositivo atestiguado.

Si la versión de OSRevListInfo notificada es igual a un valor aceptado, permita el acceso.

Si la versión de OSRevListInfo notificada no es igual a un valor aceptado, realice una de las siguientes acciones que se alineen con las directivas empresariales:
- Impedir todo acceso.
- Dirija el dispositivo a una honeypot empresarial para supervisar aún más las actividades del dispositivo.
HealthStatusMismatchFlags: el atributo HealthStatusMismatchFlags aparece si DHA-Service detecta un problema de integridad (falta de coincidencia) en el DHA-Data que recibe de las soluciones de administración de dispositivos, para la validación.

Si se detecta un problema, se mostrará una lista de elementos dha-report afectados en el atributo HealthStatusMismatchFlags.

DHA-Report ejemplo

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

Estado y códigos de error de HEALTHAttestation CSP

Código de error	Nombre del error	Descripción del error
0	HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED	Este estado es el estado inicial de los dispositivos que nunca han participado en una sesión dha.
1	HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED	Este estado indica que la llamada Exec del cliente MDM en el nodo VerifyHealth se ha desencadenado y ahora el sistema operativo está intentando recuperar DHA-EncBlob de DHA-Server.
2	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED	Este estado indica que el dispositivo no pudo recuperar DHA-EncBlob de DHA-Server.
3	HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE	Este estado indica que el dispositivo ha recuperado correctamente DHA-EncBlob del dha-server.
4	HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL	En desuso en Windows 10, versión 1607.
5	HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL	DHA-CSP no pudo obtener una cita de notificación.
6	HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY	Error de DHA-CSP al abrir un identificador al proveedor criptográfico de la plataforma Microsoft.
7	HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL	Error de DHA-CSP al recuperar AIK de Windows
8	HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL	En desuso en Windows 10, versión 1607.
9	HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION	Versión de TPM no válida (la versión de TPM no es 1.2 o 2.0)
10	HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL	Nonce no se encontró en el registro.
11	HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL	No se encontró el identificador de correlación en el registro.
12	HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL	En desuso en Windows 10, versión 1607.
13	HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL	En desuso en Windows 10, versión 1607.
14	HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL	Error en las funciones de codificación. (Escenario extremadamente improbable)
15	HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL	En desuso en Windows 10, versión 1607.
16	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML	DHA-CSP no pudo cargar la carga que recibió de DHA-Service.
17	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML	DHA-CSP recibió una respuesta dañada de DHA-Service.
18	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY	DHA-CSP recibió una respuesta vacía de DHA-Service.
19	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK	Error de DHA-CSP al descifrar la clave de AES del desafío de EK.
20	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK	ERROR de DHA-CSP al descifrar el certificado de mantenimiento con la clave AES.
21	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB	Error de DHA-CSP al exportar la clave pública de AIK.
22	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY	ERROR de DHA-CSP al intentar crear una notificación con datos de atestación de AIK.
23	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB	ERROR de DHA-CSP al anexar el AIK Pub al blob de solicitud.
24	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT	ERROR de DHA-CSP al anexar el certificado AIK al blob de solicitud.
25	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE	DHA-CSP no pudo obtener un identificador de sesión.
26	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE	DHA-CSP no pudo conectarse al dha-service.
27	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND	DHA-CSP no pudo crear un identificador de solicitud HTTP.
28	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION	DHA-CSP no pudo establecer las opciones.
29	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS	DHA-CSP no pudo agregar encabezados de solicitud.
30	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST	DHA-CSP no pudo enviar la solicitud HTTP.
31	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE	DHA-CSP no pudo recibir una respuesta del dha-service.
32	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS	DHA-CSP no pudo consultar los encabezados al intentar obtener código de estado HTTP.
33	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE	DHA-CSP recibió una respuesta vacía de DHA-Service aunque el estado HTTP era correcto.
34	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE	DHA-CSP recibió una respuesta vacía junto con un código de error HTTP de DHA-Service.
35	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER	DHA-CSP no pudo suplantar al usuario.
36	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR	DHA-CSP no pudo adquirir los activadores de PDC necesarios para la comunicación de red cuando el dispositivo está en modo de espera conectado.
0xFFFF	HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN	Error de DHA-CSP debido a una razón desconocida, es muy poco probable que se produzca este error.
400	Bad_Request_From_Client	DHA-CSP ha recibido una solicitud de atestación incorrecta (con formato incorrecto).
404	Endpoint_Not_Reachable	no se puede acceder a DHA-Service mediante DHA-CSP

Consideraciones de seguridad

DHA delimita su confianza en el TPM y sus medidas. Si las medidas de TPM se pueden suplantar o manipular, DHA no puede proporcionar ninguna garantía de estado del dispositivo para ese dispositivo.

Para obtener más información, consulte Certificación de TPM de cliente de PC.

Referencia de proveedor de servicios de configuración

HealthAttestation CSP

AttestErrorMessage

AttestStatus

Certificado

CorrelationID

CurrentProtocolVersion

ForceRetrieve

GetAttestReport

GetServiceCorrelationIDs

HASEndpoint

MaxSupportedProtocolVersion

Nonce

PreferredMaxProtocolVersion

Estado

TpmReadyStatus

TriggerAttestation

VerifyHealth

atestación de estado del dispositivo Windows 11

Flujo de atestación con microsoft Azure Attestation Service

Pasos de integración de CSP de MAA

Más información

Windows 10 Device HealthAttestation

Pasos de integración de DHA-CSP

Paso 1: Comprobar el acceso HTTPS

Paso 2: Asignar una DHA-Service de confianza empresarial

Paso 3: Indicar al cliente que prepare los datos de estado para la verificación

Paso 4: Realizar acciones en función de la respuesta del cliente

Paso 5: Indicar al cliente que reenvíe los datos de atestación de estado para la comprobación

Paso 6: Reenvío de datos de atestación de estado del dispositivo al servicio DHA

Paso 7: Recibir respuesta del servicio DHA

Paso 8: Tomar las medidas de directiva adecuadas en función de los resultados de la evaluación

esquema DHA-Report V3

DHA-Report ejemplo

Estado y códigos de error de HEALTHAttestation CSP

Consideraciones de seguridad

Comentarios

Comentarios

Recursos adicionales

HealthAttestation CSP

AttestErrorMessage

AttestStatus

Certificado

CorrelationID

CurrentProtocolVersion

ForceRetrieve

GetAttestReport

GetServiceCorrelationIDs

HASEndpoint

MaxSupportedProtocolVersion

Nonce

PreferredMaxProtocolVersion

Estado

TpmReadyStatus

TriggerAttestation

VerifyHealth

atestación de estado del dispositivo Windows 11

Flujo de atestación con microsoft Azure Attestation Service

Pasos de integración de CSP de MAA

Más información

Windows 10 Device HealthAttestation

Pasos de integración de DHA-CSP

Paso 1: Comprobar el acceso HTTPS

Paso 2: Asignar una DHA-Service de confianza empresarial

Paso 3: Indicar al cliente que prepare los datos de estado para la verificación

Paso 4: Realizar acciones en función de la respuesta del cliente

Paso 5: Indicar al cliente que reenvíe los datos de atestación de estado para la comprobación

Paso 6: Reenvío de datos de atestación de estado del dispositivo al servicio DHA

Paso 7: Recibir respuesta del servicio DHA

Paso 8: Tomar las medidas de directiva adecuadas en función de los resultados de la evaluación

esquema DHA-Report V3

DHA-Report ejemplo

Estado y códigos de error de HEALTHAttestation CSP

Consideraciones de seguridad

Artículos relacionados

Comentarios

Comentarios

Recursos adicionales