Windows 10 ベースのデバイスの正常性の制御
この記事では、Windows 10 ベースのデバイスの正常性を適用、制御、レポートすることで価値の高い資産を保護できるエンド ツー エンドのソリューションについて詳しく説明します。
概要
Bring Your Own Device (BYOD) シナリオでは、従業員が市販のデバイスを持ち込んで、仕事関連のリソースと個人データの両方にアクセスします。ユーザーは好みのデバイスを使って、内部ネットワークからだけではなくどこからでも、組織のアプリケーション、データ、リソースにアクセスしたいと考えています。この現象は IT のコンシューマライゼーションとしても知られています。
ユーザーは、自分のデバイスから企業のアプリケーションにアクセスして組織のデータで作業するときに、生産性のエクスペリエンスを最大限に高めたいと考えています。つまり、ユーザーは、アプリケーションやファイル サーバーにアクセスするたびに、職場の資格情報を入力するように求められることを煩わしく感じています。セキュリティの観点から言えば、ユーザーは管理対象外のデバイスで企業の資格情報やデータを操作していることになります。
BYOD が広がるにつれ、企業のサービス、内部のリソース、クラウド アプリケーションにアクセスする、正常でない可能性のある管理対象外のシステムが増えます。
管理されたデバイスでさえ、侵害されて有害になることがあります。組織は、価値の高い資産を保護するために、セキュリティが破られたことを検出し、できる限り早期に対応する必要があります。
マイクロソフトの取り組みが進むにつれ、セキュリティ関連の投資先は、セキュリティの予防的防御だけでなく検出および対応機能に、ますます向くようになっています。
Windows 10 は、セキュリティの予防的防御の実装に焦点を当てるだけでなく、総合的なセキュリティ戦略にデバイスの正常性の認証機能を加えるエンド ツー エンドのセキュリティ ソリューションの重要なコンポーネントになっています。
堅牢なエンド ツー エンドのセキュリティ ソリューションの説明
今日のコンピューティングの脅威はこれまでにない速度で増えています。犯罪者の攻撃はますます巧妙になっており、マルウェアは現在、あらゆる業界の消費者とエキスパートの両方を標的としていることは間違いありません。
近年、脅威の 1 カテゴリとして広がっているのが、持続的標的型攻撃 (APT) です。一般的に APT という用語は、特に個々の組織を継続的に標的とするような攻撃すべてを説明するために使われます。実際、この種の攻撃には通常、必要なあらゆる方法や手法を駆使し得る、特定の敵がかかわります。
BYOD 現象に伴い、十分に管理されていないデバイスが格好の標的になります。攻撃者にとって、セキュリティ ネットワーク境界を突破して、価値の高い資産にアクセスしてそれらを盗み出すのは簡単です。
攻撃者が個人を標的にするのは、特に、その人がだれかというよりも、どのような仕事を担当しているかが理由になります。感染したデバイスによって組織にマルウェアが持ち込まれます。これは、組織がネットワーク境界を強化していても、防御態勢に投資していても同じです。防御戦略はこれらの脅威に対して十分ではありません。
異なるアプローチ
効果的なセキュリティ戦略では、従来のようにセキュリティ侵害を予防することに注目するのではなく、特定の敵があらゆる防御を突破できることを前提とします。つまり、焦点を予防的なセキュリティ制御からセキュリティ問題の検出と対応に移す必要があるということです。したがって、リスク管理戦略の実装では、予防、検出、対応にバランスよく投資します。
ますます多くのモバイル デバイスが企業情報にアクセスするために使われているため、デバイスのセキュリティや正常性を評価するための何らかの方法が必要です。このセクションでは、価値の高い資産を正常でないデバイスから保護できるようにデバイスの正常性評価をプロビジョニングする方法について説明します。
企業リソースへのアクセスに使われるデバイスは信頼されている必要があります。効率的なエンド ツー エンドのセキュリティ アプローチでは、デバイスの正常性を評価して、価値の高い資産へのアクセスを許可するときに現在のセキュリティ状態を使えます。
.png "図 1")
堅牢な設計では、ユーザーの ID を確立し、必要に応じて認証方法を強化するほか、ユーザーが定期的に接続しているネットワークの場所のような行動パターンを調べる必要があります。また、現代的なアプローチでは、ユーザー デバイスが正常で安全であると見なされた場合にのみ、秘密度の高いコンテンツを公開できることが必要です。
次の図では、クラウドからデバイスの正常性を評価するために作成されたソリューションを示しています。デバイスは、クラウド内の ID プロバイダーへの接続を介してユーザーを認証します。管理対象の資産に機密性の高い情報が含まれている場合、ID プロバイダーの条件付きアクセス エンジンでは、アクセスを許可する前にモバイル デバイスのセキュリティ準拠を検証することを選べます。ユーザーのデバイスは、正常性状態を証明でき、その状態は、モバイル デバイス管理 (MDM) から求められたらいつでも送ることができます。
.png "図 2")
Windows デバイスは、Unified Extensible Firmware Interface (UEFI) セキュア ブートなどの低レベルのハードウェア テクノロジを使って、低レベルのルートキットやブートキットから保護できます。
セキュア ブートは、ルートキットの攻撃を防ぐことのできるファームウェア検証プロセスで、UEFI 仕様に含まれています。UEFI の目的は、オペレーティング システムが最新のハードウェアと通信する標準的な方法を定義することです。その方法では、これまでのソフトウェア割り込み駆動型の BIOS システムよりも高速かつ効率的に入力/出力 (I/O) 機能を実行できます。
デバイスの正常性の認証モジュールは、トラステッド プラットフォーム モジュール (TPM) によって保護されたメジャー ブート データをリモート サービスとやり取りできます。デバイスを正常に起動した後、メジャー ブート プロセスのデータは、安全で改ざんされにくい通信チャネルを介して、信頼されたクラウド サービス (正常性認証サービス) に送られます。
リモートの正常性認証サービスは測定値の一連のチェックを行い、ブート状態 (セキュア ブート、デバッグ モードなど) やセキュリティを管理するコンポーネント (BitLocker、Device Guard など) の状態を含め、セキュリティ関連のデータ ポイントを検証します。続いて、デバイスに正常性暗号化 BLOB を送ることで、デバイスの正常性状態を伝えます。
MDM ソリューションは通常、構成ポリシーを適用し、デバイスにソフトウェアを展開します。MDM は、セキュリティ ベースラインを定義し、デバイスの準拠レベルを定期的に調べて、インストールされているソフトウェア、適用されている構成のほか、デバイスの正常性状態も確認します。
MDM ソリューションは、リモートの正常性認証サービスにデバイスの正常性の情報を送り、正常性暗号化 BLOB を転送するように、デバイスに求めます。リモートの正常性認証サービスは、デバイスの正常性データを検証し、MDM が同じデバイスとやり取りしていることを確認したら、デバイスの正常性レポートを MDM ソリューションに戻します。
MDM ソリューションは、正常性アサーションを評価し、組織に属する正常性規則に従ってデバイスが正常であるかどうかを決めます。デバイスが正常で準拠している場合、MDM は、組織のアクセス制御ポリシーを呼び出してアクセスを許可できるように、その情報を ID プロバイダーに渡します。
その後、コンテンツへのアクセスは、正常性状態とその他の条件付き要素に応じて、信頼の適切なレベルに許可されます。
管理対象の資産の要件と秘密度に基づいて、デバイスの正常性状態は、アクセス要求の処理時に、ユーザー ID 情報と組み合わせることができます。その後、コンテンツへのアクセスは信頼の適切なレベルに許可されます。条件付きアクセス エンジンは、管理対象の資産の秘密度に応じて追加の検証ができるように構成することもできます。たとえば、価値の高いデータへのアクセスを求められた場合、追加のセキュリティ認証を確立するために、アクセスを許可する前に、電話の呼び出しに応答するようにユーザーに求めることもできます。
Windows 10 でのマイクロソフトのセキュリティへの投資
Windows 10 では、投資には次の 3 つの柱があります。
ID の保護。マイクロソフトは、ローカル システムとサービス (オンプレミスのリソース、クラウドのリソースなど) の認証に対するパスワードの使用から脱却して、セキュリティで保護された認証の相互運用可能な方法の実現を目指す FIDO Alliance に参加しています。
情報の保護。マイクロソフトは、組織で重要なデータにだれがアクセスできて何を実行できるかをより細かく制御できるように、投資を行っています。組織では、Windows 10 の導入により、保護されたデータへのアクセスに使える信頼できる企業アプリケーションを指定するポリシーを利用できます。
脅威への対抗。マイクロソフトは、ハードウェア依存型のセキュリティ防御を使って、マルウェアや攻撃の脅威から企業の資産をより強力に保護できるように、組織を支援しています。
Windows 10 ベースのデバイスのセキュリティ状態の保護、制御、レポート
このセクションでは、攻撃者やマルウェアから価値の高い資産と情報を保護するエンド ツー エンドのセキュリティ ソリューションのさまざまな部分について概説します。
.png "図 3")
| 番号 | ソリューションの部分 | 説明 |
|---|---|---|
1 |
Windows 10 ベースのデバイス |
初めて Windows 10 ベースのデバイスの電源をオンにすると、Out-Of-Box Experience (OOBE) 画面が表示されます。セットアップ中に、デバイスは自動的に Azure Active Directory (AD) に、続いて MDM に登録されます。 TPM 2.0 を搭載した Windows 10 ベースのデバイスは、Windows 10 のすべてのエディションに対応した正常性認証サービスを使って、いつでも正常性状態をレポートできます。 |
2 |
ID プロバイダー |
Azure AD には、ユーザーのほか、組織のテナントに登録されたデバイスとアプリケーションが含まれています。1 台のデバイスは常に 1 人のユーザーに属し、1 人のユーザーは複数のデバイスを所有できます。デバイスは、デバイスの準拠状態など、さまざまな属性を備えたオブジェクトとして表されます。信頼された MDM は準拠状態を更新できます。 Azure AD はリポジトリというだけではありません。ユーザーとデバイスを認証でき、また、管理対象のリソースへのアクセスを許可できます。Azure AD の条件付きアクセス制御エンジンは、信頼されたアクセスを決めるとき、ユーザーの ID 情報、デバイスの位置情報のほか、デバイスの準拠状態も活用します。 |
3 |
モバイル デバイス管理 |
Windows 10 では、MDM がサポートされており、いずれのエージェントも展開することなく、導入直後からデバイスを管理できます。 MDM には、Microsoft Intune、または Windows 10 と互換性のあるサード パーティの MDM ソリューションを使うことができます。 |
4 |
リモートの正常性認証 |
正常性認証サービスは、マイクロソフトが運営する信頼されたクラウド サービスであり、一連の正常性チェックを実行し、デバイスで有効になっている Windows 10 のセキュリティ機能を MDM にレポートします。 セキュリティ検証には、ブート状態 (WinPE、セーフ モード、デバッグ/テスト モード)、ランタイム操作のセキュリティ/整合性を管理するコンポーネント (BitLocker、Device Guard) が含まれます。 |
5 |
企業管理対象の資産 |
企業管理対象の資産は保護するリソースです。 たとえば、資産には、Office 365 などのクラウド アプリのほか、Azure AD によって公開されたオンプレミスの Web リソース、VPN アクセスがあります。 |
Windows 10 ベースのデバイス、ID プロバイダー、MDM、リモート正常性認証の組み合わせにより、価値の高い資産にアクセスするデバイスの正常性と準拠の検証が可能になる堅牢なエンド ツー エンド ソリューションが作成されます。
脅威に対するデバイスと企業の資格情報の保護
このセクションでは、Windows 10 によってセキュリティ防御の面で何がもたらされるか、どのような制御が測定されてレポートされるかについて説明します。
Windows 10 ハードウェア ベースのセキュリティ防御
マルウェアの最もアグレッシブな攻撃形態は、できるだけ早期にブート プロセスに自らを挿入することで、初期にオペレーティング システムの制御を奪い、保護メカニズムとマルウェア対策ソフトウェアの動作を阻むというものです。この種の悪質なコードは、多くの場合、ルートキットやブートキットと呼ばれています。低レベルのマルウェアへの対処を省く最善の方法は、デバイスが初期から保護されるように、ブート プロセスをセキュリティで保護することです。
Windows 10 では、複数レイヤーのブート保護がサポートされています。これらの機能のいくつかは、特定の種類のハードウェアがインストールされている場合にのみ使うことができます。詳しくは、「ハードウェア要件」をご覧ください。
.png "図 4")
Windows 10 では、スタートアップ プロセス中にルートキットやブートキットなどの高度な低レベルのマルウェアが読み込まれないようにする機能をサポートしています。
トラステッド プラットフォーム モジュール。トラステッド プラットフォーム モジュール (TPM) は、独自のセキュリティ機能を提供するハードウェア コンポーネントです。
Windows 10 では、ブート整合性シーケンスの測定 (およびそれに応じた BitLocker で保護されているドライブの自動ロック解除)、資格情報の保護、正常性の認証に TPM のセキュリティ特性を利用しています。
TPM には、Trusted Computing Group (TCG) による仕様を満たす制御が実装されています。本稿執筆時点では、TCG による TPM の仕様には、互いに互換性のない 2 つのバージョンがあります。
最初の TPM の仕様であるバージョン 1.2 は、TCG によって 2005 年 2 月に公開され、ISO/IEC 11889 標準で標準化されました。
TPM 2.0 と呼ばれる最新の TPM の仕様は、2014 年 4 月にリリースされ、ISO/IEC Joint Technical Committee (JTC) によって ISO/IEC 11889:2015 として承認されました。
TPM は、Windows 10 では、正常性認証の一環である暗号化計算と、BitLocker、Microsoft Passport、仮想スマート カードなどの公開キー証明書のキーの保護に使われています。詳しくは、Windows 10 の TPM 要件に関するページをご覧ください。
Windows 10 は、TCG によるバージョン 1.2 と 2.0 の TPM の仕様を認識します。最新のセキュリティ機能については、Windows 10 では TPM 2.0 のみをサポートしています。デバイスの正常性の認証には、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 10 の OS ローダーにデジタル署名するために使われた Microsoft 証明書はそこに格納されているため、UEFI はセキュリティ ポリシーの一環として証明書を検証できます。Windows ハードウェア互換性プログラムで Windows 10 の認定を受けたすべてのコンピューターは、既定でセキュア ブートを有効にする必要があります。
セキュア ブートは UEFI ファームウェアベースの機能で、起動時に重要なブート ファイルとドライバーの署名と検証を実行できます。セキュア ブートでは、ビルド時に OEM が定義したポリシーを使って利用可能なオペレーティング システムを完全に起動できるようになる前に、起動時に Windows ブート マネージャー、BCD ストア、Windows OS ローダー ファイル、ブートに不可欠なその他の DLL の署名値を確認します。セキュア ブートは、ブートベースのルートキットやマルウェアなど、Windows プラットフォームに対するさまざまな種類のセキュリティ関連の攻撃を防ぎます。ローカル ハード ディスク、USB、PXE、DVD から通常の Windows と Windows 回復環境 (RE) のどちらを起動する場合でも、セキュア ブートによってオペレーティング システムのブート プロセスが保護されます。
セキュア ブートでは、重要なブート コンポーネントの署名を検証して、悪意のあるアクティビティによってセキュリティが侵害されていないことを確認することで Windows 10 インストールのブート環境を保護します。セキュア ブートによる保護は、Windows カーネル ファイル (ntoskrnl.exe) が読み込まれた後に終了します。
注
セキュア ブートは、Windows カーネルが読み込まれるまで、プラットフォームを保護します。ELAM などの保護は引き継がれます。
セキュア ブート構成ポリシー。セキュア ブート機能を Windows 10 の重要な構成に拡張します。
保護される構成情報の例としては、Disable Execute ビット (NX オプション) の保護や、テスト署名ポリシー (コード整合性) を有効にできないことの確認があります。これにより、ブート プロセス完了後のコンピューターのバイナリと構成を信頼できるようにします。
セキュア ブート構成ポリシーと UEFI ポリシーでこれを実現します。 これらのポリシーの署名は、セキュア ブートで使われるオペレーティング システムのバイナリの署名と同じ方法で署名されます。
セキュア ブート構成ポリシーは、キー交換キー (KEK) の一覧に格納されている公開キーのいずれかに対応する秘密キーで署名する必要があります。Microsoft 証明機関 (CA) は、Windows 認定済みのすべてのセキュア ブート システムの KEK の一覧に存在します。既定では、Microsoft KEK によって署名されたポリシーはすべてのセキュア ブート システムで利用できます。BootMgr は、署名されたポリシーを適用する前に、署名と KEK の一覧を照合する必要があります。Windows 10 では、既定のセキュア ブート構成ポリシーが bootmgr に埋め込まれています。
ブートローダーは、Windows 10 カーネルのデジタル署名を検証してから読み込みます。その後、Windows 10 カーネルは、ブート ドライバー、スタートアップ ファイル、および ELAM コンポーネントを含む、Windows スタートアップ プロセスの他のすべてのコンポーネントを検証します。このステップは重要で、すべての Windows ブート コンポーネントに整合性があり、信頼できることを確認することで、残りのブート プロセスを保護します。
起動時マルウェア対策 (ELAM)。ELAM では、すべてのドライバーを読み込む前にテストし、承認されていないドライバーが読み込まれないようにします。
従来のマルウェア対策アプリは、ブート ドライバーが読み込まれるまで起動しないため、ルートキットをドライバーに偽装して実行できる可能性があります。ELAM は、前のバージョンの Windows で導入された Windows メカニズムで、ブート シーケンスの初期にマルウェア対策ソフトウェアの実行を許可します。そのため、マルウェア対策コンポーネントは最初に実行されるサード パーティ コンポーネントとなり、Windows オペレーティング システムが動作するまでその他のブート ドライバーの初期化を制御します。完全なランタイム環境 (ネットワーク アクセスやストレージなど) を備えたシステムが起動すると、フル装備のマルウェア対策が読み込まれます。
ELAM は、Microsoft 以外のすべてのブート ドライバーとアプリケーションよりも先に Microsoft または Microsoft 以外のマルウェア対策ドライバーを読み込むことができるため、セキュア ブートとトラスト ブートによって確立された信頼チェーンが維持されます。オペレーティング システムがまだ起動していないうえに、Windows をできる限り短時間で起動する必要があるため、ELAM はすべてのブート ドライバーを調べ、信頼されたドライバーの一覧に含まれているかどうかを確認するという単純なタスクを実行します。信頼されていないドライバーは読み込まれません。
注
Windows Defender (Windows 10 に既定で含まれている Microsoft のマルウェア対策) は、ELAM をサポートしています。サード パーティの互換性のあるマルウェア対策ソリューションに置き換えることができます。Windows Defender の ELAM ドライバーの名前は WdBoot.sys です。Windows 10 の Windows Defender では、その ELAM ドライバーを使って、次回の再起動時に Windows Defender ドライバーに対して行われた悪意のある変更をすべてロールバックします。そのため、カーネル モードのマルウェアは、シャットダウンや再起動の前に、Windows Defender のミニフィルター ドライバーに永続的な変更を加えることができません。
ELAM の署名済みドライバーは、その他のサード パーティのドライバーやアプリケーションよりも先に読み込まれます。そのため、マルウェア対策ソフトウェアでは、署名されていないコードや信頼されていないコードを読み込ませてブート プロセスを改ざんしようとするすべての試みを検出してブロックできます。
ELAM ドライバーは、システム起動時の初期に読み込まれるドライバーに焦点を絞った非常に範囲の狭い小規模なポリシー データベースを備えた小さなドライバーです。ポリシー データベースは、TPM で測定されるレジストリ ハイブに保存され、ELAM ドライバーの動作パラメーターを記録します。ELAM ドライバーには Microsoft の署名が必要で、関連付けられている証明書に補完的な EKU (1.3.6.1.4.1.311.61.4.1) が含まれている必要があります。
仮想化ベースのセキュリティ (Hyper-V + セキュリティで保護されたカーネル)。仮想化ベースのセキュリティは、Windows 10 の重要な部分を保護できる完全に新しく適用されたセキュリティ境界です。
仮想化ベースのセキュリティは、カーネル モード コード整合性や、Windows オペレーティング システムの他の部分からの機密性の高い企業のドメイン資格情報などの機密性の高いコードを分離します。詳しくは、「仮想化ベースのセキュリティ」セクションをご覧ください。
Hyper-V コード整合性 (HVCI)。Hyper-V コード整合性は、Device Guard のコード整合性ポリシーに準拠しているドライバー、実行可能ファイル、DLL にだけ実行を許可する Device Guard の機能です。
有効にされ、構成されている場合、Windows 10 は、Hyper-V コード整合性 (HVCI) を含む、Hyper-V 仮想化ベース セキュリティ サービスを開始できます。HVCI は、ブート プロセスの初期段階、または起動後のマルウェアの動作を防ぐことによって、システムのコア (カーネル)、特権ドライバー、およびマルウェア対策ソリューションなどのシステム防御を保護するのに役立ちます。
HVCI では、仮想化ベースのセキュリティを使って、コード整合性を分離します。カーネル メモリが実行できるようになる唯一の方法は、コード整合性の検証にパスすることです。そのため、カーネル メモリのページは決して書き込み可能または実行可能 (W+X) にならず、実行可能コードを直接変更することはできません。
注
カーネル モード コード整合性と仮想化ベースのセキュリティを実行する Device Guard デバイスには、互換性のあるドライバーが必要です。詳しくは、Windows 10 の Device Guard と互換性のあるドライバーに関するブログ記事をご覧ください。
Device Guard コード整合性機能を使うと、信頼して Windows カーネルで実行するコードと、ユーザー モードでの実行を許可するアプリケーションを制御できます。これは、ポリシーを使って構成できます。
Device Guard コード整合性ポリシーは、署名することをお勧めしているバイナリ ファイルです。コード整合性ポリシーに署名しておくと、現在のコード整合性ポリシーを変更または削除しようとする、管理者特権を持つ悪意のあるユーザーから保護するのに役立ちます。
Credential Guard。Credential Guard では、ハードウェアベースの資格情報の分離によって企業の資格情報を保護します。
Windows 10 の Credential Guard の目的は、企業のドメイン資格情報をマルウェアによる盗難や再利用から保護することです。Windows 10 では、Credential Guard を利用して、現行の pass-the-hash (PtH) 攻撃を根本的に防ぐアーキテクチャ上の変更を実装しています。
これは、Hyper-V と新しい仮想化ベースのセキュリティ機能を利用して、信頼できるコードと機密情報を Windows カーネルから分離する保護コンテナーを作成することで実現しています。そのため、Windows カーネルのセキュリティが侵害されても、攻撃者には PtH 攻撃を開始するために必要なデータを読み取って抽出する方法がありません。機密情報が格納されているメモリには、カーネル モードでも、通常の OS からはアクセスできないため、Credential Guard によって PtH 攻撃が防止されます。メモリにアクセスできるユーザーはハイパーバイザーで制御します。
正常性の認証。デバイスのファームウェアでブート プロセスをログに記録し、Windows 10 から信頼されたサーバーにそのログを送って、デバイスの正常性を確認し、評価できます。
Windows 10 では、UEFI ファームウェアを測定します。Windows とマルウェア対策の各コンポーネントは、ブート プロセス時に読み込まれたときに測定されます。また、一度にまとめてではなく、順番に測定されます。これらの測定が完了すると、その値はデジタル署名され、TPM に安全に格納されます。システムをリセットしない限り、変更することはできません。
詳しくは、「セキュア ブートとメジャー ブート: マルウェアに対する初期ブート コンポーネントの強化」をご覧ください。
後続の起動のたびに、同じコンポーネントが測定されます。それにより、予期されるベースラインと測定値を比較できます。セキュリティを強化するために、TPM によって測定された値に署名し、リモート サーバーに送って、比較することができます。リモート デバイスの正常性の認証と呼ばれるこのプロセスにより、サーバーは Windows デバイスの正常性状態を確認できます。
正常性の認証には、TPM 2.0 が必要です。Windows 10 では、TPM 2.0 に UEFI ファームウェアが必要です。
セキュア ブートは事前対応型の保護で、正常性の認証は事後対応型のブート保護です。正常性の認証は、Windows では出荷時は無効になっており、マルウェア対策ベンダーや MDM ベンダーが有効にします。セキュア ブートとは異なり、正常性の認証ではブート プロセスが停止することはなく、測定できない場合は修復が開始されます。ただし、条件付きアクセス制御と組み合わせると、正常性の認証で価値の高い資産へのアクセスを防止することができます。
仮想化ベースのセキュリティ
仮想化ベースのセキュリティは、Windows 10 に新しい信頼境界を追加します。 Hyper-V Hypervisor テクノロジを活用して、プラットフォームのセキュリティを強化します。仮想化ベースのセキュリティは、Windows の特定の信頼されたコード (トレストレット) を実行し、機密性の高いデータを保護する、セキュリティで保護された実行環境を提供します。
仮想化ベースのセキュリティでは、侵害されたカーネルや管理者特権を持つ悪意のあるユーザーから保護できます。仮想化ベースのセキュリティでは物理的な攻撃者からは保護されないことに注意してください。
仮想化ベースのセキュリティでは、次の Windows 10 サービスが保護されます。
Credential Guard (LSA の資格情報の分離): pass-the-hash 攻撃と、lsass メモリの内容を読み取り、ダンプすることで行われるエンタープライズ資格情報の盗難を防ぎます。
Device Guard (Hyper-V コード整合性): Device Guard は、Windows 10 の新しい仮想化ベースのセキュリティを使って、Windows カーネル自体からコード整合性サービスを分離します。これにより、このサービスで、企業が管理するポリシーで定義された署名を使って、信頼できるものを特定できます。実際には、コード整合性サービスは、Windows ハイパーバイザーで保護されているコンテナーでカーネルと並行して動作します。
分離されたその他のサービス: たとえば、Windows Server Technical Preview 2016 には、暗号化された仮想マシン (VM) をサーバーに追加できる vTPM 機能があります。
注
仮想化ベースのセキュリティは、Windows 10 Enterprise でのみ利用できます。仮想化ベースのセキュリティを利用するには、セキュア ブートが有効な UEFI (2.3.1 以上) に加え、仮想化拡張と SLAT が有効な x64 プロセッサを搭載しているデバイスが必要です。 IOMMU、TPM 2.0、セキュア メモリの上書きのサポートは任意ですが、使うことをお勧めします。
次のスキーマは、仮想化ベースのセキュリティを使った Windows 10 の概要を示しています。
.png "図 5")
Credential Guard
Windows 10 では、Credential Guard が有効な場合は、ローカル セキュリティ機関サブシステム サービス (lsass.exe) によって機密性の高いコードが分離ユーザー モードで実行されるため、通常のユーザー モードでは実行される可能性のあるマルウェアからデータを保護できます。これにより、保護されたデータが盗まれたり、リモート コンピューターで再利用されたりすることがなくなり、PtH スタイルのさまざまな攻撃が緩和されます。
Credential Guard では、資格情報をブートごとのキーまたは永続的なキーで暗号化して保護します。
ブートごとのキーは、保持する必要のないメモリ内の資格情報に使われます。そうした資格情報の例としては、チケット保証チケット (TGT) セッションのキーがあります。このキーは、認証が行われるたびにキー配布センター (KDC) とネゴシエートされ、ブートごとのキーで保護されます。
永続的なキー (または派生物) は、保存され、再起動後に再び読み込まれる項目の保護に使われます。そうした保護は長期保存を目的としており、永続的なキーで保護する必要があります。
Credential Guard は、レジストリ キーでアクティブ化され、UEFI 変数を使って有効にされます。これは、リモートからの構成の変更から保護するためです。UEFI 変数を利用するため、構成を変更するには物理的にアクセスする必要があります。lsass.exe は、資格情報の分離が有効になっていることを検出すると、LsaIso.exe を分離プロセスとして生成します。これにより、LsaIso.exe が分離ユーザー モードで実行されます。LsaIso.exe の起動は、セキュリティ サポート プロバイダーの初期化よりも前に実行されます。そのため、認証が始まる前に、セキュリティで保護されたモードのサポート ルーチンの準備が整います。
Device Guard
Device Guard は、組織がデバイスをロックダウンして、信頼されていないソフトウェアを実行できないようにする Windows 10 Enterprise の新機能です。この構成では、組織が信頼したアプリケーションしか実行できません。
コードを実行するかどうかの信頼性の判断は、仮想化ベースのセキュリティ (標準の Windows と並行して動作する Hyper-V 保護コンテナー) で実行される Hyper-V コード整合性を使って実行されます。
Hyper-V コード整合性は、ドライバーやシステム ファイルがメモリに読み込まれるたびに、その整合性を検証する機能です。コード整合性では、未署名のドライバーやシステム ファイルがカーネルに読み込まれるかどうかや、管理者特権を持つユーザー アカウントで実行されている悪意のあるソフトウェアによってシステム ファイルが変更されているかどうかを検出します。x64 ベースのバージョンの Windows 10 では、カーネル モード ドライバーにデジタル署名する必要があります。
注
Device Guard ポリシーのアクティブ化とは別に、Windows 10 では、カーネルで実行するための条件を既定で引き上げています。Windows 10 ドライバーは、Microsoft (具体的には、WHQL (Windows Hardware Quality Labs) ポータル) によって署名されている必要があります。さらに、2015 年 10 月から、WHQL ポータルでは、カーネル モードとユーザー モードの両方のドライバーの提出を含め、有効な Extended Validation ("EV") コード署名証明書を持つドライバーの提出しか受け入れなくなりました。
Windows 10 の Device Guard では、組織が Windows 10 Enterprise を実行している x64 システムで使うコード整合性ポリシーを独自に定義できるようになりました。 ポリシーの構成によって、何を信頼して実行するかを決めることができます。対象となるのは、ドライバー、システム ファイル、従来のデスクトップ アプリケーション、スクリプトです。構成すると、システムはロックダウンされ、組織が信頼しているアプリケーションのみが実行されます。
Device Guard は、望ましくないコードやアプリケーションが実行されないようにする Windows 10 Enterprise の組み込み機能です。Device Guard は、許可と拒否という 2 つの規則操作を使って構成できます。
許可では、アプリケーションの実行をコードの許可リストまたは信頼された発行元に制限し、それ以外はすべてブロックします。
拒否では、特定のアプリケーションの実行をブロックすることで、信頼された発行元の許可アプローチを完成させます。
この記事の執筆時点における Microsoft の最新の調査によると、マルウェアの 90% 以上がまったく署名されていません。そのため、基本的な Device Guard ポリシーを実装することで、マルウェアのほとんどを簡単かつ効率的にブロックできます。実のところ、Device Guard はさらなる可能性を秘めており、署名されたマルウェアもブロックできます。
Device Guard が真の効果を発揮するように計画して構成する必要があります。これは、単に有効または無効にするだけの保護ではありません。Device Guard は、ハードウェア セキュリティ機能とソフトウェア セキュリティ機能を兼ね備えています。そのため、両方の機能を構成すると、コンピューターをロックダウンして、最も高いセキュリティと耐性を備えたシステムを実現できます。
Windows 10 の Device Guard ソリューションは、次の 3 つで構成されています。
最初の構成要素は、前のバージョンの Windows で導入された基本となる一連のハードウェア セキュリティ機能です。ハードウェア暗号化操作を行う TPM、最新のファームウェアを備えた UEFI、セキュア ブートを組み合わせて、システムの起動時に実行されるデバイスを制御できます。
ハードウェア セキュリティ機能の次は、コード整合性エンジンです。Windows 10 では、コード整合性が完全に構成できるようになり、分離ユーザー モード (仮想化ベースのセキュリティで保護されるメモリの一部) に存在するようになりました。
Device Guard の最後の構成要素は、管理機能です。コード整合性の構成は、特定のグループ ポリシー オブジェクト、PowerShell コマンドレット、MDM 構成サービス プロバイダー (CSP) を介して公開されます。
企業で Device Guard を展開する方法について詳しくは、「Device Guard 展開ガイド」をご覧ください。
Device Guard のシナリオ
既に説明したように、Device Guard はシステムをロックダウンする強力な方法です。Device Guard は、幅広い利用は想定されておらず、適用できない場合もありますが、いくつかの興味深いシナリオがあります。
Device Guard は便利で、レジ、キオスクの機器、セキュリティで保護された管理ワークステーション (SAW)、適切に管理されたデスクトップなど、ワークロードが固定されたシステムに適用できます。Device Guard は、実行する必要があるものの、あまりに頻繁に変更されない、非常に明確に定義されたソフトウェアが存在するシステムに非常に適しています。また、実行する必要があるものを把握しており、一連のアプリケーションが毎日変更されることがない限り、SAW にとどまらずにインフォメーション ワーカー (IW) も保護できます。
SAW は、セキュリティ リスクの中でも特にマルウェア、フィッシング攻撃、偽の Web サイト、PtH 攻撃によるセキュリティ侵害のリスクを大幅に軽減するために構築されたコンピューターです。SAW はそうした攻撃に対する "特効薬" となるセキュリティ ソリューションというわけではありませんが、この種のクライアントはセキュリティに対する多層防御手法の一端として役に立ちます。
価値の高い資産を保護するには、SAW を使って、それらの資産へのセキュリティで保護された接続を確立します。
また、System Center Configuration Manager、Intune、サード パーティのデバイス管理などの配布ツールを使ってアプリケーションがインストールされる企業の完全に管理されたワークステーションでは、Device Guard は非常に有用です。このようなシナリオでは、組織はユーザーが通常実行するソフトウェアを十分に把握してます。
ユーザーが自分でソフトウェアをインストールすることが普通に許可されている企業の緩やかに管理されたワークステーションで Device Guard を利用するのは難しい場合があります。柔軟性に優れた組織では、Device Guard を実施モードで実行するのは非常に困難です。ただし、監査モードで実行することはできます。その場合は、Device Guard ポリシーに違反したバイナリがイベント ログに記録されます。Device Guard を監査モードで使うと、組織は、ユーザーがインストールして実行するドライバーやアプリケーションに関する豊富なデータを入手できます。
Device Guard に含まれる保護を使う前に、Microsoft が提供するツールを使ってコード整合性ポリシーを作成する必要があります。ただし、このポリシーは、グループ ポリシーなど、一般的な管理ツールを使って展開できます。コード整合性ポリシーは、Windows 10 のユーザー モードとカーネル モードの両方の構成設定と共に、Windows 10 スクリプト ホストの制限を含む、バイナリ形式でエンコードされた XML ドキュメントです。Device Guard のコード整合性ポリシーにより、デバイスで実行できるコードが制限されます。
注
Device Guard ポリシーは Windows 10 で署名できるため、このポリシーの変更や削除を行う管理ユーザーに対する詳細な保護が追加されます。
署名された Device Guard ポリシーは、Device Guard を攻略しようとする悪意のあるローカル管理者に対する強力な保護を提供します。
ポリシーが署名されている場合は、改ざんから保護する UEFI の Pre-OS セキュア変数にポリシーの GUID が保存されます。Device Guard ポリシーを後で更新するには、同じ署名者か、Device Guard ポリシーの一部として UpdateSigner セクションに指定した署名者が署名した新しいバージョンのポリシーを提供するしかありません。
アプリケーションの署名の重要性
マイクロソフトは、Device Guard に対応したコンピューターでは、署名されていないアプリが制限なく実行できる世界から、署名され、信頼されたコードだけが Windows 10 で実行を許可される世界に移行することを提案しています。
Windows 10 では、組織は、Windows ストア インフラストラクチャを利用して、組織のメンバーが基幹業務 (LOB) アプリを利用できるようにします。具体的には、LOB アプリはパブリックな Windows ストア内のプライベート ストアから入手できます。Windows ストアでは、ユニバーサル Windows アプリと従来の Windows アプリに署名して配布します。Windows ストアからダウンロードしたアプリはすべて署名されています。
現在の組織では、LOB アプリケーションの大部分が署名されていません。コード署名は、コード署名の専門知識がないなどのさまざまな理由から、解決の難しい問題と思われることがよくあります。コード署名をお勧めしているものの、内部アプリケーションの多くは署名されていません。
Windows 10 に含まれているツールを使って、IT 担当者は、既にパッケージ化されているアプリケーションに対して、既存のアプリケーションと共に配布できる追加の署名を作成するプロセスを実行できます。
マルウェア対策ソリューションやデバイス管理ソリューションが依然として必要な理由
許可リスト メカニズムは信頼されているアプリケーションのみを確実に実行できるという点で非常に効率的ですが、既知の脆弱性を悪用するように設計された悪意のあるコンテンツによる、信頼されている (が、脆弱な) アプリケーションのセキュリティ侵害を防ぐことはできません。Device Guard では、脆弱性を悪用して実行されたユーザー モードの悪意のあるコードからは保護されません。
脆弱性とは、攻撃者がデバイスの整合性、利用可能性、機密性を侵害できる可能性があるソフトウェアの欠点のことです。最悪の場合、脆弱性により、ユーザーの知らないうちに攻撃者が悪意のあるコードを実行して侵害したデバイスを悪用することができます。
攻撃者が Web ブラウザー (とそのプラグイン)、Java 仮想マシン、PDF リーダー、ドキュメント エディターなどのユーザー モード ソフトウェアの既知の脆弱性を悪用するために特別に作ったコンテンツを配布することはよくあります。現在、発見された脆弱性の 90% は、ユーザー モード アプリケーションをホストするオペレーティング システムやカーネル モード ドライバーよりも、それらのアプリケーションに影響します。
これらの脅威の対応策として、補完的な防御層を形成するマルウェア対策ソフトウェアと合わせて、修正プログラムを適用することが唯一の最も効果的な制御です。
ほとんどのアプリケーション ソフトウェアは、更新自体が簡単ではありません。ソフトウェア ベンダーが脆弱性を修正する更新プログラムを公開しても、ユーザーは更新プログラムがあることやその入手方法がわからないため、攻撃に対して脆弱なままになることがあります。組織は、依然として、デバイスを管理し、脆弱性に対する修正プログラムを適用する必要があります。
MDM ソリューションは、軽量のデバイス管理テクノロジとして広く使われるようになってきています。Windows 10 では、MDM で利用できるように管理機能を拡張しています。Windows 10 に追加された重要な機能の 1 つに、MDM が管理対象の登録済みデバイスから強力なデバイス正常性ステートメントを取得する機能があります。
デバイスの正常性の認証
デバイスの正常性の認証では、TPM 2.0 を活用して、デバイスの起動に使われる一連のソフトウェアの強力で検証可能な測定値を暗号化して提供します。
Windows 10 ベースのデバイスには、MDM ソフトウェアが Windows 正常性認証サービスと呼ばれるリモート認証サービスにアクセスできるようにする新しいパブリック API が導入されています。 正常性の認証結果と他の要素を使って、デバイスが正常であることが証明されたかどうかに応じて、ネットワーク、アプリ、サービスへのアクセスを許可または拒否できます。
デバイスの正常性の認証について詳しくは、「正常でない Windows 10 ベースのデバイスの検出」をご覧ください。
ハードウェア要件
次の表では、仮想化ベースのセキュリティ サービスと正常性認証機能の両方のハードウェア要件について説明します。詳しくは、「最小ハードウェア要件」をご覧ください。
| ハードウェア | 利点 |
|---|---|
セキュア ブートが有効な UEFI 2.3.1 以降のファームウェア |
UEFI セキュア ブートをサポートするために必要です。 UEFI セキュア ブートにより、承認されたコードのみがデバイスで起動されます。 さらに、Windows 10 システムのハードウェア互換性仕様の「System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby」サブセクションの要件に従って、ブート整合性 (プラットフォームのセキュア ブート) をサポートする必要があります。 |
仮想化拡張機能 (Intel VT-x、AMD-V など)。SLAT を有効にする必要があります |
仮想化ベースのセキュリティをサポートするために必要です。 注仮想化ベースのセキュリティを使わなくても、Device Guard を有効にできます。 |
X64 プロセッサ |
Windows ハイパーバイザーを使う仮想化ベースのセキュリティをサポートするために必要です。Hyper-V は、x64 プロセッサでのみサポートされます (x86 ではサポートされません)。 ダイレクト メモリ アクセス (DMA) 保護を有効にして追加のメモリ保護を実施できますが、DMA 保護には DMA 保護テクノロジを備えているプロセッサが必要です。 |
IOMMU (Intel VT-d、AMD-Vi など) |
Windows 10 では、IOMMU のサポートによって、DMA 攻撃からのシステムの回復性を強化します。 |
トラステッド プラットフォーム モジュール (TPM) 2.0 |
正常性の認証のサポートと仮想化ベースのセキュリティの追加のキー保護のために必要です。 |
このセクションでは、Windows 10 に密接に関連したさまざまな制御に関する情報を示しました。多層防御と詳細アプローチは、ブート シーケンス中に低レベルのマルウェアを駆除するのに役立ちます。仮想化ベースのセキュリティは、新しいセキュリティ境界を追加するオペレーティング システム アーキテクチャの抜本的な変更です。Device Guard と Credential Guard はそれぞれ、信頼されていないコードをブロックし、企業のドメイン資格情報を盗難や再利用から保護します。このセクションでは、デバイスの管理と脆弱性に対する修正プログラムの適用の重要性についても簡単に説明しました。これらテクノロジをすべて利用することで、デバイスのセキュリティ強化やロックダウンを行い、攻撃者がデバイスのセキュリティを侵害するリスクを抑えることができます。
正常でない Windows 10 ベースのデバイスの検出
現在、多くの組織では、オペレーティング システムが適切な状態で、正しく構成され、セキュリティ保護が有効になっていることなどを確認するさまざまなチェックにパスすれば、デバイスが企業のポリシーに準拠していると見なしています。 しかし、残念ながら、現在のシステムでは、マルウェアがシステム正常性に関するソフトウェア ステートメントを偽装できるため、この種のレポートはまったく信頼できません。ルートキットなどの低レベルの悪質なコードは、従来のコンプライアンス ツールに偽の正常性状態をレポートできます。
ルートキットの最も大きな問題は、クライアントがルートキットを検出できないことです。ルートキットは、マルウェア対策の前に起動し、システム レベルの特権を持っているため、自身を完全に偽装しながら、システム リソースへのアクセスを続けることができます。この結果、ルートキットに感染している従来のコンピューターは、マルウェア対策が稼働していても、正常に見えます。
既に説明したように、Windows 10 の正常性の認証機能では、TPM 2.0 ハードウェア コンポーネントを使って、ブート関連のすべてのコンポーネント (ファームウェア、Windows 10 カーネル、初期ブート ドライバーなど) の測定値を安全に記録します。正常性の認証では TPM のハードウェア ベースのセキュリティ機能を利用するため、測定されたすべてのブート コンポーネントのログはマルウェアの手の届かない場所に格納されます。
トラスト ブート状態を証明することで、デバイスは後で準拠チェックを偽装する可能性のある低レベルのマルウェアを実行していないことを証明できます。TPM ベースの正常性の認証は、価値の高いデータが含まれる資産の信頼性を確実に確保します。
デバイスの正常性の概念について
デバイスの正常性という概念を理解するには、IT 担当者がマルウェアによる侵害を防ぐために実施していた従来の対策を知ることが重要です。マルウェア制御テクノロジは、インストールと配布の防止に重点を置いています。
しかし、マルウェア対策ソリューションや修正プログラムの適用などの従来のマルウェア防止テクノロジを利用すると、組織のリソースにアクセスするデバイスの準拠の監視と制御という一連の新たな問題が IT 担当者に降りかかります。
デバイスの準拠の定義は、組織がインストールしたマルウェア対策、デバイス構成の設定、修正プログラム管理のベースラインなどのセキュリティ要件によって異なります。 ただし、デバイスの正常性はデバイスの準拠ポリシー全体にかかわります。
デバイスの正常性は、2 進法ではなく、組織のセキュリティの実装によって異なります。正常性認証サービスは、信頼できるハードウェア TPM を利用して、デバイスの起動時に有効になっているセキュリティ機能に関する情報を MDM に返します。
ただし、正常性の認証は情報を返すだけなので、MDM ソリューションが判断して実行に移す必要があります。
リモート デバイスの正常性の認証
Windows 10 では、正常性の認証とは、ブート プロセス中に生成されたメジャー ブート データをマイクロソフトが運営するリモート デバイスの正常性認証サービスに送る機能を指します。
これは、Windows 10 ベースのデバイスでセキュリティ防御がダウンしたことを検出するのに利用できる最も安全な方法です。ブート プロセス中に、TCG ログと PCR 値がリモートの Microsoft クラウド サービスに送られます。その後、正常性認証サービスによってログがチェックされ、デバイスに加えられた変更が確認されます。
MDM などの証明書利用者は、リモートの正常性認証サービスによって生成されたレポートを確認できます。
注
Windows 10 の正常性認証機能を使うには、デバイスにディスクリートまたはファームウェアの TPM 2.0 が搭載されている必要があります。Windows 10 の特定のエディションに対する制限はありません。
Windows 10 では、基になる正常性認証構成サービス プロバイダー (CSP) へのアクセスをアプリケーションに許可して、アプリケーションが正常性認証トークンを要求できるようにすることで、正常性の認証シナリオをサポートしています。マルウェア対策や MDM エージェントは、ブート シーケンスの測定値をローカルでいつでも確認できます。
リモート デバイスの正常性認証を MDM と組み合わせることで、システムで実行されているソフトウェアを信頼することなく、現在のセキュリティ状態をレポートし、変更を検出するハードウェア ベースの方法を実現します。
デバイスで悪意のあるコードが実行されている場合は、リモート サーバーを使う必要があります。 ルートキットがデバイス上に存在する場合、マルウェア対策は信頼できず、スタートアップ シーケンスの初期段階に実行される悪意のあるコードによってハイジャックされている可能性があります。そのため、セキュア ブートと Device Guard を使って、ブート シーケンス中に読み込まれるコードを制御することが重要です。
マルウェア対策ソフトウェアは、ルートキットなどのマルウェアの兆候がブート シーケンスに含まれているかどうかを検索して調べることができます。また、TCG ログと PCR をリモートの正常性認証サーバーに送って、測定コンポーネントと検証コンポーネントを分けることもできます。
正常性の認証では、ブート プロセス中に、さまざまな TPM プラットフォーム構成レジスタ (PCR) の測定値と TCG ログを記録します。
.png "図 6")
TPM が搭載されているデバイスを起動すると、さまざまなコンポーネントの測定が実行されます。これには、ファームウェア、UEFI ドライバー、CPU のマイクロコードに加え、Windows 10 のすべてのブート開始ドライバーも含まれます。未処理の測定値は TPM PCR レジスタに格納され、すべてのイベントの詳細 (実行可能ファイルのパスや機関の証明書など) は TCG ログで確認できます。
.png "図 7")
正常性の認証プロセスは次のとおりです。
ハードウェアのブート コンポーネントが測定されます。
オペレーティング システムのブート コンポーネントが測定されます。
Device Guard が有効な場合、現在の Device Guard ポリシーが測定されます。
Windows カーネルが測定されます。
最初のカーネル モード ドライバーとしてウイルス対策ソフトウェアが開始されます。
ブート開始ドライバーが測定されます。
MDM サーバーが、正常性認証 CSP を利用し、MDM エージェントを介して正常性チェック コマンドを発行します。
ブートの測定値が正常性認証サービスによって検証されます。
注
既定では、最新の 100 個のシステム ブート ログと、関連するすべての再開ログが %SystemRoot%\logs\measuredboot フォルダーにアーカイブされます。
保持するログの数は、レジストリの HKLM\SYSTEM\CurrentControlSet\Services\TPM キーにある REG_DWORD 値の PlatformLogRetention で設定できます。値 0 を指定すると、ログのアーカイブがオフになります。値 0xffffffff を指定すると、すべてのログが保持されます。
次のプロセスでは、正常性ブートの測定値を正常性認証サービスに送る方法について説明します。
クライアント (TPM 2.0 を搭載した Windows 10 ベースのデバイス) がリモート デバイスの正常性認証サービスに対して要求を開始します。正常性認証サーバーは Microsoft クラウド サービスであると想定されているため、クライアントでは既に URI があらかじめプロビジョニングされています。
次に、クライアントが TCG ログ、AIK で署名されたデータ (PCR 値、ブート カウンター)、AIK 証明書情報を送ります。
リモート デバイスの正常性認証サービスが次の処理を実行します。
AIK 証明書が既知の信頼された CA によって発行されており、証明書が有効で、失効していないことを確認します。
PCR クォートの署名が正しく、TCG ログの値と一致することを確認します。
TCG ログのプロパティを解析します。
正常性に関する情報、AIK に関する情報、ブート カウンター情報を含むデバイス正常性トークンを発行します。正常性トークンには、有効な発行時刻も含まれます。デバイス正常性トークンは暗号化され、署名されます。それにより、情報が保護され、発行元の正常性認証サービスのみがアクセスできるようになります。
クライアントがローカル ストアに正常性暗号化 BLOB を格納します。デバイス正常性トークンには、デバイスの正常性状態、デバイス ID (Windows AIK)、ブート カウンターが含まれています。
.png "図 8")
デバイスの正常性の認証コンポーネント
デバイスの正常性認証ソリューションには、TPM、正常性認証 CSP、Windows 正常性認証サービスという複数のコンポーネントが必要です。このセクションでは、それらのコンポーネントについて説明します。
トラステッド プラットフォーム モジュール
*最も重要なのは TPM 2.0 と保証証明書です。*このセクションでは、正常性の認証レポートに PCR (システム構成データを含む)、保証キー (EK) (TPM の身分証明書として機能する)、SRK (キーを保護する)、AIK (プラットフォームの状態をレポートできる) がどのように使われるかについて説明します。
わかりやすく説明すると、TPM はリソースの限られたパッシブ コンポーネントです。乱数と RSA キーを計算し、短いデータを暗号化解除して、デバイスの起動時に取得したハッシュを格納できます。
TPM は、以下を 1 つのコンポーネントにまとめたものです。
RSA 2048 ビット キー ジェネレーター
乱数ジェネレーター
EK、SRK、AIK キーを格納する不揮発性メモリ
暗号化、暗号化解除、署名を行う暗号化エンジン
PCR と RSA キーを格納する不揮発性メモリ
保証キー
TPM には、保証キーと呼ばれる一意の暗号化キーが埋め込まれています。TPM 保証キーは、非対称キーのペアです (RSA サイズ 2048 ビット)。
保証キーの公開キーは、通常、所有者パスワードの定義ハッシュを含む TPM の所有権を得る場合など、機密性の高いパラメーターを安全に送るために使われます。EK の秘密キーは、AIK などのセカンダリ キーを作成する際に使われます。
保証キーは、TPM の身分証明書として機能します。詳しくは、「TPM 保証キーについて」をご覧ください。
保証キーには、多くの場合、1 つまたは 2 つのデジタル証明書が付属します。
1 つの証明書は、TPM の製造元によって作成され、保証証明書と呼ばれます。保証証明書は、ローカル プロセス、アプリケーション、クラウド サービスに対して TPM の信頼性 (たとえば、特定のチップ メーカーによって製造された本物の TPM であること) を証明するために使われます。保証証明書は、製造時、またはオンライン サービスと通信して TPM を初めて初期化するときに作成されます。
もう 1 つの証明書は、プラットフォーム ビルダーによって作成され、プラットフォーム証明書と呼ばれます。この証明書は、特定の TPM が特定のデバイスに統合されていることを示します。
Intel または Qualcomm によって製造されたファームウェア ベースの TPM を搭載した特定のデバイスでは、Windows 10 の 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 10 では、保証証明書に基づいた派生認証アンカーを発行します。保証キーを証明できるこの中間キーが認証 ID キー (AIK) です。対応する証明書は、AIK 証明書と呼ばれます。この AIK 証明書は、Microsoft クラウド サービスによって発行されます。
注
デバイスが TPM 2.0 の認証機能を使って正常性をレポートするには、その前に Microsoft クラウド CA サービスなどのサード パーティのサービスと協力して AIK 証明書をプロビジョニングする必要があります。 プロビジョニングが済むと、AIK 秘密キーを使って、プラットフォームの構成をレポートできるようになります。Windows 10 では、起動のたびに AIK を使ってプラットフォームのログ状態 (と単調カウンター値) の署名を作成します。
AIK は、プライバシー保護のために、TPM の ID として EK の代わりに使われる非対称 (公開/秘密) キー ペアです。AIK の秘密部分は、公開されることや TPM の外部で使われることはなく、TPM 内で限られた操作にだけ使うことができます。具体的には、署名と、TPM によって定義された限られた操作にだけ使うことができます。
Windows 10 では、TPM によって保護された AIK を作成します。可能であれば、AIK は 2048 ビットの RSA 署名キーになります。マイクロソフトでは、本物の TPM と通信しており、提示された AIK を TPM が所有していることを暗号を使って確認するために、Microsoft クラウド CA と呼ばれるクラウド サービスをホストしています。Microsoft クラウド CA サービスでは、これらの確認が取れると、Windows 10 ベースのデバイスに AIK 証明書を発行します。
Windows 10 にアップグレードする既存のデバイスの多くは、TPM がないか、TPM に保証証明書が含まれていません。**これらのデバイスに対応するために、Windows 10 では、保証証明書がなくても、AIK 証明書を発行できます。**そうした AIK 証明書は、Microsoft クラウド CA によって発行されたものではありません。この証明書は、製造時にデバイスに書き込まれた保証証明書ほどの信頼性はありませんが、TPM がない場合の Microsoft Passport などの高度なシナリオとの互換性は確保されます。
発行された AIK 証明書には、認証プロセス中に保証証明書が使われたことを証明するために特別な OID が追加されます。証明書利用者は、この情報を利用して、保証証明書なしで AIK 証明書を使って証明されたデバイスを拒否するか承諾するかを決めることができます。また、保証証明書なしで AIK 証明書によって証明されたデバイスから価値の高い資産へのアクセスを許可しないこともできます。
ストレージ ルート キー
ストレージ ルート キー (SRK) も非対称キー ペアです (最小 2048 ビットの長さの RSA)。SRK には重要な役割があり、TPM キーの保護に使われます。TPM がない場合は、これらのキーを使うことはできません。TPM の所有権を取得すると、SRK キーが作成されます。
プラットフォーム構成レジスタ
TPM には、起動したシステムの状態とソフトウェアの暗号化表現を提供するために設計された一連のレジスタがあります。これらのレジスタは、プラットフォーム構成レジスタ (PCR) と呼ばれます。
ブート シーケンスの測定値は、PCR と TCG ログに基づいています。静的な信頼のルートを確立するために、デバイスが起動するときに、ファームウェア コードを実行前に測定できる必要があります。この場合、コアの信頼性測定のルート (CRTM) がブートから実行され、ファームウェアのハッシュを計算します。その後、レジスタ PCR[0] を拡張してそのハッシュを保存し、実行をファームウェアに転送します。
PCR は、プラットフォームの起動時に 0 に設定されます。ブート チェーンのコンポーネントを測定し、PCR に測定値を記録するのは、プラットフォームを起動するファームウェアの役割です。通常、ブート コンポーネントが、実行される次のコンポーネントのハッシュを受け取り、PCR に測定値を記録します。測定チェーンを開始する最初のコンポーネントは、暗黙的に信頼されます。これが CRTM です。プラットフォームの製造元は、CRTM のセキュリティで保護された更新プロセスを用意するか、CRTM の更新を許可しない必要があります。 PCR には、測定されたコンポーネントの累積的なハッシュが記録されます。
PCR の値はそのままでは解釈することが困難です (ただのハッシュ値です) が、プラットフォームでは、通常、測定したコンポーネントの詳細をログに保持しており、PCR はログが改ざんされていないことを確認するためだけに存在します。このログは、TCG ログと呼ばれます。PCR レジスタが拡張されるたびに、TCG ログにエントリが追加されます。つまり、ブート プロセス全体の実行可能コードと構成データのトレースが TCG ログに作成されます。
TPM のプロビジョニング
Windows 10 ベースのデバイスで TPM を利用できる場合は、まず TPM をプロビジョニングする必要があります。プロビジョニング プロセスは TPM のバージョンによって若干異なりますが、正常に完了すると、TPM が利用可能になり、TPM の所有者認証データ (ownerAuth) がレジストリにローカルに格納されます。
TPM をプロビジョニングすると、Windows 10 はまずレジストリの次の場所を調べて、EK とローカルに格納された ownerAuth 値を確認します。HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement
プロビジョニング プロセス中に、デバイスを再起動することが必要な場合があります。
管理者権限で Get-TpmEndorsementKeyInfo PowerShell コマンドレットを使うと、TPM の保証キーと証明書に関する情報を取得できます。
TPM の所有権が不明だが、EK が存在する場合は、クライアント ライブラリによって、TPM がプロビジョニングされます。さらに、ポリシーで SRK の公開部分を次の場所に格納することが許可されている場合は、生成された ownerAuth 値がレジストリに格納されます。HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub
プロビジョニング プロセスの一環として、TPM を使って AIK が作成されます。この操作が実行されると、生成された AIK の公開部分がレジストリの次の場所に格納されます。HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub
注
インターネット アクセスをフィルター処理している場合は、AIK 証明書をプロビジョニングするために、次のワイルドカード URL を承認する必要があります。https://*.microsoftaik.azure.net
Windows 10 の正常性認証 CSP
Windows 10 には、正常性認証機能の操作に特化した構成サービス プロバイダー (CSP) が用意されています。CSP は、Windows MDM クライアントに組み込まれているコンポーネントで、MDM サーバーで設定の構成と Windows ベースのデバイスの管理を行う方法に関するプロトコルを公開します。管理プロトコルは、"get"、"set"、"delete" など、URI に対して実行する関数を URI に含めて指定できるツリー構造体として表されます。
Windows 10 の正常性認証 CSP で実行できる操作の一覧を次に示します。
デバイスの正常性状態を確認するために使うデータを収集する
そのデータを正常性認証サービスに転送する
正常性認証サービスから受け取った正常性認証証明書をプロビジョニングする
要求時に、(正常性認証サービスから受け取った) 正常性認証証明書と、関連するランタイム情報を検証のために MDM サーバーに転送します。
正常性認証セッション中に、正常性認証 CSP は、正常性認証サービスへのセキュリティで保護された通信チャネルを使って、起動時に測定した PCR 値と TCG ログを転送します。
MDM サーバーは、デバイスが正常性認証サービスに対して証明されたことを検証する際に、デバイスが正常性を証明してから MDM サーバーが検証するまでの間に再起動しなかったという保証として、そのデバイスがどうのように起動したかに関する一連のステートメントと信頼性情報を受け取ります。
Windows 正常性認証サービス
Windows 正常性認証サービスの役割は、基本的に、一連の正常性データ (TCG ログと PCR 値) を評価し、(利用可能な正常性データに基づいて) 一連の検出を実行して、暗号化された正常性 BLOB を生成したり、MDM サーバーへのレポートを生成したりすることです。
注
デバイスと MDM サーバーは、どちらもポート 443 (HTTPS) で TCP プロトコルを使って has.spserv.microsoft.com にアクセスできる必要があります。
TPM 認証と、関連するログが有効かどうかは、次の手順でチェックされます。
まず、レポートが信頼できる AIK で署名されていることをサーバーがチェックする必要があります。これは、AIK の公開部分が資産のデータベースに含まれていることや、証明書が確認されていることなどをチェックすることで行われます。
キーをチェックしたら、署名された構成証明 (クォート構造体) をチェックして、PCR 値の有効な署名かどうかを確認します。
次に、ログをチェックして、レポートされた PCR 値と一致することを確認します。
最後に、MDM ソリューションがログ自体を調べて、既知または有効なセキュリティ構成を表しているかどうかを確認します。たとえば、簡単なチェックでは、測定された初期 OS コンポーネントが正常かどうか、ELAM ドライバーが想定どおりであること、ELAM ドライバーのポリシー ファイルが最新であることなどを確認します。これらのチェックにすべてパスすると、後でクライアントにリソースへのアクセスを許可するかどうかを決めるために利用できる構成証明ステートメントを発行できます。
正常性認証サービスは、デバイスの正常性に関する次の情報を MDM ソリューションに渡します。
セキュア ブートの有効化
ブート デバッグとカーネル デバッグの有効化
BitLocker の有効化
VSM が有効
署名済みまたは未署名の Device Guard コード整合性ポリシーの測定値
ELAM が読み込まれた
セーフ モードでの起動、DEP の有効化、テスト署名の有効化
デバイスの TPM が信頼できる保証証明書でプロビジョニングされている
測定値について詳しくは、「正常性認証 CSP」をご覧ください。
次の表には、Windows 10 ベースのデバイスの種類ごとに、MDM にレポートできる主な項目をいくつかを示しています。
| OS の種類 | レポートできる主な項目 |
|---|---|
Windows 10 Mobile |
|
Windows 10 デスクトップ エディション |
|
MDM と正常性認証サービスの利用
デバイスの正常性を利用するには、MDM ソリューションでデバイスの正常性レポートを評価し、組織のデバイスの正常性要件に合わせて MDM ソリューションを構成します。
MDM と正常性認証サービスを活用するソリューションは、主に次の 3 つで構成されます。
正常性の認証が有効になっているデバイス。これは通常、MDM プロバイダーへの登録の一環として行われます (正常性の認証は既定で無効になります)。
有効になると、それ以降の起動のたびに、デバイスは Microsoft がホストする正常性認証サービスに正常性の測定値を送り、正常性の認証 BLOB を受け取ります。
この後はいつでも、MDM サーバーはデバイスに正常性認証 BLOB を要求し、正常性認証サービスにコンテンツの暗号化解除と証明されているかどうかの検証を要求できます。
.png "図 9")
Windows 10 ベースのデバイス、正常性認証サービス、MDM の間のやり取りは、次のように行われます。
クライアントが MDM サーバーとのセッションを開始します。MDM サーバーの URI は、要求を開始するクライアント アプリに含まれています。この時点で MDM サーバーは、適切な CSP URI を使って、正常性認証データを要求できます。
MDM サーバーは、要求と共に nonce を指定します。
その後、クライアントが AIK でクォートされた nonce に加え、ブート カウンターと正常性 BLOB 情報を送ります。この正常性 BLOB は、正常性認証サービスだけが暗号化解除できる正常性認証サービスの公開キーで暗号化されます。
MDM サーバーが次の処理を実行します。
nonce が予想どおりであることを確認します。
正常性認証サービス サーバーにクォートされたデータ、nonce、暗号化された正常性 BLOB を渡します。
正常性認証サービスが次の処理を実行します。
正常性 BLOB の暗号化を解除します。
正常性 BLOB の AIK を使ってクォートのブート カウンターが正しく、正常性 BLOB の値と一致することを確認します。
クォートの nonce と MDM から渡された nonce が一致することを確認します。
ブート カウンターと nonce は正常性 BLOB の AIK でクォートされているため、デバイスが正常性 BLOB が生成されたデバイスと同じであることも証明されます。
正常性のパラメーターや鮮度などのデータを MDM サーバーに送り返します。
注
MDM サーバー (証明書利用者) がクォートやブート カウンターの検証自体を実行することはありません。MDM サーバーは、クォートされたデータと正常性 BLOB (暗号化済み) を取得し、データを検証のために正常性認証サービスに送ります。そのため、AIK が MDM に公開されることはありません。このようにして、プライバシーに関する問題に対処しています。
正常性要件と準拠要件を満たしていない登録済みのデバイスが MDM ソリューションによって確実に検出、追跡、対処されるようにする第一歩は、デバイスの準拠要件を設定することです。
正常でないデバイスや準拠していないデバイスを検出してレポートできるように、リソースに接続しようとするデバイスの正常性を評価する必要があります。完全に効率化するには、エンド ツー エンドのセキュリティ ソリューションにより、正常でないデバイスに対して、価値の高い資産へのアクセスを拒否するなどの措置を取る必要があります。それが条件付きアクセス制御の目的です。これについては、次のセクションで詳しく説明します。
アクセスを許可する前の Windows 10 ベースのデバイスのセキュリティの制御
現在のアクセス制御テクノロジは、ほとんどの場合、適切なユーザーが適切なリソースにアクセスできるようにすることに重点を置いています。ユーザーは、認証されれば、組織の IT スタッフやシステムがほとんど把握していないデバイスを使って、リソースにアクセスできます。メールにアクセスする前にデバイスが暗号化されていることを確認するなどのチェックは行っているかもしれませんが、デバイスがマルウェアに感染していた場合はどうなるでしょうか。
リモート デバイスの正常性の認証プロセスでは、ブート データを測定して、デバイスの正常性状態を確認します。デバイスの正常性は、その後、Intune などの MDM ソリューションで利用できます。
注
Intune と Windows 10 の機能のサポートの最新情報については、Microsoft Intune ブログと「Microsoft Intune の新機能」をご覧ください。
次の図には、正常性認証サービスが Microsoft のクラウド ベースの Intune MDM サービスとどのように連携するかを示しています。
.png "図 10")
MDM ソリューションは、正常性状態ステートメントを活用し、クライアント ポリシーと組み合わせて次のレベルに渡すことができます。それによって、マルウェアに感染しておらず、マルウェア対策システムが機能し、最新の状態に保たれており、ファイアウォールが実行され、デバイスの更新プログラムの状態が準拠していることをデバイスが証明できるかどうかに応じて許可する条件付きアクセスを実現します。
最後に、正常であることを証明できないエンドポイントに対してはアクセスを拒否することで、リソースを保護できます。この機能は、特に、組織のリソースにアクセスする必要がある BYOD デバイスに必要です。
Windows 10 での MDM の組み込みサポート
Windows 10 には、オペレーティング システムの一部として MDM クライアントが付属しています。そのため、別途エージェントを用意しなくても、MDM サーバーで Windows 10 ベースのデバイスを管理できます。
サード パーティの MDM サーバーのサポート
サード パーティの MDM サーバーで MDM プロトコルを使って Windows 10 を管理できます。組み込みの管理クライアントは、OMA-DM プロトコルをサポートする互換性のあるサーバーと通信して、エンタープライズ管理タスクを実行できます。詳しくは、「Azure Active Directory と MDM の統合」をご覧ください。
注
Windows 10 を管理するために、MDM サーバーでクライアントを作成したり、ダウンロードしたりする必要はありません。詳しくは、「モバイル デバイス管理」をご覧ください。
サード パーティの MDM サーバーでは、登録に関して同一で一貫性のあるファースト パーティのユーザー エクスペリエンスが提供されるため、Windows 10 ユーザーは簡単に利用することができます。
サード パーティの MDM による Windows Defender の管理
この管理インフラストラクチャにより、IT 担当者は、Intune など MDM 対応製品を使って、ドメインに参加していない BYOD を含め、Windows 10 ベースのデバイスで正常性の認証、Device Guard、Windows Defender を管理できます。また、ダウンレベルのオペレーティング システムで Intune と Intune Endpoint Protection を使って、カスタマイズに慣れた操作と設定を管理、構成することもできます。現在はドメインに参加しているデバイスだけをグループ ポリシーで管理している管理者は、両方のメカニズムで設定と操作の多くが共通しているため、MDM を使った Windows 10 ベースのデバイスの管理に簡単に移行できます。
MDM ソリューションを使って Windows 10 のセキュリティとシステム設定を管理する方法について詳しくは、「Windows 10 デバイス用カスタム URI 設定」をご覧ください。
条件付きアクセス制御
ほとんどのプラットフォームでは、Azure Active Directory (Azure AD) デバイスの登録は MDM の登録時に自動的に行われます。デバイスの状態が MDM ソリューションによって Azure AD に書き込まれ、次回クライアントが Office 365 と互換性のあるワークロードにアクセスしようとしたときに Office 365 (または Azure AD とやり取りする承認済みの Windows アプリ) によって読み取られます。
デバイスが登録されていない場合は、登録方法に関する指示が含まれたメッセージが表示されます。デバイスが準拠していない場合は、準拠の問題とその解決方法に関する詳細情報を入手できる MDM Web ポータルにリダイレクトする別のメッセージが表示されます。
Azure AD がユーザーとデバイスを認証し、MDM が準拠と条件付きアクセス ポリシーを管理し、正常性認証サービスが構成証明された方法でデバイスの正常性についてレポートします。
.png "図 11")
Office 365 の条件付きアクセス制御
Azure AD は、Office 365 サービスへのアクセスをセキュリティで保護するために、条件付きアクセス ポリシーを適用します。テナントの管理者は、準拠していないデバイスのユーザーによる Office 365 サービスへのアクセスをブロックする条件付きアクセス ポリシーを作成できます。ユーザーは、サービスへのアクセスが許可されるには、会社のデバイス ポリシーに準拠する必要があります。また、管理者は、ユーザーがデバイスを登録するだけで Office 365 サービスにアクセスできるようにするポリシーを作成することもできます。ポリシーは、組織のすべてのユーザーに適用することや、一部のターゲット グループに限定し、徐々にターゲット グループを追加して拡張することができます。
ユーザーがサポートされているデバイス プラットフォームから Office 365 サービスへのアクセスを要求すると、Azure AD がユーザーとユーザーが要求を発行したデバイスを認証し、そのサービスに設定されているポリシーにユーザーが準拠している場合にのみ、サービスへのアクセスを許可します。デバイスが登録されていないユーザーには、企業の Office 365 サービスにアクセスするために登録し、準拠した状態になる方法に関する指示が与えられます。
ユーザーが登録すると、デバイスが Azure AD と、Intune などの互換性のある MDM ソリューションに登録されます。
注
マイクロソフトは、サード パーティの MDM ISV と協力して、自動化された MDM の登録とポリシー ベースのアクセス チェックのサポートに取り組んでいます。Azure AD と Intune への MDM の自動登録を有効にする手順については、Windows 10、Azure AD、Microsoft Intune のクラウドを利用した MDM の自動登録に関するブログの記事をご覧ください。
ユーザーがデバイスを正常に登録すると、デバイスは信頼済みになります。Azure AD は、社内アプリケーションにアクセスするためのシングル サインオンを提供し、ユーザーが初めてアクセスを要求したときと、ユーザーがアクセスの更新を要求するたびに、サービスへのアクセスを許可する条件付きアクセス ポリシーを適用します。
サインイン資格情報が変更された場合や、デバイスの紛失や盗難が生じた場合、更新の要求時に準拠ポリシーを満たしていない場合、ユーザーはサービスへのアクセスを拒否されます。
従業員が Exchange Online へのアクセスに使うメール アプリケーションの種類によって、メールへのセキュリティで保護されたアクセスを確立するための流れが若干異なる場合があります。ただし、主要なコンポーネントは同じく Azure AD、Office 365/Exchange Online、Intune です。IT エクスペリエンスとエンド ユーザー エクスペリエンスも似ています。
.png "図 12")
Office 365 にアクセスしようとするクライアントは、次の点について評価されます。
デバイスが MDM によって管理されているか?
デバイスが Azure AD に登録されているか?
デバイスが準拠しているか?
Windows 10 ベースのデバイスを準拠した状態にするには、次の操作を行う必要があります。
MDM ソリューションに登録します。
Azure AD に登録します。
MDM ソリューションによって設定されているデバイス ポリシーに準拠します。
注
現時点では、条件付きアクセス ポリシーは、iOS と Android デバイスのユーザーに選択的に適用されます。詳しくは、Azure AD、Microsoft Intune、Windows 10 のクラウドによる企業のモビリティの現代化に関するブログの記事をご覧ください。
クラウドとオンプレミスのアプリの条件付きアクセス制御
条件付きアクセス制御は、Azure AD に組み込まれている強力なポリシー評価エンジンです。これにより、IT 担当者は、Office 365 に限らず、ユーザーのログオン コンテキストを評価して、アクセスを許可するアプリケーションをリアルタイムに判断するアクセス規則を簡単に作成できます。
また、Azure AD によってセキュリティで保護されたクラウド SaaS アプリケーション用だけでなく、オンプレミスのアプリケーション用にも条件付きアクセス制御ポリシーを構成できます。Azure AD のアクセス規則では、条件付きアクセス エンジンを活用して、Intune などの互換性のある MDM ソリューションによってレポートされたデバイスの正常性と準拠状態をチェックし、アクセスを許可するかどうかを判断します。
条件付きアクセスについて詳しくは、「Azure Conditional Access Preview for SaaS Apps」をご覧ください。
注
条件付きアクセス制御は、EMS でも利用できる Azure AD Premium の機能です。Azure AD Premium サブスクリプションをお持ちでない場合は、Microsoft Azure のサイトから試用版を入手できます。
オンプレミスのアプリケーションについては、デバイスの準拠状態に基づいた条件付きアクセス制御を有効にする方法が 2 つあります。
Azure AD アプリケーション プロキシ経由で公開されているオンプレミスのアプリケーションの場合は、クラウド アプリケーションの場合と同じように条件付きアクセス制御ポリシーを構成できます。詳しくは、更新された Azure AD 条件付きアクセス プレビューでのオンプレミスとカスタムの LOB アプリのサポートに関するブログの投稿をご覧ください。
または、Azure AD Connect で Azure AD からオンプレミスの AD にデバイスの準拠情報を同期します。Windows Server Technical Preview 2016 の ADFS では、デバイスの準拠状態に基づいた条件付きアクセス制御をサポートします。IT 担当者は、オンプレミスのアプリケーションをセキュリティで保護するために、互換性のある MDM ソリューションによってレポートされたデバイスの準拠状態を利用する条件付きアクセス制御ポリシーを ADFS で構成します。
.png "図 13")
次のプロセスでは、Azure AD の条件付きアクセスのしくみを説明しています。
ユーザーは、既に社内アクセス/Azure AD Join によって MDM に登録され、デバイスが Azure AD に登録されています。
デバイスが起動するか、休止状態から再開すると、"Tpm-HASCertRetr" タスクがトリガーされ、バックグラウンドで正常性認証 BLOB を要求します。デバイスが TPM ブートの測定値を正常性認証サービスに送ります。
正常性認証サービスがデバイスの状態を検証し、正常性状態と失敗したチェックの詳細 (ある場合) に応じて、デバイスに暗号化 BLOB を発行します。
ユーザーがログオンし、MDM エージェントが Intune/MDM サーバーに接続します。
MDM サーバーが、利用可能な場合は新しいポリシーをプッシュし、正常性 BLOB の状態とその他のインベントリの状態を照会します。
デバイスが、前に取得した正常性認証 BLOB と、Intune/MDM サーバーによって要求されたその他の状態インベントリの値を送ります。
Intune/MDM サーバーが、正常性認証 BLOB を検証のために正常性認証サービスに送ります。
正常性認証サービスが、正常性認証 BLOB を送ったデバイスが正常であることを検証し、その結果を Intune/MDM サーバーに返します。
Intune/MDM サーバーが、デバイスの準拠状態と照会したインベントリ/正常性認証の状態に基づいて準拠しているかどうかを評価します。
Intune/MDM サーバーが、Azure AD のデバイス オブジェクトに対する準拠状態を更新します。
ユーザーがアプリを開き、企業が管理する資産にアクセスしようとします。
アクセスは、Azure AD のコンプライアンス請求によって制御されます。
デバイスが準拠しており、ユーザーが承認されている場合は、アクセス トークンが生成されます。
ユーザーが、企業が管理する資産にアクセスできます。
Azure AD Join について詳しくは、職場や学校に最適な Azure AD と Windows 10 に関するホワイト ペーパーをご覧ください。
条件付きアクセス制御は、多くの組織や IT 担当者が必要にもかかわらず把握していないことがあるトピックです。ユーザー、デバイス、準拠、アクセスのコンテキストを表すさまざまな属性を条件付きアクセス エンジンと組み合わせて使うと非常に強力です。条件付きアクセス制御は、組織の環境をセキュリティで保護するのに役立つ重要なステップです。
ポイントと概要
次の一覧には、組織のセキュリティ状態を強化するための重要なポイントの概要を示しています。ただし、このセクションに示したポイントがセキュリティのベスト プラクティスの包括的な一覧というわけではありません。
100% 安全なソリューションはないことを理解する
悪意のある攻撃者が本気でデバイスへの物理的アクセス権を取得した場合、最終的にセキュリティ層を突破して、制御できます。
正常性の認証と MDM ソリューションを使う
正常でないデバイスや準拠していないデバイスを検出、レポートし、最終的にブロックできるように、価値の高い資産に接続しようとするデバイスの正常性を評価する必要があります。
Credential Guard を使う
Credential Guard は、pass-the-hash 攻撃から企業のドメイン資格情報を保護するのに大いに役立つ機能です。
Device Guard を使う
Device Guard は、セキュリティを実際に強化し、マルウェアからの保護に役立つ効果的な方法です。Windows 10 の新しい 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 は Device Guard の新機能というわけではありませんが、特定のユーザーまたはユーザー グループに対して特定のユニバーサル Windows アプリを拒否できるなど、一部のシナリオで Device Guard の機能を補完します。
ファームウェアと構成をロックダウンする
Windows 10 のインストール後に、ファームウェア ブート オプションのアクセスをロックダウンします。これにより、ユーザーが物理的にアクセスして、UEFI 設定の変更、セキュア ブートの無効化、他のオペレーティング システムの起動を行うことができなくなります。 また、Device Guard を無効にしようとする管理者から保護するために、C:\Windows\System32\SecConfig.efi ツールの実行を拒否してブロックする規則を現在の Device Guard ポリシーに追加します。
正常性の認証は、ユーザーとデバイスの ID に加え、コーポレート ガバナンス ポリシーへの準拠状態に基づいて価値の高い資産へのアクセスを制御する、クライアントとクラウドのコンポーネントを対象にした Windows 10 の重要な機能です。組織では、正常でないデバイスを検出してレポートするか、ニーズに基づいて正常性の実施規則を構成するかを選ぶことができます。正常性の認証では、エンド ツー エンドのセキュリティ モデルと統合ポイントが提供されます。ベンダーやソフトウェア開発者は、それらを利用して、カスタマイズしたソリューションを作成し、統合できます。