次の方法で共有

HealthAttestation CSP

  • [アーティクル]

Windows Insider のロゴ。

重要

この CSP には、開発中であり、Windows Insider Preview ビルド にのみ適用される一部の設定が含まれています。 これらの設定は変更する可能性があり、プレビューで他の機能やサービスに依存する場合があります。

Device HealthAttestation 構成サービス プロバイダー (DHA-CSP) を使用すると、エンタープライズ IT 管理者は、デバイスが信頼された準拠状態で起動されているかどうかを評価し、エンタープライズ ポリシーアクションを実行できます。

次の一覧は、Device HealthAttestation CSP によって実行される関数の説明です。

  • マネージド デバイスからデバイス ブート ログ、トラステッド プラットフォーム モジュール (TPM) 監査証跡、TPM 証明書 (DHA-BootData) を収集します
  • デバイス正常性構成証明サービス (DHA-Service) に DHA-BootData を転送する
  • DHA-Service から暗号化された BLOB (DHA-EncBlob) を受信し、デバイス上のローカル キャッシュに格納します
  • DHA-Enabled MDM から構成証明要求 (DHA-Requests) を受信し、Device Health 構成証明データ (DHA-Data) で応答します

次の一覧は、HealthAttestation 構成サービス プロバイダー ノードを示しています。

AttestErrorMessage

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows Insider Preview 
./Vendor/MSFT/HealthAttestation/AttestErrorMessage

AttestErrorMessage は、構成証明サービスによって返された場合、最後の構成証明セッションのエラー メッセージを保持します。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 [ゲームをゲット] を選びます

AttestStatus

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 11バージョン 21H2 [10.0.22000] 以降 
./Vendor/MSFT/HealthAttestation/AttestStatus

AttestStatus は、最後の構成証明セッションの成功または失敗の状態コードを保持します。

構成証明サービス呼び出しを行う前に、状態は常にクリアされます。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 int
アクセスの種類 [ゲームをゲット] を選びます

例:

  • テンプレート化された SyncML 呼び出し:

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

  • 応答の例:

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

証明書

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/Certificate

DHA-Data を MDM サーバーに転送するように DHA-CSP に指示します。

値型は base64 文字列です。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 [ゲームをゲット] を選びます

Correlationid

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/CorrelationID

一意のデバイス正常性構成証明セッションを識別します。 CorrelationId は、デバッグとトラブルシューティングのために、DHA-Service ログを MDM サーバー イベントとクライアント イベント ログに関連付けるために使用されます。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 [ゲームをゲット] を選びます

CurrentProtocolVersion

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1709 [10.0.16299] 以降 
./Vendor/MSFT/HealthAttestation/CurrentProtocolVersion

正常性構成証明サービスとの通信にクライアントが使用している現在のプロトコル バージョンを提供します。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 int
アクセスの種類 [ゲームをゲット] を選びます

ForceRetrieve

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/ForceRetrieve

クライアントに対して、DHA-Service への新しい要求を開始し、新しい DHA-EncBlob を取得するように指示します (DHA-Service によって発行されたブート状態の概要)。 このオプションは、MDM サーバーが証明書の更新ポリシーを適用する場合にのみ使用する必要があります。これは、デバイスが DHA-Service から新しい暗号化された BLOB を取得するように強制する必要があります。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 bool
アクセスの種類 取得、置換
既定値 False

指定可能な値

値 説明
false (既定値) False。
true True。

GetAttestReport

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 11バージョン 21H2 [10.0.22000] 以降 
./Vendor/MSFT/HealthAttestation/GetAttestReport

構成証明セッション レポートが存在する場合は取得します。

レポートは、それぞれの MDM 登録ストアのレジストリ キーに格納されます。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 [ゲームをゲット] を選びます

例:

  • テンプレート化された SyncML 呼び出し:

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

  • サンプル データ:

    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

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 11バージョン 21H2 [10.0.22000] 以降 
./Vendor/MSFT/HealthAttestation/GetServiceCorrelationIDs

存在する場合は、サービス相関 ID を取得します。

関連付け ID が複数ある場合は、文字列内の ";" で区切ります。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 [ゲームをゲット] を選びます

例:

  • テンプレート化された SyncML 呼び出し:

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

  • サンプル データ:

    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

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/HASEndpoint

構成証明を実行するために割り当てられている DHA-Service の完全修飾ドメイン名 (FQDN) を識別します。 FQDN が割り当てられない場合は、DHA-Cloud (Microsoft が所有および運用するクラウド サービス) が既定の構成証明サービスとして使用されます。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 取得、置換
既定値 has.spserv.microsoft.com。

MaxSupportedProtocolVersion

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1709 [10.0.16299] 以降 
./Vendor/MSFT/HealthAttestation/MaxSupportedProtocolVersion

このクライアントがサポートできる最大プロトコル バージョンを返します。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 int
アクセスの種類 [ゲームをゲット] を選びます

Nonce

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/Nonce

MDM サーバーによって生成される暗号化で保護されたランダム値を使用して、MDM が中間者型 (MITM) 攻撃からデバイスの正常性構成証明通信を保護できるようにします。 nonce は 16 進形式で、最小サイズは 8 バイト、最大サイズは 32 バイトです。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 取得、置換
既定値 \0

PreferredMaxProtocolVersion

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1709 [10.0.16299] 以降 
./Vendor/MSFT/HealthAttestation/PreferredMaxProtocolVersion

クライアントが通信するように構成されている推奨プロトコルの最大バージョンを提供します。 これがクライアントでサポートされているプロトコル バージョンよりも高い場合は、使用可能な最高のプロトコル バージョンが使用されます。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 int
アクセスの種類 取得、置換
既定値 3

状態

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/Status

デバイス正常性要求の現在の状態を提供します。 状態値の完全な一覧については、「 HealthAttestation CSP の状態とエラー コード」を参照してください。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 int
アクセスの種類 [ゲームをゲット] を選びます

TpmReadyStatus

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1607 [10.0.14393] 以降 
./Vendor/MSFT/HealthAttestation/TpmReadyStatus

TPM の状態を説明する情報のビットマスクを返します。 デバイスの TPM が準備完了状態で信頼済み状態かどうかを示します。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 int
アクセスの種類 [ゲームをゲット] を選びます

TriggerAttestation

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 11バージョン 21H2 [10.0.22000] 以降 
./Vendor/MSFT/HealthAttestation/TriggerAttestation

構成証明セッションを非同期的にトリガーするようにデバイスに通知します。

構成証明プロセスが正常に起動された場合、このノードは、要求が受信され、処理されていることを示すコード 202 を返します。 それ以外の場合は、エラーが返されます。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 chr (string)
アクセスの種類 Exec

