忘れた管理者パスワードを変更する方法 – Windows 8.1編

以前、「忘れたAdministratorパスワードを変更する方法」という投稿を3年ぐらい前に書かせていただき、想像以上の反響をいただきました。対象としていたOSはWindows Server 2008だったのですが、もちろんWindows 7でも同様の手順で変更することは可能です。

では、Windows 8.xの場合はどうでしょうか?
Windows 8以降のOSではサインイン画面のユーティリティマネージャーはWindows 7とは異なり、
メニューが固定化されてしまっています。

image

そこで、Windows 8.xにて

1.OSのセットアップDVDから起動
2.コマンドプロンプトを起動
3.renコマンドでutilman.exeの名前を異なる名前に変更
4.renコマンドでcmd.exeファイルの名前をutilman.exeに変更
5.再起動

以上の手順で画面左下のボタンを押したら、ユーティリティマネージャーの代わりにコマンドプロンプトが起動するのでしょうか?

image

結果はご覧のとおり。

image

普通にコマンドプロンプトが起動しました。
whoamiコマンドを実行してみると、nt authority\systemとなっているので、Administratorよりも権限の強いSYSTEMアカウントでコマンドプロンプトが起動していることがわかります。

私たちは物理セキュリティという観点から対策を考えておく必要がありそうですね。

System Center Endpoint Protection ~ 定義ファイルを確認する

マイクロソフト謹製のマルウェア対策ソフトウェアである、System Center 2012, Endpoint Protection (SCEP)は他社のマルウェア対策ソフトウェアと同じく、定義ファイルをベースにコンピューター内のマルウェアを検出する仕組みを採用しています。そのため、定義ファイルを正しく入手し、定義ファイルを正しく利用してマルウェアスキャンを行うことがとても重要になります。

そこで、SCEPがどのような仕組みで定義ファイルを取得し、実装しているか、調べてみました。

注意:私が調べた限りでは、マイクロソフトオフィシャルな情報が見当たらなかったため、自分のコンピューターにおける挙動をベースにこの投稿はまとめられています。そのため、投稿の内容の正当性についての最終的な判断はご自身で行うよう、お願いします。

■ ■ ■

定義ファイルの取得方法

SCEPで使用する定義ファイルは基本的にMicrosoft Updateから取得します。SCEPクライアントは直接Microsoft Updateから取得することもできますし、SCCMの配布ポイント経由で取得することもできます。
配布ポイント経由で取得する場合、SCEPクライアントに配布する定義ファイル自体をMicrosoft Updateから取得しなければなりません。しかし、Microsoft Updateから取得する作業を手動で行っていては面倒なので、定期的に定義ファイルをMicrosoft Updateから取得し、配布ポイントに保存しておく機能をSCCMでは使用します(これを「自動展開規則」と呼びます)。

image

 

定義ファイルの保存場所

Microsoft Updateから取得した定義ファイルはSCEPクライアントのc:\ProgramData\Microsoft Antimalware\Definition Updatesフォルダーに保存されます。ファイルには、マルウェア対策機能用の定義ファイルである、Mp*.vdmファイル群と、IPS用の定義ファイルである、NIS*.vdmファイル群があります。

image

では、これらのファイルが保存されている場所を実際に見てみましょう。
c:\ProgramData\Microsoft Antimalware\Definition Updatesフォルダーには、GUIDのような番号が割り当てられたフォルダーがいくつか作られています。このうち、更新日時が一番新しいフォルダーを開いてみると、

image

ありました!
↓これ↓が最新の定義ファイルになります。

image

前の世代の定義ファイルと比べるとわかるのですが、定義ファイルは最新版を取得しても、mpavbase.vdmファイルとmpasbase.vdmファイルは新しいファイルになっていないことがわかります。
これは定義ファイルを取得するときに前回取得した定義ファイルからの差分だけを取得するからです。

image ■こちらは最新の定義ファイル

image

■一世代前の定義ファイル(mpasbase.vdmとmpavbase.vdmファイルの更新日時は変わっていない)

