次の方法で共有

Windows デバイスの正常性を制御する

  • [アーティクル]
  • 適用対象:
    ✅ Windows 11, ✅ Windows 10

この記事では、Windows デバイスの正常性を強制、制御、およびレポートすることで、価値の高い資産を保護するのに役立つエンド ツー エンド のソリューションについて説明します。

概要

Bring Your Own Device (BYOD) シナリオでは、ユーザーは商用のデバイスを持ち込んで、仕事関連のリソースと個人データの両方にアクセスします。 ユーザーは、任意のデバイスを使用して、組織のアプリケーション、データ、リソースに内部ネットワークからだけでなく、どこからでもアクセスしたいと考えています。 この現象は、IT のコンシューマー化とも呼ばれます。

ユーザーは、会社のアプリケーションにアクセスし、デバイスから組織データに取り組むときに、最高の生産性エクスペリエンスを得たいと考えています。 つまり、アプリケーションまたはファイル サーバーにアクセスするたびに、作業資格情報の入力を求められるのは許容されません。 セキュリティの観点からは、ユーザーが管理されていないデバイス上の企業の資格情報と企業データを操作することも意味します。

BYOD の使用が増えることで、企業のサービス、内部リソース、クラウド アプリにアクセスする、より管理されていない可能性のある異常なシステムが増えます。

マネージド デバイスでも侵害され、有害になる可能性があります。 組織は、価値の高い資産を保護するために、セキュリティが侵害されたタイミングを検出し、できるだけ早く対応する必要があります。

Microsoft が前進するにつれて、セキュリティへの投資は、セキュリティ予防防御と検出と対応の機能にますます焦点を当てています。

Windows は、セキュリティ予防防御の実装だけでなく、全体的なセキュリティ戦略にデバイス正常性構成証明機能を追加するエンドツーエンドのセキュリティ ソリューションの重要なコンポーネントです。

堅牢なエンドツーエンドのセキュリティ ソリューションの説明

今日のコンピューティングの脅威の状況は、かつてない速度で増加しています。 犯罪攻撃の高度化が進み、マルウェアがすべての業界の消費者と専門家の両方を標的にしていることは間違いありません。

近年、脅威の特定のカテゴリの 1 つが普及しています。高度な永続的な脅威 (APT) です。 APT という用語は、個々の組織を継続的にターゲットと思われる攻撃を記述するために一般的に使用されます。 実際、この種の攻撃には通常、必要な方法や手法を使用する可能性のある特定の敵対者が含まれます。

BYOD 現象では、保守が不十分なデバイスが選択のターゲットを表します。 攻撃者にとっては、セキュリティ ネットワークの境界を侵害し、アクセスし、価値の高い資産を盗む簡単な方法です。

攻撃者は個人を標的にしています。具体的には、自分が誰であるかではなく、誰のために働いているかによってターゲットを絞ります。 感染したデバイスは、組織がネットワークの境界を強化したか、防御的な姿勢に投資した場合でも、マルウェアを組織に取り込みます。 防御戦略では、これらの脅威に対して十分ではありません。

別のアプローチ

従来の侵害防止に焦点を当てるのではなく、効果的なセキュリティ戦略は、決定された敵対者が防御に正常に違反することを前提としています。 これは、予防的なセキュリティ制御から、セキュリティの問題の検出と対応に焦点を移す必要があることを意味します。 したがって、リスク管理戦略の実施は、予防、検出、対応への投資のバランスを取ります。

モバイル デバイスは企業情報へのアクセスにますます使用されるため、デバイスのセキュリティや正常性を評価する何らかの方法が必要です。 このセクションでは、価値の高い資産を異常なデバイスから保護できるように、デバイスの正常性評価をプロビジョニングする方法について説明します。

企業リソースへのアクセスに使用されるデバイスは信頼されている必要があります。 効率的なエンドツーエンドのセキュリティ アプローチでは、デバイスの正常性を評価し、価値の高い資産へのアクセスを許可するときに現在のセキュリティ状態を使用できます。

図 1.

堅牢な設計では、ユーザーの ID を確立し、必要に応じて認証方法を強化し、ユーザーが定期的に接続するネットワークの場所などの動作を学習する必要があります。 また、最新のアプローチでは、ユーザー デバイスが正常で安全であると判断された場合にのみ、機密性の高いコンテンツをリリースできる必要があります。

次の図は、クラウドからデバイスの正常性を評価するために構築されたソリューションを示しています。 デバイスは、クラウド内の ID プロバイダーへの接続を介してユーザーを認証します。 マネージド資産に機密性の高い情報が含まれている場合、ID プロバイダーの条件付きアクセス エンジンは、アクセスが許可される前に、モバイル デバイスのセキュリティ コンプライアンスを確認することを選択できます。 ユーザーのデバイスは、いつでも、またはモバイル デバイス管理 (MDM) から要求されたときに送信できる正常性状態を証明できます。

図 2。

Windows デバイスは、統合拡張ファームウェア インターフェイス (UEFI) セキュア ブートなどの低レベルのハードウェア テクノロジを使用して、低レベルのルートキットとブートキットから保護できます。

セキュア ブートは、ルートキット攻撃を防ぐのに役立つファームウェア検証プロセスです。これは UEFI 仕様の一部です。 UEFI の目的は、オペレーティング システムが最新のハードウェアと通信するための標準的な方法を定義することです。これにより、古いソフトウェア割り込み駆動 BIOS システムよりも高速で効率的な入出力 (I/O) 機能を実行できます。

デバイス正常性構成証明モジュールは、トラステッド プラットフォーム モジュール (TPM) によって保護されている測定されたブート データをリモート サービスに通信できます。 デバイスが正常に起動すると、ブート プロセス測定データは、より安全で改ざん防止の通信チャネルを使用して、信頼されたクラウド サービス (正常性構成証明サービス) に送信されます。

リモート正常性構成証明サービスは、測定値に対して一連のチェックを実行します。 ブート状態 (セキュア ブート、デバッグ モードなど) や、セキュリティを管理するコンポーネントの状態 (BitLocker、Device Guard など) など、セキュリティ関連のデータ ポイントを検証します。 その後、正常性で暗号化された BLOB をデバイスに送信し、デバイスの正常性状態を伝えます。

MDM ソリューションは通常、構成ポリシーを適用し、デバイスにソフトウェアを展開します。 MDM はセキュリティ ベースラインを定義し、デバイスのコンプライアンスレベルを定期的にチェックして、インストールされているソフトウェアと適用される構成を確認し、デバイスの正常性状態を判断します。

MDM ソリューションは、デバイスの正常性情報を送信し、正常性で暗号化された BLOB をリモート正常性構成証明サービスに転送するようにデバイスに求めます。 リモート正常性構成証明サービスは、デバイスの正常性データを検証し、MDM が同じデバイスと通信していることを確認してから、デバイス正常性レポートを MDM ソリューションに発行します。

MDM ソリューションは正常性アサーションを評価し、組織に属する正常性規則に応じて、デバイスが正常かどうかを判断できます。 デバイスが正常で準拠している場合、MDM はその情報を ID プロバイダーに渡して、組織のアクセス制御ポリシーを呼び出してアクセスを許可できるようにします。

その後、コンテンツへのアクセスは、正常性状態やその他の条件付き要素が示す内容に対して、適切なレベルの信頼に対して承認されます。

管理資産の要件と機密性に応じて、アクセス要求を処理するときに、デバイスの正常性状態をユーザー ID 情報と組み合わせることができます。 コンテンツへのアクセスは、適切なレベルの信頼に対して承認されます。 条件付きアクセス エンジンは、マネージド資産の機密性によって必要に応じてより多くの検証を可能にするように構成される場合があります。 たとえば、価値の高いデータへのアクセスが要求された場合は、アクセスが許可される前にユーザーに電話に応答するようにクエリを実行することで、さらにセキュリティ認証を確立する必要がある場合があります。

Windows に対する Microsoft のセキュリティ投資

Windows では、次の 3 つの投資の柱があります。

  • セキュリティで保護された ID。 Microsoft は、ローカル システムとオンプレミス リソースやクラウド リソースなどのサービスの両方で、認証にパスワードを使用しないようにすることで、相互運用可能なセキュリティで保護された認証方法を提供することを目的とする FIDO アライアンスの一部です。
  • 情報の保護。 Microsoft は、組織が重要なデータにアクセスできるユーザーとそのデータで何ができるかをより適切に制御できるようにするための投資を行っています。 Windows では、企業アプリケーションと見なされ、セキュリティで保護されたデータにアクセスするために信頼できるアプリケーションを指定するポリシーを利用できます。
  • 脅威の耐性。 Microsoft は、ハードウェアに依存するセキュリティ防御を使用して、マルウェアや攻撃の脅威に対するエンタープライズ資産のセキュリティを強化するために組織を支援しています。

Windows ベースのデバイスのセキュリティ状態を保護、制御、およびレポートする

このセクションでは、価値の高い資産と情報を攻撃者やマルウェアから保護するのに役立つエンドツーエンドのセキュリティ ソリューションのさまざまな部分について説明する概要です。

図 3。

Number ソリューションの一部 説明
1 Windows ベースのデバイス Windows ベースのデバイスの電源が初めてオンの場合は、すぐに使えるエクスペリエンス (OOBE) 画面が表示されます。 セットアップ中に、デバイスを Microsoft Entra ID に自動的に登録し、MDM に登録できます。
TPM を備えた Windows ベースのデバイスは、サポートされているすべてのエディションの Windows で利用可能な正常性構成証明サービスを使用して、いつでも正常性状態を報告できます。
2 ID プロバイダー Microsoft Entra ID には、ユーザー、登録済みデバイス、および組織のテナントの登録済みアプリケーションが含まれています。 デバイスは常に 1 人のユーザーに属しており、ユーザーは複数のデバイスを持つことができます。 デバイスは、デバイスのコンプライアンス状態などの異なる属性を持つオブジェクトとして表されます。 信頼された MDM は、コンプライアンスの状態を更新できます。
Microsoft Entra ID はリポジトリ以上です。 Microsoft Entra ID は、ユーザーとデバイスを認証でき、マネージド リソースへのアクセスを承認することもできます。 Microsoft Entra ID には、ユーザーの ID、デバイスの場所、および信頼されたアクセスの決定時のデバイスのコンプライアンス状態を使用する条件付きアクセス制御エンジンがあります。
3 モバイル デバイス管理 Windows には MDM のサポートがあり、エージェントを展開せずにデバイスをすぐに管理できます。
MDM には、Microsoft Intune、または Windows と互換性のある任意のサード パーティの MDM ソリューションを指定できます。
4 リモート正常性構成証明 正常性構成証明サービスは、一連の正常性チェックを実行し、デバイスで有効になっている Windows セキュリティ機能を MDM に報告する、Microsoft が運営する信頼できるクラウド サービスです。
セキュリティ検証には、ブート状態 (WinPE、セーフ モード、デバッグ/テスト モード) と、ランタイム操作 (BitLocker、Device Guard) のセキュリティと整合性を管理するコンポーネントが含まれます。
5 エンタープライズ管理資産 エンタープライズ管理資産は、保護するリソースです。
たとえば、資産には、Office 365、他のクラウド アプリ、Microsoft Entra ID によって発行されたオンプレミスの Web リソース、さらには VPN アクセスなどがあります。