例:

  • テンプレート化された SyncML 呼び出し:

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

  • データ フィールド:

    • rpID (証明書利用者識別子): このフィールドには、呼び出し元の特定に使用できる識別子が含まれています。
    • serviceEndpoint : このフィールドには、評価に使用する Microsoft Azure Attestation プロバイダー インスタンスの完全な URL が含まれています。
    • nonce: このフィールドには、暗号化通信で 1 回だけ使用できる任意の番号が含まれています。 多くの場合、再生攻撃で古い通信を再利用できないようにするために、認証プロトコルで発行されるランダムまたは擬似乱数です。
    • aadToken: Microsoft Azure Attestation サービスに対する認証に使用するMicrosoft Entra トークン。
    • cv: このフィールドには、サービス呼び出しに渡される識別子 (相関ベクトル) が含まれており、診断目的で使用できます。

  • サンプル <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

適用範囲 エディション 対象となる OS
✅ デバイス
❌ ユーザー		 ✅ Pro
✅ Enterprise
✅ Education
✅ Windows SE
✅ IoT Enterprise / IoT Enterprise LTSC		 ✅Windows 10バージョン 1511 [10.0.10586] 以降 
./Vendor/MSFT/HealthAttestation/VerifyHealth

デバイスの正常性検証要求を準備するようにデバイスに通知します。

説明フレームワークのプロパティ:

プロパティ名 プロパティ値
形式 null
アクセスの種類 Exec

デバイス正常性構成証明のWindows 11

Windows 11では、デバイス正常性構成証明機能の更新が導入されます。 この更新プログラムは、Windows ブート セキュリティに対するより深い分析情報のサポートを追加し、デバイス セキュリティに対するゼロ トラスト アプローチをサポートするのに役立ちます。 Windows のデバイス正常性構成証明には、HealthAttestation CSP を使用してアクセスできます。 この CSP は、デバイスが信頼された準拠状態で起動されているかどうかを評価し、適切なアクションを実行するのに役立ちます。 Windows 11では、MDM プロバイダーが Microsoft Azure Attestation サービスに接続するための HealthAttestation ノードにより多くの子ノードが導入され、構成証明に対する簡略化されたアプローチが提供されます。

構成証明レポートは、デバイスの起動時のプロパティの正常性評価を提供し、デバイスの電源が入るとすぐに自動的にセキュリティで保護されるようにします。 その後、正常性構成証明の結果を使用して、デバイスの正常性に応じて、ネットワーク、アプリ、またはサービスへのアクセスを許可または拒否できます。

使用される用語:

  • TPM (トラステッド プラットフォーム モジュール): TPM は、保護されたストレージ、乱数の生成、暗号化、署名を提供するなど、ハードウェアで保護された一連のセキュリティ操作を実行する、特殊なハードウェアで保護されたロジックです。
  • DHA (Device HealthAttestation) 機能: Device HealthAttestation (DHA) 機能を使用すると、企業の IT 管理者は、改ざん防止および改ざん防止の通信チャネルを介して、保護および証明されたハードウェア (TPM) データを使用して、マネージド デバイスのセキュリティ態勢をリモートで監視できます。
  • MAA セッション (Microsoft Azure Attestation サービス ベースのデバイス HealthAttestation セッション): Microsoft Azure Attestation サービス ベースのデバイス HealthAttestation セッション (MAA-Session) では、1 つのデバイス正常性構成証明セッションで実行されるエンドツーエンドの通信フローについて説明します。
  • MAA-CSP ノード (Microsoft Azure Attestation ベースの構成サービス プロバイダー): Microsoft Azure Attestation サービスと統合するためにWindows 11に追加された構成サービス プロバイダー ノード。 次の操作の一覧は、MAA-CSP によって実行されます。
    • HealthAttestation 対応 MDM プロバイダーから構成証明トリガー要求を受信します。
    • デバイスは、構成証明の証拠 (デバイスのブート ログ、TPM 監査証跡、TPM 証明書) をマネージド デバイスから収集します。
    • MDM プロバイダーによって構成されたAzure Attestation サービス インスタンスに構成証明の証拠を転送します。
    • Azure Attestation Service インスタンスから署名されたレポートを受信し、デバイス上のローカル キャッシュに格納します。
  • MAA エンドポイント: Microsoft Azure 構成証明サービスは Azure リソースであり、サービスのすべてのインスタンスは管理者が構成した URL を取得します。 生成される URI は本質的に一意であり、デバイス正常性構成証明の目的で MAA エンドポイントと呼ばれます。
  • JWT (JSON Web トークン): JSON Web トークン (JWT) は、JavaScript Object Notation (JSON) オブジェクトとして関係者間で情報を安全に送信するためのオープン標準のRFC7519メソッドです。 この情報はデジタル署名されているため、検証および信頼できます。 JWT は、シークレットまたは公開/秘密キーのペアを使用して署名できます。

Microsoft Azure Attestation Service を使用した構成証明フロー

Microsoft Azure Attestation Service を使用した構成証明フロー

構成証明フローは、大きく 3 つのメイン手順で実行できます。

  • Azure Attestation サービスのインスタンスは、適切な構成証明ポリシーで設定されます。 構成証明ポリシーを使用すると、MDM プロバイダーは、ブート内の特定のイベントとセキュリティ機能を証明できます。
  • MDM プロバイダーは構成証明サービスの呼び出しをトリガーし、デバイスは構成証明を実行チェックレポートを取得する準備が整います。
  • トークンが構成証明サービスから取得されていることを確認した後の MDM プロバイダーは、構成証明トークンを解析して、デバイスの構成証明された状態を反映できます。

詳細については、「 構成証明プロトコル」を参照してください。

MAA CSP 統合手順

  1. MAA プロバイダー インスタンスのセットアップ: MAA インスタンスは、「クイック スタート: Azure portalを使用してAzure Attestationを設定する」の手順に従って作成できます。

  2. 適切なポリシーでプロバイダーを更新する: MAA インスタンスは、適切なポリシーで更新する必要があります。 詳細については、「Azure Attestation ポリシーを作成する方法」を参照してください。

    サンプル構成証明ポリシー:

    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. と を使用して rpidAzure Active Directory token TriggerAttestation を呼び出しattestURI、手順 1 で生成された構成証明 URL を使用し、ヒットする適切な API バージョンを追加します。 API バージョンの詳細については、「 構成証明 - 構成証明 Tpm - REST API」を参照してください。

  4. GetAttestReport を呼び出し、レポートをデコードして解析して、構成証明されたレポートに必要なプロパティが含まれていることを確認します。GetAttestReport は署名された構成証明トークンを JWT として返します。 JWT をデコードして、構成証明ポリシーに従って情報を解析できます。

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

詳細情報

TPM 構成証明の詳細については、「Microsoft Azure Attestation」を参照してください。

Windows 10 Device HealthAttestation

使用される用語:

  • TPM (トラステッド プラットフォーム モジュール): TPM は、保護されたストレージ、乱数の生成、暗号化、署名を提供するなど、ハードウェアで保護された一連のセキュリティ操作を実行する、特殊なハードウェアで保護されたロジックです。

  • DHA (Device HealthAttestation) 機能: Device HealthAttestation (DHA) 機能を使用すると、企業の IT 管理者は、改ざん防止および改ざん防止の通信チャネルを介して、保護および証明されたハードウェア (TPM) データを使用して、マネージド デバイスのセキュリティ態勢をリモートで監視できます。

  • DHA 対応デバイス (Device HealthAttestation 対応デバイス): Device HealthAttestation enabled (DHA-Enabled) デバイスは、Windows 10を実行し、TPM バージョン 1.2 または 2.0 をサポートするコンピューティング デバイス (電話、デスクトップ、ノート PC、タブレット、サーバー) です。

  • DHA セッション (Device HealthAttestation セッション): Device HealthAttestation セッション (DHA セッション) では、1 つのデバイス正常性構成証明セッションで実行されるエンドツーエンドの通信フローについて説明します。 トランザクションの次の一覧は、1 つの DHA セッションで実行されます。

    DHA セッションの正常性の設定セッションの図

    • DHA-CSP と DHA-Service 通信:
      • DHA-CSP はデバイス ブート データ (DHA-BootData) を DHA-Service に転送します
      • 暗号化されたデータ BLOB (DHA-EncBlob) を使用した DHA-Service 応答
    • DHA-CSP と MDM-Server 通信:
      • MDM-Server は、デバイスの正常性検証要求を DHA-CSP に送信します
      • DHA-CSP は、暗号化された (DHA-EncBlob) と署名された (DHA-SignedBlob) データ BLOB を含む DHA-Data というペイロードで応答します
    • 通信の MDM-Server と DHA-Service:
      • MDM-Server デバイスから受信したデータを DHA-Service に投稿する
      • DHA-Service は、受信したデータを確認し、デバイス正常性レポートを使用して応答します (DHA-Report)

  • DHA セッション データ (Device HealthAttestation セッション データ): 次のデータの一覧は、1 つの DHA トランザクションで生成または使用されます。

    • DHA-BootData: デバイス ブートの正常性を検証するために必要なデバイス ブート データ (TCG ログ、PCR 値、デバイス/TPM 証明書、ブート、TPM カウンター)。
    • DHA-EncBlob: デバイスから受信した DHA-BootData を確認した後、デバイスに問題を DHA-Service する暗号化された概要レポート。
    • DHA-SignedBlob: デバイスの正常性構成証明時に DHA-CSP によってキャプチャされる、デバイスのランタイムの現在の状態の署名されたスナップショットです。
    • DHA-Data: デバイスの正常性検証のためにデバイスが MDM-Server 経由で DHA-Service するためにデバイスが転送する XML 形式のデータ BLOB。 DHA-Data には、次の 2 つの部分があります。
      • DHA-EncBlob: デバイスが DHA-Service から受信する暗号化されたデータ BLOB
      • DHA-SignedBlob: DHA-CSP によって生成されるデバイスの現在のセキュリティ状態の現在のスナップショット
    • DHA-Report: DHA-Service から MDM-Server に発行されたレポート
    • Nonce: MDM-Server によって生成される暗号化保護された番号。これは、中間者型の攻撃から DHA-Session を保護します

  • DHA 対応 MDM (Device HealthAttestation 対応デバイス管理ソリューション): Device HealthAttestation enabled (DHA-Enabled) デバイス管理ソリューションは、DHA 機能と統合されたデバイス管理ツールです。 DHA-Enabled デバイス管理ソリューションを使用すると、エンタープライズ IT マネージャーは、高度なセキュリティ脅威によってデバイスが侵害されたり、悪意のある (脱獄された) オペレーティング システムを実行している場合でも、信頼できるハードウェア (TPM) で保護されたデータに基づいて、マネージド デバイスのセキュリティ保護バーを上げることができます。 次の操作の一覧は、DHA-Enabled-MDM によって実行されます。

    • DHA-Enabled デバイスで DHA 機能を有効にする
    • 登録済み/管理対象デバイスにデバイス正常性構成証明要求を発行する
    • デバイス正常性構成証明データ (DHA-Data) を収集し、検証のためにデバイス正常性構成証明サービス (DHA-Service) に送信します
    • コンプライアンス アクションをトリガーする DHA-Service からデバイス正常性レポート (DHA-Report) を取得します

  • DHA-CSP (Device HealthAttestation Configuration Service Provider): Device HealthAttestation Configuration Service Provider (DHA-CSP) は、デバイスの TPM とファームウェアを使用して、デバイスの BIOS と Windows ブートの重要なセキュリティ プロパティを測定します。これにより、カーネル レベルのマルウェアやルートキットに感染したシステムでも、これらのプロパティはスプーフィングできません。 次の操作の一覧は、DHA-CSP によって実行されます。

    • マネージド デバイスからデバイス ブート データ (DHA-BootData) を収集します
    • デバイス正常性構成証明サービス (DHA-Service) に DHA-BootData を転送する
    • DHA-Service から暗号化された BLOB (DHA-EncBlob) を受信し、デバイス上のローカル キャッシュに格納します
    • DHA-Enabled MDM から構成証明要求 (DHA-Requests) を受信し、Device Health 構成証明データ (DHA-Data) で応答します

  • DHA-Service (Device HealthAttestation Service): Device HealthAttestation Service (DHA-Service) は、DHA-CSP から受信したデータを検証し、信頼性の高いハードウェア (TPM) で保護されたレポート (DHA-Report) を発行して、改ざん防止および改ざんが明らかな通信チャネルを通じてデバイス管理ソリューションを DHA-Enabled します。 DHA-Service は、"DHA-Cloud" と "DHA-Server2016" の 2 種類のフレーバーで利用できます。 DHA-Service では、クラウド、オンプレミス、エアギャップ、ハイブリッドシナリオなど、さまざまな実装シナリオがサポートされています。 次の操作の一覧は、DHA-Service によって実行されます。

    • DHA-Enabled デバイスからデバイス ブート データ (DHA-BootData) を受信します
    • デバイス正常性構成証明サービス (DHA-Service) に DHA-BootData を転送する
    • DHA-Service から暗号化された BLOB (DHA-EncBlob) を受信し、デバイス上のローカル キャッシュに格納します
    • DHA 対応 MDM から構成証明要求 (DHA-Requests) を受信し、デバイス正常性レポート (DHA-Report) で応答します