このようにして、クライアントが定義ファイルを取得するときには最低限のデータだけをダウンロードするように構成されているのですね。

定義ファイルのバックアップ

では、もう一度、Definition Updatesフォルダーに戻ってみましょう。フォルダーにはBackupという名前のフォルダーがあります。Backupフォルダーの中に入っているファイルは、*.vdmファイルで更新日時を調べてみると、最新の定義ファイルから1世代前の定義ファイルが保存されていることがわかりました。つまり、Backupフォルダーに入っている定義ファイルは、文字通り、最新バージョンの定義ファイルに対するバックアップなのです。
しかし、Backupフォルダーの活用方法についてはユーザーインターフェイスのどこを見てありません。
そのため、最新バージョンの定義ファイルが壊れたときには手動でファイルを置き換えることで対処することになると思います(推測)。

image

実際に、Backupフォルダーから定義ファイルを復元してみようとしたのですが、一部のファイルはSCEPクライアントによって排他制御されているため、 すべてのファイルをBackupフォルダーから最新バージョンの定義ファイルを上書きすることはできません。そのため、Movefile (Sysinternalsツール) を使用して手動で最新のファイルを削除予約しておき、一度再起動すると、最新バージョンの定義ファイルはすべて削除され、Backupフォルダーの定義ファイルに置き換えることができるようになります。
これが正しいロールバック方法なのか、よくわかりませんが、私の環境では少なくとも前のバージョンに戻すことができました。

 

定義ファイルの保存場所 ~ サーバーサイド

今度はSCCMのサーバーサイド (サイトシステム) に保存されている定義ファイルについて見てみましょう。
Microsoft Updateから取得した定義ファイルはSCCMの自動展開規則を作成するウィザードの[パッケージのソース]で設定した場所に保存されます。

SCEP087

自動展開規則を設定し、実行すると、Microsoft Updateから取得した定義ファイルが格納されます。
一つひとつのフォルダーには各定義ファイルが格納されています。

image

フォルダーのうちのひとつを開くと、exeの形式の定義ファイルが格納されています。
Microsoft Updateから取得したタイミングでは、vdm形式のファイルではないのです。
(SCCMでexe形式の定義ファイルを取得してから、vdm形式のファイルを生成している??)

image

一方、配布ポイントが取得した定義ファイルはSCCMのコンソールからは[ソフトウェアライブラリ]-[ソフトウェア更新プログラム]-[すべての更新プログラム]から確認できます。

image

SCCMのコンソールに表示されている更新プログラムのひとつを開くと、以下のような情報が確認できます。一つひとつの定義ファイルがどのKBに対応しているか、という情報です。
ちなみに前の画像にAM_Delta_Patch_1.155.923.0というファイルが映っていましたが、これは
下の図でいうところの「Microsoft Endpoint Protectionの定義の更新 – KB2461484 (定義 1.155.923.0)」に当たります。

image

さらに[コンテンツ情報]タブをクリックすると、ソースのダウンロード先URLも確認できます。
このように定義ファイルが保存されているフォルダーだけ見ると、なんだかよくわかりませんが、
SCCMのコンソールを参照することで、一つひとつの定義ファイルが
どのような効果のある定義ファイルなのかがわかるわけです。

image

 

定義ファイルを手動で取得する

ここまで、定義ファイルはMicrosoft Updateから取得する、またはSCCMの配布ポイントから取得する方法があることを確認しました。では、定義ファイルをファイルの形で手動で取得したい場合、どうすればよいでしょうか?
その場合には、マイクロソフトのサイトから直接ダウンロードします。

pMalware Protection Center
http://www.microsoft.com/security/portal/definitions/howtoforefront.aspx

既にマルウェア感染しているコンピューターで最新の定義ファイルを使ってマルウェアスキャンを行いたい、
だけど、定義ファイルをネットワーク経由で取得しなければならない、
だけど、マルウェア感染したコンピューターをネットワークに接続させたくない、

というときにお勧めです。