Windows ベースのデバイス、ID プロバイダー、MDM、およびリモート正常性構成証明の組み合わせにより、価値の高い資産にアクセスするデバイスの正常性とコンプライアンスの検証を提供する堅牢なエンドツーエンド ソリューションが作成されます。

脅威からデバイスとエンタープライズ資格情報を保護する

このセクションでは、セキュリティ防御の観点から Windows が提供する内容と、測定および報告できる制御について説明します。

Windows ハードウェア ベースのセキュリティ防御

マルウェアの最も積極的な形態は、彼らが早期にオペレーティングシステムの制御を取り、保護メカニズムやマルウェア対策ソフトウェアが動作するのを防ぐことができるように、できるだけ早くブートプロセスに自分自身を挿入しようとします。 この種の悪意のあるコードは、多くの場合、ルートキットまたはブートキットと呼ばれます。 低レベルのマルウェアに対処する必要を回避する最善の方法は、デバイスが最初から保護されるようにブート プロセスをセキュリティで保護することです。 Windows では、複数のブート保護レイヤーがサポートされています。 これらの機能の一部は、特定の種類のハードウェアがインストールされている場合にのみ使用できます。 詳細については、「 ハードウェア要件 」セクションを参照してください。

図 4。

Windows では、スタートアップ プロセス中にルートキットやブートキットなどの高度な低レベルのマルウェアが読み込まれるのを防ぐのに役立つ機能がサポートされています。

  • トラステッド プラットフォーム モジュール。 トラステッド プラットフォーム モジュール (TPM) は、固有のセキュリティ機能を提供するハードウェア コンポーネントです。

    Windows では、TPM のセキュリティ特性を使用して、ブート整合性シーケンスを測定します (また、これに基づいて、自動的に BitLocker で保護されたドライブのロックを解除する)、資格情報を保護したり、正常性構成証明を行ったりします。

    TPM は、トラステッド コンピューティング グループ (TCG) で説明されている仕様を満たすコントロールを実装します。 この執筆時点では、TCG によって生成される TPM 仕様には、相互に互換性のない 2 つのバージョンがあります。

    • 最初の TPM 仕様であるバージョン 1.2 は、TCG によって 2005 年 2 月に公開され、ISO/IEC 11889 標準で標準化されました。
    • TPM 2.0 と呼ばれる最新の TPM 仕様は、2014 年 4 月にリリースされ、ISO/IEC ジョイント技術委員会 (JTC) によって ISO/IEC 11889:2015 として承認されました。

    Windows では、正常性構成証明の一部として暗号化計算に TPM を使用し、BitLocker、Windows Hello、仮想スマート カード、およびその他の公開キー証明書のキーを保護します。 詳細については、「 Windows での TPM 要件」を参照してください。

    Windows では、TCG によって生成されたバージョン 1.2 および 2.0 TPM 仕様が認識されます。 最新および最新のセキュリティ機能については、Windows では TPM 2.0 のみがサポートされています。

    TPM 2.0 では、TPM 1.2 を介した機能のメジャー リビジョンが提供されます。

    • 最新のセキュリティ ニーズを満たすために暗号強度を更新する

      • PCR の SHA-256 のサポート
      • HMAC コマンドのサポート

    • 政府のニーズをサポートする暗号化アルゴリズムの柔軟性

      • TPM 1.2 は、サポートできるアルゴリズムの点で厳しく制限されています
      • TPM 2.0 では、TCG 仕様ドキュメントをマイナー更新して任意のアルゴリズムをサポートできます

    • 実装間の整合性

      • TPM 1.2 仕様では、実装の詳細を選択するときにベンダーの広い緯度を使用できます
      • TPM 2.0 では、この動作の大部分が標準化されています

  • セキュア ブート。 UEFI ファームウェアを持つデバイスは、信頼されたオペレーティング システムのブートローダーのみを読み込むよう構成できます。 セキュア ブートには TPM は必要ありません。

    最も基本的な保護は、UEFI 2.2 以降のアーキテクチャの標準的な部分であるセキュア ブート機能です。 従来の BIOS を搭載した PC では、ブート プロセスを制御できるすべてのユーザーが、代替 OS ローダーを使用して起動でき、システム リソースにアクセスできる可能性があります。 セキュア ブートが有効になっている場合は、UEFI セキュア ブート DB に格納されている証明書を使用して署名された OS ローダーのみを使用して起動できます。 当然ながら、Windows OS ローダーのデジタル署名に使用される Microsoft 証明書はストア内にあります。これにより、UEFI はセキュリティ ポリシーの一部として証明書を検証できます。 セキュリティで保護されたブートは、Windows ハードウェア互換性プログラムの下で Windows の認定を受けているすべてのコンピューターで既定で有効にする必要があります。

    セキュア ブートは UEFI ファームウェア ベースの機能であり、起動時に重要なブート ファイルとドライバーの署名と検証を行うことができます。 セキュア ブートでは、ビルド時に OEM によって定義されたポリシーを使用して、システムが使用可能なオペレーティング システムに完全に起動できるようになる前に、ブート時に Windows ブート マネージャー、BCD ストア、Windows OS ローダー ファイル、およびその他のブート クリティカル DLL の署名値がチェックされます。 セキュア ブートでは、Windows プラットフォームに対する多くの種類のブート ベースのルートキット、マルウェア、およびその他のセキュリティ関連の攻撃が防止されます。 セキュア ブートは、ローカル ハード ディスク、USB、PXE、DVD から起動するか、完全な Windows または Windows 回復環境 (RE) にブートするかに関係なく、オペレーティング システムのブート プロセスを保護します。 セキュア ブートは、重要なブート コンポーネントの署名を確認して悪意のあるアクティビティが侵害されなかったことを確認することで、Windows インストールのブート環境を保護します。 セキュア ブート保護は、Windows カーネル ファイル (ntoskrnl.exe) が読み込まれた後に終了します。

    注

    セキュア ブートは、Windows カーネルが読み込まれるまでプラットフォームを保護します。 その後、ELAM のような保護が引き継がれる。

  • セキュア ブート構成ポリシー。 セキュア ブート機能を重要な Windows 構成に拡張します。

    保護された構成情報の例としては、Disable Execute bit (NX オプション) の保護や、テスト署名ポリシー (コードの整合性) を有効にできないことなどがあります。 この保護アクションにより、ブート プロセスが完了した後にコンピューターのバイナリと構成を信頼できるようになります。 セキュア ブート構成ポリシーは、UEFI ポリシーを使用してこの保護アクションを実行します。 これらのポリシーのこれらの署名は、オペレーティング システム バイナリがセキュア ブートで使用するために署名されるのと同じ方法で署名されます。

    セキュア ブート構成ポリシーは、Key Exchange Key (KEK) リストに格納されている公開キーのいずれかに対応する秘密キーによって署名されている必要があります。 Microsoft 証明機関 (CA) は、すべての Windows 認定セキュア ブート システムの KEK リストに表示されます。 既定では、Microsoft KEK によって署名されたポリシーはすべてのセキュア ブート システムで機能します。 BootMgr は、署名済みポリシーを適用する前に、KEK リストに対して署名を確認する必要があります。 Windows では、既定のセキュア ブート構成ポリシーが bootmgr に埋め込まれています。

    ブートローダーは、Windows カーネルのデジタル署名を読み込む前に検証します。 Windows カーネルは、ブート ドライバー、スタートアップ ファイル、ELAM コンポーネントなど、Windows スタートアップ プロセスの他のすべてのコンポーネントを検証します。 この手順は重要であり、すべての Windows ブート コンポーネントが整合性を持ち、信頼できることを確認することで、ブート プロセスの残りの部分を保護します。

  • 起動時マルウェア対策 (ELAM)。 ELAM では、すべてのドライバーを読み込む前にテストし、承認されていないドライバーが読み込まれないようにします。

    従来のマルウェア対策アプリは、ブート ドライバーが読み込まれるまで開始されません。これにより、ドライバーを装ったルートキットが動作する機会が得られます。 ELAM は、以前のバージョンの Windows で導入された Windows メカニズムであり、マルウェア対策ソフトウェアを起動シーケンスの早い段階で実行できます。 したがって、マルウェア対策コンポーネントは、Windows オペレーティング システムが動作するまで、他のブート ドライバーの初期化を実行および制御する最初のサードパーティ コンポーネントです。 システムが完全なランタイム環境 (ネットワーク アクセス、ストレージなど) で起動されると、フル機能のマルウェア対策が読み込まれます。

    ELAM は、Microsoft 以外のすべてのブート ドライバーとアプリケーションの前に Microsoft または Microsoft 以外のマルウェア対策ドライバーを読み込むことができます。そのため、セキュア ブートとトラステッド ブートによって確立された信頼チェーンが継続されます。 オペレーティング システムがまだ起動しておらず、Windows をできるだけ早く起動する必要があるため、ELAM には単純なタスクがあります。すべてのブート ドライバーを調べて、信頼できるドライバーの一覧にあるかどうかを判断します。 信頼されていない場合、Windows は読み込まれません。

    注

    Windows Defender は、Windows に既定で含まれる Microsoft のマルウェア対策であり、ELAM をサポートしています。これは、サードパーティのマルウェア対策互換ソリューションに置き換えることができます。 Windows Defender ELAM ドライバーの名前が WdBoot.sys。 Windows Defender は ELAM ドライバーを使用して、次回の再起動時に Windows Defender ドライバーに加えられた悪意のある変更をロールバックします。 これにより、カーネル モードのマルウェアが、シャットダウンまたは再起動前に Windows Defender のミニ フィルター ドライバーに永続的な変更を加えるのを防ぎます。

    ELAM 署名されたドライバーは、他のサード パーティ製のドライバーまたはアプリケーションの前に読み込まれます。これにより、マルウェア対策ソフトウェアは、署名されていないコードまたは信頼されていないコードを読み込もうとすることで、ブート プロセスを改ざんしようとする試みを検出してブロックできます。

    ELAM ドライバーは、狭いスコープを持つ小さなポリシー データベースを持つ小さなドライバーで、システムの起動時に早い段階で読み込まれるドライバーに焦点を当てています。 ポリシー データベースは、ELAM ドライバーの操作パラメーターを記録するために、TPM にも測定されるレジストリ ハイブに格納されます。 ELAM ドライバーは Microsoft によって署名されている必要があり、関連付けられている証明書には補完的な EKU (1.3.6.1.4.1.311.61.4.1) が含まれている必要があります。

  • 仮想化ベースのセキュリティ (Hyper-V + Secure Kernel)。 仮想化ベースのセキュリティは、Windows の重要な部分を保護するための新しいセキュリティ境界です。

    仮想化ベースのセキュリティにより、カーネル モード コードの整合性や機密性の高い企業ドメイン資格情報などの機密性の高いコードが、Windows オペレーティング システムの残りの部分から分離されます。 詳細については、「 仮想化ベースのセキュリティ 」セクションを参照してください。

  • ハイパーバイザーで保護されたコード整合性 (HVCI)。 ハイパーバイザーで保護されたコード整合性は、Device Guard コード整合性ポリシーに準拠するドライバー、実行可能ファイル、DLL のみを実行できるようにする Device Guard の機能です。

    有効にして構成すると、Windows は Hyper-V 仮想化ベースのセキュリティ サービスを開始できます。 HVCI は、ブート プロセスの早い段階または起動後にマルウェアが実行されないようにすることで、マルウェア対策ソリューションなどのシステム コア (カーネル)、特権ドライバー、システム防御を保護するのに役立ちます。

    HVCI では、仮想化ベースのセキュリティを使用してコード整合性を分離します。カーネル メモリが実行可能になる唯一の方法は、コード整合性の検証です。 検証に対するこの依存関係は、カーネル メモリ ページを書き込み可能にすることはできず、実行可能ファイル (W + X) と実行可能コードを直接変更できないことを意味します。

    注

    仮想化ベースのセキュリティでカーネル モード コード整合性を実行する Device Guard デバイスには、互換性のあるドライバーが必要です。 詳細については、Windows の Device Guard とのドライバーの互換性に 関するブログ記事を参照してください。

    Device Guard Code Integrity 機能を使用すると、組織は、Windows カーネルで実行するために信頼されるコードと、ユーザー モードでの実行が承認されるアプリケーションを制御できます。 ポリシーを使用して構成できます。 Device Guard Code Integrity ポリシーは、Microsoft が署名することを推奨するバイナリ ファイルです。 コード整合性ポリシーの署名は、現在のコード整合性ポリシーを変更または削除しようとする管理者特権を持つ悪意のあるユーザーに対する保護に役立ちます。

  • Credential Guard。 Credential Guard は、ハードウェア ベースの資格情報の分離を使用して企業の資格情報を保護します。

    Windows では、Credential Guard は、ドメイン企業の資格情報をマルウェアによる盗難や再利用から保護することを目的としています。 Credential Guard では、現在の形式の pass-the-hash (PtH) 攻撃を根本的に防ぐアーキテクチャの変更が実装されました。

    この攻撃のない状態は、Hyper-V と新しい仮想化ベースのセキュリティ機能を使用して、信頼されたコードとシークレットが Windows カーネルから分離される保護されたコンテナーを作成することで実現されます。 この達成は、Windows カーネルが侵害された場合でも、攻撃者が PtH 攻撃を開始するために必要なデータを読み取って抽出する方法がないことを意味します。 Credential Guard では、シークレットが格納されているメモリは、カーネル モードであっても通常の OS からアクセスできなくなり、ハイパーバイザーはメモリにアクセスできるユーザーを制御するため、この未承認のアクセスを防止します。

  • 正常性構成証明。 デバイスのファームウェアはブート プロセスをログに記録し、Windows はデバイスの正常性を確認して評価できる信頼されたサーバーに送信できます。

    Windows は UEFI ファームウェアの測定値を受け取り、ブート プロセス中に読み込まれると、Windows およびマルウェア対策の各コンポーネントが行われます。 さらに、一度にすべてではなく、順番に取得および測定されます。 これらの測定値が完了すると、それらの値はデジタル署名され、TPM に安全に格納され、システムがリセットされない限り変更できません。

    詳細については、「 セキュア ブートと測定ブート: マルウェアに対する初期ブート コンポーネントの強化」を参照してください。

    以降の各ブート時に、同じコンポーネントが測定されるため、予想されるベースラインとの測定値の比較が可能になります。 セキュリティを強化するために、TPM によって測定された値を署名してリモート サーバーに送信し、比較を実行できます。 このプロセスは、 リモート デバイス正常性構成証明と呼ばれ、サーバーが Windows デバイスの正常性状態を確認できるようにします。

    セキュア ブートはプロアクティブな保護形式ですが、正常性構成証明はブート保護の反応性の形式です。 正常性構成証明は Windows で無効になっており、マルウェア対策または MDM ベンダーによって有効になっています。 セキュア ブートとは異なり、正常性構成証明はブート プロセスを停止せず、測定が機能しない場合は修復を開始します。 ただし、条件付きアクセス制御では、正常性構成証明は価値の高い資産へのアクセスを防ぐのに役立ちます。

