EFSの動作に関して

さて、時間ができたのでEFSの動作に関してまとめておきます。

そもそも、EFSとはファイル暗号化システムの略で、ファイルを暗号化するための仕組みになります。暗号化を行うためには、証明書が必要になります。企業で使用する場合はCA(証明機関)を作成してEFS証明書をクライアントユーザーに配布するというのが推奨の方法になります。

今回、検証環境を用意してテストしてみました。

efs

クライアントのユーザーUser01が、ファイルを暗号化します。

そうすると、CAからEFS証明書(User01#01)が発行され、ファイルを暗号化します。

これが通常の動作になります。

ファイルサーバーに暗号化したファイルを保存する場合は、ADのコンピューターオブジェクトの設定として、[委任のサービスへの委任でこのコンピューターを信頼する]のチェックが必要になります。この設定がされていないと、そもそもリモートのサーバーに対して暗号化はできません。

では、User01がFileSrv01(ファイルサーバー)に暗号化ファイルをコピーします。

そうすると、暗号化が解除された状態でネットワーク上にデータが流れ、FileSrv01にて再度暗号化がされます。その際にUser01の公開キーが必要になります。しかし、User01の公開キーはクライアントのローカルフォルダ(プロファイル内)に保管されています。よって、サーバー上にはありません。そこで、FileSrv01はUser01の情報を使用して、CAからEFS証明書の要求を行います。その際新たに発行されたUser01#02の証明書を使用して暗号化を行います。ここで注意が必要なのは、確かにUser01でFileSrv01上のファイルは暗号化されましたが、使用している証明書はクライアントの証明書とは別物ということです。クライアントの証明書はUser01#01ですが、FileSrv01ではUser01#02を使用しているのです。

更に、FileSrv02に暗号化ファイルをコピーすると、FileSrv01と同様に新しい証明書が発行されUser01#03で暗号化されます。

■移動ユーザープロファイルを使用する

では、User01が移動ユーザープロファイルを使用している場合はどうなるのか?

まず、重要なこととしては、移動ユーザープロファイル自体は暗号化してはいけない。更に、暗号化ファイルを移動ユーザープロファイル内に保管してはいけないということです。

移動ユーザープロファイルを使用していれば、CL1で暗号化ファイルを作成し、その後CL2でログオンした場合は、プロファイル内に証明書があるので再度CAからの証明書発行は行いません。更に、リモートのファイルサーバーであるFileSrv01に対してファイルをコピーしても、クライアントと同様に移動ユーザープロファイルが使用されるので、CAから再度証明書が発行されることはありません。要するに、1つの証明書を使用して様々な端末で利用できるということになります。

よって、EFSを使用する場合は、移動ユーザープロファイルを使用するというのは、強い推奨ということになります。

■資格情報の移動とは

グループポリシーには資格情報の移動という項目があります。

WS000030

資格情報の移動の設定を行うことによって、移動ユーザープロファイルを使用しなくても証明書がADにコピーされ、その証明書をローカルにコピーして使用することができます。ですので結果的に、CAから証明書を発行することなく、同一の証明書を使用することができます。しかし、この動作はクライアントでの動作(ローカルログオン)に限ります。要するに、リモートで接続したサーバーでは機能しないのです。ですので、User01がFileSrv01に対して暗号化ファイルをコピーすると新たにUser01#02の証明書が発行されて使用されます。

この機能のメリットは何か?

結局、リモートのファイルサーバーに対して暗号化ファイルを作成、コピーする際には資格情報の移動をするわけではありません。あくまでも複数のクライアントを使用する際に同じ証明書を使用することができるものになります。ただし、キー回復の設定を使用しなくてもADに証明書が保管されるメリットがあります。通常プロファイルが壊れるなどの障害がおこると、ファイルを回復するにはDRA(Data Recovery Agent)を使用するか、もしくはキー回復の設定を行っていた場合は、その手順を実行しKRA(Key Recovery Agent)を使用する必要があります。よってKRAの部分の必要性が減るということになります。

■EFSはどのように使用すればいいの?

移動プロファイルを使用することによって、証明書の管理が容易になります。

しかし、移動ユーザープロファイルを使用できないとなると、リモートに暗号化ファイルを作成、コピーすると新規に証明書が発行されることによって証明書管理が煩雑になります。特にサーバーが点在しているような環境ではどのサーバーに発行した証明書なのかの判断が非常に難しくなります。よって、リモートに暗号化ファイルを置くことはお勧めしません。あくまでもクライアントのローカルフォルダのみでの使用をお勧めします。

マイクロソフト公式解説書に Microsoft Windows Server 2008 PKI & 認証セキュリティ大全 (マイクロソフトITプロフェッショナルシリーズ) という書籍があります。

この書籍はPKI基盤や暗号化に関して詳しく載っている良書だと思います。

その525ページには次のように書いてあります。

■Windows Vista のリモート暗号化の変更点

Windows Server 2008 では、リモート暗号化の動作が変更され、Windows Server 2003 の WebDAV 暗号化と同じような処理になっています。

  • サーバーでプロファイルを作成する代わりに証明書とキーをクライアントで保管する。
  • ファイルサーバーがユーザーを偽装することはないので、「委任に対して信頼する」設定を有効にする必要はない。
  • ファイルを暗号化した状態でリモートファイルサーバーに送信できる。
  • 資格情報の移動サービスを実装すれば、ユーザーがワークステーション間でファイルを共有できる。

ということで、検証してみました。

結果は・・・このような動作はしませんでした。XPの時からの動作と変わりはないように見受けられました。もしかしたら、デフォルトではXPと同様の動作を行って、何か設定をすると上記のような動作をするのか?

結局わからないので、現在マイクロソフトテクニカルサポートに問い合わせ中です。結果がわかり次第追記します。

2011年10月25日追記

テクニカルサポートより連絡がありました。

やはり、記述ミスということでした。Longhorn (Windows Server 2008 開発コード名) の Beta 時に記載されたものとなり、出荷と執筆のタイミングの違いにより、実際の動作と異なる内容が記載されてしまった状況となりますとのこと。ですので、この情報は誤りですので、注意が必要です。

スポンサーリンク
レクタングル(大)広告
レクタングル(大)広告
  • このエントリーをはてなブックマークに追加

コメント

  1. EFSの動作に関して | MCTの憂鬱 : ちゅどん道中記 より:

    […] クライアントのユーザーUse… >>EFSの動作に関して | MCTの憂鬱 […]

コメントをどうぞ

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください