次の方法で共有

Data Encryption Toolkit for Mobile PCs : 計画および実装ガイド

第 1 章 : 計画に際しての考慮事項

公開日: 2007年9月14日

組織のデータを保護するためにデータ暗号化ツールを展開する場合、その組織の環境に特有のセキュリティ上の懸案事項はもとより、Microsoft オペレーティング システムに含まれる数々のテクノロジについても徹底的に理解する必要があります。また、クライアント ハードウェアの選択とその構成、組織のセキュリティ ポリシー、法規制準拠や監査のような複雑な問題など、展開プロセスに関連する潜在的な問題を特定してこれを解決する準備を整える必要があります。

『計画および実装ガイド』のこの章では、Windows Vista™ を Microsoft® BitLocker™ ドライブ暗号化 (以下「BitLocker」) および暗号化ファイル システム (以下「EFS」) (Windows Vista および Microsoft Windows® XP のコンポーネント) と共に展開する計画を立てる場合に必要な考慮事項に重点を置いて説明します。

この章で説明する、BitLocker と EFS の計画を立てる際の考慮事項の中には、ハードウェアおよびソフトウェアの要件、保護を必要とするコンピュータとデータ項目の決定方法、適切な構成の選択方法などが含まれます。その他の考慮事項として、Active Directory® ディレクトリ サービスとグループ ポリシーの展開の問題、管理性、利便性、効果的なデータ回復計画などがあります。

EFS の場合はさらに、EFS と既存の公開キー基盤 (以下「PKI」) との統合、Microsoft 暗号化ファイル システム アシスタント (以下「EFS アシスタント) の展開、および効果的なキー回復計画などの考慮事項もあります。

トピック

BitLocker ドライブ暗号化の計画
暗号化ファイル システムの計画
関連情報

BitLocker ドライブ暗号化の計画

BitLocker の展開計画を完了するには、次の手順を実行する必要があります。

  1. BitLocker の展開オプションについて理解する

  2. BitLocker を使用するための準備状況を評価する

  3. BitLocker の展開範囲を決定する

  4. BitLocker の構成を選択する

  5. データ回復計画を策定する

  6. 管理性に関する計画を策定する

  7. 利便性に関する計画を策定する

  8. Active Directory およびグループ ポリシーの実装計画を策定する

以降のサブセクションでは、BitLocker の計画を立てる際の問題点について詳細に説明します。

BitLocker の展開オプションについて理解する

BitLocker は、多数存在するセキュリティ上の脅威に効果的に対抗できる機能です。BitLocker によってどのような脅威が軽減され、BitLocker と EFS を組み合わせることで他にどのような脅威が軽減されるのかを理解するには、BitLocker のセキュリティ モデルとサポートされている展開オプションを理解する必要があります。このツールキットに含まれている『セキュリティ分析』ドキュメントでは、リスクの範囲と BitLocker によってリスクが軽減される仕組みが説明されています。計画を進める前に、これらの内容を徹底的に理解しておく必要があります。

BitLocker を使用するための準備状況を評価する

BitLocker を使用するには、コンピュータに次のコンポーネントがインストールされている必要があります。

  • Windows Vista™ Enterprise エディションまたは Ultimate エディション。

  • BitLocker と TPM を併用する場合は、TPM 対応のマザーボード (BIOS および Trusted Computing Group TPM Spec. Version 1.2 以降の TPM チップ)。

  • NTFS フォーマット済みのパーティションが 2 つ用意されたハード ディスク ドライブ。BitLocker ブート コンポーネント情報が格納されるパーティションは、空き容量が最低 1.5 GB の空のパーティションである必要があります。このパーティションをアクティブなパーティションにする必要があります。

Windows Management Instrumentation (WMI) スクリプトまたは PowerShell を使用して各クライアント コンピュータを対象にクエリを実行し、機能に関する情報を収集すれば、以上の要件を手動で確認することができます。ほとんどの組織は、Microsoft Systems Management Server (SMS) などの管理ツールや同等のサードパーティ製ツールを使用しています。こういったツールには、自動インベントリ機能やレポート機能が備わっているためです。

BitLocker のハードウェア要件

BitLocker は、Windows Vista のシステム要件を満たしているコンピュータならどれででも実行できます (特定の CPU、メモリ、およびディスク要件の詳細については、「Windows Vista Enterprise ハードウェア計画のガイドライン」 を参照してください)。マイクロソフトでは、Windows Vista の各種機能をサポートするハードウェアのカテゴリとして、"Windows Vista Capable" および "Windows Vista Premium Ready" を設けましたが、BitLocker は Windows Vista をサポートするあらゆるコンピュータで動作します。

TPM ハードウェアで BitLocker を利用するには、コンピュータに TPM 1.2 以降のハードウェアが装備されている必要があります。多くのメーカーで、TPM サポートは標準的な製品の一部として組み込まれていますが、メーカーによってはポータブル コンピュータの一部製品に限定されていることもあれば、まったく提供していないメーカーもあります。TPM サポートがコンピュータに備わっていない場合、この機能を追加する方法はありません。ただし、TPM ハードウェアが装備されていないコンピュータでは、USB キーを使用して BitLocker 暗号化キーを格納することができます。

TPM ハードウェアが装備されたコンピュータでも、BIOS のバージョンが Windows Vista で TPM 機能を完全に利用できるバージョンである必要があります。TPM 1.2 ハードウェアが装備されたコンピュータであっても、2007 年 1 月よりも前に出荷されたコンピュータの場合、BIOS のアップグレードが必要になる可能性があります。BitLocker と USB キーを併用する場合、起動プロセスで USB キーから情報を読み取れるように BIOS を設定できる必要があります。

注意

一部の BIOS 実装ではコンピュータの起動時に USB がサポートされますが、コンピュータがハード ディスクまたはその他のデバイスから起動されたる場合、この機能を無効にする必要があります。BitLocker は起動プロセスの後半で USB キーを読み取るため、このような実装では BitLocker と互換性がありません。

BitLocker で保護する各コンピュータには、ディスク パーティションが 2 つ用意されている必要があります。1 つはオペレーティング システムおよびデータ用で、もう 1 つは、コンピュータの起動時またはオペレーティング システムのアップグレード時にのみ使用する小さめのパーティションです (このスタートアップ パーティションは、その他のデータ ストレージ用に使用することはできません)。スタートアップ パーティションは、最低 1.5 GB の空き容量にすることをお勧めします。これらのパーティションは両方とも、NTFS ファイル システム (以下「NTFS」) を使用してフォーマットする必要があります。

Windows Vista Ultimate のユーザーは、Windows BitLocker ドライブ準備ツールを使用して、BitLocker を動的に使用することが可能になるユーティリティ パーティションを作成できます。Enterprise エディッションのユーザーは、マイクロソフト サポート技術情報 930063「BitLocker ドライブ準備ツールの説明」に記載されているように、ドライブ準備ツールを別途入手することが可能です。このツールを入手するには、マイクロソフト カスタマ サポート サービスに連絡する必要がありますが、連絡に際して料金はかからず、ツールも無償です。必要な BitLocker パーティション構成を作成するために、手動でパーティションを作成したり移動したりすることはできません。Windows Vista のクリーン インストールを実行するか (セットアップ プロセスの一部としてパーティションが作成されます)、ドライブ準備ツールを使用する必要があります。

BitLocker 展開プロセスの一部として USB フラッシュ ドライブの使用を予定している場合、使用するモデルは USB Mass Storage Class Bulk-Only Transport 仕様を満たしている必要があります (Universal Serial Bus Web サイトの『USB Mass Storage Class Bulk-Only Transport』(英語) を参照)。

TPM について理解する

BitLocker を展開する組織のほとんどは、TPM ハードウェアが装備されたコンピュータのセキュリティが強化されることを求めています。組織に適した BitLocker 構成を選択するためには、このハードウェアとその機能について理解することが重要です (TPM について詳細に検証することは、このガイドの目的ではありません。TPM および Trusted Computing Group の詳細については、Trusted Computing Group Web サイトの「Trusted Platform Module (TPM) Specifications」ページ (英語) を参照してください)。

本来、TPM は独自の I/O システムとオンボード ストレージを装備した特定用途のためのマイクロプロセッサであり、その特性を理解しておくことは重要です。TPM には EK (Endorsement Key) と呼ばれる保証キーが格納されます。このキーを使用して、TPM から直接受信した、または署名/暗号化のために TPM に渡されたデータの署名と暗号化が行われます。EK の TPM へのロードは、コンピュータ メーカーが行うか、BitLocker の初期化の一部として自動的に行われる必要があります。

また、TPM のステータスは、その時々で次のいずれかに切り替わる可能性があることも理解しておく必要があります。

  • 有効/無効。スタートアップの際には、TPM は何度も有効と無効に切り替わります。TPM が有効の場合、すべての機能を利用できます。TPM が無効の場合、TPM 機能をレポートする機能と更新を受け入れる機能を除いて、すべての操作が制限されます。

  • アクティブ/非アクティブ。TPM がアクティブの場合、すべての機能を利用できます。非アクティブは無効と似ていますが、動作状態を変更することが可能です (たとえば、物理プレゼンスを使用して所有またはアクティブの状態を変更します)。

  • 所有/非所有。オペレーティング システムが TPM の所有権を取得すると、TPM はストレージ ルート キー (SRK) を生成します。これは、保護対象のボリューム上での操作を封じるために使用するキー ペアです。TPM の所有者は、動作状態の変更も含めてすべての操作を実行できます。BitLocker は、所有の状態になるまで TPM を使用できません。

これらの状態は組み合わせることができます。たとえば、一部のベンダーは TPM の既定の状態を無効、非アクティブ、非所有にして、TPM 対応コンピュータを出荷しています。このようなコンピュータで BitLocker を使用するには、TPM の所有権を取得し、アクティブ化と有効化を行う必要があります。標準の BitLocker ユーザー インターフェイスを使用している場合、これらの操作は自動的に実行されます。BitLocker をオンにすると、TPM が存在する場合には BitLocker が自動的に TPM を有効化し、アクティブ化し、その所有権を取得します。

また、一部の TPM 操作を実行するには、物理プレゼンスの要件を理解しておく必要があります。Trusted Computing Group の TPM 仕様では、一部のコマンドを実行する場合、ユーザーは物理的なコンピュータで直接操作する必要があります。このユーザー操作はスクリプトで代替または模倣することはできません。物理プレゼンスとは、次のような基本的な TPM 管理タスクを実行するために、ユーザーが所有権をアサートしてコンピュータ上の物理的な対象となることを示します。

  • 所有者の情報なしに TPM を有効化する。

  • TPM をアクティブ化する。

  • TPM から既存の所有者をクリアする。

  • TPM を一時的に非アクティブ化または無効化する。

BitLocker ソフトウェアの要件

Windows Vista はいくつかの異なるエディションがリリースされていますが、BitLocker をサポートしているのは Enterprise エディションと Ultimate エディションのみです。マイクロソフトでは Windows Anytime Upgrade 機能 (Windows Vista のオンライン ヘルプを参照) を用意しており、この機能を使用して個々のコンピュータをアップグレードできます。たとえば、Anytime Upgrade 機能を使用して Business エディションを Ultimate エディションにアップグレードできます (アップグレードの種類によっては再インストールが必要になる場合もあります。たとえば、32 ビットから 64 ビットにアップグレードする場合、64 ビット バージョンの Windows Vista を再インストールする必要があります)。

注意

Data Encryption Toolkit for Mobile PCs に含まれるガイダンスとツールは、EFS (Windows XP Professional SP2 および Windows Vista の全バージョンで利用可能) と BitLocker (Windows Vista Enterprise および Windows Vista Ultimate で利用可能) の両方に適用されます。ただし、Windows Vista Ultimate で関しては、ガイダンスとツールの全機能をサポートできることを確認する厳密なテストは行われていません。このツールキットは、主に Windows XP Professional SP2 ならびに Windows Vista Enterprise エディションおよび Business エディションが対象となっています。

Windows Vista の展開

「Microsoft Solution Accelerator for Business Desktop Deployment 2007」 は、企業のクライアント コンピュータに Windows Vista を展開するための総合的なガイダンスとツールを提供します。Windows Vista の展開戦略の計画を組むときに忘れてはならないことは、BitLocker を有効にするためには各コンピュータと物理的に接触する必要があると考えられることです。というのも、対象コンピュータのコンソール以外からは、TPM の初期化または再プログラミングを実行できないからです。また、BitLocker の機能を完全に利用できるようにするためには、コンピュータの BIOS の更新が必要になる場合もあります。

展開時の重要な判断ポイントの 1 つが、既存のコンピュータを Windows XP から Windows Vista にアップグレードする方法と、新しいオペレーティング システムをクリーン インストールする方法のどちらを利用するかという点です。BitLocker は Windows Vista をインストールするまでは有効化できません。ただし、BitLocker を有効にするには特定のディスク パーティション構成が必要であることも認識しておく必要があります (「「ステップ バイ ステップ ガイド - Windows BitLocker ドライブ暗号化」 で説明されています)。Windows XP を実行している既存のコンピュータをアップグレードする必要がある場合、展開計画の中に、対象コンピュータで BitLocker をアクティブ化する前に必要なパーティション構造を構築する手順を組み入れておく必要があります。

Windows Vista Business Desktop Deployment (BDD) Toolkit を利用すると、状況に応じて BitLocker の有効化を自動的に行うことができます。オペレーティング システムの展開プロセスの一環として、BDD ツールを使用して BitLocker を有効にする方法については、「Lite Touch Installation Guide」(英語) を参照してください。

BitLocker の展開範囲を決定する