仮想化ベースのセキュリティ

仮想化ベースのセキュリティは、Windows の新しい信頼境界を提供し、Hyper-V ハイパーバイザー テクノロジを使用してプラットフォームのセキュリティを強化します。 仮想化ベースのセキュリティは、特定の Windows 信頼されたコード (trustlet) を実行し、機密データを保護するためのセキュリティで保護された実行環境を提供します。

仮想化ベースのセキュリティは、侵害されたカーネルや管理者特権を持つ悪意のあるユーザーから保護するのに役立ちます。 仮想化ベースのセキュリティは、物理的な攻撃者から保護しようとしていません。

次の Windows サービスは、仮想化ベースのセキュリティで保護されています。

  • Credential Guard (LSA 資格情報の分離): lsass メモリの内容を読み取ってダンプすることによって発生する、パス ザ ハッシュ攻撃とエンタープライズ資格情報の盗難を防ぎます
  • Device Guard (Hyper-V Code Integrity): Device Guard は、Windows の新しい仮想化ベースのセキュリティを使用して、コード整合性サービスを Windows カーネル自体から分離します。これにより、サービスはエンタープライズ制御ポリシーによって定義された署名を使用して、信頼できるものを判断できます。 実際には、コード整合性サービスは、Windows ハイパーバイザーで保護されたコンテナー内のカーネルと共に実行されます。
  • その他の分離されたサービス: たとえば、Windows Server 2016 では、サーバー上に仮想マシン (VM) を暗号化できる vTPM 機能があります。

注

仮想化ベースのセキュリティは、Enterprise エディションでのみ使用できます。 仮想化ベースのセキュリティでは、セキュア ブートが有効な UEFI (2.3.1 以上) のデバイス、仮想化拡張機能と SLAT が有効な x64 プロセッサが必要です。 IOMMU、TPM 2.0。 セキュリティで保護されたメモリの上書きのサポートは省略可能ですが、推奨されます。

次のスキーマは、仮想化ベースのセキュリティを備えた Windows の概要を示しています。

図 5。

Credential Guard

Windows では、Credential Guard が有効になっている場合、ローカル セキュリティ機関サブシステム サービス (lsass.exe) は分離ユーザー モードで機密コードを実行し、通常のユーザー モードで実行されている可能性のあるマルウェアからデータを保護します。 このコード実行は、保護されたデータが盗まれないようにし、リモート マシンで再利用するのに役立ちます。これにより、多くの PtH スタイルの攻撃が軽減されます。

Credential Guard は、ブートごとのキーまたは永続的なキーを使用して資格情報を暗号化することで、資格情報を保護するのに役立ちます。

  • ブートごとのキー は、永続化を必要としないメモリ内の資格情報に使用されます。 このような資格情報の例としては、チケット許可チケット (TGT) セッション キーがあります。 このキーは、認証が行われるたびにキー配布センター (KDC) とネゴシエートされ、ブートごとのキーで保護されます。
  • 永続的なキー (一部の派生キー) は、再起動後に保存および再読み込みされる項目を保護するために使用されます。 このような保護は、長期的なストレージを対象としており、一貫性のあるキーで保護する必要があります。 Credential Guard はレジストリ キーによってアクティブ化され、UEFI 変数を使用して有効になります。 このアクティブ化は、構成のリモート変更から保護するために行われます。 UEFI 変数の使用は、構成を変更するために物理アクセスが必要であることを意味します。 lsass.exe は、資格情報の分離が有効になっていることを検出すると、分離されたプロセスとして LsaIso.exe を生成します。これにより、分離されたユーザー モードで確実に実行されます。 LsaIso.exe の起動は、セキュリティ サポート プロバイダーの初期化の前に実行されます。これにより、認証が開始される前にセキュリティ モードのサポート ルーチンの準備が整います。

Device Guard

Device Guard は、信頼されていないソフトウェアの実行からデバイスを保護するために、組織がデバイスをロックダウンできるようにする Windows Enterprise の機能です。 この構成では、実行できるアプリケーションは、組織によって信頼されているアプリケーションだけです。

コードを実行するための信頼の決定は、通常の Windows と共に実行される Hyper-V で保護されたコンテナーである仮想化ベースのセキュリティで実行される Hyper-V コード整合性を使用して実行されます。

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

注

Device Guard Policy のアクティブ化とは別に、Windows ドライバーは Microsoft によって署名され、具体的には WHQL (Windows ハードウェア品質ラボ) ポータルによって署名されている必要があります。 さらに、2015 年 10 月以降、WHQL ポータルは、有効な拡張検証 ("EV") コード署名証明書を持つカーネル モード ドライバーとユーザー モード ドライバーの申請の両方を含むドライバーの申請のみを受け入れます。

Device Guard を使用すると、組織は Windows Enterprise を実行する x64 システムで使用する独自のコード整合性ポリシーを定義できるようになりました。 組織には、実行する信頼できる内容を決定するポリシーを構成する機能があります。 これには、ドライバーとシステム ファイル、従来のデスクトップ アプリケーションとスクリプトが含まれます。 その後、システムはロックダウンされ、組織が信頼するアプリケーションのみを実行します。

Device Guard は、不要なコードとアプリケーションの実行を防ぐ Windows Enterprise の組み込み機能です。 Device Guard は、許可と拒否の 2 つのルール アクションを使用して構成できます。

  • 許可: アプリケーションの実行を、コードまたは信頼された発行元の許可されたリストに制限し、他のすべてをブロックします。
  • [拒否] は、特定のアプリケーションの実行をブロックすることで、信頼できる発行元を許可する方法を完了します。