さまざまな DHS サービスの正常性構成証明サービスの図

DHA-Service 型 説明 運用コスト
デバイス正常性構成証明 - クラウド (DHA-Cloud) DHA-Cloud は、Microsoft が所有および運用する次の DHA-Service です。
  • Windows で無料で利用できる
  • 高可用性と地理的にバランスの取れたクラウド インフラストラクチャでの実行
  • 既定のデバイス構成証明サービス プロバイダーとして、ほとんどの DHA-Enabled デバイス管理ソリューションでサポートされています
  • 次の方法で、すべてのエンタープライズ管理デバイスからアクセスできます。
    • FQDN = has.spserv.microsoft.com ポート
    • ポート = 443
    • プロトコル = TCP
    		•  コストなし
    デバイス正常性構成証明 - オンプレミス (DHA-OnPrem) DHA-OnPrem は、オンプレミスで実行されている DHA-Service を指します。
  • Windows Server 2016顧客に提供 (DHA-Service を有効/実行するための追加ライセンス コストなし)
  • エンタープライズ所有およびマネージド サーバー デバイス/ハードウェアでホストされる
  • オンプレミスおよびハイブリッド (Cloud + OnPrem) ハードウェア構成証明シナリオをサポートする第 1 およびサード パーティの DHA-Enabled デバイス管理ソリューション プロバイダーによってサポートされます
  • 次の設定を使用して、すべてのエンタープライズマネージド デバイスからアクセスできます。
    • FQDN = (エンタープライズ割り当て)
    • Port = (エンタープライズ割り当て)
    • プロトコル = TCP
    		•  Server 2016 オンプレミスの 1 つ以上のインスタンスを実行する操作コスト。
    デバイス正常性構成証明 - Enterprise-Managed Cloud(DHA-EMC) DHA-EMC とは、エンタープライズで管理される DHA-Service を指し、Microsoft Azure など、Windows Server 2016互換のエンタープライズマネージド クラウド サービスで仮想ホスト/サービスとして実行されます。
  • 追加のライセンス コストなしでWindows Server 2016のお客様に提供されます (DHA-Service を有効/実行するための追加ライセンス コストなし)
  • オンプレミスおよびハイブリッド (Cloud + OnPrem) ハードウェア構成証明シナリオをサポートする第 1 およびサード パーティの DHA-Enabled デバイス管理ソリューション プロバイダーによってサポートされます
  • 次の設定を使用して、すべてのエンタープライズマネージド デバイスからアクセスできます。
    • FQDN = (エンタープライズ割り当て)
    • Port = (エンタープライズ割り当て)
    • プロトコル = TCP
    		•  Microsoft Azure などの互換性のあるクラウド サービスで Server 2016 を実行する操作コスト。

    DHA-CSP 統合手順

    次の検証タスクと開発タスクの一覧は、Microsoft Device Health 構成証明機能を Windows Mobile デバイス管理ソリューション (MDM) と統合するために必要です。

    1. HTTPS アクセスの確認
    2. エンタープライズ信頼された DHA-Service を割り当てる
    3. 検証のために DHA データを準備するようにクライアントに指示する
    4. クライアントの応答に基づいてアクションを実行する
    5. 検証のために DHA データを転送するようにクライアントに指示する
    6. DHA データを DHA サービスに投稿する
    7. DHA サービスからの応答を受信する
    8. データ DHA-Report 解析します。 評価結果に基づいて適切なポリシー アクションを実行する

    各手順については、このトピックの次のセクションで詳しく説明します。

    手順 1: HTTPS アクセスを確認する

    MDM サーバーとデバイス (MDM クライアント) の両方が、ポート 443 (HTTPS) 経由の TCP プロトコルを使用して has.spserv.microsoft.com にアクセスできることを検証します。

    OpenSSL を使用して、DHA-Service へのアクセスを検証できます。 サンプルの OpenSSL コマンドと、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)

    手順 2: エンタープライズ信頼された DHA-Service を割り当てる

    DHA サービスには次の 3 種類があります。

    • Device Health 構成証明 - クラウド (Microsoft が所有および運用)
    • デバイス正常性構成証明 - オンプレミス (企業が所有および運用し、オンプレミスでWindows Server 2016実行)
    • Device Health 構成証明 - Enterprise-Managed クラウド (企業が所有および運用し、互換性のあるエンタープライズマネージド クラウドWindows Server 2016上で実行)

    DHA-Cloud が既定の設定です。 企業が信頼された DHA-Service プロバイダーとして Microsoft DHA-Cloud を使用する予定がある場合は、これ以上の操作は必要ありません。

    DHA-OnPrem & DHA-EMC シナリオの場合は、SYNCML コマンドを HASEndpoint ノードに送信して、マネージド デバイスに対して、エンタープライズで信頼された DHA-Service と通信するように指示します。

    次の例は、マネージド デバイスにエンタープライズ管理の DHA-Service と通信するように指示するサンプル呼び出しを示しています。

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

    手順 3: 検証のために正常性データを準備するようにクライアントに指示する

    SYNCML 呼び出しを送信して、DHA-Data のコレクションを開始します。

    次の例は、マネージド デバイスからの正常性構成証明データの収集と検証をトリガーするサンプル呼び出しを示しています。

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

    手順 4: クライアントの応答に基づいてアクションを実行する

    クライアントは正常性構成証明要求を受け取ると、応答を送信します。 次の一覧では、応答と推奨されるアクションについて説明します。

    • 応答がHEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE (3) の場合は、次のセクションに進みます。
    • 応答が (1) またはHEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED場合は、アラートを待機してから、次のセクションに進みます。

    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>
    • 状態ノードへの応答が 0、1、または 3 ではない場合は、問題のトラブルシューティングを行います。 状態コードの完全な一覧については、「 HealthAttestation CSP の状態とエラー コード」を参照してください。

    手順 5: 検証のために正常性構成証明データを転送するようにクライアントに指示する

    Nonce、Certificate、CorrelationId ノードの呼び出しを作成し、正常性証明書と関連データを含む暗号化されたペイロードをデバイスから取得します。

    以下に例を示します。

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

    手順 6: デバイス正常性構成証明データを DHA サービスに転送する

    前の手順で送信された要求に応答して、MDM クライアントは XML 形式の BLOB (./Vendor/MSFT/HealthAttestation/Certificate ノードからの応答) と CorrelationId (./Vendor/MSFT/HealthAttestation/CorrelationId ノードへの応答) という呼び出し識別子を転送します。

    MDM-Server が上記のデータを受信する場合は、次の手順を実行する必要があります。

    • デバイスから受信した CorrelationId をログに記録し (今後のトラブルシューティング/参照のために)、呼び出しに関連付けます。

    • デバイスから受信する XML 形式のデータ BLOB をデコードする

    • MDM サービスによって生成された nonce (手順 5 でデバイスに転送された nonce を追加) を、デバイスによって次の形式で転送された XML 構造体に追加します。

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

    • 転送 (HTTP Post) XML データ構造体 (前の手順で追加された nonce を含む) を、次で実行される割り当てられた DHA-Service に転送します。

      • DHA-Cloud (Microsoft が所有および運用する DHA-Service) シナリオ: https://has.spserv.microsoft.com/DeviceHealthAttestation/ValidateHealthCertificate/v3
      • DHA-OnPrem または DHA-EMC: https://FullyQualifiedDomainName-FDQN/DeviceHealthAttestation/ValidateHealthCertificate/v3

    手順 7: DHA サービスからの応答を受信する

    Microsoft Device Health 構成証明サービスが検証の要求を受け取ると、次の手順を実行します。

    • 受信した暗号化されたデータの暗号化を解除します。
    • 受信したデータを検証します。
    • レポートを作成し、評価結果を XML 形式で SSL 経由で MDM サーバーに共有します。

    手順 8: 評価結果に基づいて適切なポリシー アクションを実行する

    MDM サーバーが検証済みデータを受信した後、その情報を使用して、データを評価することでポリシーの決定を行うことができます。 考えられるアクションは次のとおりです。

    • デバイスへのアクセスを許可します。
    • デバイスにリソースへのアクセスを許可しますが、さらに調査するためにデバイスにフラグを設定します。
    • デバイスがリソースにアクセスできないようにします。

    V3 スキーマの DHA-Report

    <?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 バージョン 3 の DHA-Service によって検証されます。

    • 発行済み: DHA レポートが MDM に評価または発行された日時。

    • AIKPresent: 構成証明 ID キー (AIK) がデバイスに存在する場合、デバイスに保証キー (EK) 証明書があることを示します。 EK 証明書を持たないデバイス以上に信頼できます。

      AIKPresent = True (1) の場合は、アクセスを許可します。

      AIKPresent = False (0) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 評価時に存在する他のデータ ポイントに基づいて条件付きアクセスを許可します。 たとえば、正常性証明書の他の属性、デバイスの過去のアクティビティと信頼履歴などです。
      • 前のアクションのいずれかを実行し、さらにデバイスをwatchリストに配置して、潜在的なリスクについてデバイスをより緊密に監視します。

    • ResetCount (TPM 2.0 をサポートするデバイスに対してのみ報告されます): この属性は、PC デバイスが休止状態になったか再開された回数を報告します。

    • RestartCount (TPM 2.0 をサポートするデバイスに対してのみ報告): この属性は、PC デバイスが再起動された回数を報告します。

    • DEPPolicy: デバイスで DEP ポリシーが有効になっている場合は、デバイスをより信頼できます。

      データ実行防止 (DEP) ポリシーは、メモリに対して追加のチェックを実行して、悪意のあるコードがシステム上で実行されるのを防ぐ一連のハードウェアおよびソフトウェア テクノロジを定義します。 セキュア ブートを使用すると、x86/amd64 と ARM NTOS の制限付きリストでロックをオンにできます。

      DEPPolicy は、WMI または PowerShell スクリプトで次のコマンドを使用して無効または有効にすることができます。

      • DEP を無効にするには、/set {current} nx AlwaysOffbcdedit.exe と入力します
      • DEP を有効にするには、/set {current} nx AlwaysOnbcdedit.exe と入力します

      DEPPolicy = 1 (オン) の場合は、アクセスを許可します。

      DEPPolicy = 0 (オフ) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 評価時に存在する他のデータ ポイントに基づいて条件付きアクセスを許可します。 たとえば、正常性証明書の他の属性、デバイスの過去のアクティビティと信頼履歴などです。
      • 前のアクションのいずれかを実行し、さらにデバイスをwatchリストに配置して、潜在的なリスクについてデバイスをより緊密に監視します。

      DEP ポリシーの評価は、クエリ時の非バイナリ状態です。 その後、オン/オフ状態にマップされます。

      DEP ポリシー レベル 説明 構成証明の報告レベル プロパティ値
      OptIn (既定の構成) DEP が適用されているのは、Windows システム コンポーネントとサービスだけです。 0 2
      Optout DEP はすべてのプロセスで有効になっています。 管理者は、DEP が適用されていない特定のアプリケーションの一覧を手動で作成できます。 1 3
      AlwaysOn DEP はすべてのプロセスで有効になっています。 3 1
      AlwaysOff DEP はどのプロセスでも有効になっていません。 2 0

    • BitLockerStatus (初回起動時に BitLocker が有効にされた場合に報告されます)。

      BitLocker が起動時に "オン" と報告されると、デバイスは、システムの電源がオフになっているか休止状態になったときに、ドライブに保存されているデータを不正なアクセスから保護できます。

      Windows BitLocker ドライブ暗号化は、Windows オペレーティング システム ボリュームに格納されているすべてのデータを暗号化します。 BitLocker は TPM を使用して Windows オペレーティング システムとユーザー データを保護し、コンピューターが無人、紛失、または盗難にあった場合でも、コンピューターが改ざんされないようにするのに役立ちます。

      コンピューターに互換性のある TPM が搭載されている場合、BitLocker は TPM を使用してデータを保護する暗号化キーをロックします。 その結果、TPM がコンピューターの状態を確認するまで、キーにアクセスできません。

      BitLockerStatus = 1 (オン) の場合は、アクセスを許可します。

      BitLockerStatus = 0 (オフ) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 評価時に存在する他のデータ ポイントに基づいて条件付きアクセスを許可します。 たとえば、正常性証明書の他の属性、デバイスの過去のアクティビティと信頼履歴などです。
      • 前のアクションのいずれかを実行し、さらにデバイスをwatchリストに配置して、潜在的なリスクについてデバイスをより緊密に監視します。

    • BootManagerRevListVersion: この属性は、ブート シーケンス/環境のセキュリティを追跡および管理できるようにするために、デバイスで実行されているブート マネージャーのバージョンを示します。

      BootManagerRevListVersion = [CurrentVersion]の場合は、アクセスを許可します。

      = [CurrentVersion] の場合 BootManagerRevListVersion !は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI および MBI 資産へのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。
      • 所有者に連絡して問題を調査するようにテクニカル サポート チームに通知するなど、是正措置をトリガーします。

    • CodeIntegrityRevListVersion: この属性は、ブート シーケンス中に整合性チェックを実行しているコードのバージョンを示します。 この属性を使用すると、デバイスで整合性チェックを実行する最新バージョンのコードが実行されているかどうか、またはセキュリティ リスク (取り消された) にさらされているかどうかを検出し、適切なポリシー アクションを適用するのに役立ちます。

      CodeIntegrityRevListVersion = [CurrentVersion]の場合は、アクセスを許可します。

      = [CurrentVersion] の場合 CodeIntegrityRevListVersion !は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI および MBI 資産へのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。
      • 所有者に連絡して問題を調査するようにテクニカル サポート チームに通知するなど、是正措置をトリガーします。

    • SecureBootEnabled: セキュア ブートが有効になっている場合、マシンの起動に使用されるコア コンポーネントには、デバイスを製造したorganizationによって信頼されている正しい暗号化署名が必要です。 UEFI ファームウェアは、マシンを起動する前に、この要件を検証します。 ファイルが改ざんされ、署名が破損した場合、システムは起動しません。

      SecureBootEnabled = 1 (True) の場合は、アクセスを許可します。

      SecurebootEnabled = 0 (False) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 評価時に存在する他のデータ ポイントに基づいて条件付きアクセスを許可します。 たとえば、正常性証明書の他の属性、デバイスの過去のアクティビティと信頼履歴などです。
      • 前のアクションのいずれかを実行し、さらにデバイスをwatchリストに配置して、潜在的なリスクについてデバイスをより緊密に監視します。

    • BootDebuggingEnabled: ブート デバッグが有効な場合は、開発とテストで使用されるデバイスを指します。 通常、テストと開発に使用されるデバイスのセキュリティは低くなります。デバイスが不安定なコードを実行する場合や、テストと開発に必要なセキュリティ制限が少なく構成される場合があります。

      WMI または PowerShell スクリプトで次のコマンドを使用して、ブート デバッグを無効または有効にすることができます。

      • ブート デバッグを無効にするには、 /set {current} bootdebug offbcdedit.exe と入力します。
      • ブート デバッグを有効にするには、「 bcdedit.exe /set {current} bootdebug on」と入力します。

      BootdebuggingEnabled = 0 (False) の場合は、アクセスを許可します。

      BootDebuggingEnabled = 1 (True) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。
      • WMI または PowerShell スクリプトを使用して VSM を有効にするなどの修正アクションをトリガーします。

    • OSKernelDebuggingEnabled: OSKernelDebuggingEnabled は、開発とテストで使用されるデバイスを指します。 通常、テストと開発に使用されるデバイスの安全性は低くなります。不安定なコードを実行したり、テストや開発に必要なセキュリティ制限を少なくして構成したりできます。

      OSKernelDebuggingEnabled = 0 (False) の場合は、アクセスを許可します。

      OSKernelDebuggingEnabled = 1 (True) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。
      • 所有者に連絡して問題を調査するようにテクニカル サポート チームに通知するなど、是正措置をトリガーします。

    • CodeIntegrityEnabled: コードの整合性が有効になっている場合、コードの実行は整合性検証済みコードに制限されます。

      コードの整合性は、ドライバーまたはシステム ファイルがメモリに読み込まれるたびに整合性を検証する機能です。 コード整合性は、署名されていないドライバーまたはシステム ファイルがカーネルに読み込まれているかどうか、または管理者特権を持つユーザー アカウントによって実行されている悪意のあるソフトウェアによってシステム ファイルが変更されたかどうかを検出します。

      オペレーティング システムの x64 ベースのバージョンでは、カーネル モード ドライバーはデジタル署名されている必要があります。

      CodeIntegrityEnabled = 1 (True) の場合は、アクセスを許可します。

      CodeIntegrityEnabled = 0 (False) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 評価時に存在する他のデータ ポイントに基づいて条件付きアクセスを許可します。 たとえば、正常性証明書の他の属性、デバイスの過去のアクティビティと信頼履歴などです。
      • 前のアクションのいずれかを実行し、さらにデバイスをwatchリストに配置して、潜在的なリスクについてデバイスをより緊密に監視します。

    • TestSigningEnabled: テスト署名が有効になっている場合、デバイスは起動時に署名検証を適用せず、署名されていないドライバー (署名されていない UEFI モジュールなど) を起動時に読み込むことができます。

      WMI または PowerShell スクリプトで次のコマンドを使用して、テスト署名を無効または有効にすることができます。

      • ブート デバッグを無効にするには、「 /set {current} testsigning off」とbcdedit.exe 入力します。
      • ブート デバッグを有効にするには、「 bcdedit.exe /set {current} testsigning on」と入力します。

      TestSigningEnabled = 0 (False) の場合は、アクセスを許可します。

      TestSigningEnabled = 1 (True) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI および MBI 資産へのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。
      • WMI または PowerShell スクリプトを使用してテスト署名を有効にするなどの修正アクションをトリガーします。

    • SafeMode: セーフ モードは、制限された状態でコンピューターを起動する Windows のトラブルシューティング オプションです。 Windows を実行するために必要な基本的なファイルとドライバーのみが起動されます。

      SafeMode = 0 (False) の場合は、アクセスを許可します。

      SafeMode = 1 (True) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 所有者に連絡して問題を調査するようにテクニカル サポート チームに通知するなど、是正措置をトリガーします。

    • WinPE: Windows プレインストール環境 (Windows PE) は、Windows インストール用のコンピューターの準備、ネットワーク ファイル サーバーからのディスク イメージのコピー、および Windows セットアップの開始に使用される、限られたサービスを備えた最小限のオペレーティング システムです。

      WinPE = 0 (False) の場合は、アクセスを許可します。

      WinPE = 1 (True) の場合は、Windows OS のインストールに必要なリモート リソースへのアクセスを制限します。

    • ELAMDriverLoaded (Windows Defender): このレポート機能を使用するには、デバイスで "ハイブリッド履歴書" を無効にする必要があります。 マルウェア対策 (ELAM) を早期起動すると、ネットワーク内のコンピューターが起動し、サードパーティ製ドライバーが初期化される前に保護されます。

      現在のリリースでは、この属性は、初回起動時に Microsoft ファースト パーティの ELAM (Windows Defender) が読み込まれた場合にのみ監視/レポートを行います。

      デバイスでサード パーティ製のウイルス対策プログラムを使用することが予想される場合は、報告された状態を無視します。

      デバイスで Windows Defender と ELAMDriverLoaded = 1 (True) を使用することが予想される場合は、アクセスを許可します。

      デバイスで Windows Defender と ELAMDriverLoaded = 0 (False) を使用することが予想される場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 所有者に連絡して問題を調査するようにテクニカル サポート チームに通知するなど、是正措置をトリガーします。

    • VSMEnabled: Virtual Secure Mode (VSM) は、侵害されたカーネルから価値の高い資産を保護するコンテナーです。 VSM には約 1 GB のメモリが必要です。すべての認証ブローカーに使用される LSA サービスを実行するのに十分な機能があります。

      VSM は、WMI または PowerShell スクリプトで次のコマンドを使用して有効にすることができます。

      bcdedit.exe /set {current} vsmlaunchtype auto

      VSMEnabled = 1 (True) の場合は、アクセスを許可します。 VSMEnabled = 0 (False) の場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • HBI 資産へのアクセスを禁止します。
      • 問題を調査する所有者に連絡するようにテクニカル サポート チームに通知するなど、是正措置をトリガーする

    • PCRHashAlgorithmID: この属性は、TPM によって使用された HASH アルゴリズムを識別する情報属性です。コンプライアンス アクションは必要ありません。

    • BootAppSVN: この属性は、構成証明されたデバイスで初回起動時に読み込まれたブート アプリケーションのセキュリティ バージョン番号を識別します

      報告された BootAppSVN が受け入れられた値と等しい場合は、アクセスを許可します。

      報告された BootAppSVN が受け入れられた値と等しくない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスのアクティビティをさらに監視するために、デバイスをエンタープライズ ハニーポットに指示します。

    • BootManagerSVN: この属性は、構成証明されたデバイスでの初回起動時に読み込まれたブート マネージャーのセキュリティ バージョン番号を識別します。

      報告された BootManagerSVN が受け入れられた値と等しい場合は、アクセスを許可します。

      報告された BootManagerSVN が受け入れられた値と等しくない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスのアクティビティをさらに監視するために、デバイスをエンタープライズ ハニーポットに指示します。

    • TPMVersion: この属性は、構成証明されたデバイスで実行されている TPM のバージョンを識別します。 TPMVersion ノードは、応答 "1" と "2" を提供します。

      • 1 は TPM 仕様バージョン 1.2 を意味します
      • 2 は TPM 仕様バージョン 2.0 を意味します

      TPMVersion ノードから受信した応答に基づいて、次の手順を実行します。

      • 報告された TPMVersion が受け入れられた値と等しい場合は、アクセスを許可します。
      • 報告された TPMVersion が受け入れられた値と等しくない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。
        • すべてのアクセスを禁止する
        • デバイスのアクティビティをさらに監視するために、デバイスをエンタープライズ ハニーポットに指示します。

    • PCR0: PCR[0] でキャプチャされる測定値は、通常、ブート サイクル間のホスト プラットフォームの一貫したビューを表します。 これには、ホスト プラットフォームの製造元によって提供されるコンポーネントの測定値が含まれています。

      エンタープライズ マネージャーは、信頼された PCR[0] 値の許可リストを作成し、マネージド デバイスの PCR[0] 値 (HAS によって検証および報告される値) を許可リストと比較し、比較の結果に基づいて信頼の決定を行うことができます。

      企業に受け入れられた PCR[0] 値の許可リストがない場合は、アクションを実行しないでください。 PCR[0] が許可された許可リスト値と等しい場合は、アクセスを許可します。

      PCR[0] が一覧表示された値と等しくない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスのアクティビティをさらに監視するために、デバイスをエンタープライズ ハニーポットに指示します。

    • SBCPHash: SBCPHash は、PC を除く Windows デバイスで起動中に読み込まれたカスタム セキュア ブート構成ポリシー (SBCP) のフィンガー プリントです。

      SBCPHash が存在しない場合、または許可されている許可リスト値の場合は、アクセスを許可します。

      SBCPHash が DHA-Report に存在し、許可リストに記載されていない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。

    • CIPolicy: この属性は、ブート環境のセキュリティを制御するコード整合性ポリシーを示します。

      CIPolicy が存在しない場合、または許可されている許可リスト値の場合は、アクセスを許可します。

      CIPolicy が存在し、許可されている値でない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスをwatchリストに配置して、潜在的なリスクをより詳細に監視します。

    • BootRevListInfo: この属性は、構成証明されたデバイスでの初回起動時に読み込まれたブートリビジョンリストを識別します。

      報告された BootRevListInfo バージョンが受け入れられた値と等しい場合は、アクセスを許可します。

      報告された BootRevListInfo バージョンが受け入れられた値と等しくない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスのアクティビティをさらに監視するために、デバイスをエンタープライズ ハニーポットに指示します。

    • OSRevListInfo: この属性は、構成証明されたデバイスでの初回起動時に読み込まれたオペレーティング システムリビジョンリストを識別します。

      報告された OSRevListInfo バージョンが受け入れられた値と等しい場合は、アクセスを許可します。

      報告された OSRevListInfo バージョンが受け入れられた値と等しくない場合は、エンタープライズ ポリシーに合わせて次のいずれかのアクションを実行します。

      • すべてのアクセスを禁止します。
      • デバイスのアクティビティをさらに監視するために、デバイスをエンタープライズ ハニーポットに指示します。

    • HealthStatusMismatchFlags: HealthStatusMismatchFlags 属性は、DHA-Service がデバイス管理ソリューションから受信した DHA-Data で検証のために整合性の問題 (不一致) を検出した場合に表示されます。

      問題が検出されると、影響を受ける DHA レポート要素の一覧が HealthStatusMismatchFlags 属性の下に一覧表示されます。

    DHA-Report 例

    <?xml version="1.0" encoding="utf-8"?>
<HealthCertificateValidationResponse xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ErrorCode="0" ProtocolVersion="0"
xmlns="http://schemas.microsoft.com/windows/security/healthcertificate/validation/response/v3">
<HealthCertificateProperties>
     <Issued>2016-10-21T02:12:58.6656577Z</Issued>
     <AIKPresent>false</AIKPresent>
     <ResetCount>2107533174</ResetCount>
     <RestartCount>2749041230</RestartCount>
     <DEPPolicy>0</DEPPolicy>
     <BitlockerStatus>0</BitlockerStatus>
     <BootManagerRevListVersion>0</BootManagerRevListVersion>
     <CodeIntegrityRevListVersion>0</CodeIntegrityRevListVersion>
     <SecureBootEnabled>false</SecureBootEnabled>
     <BootDebuggingEnabled>false</BootDebuggingEnabled>
     <OSKernelDebuggingEnabled>false</OSKernelDebuggingEnabled>
     <CodeIntegrityEnabled>true</CodeIntegrityEnabled>
     <TestSigningEnabled>true</TestSigningEnabled>
     <SafeMode>false</SafeMode>
     <WinPE>false</WinPE>
     <ELAMDriverLoaded>true</ELAMDriverLoaded>
     <VSMEnabled>false</VSMEnabled>
     <PCRHashAlgorithmID>0</PCRHashAlgorithmID>
     <BootAppSVN>1</BootAppSVN>
     <BootManagerSVN>1</BootManagerSVN>
     <TpmVersion>2</TpmVersion>
     <PCR0>4ACCBE0ADB9627FFD6285C2E06EC5AC59ABF62C7</PCR0>
     <CIPolicy>00000000000001001A000B00200000005300690050006F006C006900630079002E007000370062000000A4BF7EF05585876A61CBFF7CAE8123BE756D58B1BBE04F9719D15D6271514CF5</CIPolicy>
     <BootRevListInfo>005D447A7CC6D101200000000B00CBB56E8B19267E24A2986C4A616CCB58B4D53F6020AC8FD5FC205C20F2AB00BC</BootRevListInfo>
     <OSRevListInfo>8073EEA7F8FAD001200000000B00A8285B04DE618ACF4174C59F07AECC002D11DD7D97FA5D464F190C9D9E3479BA</OSRevListInfo>
 </HealthCertificateProperties>