BitLocker の 1 つ以上のモードに対応するハードウェアおよびソフトウェアを所有する組織内の部門を確認したら、次の手順として、BitLocker を展開する必要のある場所を厳密に決定します。この手順を完了して、BitLocker を展開する最終的な範囲を決定するには、次の質問に回答する必要があります。

  • 組織内で保護が必要なコンピュータはどれか。セキュリティ上のニーズと展開実装サイクルに応じて、モバイル/デスクトップ コンピュータの一部しか保護を必要としていない場合もあれば、すべてを保護することが必要な場合もあります。

  • 組織内で保護が必要なデータ項目はどれか。組織によっては、利用可能な全データを保護することが必要な場合もあれば、もっと細かい要件に対応することが必要な場合もあります。

保護が必要なコンピュータはどれか。

セキュリティについて判断する場合、通常、保護とコストの間でどのようにバランスを取るかが問題になりますが、BitLocker を実装する場合もその例外ではありません。一見したところでは、最善のセキュリティ戦略は組織内のすべてのクライアント コンピュータに Windows Vista を展開して、各コンピュータで BitLocker を有効にすることだと思われます。しかし、Windows Vista (したがって、BitLocker) を広範囲に実装する場合、ほとんどの組織は全体的な IT 展開計画に合わせてスケジュールを組む必要があります。一方、リスクにさらされる可能性が最も大きいコンピュータに対象を絞って Windows Vista と BitLocker を実装すると、どのような組織であっても効果を得ることができます。そのような対象となるコンピュータの例を次に示します。

  • 取締役、顧問弁護士、または機密性の高い財務データ、法律データ、戦略的データを日常的に扱っているその他の従業員のコンピュータ。

  • ソフトウェア開発者、テスター、Web サイト デザイナ、あるいは顧客、従業員、ビジネス パートナーの個人データまたは財務データにアクセスできるその他のユーザーのコンピュータ。

  • 人事担当スタッフ、保険外交員、医療スタッフ、あるいは顧客または従業員に関する機密性の高い個人情報を日常的に取り扱うその他のスタッフのコンピュータ。

  • 物理的な攻撃 (ディスク ドライブまたはコンピュータ自体の盗難など) を受けやすい場所にあるコンピュータ。

  • 外出先で企業情報にアクセスしたり操作するために従業員が使用するラップトップまたはポータブル コンピュータ。

  • 重要な立場にある従業員の自宅にあるコンピュータまたは個人所有のコンピュータ (企業情報の操作や組織ネットワークへのアクセスに使用されている場合)。

環境内にあるコンピュータの中から保護する必要のあるコンピュータを判断するには、自動収集された資産インベントリ (利用できる場合) を使用して上記のグループに当てはまるコンピュータを特定します。自動収集されたインベントリに加えて、機密データを取り扱う従業員と彼らが日常的に使用する組織所有のコンピュータを手作業で照合し確認する場合もあります。組織で複数のモバイル コンピュータがひとまとめにされ、特定の場所に置かれている場合、または従業員が借り出せるようになっている場合、これらのコンピュータ全体を保護が必要なコンピュータの 1 カテゴリと見なすことができます。

保護が必要なデータ項目

BitLocker の最大の利点の 1 つが、システム ボリュームの内容全体を保護できることです。この機能を使用すると、暗号化するデータ項目についての判断の不確実性がなくなります。オペレーティング システム ボリュームにファイルが保存されている限り、ユーザーが作成または操作したすべてのファイルが暗号化されます。

ただし、BitLocker の保護を必要とするデータのカテゴリまたはクラスも正確に特定しておくことが重要です。そうしておけば、これらのデータの処理を許可するユーザーとコンピュータをより適切に識別できるようになります。保護が必要なデータとして、次のようなものが挙げられます。

  • ビジネス上の機密情報 (財務データ、製品計画、銀行/信用情報、戦略計画/コミュニケーションなど)。

  • 過去、現在、将来の訴訟に関する情報および記録 (特に、弁護士と依頼者間の秘匿特権に触れる場合)。

  • 従業員、元従業員、退職者、または顧客に関する個人データ。

  • ソース コード、データベース、独自開発の設計情報、取引上の機密資料、またはその他の知的財産物。

  • 情報の機密性を要求しているビジネス パートナーまたはその他の使用許諾契約者の契約または所有に関する資料。

BitLocker の構成を選択する

計画のこの段階では、組織に適した構成を決定して構成/展開プロセスのアウトラインを明確にします。

セキュリティ分析』ガイドに、BitLocker を使用してボリューム暗号化キーを保護するセキュリティ方法についての詳細が記載されています。組織に適した BitLocker モードを選択するには、『セキュリティ分析』ガイドの情報を参照してください。既に説明したとおり、BitLocker モードの選択内容は、利用できるハードウェアとソフトウェアによって変わり、組織内のさまざまな部門のさまざまなセキュリティ要件によっても変わります。選択できるモードは次のとおりです。

  • BitLocker と TPM を併用

  • BitLocker と TPM/PIN を併用

  • BitLocker と USB デバイスを併用

  • BitLocker と TPM/USB デバイスを併用

次の図は、環境に適した BitLocker の構成オプションを評価できるデシジョン ツリーです。

図 1.1 BitLocker 構成オプション デシジョン ツリー

デシジョン ツリーを使用した結果は、次の表に示したものと近い結果が出ると考えられます。情報には、ハードウェアの役割、サポートされるハードウェアの種類、関連する BitLocker のポリシーと構成が含まれます。

表 1.1 BitLocker のポリシーと構成のガイドライン