この執筆時点で、Microsoft の最新の調査によると、マルウェアの 90% 以上が完全に署名されていません。 そのため、基本的な Device Guard ポリシーを実装すると、マルウェアを簡単かつ効果的にブロックできます。 実際、Device Guard にはさらに進む可能性があり、署名されたマルウェアをブロックするのにも役立ちます。

Device Guard は、本当に効果的に計画し、構成する必要があります。 これは、有効または無効になっている保護だけではありません。 Device Guard は、ハードウェア セキュリティ機能とソフトウェア セキュリティ機能の組み合わせで、一緒に構成すると、コンピューターをロックダウンして、可能な限り最も安全で耐性のあるシステムを確保できます。

Windows の Device Guard ソリューションを構成する 3 つの異なる部分があります。

  • 最初の部分は、以前のバージョンの Windows で導入された ハードウェア セキュリティ機能 の基本セットです。 ハードウェア暗号化操作用の TPM と最新のファームウェアを使用した UEFI とセキュア ブートを使用すると、システムの起動時に実行されているデバイスを制御できます。
  • ハードウェア セキュリティ機能の後に、コード整合性エンジンがあります。 Windows では、 コードの整合性が完全に構成可能 になり、仮想化ベースのセキュリティによって保護されるメモリの一部である分離ユーザー モードになります。
  • Device Guard の最後の部分は 、管理容易性です。 コード整合性の構成は、特定のグループ ポリシー オブジェクト、PowerShell コマンドレット、MDM 構成サービス プロバイダー (CSP) を介して公開されます。

企業で Device Guard を展開する方法の詳細については、 Device Guard 展開ガイドを参照してください。

Device Guard のシナリオ

前に説明したように、Device Guard はシステムをロックダウンする強力な方法です。 Device Guard は広く使用されるものではなく、常に適用可能であるとは限りませんが、関心の高いシナリオがいくつかあります。

Device Guard は、キャッシュ レジスタ、キオスク マシン、Secure Admin Workstations (SAW)、適切に管理されたデスクトップなどの固定ワークロード システムで役立ち、適用可能です。 Device Guard は、実行が予想され、頻繁に変更されない、適切に定義されたソフトウェアを持つシステムに非常に関連性があります。 また、実行する必要がある内容がわかっており、アプリケーションのセットが日常的に変更されない限り、SAW 以外の Information Worker (IW) を保護するのにも役立ちます。

SAW は、他のセキュリティ リスクの中でも、マルウェア、フィッシング攻撃、偽の Web サイト、PtH 攻撃による侵害のリスクを大幅に軽減するために構築されたコンピューターです。 SAW は、これらの攻撃に対する "銀の箇条書き" セキュリティ ソリューションとは見なすことはできませんが、これらの種類のクライアントは、セキュリティに対する多層的な多層防御アプローチの一部として役立ちます。

価値の高い資産を保護するために、SAW を使用してそれらの資産への安全な接続を行います。

同様に、Microsoft Configuration Manager、Intune、またはサード パーティ製デバイス管理などの配布ツールを使用してアプリケーションがインストールされている企業のフル マネージド ワークステーションでは、Device Guard が適用されます。 この種のシナリオでは、組織は、平均的なユーザーが実行しているソフトウェアを適切に把握しています。

通常、ユーザーが自分でソフトウェアをインストールすることが許可されている、会社の軽量で管理されたワークステーションで Device Guard を使用するのは困難な場合があります。 組織が優れた柔軟性を提供する場合、Device Guard を強制モードで実行するのは困難です。 ただし、Device Guard は監査モードで実行できます。その場合、イベント ログには Device Guard ポリシーに違反したすべてのバイナリのレコードが含まれます。 Device Guard を監査モードで使用すると、組織は、ユーザーがインストールして実行するドライバーとアプリケーションに関する豊富なデータを取得できます。

Device Guard に含まれる保護を利用するには、Microsoft が提供するツールを使用してコード整合性ポリシーを作成する必要がありますが、ポリシーはグループ ポリシーなどの一般的な管理ツールを使用して展開できます。 コード整合性ポリシーは、Windows のユーザー モードとカーネル モードの両方の構成設定と、Windows スクリプト ホストの制限を含むバイナリエンコード XML ドキュメントです。 Device Guard Code Integrity ポリシーは、デバイスで実行できるコードを制限します。

注

Device Guard ポリシーは Windows にサインインできます。これにより、このポリシーを変更または削除する管理者ユーザーに対する保護が追加されます。

署名済み Device Guard ポリシーは、Device Guard を倒そうとしている悪意のあるローカル管理者に対して、より強力な保護を提供します。

ポリシーが署名されると、ポリシーの GUID は、改ざん防止を提供する UEFI プレ OS のセキュリティで保護された変数に格納されます。 Device Guard ポリシーを後で更新する唯一の方法は、同じ署名者または Device Guard ポリシーの一部として指定された署名者から UpdateSigner セクションに署名された新しいバージョンのポリシーを提供することです。

アプリケーションに署名することの重要性

Device Guard を使用するコンピューターでは、署名されていないアプリを制限なく実行できる世界から、署名済みの信頼されたコードのみを Windows で実行できる世界に移行することを提案しています。

Windows を使用すると、組織は Microsoft Store インフラストラクチャを通じて組織のメンバーが基幹業務 (LOB) アプリを利用できるようにします。 具体的には、LOB アプリは、パブリック Microsoft ストア内のプライベート ストアで使用できます。 Microsoft Store は、ユニバーサル Windows アプリとクラシック Windows アプリに署名して配布します。 Microsoft Store からダウンロードされたすべてのアプリが署名されます。

現在の組織では、多くの LOB アプリケーションが署名されていません。 コード署名は、コード署名の専門知識の欠如など、さまざまな理由で解決するための困難な問題とよく見なされます。 コード署名がベスト プラクティスである場合でも、多くの内部アプリケーションは署名されません。

Windows には、IT 担当者が既にパッケージ化されているアプリケーションを取得し、プロセスを通じて実行して、既存のアプリケーションと共に配布できるより多くの署名を作成できるツールが含まれています。

マルウェア対策とデバイス管理ソリューションが引き続き必要な理由

許可リスト メカニズムは、信頼されたアプリケーションのみを確実に実行する際に効率的ですが、既知の脆弱性を悪用するように設計された悪意のあるコンテンツによる信頼された (脆弱な) アプリケーションの侵害を防ぐことはできません。 Device Guard は、脆弱性を悪用して実行されるユーザー モードの悪意のあるコードから保護しません。

脆弱性はソフトウェアの弱点であり、攻撃者がデバイスの整合性、可用性、または機密性を侵害する可能性があります。 最悪の脆弱性の一部では、攻撃者がユーザーの知らないうちに悪意のあるコードを実行させることで、侵害されたデバイスを悪用することができます。

Web ブラウザー (およびそのプラグイン)、Java 仮想マシン、PDF リーダー、ドキュメント エディターなどのユーザー モード ソフトウェアで既知の脆弱性を悪用しようとして、攻撃者が特別に細工されたコンテンツを配布しているのが一般的です。 現在、検出された脆弱性の 90% は、オペレーティング システムとカーネル モード ドライバーをホストするドライバーと比較して、ユーザー モード アプリケーションに影響します。

これらの脅威に対処するために、パッチ適用は最も効果的な唯一の制御であり、マルウェア対策ソフトウェアは補完的な防御層を形成します。

ほとんどのアプリケーション ソフトウェアには、それ自体を更新するための機能がないため、ソフトウェア ベンダーが脆弱性を修正する更新プログラムを公開した場合でも、ユーザーは更新プログラムが利用可能であるか、取得方法がわからない可能性があるため、攻撃に対して脆弱なままです。 組織は引き続きデバイスを管理し、脆弱性にパッチを適用する必要があります。

MDM ソリューションは、軽量デバイス管理テクノロジとして普及しています。 Windows では、MDM で使用できるようになった管理機能が拡張されます。 Microsoft が Windows に追加した主な機能の 1 つは、MDM が管理対象デバイスと登録済みデバイスからデバイスの正常性に関する強力なステートメントを取得できることです。

デバイス正常性構成証明

デバイス正常性構成証明は、TPM を使用して、デバイスの起動に使用されるソフトウェアチェーンの暗号的に強力で検証可能な測定値を提供します。

Windows ベースのデバイスでは、MDM ソフトウェアが Windows Health 構成証明サービスと呼ばれるリモート構成証明サービスにアクセスできるようにする新しいパブリック API が導入されています。 正常性構成証明の結果は、他の要素と共に使用して、デバイスが正常であると証明されたかどうかに基づいて、ネットワーク、アプリ、またはサービスへのアクセスを許可または拒否できます。

デバイスの正常性構成証明の詳細については、「異常 な Windows ベースのデバイスを検出する 」セクションを参照してください。

Windows エディションとライセンスに関する要件

次の表は、デバイス正常性構成証明サービスをサポートする Windows エディションの一覧です。

Windows Pro Windows Enterprise Windows Pro Education/SE Windows Education
はい はい ○ ○

デバイス正常性構成証明サービスライセンスの権利は、次のライセンスによって付与されます。

Windows Pro/Pro Education/SE Windows Enterprise E3 Windows Enterprise E5 Windows Education A3 Windows Education A5
はい はい はい ○ ○

Windows ライセンスの詳細については、「Windows ライセンスの概要」を参照してください。

ハードウェアの要件

次の表では、仮想化ベースのセキュリティ サービスと正常性構成証明機能の両方のハードウェア要件について詳しくは、次の表をご覧ください。 詳細については、「 ハードウェアの最小要件」を参照してください。

ハードウェア モチベーション
セキュア ブートが有効になっている UEFI 2.3.1 以降のファームウェア UEFI セキュア ブートをサポートするために必要です。 UEFI セキュア ブートでは、デバイスが承認されたコードのみを起動します。 さらに、「System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby」というサブセクションの「Windows 用システムのハードウェア互換性仕様」の要件に従って、ブート整合性 (プラットフォーム セキュア ブート) をサポートする必要があります。
Intel VT-x、AMD-V、SLAT などの仮想化拡張機能を有効にする必要があります 仮想化ベースのセキュリティをサポートするために必要です。 手記： Device Guard は、仮想化ベースのセキュリティを使用せずに有効にすることができます。
X64 プロセッサ Windows ハイパーバイザーを使用する仮想化ベースのセキュリティをサポートするために必要です。 Hyper-V は x64 プロセッサでのみサポートされます (x86 ではサポートされません)。 ダイレクト メモリ アクセス (DMA) 保護を有効にすると、追加のメモリ保護を提供できますが、DMA 保護テクノロジを含めるプロセッサが必要です。
INTEL VT-d などの IOMMU AMD-Vi Windows での IOMMU のサポートにより、DMA 攻撃に対するシステムの回復性が強化されます。
トラステッド プラットフォーム モジュール (TPM) 正常性構成証明をサポートするために必要であり、仮想化ベースのセキュリティの他のキー保護に必要です。 TPM 2.0 がサポートされています。 Windows 10 バージョン 1607 (RS1) 以降に TPM 1.2 のサポートが追加されました