</HealthCertificateValidationResponse>

    HealthAttestation CSP の状態とエラー コード

    エラー コード エラー名 エラーの説明
    0 HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED この状態は、DHA セッションに参加したことがないデバイスの初期状態です。
    1 HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED この状態は、ノード VerifyHealth での MDM クライアントの Exec 呼び出しがトリガーされ、OS が DHA-Server から DHA-EncBlob を取得しようとしていることを示します。
    2 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED この状態は、デバイスが DHA-Server から DHA-EncBlob を取得できなかったことを示します。
    3 HEALTHATTESTATION_CERT_RETRIEVAL_COMPLETE この状態は、デバイスが DHA-Server から DHA-EncBlob を正常に取得したことを示します。
    4 HEALTHATTESTATION_CERT_RETRIEVAL_PCR_FAIL バージョン 1607 Windows 10では非推奨です。
    5 HEALTHATTESTATION_CERT_RETRIEVAL_GETQUOTE_FAIL DHA-CSP が要求の見積もりを取得できませんでした。
    6 HEALTHATTESTATION_CERT_RETRIEVAL_DEVICE_NOT_READY DHA-CSP が Microsoft Platform Crypto Provider へのハンドルを開くことに失敗しました。
    7 HEALTHATTESTATION_CERT_RETRIEVAL_WINDOWS_AIK_FAIL DHA-CSP が Windows AIK の取得に失敗しました
    8 HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL バージョン 1607 Windows 10では非推奨です。
    9 HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION 無効な TPM バージョン (TPM バージョンが 1.2 または 2.0 ではありません)
    10 HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL レジストリに Nonce が見つかりませんでした。
    11 HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL 関連付け ID がレジストリに見つかりませんでした。
    12 HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL バージョン 1607 Windows 10では非推奨です。
    13 HEALTHATTESTATION_CERT_RETRIEVAL_GETCLAIM_FAIL バージョン 1607 Windows 10では非推奨です。
    14 HEALTHATTESTATION_CERT_RETRIEVAL_ENCODING_FAIL エンコード関数のエラー。 (非常に可能性の低いシナリオ)
    15 HEALTHATTESTATION_CERT_RETRIEVAL_ENDPOINTOVERRIDE_FAIL バージョン 1607 Windows 10では非推奨です。
    16 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_LOAD_XML DHA-CSP は、DHA-Service から受信したペイロードを読み込めませんでした。
    17 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CORRUPT_XML DHA-CSP は、DHA-Service から破損した応答を受信しました。
    18 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY DHA-CSP は、DHA-Service から空の応答を受信しました。
    19 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_AES_EK DHA-CSP は、EK チャレンジから AES キーの暗号化を解除できませんでした。
    20 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_DECRYPT_CERT_AES_EK DHA-CSP は、AES キーを使用して正常性証明書の暗号化を解除できませんでした。
    21 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EXPORT_AIKPUB DHA-CSP が AIK 公開キーのエクスポートに失敗しました。
    22 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_CLAIMAUTHORITYONLY DHA-CSP は、AIK 構成証明データを使用して要求を作成しようとして失敗しました。
    23 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKPUB DHA-CSP が要求 BLOB に AIK Pub を追加できませんでした。
    24 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_APPEND_AIKCERT DHA-CSP が要求 BLOB に AIK 証明書を追加できませんでした。
    25 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_INIT_HTTPHANDLE DHA-CSP がセッション ハンドルを取得できませんでした。
    26 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_GETTARGET_HTTPHANDLE DHA-CSP が DHA-Service に接続できませんでした。
    27 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_CREATE_HTTPHAND DHA-CSP で HTTP 要求ハンドルを作成できませんでした。
    28 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SET_INTERNETOPTION DHA-CSP でオプションを設定できませんでした。
    29 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ADD_REQUESTHEADERS DHA-CSP が要求ヘッダーを追加できませんでした。
    30 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_SEND_REQUEST DHA-CSP が HTTP 要求を送信できませんでした。
    31 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_RECEIVE_RESPONSE DHA-CSP が DHA-Service からの応答を受信できませんでした。
    32 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_QUERY_HEADERS DHA-CSP は、HTTP 状態コードを取得しようとしたときにヘッダーのクエリを実行できませんでした。
    33 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_EMPTY_RESPONSE DHA-CSP は、HTTP 状態が OK であったにもかかわらず、DHA-Service から空の応答を受信しました。
    34 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_MISSING_RESPONSE DHA-CSP は、DHA-Service から HTTP エラー コードと共に空の応答を受信しました。
    35 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_IMPERSONATE_USER DHA-CSP がユーザーの偽装に失敗しました。
    36 HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_ACQUIRE_PDCNETWORKACTIVATOR DHA-CSP は、デバイスがコネクト スタンバイ モードのときにネットワーク通信に必要な PDC アクティベーターを取得できませんでした。
    0xFFFF HEALTHATTESTATION_CERT_RETRIEVAL_FAILED_UNKNOWN DHA-CSP は不明な理由のために失敗しました。このエラーが発生する可能性は非常に低いです。
    400 Bad_Request_From_Client DHA-CSP は、不適切な (形式が正しくない) 構成証明要求を受け取っています。
    404 Endpoint_Not_Reachable DHA-Service に DHA-CSP が到達できない

    セキュリティの考慮事項

    DHA は、TPM とその測定値に対する信頼を固定します。 TPM の測定値がなりすましまたは改ざんされる可能性がある場合、DHA はそのデバイスのデバイスの正常性を保証できません。

    詳細については、「 PC クライアント TPM 認定」を参照してください。

    構成サービス プロバイダーのリファレンス