System Center 2012, Endpoint Protection ~ インストールと設定のログ

先日、System Center User Group Japanの勉強会で、マイクロソフト製のマルウェア対策ソフトである、System Center 2012, Endpoint Protection (SCEP)の話をさせていただきました。スライドはこちらからご覧になれますので、ご興味のある方はご覧になってみてください。

■ ■ ■

さて、今日はその勉強会の中でいただいたご質問の中から、「インストールに失敗した場合、どのログを参照すればよいですか?」というご質問をいただいたので、これについて解説したいと思います。

System Center 2012, Configuration Manager (SCCM)のひとつのコンポーネントであるSCEPは、SCCMをインストールするときに一緒にインストール、またはSCCMのインストール後に単体でインストールすることができます。
そのため、SCEPのインストールはSCCMのインストールログに記録されます。

SCCMのインストールログは各クライアントコンピューターのc:\windows\ccmsetup\logsフォルダーに保存されます。logsフォルダーには複数のファイルが保存されていますが、このうち、client.msi.logファイルにSCEPのインストールを示すログが残されています。

image

成功すれば、上の画面のように「Endpoint Protection : Installed」と表示されますので、これで確認してください。

また、同じくログから「Queuing endpoint ‘EndpointProtectionAgent’ for installation」の部分でも状況を確認できます。

image

その他、SCEPのポリシーの適用状況を確認するために使用する、c:\windows\ccm\logs\EndpointProtectionAgent.logファイルでもインストール成功/失敗の確認が可能です。

 

■参考情報
using System Center 2012 Configuration Manager – Part 6. Adding the Endpoint Protection role, configure Alerts and custom Antimalware Policies
http://tinyurl.com/nx372qj

SCEPは色々とお伝えしたい情報があるのですが、まとめる時間がなかなか取れずに
申し訳ないです。不定期でご紹介しますので、たまにチェックしてみてください。

MicrosoftアカウントとWindows 8アカウント

前回紹介したWindows Server 2012 R2のActive Directoryですが、Kerberosポリシーの実装に少し苦慮していて、続編を書くまでに時間がかかりそうです。そのため今回は、以前、他のブログで紹介させていただいた「MicrosoftアカウントとWindows 8アカウント」について、改めて書き起こしてみました。

あ、あとフォントも少し変えてみました。

 

Windows 8ではローカルアカウントまたはドメインアカウントの代わりにMicrosoftアカウントを利用してサインインできる方法が提供されるようになりました。

Microsoftアカウントを使ってサインインすると言っても、実際にはMicrosoftアカウントに関連付けられたローカルアカウントを作ってサインインするというのが正確な表現です。そこで、単純にローカルアカウントを使った場合とMicrosoftアカウント+ローカルアカウントを組み合わせて使った場合、どのような違いがあるのかについて考えてみたいと思います。

 

ユーザープロファイルの同期

Microsoftアカウントを使ってWindows 8にサインインする場合、Windowsのサインイン自体はローカルアカウントを使って行いますが、サインイン後の各種サービスの利用はMicrosoftアカウント経由で行います。

サインイン後の各種サービスにはどのようなものが含まれるかというと、最も代表的なものとして、hotmailやSkyDriveなどのマイクロソフトが提供するサービスへ自動的にサインインを行い、各サービスに素早くアクセスできる点があげられます。

そして、もうひとつの大きな特徴として、サインインしたユーザーのプロファイル情報の一部がインターネット上のストレージにアップされ、ほかのコンピューターから同じMicrosoftアカウントでサインインすると、プロファイル情報を引き継いでくれる機能があります(こちらのサイトに詳しい説明が載っています)。

今までユーザープロファイルをほかのコンピューターでも使えるようにしたいと思ったら、Active Directoryドメインに参加し、移動ユーザープロファイルを設定しなければなりませんでした。それがMicrosoftアカウントを使うだけで利用できるようになってしまうなんて、今まで移動ユーザープロファイルで苦労してきた方からしてみれば、とても画期的なことだと思います(もちろん、移動ユーザープロファイルと全く同じものではありませんが..)。