このセクションでは、Windows のいくつかの密接に関連するコントロールに関する情報を示しました。 多層防御と詳細なアプローチは、ブート シーケンス中に低レベルのマルウェアを根絶するのに役立ちます。 仮想化ベースのセキュリティは、新しいセキュリティ境界を追加する基本的なオペレーティング システム アーキテクチャの変更です。 Device Guard と Credential Guard はそれぞれ、信頼されていないコードをブロックし、企業ドメインの資格情報を盗難や再利用から保護するのに役立ちます。 このセクションでは、デバイスの管理と脆弱性の修正プログラムの適用の重要性についても簡単に説明します。 これらのテクノロジはすべて、攻撃者がデバイスを侵害するリスクを制限しながら、デバイスを強化およびロックダウンするために使用できます。

異常な Windows ベースのデバイスを検出する

現在、多くの組織では、オペレーティング システムが正しい状態で適切に構成され、セキュリティ保護が有効になっているなど、さまざまなチェックに合格した後、デバイスが会社のポリシーに準拠していると見なすだけです。 残念ながら、今日のシステムでは、マルウェアがシステムの正常性に関するソフトウェア ステートメントを偽装する可能性があるため、この形式のレポートは完全に信頼できません。 ルートキットまたは同様の低レベルの悪用は、従来のコンプライアンス ツールに誤った正常な状態を報告できます。

ルートキットの最大の課題は、クライアントが検出できない可能性があることです。 マルウェア対策の前に起動し、システム レベルの特権を持っているため、システム リソースへのアクセスを続けながら完全に偽装できます。 その結果、ルートキットに感染した従来のコンピュータは、マルウェア対策が実行されていても正常であるように見えます。

前に説明したように、Windows の正常性構成証明機能では、TPM ハードウェア コンポーネントを使用して、ファームウェア、Windows カーネル、さらには初期ブート ドライバーなど、すべてのブート関連コンポーネントの測定値を安全に記録します。 正常性構成証明は TPM のハードウェア ベースのセキュリティ機能を使用するため、すべてのブート測定コンポーネントのログはマルウェアの手の届かないところに残ります。

デバイスが信頼されたブート状態を証明した後、後でコンプライアンス チェックを偽装する可能性がある低レベルのマルウェアが実行されていないことを証明できます。 TPM ベースの正常性構成証明は、価値の高いデータを含む資産に信頼できるアンカーを提供します。

デバイスの正常性の概念は何ですか?

デバイスの正常性の概念を理解するには、マルウェアの侵害を防ぐために IT 担当者が講じてきた従来の対策を理解することが重要です。 マルウェア制御技術は、インストールと配布の防止に重点を置いている。

ただし、マルウェア対策や修正プログラムの適用ソリューションなどの従来のマルウェア防止テクノロジを使用すると、IT 担当者にとって新しい一連の問題が発生します。組織のリソースにアクセスするデバイスのコンプライアンスを監視および制御する機能です。

デバイスコンプライアンスの定義は、組織がインストールしたマルウェア対策、デバイス構成設定、パッチ管理ベースライン、およびその他のセキュリティ要件によって異なります。 ただし、デバイスの正常性は、デバイス コンプライアンス ポリシー全体の一部です。

デバイスの正常性はバイナリではなく、組織のセキュリティ実装に依存します。 正常性構成証明サービスは、信頼できるハードウェア TPM を使用して、デバイスの起動時にセキュリティ機能が有効になっている MDM に情報を返します。

ただし、正常性構成証明は情報のみを提供するため、MDM ソリューションで決定を行い、適用する必要があります。

リモート デバイス正常性構成証明

Windows では、正常性構成証明とは、ブート プロセス中に生成された測定ブート データが、Microsoft が運用するリモート デバイス正常性構成証明サービスに送信される機能を指します。

この方法は、Windows ベースのデバイスがセキュリティ防御がダウンしたタイミングを検出するために使用できる最も安全な方法です。 ブート プロセス中に、TCG ログと PCR の値がリモートの Microsoft クラウド サービスに送信されます。 その後、正常性構成証明サービスによってログがチェックされ、デバイスで発生した変更が確認されます。

MDM などの証明書利用者は、リモート正常性構成証明サービスによって生成されたレポートを検査できます。

注

Windows の正常性構成証明機能を使用するには、デバイスに個別の TPM またはファームウェア TPM が装備されている必要があります。 Windows の特定のエディションに制限はありません。

Windows では、アプリケーションが正常性構成証明トークンを要求できるように、基になる正常性構成証明構成サービス プロバイダー (CSP) へのアクセスをアプリケーションに許可することで、正常性構成証明シナリオがサポートされています。 ブート シーケンスの測定は、マルウェア対策エージェントまたは MDM エージェントによってローカルでいつでも確認できます。

MDM と組み合わせたリモート デバイス正常性構成証明は、システム上で実行されているソフトウェアを信頼することなく、現在のセキュリティ状態を報告し、変更を検出するためのハードウェアルート方式を提供します。

デバイスで悪意のあるコードが実行されている場合は、リモート サーバーの使用が必要です。 ルートキットがデバイスに存在する場合、マルウェア対策は信頼できなくなり、起動シーケンスの早い段階で実行されている悪意のあるコードによってその動作が乗っ取られる可能性があります。 このため、セキュア ブートと Device Guard を使用して、ブート シーケンス中に読み込まれるコードを制御することが重要になります。

マルウェア対策ソフトウェアは、ブート シーケンスにルートキットなどのマルウェアの兆候が含まれているかどうかを調べるために検索できます。 また、TCG ログと PCR をリモート正常性構成証明サーバーに送信して、測定コンポーネントと検証コンポーネントの間の分離を提供することもできます。

正常性構成証明は、ブート プロセス中のさまざまな TPM プラットフォーム構成レジスタ (PCR) と TCG ログの測定値をログに記録します。

図 6.

TPM を搭載したデバイスを起動すると、さまざまなコンポーネントの測定が実行されます。 これらのコンポーネントには、ファームウェア、UEFI ドライバー、CPU マイクロコード、および種類がブート スタートのすべての Windows ドライバーが含まれます。 未加工の測定値は TPM PCR レジスタに格納され、すべてのイベント (実行可能パス、機関認定など) の詳細は TCG ログで使用できます。

図 7.

正常性構成証明プロセスは、次のように機能します。

  1. ハードウェア ブート コンポーネントが測定されます。
  2. オペレーティング システムのブート コンポーネントが測定されます。
  3. Device Guard が有効になっている場合、現在の Device Guard ポリシーが測定されます。
  4. Windows カーネルが測定されます。
  5. ウイルス対策ソフトウェアは、最初のカーネル モード ドライバーとして起動されます。
  6. ブート開始ドライバーが測定されます。
  7. MDM エージェントを介した MDM サーバーは、正常性構成証明 CSP を使用して正常性チェック コマンドを発行します。
  8. ブート測定値は、正常性構成証明サービスによって検証されます

注

既定では、最新の 100 個のシステム ブート ログと関連するすべての再開ログは、%SystemRoot%\logs\measuredboot フォルダーにアーカイブされます。 保持されるログの数は、HKLM\SYSTEM\CurrentControlSet\Services\TPM キーの下のレジストリ REG_DWORD値 PlatformLogRetention で設定できます。 値 0 はログアーカイブをオフにし、 0xffffffff の値はすべてのログを保持します。

次のプロセスでは、正常性ブート測定値を正常性構成証明サービスに送信する方法について説明します。

  1. クライアント (TPM を使用した Windows ベースのデバイス) は、リモート デバイス正常性構成証明サービスを使用して要求を開始します。 正常性構成証明サーバーは Microsoft クラウド サービスであると予想されるため、URI はクライアントで既に事前にプロビジョニングされています。

  2. 次に、クライアントは TCG ログ、AIK 署名されたデータ (PCR 値、ブート カウンター) と AIK 証明書情報を送信します。

  3. 次に、リモート デバイスのヒート構成証明サービス:

    1. AIK 証明書が既知の信頼された CA によって発行され、証明書が有効であり、失効していないかどうかを確認します。
    2. PCR クォートのシグネチャが正しく、TCG ログ値と一致していることを確認します。
    3. TCG ログのプロパティを解析します。
    4. 正常性情報、AIK 情報、ブート カウンター情報を含むデバイス正常性トークンを発行します。 正常性トークンには、有効な発行時間も含まれています。 デバイス正常性トークンは暗号化され、署名されています。つまり、情報は保護されており、正常性構成証明サービスの発行にのみアクセスできます。

  4. クライアントは、正常性で暗号化された BLOB をローカル ストアに格納します。 デバイス正常性トークンには、デバイスの正常性状態、デバイス ID (Windows AIK)、ブート カウンターが含まれています。

図 8。

デバイス正常性構成証明コンポーネント

デバイス正常性構成証明ソリューションには、TPM、正常性構成証明 CSP、および Windows 正常性構成証明サービスのさまざまなコンポーネントが含まれます。 これらのコンポーネントについては、このセクションで説明します。

トラステッド プラットフォーム モジュール

このセクションでは、PCR (システム構成データを含む)、保証キー (EK) (TPM の ID カードとして機能する)、SRK (キーを保護する)、AIK (プラットフォームの状態を報告できる) を正常性構成証明レポートに使用する方法について説明します。

簡単に言うと、TPM はリソースが限られたパッシブ コンポーネントです。 乱数、RSA キーの計算、短いデータの暗号化解除、デバイスの起動時に取得されたハッシュの格納を行うことができます。

TPM は 1 つのコンポーネントに組み込まれています。

  • RSA 2048 ビット キー ジェネレーター
  • 乱数ジェネレーター
  • EK、SRK、AIK キーを格納するための不揮発性メモリ
  • 暗号化、暗号化解除、署名を行う暗号化エンジン
  • PCR キーと RSA キーを格納するための揮発性メモリ

保証キー

TPM には、保証キーと呼ばれる一意の暗号化キーが埋め込まれています。 TPM 保証キーは、非対称キーのペア (RSA サイズ 2048 ビット) です。

保証キー公開キーは、所有者パスワードの定義ハッシュを含む TPM を所有する場合など、安全に機密性の高いパラメーターを送信するために使用されます。 EK 秘密キーは、AIK などのセカンダリ キーを作成するときに使用されます。

