セキュリティ ウォッチEFS を展開する : 第 1 部

John Morello

皆さんは、ラップトップの盗難や置忘れが原因で、個人データや機密データが失われた、などのレポートを耳にしたことがあるでしょう。ラップトップの紛失は日常茶飯事に発生します。なりすまし犯罪が増加し、法令遵守がますます重要になっている現在、モバイル コンピューティング システムのデータを完全に保護することが不可欠となっています。

1 つの答えとして、Windows 2000 以降 Windows® に含まれている暗号化ファイル システム (EFS) を使用する方法があります。EFS は、組み込みで高パフォーマンスなディスク ベースの暗号化を提供します。EFS はエクスプローラとシームレスに統合しているため、使用しているファイルがいつ暗号化されているかエンド ユーザーに気づかれることはありません。さらに EFS はネイティブの Windows 認証やアクセス制御テクノロジとも同様にうまく機能するので、ユーザーはデータにアクセスするために別のパスワードを記憶する必要がありません。最終的に、EFS にはユーザーが暗号化キーにアクセスできなくなった場合 (ユーザー プロファイルが削除された、損傷した、あるいはスマート カードを損失した、などの場合) にデータを回復できる管理が容易なオプションがあります。

EFS は、Windows の組み込み暗号化テクノロジを使用して、強力な暗号化キーを生成、保存、展開し、データを保護します。Windows XP Service Pack 1 (SP1) 以降のバージョンでは、EFS は 256 ビット キーと一緒に Advanced Encryption Standard (AES) アルゴリズムを使用してディスク上のデータを暗号化します。これらの対称キーは、非対称 (RSA) キーのペアを使用して保護されます。EFS は AES キーを使用して各ファイルを暗号化し、ユーザーの RSA キーを使用してこのキーを暗号化して、その結果をファイルに保存します。EFS 暗号化の詳細については、見出し一覧の「EFS リソース」を参照してください。ここでは、EFS の技術的基盤ではなく、EFS を展開して使用中の環境で使用可能にする方法を重点的に説明します。このため、この記事では、EFS 暗号化の概念についての知識があることを前提としています。

EFS セキュリティについての注意事項

EFS 暗号化を解読する、あるいは破ると主張するアプリケーションがいくつかあります。これらのアプリケーションに、実際に AES (あるいは Data Encryption Standard － DES、もしくは Expanded Data Encryption Standard － DESX) で暗号化された暗号化テキストを解読するものはありません。ただし、これらのアプリケーションは、ユーザーのパスワードから強引にユーザーの EFS 秘密キーにアクセスします。EFS 暗号化に関して覚えておくべき重要なことは、暗号化データの生成と保護に使用される秘密キーがデータ保護 API (DPAPI) を使用しているということです。DPAPI では、ユーザーのログオン資格情報の派生物を使用してデータが保護されるので、EFS を使用したデータ保護は、ユーザーのパスワードと同程度の効果はあります。Windows Vista™ では、スマート カードに EFS 暗号化証明書を保存できるようになったため、パラダイムが変わり、EFS で保護されたデータの相対的なセキュリティが大幅に向上しました。