また、ユーザープロファイルの内容のうち、クラウドと同期する対象も
Windows+I → PC設定の変更 → PC設定の同期
からカスタマイズできます。

設定項目には、デスクトップやマイドキュメントなどのユーザープロファイル内のフォルダは含まれていませんが、SkyDriveを使って共有すればほとんどのユーザープロファイルに含まれるデータをクラウドに保存し、どのPCからでもサインインしても同じデータ・環境にアクセスすることができます。

もちろん、ローカルアカウント単体でもSkyDriveを使うことは可能ですが、別途Microsoftアカウントでサインインしなければならないことを考えると、Microsoftアカウント+ローカルアカウントを活用することはとても便利であるといえます。

 

パスワードの同期

ここからが本題です。
Microsoftアカウントを利用すると、(当然ですが)パスワードに関してもどこのPCからサインインしても同じパスワードになります。これは正確にいうと、Microsoftアカウントで使用しているパスワードと同じパスワードがローカルアカウントにも設定されます。

また、Microsoftアカウントのパスワードが変われば、ローカルアカウントのパスワードも自動的に変えてくれます。そのため、AというPCでパスワードを変更したのち、BというPCでサインインを行った場合、BというPCでは変更後のパスワードを入力してサインインすることになります。

どのPCからでも同じユーザー名とパスワードでサインインできるというのは、一人で複数のPC(タブレット)を使う時代に即した素敵な方法ですが、Microsoftアカウントはhotmail等のオンラインサービスへのサインインにも使えてしまうので、もしパスワードが知られてしまい、パスワードを変更されてしまうと本人はWindowsにサインインできなくなるという問題が起きます。

との趣旨を、以前他のブログで書きました。しかし、そんな酷なことが本当に起こるのでしょうか?

 

パスワードの同期は、いつ行うか?

その疑問は「Microsoftアカウントは、いつWindows 8マシンとの間で同期しているのか?」が解れば解決できるだろう、ということで、パスワードの同期について少し調べてみました。

調査方法は次のとおりです。
まず、Windows 8マシンでadminユーザーとuser1ユーザーの2つのユーザーをローカルアカウントとして作成しました。そして、adminユーザーは私の持つMicrosoftアカウントと関連付けを行いました。
すると、もともとadminユーザーに割り当てられていたパスワードは破棄され、Microsoftアカウントで設定されているパスワードがadminユーザーのパスワードとして設定されました。

この時点で、Microsoftアカウントとuser1ユーザーのパスワードは同じパスワードになっているのですが、ここまでのところで、ローカルアカウントのデータベースをパスワードごとダンプしてみました。

skblog121128-1

ダンプされたデータのうち、一番左の列がユーザー名、一番右の列がパスワード(NTLMハッシュによる暗号化済み)です。adminユーザーとuser1ユーザーのパスワードの列を見てみると、もともと同じパスワードを設定していましたから、ダンプされたパスワードの値も同じになっていることが確認できます。

このことから、Microsoftアカウントのパスワードはローカルアカウント(ここではAdminユーザー)のパスワードとしてキャッシュされることも確認できますね。

続いて、Windows 8マシン以外のマシンからhttp://account.live.comにアクセスし、Microsoftアカウントでサインインして、パスワードの変更を行いました。

その後、Windows 8マシンをインターネット接続ができる状態で半日ほど放置したのですが、もう一度パスワードデータベースをダンプしてもキャッシュされているパスワードの値(パスワードハッシュの値)が変わることはありませんでした。

 

そこで、今度はWindows 8マシンでサインインを試してみることにしました。

まず、変更前のMicrosoftアカウントでサインインしました。すると、古いパスワードでも問題なくMicrosoftアカウントによるサインインに成功しました。ただし、サインイン後、Microsoftアカウントを利用するサービス(SkyDriveなど)にアクセスすると、パスワードが違うとのエラーが表示されます。

skblog121128-5