保証キーは、TPM の ID カードとして機能します。 詳細については、「 TPM 保証キーについて」を参照してください。

保証キーには、多くの場合、1 つまたは 2 つのデジタル証明書が付属しています。

  • 1 つの証明書は TPM 製造元によって生成され、 保証証明書と呼ばれます。 保証証明書は、ローカル プロセス、アプリケーション、またはクラウド サービスに対する TPM の信頼性 (たとえば、特定のチップ メーカーによって製造された実際の TPM) を証明するために使用されます。 保証証明書は、製造中、またはオンライン サービスと通信して TPM が初めて初期化されるときに作成されます。
  • もう 1 つの証明書はプラットフォーム ビルダーによって生成され、プラットフォーム 証明書 と呼ばれ、特定の TPM が特定のデバイスと統合されていることを示します。 Intel または Qualcomm によって生成されたファームウェア ベースの TPM を使用する特定のデバイスでは、WINDOWS の OOBE 中に TPM が初期化されるときに保証証明書が作成されます。

注

セキュア ブートは、Windows カーネルが読み込まれるまでプラットフォームを保護します。 次に、トラステッド ブート、Hyper-V コード整合性、ELAM などの保護が引き継ぎます。 Intel TPM または Qualcomm TPM を使用するデバイスは、チップを作成した製造元からオンラインで署名付き証明書を取得し、署名された証明書を TPM ストレージに格納します。 操作を成功させるには、クライアント デバイスからインターネット アクセスをフィルター処理する場合は、次の URL を承認する必要があります。

  • Intel ファームウェア TPM の場合: https://ekop.intel.com/ekcertservice
  • Qualcomm ファームウェア TPM の場合: https://ekcert.spserv.microsoft.com/

構成証明 ID キー

保証証明書はデバイスごとに一意であり、変更されないため、理論的には特定のデバイスを追跡できるため、使用にプライバシーの問題が発生する可能性があります。 このプライバシーの問題を回避するために、Windows は保証証明書に基づいて派生構成証明アンカーを発行します。 この中間キーは、保証キーに対して証明することができますが、構成証明 ID キー (AIK) であり、対応する証明書は AIK 証明書と呼ばれます。 この AIK 証明書は、Microsoft クラウド サービスによって発行されます。

注

デバイスが TPM 構成証明機能を使用してその正常性を報告するには、まず、AIK 証明書を Microsoft Cloud CA サービスなどのサード パーティのサービスと組み合わせてプロビジョニングする必要があります。 プロビジョニング後、AIK 秘密キーを使用してプラットフォームの構成を報告できます。 Windows では、AIK を使用して、各ブートでプラットフォーム ログの状態 (および単調なカウンター値) に対して署名が作成されます。

AIK は非対称 (公開/秘密) キー ペアであり、プライバシーのために TPM の ID として EK の代わりに使用されます。 AIK のプライベート部分は、TPM の外部で公開または使用されることは決してなく、限られた一連の操作でのみ TPM 内で使用できます。 さらに、署名にのみ使用でき、限られた TPM 定義の操作にのみ使用できます。

Windows では、TPM によって保護された AIK (使用可能な場合) が作成されます。これは 2048 ビット RSA 署名キーです。 Microsoft は、実際の TPM と通信していること、および TPM が提示された AIK を所有していることを暗号化して確立するために、Microsoft Cloud CA というクラウド サービスをホストしています。 Microsoft Cloud CA サービスは、これらの事実を確立した後、Windows ベースのデバイスに AIK 証明書を発行します。

Windows 10 にアップグレードする既存のデバイスの多くは TPM を持っていないか、TPM に保証証明書が含まれません。 これらのデバイスに対応するために、Windows 10 では、保証証明書が存在せずに AIK 証明書を発行できます。 このような AIK 証明書は、Microsoft Cloud CA によって発行されません。 これらの証明書は、製造中にデバイスに書き込まれる保証証明書ほど信頼できませんが、TPM を使用しない Windows Hello for Business などの高度なシナリオとの互換性が提供されます。

発行された AIK 証明書では、構成証明プロセス中に保証証明書が使用されたことを証明するために、特別な OID が追加されます。 証明書利用者は、この情報を使用して、保証証明書なしで AIK 証明書を使用して証明されたデバイスを拒否するか、受け入れるかを決定できます。 もう 1 つのシナリオは、保証証明書によってサポートされていない AIK 証明書によって証明されたデバイスから価値の高い資産へのアクセスを許可しないことです。

ストレージ ルート キー

ストレージ ルート キー (SRK) も非対称キー ペアです (RSA の長さは 2048 ビット以上)。 SRK には主要な役割があり、TPM キーを保護するために使用されるため、これらのキーを TPM なしで使用することはできません。 SRK キーは、TPM の所有権が取得されるときに作成されます。

プラットフォーム構成レジスタ

TPM には、起動したシステムのソフトウェアと状態の暗号化表現を提供するように設計された一連のレジスタが含まれています。 これらのレジスタは、プラットフォーム構成レジスタ (PCR) と呼ばれます。

ブート シーケンスの測定は、PCR と TCG ログに基づいています。 信頼の静的ルートを確立するには、デバイスの起動時に、デバイスが実行前にファームウェア コードを測定できる必要があります。 この場合、測定の信頼のコア ルート (CRTM) がブートから実行され、ファームウェアのハッシュが計算され、レジスタ PCR[0] を展開して格納され、実行がファームウェアに転送されます。

PCR は、プラットフォームの起動時に 0 に設定され、プラットフォームを起動してブート チェーン内のコンポーネントを測定し、PCR で測定値を記録するファームウェアのジョブです。 通常、ブート コンポーネントは、実行する次のコンポーネントのハッシュを受け取り、PCR で測定値を記録します。 測定チェーンを開始する初期コンポーネントは、暗黙的に信頼されます。 このコンポーネントは CRTM です。 プラットフォームの製造元は、CRTM のセキュリティで保護された更新プロセスを行うか、更新を許可しない必要があります。 PCR は、測定されたコンポーネントの累積ハッシュを記録します。

PCR の値自体は解釈が困難ですが (単なるハッシュ値です)、プラットフォームは通常、測定された内容の詳細を含むログを保持し、PCR はログが改ざんされていないことを確認するだけです。 ログは TCG ログと呼ばれます。 レジスタ PCR が拡張されるたびに、エントリが TCG ログに追加されます。 したがって、ブート プロセス全体を通じて、実行可能コードと構成データのトレースが TCG ログに作成されます。

TPM プロビジョニング

Windows ベースのデバイスの TPM を使用できるようにするには、最初にプロビジョニングする必要があります。 プロビジョニングのプロセスは TPM のバージョンによって異なりますが、成功すると TPM が使用可能になり、TPM の所有者承認データ (ownerAuth) がレジストリにローカルに格納されます。

TPM がプロビジョニングされると、Windows はまず、レジストリ内の HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\保証の場所を調べることで、EK 値とローカルに格納されている ownerAuth 値の決定を試みます。

プロビジョニング プロセス中に、デバイスを再起動する必要がある場合があります。

Get-TpmEndorsementKeyInfo PowerShell コマンドレットを管理特権と共に使用して、TPM の保証キーと証明書に関する情報を取得できます。

TPM の所有権が不明でも EK が存在する場合、クライアント ライブラリは TPM をプロビジョニングし、ポリシーで SRK パブリック部分を HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub に格納できる場合、その結果の ownerAuth 値がレジストリに格納されます。

プロビジョニング プロセスの一環として、Windows は TPM を使用して AIK を作成します。 この操作を実行すると、結果の AIK パブリック部分がレジストリに格納されます。 HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

注

AIK 証明書をプロビジョニングし、インターネット アクセスをフィルター処理するには、次のワイルドカード URL を承認する必要があります。 https://\*.microsoftaik.azure.net

Windows Health 構成証明 CSP

Windows には、正常性構成証明機能との対話に特化した構成サービス プロバイダー (CSP) が含まれています。 CSP は、Windows MDM クライアントに接続するコンポーネントであり、MDM サーバーが設定を構成し、Windows ベースのデバイスを管理する方法に関する公開されたプロトコルを提供します。 管理プロトコルは、"get"、"set"、"delete"などの URI で実行する関数を持つ URI として指定できるツリー構造として表されます。

次の一覧は、Windows Health 構成証明 CSP によって実行される関数の一覧です。

  • デバイスの正常性状態を確認するために使用されるデータを収集します
  • 正常性構成証明サービスにデータを転送します
  • 正常性構成証明サービスから受け取る正常性構成証明証明書をプロビジョニングします
  • 要求に応じて、正常性構成証明証明書 (正常性構成証明サービスから受信) と関連するランタイム情報を MDM サーバーに転送して検証します

正常性構成証明セッション中、正常性構成証明 CSP は、セキュリティで保護された通信チャネルを使用して正常性構成証明サービスに、ブート中に測定される TCG ログと PCR の値を転送します。

MDM サーバーは、デバイスが正常性構成証明サービスに対して構成証明を行ったと検証すると、そのデバイスの起動方法に関する一連のステートメントと要求が提供され、デバイスが正常性を証明してから MDM サーバーが検証した時間の間にデバイスが再起動されなかったことが保証されます。

Windows 正常性構成証明サービス

Windows Health 構成証明サービスの役割は、基本的に、一連の正常性データ (TCG ログと PCR 値) を評価し、一連の検出 (使用可能な正常性データに基づく) を作成し、暗号化された正常性 BLOB を生成するか、MDM サーバーにレポートを生成することです。

注

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

TPM 構成証明と関連するログが有効であることを確認するには、いくつかの手順を実行します。

  1. まず、サーバーは、 信頼できる AIK によってレポートが署名されていることを確認する必要があります。 この検証は、AIK のパブリック部分が資産のデータベースに一覧表示されていることを確認するか、証明書がチェックされている可能性があります。
  2. キーがチェックされた後、署名済みの構成証明 (引用符構造) をチェックして、 それが PCR 値に対して有効な署名であるかどうかを確認する必要があります。
  3. 次に、ログをチェックして、報告された PCR 値と一致することを確認する必要があります。
  4. 最後に、既知 のセキュリティ構成または有効なセキュリティ構成を表しているかどうかを確認するために、ログ自体を MDM ソリューションで調べる必要があります。 たとえば、測定された初期 OS コンポーネントが適切かどうか、ELAM ドライバーが期待どおりに動作していること、ELAM ドライバー ポリシー ファイルが最新の状態であることを確認する簡単なチェックが考えられます。 これらのチェックがすべて成功した場合は、構成証明ステートメントを発行できます。このステートメントを後で使用して、クライアントにリソースへのアクセスを許可するかどうかを判断できます。