これらの攻撃に耐えるには、どれぐらいの長さのパスワードが必要ですか。今日のハードウェア機能や現代のパスワード攻撃アルゴリズムを考えると、11 文字以上のパスワード (正確にはパスフレーズ) をお勧めします。11 文字以上のパスフレーズは、事前計算済みのハッシュ攻撃 (Rainbow Table など。詳細については、[リソース] 見出し一覧の「Why you shouldn't be using passwords of any kind on your Windows networks」のブログ投稿 (英語) を参照してください) など、今日最も高度な方法に対して強い耐性があります。

PKI を使用するか使用しないか

EFS に関して、公開キー インフラストラクチャ (PKI) を使用しなければ機能しないという誤った認識がしばしばあります。組織で既に PKI が使用されている場合、EFS を統合して利用することは簡単ですが、これは要件ではありません。したがって、EFS 展開で PKI を使用するかしないかを決定することで、今後の多数の展開決定にも影響を及ぼすことになるので、最初に検討する必要があります。

EFS と一緒に PKI を使用する主な利点は、キーのアーカイブと回復を実行できる機能です。EFS を単独で使用してもデータ回復は実行できますが、自動キー回復は PKI がなければ使用できません。しかも Windows Server® 2003 Enterprise Edition を証明機関 (CA) として実行する必要があります。データ復旧は、暗号化キーにアクセスできなくなったユーザーが、データ回復エージェント (DRA) と呼ばれる指定の管理者に暗号化データを提供すると、DRA がデータを解読してユーザーに返すか、新しい秘密キーで使用するためにデータを再暗号化するプロセスです。ユーザーがこのキーを使用して暗号化する情報は DRA キーのコピーでも暗号化されるため、DRA はユーザーの暗号化プロセスのシャドウの役割を果たします。したがって、ユーザーがキーを紛失した場合でも、DRA が関係していれば、暗号化テキスト データを取得してこれを DRA キーに適用し、解読 (または再暗号化) したデータをユーザーに返すことができます。DRA のアプローチは効果的ですが、ユーザーの暗号化したデータが大量だったり、DRA の役割を果たすローカル IT スタッフがいなかったりする場合には、管理が難しくなります。

これに対してキー回復では、CA がキー作成プロセス時にユーザーの暗号化キーのコピーを作成し、そのキーのコピーを CA のデータベースに保存する必要があります。ユーザーが暗号化ファイルにアクセスできなくなっても、CA 管理者はこのデータベースを検索してユーザーのキーを取得するだけで済みます。その時点で、ユーザーは DRA に回復を依頼しなくても、データにすぐにアクセスできるようになります。この方法でキーを回復した方が、処理も速く効率的です。ただし、ベスト プラクティスとして、キー回復を使用した場合でも、キーを紛失した場合のバックアップ手段として DRA を準備しておくことをお勧めします。こうすれば、大規模な組織では、ローカル IT 管理者が PKI 管理者グループに依存することなくユーザーのデータを回復できる分散回復システムを持つことができます。

EFS と PKI を併用するもう 1 つの利点は、暗号化ファイルの共有が簡単になることです。EFS はラップトップ システムに限定されません。コンピュータの物理的なセキュリティが保証できないあらゆる状況に等しく有益です。これらの状況では、複数のユーザーが同じ暗号化データにアクセスしなければならない場合もあります。Windows での暗号化ファイルの共有サポートは、ディレクトリではなく個別のファイルの共有しか許可されていないため多少制限がありますが、役に立つツールにもなり得ます。ファイルを共有するユーザーは、EFS ファイルを共有しやすくするため、共有相手のユーザーの公開キーにアクセスする必要があります (有効な EFS 証明書が Active Directory® のアカウントに対して発行されている場合はこの方法が一番簡単です)。証明書を手動で発行することもできますが、Enterprise (Active Directory 統合) モードに Windows CA がインストールされていれば、このプロセスを完全に自動化できます。

EFS キー管理

Windows Server 2003 ベースの PKI を使用できる場合、ユーザーの EFS 証明書を生成するプロセスは簡単です。Windows Server 2003 CA には、基本 EFS などの証明書テンプレートの既定セットが用意されています。ただし、このテンプレートはバージョン 1 のテンプレートなので、キーのアーカイブはサポートされていません。そのため、CA でテンプレートを使用可能にする前に、テンプレートを複製して新しいバージョン 2 テンプレートを作成する必要があります (図 1 のように「キー アーカイブ付き EFS」などの名前を付けることができます)。新しいテンプレートの [要求処理] タブに移動し、ユーザーの暗号化キーをアーカイブするオプションを選択します。このオプションを有効にする前に、CA でキーのアーカイブを正しく構成しなければならないことに注意してください。「詳細情報」にはこのプロセスの優れた手引きが掲載されています。基本 EFS テンプレートに優先して、新しいバージョンを使用するようにこのテンプレートを設定することができます (図 2 を参照)。

図 1** キー アーカイブ付き EFS **(画像を拡大するには、ここをクリックします)

図 2** 基本 EFS テンプレートに優先します **(画像を拡大するには、ここをクリックします)

次に、テンプレートに適切な権限を設定して、該当する一連のユーザーにのみ登録アクセスを許可する必要があります。Windows の EFS コンポーネントでは、EFS を最初に使用したときに証明書が自動的に要求されるため、EFS テンプレートへの自動登録をユーザーに許可する必要はないのが普通です。実際、自動登録されたユーザーが全員 EFS を使用していることが確実でない限り、EFS 証明書の自動登録を有効にしないことをお勧めします。図 3 に、EFS 登録設定を示します。EFS を使用しないユーザーに証明書を発行すると、何のメリットもなく CA データベースのサイズを増やすだけになります。CA データベース自体にサイズ制限はありませんが、証明書の発行部数が増えると、特に Microsoft 管理コンソール －MMC から管理することがますます難しくなります。

図 3** EFS ユーザー権限を設定する **(画像を拡大するには、ここをクリックします)

最後に、暗号化ファイルの共有をサポートしなければならない場合は、CA でユーザーの証明書を Active Directory に自動発行することもできます。

テンプレートが CA 上に正しく構成されると、ユーザーが最初に EFS を使用してファイルを暗号化したときに、証明書が CA から取得されます。秘密キーは CA によって自動的にアーカイブされます。

DRA キー管理

PKI を使用する準備が整っている場合に、次に考慮しなければならないことは、CA が生成した DRA 証明書を使用するかどうかです。PKI から DRA 証明書を使用しないのはなぜでしょうか。証明書の有効期限が迫っている (2 年未満) 発行元 CA がある、というシナリオを考えてみましょう。CA は自分の有効期限よりも長い有効期限を持つ証明書を発行することはできません。つまり DRA 証明書の有効期間は最大 2 年ということになります。このため、データ復旧シナリオがますます複雑になる可能性があります。この架空の例を次のシナリオに示します。

1. ユーザーが 2006 年 1 月 にファイルを暗号化しました。グループ ポリシーからコンピュータにプッシュされる DRA 証明書の有効期間は 2 年間になります (2008 年 1 月に有効期限が切れます)。
2. ユーザーは続けて EFS を使用して新しいファイルを暗号化します。
3. 2008 年 1 月に DRA 証明書の有効期限が切れると、管理者はグループ ポリシーを通じて新しい証明書をプッシュ ダウンします。
4. これ以降の暗号化操作にはすべて新しい DRA 証明書が使用されます (古い DRA を使用して暗号化されたファイルを開いた場合も、ファイルを保存すると新しい DRA が使用されます) が、ユーザーが開くことのないファイルも、古い DRA によって保護されています。
5. ユーザーが誤ってプロファイルを破損し、データ復旧が必要になりました。
6. この場合、IT 管理者には 2 つの DRA 証明書のセットが必要になります。手順 3 以降にアクセスしたすべてのファイルには新しい証明書が必要となり、手順 3 以降アクセスしなかったファイルには古い証明書が必要となります。

IT 管理者が手順 3 以降にスクリプト (cipher.exe /u) を実行して、新しい DRA ですべてのファイルを更新することもできますが、このプロセスには時間がかかります。また、当然のことですが、有効期限が切れた DRA 証明書が回復ポリシーに含まれている場合、EFS コンポーネントで新しい暗号化操作を行うことはできませんが、DRA キーのペアが有効期限後に無用になってしまうわけではありません。有効期限が切れた DRA キーのペアで暗号化された古いファイルも、そのキーで回復することが可能です。そのため、有効期限が切れた後も DRA キーのペアを破棄してはいけません。いつ必要になるかわからないからです。

このため、有効期間が短い CA がある環境では、有効期限の長い自己署名入りの DRA 証明書を使用することをお勧めします。暗号ユーティリティには、100 年の有効期間を持つ EFS 回復エージェントのキーのペアを自動的に作成するスイッチ (cipher.exe /r) があります (図 4 を参照)。このキーのペアから作成された証明書は、グループ ポリシー オブジェクト (GPO) に追加して、組織全体で DRA として使用することができます。EFS コンポーネントでは DRA 証明書の信頼チェーンがチェックされないので、システムに存在する信頼するルート証明機関のリストに変更を加えなくても、自己署名入り証明書を使用することができます。組織の CA の有効期間に関係なく、長期の有効期間を持つ DRA 証明書を少なくとも 1 つ作成して、ドメイン全体の GPO に追加することをお勧めします。これは他のオプションがすべて失敗した場合の代替手段です。これは CA キーをアーカイブせずに CA で生成された DRA キーを使用している場合に特に重要です。DRA 証明書が危険にさらされた場合は、新しい証明書で GPO を更新し、前述した cipher.exe /u を使用してファイルを更新することができます。

図 4** Ciquer /R を実行する **(画像を拡大するには、ここをクリックします)

EFS のリソース

EFS の具体的な問題やベスト プラクティスの詳細については、以下のサイトを参照してください。

• Why you shouldn’t be using passwords of any kind on your Windows networks(英語)
• Implementing Key Archival Walkthrough(英語)
• Encrypting File System in Windows XP and Windows Server 2003(英語)

KRA と DRA の展開

CA 管理者はキーのアーカイブを使用することで、ユーザーに代わって預託された暗号化キーを回復することができます。これは、CA 管理者が CA によって署名されたキーを使用して組織内のあらゆるデータを解読できることになるため、かなり細心の注意を要する強力な機能です。そのため、キーのアーカイブと回復は慎重に行う必要があります。また、この権限の付与は、信頼されている少数のセキュリティ担当者に限定する必要があります。キーの回復には細心の注意を要するため、EFS で暗号化されたデータへのアクセスを取り戻す主な方法にキーの回復を使用する場合は、CA 管理チームに回復要求を送信する際のエスカレーション プロセスを明確に設定しておくことが重要です。要求を慎重に検討するまでは、回復プロセスを開始しないでください。キーを実際に回復した場合は、回復したキーを使用することで EFS で保護されたすべてのユーザーのデータにアクセスできるため、セキュリティ保護された方法で (電子メールなどを使用せずに) キーをユーザーに届ける必要があります。

キー回復エージェント (KRA) キーは、生成されると CA 管理者によって保管されます。グループ ポリシーを通じてアドバタイズされることはありません。実際、EFS では使用するキーがアーカイブされているかどうかを判断できません。通常どおりに暗号化操作が行われるだけです。さらに、CA で作成された KRA キーは、EFS に固有ではありません。キーのアーカイブを使用している CA は、CA によってアーカイブされるキーを保護するために、CA レベルに n 個の KRA キーが追加されています。これらのキーには、EFS で使用されているキー、セキュリティ保護された電子メール、または暗号化が含まれるその他の証明書などがあります。KRA キーは個々のキー回復エージェントがセキュリティ保護して保存すべきです。また、キーの 1 つを紛失した場合の代替手段として、最低でも 2 つの KRA を使用する必要があります。

管理者が新しく作成されたドメインのドメイン コントローラに初めてログ オンすると、自己署名入りの証明書を使用してドメイン レベルに既定の回復ポリシーが作成され、DC の管理者のプロファイルにキーのペアが保存されます。この DRA 証明書の有効期間は 3 年間です。この既定の証明書を削除して、有効期間が長い自己署名入り証明書か PKI で発行された証明書と置き換えることをお勧めします。この既定の自己署名入り証明書を削除しないと、作成から 3 年後に EFS はドメイン全体で新しいファイルの暗号化を停止してしまいます。これは証明書の有効期限が切れると、有効期限の切れた DRA 証明書が回復ポリシーに含まれている場合、それ以降データを暗号化できないからです。回復エージェント ポリシーを実施せずに Windows XP 以降のシステムを実行することは可能ですが、できるだけ行わないことをお勧めします。そのようなことをすると、何らかの理由でユーザーが暗号化キーにアクセスできなくなったときにキー回復が不可能になり、データはすべて失われ、取り戻すことができなくなります。

説明したように、DRA キーには自己署名入りのものと CA から発行したものを使用できます。大抵の場合、ハイブリッド アプローチを採用し、回復エージェントの最後の手段として、企業全体で最低 2 つの長期の自己署名入り DRA を使用するのが最善の方法です。DRA 証明書はグループ ポリシー オブジェクトを通じて展開されるため、他の GPO と同じ機能を継承しています。つまり、他の GPO 設定の適用を制御する、標準のローカル、サイト、ドメイン、組織単位 (OU) GPO の累計および適用アルゴリズムが DRA にも適用されます。そのため組織では、中央の IT グループが企業のあらゆる部分に DRA でアクセスできる一方、ローカル IT グループは担当する特定領域にしかアクセスできないという多層アプローチを簡単に DRA に実装できます。これは、大規模で地理的に分散した組織にとって、データ回復を促進するために暗号化された大量のデータを WAN リンクを通じて転送する必要がなくなるため、特に貴重な資産です。図 5 は、DRA を多層展開した場合の標準的な例を示します。

図 5** DRA の多層展開 **

この場合、バトン ルージュ OU のユーザーは、暗号化された各ファイルにつき、ローカル管理者から 2 つ、北米 IT グループから 2 つ、ドメイン レベルから 2 つの合計 6 つの DRA を持つことになります。したがって、ユーザーが暗号化されたデータにアクセスできなくなっても、バトン ルージュのローカル DRA か北米 IT グループから回復することができます。これらの 4 つの DRA を使用できなくなったり紛失したりしても、最後の手段としてドメイン レベルの DRA を使用してこのデータを回復することができます。どの DRA で回復を実行しても、プロセスは本質的に同じです。最初にユーザーが DRA でデータを使用できるようにします。DRA が必要な手順を踏んで、要求が合法であり、データの真の所有者から寄せられていることを確認することが重要です。合法であることが確認されると、DRA は DRA 証明書を読み込み、データを解読 (できれば再暗号化) して、データをエンド ユーザーに送り返します。問題のあるユーザーを DRA が実際に訪問し、自分の DRA キーのペアをプロファイルに読み込み、データを解読してからキー ペアを削除する、といったローカル回復を選択する組織もあります。そうすれば、ユーザーはプレーンテキスト形式のデータにアクセスし、新しいキーで再暗号化できます。このアプローチは DRA のキーのペアがローカル コンピュータに (一時的に) コピーされるので、安全性では劣りますが、大量のデータを回復しなければならない場合には時間を節約できます。

キーのアーカイブと回復による回復をユーザーに提供する場合は、このプロセスとはまったく別に回復要求を処理する必要があります。ユーザーの要求は、DRA を一切使用せずに CA 管理者に寄せられ、CA 管理者は要求を検証してからアーカイブを検索し、ユーザーの秘密キーを取得する必要があります。これに続き、CA 管理者はこの秘密キーをセキュリティ保護された Web サイトに置いてダウンロードしてもらうなど、セキュリティ保護された方法でユーザーに秘密キーを提供します (スマート カードを利用して Windows Vista から提供されている EFS キーを保存した場合は、そのキーも再発行する必要があります)。このキーをプロファイルに読み込むと、暗号化されたすべてのデータにすぐにアクセスできるようになります。

DRA と KRA のキーのペアで機密データを解読することができるため、キーのペアは正しく保護することが重要です。DRA と KRA のキーのペアは、通常の管理者のデスクトップ プロファイル (日常業務を行うプロファイル) には保存すべきではありません。フロッピー、光ディスク、フラッシュ メディアなど物理的に安全な場所にオフラインで保存する必要があります。回復が必要になると、回復エージェントがキーのペアをこのメディアから回復ワークステーションに読み込み、回復操作を実行してから、キーのペアを削除します。特にセキュリティに厳しい組織では、これらのキーのペアのセキュリティをさらに高めるために、回復用の専用ワークステーションが指定されている場合もありますが、これはすべての組織の要件ではありません。

次回予告

EFS 計画のキー管理、データ復旧、および Active Directory の側面について検証してきましたが、来月はこのトピックの第 2 部でクライアント側の展開に関する質問を重点的に見ていきます。グループ ポリシーを使用した EFS 使用の制御、暗号化対象情報の選択、ログオン スクリプトによるデータの自動暗号化、EFS で保護されたデータを簡単に使用するためのエクスプローラでのクライアント側の強化機能などについて説明する予定です。

John Morello は、ルイジアナ州立大学を首席で卒業し、マイクロソフトで 6 年間さまざまな任務を果たしてきました。シニア コンサルタントとして、フォーチュン 100 企業や連邦政府および国防省向けのセキュリティ ソリューションの設計に携わってきました。現在は Windows Server グループのプログラム マネージャとして、セキュリティおよびリモート アクセス テクノロジに取り組んでいます。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.