続いて、変更後のMicrosoftアカウントでサインインしました。すると、変更後のMicrosoftアカウントでもサインインに成功しました。そして、サインイン後にMicrosoftアカウントを利用するサービスには問題なくアクセスできることも確認できました。

以上のことから、次のようなことが言えると思います。

Microsoftアカウントによるサインインは、ローカルにキャッシュされているパスワードと比較し、同じであればサインイン成功とみなす(たとえ、Microsoftアカウントのパスワードと異なるパスワードであったとしても)。
一方、入力したパスワードがキャッシュされたパスワードと異なる場合はWindows Liveのサービスにアクアセスし、Windows Liveで格納されているパスワードと比較して、同じであればサインイン成功とみなす。

実際に、変更後のMicrosoftアカウントでサインインしたときの様子をWireSharkでキャプチャしてみると、確かにWindows Liveへのアクセスが確認できました。
(ちなみに、古いパスワードでサインインした時にはWindows Liveへのアクセスは確認できませんでした)

そして、Microsoftアカウントのパスワードが変わっていることが確認されると、それに合わせてキャッシュとして使われているローカルアカウントのパスワードも変更されるはずなので、変更後のMicrosoftアカウントのパスワードでサインインした後で、もう一度ローカルアカウントのデータベースをダンプしてみます。

skblog121128-4 

すると、adminユーザーとuser1ユーザーのパスワード(各行の右端)が異なることがわかります。

 

ということで、オンラインでMicrosoftアカウントのパスワードを変更しても、バックグラウンドで勝手にローカルアカウントのパスワードを変更してしまうわけではなく、Windowsのサインイン時に新しいパスワードでサインインしたときだけ、ローカルアカウントのパスワードが変更されるのです。

だから、何者かによってオンラインのMicrosoftアカウントのパスワードを変更されても、Windows自体のサインインには影響はないのですね。
(もちろん、Microsoftアカウント自体が乗っ取られてしまうのは重大な問題だから、それに対しては対処が必要です)

 

■余談

筆者はOffice365のアカウントと同一のアカウント名をMicrosoftアカウントでも持っているため、Windows 8からMicrosoftアカウントアカウントにサインインすれば、Office365にもシングルサインオンされるのかと淡い期待を持ちましたが、これはダメでした。
実はMicrosoftアカウントとOffice365アカウントもややこしい関係なんです。これは機会を改めて紹介できればと思います。

【TechNetライブラリより】仮想マシンのアクセス監査

マイクロソフトのTechNetライブラリから「Hyper-V Security Guide」というドキュメントが提供されています。

■Hyper-V Security Guide
http://technet.microsoft.com/en-us/library/dd569113.aspx

このドキュメントを読んでいたら、 「仮想マシンリソースのアクセス監査」という項目を見つけました。
内容は親パーティションからVHDファイルの監査を設定し、 イベントログで監査結果を確認する、
というものなのですが、 果たして、いかほどのものが記録されるのか試してみました。

設定に関する詳細はドキュメントにも記録されていますが、こちらでも簡単に記しておきます。

■グループポリシー
コンピューターの構成/ポリシー/Windowsの設定/セキュリティの設定/監査の詳細な設定/オブジェクトアクセス/ファイルシステムの監査-有効
■監査対象の仮想マシンが格納されたフォルダ
フォルダのプロパティ/セキュリティ/詳細設定/監査/Everyone – <監査するアクティビティ>

以上の設定ができたら、実際に監査対象となる仮想マシンを起動します。
実際に仮想マシンを操作した後、イベントビューアのセキュリティログを見ると、
イベントID4663でその内容を確認できます。
実際に確認できたログは以下のものがほとんどでした。

vmaudit1

vmaudit2