正常性構成証明サービスは、デバイスの正常性に関する次の情報を MDM ソリューションに提供します。

  • セキュア ブートの有効化
  • ブートとカーネルデバッグの有効化
  • BitLocker の有効化
  • VSM が有効
  • 署名済みまたは署名されていない Device Guard Code Integrity ポリシーの測定
  • ELAM の読み込み
  • セーフ モードブート、DEP 有効化、テスト署名有効化
  • 信頼された保証証明書を使用してデバイス TPM がプロビジョニングされました

測定値の完全性については、「 正常性構成証明 CSP」を参照してください。

次の一覧は、Windows ベースのデバイスの MDM に報告できるいくつかの重要な項目を示しています。

  • PCR0 測定
  • セキュア ブートが有効
  • セキュア ブート DB が予期した値と一致する
  • セキュア ブート dbx が最新の状態である
  • セキュア ブート ポリシー GUID が予期した値と一致する
  • BitLocker が有効
  • 仮想化ベースのセキュリティが有効
  • ELAM が読み込まれました
  • コード整合性バージョンが最新の状態である
  • コード整合性ポリシー ハッシュが予期した値と一致する

MDM と正常性構成証明サービスを使用する

デバイスの正常性を関連させるために、MDM ソリューションはデバイス正常性レポートを評価し、組織のデバイス正常性要件に対して構成します。

MDM と正常性構成証明サービスを使用するソリューションは、次の 3 つの主要な部分で構成されます。

  1. 正常性構成証明が有効になっているデバイス。 この有効化は、MDM プロバイダーとの登録の一部として行われます (正常性構成証明は既定で無効になります)。

  2. このサービスが有効になり、その後のすべてのブート後、デバイスは Microsoft がホストする正常性構成証明サービスに正常性測定値を送信し、その代わりに正常性構成証明 BLOB を受け取ります。

  3. このサイクルの後の任意の時点で、MDM サーバーはデバイスから正常性構成証明 BLOB を要求し、正常性構成証明サービスにコンテンツの暗号化を解除し、それが構成証明されていることを検証するように依頼できます。

    図 9。

Windows ベースのデバイス、正常性構成証明サービス、MDM 間の相互作用は、次のように実行できます。

  1. クライアントは MDM サーバーとのセッションを開始します。 MDM サーバーの URI は、要求を開始するクライアント アプリの一部になります。 現時点では、MDM サーバーは、適切な CSP URI を使用して正常性構成証明データを要求できます。

  2. MDM サーバーは、要求と共に nonce を指定します。

  3. その後、クライアントは AIK 引用符で囲まれた nonce + ブート カウンターと正常性 BLOB 情報を送信します。 この正常性 BLOB は、正常性構成証明サービスのみが復号化できる正常性構成証明サービス公開キーで暗号化されます。

  4. MDM サーバー:

    1. nonce が想定どおりに行われるかどうかを確認します。
    2. 見積もられたデータ、nonce、および暗号化された正常性 BLOB を Health Attestation Service サーバーに渡します。

  5. 正常性構成証明サービス:

    1. 正常性 BLOB の暗号化を解除します。
    2. 見積もりのブート カウンターが正常性 BLOB の AIK を使用して正しいことを確認し、正常性 BLOB の値と一致します。
    3. 引用符内の nonce と MDM から渡されたものが一致することを確認します。
    4. ブート カウンターと nonce は正常性 BLOB から AIK で引用されるため、デバイスが正常性 BLOB が生成されたものと同じであることが証明されます。
    5. 正常性パラメーター、鮮度など、データを MDM サーバーに送信します。

注

MDM サーバー (証明書利用者) は、見積もりまたはブート カウンター検証自体を実行しません。 引用符で囲まれたデータと正常性 BLOB (暗号化) を取得し、検証のために正常性構成証明サービスにデータを送信します。 このようにすると、AIK は MDM には表示されません。これにより、プライバシーに関する問題に対処できます。

デバイスコンプライアンスの要件を設定することは、正常性とコンプライアンスの要件を満たしていない登録済みデバイスが検出、追跡、および MDM ソリューションによって適用されるアクションを確実に行う最初の手順です。

リソースへの接続を試みるデバイスでは、異常なデバイスと非準拠デバイスを検出して報告できるように、正常性が評価されている必要があります。 完全に効率的にするには、エンド ツー エンドのセキュリティ ソリューションによって、価値の高い資産へのアクセスを拒否するような異常なデバイスに対して結果が課される必要があります。 異常なデバイスのその結果は、次のセクションで詳しく説明する条件付きアクセス制御の目的です。

アクセスが許可される前に Windows ベースのデバイスのセキュリティを制御する

今日のアクセス制御テクノロジは、ほとんどの場合、適切なユーザーが適切なリソースにアクセスできるようにすることに重点を置いています。 ユーザーが認証できる場合は、組織の IT スタッフやシステムがほとんど知らないデバイスを使用してリソースにアクセスできます。 おそらく、電子メールにアクセスする前にデバイスが暗号化されていることを確認するなど、いくつかのチェックがありますが、デバイスがマルウェアに感染した場合はどうしますか?

リモート デバイス正常性構成証明プロセスでは、測定されたブート データを使用して、デバイスの正常性状態を確認します。 デバイスの正常性は、Intune などの MDM ソリューションで使用できるようになります。

注

Intune と Windows の機能のサポートに関する最新情報については、「 Microsoft Intune の新機能」を参照してください。

次の図は、正常性構成証明サービスが Microsoft のクラウドベースの Intune MDM サービスとどのように連携すると予想されるかを示しています。

図 10。

MDM ソリューションでは、正常性状態ステートメントを使用し、デバイスがマルウェアフリーであること、マルウェア対策システムが機能し、最新の状態であること、ファイアウォールが実行されていること、デバイスのパッチ状態が準拠していることを証明する機能に基づいて条件付きアクセスを許可するクライアント ポリシーと組み合わせて、次のレベルに進むことができます。

最後に、正常であることを証明できないエンドポイントへのアクセスを拒否することで、リソースを保護できます。 この機能は、組織のリソースにアクセスする必要がある BYOD デバイスに非常に必要です。

Windows での MDM の組み込みサポート

Windows には、オペレーティング システムの一部として付属する MDM クライアントがあります。 この MDM クライアントを使用すると、MDM サーバーは別のエージェントを必要とせずに Windows ベースのデバイスを管理できます。

Microsoft MDM 以外のサーバーのサポート

Microsoft 以外の MDM サーバーは、MDM プロトコルを使用して Windows を管理できます。 組み込みの管理クライアントは、OMA-DM プロトコルをサポートする互換性のあるサーバーと通信して、エンタープライズ管理タスクを実行できます。 詳細については、「 Microsoft Entra と MDM の統合」を参照してください。

注

MDM サーバーは、Windows を管理するためにクライアントを作成またはダウンロードする必要はありません。 詳細については、「 モバイル デバイス管理」を参照してください。

サード パーティの MDM サーバーは、登録に同じ一貫性のあるファースト パーティ ユーザー エクスペリエンスを備え、Windows ユーザーにもわかりやすくします。

サード パーティ MDM による Windows Defender の管理

この管理インフラストラクチャにより、IT 担当者は Intune などの MDM 対応製品を使用して、ドメインに参加していない BYD を含む Windows ベースのデバイスで正常性構成証明、Device Guard、または Windows Defender を管理できます。 IT 担当者は、ダウンレベルのオペレーティング システムで Intune と Intune Endpoint Protection を使用することで、カスタマイズに慣れているすべてのアクションと設定を管理および構成できます。 現在、グループ ポリシーを使用してドメイン参加済みデバイスのみを管理している管理者は、設定とアクションの多くが両方のメカニズムで共有されるため、MDM を使用して Windows ベースのデバイスを管理する方法に簡単に移行できます。

MDM ソリューションを使用して Windows セキュリティとシステム設定を管理する方法の詳細については、「 Windows デバイスのカスタム URI 設定」を参照してください。

条件付きアクセス制御

ほとんどのプラットフォームでは、登録中に Microsoft Entra デバイスの登録が自動的に行われます。 デバイスの状態は、MDM ソリューションによって Microsoft Entra ID に書き込まれ、次にクライアントが Office 365 互換ワークロードにアクセスしようとしたときに、Office 365 (または Microsoft Entra ID と対話する承認された Windows アプリによって) によって読み取られます。

デバイスが登録されていない場合、ユーザーは登録方法 (登録とも呼ばれます) に関するメッセージを受け取ります。 デバイスが準拠していない場合、ユーザーは MDM Web ポータルにリダイレクトする別のメッセージを受け取り、コンプライアンスの問題とその解決方法に関する詳細情報を取得できます。

Microsoft Entra ID は ユーザーとデバイスを認証し、 MDM はコンプライアンスと条件付きアクセス ポリシーを管理し、 正常性構成証明サービスは 、証明された方法でデバイスの正常性について報告します。

図 11。

Office 365 の条件付きアクセス制御

Microsoft Entra ID では、Office 365 サービスへのアクセスをセキュリティで保護するための条件付きアクセス ポリシーが適用されます。 テナント管理者は、非準拠デバイス上のユーザーが Office 365 サービスにアクセスできないようにブロックする条件付きアクセス ポリシーを作成できます。 ユーザーは、サービスへのアクセスを許可する前に、会社のデバイス ポリシーに準拠している必要があります。 または、管理者は、ユーザーが自分のデバイスを登録して Office 365 サービスにアクセスすることを要求するポリシーを作成することもできます。 ポリシーは、組織のすべてのユーザーに適用されるか、いくつかのターゲット グループに制限され、より多くのターゲット グループを含むように時間の経過とともに強化される場合があります。

ユーザーがサポートされているデバイス プラットフォームから Office 365 サービスへのアクセスを要求すると、Microsoft Entra は、ユーザーが要求を起動したユーザーとデバイスを認証します。および は、ユーザーがサービスのポリシー セットに準拠している場合にのみ、サービスへのアクセスを許可します。 デバイスが登録されていないユーザーには、会社の Office 365 サービスにアクセスするために登録および準拠する方法に関する修復手順が提供されます。

ユーザーが登録すると、デバイスは Microsoft Entra ID に登録され、Intune などの互換性のある MDM ソリューションに登録されます。

注

Microsoft は、自動 MDM 登録とポリシー ベースのアクセス チェックをサポートするために、サードパーティの MDM ISV と連携しています。 Microsoft Entra ID と Intune を使用して自動 MDM 登録を有効にする手順については 、Windows、Microsoft Entra ID、Microsoft Intune: Cloud を利用した自動 MDM 登録に 関するブログ投稿を参照してください。