システムの種類 BitLocker のポリシーと構成
標準的なデスクトップ コンピュータはハードウェアの機能に応じて、TPM または USB スタートアップ キーによる BitLocker 暗号化を使用します。この構成は、データの漏洩を抑制し、資産の耐用年数を管理するために使用します。
標準的なラップトップ すべての新しいコンピュータで、TPM と PIN を使用します。TPM に対応していないコンピュータでは、USB ドライブに保存されたスタートアップ キーを使用しますが、新しいコンピュータについてはすべて、TPM デバイスが装備されたものを購入します。この構成は、データの漏洩を抑制し、資産の耐用年数を管理するために使用します。
取締役のラップトップ すべてのコンピュータで、TPM と PIN を使用します。TPM に対応していない既存のコンピュータはすべて交換します。
##### BitLocker と TPM を併用する場合の考慮事項 BitLocker と TPM を併用するモードでは、ユーザーは何も操作しなくても保護を実現できます。ボリュームの暗号化、起動、操作など、すべてがユーザーには見えない状態で実行されます。一般的には、この BitLocker モードは BitLocker の基本的実装に*適していません* - 複数要素の BitLocker 認証が不要であるとき。 - 複数要素の BitLocker 認証によって増すコストや複雑さが、そのデータの価値に見合わないと思われるとき。 ##### BitLocker と TPM を併用する場合の計画 BitLocker と TPM を併用するモードの利用を計画する場合、次の手順を実行します。 - 組織内のコンピュータを調べて、TPM ハードウェアを利用できるコンピュータの一覧を作成する。 - ハードウェアのアップグレードと交換サイクルを計画する。 - 既存ソフトウェアの更新とパッチ管理プロセスの方法を計画する。 - コンピュータの無人スタートアップを許可または拒否する業務上または運用上の理由を明確にする。BitLocker と TPM を併用するモードでは無人スタートアップが可能ですが、PIN または USB キーを使用する BitLocker モードでは、スタートアップ時に PIN または USB キーの入力が求められます。 - BitLocker の保護対象のディスクを交換したコンピュータで直接的に利用できない場合、既存のヘルプ デスク プロセス (ハードウェアの修理、交換、配置転換など) でどのようにして TPM 保護システムに対応するかを計画する。 ##### BitLocker と TPM/PIN を併用する場合の考慮事項 BitLocker と TPM/PIN を併用するモードでは、ドメイン ユーザーが PIN を知らない場合、保護されたコンピュータからデータを読み取ることができなくなります。このモードは、コンピュータが起動してログオン画面が表示された場合に攻撃が成功したと見なされるようなコンピュータ攻撃に対する保護対策となります。 追加の PIN を覚える必要が出てくるとユーザーは抵抗感を感じるため、この抵抗感に対処する手順を設けるかどうか、計画の段階で判断する必要があります。別の認証要素を必要とする補完的なセキュリティを追加すれば、このソリューションは貴重な資産を保護する適切な選択肢になります。 ##### BitLocker と TPM/PIN を併用する場合の計画 BitLocker と TPM/PIN を併用するモードの利用を計画する場合、BitLocker と TPM を併用するモードの計画で必要なすべての手順を実行する必要があります。また、次に挙げる手順を実行する計画も策定する必要があります。 1. 組織のセキュリティ要件を満たした適切な強度を持つ PIN の設定方法や、PIN を忘れた場合にユーザーが取るべき行動などを示した、ユーザーを教育するためのドキュメントを作成する。 2. PIN のリセット手順をヘルプ デスク担当者に指示するためのドキュメントを作成する。 ##### BitLocker と USB を併用する場合の考慮事項 BitLocker と USB デバイスを併用するモードを利用すると、TPM が装備されていないコンピュータで保護を実現できます。このモードでは、基本的な保護機能は利用できますが起動時の整合性チェック機能は利用できません。したがって、ドメイン ユーザーが USB デバイスを使用してシステムを起動した場合、そのユーザーがコンピュータにログオンしてデータを読み取る行為を阻止することはできません。 ##### BitLocker と USB を併用する場合の計画 USB スタートアップ キーと BitLocker を併用する計画を立てる場合、次の手順を実行する必要があります。 1. コンピュータをテストして、起動時に USB キーの優先モデルを認識できることを確認します。マイクロソフトが行ったテストでは、USB キーの一部のブランドで 50% を超える障害発生率が確認されているため、信頼性テストも含めてテストを行う必要があります。また、スタートアップ パスワードと回復パスワードに確実にアクセスできるように、USB キーを特定のブランドに統一することを強くお勧めします。 2. BitLocker と USB キーの組み合わせのみを利用しているユーザーが BitLocker と TPM/PIN を併用するモードに移行する方法について、計画を策定します。この計画には、TPM 対応のコンピュータにデータとアプリケーションを移行する方法、または既存のコンピュータが TPM に対応している場合は、TPM を有効にして BitLocker を再度有効にする方法も含めます。 ##### BitLocker と TPM/USB を併用する場合の考慮事項 このモードでは、BitLocker によって起動時の整合性チェックと暗号化が行われますが、コンピュータを起動できるように、USB トークンが起動時に存在している必要があります。このモードを計画する場合の考慮事項は、TPM のみのモードと USB のみのモードの考慮事項を合わせたものになります。これは、コンピュータで BitLocker と TPM を併用でき、さらに USB キー ストレージがサポート可能であることを確認する必要があるためです。 ##### BitLocker と TPM/USB を併用する場合の計画 このモードを使用する場合、この章の「BitLocker と TPM を併用する場合の計画」および「BitLocker と USB を併用する場合の計画」の項で説明した計画手順を実行する必要があります。 #### データ回復計画を策定する BitLocker では、データを強固に暗号化することができます。適切な回復パスワードがないと、BitLocker で保護されたディスクからデータを回復することはできません。"裏技" などは一切存在しません。このことから、回復計画がいかに重要かおわかりと思います。回復パスワードの適切なコピーがない場合、保護されたボリュームから*すべて* コンピュータの起動時に、Windows のインストール先ドライブのロック解除を防止する条件が BitLocker によって検出される場合があります。そのような条件の例として、ディスク エラーや、コンピュータのスタートアップ ファイルの変更などがあります。こういった条件が検出されると、BitLocker 回復パスワードを使用してボリュームのロックを解除するまで、ユーザーはログオンして保護されたファイルにアクセスすることができなくなります。異なるコンピュータにハード ディスクをマウントしようとした場合にも、BitLocker 回復パスワードが必要になります。 回復パスワードを記録する基本的な方法として、4 とおりの戦略が考えられます。 - パスワードを印刷する。 - パスワードをリムーバブル メディアに保存する。 - パスワードをネットワーク内の保存場所に格納する。 - パスワードを Active Directory に保存する。 環境に応じて、いくつかの回復方法を組み合わせることをお勧めします。パスワードがないと BitLocker ボリュームは回復不能になるため、1 つの回復方法だけで回復パスワードを記録した場合、データ回復のプロセスに単一障害点を作ってしまうことになります。それぞれの回復方法には長所と短所があり、方法を選択するときにはこういった点を確実に理解している必要があります。 ##### ###### Active Directory マイクロソフトでは、BitLocker で保護されたコンピュータの回復パスワードを Active Directory に保存する方法を計画して展開することを強くお勧めしています。この方法を使用した場合、回復情報は Active Directory のコンピュータ オブジェクトに属性として格納されます。回復情報には、各 BitLocker 対応ボリュームの回復パスワード、TPM 所有者パスワード、回復情報の適用先であるコンピュータやボリュームの識別に必要な情報などが含まれます。また、実行は任意ですが、データの暗号化に使用する実際のキーとこれらのキーにアクセスする際に必要な回復パスワードをパッケージにして保存することもできます。この回復パスワード格納方法には、その他の保存方法と比べて次のような大きな利点があります。 - 記録プロセスが自動化されているため、ユーザーの操作は不要です。 - ユーザーの操作によって回復情報が失われたり、壊れたりすることはありません。 - Active Directory では、回復情報の保管と利用を一元的に管理し、監査することができます。 - 回復情報のバックアップが作成され、その他の貴重な Active Directory データと共に保護されます。 - 回復情報にリモートからアクセスできるため、ヘルプ デスクのサポートを受けながらのオフサイトでの回復作業が可能になります。 Active Directory を使用して BitLocker 回復パスワードを保存する場合、次の要件を満たしている必要があります。 - 組織内に、適切に管理された堅牢な Active Directory インフラストラクチャが必要です。 - BitLocker の属性とオブジェクトを格納するため、Windows Server® 2003 Active Directory スキーマを拡張する必要があります。Active Directory スキーマの拡張を計画する作業には、多大な知識と労力が必要とされます。Active Directory スキーマの拡張の詳細については、「[Extending Your Active Directory Schema in Windows Server 2003 R2](https://technet.microsoft.com/ja-jp/library/509ada1a-9fdc-45c1-8739-20085b20797b(v=TechNet.10))」(英語) を参照してください。 - 次に、管理者が BitLocker 回復パスワードのバックアップを可能にするグループ ポリシー設定を有効にする必要があります。 - Active Directory に回復マテリアルを安全に保管し、格納されたマテリアルへのアクセスを制御するには、適切なポリシーと担当者が不可欠です。 > [!NOTE] > 回復モードが開始されたコンピュータは、マルウェアによって予期せぬ攻撃を受けている可能性があります。原因不明で回復モードが開始されたコンピュータは、ユーザーが回復プロセスを実行する前に、サポート スタッフが確実に調査する必要があります。 ###### ファイル/プリンタを使用する方法 回復パスワードを印刷するかファイルに保存する方法は、プロセスが簡単で、次のような重要な利点がいくつか存在します。 - セットアップが簡単です。 - 必要なインフラストラクチャは小規模なもので大丈夫です。 - 技術的知識のないユーザーでも簡単に管理できます。 ただし、重大な欠点もいくつか存在します。 - 回復パスワードの管理と、損失または侵害からパスワードを保護する作業はユーザーに委ねられます。 - この方法では、保存したパスワードを一元的に管理または監査できません。 - 保存先のファイルまたは印刷した用紙を損失または破損から保護する有効な手段はありません。 ###### USB デバイスを使用する方法 回復パスワードを USB デバイスに保存すると、次のような利点があります。 - 回復パスワードは単純なテキスト ファイルであるため、複数のパスワードを 1 つの USB デバイスに保存できます。 - パスワードを保護するために、物理的なセキュリティと障壁を簡単に追加できます。 - USB キーとコンピュータを切り離せば、それぞれの管理責任も分離できます。 ただし、この方法には次のような欠点も存在します。 - すべてのコンピュータで、起動前や起動時の USB デバイスの取り付けがサポートされているわけではありません。 - 回復パスワードの回収と保存は、個々のコンピュータで手動で実行する必要があります。 - この方法では、一元的な管理または監査の機能はありません。 - USB デバイスを失くすか壊す可能性があります。また、障害が発生する可能性もあります。 ###### 回復ポリシーの定義 BitLocker で保護されたコンピュータからデータを回復する担当者を指定したポリシーを定義することが重要です。BitLocker の回復プロセスでは、コンピュータに物理的にアクセスして回復パスワードを入力する必要があります。この要件は、回復ポリシーを定義するプロセスに大きく影響します。外出先にいるリモート ユーザーまたはモバイル ユーザーが BitLocker で保護されたボリュームにアクセスする必要があるというような状況にも対応できる必要があるからです。 既定では、すべてのドメイン管理者が、Active Directory ドメイン サービス (以下「AD DS」) に格納された BitLocker 回復パスワードを読み取ることができます。ドメイン管理者は、"アクセスの制御" と "プロパティの読み取り" アクセス許可をユーザーに割り当てることで、他のユーザーにこの権限を委譲できます。同様に、格納された TPM 所有者情報を読み取る権限を委譲することもできます。たとえば、管理者はヘルプ デスクまたは電話サポート スタッフに、ユーザーの回復パスワードにアクセスする権限を与えることができます。ただし、権限を与える前に、このようなアクセスを許可することと組織のセキュリティ ポリシーとに整合性があることを確認する必要があります。というのも、ボリュームの回復パスワードにアクセスできるユーザーは、無制限にボリュームのデータを読み取ることができるからです。 必須の回復方法を指定する前に、その方法に必要とされる前提条件が満たされていることを確認してください。たとえば、次のような前提条件があります。 - USB キーを使用する場合、起動時に USB デバイスを読み取る機能が対象のシステムにあることを確認します。また、広範囲への展開を実施する前に代表コンピュータでテストを行い、標準的なブランドの USB キーが BitLocker で適切に動作することを確認します。初めて BitLocker を有効にしたときには、利用可能な USB キーがあることを確認します。 - 別の保存場所を使用する場合、回復プロセスの実行時にユーザーが回復パスワードを利用できることを確認します。同じコンピュータ内に保存場所を作成しないでください。コンピュータの回復作業中、その場所にはアクセスできないためです。ネットワーク共有は、悪意のあるユーザーや信頼できないユーザーのアクセスから適切に保護できないため、使用しないように注意します。 - 回復パスワードを印刷する場合は、BitLocker を有効にしたときに接続されているローカル プリンタまたはネットワーク プリンタが利用可能なことを確認します。また、印刷したパスワード、つまり紙の記録は、紙ベース特有のリスクや脅威にさらされるため、取り扱い方法に関する計画を必ず立ててください。 - 回復パスワードを Active Directory に格納する場合、準備のための独自の手順 (次の章を参照) を実行する必要があります。 #### 管理性に関する計画を策定する BitLocker の計画プロセスの中でも重要な手順が、BitLocker が組織の IT 管理プロセスに与える影響を判断することです。BitLocker は、組織で行われている次のような継続的な管理プロセスに影響します。 - ソフトウェア更新管理 - ハードウェアの更新と交換 - イメージング、バックアップ、およびマルウェア対策ソフトウェアとの統合 - BitLocker 構成の管理 - コンピュータの配置転換 ##### ソフトウェア更新管理 ソフトウェア更新管理が BitLocker の展開計画に影響を与える例として、主に次の 3 とおりのシナリオが考えられます。 第 1 に、BIOS を更新する場合です。BitLocker は、BIOS 構成の一部を含めて、変更の有無をチェックするためにさまざまなコンポーネントを監視しています。このようなパラメータに予期せぬ変更があった場合、再起動のたびに BitLocker は強制的に回復プロセスを実行します。この問題を避けるには、システム BIOS を更新する前に BitLocker を無効にし、BIOS を更新した上で再度 BitLocker を有効にする必要があります。 第 2 に、Windows Vista に更新プログラムを適用する場合です。TPM と併用する形で BitLocker を有効にしている場合、次の 2 とおりのサブシナリオが考えられます。 - ブート マネージャ、オペレーティング システム ローダー、休止状態から再開するために使用されるアプリケーション、またはメモリ診断アプリケーションに影響する更新の場合。これらのコンポーネントの 1 つまたは複数が Windows Update によって変更されたと BitLocker が判断した場合、新しいバージョンを反映するために構成情報が更新されます。 - その他の Windows コンポーネントに影響する更新の場合。このような更新は通常の Windows 更新メカニズムに従って適用されるため、BitLocker が監視するパラメータには影響しません。 > [!NOTE] > BitLocker を有効にしていても TPM を使用していない場合、起動時の整合性を確保する信頼されたパスが存在しないため、システム更新プログラムによって回復または構成の更新を強制することはできません。 第 3 に、バージョンまたはエディッションをアップグレードする (たとえば、Windows Vista Enterprise から Windows Vista Ultimate に移行する) 場合です。この場合、アップグレードを適用する前に、ドライブの暗号化を解除して BitLocker を無効にする必要があります。アップグレードが完了したら、BitLocker を有効にしてドライブを再度暗号化することができます。 ##### ハードウェアの更新と交換 回復パスワードにアクセスできない限り、BitLocker で暗号化されたディスク ボリュームは別のコンピュータにマウントしても読み取ることはできません。Windows Vista の起動時に、起動プロセスを続行できるように回復パスワードを入力することで、ボリュームを回復することができます。この機能を使用する場合、ハードウェアの修理ポリシーやアップグレード ポリシーを変更する必要があります。具体的な変更内容は、コンピュータを交換する方法とタイミング、ディスク イメージング ソフトウェアやバックアップ ソフトウェアを使用してデータを特定のコンピュータから別のコンピュータに移動するかどうか、BitLocker 回復データへのアクセス許可を与える方法などによって異なります。 ##### イメージング、バックアップ、およびマルウェア対策ソフトウェアとの統合 BitLocker では、ディスク ボリューム レベルでデータが暗号化されます。Windows が実行されていないときでもディスクに直接アクセスできるプログラムまたはユーティリティを使用すると、ディスクからデータを読み取ることはできますが、そのデータは暗号化されています。たとえば、イメージング ツールを使えば、BitLocker で保護されたディスクの暗号化されたコンテンツをキャプチャできますが、そのコンテンツはプレーンテキストではありません。 Windows の実行時に動作するほとんどのバックアップ、復元、およびマルウェア対策ツールは、BitLocker を使用しているコンピュータでも通常どおりに機能します。 また、Windows システム ファイルを変更するツールやシステム構成パラメータを変更するツールを使用した場合、次回の起動時に BitLocker によって回復パスワードを要求される可能性があります (TPM のみのモードから TPM と PIN を併用するモードへの切り換えなど、ポリシーを変更しても回復プロセスが開始される可能性があります)。BitLocker の暗号化がソフトウェア更新管理に与える影響については、このガイドの「[第 3 章 : 運用および回復のシナリオ](https://technet.microsoft.com/ja-jp/library/01754723-3e94-4bec-8284-02e2a4e91593(v=TechNet.10)) ##### BitLocker 構成の管理 BitLocker では、グループ ポリシーに加えて、テクノロジの基本動作を制御および管理するスクリプトを利用できます。ProtectKeyWithTPM などのスクリプト インターフェイスの詳細については、「[BitLocker Drive Encryption Technical Overview](https://go.microsoft.com/fwlink/?linkid=77977)」(英語) を参照してください。スクリプトを使用して BitLocker のポリシーを適用する組織もあれば、グループ ポリシーを使用してそれを行う組織もあります。どちらにするかは、計画プロセスの比較的初期の段階に決定する必要があります。 Windows Vista グループ ポリシー管理コンソール (または Windows Vista 管理用テンプレートがインストールされた他のコンピュータ) の BitLocker 制御オプションでは、次の点を制御できます。 - BitLocker キーのバックアップを Active Directory に自動的に作成するかどうか。 - 回復キーの格納に使用する既定の場所。 - 回復とスタートアップのオプションを変更する権限をユーザーに与えるかどうか。 - BitLocker で使用される暗号化の方法。 - TPM プラットフォームの検証の実行方法。 **\\コンピュータの構成\\管理用テンプレート\\Windows コンポーネント\\BitLocker ドライブ暗号化** ###### Active Directory ドメイン サービスへの BitLocker バックアップを有効にする このポリシー設定では、Active Directory ドメイン サービス (AD DS) による BitLocker ドライブ暗号化の回復情報のバックアップを管理できます。既定では、この設定は **\[未構成\]** になっています。このポリシー設定を有効にすると、コンピュータで BitLocker がオンになっている場合、BitLocker 回復情報は通知なしで自動的に AD DS にバックアップされます。 BitLocker 回復情報には、回復パスワードと一意の識別子データが含まれます。また、BitLocker で保護されたボリュームの暗号化キーと回復パスワードが共に格納された回復キー パッケージのバックアップを作成するように指定することもできます。このキー パッケージは回復パスワードによって保護され、ディスクが損害を受けるか破損した場合、これを使用して特別な回復プロセスを実行することができます。 **\[Active Directory ドメイン サービスへの** **BitLocker バックアップを有効にする\]** オプションをオンにした場合、コンピュータがドメインに接続して AD DS へのバックアップを正常に実行できるようになるまで、BitLocker をオンにできなくなります。BitLocker による回復を確実に可能なものとするため、このオプションは既定でオンになっています。このオプションをオフにした場合でも、BitLocker は回復キーを Active Directory に登録しようとします。登録が失敗しても、BitLocker のセットアップは続行できます。BitLocker のセットアップ中は、バックアップが自動的に再試行されることはないため、回復パスワードは AD DS に格納されていません。 > [!IMPORTANT] > データの損失を防止するため、BitLocker を回復する方法を何か用意しておく必要があります。このポリシー設定を無効にするか構成しなかった場合、BitLocker 回復情報は AD DS にバックアップされません。 ###### コントロール パネル セットアップ: 回復フォルダを構成する このポリシー設定では、BitLocker ドライブ暗号化セットアップ ウィザードの、回復パスワードの保存先フォルダの場所を入力するように指示する画面で表示される既定のパスを指定できます。 このポリシー設定を有効にした場合、ユーザーが回復パスワードをフォルダに保存するオプションを選択した場合に既定のフォルダの場所として使用されるパスを指定できます。完全修飾パスを指定することも、対象コンピュータの環境変数をパスに含めることも可能です。このパスが有効でない場合、BitLocker セットアップ ウィザードでは、コンピュータの最上位のフォルダが表示されます。 このポリシー設定を無効にするか構成しなかった場合、ユーザーが回復パスワードをフォルダに保存するオプションを選択すると、BitLocker セットアップ ウィザードにはコンピュータの最上位のフォルダが表示されます。 > [!NOTE] > ユーザーは常に、回復パスワードの保存先として他のフォルダを選択できます。 ###### コントロール パネル セットアップ: 回復オプションを構成する このポリシー設定では、BitLocker ドライブ暗号化セットアップ ウィザードで、BitLocker 回復オプションの保存をユーザーに求めるかどうかを構成できます。 BitLocker で暗号化されたデータへのアクセスのロックを解除する回復オプションとして、ユーザーは 2 とおりのオプションを使用できます。 - ランダムに生成された 48 桁の数値から成る回復パスワードを入力する。 - ランダムに生成された 256 ビットの回復キーが保存された USB フラッシュ ドライブを挿入する。 回復キーまたはパスワードは、BitLocker のセットアップ時に生成されます。このポリシー設定を有効にすると、セットアップ ウィザードに表示される BitLocker 回復用オプションを構成できます。たとえば、48 桁の回復パスワードを無効にすると、ユーザーは回復情報をフォルダに保存したり、紙に印刷したりできなくなります。 このポリシー設定を無効にするか構成しなかった場合、BitLocker セットアップ ウィザードには、回復オプションを保存する複数の方法が提示されます。USB フラッシュ ドライブに保存する場合、48 桁の回復パスワードはテキスト ファイルとして保存され、256 ビットの回復キーは隠しファイルとして保存されます。フォルダに保存する場合、48 桁の回復パスワードはテキスト ファイルとして保存されます。印刷すると、48 桁の回復パスワードが出力されます。 > [!NOTE] > TPM は、BitLocker のセットアップ時に初期化する必要があります。TPM の所有者情報は、BitLocker 回復情報と共に保存または印刷されます。 ###### コントロール パネル セットアップ: 詳細なスタートアップ オプションを有効にする このポリシー設定では、BitLocker ドライブ暗号化セットアップ ウィザードで、コンピュータの起動時に毎回要求する追加の認証のセットアップをユーザーに求めるかどうかを構成できます。このポリシー設定では、BitLocker のスタートアップに関して次の点を制御できます。 - **\[互換性のある TPM が装備されていない BitLocker を許可する\]** 設定では、サポート対象の TPM が装備されていないコンピュータでも BitLocker を使用できるようにするかどうかを制御します。TPM が装備されていないコンピュータでは、スタートアップ キーを格納するために USB デバイスを使用する必要があります。つまり、起動時に USB デバイスを読み取ることができる機能がコンピュータに必要です。TPM がない場合、BitLocker で暗号化されたデータは、この USB フラッシュ ドライブのキー マテリアルのみによって保護されます。 - 互換性のある TPM が装備されたコンピュータでは、ユーザーが利用できるスタートアップ方法を選択できます。コンピュータの起動時に、スタートアップ キーが格納された USB フラッシュ ドライブを挿入するようにユーザーに要求できます。また、4 ～ 20 桁のスタートアップ PIN を入力するように要求することもできます。 このポリシー設定を有効にした場合、BitLocker の詳細なスタートアップ オプションをユーザーが構成できるページがウィザードで表示されます。また、TPM が装備されたコンピュータと装備されていないコンピュータを対象にした設定オプションも構成できます。 このポリシー設定を無効にするか構成しなかった場合、BitLocker セットアップ ウィザードには、TPM が装備されたコンピュータでユーザーが BitLocker を有効にできる基本的な手順が表示されます。この基本のウィザードでは、追加のスタートアップ キーまたはスタートアップ PIN を構成することはできません。 TPM なしで BitLocker を使用する場合、または TPM に加えて PIN またはスタートアップ キーも使用する場合、詳細なスタートアップ オプション (次の図を参照) のためのローカル コンピュータ ポリシー (または累積的な効果があるグループ ポリシー) の構成が行われていることを確認します。BitLocker を有効にする前に、この構成を設定する必要があります。この構成は、**コンピュータの構成\\管理用テンプレート\\Windows コンポーネント\\BitLocker ドライブ暗号化\\コントロール パネル セットアップ: 詳細なスタートアップ オプションを有効にする** ![](images/Cc162806.01e06e8d-fc15-49cd-a09c-ed805d2c1655(ja-jp,TechNet.10).gif) **図 1.2 \[詳細なスタートアップ オプションを有効にする\] ダイアログ ボックス** ###### 暗号化方法を構成する このポリシー設定では、BitLocker が使用するアルゴリズムとキー サイズを構成できます。このポリシー設定は、完全に暗号化が解除されたディスクに適用されます。ディスクが既に暗号化されているか、暗号化の処理中である場合、暗号化方法を変更しても影響はありません。このポリシー設定には 4 つのオプションがあります。 - AES 128-bit および AES 256-bit では、FIPS 標準の AES (Advanced Encryption Standard) アルゴリズムと指定されたキー強度が使用されます。 - AES 128-bit with Diffuser および AES 256-bit with Diffuser では、『*セキュリティ分析*』ガイドで説明した Diffuser アルゴリズムが追加されます。diffuser レイヤによって、ディスクの暗号化設定で必要性が高いにもかかわらず AES の CBC (Cipher Block Chaining) モードで直接的に提供されない一部のセキュリティ プロパティが追加されます。 このポリシー設定を有効にした場合、ボリュームの暗号化/暗号化解除に使用される暗号化方法を構成できます。このポリシー設定を無効にするか構成しなかった場合、BitLocker では、既定の暗号化方法である AES 128-bit with Diffuser か、ローカル管理者のセットアップ スクリプトによって指定された暗号化方法が使用されます。 ###### 再起動時のメモリ上書きの回避 このポリシー設定では、BitLocker の機密情報が漏洩するリスクを考慮しながら、コンピュータの再起動パフォーマンスを制御します。BitLocker の機密情報には、データの暗号化に使用されるキー マテリアルも含まれます。このポリシー設定は、BitLocker による保護が有効になっているときにのみ適用されます。 このポリシー設定を有効にした場合、Microsoft Windows は再起動時にメモリを上書きするようにコンピュータに命令しません。メモリの上書きを防止すると、BitLocker の機密情報が漏洩するリスクが大きくなりますが、再起動時のパフォーマンスが改善されます。 このポリシー設定を無効にするか構成しなかった場合、BitLocker の機密情報は、コンピュータの再起動時に Windows によって確実にメモリから削除されます。既定では、このポリシーは未構成です。 ###### TPM プラットフォーム検証プロファイルを構成する このポリシー設定では、コンピュータの TPM セキュリティ ハードウェアによって BitLocker の暗号化キーを保護する方法を構成できます。互換性のある TPM がコンピュータに装備されていない場合、または TPM を使用した BitLocker の保護が既にオンになっている場合、このポリシー設定は適用されません。 BitLocker をオンにする前にこのポリシー設定を有効にした場合、BitLocker で暗号化されたオペレーティング システム ボリュームへのアクセスのロックを解除する前に TPM の検証を実行するブート コンポーネントを構成できます。BitLocker による保護が有効なときにこれらのコンポーネントのいずれかが変更された場合、TPM はボリュームのロック解除に必要な暗号化キーをリリースせず、コンピュータは起動中に回復モードに切り替わります。 このポリシー設定を無効にするか構成しなかった場合、TPM は既定のプラットフォーム検証プロファイルか、ローカル管理者のセットアップ スクリプトによって指定されたプラットフォーム検証プロファイルを使用します。既定のプラットフォーム検証プロファイルは、CRTM (Core Root of Trust of Measurement)、BIOS、プラットフォーム拡張 (プロセッサ構成レジスタ 0 (PCR 0))、オプション ROM コード (PCR 2)、マスタ ブート レコード (MBR) コード (PCR 4)、NTFS ブート セクタ (PCR 8)、NTFS ブート ブロック (PCR 9)、ブート マネージャ (PCR 10)、および BitLocker アクセス制御 (PCR 11) に変更があった場合に、暗号化キーの安全性を確保します。 > [!IMPORTANT] > 既定のプロファイルを別のプロファイルに変更した場合、コンピュータのセキュリティと管理性に影響が出ます。プラットフォームの変更 (悪意のある変更か許可された変更かを問わず) に対する BitLocker の感度は、PCR が含まれる場合は高くなり、PCR が含まれない場合は低くなります。 ##### コンピュータの配置転換 計画の一環として、コンピュータの配置転換を考慮対象に入れる必要があります。たとえば、BitLocker で保護されたコンピュータの再割り当てを行う場合や、組織の外部に移す場合、またはハードウェア障害により廃棄する場合、どのようなアクションを取ればいいでしょうか。BitLocker が使用している AES アルゴリズムは強固なため、回復パスワードを消去してしまうと保護されたボリュームには事実上アクセスできなくなります。コンピュータの配置転換を行うときに、Active Directory またはその他の場所からすべてのプロテクタが除去されたことを確認できるように、ポリシーと手順を設けることを検討する必要があります。配置転換時にプロテクタを除去する方法の詳細については、「[BitLocker Drive Encryption and Disk Sanitation](https://technet.microsoft.com/ja-jp/library/a4d82f78-cc5d-49b3-8229-4cb4162d43a2(v=TechNet.10))」(英語) を参照してください。 #### 利便性に関する計画を策定する BitLocker は、通常の操作のときにはユーザーからは見えない形で強力なセキュリティを提供するように設計されています。ただし、BitLocker を効果的かつ安全に利用するためには、ユーザーは多くのことを知っておく必要があります。暗号化に関する、使い方、要件、操作上の問題といった事項を説明する文書化された暗号化ポリシーを作成する必要があります。ユーザーとサポート スタッフは、暗号化が展開される前に、暗号化の適切な使い方について教育を受ける必要があります。 機密データの保護を目的として暗号化を使用するために、暗号化ポリシーでは次のようなことを考慮する必要があります。 - 暗号化を使用する必要がある情報の種類。 - 暗号化を使用する必要があるコンピュータ資産の種類 (デスクトップ コンピュータ、ラップトップなど)。 - サポートされているデータ暗号化ソリューション (EFS と BitLocker など)。 - 暗号化によって解決できる問題と解決できない問題。 - 回復キーとパスワードを格納する必要の有無。 - 回復キーとパスワードの管理者、アクセス可能なユーザー。 - 暗号化を適切に行うためにユーザーが実行できる行為、実行する必要がある行為。 - コンピュータの回復パスワードを保持する場合にユーザーが負う責任。 - 暗号化に関連した潜在的な問題 (データの損失など)。 - ファイルを暗号化するためにユーザーが実行する必要のある手順。 - 暗号化されたデータの回復を実行する責任者、ユーザーが回復プロセスを開始する方法。 - 暗号化の問題に関してユーザーがサポートを受ける方法。 オンライン資料、印刷物の資料、実地レッスン、教育クラスなど、一般的な教育手段を通じて、暗号化の情報を必要に応じてユーザーと共有します。この取り組みは、残りの展開プロセスと並行して実施できます。 #### Active Directory およびグループ ポリシーの実装計画を策定する ここまで説明してきた計画手順に従った結果、Active Directory を使用して BitLocker 環境をどの程度まで管理できるかが判明します。次の可能性が考えられます。 - Active Directory を使用して TPM パスワードと回復パスワードを格納する。 - グループ ポリシーを使用して BitLocker の設定と構成を管理する。 ##### Active Directory に回復パスワードを格納する計画を策定する 「データ回復計画を策定する」の項で既に説明したように、Active Directory を使用して回復パスワードを格納する場合、Active Directory スキーマを拡張する必要があります。この拡張作業には多大な知識と労力が必要であり、スキーマの拡張に成功して環境が適切に安定するように、BitLocker を展開する前に慎重に計画を立てる必要があります。 また、BitLocker のために Active Directory を使用する場合の計画プロセスでは、キーとデータの回復を担当するオペレータに誰を任命すべきか検討し、決定する必要もあります。ここで検討が必要となる重要なポイントは、回復オペレータの職務をドメイン管理者およびエンタープライズ管理者の役割から分離するかどうかです。責務を厳格に区分することを要件としている組織では、これらの役割を分離する必要があります。その一方、ドメイン管理者は Active Directory の管理という複雑で技術的な作業に既に慣れているという理由から、ドメイン管理者にデータとキーの回復作業を許可する組織も存在します (おそらく小さめの規模の組織)。 ##### グループ ポリシーを使用して BitLocker データ暗号化を制御する ここまでの計画手順で、使用する BitLocker 関連のグループ ポリシー オプションは決定されています。計画の必要があるグループ ポリシー オプションは次のとおりです。 - TPM と回復パスワードを Active Directory に格納する方法。 - 無効/有効にする回復メカニズム。 - 暗号の長さと強度に関する既定の BitLocker 設定。 [](#mainsection)[ページのトップへ](#mainsection) ### 暗号化ファイル システムの計画 EFS の展開計画を完了するには、次の手順を実行する必要があります。 1. EFS の展開オプションについて理解する 2. EFS を使用するための準備状況を評価する 3. EFS の展開範囲を決定する 4. EFS の構成を選択する 5. キーとデータの回復計画を策定する 6. 管理性に関する計画を策定する 7. 利便性に関する計画を策定する 8. Active Directory およびグループ ポリシーの実装計画を策定する #### EFS の展開オプションについて理解する EFS は、いくつか存在するセキュリティ上の脅威に効果的に対抗できる機能です。EFS によってどのような脅威が軽減され、EFS と BitLocker を組み合わせることで他にどのような脅威が軽減されるのかを理解するには、EFS のセキュリティ モデルとサポートされている展開オプションを理解する必要があります。このツールキットに含まれている『*セキュリティ分析*』ドキュメントでは、リスクの範囲と EFS によってリスクが軽減される仕組みが説明されています。計画を進める前に、これらの内容を徹底的に理解しておく必要があります。 #### EFS を使用するための準備状況を評価する EFS の展開計画を作成する前に、EFS を展開して使用できるだけの準備が組織に整っているか、評価する必要があります。 > [!NOTE] > Active Directory 資格情報のローミング機能を使用すると、EFS の展開計画を大幅に簡略化できます。詳細については、Microsoft TechNet Web サイトの「[「資格情報の移動とは」](https://technet.microsoft.com/ja-jp/library/d052e2b5-fd73-4bd0-8018-7713049463ee(v=TechNet.10)) ページを参照してください。 ##### ハードウェアとソフトウェアの要件 EFS の場合、EFS をサポートする Windows オペレーティング システムを実行できるコンピュータ以外に、特別なハードウェアは必要ありません。Windows XP Professional、Windows Vista Business、Enterprise、または Ultimate 以外のオペレーティング システムで EFS を使用する方法についての具体的な情報は、このガイドでは取り扱っていません。 ##### その他の要件 既に一覧で示したハードウェアおよびソフトウェアの要件以外に、EFS には次の要件があります。 - 参加しているすべてのコンピュータは、Windows XP または Windows Vista を実行している必要があります。 - 暗号化するファイルとフォルダは、NTFS でフォーマットされたボリュームに格納されている必要があります。 - ファイルを暗号化するユーザーは、暗号化するファイルまたはフォルダに対して NTFS の変更アクセス許可を持っている必要があります。 - EFS で保護されたファイルを開いて変更するアプリケーションは、EFS と互換性があることが確認されている必要があります。通常、Microsoft Win32® アプリケーションはいずれも EFS と互換性があります。互換性の問題のほとんどは 16 ビットのレガシー アプリケーションで発生しますが、特殊な方法でファイル システムにアクセスするアプリケーション (ウイルス対策パッケージ、バックアップ アプリケーション、デフラグ用プログラムなど) にも特別な注意が必要です。 #### EFS の展開範囲を決定する EFS の展開計画では、EFS で保護する必要がある各コンピュータのデータを特定するだけでなく、EFS を使用するコンピュータとユーザーに関しても決定する必要があります。EFS はほとんどの Windows ベースのコンピュータで使用できるため、分析プロセスでまず保護が必要なデータを決定し、次にそのデータのコピーを所持しているユーザー、そのデータが格納されているコンピュータを特定すれば、EFS の展開範囲を完全に定義することができます。 保護が必要なデータを特定するため、次の質問について考えてください。 - 故意または事故によりデータが壊れるか変更された場合、データの回復または再作成にどの程度の労力が必要になるか。 - データの回復または再作成ができない場合、組織にとって財政的負担はどの程度になるか。 - データが不適切に漏洩または開示された場合、組織は厄介な事態に陥るか。 - データが公けにされた場合の損失はどの程度か。 - 漏洩したデータの内容に加えて、漏洩という事実そのものがダメージや損害になるか。 - 敵対的な部外者がデータを密かに入手した場合、会社に対する混乱、妨害、策謀、詐取、またはその他の悪意のある行為のためにそのデータを使えるか。 - 以上の各シナリオによって、組織にどの程度の損害が発生するか。 暗号化が必要なデータの例を次に示します。 - 契約書、交渉記録、提案依頼書、見積もり依頼書、見積もり書 (顧客によって作成されたものかベンダー向けに作成したものかを問わない)。 - 表示価格、割引予定、またはその他の価格関連情報。 - 従業員、顧客、見込み客の連絡先情報。 - 会議の議事録、プレゼンテーション資料。 - ポリシーに関するメモ、マニュアル。 - 設計書、構成図。 - 企業競争に関する調査および分析。 - 法的な保護対象となるデータ (消費者個人を特定できる情報など)。 この一覧を示した目的は、セキュリティを意識して考える習慣を促すことにあります。この一覧にすべての項目が挙げられているわけではありません。 ##### EFS を使用して暗号化することができないファイルおよびフォルダ ユーザーのアクセス許可の種類と関係なく、EFS を使用して暗号化できないファイルとフォルダは多数あります。ユーザーが操作不能な状態にならないようにするため、Windows では、特に暗号化するべきではない重要な項目については暗号化ができないようになっています。暗号化できないファイルとフォルダは、次のとおりです。 - ルート フォルダ内にあるシステムの重要なブート ファイル - %Windir% およびその子オブジェクト - ユーザー プロファイル関連のファイル (つまり、Ntuser.\*) - %APPDATA% - \\Boot (Windows Vista の場合) - \\$Recycle.Bin - システム属性がマークされたファイルまたはフォルダ - 休止状態ファイル > [!NOTE] > これらのフォルダの一部では、重要なファイルでない限り、フォルダ内のファイルの一部を暗号化できます。 EFS で暗号化できないほとんどのファイルとフォルダは、ユーザーおよび参加しているコンピュータを保護するため、暗号化から明示的に除外されます。たとえば、ユーザーの EFS 解除用の秘密キーは、ユーザーのプロファイルに格納されます。ユーザーがユーザー プロファイルを暗号化できるとしたら、Windows ではユーザー プロファイルの暗号化を解除するための解読キーを取得できないことになります。したがって、Windows ではユーザーはこのようなファイルを暗号化することができません。 > [!NOTE] > BitLocker を使用すると、起動前に重要なシステム ファイルを暗号化することができます。 Windows Vista では、システム ページ ファイル (**pagefile.sys**) など、Windows の初期バージョンでは暗号化できなかった重要なファイルとフォルダの一部を暗号化できるようになっています。 ##### 暗号化してはいけないファイルおよびフォルダ オペレーティング システムでは暗号化が許可されていますが、通常は暗号化するべきではないファイルとフォルダもあります。次にその例を挙げます。 - 共有する予定のファイル (EFS 共有が有効になっていない場合)。 - \\Program Files フォルダおよびそのサブフォルダ。 - Microsoft Exchange Server データベースなどの共有データベース。 - 別のコンピュータで利用または処理するために生成したファイル (EFS 共有が有効になっていない場合)。 > [!NOTE] > 共有データベース ファイルは暗号化しないでください。データベース プログラムだけでなく、すべてのユーザーがファイルにアクセスできる必要があります。データベース ファイルは、フィールド/属性単位で暗号化した方がより適切に保護できます。 ##### データおよびデータの場所の特定 一般的な EFS シナリオでは、Microsoft Office スイートなどの製品で作成したテキスト、グラフィック、スプレッドシート、スライド ショーなどの保護を行います。組織内の全ユーザーが既定の場所を使用してこのような文書を保存しているかどうかを確認するため、調査を実施する必要があります。既定の場所が使用されている場合、保護対象のコンピュータごとに、このフォルダ全体を暗号化する計画を立てます。 また、%TEMP% フォルダも暗号化して、このフォルダ内で作成されるアプリケーション一時ファイルを保護する必要があります。 機密データを取り扱うその他のアプリケーションについても調査し、作成データが保存される場所を確認する必要があります。 すべての機密データとアプリケーション データが保存される既定の場所を確認したら、ポリシーを文書化して、これらのフォルダで暗号化を有効にする方法をユーザーに通知する必要があります。また、ポリシーの自動化を構成、展開して暗号化を自動的に有効にする計画も立てる必要があります。 ##### 暗号化対象とする共通のディレクトリ構造 ユーザーが機密データ ファイルを現状どこに保存しているかを知って驚かされることがあります。この取り組みの主なポイントは、ドキュメントを My Documents\\Sensitive フォルダに保存するようにユーザーに義務付けるというようなことではなく、C:\\ や C:\\WINDOWS といった暗号化してはいけないディレクトリまたは暗号化できないディレクトリにデータを保存しないよう、ユーザーに徹底することにあります。 保護対象のすべてのラップトップで共通のディレクトリ構造を作成すると、保守が簡単になります。当然ながら、最も簡単な方法は、すべてのドキュメントを My Documents の下に保存して My Documents ツリー全体を暗号化するようにポリシーを設定することです。ほとんどの組織ではこの方法で十分ですが、この方法には制約も多いため、組織によってはさらに複雑で柔軟性のあるポリシーを定義する場合があります。 一部のアプリケーションは、機密データが含まれる一時ファイルまたはキャッシュ ファイルを作成します。そのようなファイルが含まれるディレクトリを保護するために、EFS およびこのガイドに付属する EFS アシスタント ツールを使用することができます。ただし、アプリケーションのテストを実施して、一時ディレクトリまたはキャッシュ ディレクトリを暗号化したときに適切に動作するかどうかを確認する必要があります。 #### EFS 構成オプションの選択 EFS の展開範囲を決める場合、EFS 計画プロセスの次の手順として、組織のコンピュータに適用する EFS のオプションと構成を選択します。検討して計画する必要があるオプションは次のとおりです。 - 自己署名入りの証明書と CA で発行された証明書のどちらを使用するかの選択。 - EFS 証明書およびキーの格納用にスマート カードを使用するかどうかの選択。 - 暗号化に使用する暗号の種類とキー サイズの選択。 - 証明機関 (CA) がないときに自己署名入りの証明書を EFS で使用できないようにする機能。 > [!NOTE] > この機能は Windows Vista には含まれています。Windows XP でこの機能を使用するには、マイクロソフト サポート技術情報 912761「[暗号化ファイル システム (EFS) では、Windows XP ベースのコンピュータで EFS ファイルを暗号化しようとすると自己署名入りの証明書が生成される](https://support.microsoft.com/kb/912761) Windows Vista ベースのコンピュータでは、次のようないくつかの追加オプションを利用できます。 - ユーザーの Documents フォルダのコンテンツを暗号化する - EFS でスマート カードの使用を必須とする - すべての暗号化操作で直接スマート カードを使用する - ページ ファイルの暗号化を有効にする - ユーザー キーが作成されるか変更された場合、キーのバックアップに関する通知を表示する 一部の構成オプションは Windows Vista でしか利用できないため、組織内の特定部署のセキュリティ要件によっては、一部のコンピュータのオペレーティング システムのアップグレードも計画に組み込むことが必要になる場合があります。 ##### デジタル証明書に関する戦略の選択 EFS のデジタル証明書は、自己署名入りの証明書でも、信頼された CA で発行された証明書でもかまいません。ユーザーが初めて EFS を使用したファイルまたはフォルダの暗号化を試みたとき、使用できる既存の証明書やキーの有無が Windows によってチェックされます。既存の証明書やキーが見つからなかった場合、Windows は証明書やキーを取得するため、発行 CA へのアクセスを試みます。アクセスに失敗した場合、Windows はユーザーのために自己署名入りの証明書を生成します。自己署名入りの証明書は、本物であることを証明するより高いレベルの信頼できる署名機関がない場合に使用されるデジタル証明書です。外部の組織にとっては、自己署名入りのデジタル証明書は信頼できませんが、 EFS など内部のアプリケーションで使用する場合、自己署名入りのデジタル証明書で十分です。 一般的に、自己署名入りの EFS デジタル証明書は、最初の実装は簡単ですが、運用上の管理作業が困難です。適切な PKI サービスが既に実装されている場合は、CA で生成された証明書を選択することをお勧めします。 > [!NOTE] > PKI プラットフォームのない企業は、EFS を有効にして利用する前に、証明書サービスを実装することを検討する必要があります。証明書サービスは、Microsoft Windows 2000 Server 以降のサーバー製品で利用できます。EFS デジタル証明書のライフ サイクル管理と回復ソリューションの自動化を行えば、全体的な手間とコストを軽減できるという利点があります。 グループ ポリシーまたはローカル コンピュータ ポリシーを使用すると、利用できる CA が存在しない場合、自己署名入りの EFS 証明書を生成する機能を有効または無効にすることができます。以降のセクションでは、このオプションについて説明します。 管理者は、それぞれのデジタル証明書の長所と短所を確認し、目的に合ったソリューションを選択してください。一度 EFS を実装した後に EFS デジタル証明書の信頼連鎖の方法を変更するのは、きわめて面倒な作業になる可能性があります。 ###### EFS 自己署名入り証明書の長所と短所 自己署名入りの証明書は、有効な EFS インフラストラクチャを構築する最も簡単な方法です。自己署名入りの証明書は、互換性のある利用可能な PKI CA が検出されない場合に EFS クライアントに対して自動的に発行されます。自己署名入りのデジタル証明書の生成とインストールは、操作中のユーザーには見えないところで迅速に実行されます。既定では、自己署名入りの証明書の有効期間は 100 年間です。 ただし、自己署名入りのデジタル証明書には、次のようないくつかの大きな短所があります。 - 自己署名入りのデジタル証明書は有効期間が長いため、有効期間中に侵害される可能性が高くなります。 - 中央の CA ではなく、各コンピュータで証明書を取り消す必要があるため、自己署名入りのデジタル証明書を取り消すには多くの労力が必要になります。 - 暗号化されたファイルの共有が困難です。自己署名入りの証明書は Active Directory で発行されないため、手動で移動しない限り、他のコンピュータにアクセスできません。 - キーをアーカイブするための一元的な場所がないため、キーのアーカイブを自動化するには労力が必要になります。 ###### 証明機関から発行された EFS 証明書の長所と短所 中央の CA から EFS 証明書を発行する方法を採用すると、非常に大きな利点があります。この方法の場合、デジタル証明書を一元的に管理できます。また、生成されたデジタル証明書の有効期間が短いため、セキュリティ リスクも軽減されます。キーと証明書のマテリアルには CA からアクセスできるため、更新、取り消し、キー更新、アーカイブなどをすべて簡単に自動化できます。また、証明書テンプレートを変更することで、さまざまな証明書パラメータを調整できます。さらに、証明書を Active Directory に発行するとユーザーはお互いの証明書を簡単に見つけることができるので、EFS で暗号化されたファイルを共有できるようになります。 ただし、CA で発行された EFS 証明書には特有の短所もあります。第 1 に、EFS を展開する前に、EFS と互換性のある利用可能な CA を実装する必要があります。第 2 に、CA で発行された証明書の有効期間は短いため、証明書のキー更新を高い頻度で実行する必要があります。最も重大な点は、Windows ベースのコンピュータが参加している CA にアクセスできない場合、自己署名入りの EFS 証明書が独自に発行されることです。この機能が存在するために、CA で署名された証明書と自己署名入りの証明書が混在する環境が生じて、EFS デジタル証明書の管理が複雑になる可能性があります。この潜在的な問題は、必要な CA サービスを実装するまでは、グループ ポリシーを構成して EFS での自己署名入りの証明書の使用を無効にするか、EFS を全面的に無効にすることで回避できます。 自動登録を使用して EFS で使用するクライアント証明書を発行する場合は、この章の後半にある「Active Directory およびグループ ポリシーの計画を策定する」の項をよく読み、Active Directory インフラストラクチャで自動登録がサポートされていることを確認してください (フォレスト内に最低でも Windows Server 2003 ドメイン コントローラが必要です)。 ##### EFS とスマート カード Windows XP と Windows Vista は両方とも、スマート カードと EFS の併用をサポートしています。『*セキュリティ分析*』で説明したように、スマート カードと EFS を併用すると、攻撃者がユーザーのパスワードを入手してコンピュータにログオンし、EFS で保護されたファイルを回復しようとするリスク (EFS の主要なリスク要因の 1 つ) を軽減できます。スマート カードと EFS の併用を必須にすると効果的に保護機能を追加できますが、そのための方法は Windows XP と Windows Vista で異なります。 Windows XP では、ログオン時にスマート カードを要求できます。オプションで、非アクティブまたはロックされたデスクトップのロックを解除するときにも要求することができます。このようなシナリオでは、スマート カードの存在を必須とし、EFS キーのロックを解除してファイルに対してキーを使用できる唯一の方法にすれば、EFS キーの保護を強化できます。 Windows Vista では、ログオン時およびロック解除のときにスマート カードを要求できます。また、EFS で保護されたファイルの暗号化または暗号化解除を行うごとに、カードの存在を必須とすることも可能です。既定では、Windows Vista によって暗号化キーが生成され、EFS の操作で使用するためにキャッシュされます。セキュリティを強化するため、Windows Vista では、すべての暗号化操作で代わりにスマート カードを直接使用できます。ただし、ユーザーにとってはこの方法は利便性に欠けており、動作もキャッシュ キー モードよりはるかに遅くなります。したがって、環境によってはこの方法は望ましくありません。 > [!NOTE] > Windows Vista および Windows XP でサポートされている EFS のモードの詳細については、『*セキュリティ分析*』の「第 3 章 : 暗号化ファイル システム」を参照してください。 ###### スマート カードの長所 スマート カードは、物理的に安全な携帯パッケージという形で強固な暗号化セキュリティを実現するために設計されたものです。これらのカードでは、署名、認証、暗号化、および解読の情報がホスト コンピュータからスマート カード自体に移されることで、セキュリティが付加されます。暗号化キーはスマート カードに安全に格納されており、通常は、よほどの知識と資金に恵まれた攻撃者の手にかからなければ安全と考えられます。スマート カードと関連付けられた証明書は、電子メールの S/MIME 保護、Web アプリケーションやリモート アクセス向けの証明書ベースの認証、安全性が向上したデスクトップ ログオンなど、さまざまなセキュリティ強化機能に使用できます。スマート カードの使用を必須とした場合、基本的に 2 要素の認証の使用が強制されます。認証を受けるユーザーは、カードの他にも関連するパス フレーズまたは PIN を所持している必要があるためです。また、各ユーザーの資格情報はカードに格納されるため、資格情報のローミング システムをセットアップする必要はありません。 ###### スマート カードの短所 スマート カードには、注目すべき欠点がいくつかあります。第 1 に、カードと共にカードの読み取り装置を展開する必要があるため、組織によっては非常に大きなコスト負担になる可能性があります。カードの証明書の発行/管理メカニズムを PKI と統合する必要があるため、スマート カードの展開が複雑になり、コストも増加する可能性があります。スマート カードの使用を必須とする組織は、カードの発行と追跡を行う手続きを決める必要もあります。この手続きは、脆弱性が生じることを防ぐために慎重に管理する必要があるセキュリティ関連の活動です。Microsoft [Identity Lifecycle Manager 2007](https://www.microsoft.com/windowsserver/ilm2007) (ILM 2007) を展開すると、スマート カードの展開プロセスを円滑に進めることができます。 ##### 暗号化に使用する暗号の選択 EFS は、さまざまな暗号とキー強度の設定で実装できます。暗号の種類とキー強度は、2 つの*異なる* EFS オブジェクト、すなわち、ユーザーの個人的な EFS 非対称キーと、ファイルの共有対称ファイル暗号化キー (FEK) で選択できることを理解しておくことが重要です。EFS で保護されたすべてのファイルには、1 つの対称 FEK が含まれます。EFS で保護された各ファイルのファイル データは、そのファイルの FEK によって暗号化されます。 承認された各ユーザー (または回復エージェント) に、ファイルの FEK のコピーが割り当てられます。これは、ユーザーの EFS 証明書の公開キーで暗号化されます (ユーザーが持つ対応する秘密キーでのみ解除できます)。ユーザーが EFS で保護されたファイルにアクセスする必要がある場合、ユーザーの個人的な秘密非対称 EFS 暗号化キーを使用して、ファイルの FEK の暗号化されたユーザーのコピーの暗号化が解除されます。この時点で暗号化が解除された対称 FEK を使用して、EFS で保護されたファイルの暗号化が解除されます。暗号の種類とキー強度を決めるときには、2 種類の EFS キーの違いについて理解していることが重要です。 ###### サポートされている暗号 FEK の暗号化アルゴリズムで使用される暗号を、強度の低いものから順に示します。 - Data Encryption Standard (DES) - Data Encryption Standard Expanded (DESX) - Triple Data Encryption Standard (3DES) - Advanced Encryption Standard (AES) Windows Vista、Windows XP Professional (SP1 以降)、および Windows Server 2003 では、既定で強力な AES 暗号が使用されています。Windows XP Professional の以前のバージョンでは、既定で DESX が使用されていますが、より強力な 3DES 暗号に切り替えることができます。それには、グループ ポリシーまたはローカル コンピュータ ポリシーを使用して、あるいはレジストリを直接編集して、**\[暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う\]** セキュリティ ポリシー オプションを有効にする必要があります。Windows 2000 では、EFS の暗号として DES または DESX が使用されています。Windows 2000 SP1 以降のバージョンでは、DESX が自動的に使用されます。 Windows XP Professional SP1 以降または Windows Server 2003 で FIPS オプションを有効にすると、暗号化による保護が実際上 AES から 3DES に変更されます。ただし、FIPS オプションを有効にする場合、強度の低い Secure Sockets Layer (SSL) ではなく Transport Layer Security (TLS) を使用して安全な Web トランザクションを実現するため、インターネット インフォメーション サービス (IIS) サーバーおよび Microsoft Internet Explorer® クライアントが必要になります。サーバー レベルでは、強度の高い TLS を必須にすることもできます。そのために FIPS セキュリティを有効にして、Windows XP ベースのレガシー クライアントでの対称キー セキュリティを低下させる必要はありません。 自己署名入りのキーの場合も Microsoft ベースの証明機関で発行されるキーの場合も、FEK の暗号化に使用される既定の非対称暗号アルゴリズムは RSA です。 > [!NOTE] > 使用される既定のアルゴリズムは常に、その時点で利用可能な中で最も安全な暗号です。Windows の各バージョンでは、以前のバージョンでサポートされていたすべての暗号を取り扱うことができます。法規制上または標準への準拠のために求められる場合を除いて、EFS の暗号設定は変更しないことをお勧めします。 ###### EFS キーのサイズ Windows XP および Windows Vista の場合、FEK キーのサイズにはそれほど柔軟性はありませんが、ユーザーの非対称キーおよびファイルの FEK 暗号キーのサイズには柔軟性があります。FEK の暗号アルゴリズムを選択すると、FEK の対称キーの強度も決まります。大きなキー サイズを使用すればそれだけ EFS の保護も強力になりますが、使用しているアルゴリズムによっては、パフォーマンスが大幅に低下する可能性もあります。 **ユーザーの非対称キーのサイズ** 一般的に、EFS 非対称キーのサイズは、1,024 ～ 16,384 ビットです。通常使われるキー サイズは、 1,024、2,048、4,096、8,192、および 16,384 ビットです。Windows Vista では、既定のキー サイズは 2,048 ビットです。この値はほとんどすべての EFS アプリケーションに対して十分な強度を持っています。新しい EFS を展開する場合、この既定のキー サイズを維持することを強くお勧めします。以前のバージョンの Windows では、既定のキー サイズは 1,024 ビットでした。 **対称 FEK のサイズ** EFS の対称 FEK 暗号は通常、以前のバージョンの Windows では 56 ビット、Windows Vista の AES では 256 ビットです。Windows 2000 の場合、高度暗号化パックまたは SP1 以降がインストールされていれば 128 ビットの DESX キーが使用されており、インストールされていなければ 56 ビット キーが使用されています。Windows XP SP 1 (以降) および Windows Server 2003 では、既定で 256 ビットの AES が使用されています。SP1 よりも前のバージョンの Windows XP では DESX が使用されていましたが、168 ビットの 3DES が使用されるように設定することができました。 一般的に、ほとんどのユーザーは既定の EFS FEK 暗号を使用すれば十分です。ただし、一部の組織では、以前の暗号化アルゴリズムの暗号やカスタムのキー サイズを代わりに使用する必要があります。 ##### EFS と Windows Vista Windows Vista では、EFS の機能が大幅に強化されています。次に挙げる強化機能を適切に利用できるように、Windows Vista を展開する場所と方法を検討することが必要です。 - EFS でスマート カードの使用を必須とする機能。この機能を使用すると、セキュリティ面でも管理性の面でも大きな利点を得られます。スマート カードを管理するための既存のプロセスで EFS を管理できるからです。 - すべての暗号化操作でスマート カードを直接使用する機能 (非キャッシュ モード)、または取得した暗号化キーを Windows で格納する機能 (キャッシュ モード)。『*セキュリティ分析*』の「第 3 章 : 暗号化ファイル システム」で詳細に説明しているこれらのモードを利用すれば、セキュリティ、パフォーマンス、およびユーザーの利便性の間のバランスを取ることができます。 - システムのページ ファイルを暗号化する機能。この機能を使用すると、Windows の停止時に攻撃者がページ ファイルを参照できなくなるため、機密情報の漏洩防止に役立ちます。 - 既存のキーの更新時、またはキーの新規作成時にキーのバックアップをユーザーに促す機能。 - 証明機関 (CA) がないときに EFS で使用する自己署名入り証明書をユーザーが作成できなくする機能。この機能を使用すると、公開キー基盤の外部での EFS の使用を制限できます。 以上の機能が組織にとって重要である場合、EFS の展開と Windows Vista の展開を調整しながら行う方法を検討する必要があります。Windows 展開ウィザードでは、ライト タッチ展開の一部として BitLocker を有効化できます。EFS にも類似の機能があり、機密ファイルが自動的に保護されるように、ユーザー証明書の自動登録を有効にして、EFS アシスタントをインストール (Windows Vista イメージの一部として、またはその他の手段を通じて) することができます。 ##### EFS とファイル共有 Windows XP Professional で運用を開始すると、EFS で保護されたファイルとフォルダは他のユーザーと共有できます。ファイルまたはフォルダを暗号化した最初のユーザー (または EFS データ回復エージェント) は、ファイルまたはフォルダに他のユーザーを追加する必要があります。他のユーザーは、既に有効な EFS デジタル証明書を持っている必要があります。 書き込み、削除、または変更のアクセス許可を持っている他のユーザーは、EFS で保護されたファイルまたはフォルダの暗号化/暗号化解除のアクセス許可を持っていなくても、そのファイルおよびフォルダを変更または削除できる場合があります。EFS は機密性を保護する機能であるため、許可されていないユーザーは保護されたファイルの読み取り、表示、または印刷を実行することはできません。ただし、ファイルの内容を表示または読み取ることをしない状態でファイルを操作すること自体は可能です。複数のユーザー間でファイルを共有する機能が重要である場合、ファイルを暗号化する担当者、ファイルの読み取りを許可されるユーザー、暗号化されたファイルの共有ユーザーの追加または削除を行う権限を持つ担当者が、組織のポリシーで明確に規定されていることを確認する必要があります。 #### キーとデータの回復計画を策定する EFS を展開することを選択した組織は、退職したユーザーをワークステーションから除外する場合とか、EFS 証明書やキーが壊れた場合のような、特定の状況でデータを回復する方法に関して慎重に計画を立てておく必要があります。EFS のデータ回復計画の最も重要なタスクについては、Windows XP に関するドキュメント『Data Protection and Recovery in Windows XP』の「[Data Recovery Overview](https://go.microsoft.com/fwlink/?linkid=139246)」(英語) で説明されています。このセクションは、計画の際に考慮する必要がある問題についての補足的なガイダンスです。 EFS は安全なファイル暗号化ソリューションです。保護されたファイルの暗号化解除に使用する暗号化キーが使用できなくなった場合、保護されたファイルも同様に使用できなくなる可能性があります。暗号化されていない状態でのデータのバックアップが存在しない場合、または暗号化されたデータの回復方法が展開されていない場合、この保護されたファイルは永久に使用できなくなります。 このガイドで既に説明したように、EFS は、対称キーと非対称 (公開/秘密) キーのアルゴリズムを組み合わせてデータを保護します。既定のシナリオでは、対称のファイル暗号化キー (FEK) が生成され、このキーが X.509 証明書から取得した公開キーを使用して暗号化されます。EFS で暗号化されたデータのバックアップ戦略には、2 つの異なる方法を利用できます。 - X.509 証明書と関連付けられた秘密キーのバックアップを作成します。この方法は通常、キー回復と呼ばれています。保護されたファイルへのアクセスを確保する方法として、キー マテリアルの保護に重点を置いているためです。 - 異なる証明書でコピーされた FEK の暗号化コピーを別途作成します。この方法はデータ回復と呼ばれています。元のキーまたは証明書が失われた場合でもデータを回復できるためです。 ##### キー回復 キー回復とは、公開キー/秘密キーのペアから秘密キーの部分をアーカイブして、必要に応じて回復できることを表します。キーの格納先がスマート カードであれローカル コンピュータであれ、ユーザーの秘密キーが損失または破損した場合、バックアップからキーを回復することができます。秘密キーが回復されれば、あらゆるデータ (正確に言えば FEK などの暗号化されたあらゆる対称キー) の暗号化を解除できます。Windows の場合、この機能を使用するには 2 つの方法があります。キー回復エージェントを使用するか、または手動でキーをアーカイブします。 ###### キー回復エージェントを使用する 証明書サービスまたは互換性のある別の CA を使用している場合、キー回復エージェント (以下「KRA」) を使用してファイルの回復を実行できます。発行 CA で、EFS デジタル証明書は発行時に自動的にアーカイブされます。KRA を使用すると、このアーカイブから失われた EFS キーを回復できます。EFS DRA と KRA の働きの主な違いは、EFS DRA の場合、EFS で保護されたすべての参加ファイルに明示的にアクセスできますが、KRA の場合、格納された他のユーザーのキー コピーのみを回復できます。また、KRA を使用した場合、EFS の範囲を超えるデジタル証明書のキー回復イベントに参加できます。 キーのアーカイブを必須とするように証明書テンプレートを構成している場合、キー アーカイブは証明書登録プロセスの一環として自動的に実行されます。このように構成されている場合、秘密キーは証明書要求の一環として CA に送信され、CA によって自動的にアーカイブされます。 [Windows Server 2003 でのキーのアーカイブと管理](https://technet.microsoft.com/ja-jp/library/296f87df-06c3-4e27-89ff-5283cb76fb81(v=TechNet.10)) を参照してください。 ###### 手動でキーをアーカイブする EFS の展開が自己署名入りの証明書に依存している場合、手動でのキー アーカイブが FEK の暗号化解除に必要な秘密キーのバックアップを作成する唯一の方法になります。既定では、すべての EFS ユーザーが、EFS デジタル証明書と EFS 秘密解読キーのバックアップを作成できます。Windows Vista では、キーを作成または変更するたびに、キーのバックアップを促すダイアログが表示されます。Windows 2000 の後にリリースされたすべてのバージョンの Windows で、ユーザーは 2 つ以上の方法で EFS キーを手動でバックアップできます。セキュリティ ポリシーで許可されている場合、ユーザーは EFS キーのバックアップを作成し、信頼性の高いストレージ メディアを使用して、2 か所以上の別々の安全な場所にキーを保管する必要があります。 手動でキーをアーカイブする場合、ユーザーは手動で秘密キーをエクスポートして CA 管理者に送信します。次に、CA 管理者はこれらを保護された CA データベースにインポートします。 この方法の場合、独自に回復キーを用意する責任をユーザーに委ねることができます。ただし、大きな規模の組織では監視と規制が難しくなり、ユーザーが EFS キーをアーカイブしたかどうかを正確に確認できなくなります。このことはどちらも、ポリシーの準拠には重要な要素です。 ##### データ回復 データ回復は、キー回復とはプロセスがやや異なり、特定の X.509 証明書と関連付けられたキーのアーカイブは使用しません。その代わり、このプロセスでは暗号化されたファイルにアクセスするための冗長パスが作成され、そのために暗号化された別の FEK が作成されます。FEK はそれぞれ、異なる X.509 証明書から取得した公開キーを使用して暗号化されます。このプロセスで作成される追加のキーは、データ回復エージェントと呼ばれます。 ファイルを暗号化すると、Windows によって自動的にファイルの FEK のコピーが作成され、DRA の公開 EFS キーを使用してこのコピーが暗号化されます。つまり、EFS で保護されたファイルならどれでも、DRA によって暗号化を解除できます。 DRA の主な利点は、EFS で保護されたすべてのファイルに対して、ファイルの FEK のコピーが既定で自動的に作成されることです。この場合、ユーザーがバックアップ キーを手動で作成する必要はありません。最大の短所は、DRA のユーザー アカウントが侵害された場合、侵入者が EFS で保護されたファイルにアクセスできることです。 > [!NOTE] > DRA ユーザー アカウントを保護するには、セキュリティの強度が高い方法を使用する必要があります。また、回復エージェントの EFS 回復キーをエクスポートして外部に保管すれば、エージェントのアカウントが侵害された場合にも EFS への侵害を防止することができます。EFS 回復キーは必要に応じて後からインポートできます。 データ回復とデータ回復エージェントを実装すれば、すべての暗号化されたファイルの暗号化キーは、DRA の公開キーとユーザーの公開キーを使用して暗号化されます。関連付けられた秘密キーを使用することで、EFS 回復ポリシーの範囲内で暗号化されたファイルは、指定された DRA によってすべて暗号化を解除できます。 ##### 回復ポリシーの定義 回復ポリシーでは、データの回復を許可するユーザー、および回復プロセスを実行できる状況を定義します。この定義作業は、EFS の計画の中でも重要な手順です。ポリシーでは次のことを定義する必要があります。 - 自分自身でデータを回復することを許可されるユーザーまたは役割。 - 他のユーザーのデータを回復することを許可されるユーザーまたは役割。 - データ回復に適用される業界規制または法規制。 - 誤用されないようにデータ回復ツールの利用状況を監視する方法。 - 回復パスワード マテリアルを収集、保存、保護する方法。 - 回復操作を実行するために使用できるワークステーションまたはリソース。 可能な場合は、回復ポリシーの 2 つのベスト プラクティスからどちらかを選択することをお勧めします。回復を実行する場合に最も望ましい方法は、DRA 証明書を発行してスマート カードに格納し、スマート カードと PIN を別々に保管する方法です。Windows Vista ベースのコンピュータでは、このスマート カードとその関連付けられた証明書を使用して、ドメイン内のクライアントからデータを回復できます。この組み合わせは、DRA 資格情報に対して 2 要素の強力な保護を提供します。また、スマート カードと PIN へのアクセスを強制的に分離すれば、回復プロセスについても職務の分離を徹底できます。 この方法が現実的ではない環境では、データ回復専用に使用するコンピュータを別に決めて、構成することをお勧めします。このような回復ワークステーションは物理的な安全を確保し、回復するデータの価値に合わせて、監査とセキュリティ対策を追加で適用する必要があります。 ###### DRA の有効期限に関する計画の策定 EFS データ回復エージェントは証明書を使用しますが、これらの証明書の有効期限も、他の証明書と同様に最終的に切れることになります。ただし、通常の証明書は、前方機密性を保持するために使用されます。前方機密性を保持するとは、将来に向けての一定期間暗号化しておく必要があるマテリアルを保護することです。前方機密性を保持するには、キーの再割り当てを実行できるように、証明書に関連付けられたキーが将来の特定の時期に期限切れになる必要があります。 DRA は、前方機密性とは逆の機能を提供します。つまり、DRA では過去のデータを回復することができます。言い換えると、DRA 証明書の有効期間内に暗号化されたデータであれば、有効期限が切れた DRA 証明書であってもデータの回復に利用できるということです。データの古さに関係なくデータを回復できる機能を維持するには、必要なときに使用できるように、DRA 証明書をストレージ メディアにアーカイブする計画を立てる必要があります。 DRA 証明書の有効期限が切れた場合、証明書を再発行するか、キーを更新します。このいずれかを実行すると、新たに暗号化されたデータを回復するために DRA を使用することができます。ただし、以前の DRA で保護されたデータを回復するには、以前の DRA 証明書のコピーを保持する必要があります。DRA の有効期限に対処する (つまり、期限切れを防止する) ための手続きとポリシーを設定する場合は、次の点を考慮してください。 - アクティブな DRA 証明書が 1 つでも有効期限切れになると (クライアントに構成済みの複数の DRA 証明書がある場合であっても)、Windows は新しいファイルの暗号化を拒否します。つまり組織は、グループ ポリシーが適用されるまでの待ち時間中にクライアントの DRA 証明書の期限が切れて無効になる事態を避けるため、新しい DRA 証明書を発行して期限切れの近い証明書と置き換える作業が十分な時間の余裕をもって行われているかどうかを確認する必要があります。 - DRA 証明書の置き換え (およびその後の、任意ながらクライアント ファイルの更新に必要な手順) は簡単な作業ですが、複数の手順を踏む必要があります。 - DRA を構成するグループ ポリシー オブジェクト (GPO) には、複数の DRA を含める必要があります。この方法は、1 つの DRA 秘密キーにアクセスできなくなったために生じるデータ損失に対して、冗長性の高い保護対策となります。 ###### データ回復ポリシーのレベルの決定 管理者が初めてドメイン コントローラにログオンしたとき、ドメインを対象にした既定の回復ポリシーが自動的に設置されます。これにより、管理者がドメインの回復エージェントになります。Windows XP、Windows Vista、および Windows Server 2003 では、ファイルを暗号化するために回復ポリシーを有効にする必要がなくなりました。 スタンドアロンのコンピュータに適用される既定の回復ポリシーは、ローカルで構成されます。Active Directory ベースのドメインに参加しているコンピュータの場合、回復ポリシーはサイト、ドメイン、組織単位 (OU)、または個々のコンピュータ レベルで構成され、指定された適用範囲内の Windows 2000、Windows Server 2003、Windows XP、および Windows Vista ベースのすべてのコンピュータに適用されます。回復証明書は CA によって発行され、Microsoft 管理コンソール (MMC) の \[証明書\] スナップインを使用して管理できます。 ネットワーク環境では、適用範囲内のすべてのユーザーとコンピュータを対象とした回復ポリシーで、ドメイン管理者が EFS の実装方法を管理します。既定の Active Directory インストールでは、最初のドメイン コントローラがセットアップされるときに、ドメイン管理者がそのドメインの回復エージェントになります。ドメイン管理者が回復ポリシーを構成する方法によって、ローカル コンピュータのユーザーに対して EFS が実装される方法が決まります。ドメインの回復ポリシーを変更するには、ドメイン管理者がクライアント コンピュータまたはドメインに接続されたサーバーから、グループ ポリシー エディタを使用します。スタンドアロン コンピュータ (ドメインに未参加) の場合、自己発行の管理者アカウント DRA 証明書の有効期間は 100 年間です。ドメインに参加しているコンピュータの場合、ドメイン管理者に発行される既定の DRA 証明書の有効期間は 3 年間になります。 管理者は、次の 3 種類のポリシーのいずれかを定義できます。 - **回復エージェント ポリシー**。管理者が 1 つ以上の回復エージェントを追加すると、回復エージェント ポリシーが有効になります。これらのエージェントは、管理の範囲内で暗号化されたデータを回復する責任を負います。回復エージェント ポリシーは、最も一般的な回復ポリシーです。組織内での管理作業の負担を分散するために、回復エージェント ポリシーを使用することができます。組織単位でグループ化されたコンピュータ カテゴリには、代替の EFS 回復アカウントを指定できます。また、ポータブル コンピュータを対象にした暗号化データ回復エージェントの設定を構成して、ポータブル コンピュータをドメインに接続してもスタンドアロン コンピュータとして動作していたときと同じ回復エージェント証明書が使用されるようにすることもできます。 - **空の回復ポリシー**。管理者がすべての回復エージェントと公開キー証明書を削除した場合、空の回復ポリシーが有効になります。空の回復ポリシーとは、つまり回復エージェントが存在しないということです。クライアントのオペレーティング システムが Windows 2000 の場合、この構成では EFS は無効になります。Windows XP クライアントでは、空の DRA ポリシーでも EFS を使用することができます。 - **回復ポリシーが存在しない**。管理者が特定の回復ポリシーと関連付けられた秘密キーを削除した場合、有効な回復ポリシーが存在しなくなります。利用できる秘密キーがないため、回復エージェントを使用する方法がなく、回復は実行できなくなります。この種のポリシーは、データ回復を行う必要がない Windows 2000 および Windows XP クライアントの混在環境にある組織に便利です。 Active Directory 環境の場合、ドメイン管理者が既定の DRA ですが、この職務は 1 人以上のユーザーに委任するか、割り当てる必要があります。 ##### 適切なメカニズムの選択 [Windows Server 2003 でのキーのアーカイブと管理](https://technet.microsoft.com/ja-jp/library/296f87df-06c3-4e27-89ff-5283cb76fb81(v=TechNet.10)) を参照してください。実施する戦略または戦略の組み合わせを決定する前に、この情報に目を通しておくことを強くお勧めします。 #### 管理性に関する計画を策定する EFS の計画プロセスの中でも重要な手順が、EFS が組織の IT 管理プロセスに与える影響を判断することです。EFS は、組織で行われている次のような継続的な管理プロセスに影響します。 - イメージング、バックアップ、およびマルウェア対策ソフトウェアとの統合 - EFS とファイル共有の計画 - コンピュータの配置転換 ##### イメージング、バックアップ、およびマルウェア対策ソフトウェアとの統合 サードパーティ製のほとんどのイメージング、バックアップ、およびマルウェア対策アプリケーションは、EFS と併用できるように設計されており、テストで互換性が確認されています。組織で使用されているこれらのツールを理解し、EFS と併用した場合のツールをテストすることは、IT サービスの契約条件を確実に満たすために不可欠な計画手順です。テストの条件には、組織の要件に応じて、アプリケーションで暗号化されたデータを適切に操作できるかどうか、ツールで暗号化の状態が維持されるかどうかといった項目も含める必要があります。 ###### ファイルのコピーと移動 EFS で保護されたファイルをコピーまたは移動すると、ファイルの暗号化の状態が変化する場合があります。ファイルのコピーまたは移動が暗号化に及ぼす影響について、基本的な規則を次に紹介します。 - *同じコンピュータ上*で特定の NTFS パーティションから別の NTFS パーティションへファイルまたはフォルダをコピーした場合、ファイルはコピー先で暗号化されます。 - コンピュータ上の NTFS パーティションから別の種類のパーティションへファイルまたはフォルダをコピーした場合、そのパーティションが同じコンピュータ上にあるかどうかに関係なく、コピーは暗号化されません。これは、コピー先のファイル システムで暗号化がサポートされていないためです。 - 2 台のコンピュータの NTFS パーティションの間でファイルまたはフォルダをコピーした場合、リモート コンピュータでユーザーがファイルの暗号化を許可されているなら、コピー先のファイルが暗号化されます。それ以外の場合、ファイルは暗号化されません。委任を行うには、リモート コンピュータが信頼済みであることが必要です。ドメイン環境の場合、リモートからの暗号化は既定では有効にされていません。 ファイル データを参照せずにファイル全体をコピーするメンテナンス ユーティリティは、通常どおりに動作します。たとえば、Windows バックアップ ユーティリティ (およびその他のほとんどのバックアップ プログラム) は、バック アップするファイルの NTFS ストリーム データ全体を読み取ります。したがって、バックアップ ユーティリティは、ユーザーのキー マテリアルにアクセスしなくても処理を続行できます。この方法でバックアップされたファイルは、バックアップ メディア内で暗号化された状態のまま保たれます。 > [!NOTE] > Windows Vista に搭載されたバックアップ ユーティリティでは、EFS で暗号化されたファイルをバックアップできません。サードパーティ製のバックアップ ツールを使用していない場合、Robocopy ツールに /efsraw スイッチを指定すれば、Windows Vista を実行しているコンピュータ上の EFS で保護されたファイルのバックアップを自動的に作成できます。 ###### ディスク イメージング ツール 同様に、ファイル システム全体の内容を取得するディスク イメージング ツールは、保護されたファイルの EFS 状態をそのまま保持します。このようなツールは、ディスクから個々のブロックを読み取るためです。EFS で保護されたデータがあるコンピュータのイメージを作成すると、イメージの一部として EFS で保護されたデータが含まれます。一部のイメージング ツールでは、イメージを対象コンピュータに復元しなくても、イメージを開いてイメージ内の個々のファイルを参照または変更することができます。通常、これらのツールでは、EFS で暗号化されたファイルを適切に操作できません。ファイルを開いているコンピュータに適切なキー マテリアルがない限り、イメージ内の暗号化されたファイルを開いたり、変更したりすることはできません。 ###### マルウェア対策ツール マルウェア対策プログラム (ウイルス対策ソフトウェア、スパイウェア対策ソフトウェアなど) の動作は、一般的に次の 2 種類の方式に分けられます。 - ファイルを開こうとするユーザーの操作を検知し、ユーザーがファイルにアクセスする前にファイルをスキャンして、マルウェアの有無をチェックします。このメカニズムを使用するプログラムは通常、EFS と併用できます。スキャンが実行されるのはアプリケーションによってファイルのデータが要求された後であり、この要求はユーザーのセキュリティ コンテキスト内で作成されるためです。 - ファイルの所有者が誰かに関係なく、システム アカウント (LOCAL SYSTEM または NETWORK SERVICE など) を使用してコンピュータ上のファイルをスキャンします。このメカニズムを使用するツールは通常、EFS で保護されたファイルをチェックできません。ファイルを開こうとすると、「アクセスが拒否されました」というエラーが表示されるためです。 個々のマルウェア対策プログラムは、この 2 つの方式を組み合わせたものです。マルウェア対策ソリューションのマニュアルを参照し、ソリューションのテストを実施して、EFS で保護されたファイルを現在の環境で適切に操作できるかどうかを確認してください。 ##### EFS とファイル共有の計画 組織内の複数のユーザー間で機密データを共有する必要がある場合、データの保存先としてファイル サーバーの一般的な共有フォルダを使用する方法と、Web フォルダを使用する方法があります。どちらの方法の場合も、EFS をサポートする構成を行う必要があり、次に説明するような問題点、利点、およびリスクを理解しておく必要があります。 - 暗号化されたファイルをリモート ファイル サーバーに保存する場合、サーバーにはファイルのプレーンテキスト コピーが保存されるようにするか、または暗号化された状態のままファイルをサーバーに保存する必要があるかを選択できます。モバイル PC の内容を保護すると同時に、暗号化されたファイルへの共有アクセスを提供する場合は、サーバー上にプレーンテキスト ファイルのコピーを保存します。ファイルの保存先に関係なく、保護対象のファイルを暗号化された状態で保持する必要がある場合は、サーバーを適切に構成する必要があります (この場合、Active Directory で委任を行うには、サーバーが信頼済みである必要があります)。 - Windows XP または Windows Server 2003 を使用している場合、暗号化されたファイルを Web フォルダに保存できます。この場合、DAV を使用して Web フォルダにアクセスするアプリケーション (Microsoft Office 2000 以降など) でファイルを利用できます。また、Web ベースのアプリケーションを通じて、ユーザーのファイル利用を可能にすることもできます。 ##### 配置転換の計画 EFS では、選択されたファイルしか暗号化されません。操作モードによっては、キー マテリアルがシステム ボリュームに保持されている場合があります。EFS で保護されたコンテンツがあるコンピュータを配置転換するときには、通常の配置転換の手順に従い、すべての機密ファイルが削除されていることを確認する必要があります。 #### 利便性に関する計画を策定する EFS は、NTFS ボリューム上のファイルとフォルダを暗号化する安全な方法です。暗号化に関する、使い方、要件、操作上の問題といった事項を説明する文書化された暗号化ポリシーを作成し、配布する必要があります。ユーザーとサポート スタッフは、暗号化が展開される前に、暗号化の適切な使い方について教育を受ける必要があります。 暗号化ポリシーには、機密データの暗号化に関する次のようなさまざまな問題点を記載する必要があります。 - 暗号化を使用する必要がある情報の種類。 - 暗号化を使用する必要があるコンピュータ資産の種類 (デスクトップ コンピュータ、ラップトップなど)。 - サポートされているデータ暗号化ソリューション (EFS と BitLocker など)。 - 暗号化によって解決できる問題と解決できない問題。 - 組織のデータ保護に適した暗号アルゴリズムと最小限のキー サイズ。 - 暗号化を適切に行うためにユーザーが実行できる行為、実行する必要がある行為。 - 暗号化に関連した潜在的な問題 (データの損失など)。 - ファイルを暗号化するためにユーザーが実行する必要のある手順。 - ユーザーがファイルの暗号化状況を確認する方法 (エクスプローラではファイルが緑色のフォントで強調表示される、Cipher.exe を使用する、など)。 - 暗号化されたデータの回復を実行する責任者、ユーザーが回復プロセスを開始する方法。 - 暗号化の問題に関してユーザーがサポートを受ける方法。 オンライン資料、印刷物の資料、実地レッスン、教育クラスなど、一般的な教育手段を通じて、暗号化の情報を必要に応じてユーザーと共有します。この取り組みは、残りの展開プロセスと並行して実施できます。 #### Active Directory およびグループ ポリシーの計画を策定する Active Directory とグループ ポリシーは、EFS の構成とポリシーを管理する場合に最も効果的な方法として利用できます。次の GPO 設定で、EFS の動作を制御できます。 - **コンピュータの構成\\Windows の設定\\セキュリティの設定\\ローカル ポリシー\\セキュリティ オプション** - **\[シャットダウン: 仮想メモリのページ ファイルをクリアする\]** - **\[システム暗号化: 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う\]**。Windows XP Service Pack 1 (SP1) および Windows Server 2003 ベースのコンピュータの EFS では、既定で 256 ビットのキー長を持つ Advanced Encryption Standard (AES) アルゴリズムが使用されます。ただし、そのコンピュータで **\[システム暗号化: 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う\]** 設定を有効にすると、代わりに 168 ビットのキー長の 3DES が使用されます。Windows Vista コンピュータでこの設定を有効にした場合、EFS では AES が使用されます。 > [!NOTE] > FIPS に準拠する必要がある場合は別ですが、EFS で使用される暗号化アルゴリズムを操作するために FIPS ポリシーを使用するのは、あまりお勧めできません。EFS で使用されるアルゴリズムを変更するには、**HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\EFS** - **コンピュータの構成\\Windows の設定\\セキュリティの設定\\公開キーのポリシー** - **\[ファイル システムの暗号化\]**。ポリシーの範囲内のコンピュータに対して EFS を有効にします。 - **\[ファイル システムの暗号化\]**[第 2 章 : 構成および展開タスク](https://technet.microsoft.com/ja-jp/library/d28caa21-4ec2-4556-a92a-5aa8410df6da(v=TechNet.10)) ##### ドメイン アカウントへの移行計画 *セキュリティ分析*』ガイドで説明済みの理由により、EFS は、Active Directory ドメイン アカウントを持つユーザーにのみ最適なセキュリティを提供します。Syskey を使用して同水準のセキュリティを実現することはできますが、高度なレベルで Syskey を使用すると、ユーザーにあまり良い影響を与えません。したがって、EFS のユーザーはドメイン ユーザーである必要があります。EFS の計画を立てる場合、潜在的なユーザーの調査も計画の中に含めて、ユーザーがドメイン アカウントを持っているか、EFS で保護された機密データにアクセスするときにはそのドメイン アカウントのみを使用してコンピュータにログオンしているか、確認する必要があります。 ##### Active Directory パスワード ポリシーの計画 スマート カードと EFS を併用しない場合、EFS のファイル暗号化キーはユーザーのパスワードで保護されます。ユーザー ID とパスワードを知っていれば誰でも、そのユーザーとしてログオンし、そのユーザーのファイルの暗号化を解除できます。したがって、EFS で暗号化されたファイルを確実に保護するためには、各組織のセキュリティ対策の一部として、強力なパスワード ポリシーと充実したユーザー教育を含める必要があります。 ##### 自己署名入り証明書から CA 発行証明書への移行計画 一部のユーザーが、正規の EFS を展開する前から EFS を使用し始めている場合があります。ユーザーが EFS 証明書のないコンピュータでファイルを暗号化しようとした場合、EFS サブシステムによって自己署名入りの新しい証明書が生成されます。EFS を組織のコンピュータに展開するときに、このような自己署名入り証明書を証明機関発行の証明書に置き換える計画を立てる必要があります。この置き換えプロセスでは、自己署名入りの証明書で既に EFS を使用しているコンピュータと、これから EFS を展開する他のコンピュータの間で、証明書の有効期間とキー強度を標準化します。 [](#mainsection)[ページのトップへ](#mainsection) ### 関連情報 - [「Windows Vista Enterprise ハードウェア計画のガイドライン」](https://technet.microsoft.com/ja-jp/library/aac4f0d8-472b-474b-8160-760ad0b7e475(v=TechNet.10)) - Universal Serial Bus Web サイトの仕様に関するドキュメント『[USB Mass Storage Class Bulk-Only Transport](https://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf)』(英語) - Trusted Computing Group Web サイトの「[Trusted Platform Module (TPM) Specifications](https://www.trustedcomputinggroup.org/specs/tpm)」ページ (英語) - [「Microsoft Solution Accelerator for Business Desktop Deployment 2007」](https://technet.microsoft.com/ja-jp/library/53fa01fb-6aae-4230-ac26-4ed036a50908(v=TechNet.10)) - Business Desktop Deployment Toolkit の「[Lite Touch Installation Guide](https://technet.microsoft.com/ja-jp/library/87f4408f-cb12-45c0-abba-14a1476db7f4(v=TechNet.10))」(英語) - [BitLocker Drive Encryption Technical Overview (英語)](https://go.microsoft.com/fwlink/?linkid=77977) - [BitLocker Drive Encryption and Disk Sanitation (英語)](https://technet.microsoft.com/ja-jp/library/a4d82f78-cc5d-49b3-8229-4cb4162d43a2(v=TechNet.10)) - [「資格情報の移動とは」](https://technet.microsoft.com/ja-jp/library/d052e2b5-fd73-4bd0-8018-7713049463ee(v=TechNet.10)) - [暗号化ファイル システム (EFS) では、Windows XP ベースのコンピュータで EFS ファイルを暗号化しようとすると自己署名入りの証明書が生成される](https://support.microsoft.com/kb/912761) - Microsoft [Identity Lifecycle Manager 2007](https://www.microsoft.com/windowsserver/ilm2007) (ILM 2007) (英語) - Windows XP ドキュメントの『Data Protection and Recovery in Windows XP』の「[Data Recovery Overview](https://go.microsoft.com/fwlink/?linkid=139246)」セクション (英語) - [「ステップ バイ ステップ ガイド - Windows BitLocker ドライブ暗号化」](https://technet.microsoft.com/ja-jp/library/c61f2a12-8ae6-4957-b031-97b4d762cf31(v=TechNet.10)) - [Windows Server 2003 でのキーのアーカイブと管理](https://technet.microsoft.com/ja-jp/library/296f87df-06c3-4e27-89ff-5283cb76fb81(v=TechNet.10)) - [BitLocker ドライブ準備ツールの説明](https://support.microsoft.com/kb/930063) - [Extending Your Active Directory Schema in Windows Server 2003 R2 (英語)](https://technet.microsoft.com/ja-jp/library/509ada1a-9fdc-45c1-8739-20085b20797b(v=TechNet.10)) [](#mainsection)[ページのトップへ](#mainsection) ##### 目次 - [概要](https://technet.microsoft.com/ja-jp/library/abfc4696-a39a-43df-b559-133633e4bd5e(v=TechNet.10)) - 第 1 章 : 計画に際しての考慮事項 - [第 2 章 : 構成および展開タスク](https://technet.microsoft.com/ja-jp/library/d28caa21-4ec2-4556-a92a-5aa8410df6da(v=TechNet.10)) - [第 3 章 : 運用および回復のシナリオ](https://technet.microsoft.com/ja-jp/library/01754723-3e94-4bec-8284-02e2a4e91593(v=TechNet.10)) **ダウンロード** [Data Encryption Toolkit for Mobile PCs を入手する (英語)](https://go.microsoft.com/fwlink/?linkid=81666) [](#mainsection)[ページのトップへ](#mainsection)