私が確認できたのは
SYSTEMアカウントによるvmms.exeプロセスと
NETWORK SERVICEアカウントによるvmwp.exeプロセスの2つでした。
ログを見るとわかるように、binファイルへのアクセス、vsvファイルへのアクセスなどは確認できても
そこから、具体的にどのようなアクセスがあったかは、せいぜいReadData、WriteDataのレベルでしかわかりません。
ドキュメントではVHDファイルに対する不正なアクセスを監視しよう!と呼びかけがありますが、
私が思うに、ログに記載されている内容は少し情報不足のように思います。
また、監査設定を行っている最中は仮想マシンのパフォーマンス低下も気になりました。

仮想マシンのバックアップは、親パーティションから子パーティションを一括で行うという手法が一般化されつつありますが、
仮想マシンのアクセス監査は、親パーティションからではなく、子パーティションごとに従来の手法で行っていくのが
良いのではないかと思います。子パーティションでのアクセス監査を行うときには、過去の投稿も参考にしてください。

参考情報
■【再掲】イベントビューアのクエリをカスタマイズする(1)
http://bit.ly/gPebYu
■【再掲】イベントビューアのクエリをカスタマイズする(2)
http://bit.ly/hd50sZ
■イベントビューアのクエリをカスタマイズする(3)
http://bit.ly/gMfZlx

NTLMセッションの制限とログの設定

今日は久しぶりにイベントビューアの情報を書き留めておきたいと思います。
(まだ情報としては不完全ですので、その点だけご了承を。)
イベントビューアからユーザーログオンを追跡するとき、2つのログオンに関連するイベントを追跡する方法があります。

・ イベントID 4624で記録されるログ
・ イベントID 4769で記録されるログ

このうち、イベントID 4769で記録される、サービスチケット(ST)の発行に関するログを参照する場合、
Active Directoryの認証で使われるKerberos認証を利用していることが前提となります。

しかし、Active Directory環境を利用していても、Kerberos認証が使われるとは限らず、
旧来の認証方法であるNTLMv2認証が引き続き使われる可能性があります。
具体的には、\\IPアドレスのようなアクセスを行ったときに、Kerberos認証が使われなくなります。

すると、イベントID4769でログオンを追跡しようとしても、NTLM認証が使われている限り、
イベントID4769は記録されず、実態が掴めないという問題が起きます。
そこで、Active Directoryをお使いであれば、グループポリシーから

NTLM認証がどのくらい使われているのかチェックする
NTLM認証を使えないようにする

を設定・確認することができるので、実態として自分のネットワーク環境ではどの程度、
NTLMv2認証が行われているのか確認または制限することができます。
実際のグループポリシーの設定項目としては、
コンピューターの構成/ポリシー/Windowsの設定/セキュリティの設定/ローカルポリシー/セキュリティオプション
の各項目になります。

NTLM1

ネットワークセキュリティで始まる項目を見ると、色々なNTLM関連の項目がありますね。
これらはWindows Server 2008 R2で新設された項目ばかりです。
ですので、以下のグループポリシー項目はWindows Server 2008 R2もしくはWindows7のみで利用できる機能です。

NTLMv2認証がどの程度、利用されたかについては、

ネットワークセキュリティ:NTLMを制限する:着信NTLMトラフィックを監査する
のグループポリシー項目、
そして、NTLMv2認証を制限する場合は、
ネットワークセキュリティ:NTLMを制限する:このドメイン内のNTLM認証
のグループポリシー項目を使います。

これらの設定については有効にした後、NTLMv2認証が発生すると、イベントビューアのNTLMログにログが記録されます。
現在、私の環境では、次のイベントログが実際に確認できています。

・イベントID 8001 発信を拒否したイベント
・イベントID 8002 着信を拒否したイベント
・イベントID 4002 NTLM認証要求のブロック (「着信NTLMトラフィック」項目を有効にした場合に記録)

他にも、記録されるイベントがあるようですが、確認でき次第、追記したいと思います。

仮想マシンの物理層セキュリティ

マイクロソフト製品のセキュリティにかかわる話を見聞きするとき、「多層防御」という言葉がよく出てきます。
そして多層防御には、さまざまな階層があり、そのひとつに「物理層」があります。
ところが、仮想マシンに対して多層防御を実践しようとしたときに、仮想マシンの「物理層」ってどこ?
という問題があります。