ユーザーがデバイスを正常に登録すると、デバイスは信頼されます。 Microsoft Entra ID は、会社のアプリケーションにアクセスするためのシングル サインオンを提供し、ユーザーが初めてアクセスを要求した場合だけでなく、ユーザーがアクセスの更新を要求するたびに、サービスへのアクセスを許可する条件付きアクセス ポリシーを適用します。

サインイン資格情報の変更、デバイスの紛失/盗難、または更新の要求時にコンプライアンス ポリシーが満たされていない場合、ユーザーはサービスへのアクセスを拒否されます。

従業員が Exchange Online へのアクセスに使用するメール アプリケーションの種類によっては、メールへのセキュリティで保護されたアクセスを確立するためのパスが若干異なる場合があります。 ただし、Microsoft Entra ID、Office 365/Exchange Online、Intune の主要なコンポーネントは同じです。 IT エクスペリエンスとエンド ユーザー エクスペリエンスも似ています。

図 12。

Office 365 へのアクセスを試みるクライアントは、次のプロパティについて評価されます。

  • デバイスは MDM によって管理されていますか?
  • デバイスは Microsoft Entra ID に登録されていますか?
  • デバイスは準拠していますか?

準拠状態を取得するには、Windows ベースのデバイスで次の作業を行う必要があります。

  • MDM ソリューションを使用して登録します。
  • Microsoft Entra ID で登録します。
  • MDM ソリューションによって設定されたデバイス ポリシーに準拠する。

注

現時点では、iOS および Android デバイスのユーザーに対して条件付きアクセス ポリシーが選択的に適用されています。 詳細については、 Microsoft Entra ID、Microsoft Intune、Windows - クラウドを使用したエンタープライズ モビリティの最新化に関する ブログ記事を参照してください。

クラウドとオンプレミスのアプリの条件付きアクセス制御

条件付きアクセス制御は、Microsoft Entra ID に組み込まれた強力なポリシー評価エンジンです。 これにより、IT 担当者は、ユーザーのサインインのコンテキストを評価する Office 365 以外のアクセス規則を簡単に作成して、アクセスを許可するアプリケーションについてリアルタイムで決定できます。

IT 担当者は、Microsoft Entra ID によってセキュリティ保護されたクラウド SaaS アプリケーションやオンプレミス アプリケーションの条件付きアクセス制御ポリシーを構成できます。 Microsoft Entra ID のアクセス 規則では、条件付きアクセス エンジンを使用して、Intune などの互換性のある MDM ソリューションによって報告されたデバイスの正常性とコンプライアンスの状態を確認し、アクセスを許可するかどうかを判断します。

条件付きアクセスの詳細については、「SaaS Apps の Azure 条件付きアクセス プレビュー」を参照してください。

注

条件付きアクセス制御は、EMS でも使用できる Microsoft Entra ID P1 または P2 機能です。 Microsoft Entra ID P1 または P2 サブスクリプションをお持ちでない場合は、 Microsoft Azure サイトから試用版を入手できます。

オンプレミス アプリケーションの場合、デバイスのコンプライアンス状態に基づいて条件付きアクセス制御を有効にするオプションは 2 つあります。

  • Microsoft Entra アプリケーション プロキシを介して発行されるオンプレミス アプリケーションの場合は、クラウド アプリケーションの場合と同様に条件付きアクセス制御ポリシーを構成できます。 詳細については、「 Microsoft Entra アプリケーション プロキシを使用したリモート ユーザー向けのオンプレミス アプリの公開」を参照してください。
  • さらに、Microsoft Entra Connect は、デバイス コンプライアンス情報を Microsoft Entra ID からオンプレミス AD に同期します。 Windows Server 2016 の ADFS では、デバイスのコンプライアンス状態に基づく条件付きアクセス制御がサポートされます。 IT 担当者は、互換性のある MDM ソリューションによって報告されたデバイスのコンプライアンス状態を使用してオンプレミス アプリケーションをセキュリティで保護する条件付きアクセス制御ポリシーを ADFS で構成します。

図 13。

次のプロセスでは、Microsoft Entra 条件付きアクセスのしくみについて説明します。

  1. ユーザーは、デバイスを Microsoft Entra ID に登録する Workplace Access/Azure AD 参加を通じて MDM に既に登録されています。
  2. デバイスが起動または休止状態から再開すると、タスク "Tpm-HASCertRetr" がトリガーされ、バックグラウンドで正常性構成証明 BLOB が要求されます。 デバイスは、TPM ブート測定値を正常性構成証明サービスに送信します。
  3. 正常性構成証明サービスは、デバイスの状態を検証し、正常性状態に基づいて暗号化された BLOB をデバイスに発行し、失敗したチェックの詳細 (存在する場合) を示します。
  4. ユーザーがログオンし、MDM エージェントが Intune/MDM サーバーにアクセスします。
  5. MDM サーバーは、使用可能な場合は新しいポリシーをプッシュダウンし、正常性 BLOB の状態やその他のインベントリ状態を照会します。
  6. デバイスは、以前に取得した正常性構成証明 BLOB と、Intune/MDM サーバーによって要求された他の状態インベントリの値も送信します。
  7. Intune/MDM サーバーは、正常性構成証明 BLOB を正常性構成証明サービスに送信して検証します。
  8. 正常性構成証明サービスは、正常性構成証明 BLOB を送信したデバイスが正常であることを検証し、この結果を Intune/MDM サーバーに返します。
  9. Intune/MDM サーバーは、コンプライアンスと、デバイスからクエリされたインベントリ/正常性構成証明の状態に基づいてコンプライアンスを評価します。
  10. Intune/MDM サーバーは、Microsoft Entra ID のデバイス オブジェクトに対するコンプライアンス状態を更新します。
  11. ユーザーがアプリを開き、企業の管理資産にアクセスしようとします。
  12. Microsoft Entra ID のコンプライアンス要求によってゲートされたアクセス。
  13. デバイスが準拠していて、ユーザーが承認されている場合は、アクセス トークンが生成されます。
  14. ユーザーは、企業の管理資産にアクセスできます。

Microsoft Entra 参加の詳細については、「 Microsoft Entra ID & Windows: Better Together for Work or School」(ホワイト ペーパー) を参照してください。

条件付きアクセス制御は、多くの組織や IT 担当者が知らない可能性があり、必要なトピックです。 ユーザー、デバイス、コンプライアンス、アクセスコンテキストを記述するさまざまな属性は、条件付きアクセス エンジンで使用する場合に強力です。 条件付きアクセス制御は、組織が環境をセキュリティで保護するのに役立つ重要な手順です。

概要と概要

次の一覧には、組織のセキュリティ体制を改善するための重要な概要が含まれています。 ただし、このセクションで説明するいくつかの点は、セキュリティのベスト プラクティスの網羅的な一覧として解釈しないでください。

  • ソリューションが 100% 安全でないことを理解する

    悪意のある敵対者がデバイスに物理的にアクセスすると、最終的にセキュリティ層を突破して制御する可能性があります。

  • MDM ソリューションで正常性構成証明を使用する

    価値の高い資産への接続を試みるデバイスでは、異常なデバイスと非準拠デバイスを検出、報告、最終的にブロックできるように、正常性が評価されている必要があります。

  • Credential Guard を使用する

    Credential Guard は、企業ドメインの資格情報をパス ザ ハッシュ攻撃から保護するのに大きく役立つ機能です。

  • Device Guard を使う

    Device Guard は、セキュリティの真の進歩であり、マルウェアから保護するのに役立つ効果的な方法です。 Windows の Device Guard 機能は、信頼されていないアプリ (組織によって承認されていないアプリ) をブロックします。

  • Device Guard ポリシーに署名する

    署名済み Device Guard ポリシーは、現在のポリシーを破ろうとする管理者特権を持つユーザーから保護するのに役立ちます。 ポリシーが署名されている場合、Device Guard を後で変更する唯一の方法は、同じ署名者によって署名されたポリシーの新しいバージョンを提供するか、Device Guard ポリシーの一部として署名者から指定することです。

  • 仮想化ベースのセキュリティを使用する

    仮想化ベースのセキュリティによってカーネル モードのコード整合性が保護されている場合、脆弱性によって未承認のカーネル モード メモリ アクセスが許可されている場合でも、コード整合性規則は引き続き適用されます。 仮想化ベースのセキュリティでカーネル コードの整合性を実行する Device Guard デバイスには、互換性のあるドライバーが必要であることに注意してください。

  • 監査モードで Device Guard の展開を開始する

    監査モードで対象のコンピューターとデバイスに Device Guard ポリシーを展開します。 Device Guard が強制モードで構成されている場合に、プログラムまたはドライバーがブロックされたことを示すコード整合性イベント ログを監視します。 高い信頼度に達するまで Device Guard ルールを調整します。 テスト フェーズが完了すると、Device Guard ポリシーを強制モードに切り替えることができます。

  • Device Guard のデプロイ時に分離された参照マシンを構築する

    企業ネットワークにはマルウェアが含まれている可能性があるため、主要な企業ネットワークから分離された参照環境の構成を開始する必要があります。 その後、保護されたデバイスで実行する信頼されたアプリケーションを含むコード整合性ポリシーを作成できます。

  • AppLocker が理にかなっている場合は、AppLocker を使用します

    AppLocker は新しい Device Guard 機能とは見なされませんが、特定のユーザーまたはユーザーのグループに対して特定のユニバーサル Windows アプリケーションを拒否できるなどの一部のシナリオで Device Guard 機能を補完します。

  • ファームウェアと構成をロックダウンする

    Windows がインストールされたら、ファームウェアブートオプションのアクセスをロックダウンします。 このロックダウンにより、物理アクセス権を持つユーザーが UEFI 設定を変更したり、セキュア ブートを無効にしたり、他のオペレーティング システムを起動したりできなくなります。 また、Device Guard を無効にしようとする管理者から保護するには、現在の Device Guard ポリシーに、 C:\Windows\System32\SecConfig.efi ツールの実行を拒否およびブロックする規則を追加します。

正常性構成証明は、ユーザーとそのデバイスの ID とコーポレート ガバナンス ポリシーへの準拠に基づいて価値の高い資産へのアクセスを制御するためのクライアントとクラウド のコンポーネントを含む Windows の重要な機能です。 組織は、異常なデバイスを検出して報告するか、ニーズに基づいて正常性の適用規則を構成することを選択できます。 正常性構成証明は、エンド ツー エンドのセキュリティ モデルと統合ポイントを提供します。ベンダーやソフトウェア開発者は、カスタマイズされたソリューションの構築と統合に使用できます。