物理層については、Microsoft TechNet – セキュリティ対策の要件解説で次のように解説しています。

他の層をどれほど完璧に対策しても、サーバー自体が誰もが操作できる場所に置かれていたのでは意味がありません。たとえログオンできなくても、HDD を抜き出せばセキュリティ設定を無視してデータを読み出すのは容易です。入退室管理や盗難防止ワイヤーなどがこの層です。

 

これを仮想マシンに置き換えて考えてみると、「HDDを抜き出す」とはHyper-VのVHDファイルに直接
アクセスすること、と解釈することができます。そのため、Hyper-Vホスト上のVHDファイルに直接アクセスできれば、
仮想マシンのハードディスクに物理的にアクセスできるのと同じ意味になります。

そのため、仮想マシンのセキュリティを考えるうえで、仮想マシンのホストするHyper-Vホストの
セキュリティも重要になってくる、というのは前々から言われていたことだと思います。

一方、もうひとつの物理層の要素、メモリの内容に関してはどうか?というと、
IPA ISEC セキュア・プログラミング講座で次のように解説しています。

プログラムの異常終了時にメモリダンプが自動生成されることがあるが、これはメモリ上に展開していたデータをファイルに書き出しており、このデータに秘密データがあると流出につながる可能性がある。

 

ということで、こちらもメモリの内容がディスクに保存されることがあるため、
ディスクに物理的にアクセスできれば、メモリの内容についても盗み出される可能性があります。
さらに仮想マシンに関して言えば、メモリダンプを実行しなくても、
ホスト側からメモリダンプを手軽に生成できるツールが提供されており、

■Microsoft Hyper-V VM State to Memory Dump Converter (vm2dmp)
http://code.msdn.microsoft.com/vm2dmp

こうしたツールをホスト側から実行できれば、仮想マシンのメモリの内容はすべて取り出せてしまうという問題があります。

ということで、まわりくどい前置き&わかりずらい説明で申し訳ないですが、
今回はvm2dmpツールの利用から、仮想マシンのメモリに関するセキュリティについて考えてみたいと思います。

vm2dmpツールを上記サイトからダウンロードして、実行するときには

・Windows Server 2008 R2 または Windows 7 から実行すること
・Debuging Tools for Windows をインストールしておくこと (Windows SDKに同梱)
・Windbgなどで解析するときはシンボルファイルを用意しておくこと

の3点が必要になります。
そのほか、私の環境では、Debuging Tools for Windowsをインストールしたフォルダにある
symsrv.dllファイルをC:\WIndows\System32フォルダにコピーしておかないと動作しない、というのがありました。

以上がそろったところで、実際に実行してみます。
(vm2dmp.exeの実行方法は上記サイトに掲載されているので参考にしてください)
実行してみると、仮想マシンのメモリサイズと同じサイズのファイルが生成されます。
(今回の私のケースでいうと、メモリは4GBに設定してあったので、4GBのファイルが生成されます)

生成されたファイルをデバッグするときは、WIndbgツールなどを使うところですが、
ここでは、あえてバイナリエディターで開いてみたいと思います。

そして、こちらがバイナリエディターで開いた様子
vm2dmp

4GBあるデータの中から、探し出すのに苦労しましたが、
ご覧のように、メモリ内に格納されているパスワードが見つけ出せたことが確認できます。
ここでは、どのあたりに記録されててあったかなどの詳細は書きませんが、
経験則から、どのあたりに重要な情報が記録されているか知っている人なら、
簡単に見つけ出すことができてしまいますね。

物理ホストを自由にアクセスできる状態になってしまったら、
仮想マシンの状態保存 → メモリのダンプ → 解析
のステップで、パスワードなどの重要情報が知られてしまう可能性があるので、
仮想マシンを動作させている物理ホストのセキュリティって、今まで以上に重要になってきますね。
(仮想マシン側で、できる対策ってあるのだろうか?)

それにしても、あまりに便利すぎる世の中って、ちょっと怖いですね。