 TechNet Magazine June 2007

TechNet Magazine June 2007

セキュリティ: Windows Vista ユーザー アカウント制御の内部

ユーザー アカウント制御 (UAC) は、Windows Vista の新機能の中で特に誤解されやすい機能です。しかし、標準ユーザー権限で実行できるようにすることを目的としたこの機能によって、セキュリティ上の多くの問題が解決可能になります。この記事では、UAC で対処しようとしている問題や、この新機能のしくみについて詳しく説明します。

Mark Russinovich セキュリティ: BitLocker ドライブ暗号化を使用したデータ保護の概要

BitLocker は、非常に重要な 2 つの機能を提供します。1 つ目は、データのフルボリューム暗号化機能、2 つ目は、初期起動コンポーネントの整合性を検証してから Windows Vista を起動する機能です。この記事では、BitLocker のしくみと、BitLocker がどのようにして組織の保護に役立つかについて概説します。

Byron Hynes セキュリティ: Windows ファイアウォールの調査

モビリティによって、コンピュータの脅威とそれらに対する保護の手法が変化しました。ノート パソコンは境界の外に移動した後でネットワークに戻ってくるため、システムをより適切に保護する方法が必要です。Windows ファイアウォールを使用して、インターネット上および固有の内部ネットワーク上でコンピュータを保護する方法を検証します。

Steve Riley セキュリティ: セキュリティを強化する Windows Vista の新しい ACL

Windows Vista 環境で ACL が大きく改訂されたわけではありませんが、ACL を管理する際に理解しておくべき重要な変更が数多く行われています。この記事では、セキュリティを強化するために 30 個の ACL に行われた変更を明らかにし、こうした変更が組織に与える影響を調べて、インフラストラクチャ内でこのような変更を管理する方法について説明します。

Jesper Johansson セキュリティ: グループ ポリシーを使用してハードウェア制約を管理する

USB メモリをはじめとするリムーバブル デバイスは、プライベートでは便利でも、職場では厄介なものになり得ます。セキュリティを強化するには、ユーザーが各自の作業用システムにインストールするハードウェア デバイスを制御する必要があります。現在は、ユーザーが使用できるデバイスと使用できないデバイスの制御に、グループ ポリシーを使用することができるようになりました。

Jeremy Moskowitz セキュリティ : すべての IT 組織が持つべき 4 つのセキュリティ テクノロジ

ほとんどの企業は、同じようなセキュリティの問題を抱えています。現在のネットワークでつながれた世界では、すべての組織が必ず備えていなければならない、大別して 4 種類のセキュリティ ツールがあります。これらがどのようなツールであるのか、また将来理想的なセキュリティ ソリューションを生み出すために、関連するテクノロジがどのように連携して機能するのかを説明します。

Matt Clapham and Todd Thompson セキュリティ: 証明書管理用の新しい強力なツール

証明書は、インフラストラクチャ内の重要なコンポーネントです。いずれかの証明書の有効期限が切れた場合、企業の活動は停止する可能性があります。Microsoft PKI 環境で証明書の管理を行っている場合、新しい Identity Lifecycle Manager Certificate Management (ILM-CM) ソリューションを使用すると、スムーズな運用を継続することができます。この記事では、このツールが、認証処理の強化と証明書管理コストの削減にどのように役立つかについて説明します。

Kevin Dallmann 編集者から: セキュリティに関する問題

Joshua Trupin ツールボックス: IT プロのための新製品

Greg Steen SQL に関する Q&A: 64 ビット インストール、クラスタ メモリの割り当てなど

Edited by Nancy Michell ユーティリティ スポットライト: Windows Vista 用のスクリプト昇格 PowerToy

ユーザー アカウント制御によりセキュリティは大幅に強化されますが、特定の管理者タスクおよび機能を実行するには特権の昇格機能が不可欠です。この記事では、昇格の柔軟性と機能を高める "昇格 PowerToy" を紹介します。

Michael Murgolo The Cable Guy: Secure Socket トンネリング プロトコル

Windows XP および Windows Server 2003 の VPN プロトコルは、一部の構成には対応していません。この記事では、これらの問題について詳しく説明し、Windows Server "Longhorn" および Windows Vista Service Pack 1 で Secure Socket トンネリング プロトコルを使用してこれらの問題を解決する方法について説明します。

Joseph Davies Windows PowerShell: Active Directory を操作する

Windows PowerShell は、Get-ADSIObject コマンドレットを提供していませんが、それが理由で強力な ADSI サポートを提供できないということはありません。ここでは、型アダプタの概要を説明し、Windows PowerShell を使用してディレクトリ オブジェクトを操作する方法を学習します。

Don Jones Hey, Scripting Guy!: 赤い波線をスクリプトで処理する

Microsoft Word の辞書に用語を簡単に追加する方法を探していませんか。手動で一度に 1 単語ずつ追加する方法ではなく、もっと簡単な方法です。探してますよね。今月の Scripting Guys は、Microsoft Word のユーザー辞書を作成する方法と、プログラムを使用して、Word がそれらの辞書を使用するように構成する方法を紹介します。

The Microsoft Scripting Guys デスクトップ ファイル: データの損失を防ぐ方法

驚くべきことに、重要なデータの損失は頻繁に発生しています。しかし実際のところ、情報の損失は、ユーザーが情報の保護を怠っていることが原因で発生しています。この記事では、組織のデータをセキュリティで保護するために実施できる、また実施する必要がある重要な対策について説明します。

Wes Miller フィールド ノート: 開発者と話そう

より管理しやすいアプリケーションを開発者に作成してもらうのは、それほど難しいことではありません。すべてはコミュニケーションから始まります。開発者は、管理者とは違う視点でソフトウェアをとらえています。しかし管理者は、開発者と話すことによって、自分たちにとって重要な機能を説明することができ、開発者はそれに応じて、より適切なコードを設計することができます。

David Aiken Windows 秘話: 新規ユーザーのスタート メニューに表示される項目

新しく購入したコンピュータで Windows を起動し、[スタート] ボタンをクリックしたとき、空のメニューが表示されることを想像してください。ユーザーが初めて使用したときにも [スタート] メニューの最も頻繁に使用したアプリケーションのエリアに項目が表示され、すぐに操作を開始できるのは、こうした理由によるものです。これらのアプリケーションがどのように選択されるかについてご紹介します。

Raymond Chen レター: 質問への回答


 セキュリティ: Windows Vista ユーザー アカウント制御の内部
セキュリティ Mark Russinovich

Windows Vista ユーザー アカウント制御の内部
概要:
  • 標準ユーザーとして実行する
  • ファイルとレジストリの仮想化
  • アカウントの状態を昇格させる

ユーザー アカウント制御 (UAC) は、Windows Vista の中でも誤解されることの多い機能です。筆者が TechNet Magazine に連載した Windows Vista のカーネルの変更に関する 3 部構成の記事は technetmagazine.com でご覧いただけますが、UAC については単独で記事にした方がよいと思い、取り上げていませんでした。
この記事では、UAC が解決する問題と、UAC のコンポーネント テクノロジのアーキテクチャおよび実装について説明します。対象となるテクノロジには、以前には管理者権限が必要であった操作のリファクタリング、管理者権限がなくてもプログラムが正常に動作するようにするための軽量な仮想化、プログラムで明示的に管理者権限を要求する機能、同一デスクトップ上で実行する管理プロセスと非管理プロセスの分離などがあります。

UAC の目標
UAC は、管理者権限がなくても、標準ユーザー権限で操作を実行できるようにすることを目的としています。管理者権限が与えられているユーザーは、他のユーザーのコードやデータなどを含むオペレーティング システムのあらゆる部分、さらには Windows® 自体の読み取りおよび変更を行うことができます。管理者権限を持たないユーザーは、うっかりにせよ、意図的にせよ、システム設定を変更することはできないようになっており、これによって、マルウェアによりシステムのセキュリティ設定が改ざんされたり、ウイルス対策ソフトウェアが無効にされたり、ユーザーが共有コンピュータ上の他のユーザーの重要情報を侵害したりすることを防ぎます。つまり標準ユーザー権限で実行することにより、社内環境でのヘルプ デスクへの緊急の問い合わせが少なくなり、マルウェアの影響が緩和され、自宅用のコンピュータはより円滑に動作し、共有コンピュータ上の機密データを保護することができます。
標準ユーザー アカウントでの実行を実用的にするには、UAC でいくつかの問題に対処する必要がありました。まず、Windows Vista™ よりも前のバージョンの Windows では、管理者権限を使用することが想定されているため、ソフトウェア開発者はすべてのファイル、レジストリ キー、オペレーティング システムの設定をプログラムで参照して変更できるということを前提にしていました。Windows NT® のセキュリティでは、管理者アカウントと標準ユーザー アカウントのアクセスが区別されるようになりましたが、セットアップ時に、組み込みの Administrator アカウントまたは Administrators グループのメンバのアカウントを使用するよう推奨されます。
UAC で対処する必要がある 2 つ目の問題は、ソフトウェアのインストール、システム時刻の変更、ファイアウォールのポートのオープンなど、場合によって管理者権限が必要な操作があるということです。
これらの問題の解決策として、通常のアプリケーションは標準ユーザー権限で実行し、必要なときだけ管理者権限を使用するようにして、ソフトウェア開発者に標準ユーザー権限で動作するアプリケーションの作成を促すという方法があります。そのために、UAC では管理者権限を必要とする場合を減らし、レガシ アプリケーションを標準ユーザー権限で実行できるようにして、標準ユーザーが必要に応じて管理者権限でアクセスしたり、場合によっては管理者ユーザーが標準ユーザーとしてアクセスすることが簡単にできるようにしています。

標準ユーザーとして実行する
Windows Vista の開発時にすべての管理操作の全面的な監査を行った結果、標準ユーザーで実行してもシステムのセキュリティに影響しない操作が数多くあることがわかりました。たとえば、会社の Windows XP デスクトップ システムを標準ユーザー アカウントで使用しているユーザーが出張した場合を考えると、Windows XP でタイム ゾーンの変更とシステム時刻の変更が区別されないというだけの理由から、そのユーザーを Administrators グループから削除することは現実的ではありません。ノート パソコンを使用しているユーザーが、出張先でカレンダーの予定が正しく表示されるようにローカル タイム ゾーンを設定するには、"システム時刻の変更" 特権 (内部的に SeSystemTimePrivilege と呼ばれる) が必要ですが、この特権は既定では管理者のみに与えられます。
時刻は Kerberos などのセキュリティ プロトコルで共通に使用されますが、タイム ゾーンは時刻の表示方法を変更するだけなので、Windows Vista では 図 1 のように、新しく [タイム ゾーンの変更] 特権 (SeTimeZonePrivilege) を追加して Users グループに割り当てます。そのため、多くの企業のノート パソコン ユーザーは標準ユーザー アカウントで実行可能です。
図 1 [タイム ゾーンの変更] 特権
図 1 [タイム ゾーンの変更] 特権
Windows Vista の標準ユーザーは、ワイヤレス ネットワークに接続する際に WEP 設定を構成したり、VPN 接続を作成したり、電源管理の設定を変更したり、Windows の重要な更新プログラムをインストールしたりすることもできます。また、Windows Vista の標準ユーザーは、グループ ポリシーの設定を使用して、IT 管理者の承認を受けたプリンタ ドライバなどのデバイス ドライバをインストールしたり、管理者によって承認されたサイトから ActiveX® コントロールをインストールすることができます。
では、標準ユーザー アカウントで正常に動作しないコンシューマ アプリケーションや基幹業務 (LOB) アプリケーションの場合はどうでしょう。管理者権限を適正に要求しているソフトウェアもありますが、多くのプログラムはユーザー データを不必要にシステム グローバルの場所に保存しています。Microsoft では、管理者権限で実行するグローバルのアプリケーション インストーラで、アプリケーションの実行可能ファイルと補助データを保存するディレクトリを %ProgramFiles% ディレクトリの下に作成し、アプリケーションの設定用に HKEY_LOCAL_MACHINE\Software の下にキーを作成することを推奨しています。これにより、アプリケーションを異なるユーザー アカウントで実行することが可能になり、ユーザー固有のデータがユーザーごとの %AppData% ディレクトリに保存され、ユーザーごとの設定が HKEY_CURRENT_USER\ Software の下のユーザーのレジストリ プロファイルに保存されます。標準ユーザー アカウントには %ProgramFiles% ディレクトリや HKEY_LOCAL_MACHINE\Software への書き込みアクセス許可はありませんが、多くの Windows システムは単一ユーザー システムであり、Windows Vista より前のバージョンでは多くのユーザーに管理者権限が与えられているため、アプリケーションがユーザーのデータや設定を間違えてこれらの場所に保存しても、とりあえず動作します。
Windows Vista では、ファイル システムとレジストリ名前空間の仮想化を利用して、これらのレガシ アプリケーションを標準ユーザー アカウントで実行することが可能です。アプリケーションがファイル システムまたはレジストリのシステム グローバルの場所を変更し、アクセスが拒否されて操作が失敗すると、Windows はその操作をユーザーごとの領域にリダイレクトします。アプリケーションがシステム グローバルの場所から読み取りを行うと、Windows は、まずユーザーごとの領域のデータをチェックし、データが存在しなければ、グローバルの場所からの読み取りを許可します。
この仮想化のために、Windows Vista ではプロセスが 32 ビット (64 ビットではなく) であり、管理者権限で実行されておらず、Windows Vista 用に記述されていることを示すマニフェスト ファイルが存在しないプロセスを、レガシ プロセスとして扱います。この定義に従って、ネットワーク ファイル共有のアクセスなど、レガシとして分類されたプロセス以外からの操作は仮想化されません。プロセスの仮想化の状態はフラグとしてトークンに保存されます。トークンは、プロセスのユーザー アカウント、グループ メンバシップ、特権などのセキュリティ コンテキストを追跡するカーネル データ構造です。
プロセスの仮想化の状態を確認するには、タスク マネージャの [プロセス] ページに仮想化の列を追加します。図 2 は、多くの Windows Vista コンポーネント (Desktop Window Manager (Dwm.exe)、Client Server Runtime Subsystem (Csrss.exe)、エクスプローラなど) が、Windows Vista マニフェストが存在するか、管理者権限で実行されており仮想化が許可されていないために、仮想化が無効になっていることを示しています。Internet Explorer® (iexplore.exe) は、複数の ActiveX コントロールやスクリプトをホスト可能であり、標準ユーザー権限で正常に動作するようには記述されていないことを前提にする必要があるため、仮想化が有効になっています。
図 2 タスク マネージャに表示された仮想化の状態
図 2 タスク マネージャに表示された仮想化の状態
レガシ プロセス用に仮想化されたファイル システムの場所は、特定のサブディレクトリを除いて %ProgramFiles%、%ProgramData%、および %SystemRoot% です。.exe、.bat、.scr、.vbs など、実行可能な拡張子のファイルは仮想化の対象から外れます。そのため、標準ユーザー アカウントでは自動更新プログラムは失敗し、グローバルなスコープの更新プログラムを実行している管理者からは見えないプライベート バージョンの実行可能ファイルは作成されません。例外リストに拡張子を追加するには、次のレジストリ キーの後にそれらを入力してコンピュータを再起動します。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
複数行文字列型を使用して複数の拡張子を区切り、拡張子名の先頭にはドット (.) を付けないようにしてください。
レガシ プロセスにより仮想化されたディレクトリの変更は、ユーザーの仮想ルート ディレクトリ %LocalAppData%\VirtualStore にリダイレクトされます。たとえば、私のシステム上で仮想化プロセスを実行すると C:\Windows\Application.ini が作成されますが、このファイルの実体は C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini に作成されています。パスのローカル コンポーネントは、アカウントに移動プロファイルが設定されている場合に、仮想化されたファイルはローミングの対象外になるという事実を明確にします。
エクスプローラで仮想化されたファイルが格納されているディレクトリに移動すると、図 3 のように、ツールバーに [互換性ファイル] というボタンが表示されます。このボタンをクリックすると、対応する VirtualStore サブディレクトリに移動し、仮想化されたファイルが表示されます。
図 3 [互換性ファイル] ボタンをクリックすると、近くにある仮想化ファイルが表示される
図 3 [互換性ファイル] ボタンをクリックすると、近くにある仮想化ファイルが表示される
図 4 は、UAC ファイル仮想化フィルタ ドライバ (%SystemRoot%\System32\Drivers\Luafv.sys) でのファイル システム仮想化の実装方法を示しています。このドライバはファイル システムのフィルタ ドライバであるため、すべてのファイル システム操作を認識しますが、実装するのはレガシ プロセスからの操作の機能のみです。この図から、システム グローバルの場所にファイルを作成するレガシ プロセスのターゲット ファイル パスは変更されますが、標準ユーザー権限で Windows Vista アプリケーションを実行しているプロセスのターゲット ファイル パスは変更されないことがわかります。ユーザーが完全にアクセス可能な場所にファイルが作成されると、レガシ プロセスは操作が成功したと認識しますが、\Windows ディレクトリの既定のアクセス許可では、Windows Vista 用に記述されたアプリケーションのアクセスは拒否されます。
図 4 ファイル システムの仮想化
図 4 ファイル システムの仮想化
レジストリの仮想化の実装は、ファイル システムの仮想化の場合と若干異なります。仮想化されたレジストリ キーには多くの HKEY_LOCAL_MACHINE\Software ブランチが含まれますが、次のような例外も数多くあります。
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
レガシ アプリケーションによって共通に変更され、互換性や相互運用性の問題が生じないキーのみが仮想化されます。レガシ アプリケーションにより仮想化されたキーの変更は、ユーザーのレジストリの仮想ルート HKEY_ CURRENT_USER\Software\Classes\VirtualStore にリダイレクトされます。キーはユーザーの Classes ハイブ、%LocalAppData%\Microsoft\Windows\UsrClass.dat に配置され、他の仮想化されたファイル データと同様に、ユーザー プロファイルのローミングの対象外になります。
ファイル システムの場合のように仮想化された場所の固定的なリストを維持するのではなく、キーの仮想化の状態は、フラグとしてそのキーの REG_ KEY_DONT_VIRTUALIZE に保存されます。図 5 のように、Reg.exe ユーティリティで、このフラグおよび仮想化に関連するその他の 2 つのフラグ、REG_KEY_ DONT_SILENT_FAIL と REG_KEY_ RECURSE_FLAG を表示できます。REG_KEY_DONT_SILENT_FAIL を設定し、キーを仮想化しない (REG_KEY_DONT_VIRTUALIZE を設定する) 場合、キーを操作するためのアクセスを拒否されたレガシ アプリケーションに、そのアプリケーションが要求したアクセス許可ではなく、ユーザーが対象のキーに対して持っているアクセス許可が与えられます。REG_KEY_RECURSE_FLAG は、新しいサブキーが親の仮想化フラグを継承しているか、既定のフラグのままであるかを示します。
図 5 Reg ユーティリティで表示された仮想化フラグ
図 5 Reg ユーティリティで表示された仮想化フラグ
図 6 は、構成マネージャによるレジストリの仮想化の実装方法を示しています。構成マネージャは、オペレーティング システムのカーネル、Ntoskrnl.exe のレジストリを管理します。ファイル システムの仮想化と同様、仮想化されたキーのサブキーを作成するレガシ プロセスは、ユーザーのレジストリの仮想ルートにリダイレクトされますが、既定のアクセス許可では、Windows Vista プロセスへのアクセスは拒否されます。
ファイル システムおよびレジストリの仮想化と共に、アプリケーションによっては、標準ユーザー権限で正常に動作するためにやらなければならないことがあります。たとえば、アカウントについて Administrators グループのメンバシップをテストするアプリケーションは、Administrators グループ以外のユーザーが実行しても動作しません。そこで、Windows Vista はいくつかのアプリケーション互換性 shim を定義して、このようなアプリケーションが動作するようにします。標準権限で操作するためにレガシ アプリケーションに適用される一般的な shim を 図 7 に示します。企業の IT 担当者は、アプリケーション互換性ツールキット (ACT。technet.microsoft .com/windowsvista/aa905066.aspx から入手可能) およびその Standard User Analyzer (SUA) ユーティリティや、Aaron Margosis の LUA Buglight などのツールを使って、基幹業務 (LOB) アプリケーションの shim 要件を確認することができます。ACT に含まれている Compatibility Administrator を使ってアプリケーションに shim を割り当て、生成された互換性データベース (.sdb ファイル) をグループ ポリシー経由でデスクトップに展開します。必要に応じて、ローカル セキュリティ ポリシーの設定を使用して、システムの仮想化を完全に無効にすることができます。
Figure 7 一般的なユーザーの shim (Close Figure 7)

shim | 目的
ElevateCreateProcess | CreateProcess を変更し、Application Information Service を呼び出して昇格に同意するかどうかをユーザーに確認し、ERROR_ELEVATION_REQUIRED エラーを処理します。
ForceAdminAccess | 管理者グループのメンバシップに対するクエリをスプーフします。
VirtualizeDeleteFile | グローバルのファイルやディレクトリの削除が成功したようにスプーフします。
LocalMappedObject | グローバル セクション オブジェクトをユーザーの名前空間に強制配置します。
VirtualizeHKCRLite、VirtualizeRegisterTypeLib | COM オブジェクトのグローバルの登録をユーザーごとの場所にリダイレクトします。
仮想化の効果
プロセスの仮想化の状態を変更するには、タスク マネージャで右クリックしたときに表示されるコンテキスト メニューの [仮想化] を選択します。図 A は、仮想化の状態が変更されたときのコマンド プロンプトの動作を示しています。Windows Vista マニフェストが存在するため、まず、仮想化が無効になります。標準ユーザー権限で動作しているため、\Windows ディレクトリにファイルを作成できませんが、タスク マネージャで仮想化された後、ファイルは正常に作成されたように見えます。仮想化が無効の状態に戻ると、ファイルは見つかりません。実際には、このファイルはユーザーの仮想ストアに存在します。
図 A 仮想化の状態の変更
図 A 仮想化の状態の変更

管理者承認モード
ユーザーが標準ユーザー権限と互換性のあるプログラムのみを実行する場合でも、一部の操作には管理者権限が必要です。大多数のソフトウェアのインストールでは、システム グローバルの場所へのディレクトリやレジストリ キーの作成、およびサービスやデバイス ドライバのインストールに管理者権限が要求されます。システム グローバルの Windows およびアプリケーションの設定を変更する場合にも、Windows Vista の保護者による制限機能と同様、管理者権限が必要です。これらの操作の多くは、専用の管理者アカウントに切り替えることで実行可能になりますが、この切り替えが面倒で、多くのユーザーは日常的なタスクも管理者アカウントのままで行う可能性があります。
そこで、Windows Vista では "別のユーザーとして実行" する機能が追加され、標準ユーザーが便宜的に管理者権限でプロセスを起動できるようになっています。この機能には、必要に応じてシステムがアプリケーションに代わって管理者権限を取得することが可能な操作をアプリケーションで識別する手段が必要です。これについては後述します。
また、システム管理者の役割を果たすユーザーが標準ユーザー権限でシステムを実行し、必要があれば、その都度ユーザー名とパスワードを入力しなくても管理者権限でアクセスできるように、Windows Vista には管理者承認モード (AAM) が用意されています。この機能では、ログオン時に 2 つの ID を作成し、1 つは標準ユーザー権限、もう 1 つは管理者権限に使用します。Windows Vista システムのユーザーは標準ユーザーであるか、AAM で大部分は標準ユーザーとしてシステムを実行するため、開発者はすべての Windows ユーザーが標準ユーザーであるという前提に立つ必要があります。つまり、仮想化や shim を利用せずに標準ユーザー権限で使用するプログラムが多くなります。
プロセスに管理者権限を与えることを昇格と呼びます。また、昇格を標準ユーザー アカウントで行う場合、管理者グループのメンバであるアカウントの資格情報を入力する必要があり、この情報は標準ユーザーとは別のユーザーが肩越しに入力することが多いため、肩越し (OTS: Over the Shoulder) 昇格と呼びます。昇格を AAM ユーザーが行う場合、ユーザーが管理者権限の割り当てを承認するだけで昇格が完了するため、Consent elevation (同意による昇格) と呼びます。
Windows Vista では、ユーザーが図 8 の管理者タイプ グループのいずれかのメンバである場合、そのユーザーを管理者と認識します。この一覧に表示されているグループの多くはドメインに参加しているシステムでのみ使用され、直接ユーザーにローカル管理者権限を与えるわけではありませんが、グループのメンバはドメイン全体をスコープとする設定を変更することができます。ユーザーがこれらのグループのメンバであって、実際の管理者グループのメンバではない場合、そのユーザーは Consent elevation (同意による昇格) ではなく、OTS 昇格によって管理者権限を行使します。
Figure 8 管理者グループ (Close Figure 8)

ビルトイン管理者
証明書管理者
ドメイン管理者
エンタープライズ管理者
ポリシー管理者
スキーマ管理者
ドメイン コントローラ
エンタープライズ読み取り専用ドメイン コントローラ
読み取り専用ドメイン コントローラ
アカウント オペレータ
バックアップ オペレータ
暗号化オペレータ
ネットワーク構成オペレータ
プリント オペレータ
システム オペレータ
RAS サーバー
パワー ユーザー
Windows 2000 以前との互換アクセス
一覧にあるグループに属しているユーザーがログオンした場合、Windows Vista によりユーザーの管理 ID の標準ユーザー バージョンを表すトークンが作成されます。この新しいトークンでは、図 9 に示された既定の標準ユーザー特権を除いて、ユーザーに割り当てられたすべての特権が解除されています。また、新しいトークンでは、すべての管理者タイプ グループに USE_FOR_DENY_ONLY フラグが付けられます。図 10 は、Sysinternals Process Explorer (microsoft .com/technet/sysinternals からダウンロード可能なプロセス管理ツール) を示しています。このツールには、グループのメンバシップと、左側に管理者権限で動作しているプロセスの特権、右側に管理者権限なしで動作しているプロセスの特権が表示されます (誤用を防ぐため、Windows セキュリティ モデルでは、無効フラグが設定された特権を使用する場合には、使用する前に有効にする必要があります)。
Figure 9 標準ユーザー特権 (Close Figure 9)

フレンドリ名 | 内部名
スキャン チェックの回避 | SeChangeNotifyPrivilege
システムのシャットダウン | SeShutdownPrivilege
ドッキング ステーションからコンピュータを削除 | SeUndockPrivilege
プロセス ワーキング セットの増加 | SeIncreaseWorkingSetPrivilege
タイム ゾーンの変更 | SeTimeZonePrivilege
図 10 AAM 管理者および標準ユーザーのトークン
図 10 AAM 管理者および標準ユーザーのトークン
deny-only フラグが付いたグループはリソースへのユーザー アクセスを拒否するためにのみ使用され、アクセスの許可に使われることはありません。これにより、グループを完全に削除した場合に生じる可能性があるセキュリティ ホールをふさぎます。たとえば、Administrators グループのすべてのアクセスを拒否し、同じユーザーの別のグループに一部のアクセスを許可するアクセス制御リスト (ACL) がファイルに存在する場合、Administrators グループがトークンになければ、そのユーザーのアクセスは許可され、標準ユーザー バージョンのユーザー ID に管理者 ID より高いアクセス許可が与えられることになります。
一般に自宅用のコンピュータであるスタンドアロン システムと、ドメインに参加しているシステムでは、リモート ユーザーによる AAM アクセスの処理が異なります。これは、ドメインに接続しているコンピュータは、そのリソースへのアクセス許可でドメインの管理グループを使用できるためです。ユーザーがスタンドアロン コンピュータのファイル共有にアクセスすると、Windows はリモート ユーザーの標準ユーザー ID を要求しますが、ドメインに参加しているシステム上では、Windows はユーザーの管理者 ID を要求することによって、すべてのユーザーのドメイン グループ メンバシップを認識します。

便宜的に管理者権限でアクセスする
管理者権限が必要な操作をシステムやアプリケーションが識別する方法は複数あります。エクスプローラの UI に表示される [管理者として実行] というコンテキスト メニュー エントリおよびショートカット オプションがあります。選択した場合に権限が昇格するボタンやメニュー項目には、色付きの盾のアイコンが配置されます。[管理者として実行] を選択すると、エクスプローラは "runas" 動詞を指定して ShellExecute API を呼び出します。
大多数のインストール プログラムは管理者権限が必要であるため、実行可能ファイルを起動するイメージ ローダーには、レガシ インストーラである可能性があるインストーラを識別する検出コードがあります。その発見方法には、イメージのファイル名や内部バージョン情報に設定、インストール、更新という語句が含まれているかどうかを検出するだけの単純なものもあれば、サードパーティ製のインストール ラッパー ユーティリティに共通する実行可能ファイルのバイト シーケンスをスキャンする高度な手法が用いられているものもあります。
また、イメージ ローダーは、対象の実行可能ファイルに管理者権限が必要かどうかを確認するアプリケーション互換性 (appcompat) ライブラリを呼び出します。このライブラリは、アプリケーション互換性データベースを参照して、実行可能ファイルに RequireAdministrator フラグまたは RunAsInvoker フラグが関連付けられているかどうかを確認します。
実行可能ファイルが管理者権限を要求するには、アプリケーションのマニフェスト ファイルに requestedElevationLevel タグを追加するのが一般的な方法です。マニフェストはイメージに関する補足情報を含む XML ファイルです。Windows XP では、マニフェストは DLL や Microsoft .NET Framework アセンブリと連携して依存関係を判別する手段として用いられました。マニフェストの trustInfo 要素 (次の Firewallsettings.exe の文字列ダンプの抜粋を参照) は、実行可能ファイルが Windows Vista 用に記述されていること、およびファイル内で requestedElevationLevel 要素がネストしていることを示しています。この要素の level 属性は asInvoker、highestAvailable、および requireAdministrator の 3 つのうちいずれかの値を取ります。
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Notepad.exe のように管理者権限が不要な実行可能ファイルには asInvoker 値を指定します。管理者に常に最大限のアクセス許可が与えられることを想定している実行可能ファイルでは、highestAvailable 値が使用されます。この値で実行可能ファイルを実行すると、ユーザーは AAM で実行している場合、または事前に定義されたルールに従って管理者として認識された場合にのみ昇格を要求され、管理者権限でアクセスするには昇格が必要になります。Regedit.exe、Mmc.exe、Eventvwr.exe などは highestAvailable を使用するアプリケーションの例です。requireAdministrator では常に昇格が要求されます。この値は管理者権限がなければ操作できない実行可能ファイルに使用されます。
ユーザー補助アプリケーションでは、uiAccess 属性を "true" に指定して、昇格されたプロセスのウィンドウでの入力を促します。この機能を有効に利用するには、昇格されたプロセスが署名されており、%SystemRoot% や %ProgramFiles% などのセキュリティ保護された場所に保存されている必要があります。
実行可能ファイルによって指定された値を簡単に確認するには、次のように Sysinternals Sigcheck ユーティリティでマニフェストを表示します。
sigcheck –m <executable>
管理者権限が要求されるイメージを実行すると、サービス ホスト プロセス (%SystemRoot%\System32\Svchost .exe) 内部で実行される Application Information Service (AIS とも呼ばれ、%SystemRoot%\System32\Appinfo.dll に含まれている) が Consent.exe (%SystemRoot%\System32\Consent.exe) を起動します。Consent.exe は、画面のビットマップをキャプチャし、フェード効果を適用して、ローカル システム アカウントのみにアクセス可能なデスクトップに切り替え、ビットマップを背景として描画し、実行可能ファイルに関する情報を示す昇格ダイアログ ボックスを表示します。別のデスクトップに表示することにより、ユーザーのアカウントに存在するマルウェアによってダイアログ ボックスの外観が変更されることを防ぎます。
図 11 OTS 昇格ダイアログ
図 11 OTS 昇格ダイアログ
イメージが、Microsoft によってデジタル署名された Windows コンポーネントであり、Windows システム ディレクトリに保存されている場合、図 11 の最上段のダイアログのように、ダイアログの上部に青いストライプが表示されます。グレーのストライプ (中央のダイアログ) は、Microsoft 以外の第三者によってデジタル署名されたイメージであることを示し、オレンジのストライプ (最下段のダイアログ) は未署名のイメージであることを示します。昇格ダイアログにイメージのアイコン、説明、デジタル署名されたイメージの発行元が表示されますが、未署名のイメージの場合は一般的なアイコンとファイル名が表示されるだけで、発行元には "認証できない発行元" と表示されます。これにより、マルウェアが適正なソフトウェアの外観を模倣することが困難になります。ダイアログの下部にある [詳細] ボタンをクリックすると、ダイアログが展開されて、実行可能ファイルを起動した場合にその実行可能ファイルに渡されるコマンド ラインが表示されます。AAM 同意ダイアログ (図 12 参照) の場合も同様ですが、このダイアログでは、管理者の資格情報を要求する代わりに、[続行] ボタンと [キャンセル] ボタンが表示されます。
図 12 AAM 昇格ダイアログ
図 12 AAM 昇格ダイアログ
ユーザーが昇格を拒否すると、Windows は起動を開始したプロセスにアクセス拒否エラーを返します。ユーザーが管理者の資格情報を入力するか、[続行] をクリックして、昇格に同意すると、AIS は CreateProcessAsUser を呼び出して、適切な管理者 ID でプロセスを起動します。AIS は昇格されたプロセスの親ですが、起動されたプロセスの親プロセス ID に起動元プロセスの ID を設定する CreateProcessAsUser API の新しいサポートを使用します (図 13 参照)。そのため、昇格されたプロセスは、プロセス ツリーを表示する Process Explorer などのツールに AIS サービス ホスト プロセスの子として表示されません。
図 13 昇格フロー
図 13 昇格フロー
昇格ダイアログを単独のセキュリティ保護されたデスクトップに表示しても、表示されているのが適正なダイアログであり、マルウェアによって表示されたものでないことをユーザーが既定で確認する手段はありません。AAM ではマルウェアが偽の同意ダイアログで管理者権限を取得することはできないため、このことは問題になりませんが、マルウェアが標準ユーザーの OTS 昇格を待機し、それをインターセプトして、トロイの木馬のダイアログを使って管理者の資格情報をキャプチャする可能性はあります。キャプチャした資格情報を使って、マルウェアが管理者のアカウントにアクセスし、侵入することは可能です。
このような理由から、企業環境で OTS 昇格を使用することはあまりお勧めできません。OTS 昇格を無効にしてヘルプ デスクへの問い合わせを減らすには、ローカル セキュリティ ポリシー エディタ (Secpol.msc) を実行して [ユーザー アカウント制御: 標準ユーザーに対する昇格時のプロンプトの動作] を [昇格の要求を自動的に拒否する] に設定します。
セキュリティを意識するホーム ユーザーは、OTS 昇格に Secure Attention Sequence (SAS) を要求する設定にして、マルウェアのインターセプトやシミュレーションを防いでください。グループ ポリシー エディタ (Gpedit.msc) を実行して SAS を設定するには、[コンピュータの構成]、[管理用テンプレート]、[Windows コンポーネント]、[資格情報のユーザー インターフェイス] の順に移動し、[資格情報の入力に信頼済みパスを要求する] を有効にします。この操作を行うと、Ctrl + Alt + Del キーを押して昇格ダイアログを表示するように要求されます。

昇格されたプロセスを分離する
Windows Vista では、昇格されたプロセスの周囲にバリアを設け、同じデスクトップ上で標準ユーザー権限により実行されているマルウェアから保護します。バリアを設けなければ、マルウェアが、合成したマウスやウィンドウをウィンドウ メッセージ経由で送信して管理者アプリケーションを操作する可能性があります。標準の Windows セキュリティ モデルでも、標準ユーザー権限で動作しているプロセスの場合は、昇格されたプロセスを別のユーザーとして実行し、改ざんしようとするマルウェアの行為を阻止しますが、管理者ユーザーが標準権限で実行している場合は、マルウェアがユーザーの昇格されたプロセスを開き、コードを注入し、スレッドを起動して、注入したコードを実行する行為を阻止するしくみはありません。
Windows Vista のウィンドウ メッセージをブロックする機能をユーザー インターフェイス特権の分離 (UIPI) と呼びます。UIPI は新しい Windows Integrity Mechanism に基づいたテクノロジで、Windows Vista では昇格されたプロセスの周囲に設けるバリアとしても使用されています。この新しいセキュリティ モデルでは、すべてのプロセスおよびオブジェクトに整合性レベルが設定され、本来は Windows 随意アクセス制御 (DAC) セキュリティ モデルによってプロセスに付与されるアクセス許可をオブジェクトの整合性ポリシーによって制限することができます。
整合性レベル (IL) はセキュリティ識別子 (SID) によって表されます。ユーザーやグループも SID で表され、その場合、レベルは SID の相対識別子 (RID) にエンコードされます。図 14 は、4 つの主要な IL の表示名、SID、SID の RID を 16 進数で表した値を示しています。16 進数を見ると、各レベル間に 0x1000 の間隔がありますが、この間隔を利用して、UI ユーザー補助アプリケーションに使用する中間レベルを設けたり、将来使用することができます。
Figure 14 主な整合性レベル (Close Figure 14)

名前 | SID | RID
必須レベル (低) | S-1-16-4096 | 0x1000
必須レベル (中) | S-1-16-8192 | 0x2000
必須レベル (高) | S-1-16-12288 | 0x3000
必須レベル (システム) | S-1-16-16384 | 0x4000
図 15 は、オブジェクトの IL ポリシーと、そのポリシーで制限するアクセスの種類を示しています。これらは、オブジェクトに対して定義された汎用アクセスに対応しています。たとえば、No-Write-Up では、IL の低いプロセスは GENERIC_WRITE アクセスによって示されるすべてのアクセスを取得できません。ファイルやレジストリ キーなど、多くのオブジェクトの既定のポリシーは No-Write-Up であり、オブジェクトの随意アクセス制御リスト (DACL) によってユーザーにアクセスが許可されている場合でも、プロセスは上位の IL を持つオブジェクトへの書き込みアクセスを取得できません。これとポリシーが異なるオブジェクトはプロセス オブジェクトとスレッド オブジェクトのみです。この 2 つのオブジェクトのポリシーは No-Write-Up + No-Read-Up であり、この場合、下位の IL で実行しているプロセスは上位 IL のプロセスにコードを追加したり、上位 IL のプロセスからパスワードなどのデータを読み取ることはできません。
Figure 15 整合性レベルのポリシー (Close Figure 15)

ポリシー | 効果
No-Write-Up | 下位の IL プロセスは上位の IL オブジェクトを変更できない
No-Read-Up | 下位の IL プロセスは上位の IL オブジェクトから読み取ることができない
No-Execute-Up | 下位の IL プロセスは上位の IL オブジェクトを実行できない
Windows はすべてのプロセスに対して、プロセスを実行しているユーザーが属するグループの SID と共に、プロセスのトークンに配置された IL を割り当てます。図 16 は、複数の IL に割り当てられたプロセスの例を示しています。通常、プロセスは親の IL を継承しますが、AIS が昇格されたプロセスを起動するときのように、別の IL でプロセスを起動することも可能です。プロセスの整合性レベルを確認するには、組み込みの Whoami ユーティリティに /all オプションを指定するか、Sysinternals Process Explorer または AccessChk を使用します。Process Explorer では、整合性レベルの列を追加すると、プロセスの IL が表示されます。
Figure 16 プロセスの整合性レベルの割り当てサンプル (Close Figure 16)

整合性レベル | プロセスの例
必須レベル (低) | 保護モードの Internet Explorer および保護モードの Internet Explorer で起動されたプロセス
必須レベル (中) | 標準ユーザーおよび昇格していない AAM プロセス
必須レベル (高) | 管理者権限で実行されているプロセス
必須レベル (システム) | ローカル システム、ローカル サービス、ネットワーク サービスの各プロセス
セキュリティ設定が可能なすべてのオブジェクトには明示的または黙示的に IL があります。プロセス、スレッド、およびトークンの各オブジェクトには必ず明示的に IL が割り当てられ、通常、その IL は対応するプロセス トークンに保存されている IL と同じです。多くのオブジェクトには明示的な IL が存在しないため、既定で中 (Medium) の IL に設定されます。"中" 以外の IL で作成されるオブジェクトは、低 (Low) IL で動作しているプロセスによって作成されたオブジェクトのみであるため、その IL は "低" です。組み込みの iCacls ツール (%SystemRoot%\System32\iCacls.exe) を使用して、ファイルの IL を確認できます。また、Sysinternals AccessChk ユーティリティを使用して、ファイル、レジストリ キー、サービス、およびプロセスの IL を確認できます。図 17 を見ると、保護モードの Internet Explorer でアクセスできる必要があるディレクトリの IL が "低" であることがわかります。
図 17 AccessChk で表示したユーザーのお気に入りディレクトリの IL
図 17 AccessChk で表示したユーザーのお気に入りディレクトリの IL
オブジェクトに明示的な IL が存在する場合は、Windows Vista で新しく登場したラベル ACE というタイプのアクセス制御エントリ (ACE) に保存されます。このエントリはオブジェクトのセキュリティ記述子のシステム アクセス制御リスト (SACL) にあります (図 18 参照)。ACE の SID はオブジェクトの IL に相当し、ACE のフラグはオブジェクトの整合性ポリシーをエンコードします。Windows Vista より前のバージョンでは、SACL で "監査とセキュリティ ログの管理" 特権 (SeSecurityPrivilege) が必要な監査 ACE のみが保存されていましたが、ラベル ACE の読み取りに必要な権限は、読み取りアクセス許可 (READ_CONTROL) のみです。プロセスがオブジェクトの IL を変更するには、オブジェクトに対する変更所有者 (WRITE_OWNER) アクセス許可とそのオブジェクト以上の IL が必要であり、プロセスが IL を設定できるのはそのプロセス以下の IL に対してのみです。新しい "オブジェクト ラベルの変更" (SeRelabelPrivilege) 特権は、プロセスに対して、アクセス可能なすべてのオブジェクトの IL を変更する権限を与え、IL をプロセス自身の IL より上位に引き上げることも可能です。ただし、既定では、どのアカウントにも特権は割り当てられません。
図 18 オブジェクトのラベル ACE
図 18 オブジェクトのラベル ACE
プロセスがオブジェクトを開こうとすると、カーネルの SeAccessCheck 関数で標準の Windows DACL チェックが実行される前に整合性チェックが行われます。既定の整合性ポリシーでは、プロセスが書き込みアクセス許可でオブジェクトを開くには、そのオブジェクト以上の IL が必要であり、プロセスが要求するアクセス許可を DACL からも付与される必要があります。たとえば、DACL がプロセスに書き込みアクセス許可を与えた場合でも、"低" の IL プロセスが "中" の IL プロセスを書き込みアクセス許可で開くことはできません。
既定の整合性ポリシーでは、オブジェクトの DACL で読み取りアクセス許可が付与されていれば、プロセスはプロセス オブジェクトおよびスレッド オブジェクト以外のすべてのオブジェクトを読み取りアクセス許可で開くことができます。つまり、"低" の IL プロセスは、そのプロセスを実行しているユーザー アカウントでアクセス可能なすべてのファイルを開くことができます。保護モードの Internet Explorer では、IL を使って、侵入したマルウェアによってユーザー アカウントの設定が変更されることは防ぎますが、マルウェアがユーザーのドキュメントを読み取ることは防げません。
プロセス オブジェクトおよびスレッド オブジェクトの場合は、整合性ポリシーに No-Read-Up も指定されているため、上記とは扱いが異なります。プロセスの IL には、開こうとしているプロセスまたはスレッド以上の IL が必要であり、対象オブジェクトを開くためのアクセス許可を DACL で付与される必要があります。図 19 は、必要なアクセスが DACL で許可されているものとして、"中" および "低" で動作しているプロセスが他のプロセスやオブジェクトに対して持つアクセス許可を示しています。
図 19 オブジェクトおよびプロセスのアクセス許可
図 19 オブジェクトおよびプロセスのアクセス許可
Windows メッセージング サブシステムも、わずかな情報量のウィンドウ メッセージを送信する以外、上位 IL のプロセスが所有するウィンドウに対する送信をブロックすることで、UIPI を実装するための整合性レベルを確保します。これにより、標準ユーザー プロセスが、昇格されたプロセスのウィンドウに入力を促進したり、内部バッファ オーバーフローが生じるような不正なメッセージを送信して昇格されたプロセスを破壊することがなくなります。プロセスが ChangeWindowMessageFilter API を呼び出し、セキュリティを突破してメッセージを追加する可能性はあります。UIPI は、ウィンドウ フックによる上位 IL プロセスのウィンドウの変更もブロックし、たとえば、ユーザーが管理者アプリケーションに入力したキー ストロークを標準ユーザー プロセスがログに記録するなどの行為を阻止します。

昇格とセキュリティ境界
UAC の昇格は便利な機能であり、セキュリティ境界ではないということを認識しておくことが重要です。セキュリティ境界には、境界の通過を許可する対象を指定するセキュリティ ポリシーが必要です。ユーザー アカウントは、ユーザーにアクセス許可が与えられなければ他のユーザーのデータにアクセスすることはできないしくみであるため、Windows のセキュリティ境界の一例であるといえます。
昇格はセキュリティ境界ではないため、標準ユーザー権限でシステムを実行しているマルウェアが昇格されたプロセスを侵害し、管理者権限を取得する可能性がないという保証はありません。たとえば、昇格ダイアログは、昇格される実行可能ファイルを識別するだけで、そのファイルを実行するとどのような動作をするかについての情報は提供しません。実行可能ファイルはコマンド ライン引数を処理し、DLL を読み込み、データ ファイルを開き、他のプロセスと通信します。これらの操作のどこかで、昇格されたプロセスがマルウェアによって侵害され、管理者権限を盗まれる可能性はあります。
低 IL のサンドボックス内で操作する
保護モードの Internet Explorer は低 IL で動作し、プロセスに侵入する可能性があるマルウェアに対するフェンスを作成します。これにより、マルウェアがユーザー アカウントの設定を変更し、自身を自動起動ための場所にインストールすることを防ぎます。実験してみるには、Sysinternals PsExec ユーティリティに -l スイッチを指定して、任意のプロセスを低 IL で起動します。図 B は、低 IL で動作しているコマンド プロンプトでは、ユーザーの中 IL の一時ディレクトリにはファイルを作成できず、低 IL の Internet Explorer 一時ディレクトリにはファイルを作成できるということを示しています。
図 Bコマンド プロンプトでファイルを作成できるのは同じ IL の場合のみ

昇格された AAM プロセスは、AAM ユーザーの標準権限プロセスと同じユーザー アカウントで動作し、ユーザーのプロファイルを共有するため、特に侵害を受ける可能性が高くなります。多くのアプリケーションでは、ユーザーのプロファイルから設定を読み取り、登録された拡張を読み込むため、マルウェアが昇格する可能性が生まれます。たとえば、コモン コントロール ダイアログではユーザーのレジストリ キー (HKEY_CURRENT_USER 以下) に設定されたシェル拡張を読み込むため、マルウェアが自身を拡張として追加すれば、昇格されたプロセスがコモン コントロール ダイアログを使用したときにその拡張が読み込まれます。
標準ユーザー アカウントから昇格したプロセスの場合も、状態を共有しているために侵害される可能性があります。ログオン セッションで動作しているすべてのプロセスは、Windows がイベント、ミューテックス、セマフォ、共有メモリなどのオブジェクトを保存する内部的な名前空間を共有しています。昇格されたプロセスの起動時に、そのプロセスが特定の共有メモリ オブジェクトを開いて読み取ろうとしていることをマルウェアが察知すれば、バッファ オーバーフローが発生するコンテンツでオブジェクトを作成し、昇格されたプロセスにコードを注入する可能性があります。この種の攻撃は比較的高度ですが、少しでも攻撃の可能性があるかぎり、OTS 昇格はセキュリティ境界であるとはいえません。
昇格は、本質的には、管理者権限でのアクセスを利用するユーザーが、既定では標準ユーザー権限で実行することを促すための便宜的な機能として導入されたものです。セキュリティ境界のような保証はありませんが、日常的なタスクには標準ユーザー アカウントを使用し、管理作業を行うときにはユーザーの簡易切り替え (FUS) で専用の管理者アカウントに切り替えるという方法には便利さというメリットがあります。これに対し、セキュリティよりも便利さを優先する場合には、コントロール パネルの [ユーザー アカウント] ダイアログでシステムの UAC を無効にすることができます。ただし、UAC を無効にすると、Internet Explorer の保護モードも無効になることに注意してください。

まとめ
システムを標準ユーザーとして実行することにより、偶発的または故意による損害からシステムが保護され、システムを共有するユーザーのデータや整合性が不正なアクセスから守られる、など多くのメリットがあります。UAC のさまざまな変更やテクノロジにより、Windows の使用モデルは大きく変わります。Windows Vista になってはじめて、Windows ユーザーは多くの日常作業および多くのソフトウェアを標準ユーザー権限で実行することが可能になりました。現在、多くの企業が標準ユーザー アカウントを使用しています。

Mark Russinovich は、Microsoft の Platform and Services Division に所属するテクニカル フェローです。また、『インサイド Microsoft Windows』(Microsoft Press、2004) の共同執筆者であり、IT カンファレンスや開発者向けカンファレンスで頻繁に講演を行っています。彼は、共同で設立した Winternals Software 社の Microsoft による先ごろの買収に伴い、Microsoft に入社しましたが、Sysinternals の設立者でもあり、同社では Process Explorer、Filemon、および Regmon の各ユーティリティを発表しています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 セキュリティ: BitLocker ドライブ暗号化を使用したデータ保護の概要
セキュリティ Byron Hynes

BitLocker ドライブ暗号化を使用したデータ保護の概要
概要:
  • フルボリューム暗号化
  • BitLocker のキー
  • BitLocker をセットアップする

Windows BitLocker ドライブ暗号化は、Windows Vista で最もよく話題になっている機能の 1 つであることは間違いありません。しかし、ほとんどのユーザーは、特にトラステッド プラットフォーム モジュール (TPM) が装備されているコンピュータで、
BitLocker を実際にテストして、その機能としくみを確認する機会をまだあまり与えられていません。この記事では、BitLocker™ の潜在能力を評価し、アップグレード計画に加えられるように、BitLocker の概要について説明します。まず、背景と概念的な情報を提供した後、BitLocker の有効化、データの回復、および管理について説明します。その後、BitLocker がコンピュータの廃棄時にどのように役立つかについて説明します。この記事で使用されている用語の詳細については、補足記事の「ディスクとボリューム」を参照してください。
ディスクとボリューム
ディスクとボリュームに関する用語は、意味を混同してしまうことがよくあります。これらの用語に関する簡単な説明を次に示します。
パーティション : パーティションは、物理ハード ディスクの一部分であり、ディスク上に保存されているパーティション テーブルで定義された論理構造です。
ボリューム : ボリュームは、Windows 内の論理構造です。1 つ以上のパーティションから構成されており、ボリューム マネージャという Windows コンポーネントによって定義されます。ボリューム マネージャと起動コンポーネントを除いた、オペレーティング システムのすべてのコンポーネント、およびアプリケーションは、パーティションではなくボリュームを操作します。通常、Windows クライアント オペレーティング システム (Windows Vista など) の場合、パーティションとボリュームは一対一で対応しています。サーバーの場合は、標準的な RAID 構成のように、複数のパーティションから 1 つのボリュームが構成されることがよくあります。
アクティブ パーティション : アクティブ パーティションとして一度にマークできるパーティションは 1 つのみです。このパーティションには、オペレーティング システムの起動に使用されるブート セクタが含まれています。アクティブ パーティションは、システム パーティションやシステム ボリュームと呼ばれることもありますが、Windows OS ボリュームとは混同しないようにしてください。
Windows OS ボリューム : このボリュームには、System フォルダや System32 フォルダなどの Windows インストールが含まれています。Windows Vista がリリースされる前は、ブート パーティションと呼ばれていました (現在でもこのように呼ばれることがよくあります)。Windows OS ボリュームという呼び方のほうが、意味がわかりやすく、今までのように、ブート パーティションとシステム パーティションを混同することもなくなります。昔の指導者は受講者に、"システム パーティションからブートが実行され、ブート パーティション上にシステム ファイルがある" と教えていました。
Windows Vista より前のオペレーティング システムでは、Windows OS ボリューム (ブート パーティション) とアクティブ パーティション (システム パーティション) は同じディスク領域を指していました。これは、ほとんどのクライアント コンピュータのハード ディスクが、1 つの大きなパーティションとして構成されていたためです。図 A に示されている、Windows Vista のディスクの管理コンソールでは、各パーティションまたはボリュームに割り当てられた機能を確認できます。
図 A パーティションの機能
図 A パーティションの機能

BitLocker は、2 つの機能を提供します。これらは相補的ですが、異なる機能です。1 つ目は、Windows® OS ボリュームのフルボリューム暗号化機能です。2 つ目は、互換性のある TPM が装備されたコンピュータで、初期起動コンポーネントの整合性を検証してから、Windows Vista™ の起動を許可する機能です。
BitLocker のすべての機能を使用するには、コンピュータに、互換性のある TPM マイクロチップと BIOS が装備されている必要があります。具体的には、TPM Version 1.2、および Trusted Computing Group (TCG) によって定義された Static Root of Trust Measurement と TPM をサポートする BIOS が使用されている必要があります。ただし、互換性のある TPM と BIOS を装備していないコンピュータでも、BitLocker 暗号化を使用できます。

フルボリューム暗号化
BitLocker によって提供されるフルボリューム暗号化機能を使用すると、Windows OS ボリュームに書き込まれるすべてのデータを暗号化できます。この機能は、組織のコンピュータ (特にノート パソコンやモバイル コンピュータ) に格納された機密情報を保護するための重要な機能です。
モバイル コンピュータの紛失や盗難は、毎日のように発生しています。また、ポータブル コンピュータの機能が強化され、モバイル ユーザーが増加したため、1 人の社員が、組織の企業秘密、機密文書、顧客の個人情報 (PII) などを何百 GB という単位で持ち運んでいる可能性があります。ニュースを検索すると、このようなデータが非常に多く紛失していることがわかります (Privacy Rights Clearinghouse によると、2005 年以降、1 億件を超える個人情報が紛失または流出しました)。
ほとんどの組織は、既に法律や企業内の指示に従って、多くの種類の個人情報を保護しています。また、おそらく法律で義務付けられていなくても、仕事上、個人情報の保護に関心を持たざるを得ません。

ボリューム全体を暗号化する理由
経験豊富な Windows 管理者であれば、暗号化ファイル システム (EFS) などの Windows ベースの暗号化オプションや、Rights Management Services (RMS) によって提供される暗号化機能と保護機能について、よく知っていると思います。これらの暗号化機能と BitLocker の最も大きな違いは、BitLocker を一度有効にすると、自動的かつ透過的に、ボリューム全体の暗号化が実行される点です。
たとえば、EFS を使用する場合、保護するファイルとフォルダを明確に指定する必要があります。Windows Vista では、EFS の柔軟性を強化できる新しいオプションがいくつか提供されます。また、BitLocker ではなく、EFS や RMS でなければ対処できないシナリオもあります。しかし、EFS や RMS を使用する場合、管理者は膨大な量の構成作業を行う必要があります。また、EFS や RMS は、ボリューム上に格納されたすべてのデータを保護するように設計されていません。
これに対して、BitLocker は、BitLocker によって保護されたボリュームに書き込まれるすべてのデータを暗号化します。たとえば、オペレーティング システム、レジストリ、休止状態のファイルとページング ファイル、アプリケーション、アプリケーションによって使用されるデータなどが暗号化されます。
また、BitLocker は、3 つのアイテムを暗号化しません。暗号化されないアイテムは、ブート セクタ、読み取り不可能としてマークされた不良セクタ、およびボリューム メタデータです。ボリューム メタデータは、BitLocker の管理に使用されるデータの 3 つの冗長なコピーから構成されます。これらのデータには、ボリュームに関する統計情報、一部の解読キーの保護されたコピーなどが含まれています。これら 3 つのアイテムは、一意でもなく、重要でもなく、個人も特定できないため、暗号化する必要はありません。
フルボリューム暗号化は、オフライン攻撃からコンピュータを保護します。オフライン攻撃とは、オペレーティング システムによる制御の回避を試みることによって展開される攻撃です。たとえば、よくあるオフライン攻撃には、コンピュータを盗み、ハード ドライブを取り外し、そのドライブを (別にインストールされた Windows や、異なるオペレーティング システムを実行している) 別のコンピュータに 2 番目のドライブとして取り付けることによって、NTFS アクセス許可やユーザーのパスワードによる制御を回避しようとする方法があります。BitLocker によって保護されたボリュームは、このような攻撃によって読み取ることはできません。

BitLocker がデータを暗号化するしくみ
BitLocker は、Advanced Encryption Standard (AES) アルゴリズムと 128 ビットのキーを使用します。保護を強化する場合は、グループ ポリシーか、BitLocker の Windows Management Instrumentation (WMI) プロバイダを使用して、キーを 256 ビットに拡張できます。
ボリュームの各セクタは、個別に暗号化されます。その暗号化キーの一部は、セクタ番号を基に生成されます。つまり、同一のデータであっても、別のセクタに保存されていれば、これらのデータは異なるバイト列に暗号化され、ディスクに書き込まれます。このため、既知の情報の暗号化を利用してキーを解読することは非常に難しくなりました。
また、BitLocker は、AES を使用してデータを暗号化する前に、ディフューザというアルゴリズムを使用します。暗号化については詳しく説明しませんが、ディフューザについて簡単に説明すると、ディフューザとは、プレーンテキストに対してどんなに小さな変更が加えられた場合でも、セクタ全体の暗号化テキストを変更するアルゴリズムです。これにより、攻撃者はさらにキーやデータを解読しにくくなります。
BitLocker 暗号化アルゴリズムの詳細については、Neil Ferguson の記事「AES-CBC と Elephant ディフューザ : Windows Vista のディスク暗号化アルゴリズム」を参照してください。

BitLocker のキー
暗号化を行う際は、必ずキーについて知っておく必要があります。BitLocker もこの例外ではありません。BitLocker が使用するキーのアーキテクチャは優れていますが、多少複雑です。
セクタ自体は、フルボリューム暗号化キー (FVEK) と呼ばれるキーを使用して暗号化されますが、ユーザーは FVEK を使用したり、FVEK にアクセスしたりすることはできません。さらに FVEK は、ボリューム マスタ キー (VMK) と呼ばれるキーを使用して暗号化されます。このレベルまで抽象化することによって、他の方法では得られないメリットを得ることができますが、処理のしくみは理解しにくくなります。FVEK は、厳重に保護されたシークレットとして保持されます。これは、FVEK が解読された場合、すべてのセクタの再暗号化が必要になるためです。すべてのセクタの再暗号化は時間がかかるため、できれば実行したくない操作です。このため、システムは VMK を使用します。
(VMK を使用して暗号化された) FVEK は、ボリューム メタデータの一部としてディスクに保存されます。FVEK はローカルに保存されますが、暗号化されていない状態でディスクに書き込まれることはありません。
VMK も、1 つ以上のキー保護機能によって暗号化されます (つまり、保護されます)。既定のキー保護機能は TPM です。次のセクションでは、整合性チェックについて説明しますが、このセクションで、TPM の使用方法についても説明します。また、緊急時用に作成されるキー保護機能として、回復パスワードがあります。回復についても、この後のセクションで説明します。
TPM を、数値で表された PIN や、USB ドライブに保存された部分キーと組み合わせることによって、セキュリティを強化することができます。どちらの場合も、二要素認証を実現できます。コンピュータに、互換性のある TPM チップと BIOS が装備されていない場合、キー保護機能をすべて USB ドライブに格納するように BitLocker を構成することができます。このようにして作成されたキーは、スタートアップ キーと呼ばれます。
データを復号化せずに、BitLocker を無効にすることができます。この場合、VMK を保護するのは、暗号化されていない状態で保存された、新しいキー保護機能のみです。システムは、このクリア キーを使用することによって、ドライブが保護されていないかのように、そのドライブにアクセスできます。
起動時に、システムは適切なキー保護機能の検出を試みます。まず TPM に照会し、USB ポートをチェックして、必要な場合はユーザーにキー保護機能の提供 (回復と呼ばれます) を要求します。キー保護機能が検出された場合、Windows は、VMK を復号化し、FVEK を復号化して、ディスクに保存されているデータを復号化できます。図 1 は、この処理手順を示しています。
図 1 BitLocker の既定の起動処理
図 1 BitLocker の既定の起動処理

整合性チェック
コンピュータを起動するには、起動処理の初期段階で使用されるコンポーネントが、暗号化されていない状態になっている必要があります。このため、攻撃者は、ディスク上のデータが暗号化された場合でも、(ルートキットなどを使用して) 初期起動コンポーネントのコードを変更することで、コンピュータにアクセスできる可能性があります。
侵入者は、このような攻撃を使用することで、BitLocker のキーやユーザーのパスワードなどの機密情報にアクセスし、その情報を利用して、他のセキュリティ保護を解除できる可能性があります。
BitLocker を作成したチームの最初の目的は、このような攻撃からコンピュータを保護することでした。ある意味では、暗号化によって、その目的はほぼ達成されていました。BitLocker のフルボリューム暗号化を使用することにより、初期起動コンポーネントが変更された場合に、システムの整合性を保護し、Windows が起動しないようにすることができるようになります。
互換性のある TPM が装備されたコンピュータでは、コンピュータを起動するたびに、BIOS、マスタ ブート レコード (MBR)、ブート セクタ、ブート マネージャのコードなどの各初期起動コンポーネントが、実行されるコードを調べ、ハッシュ値を計算し、その値をプラットフォーム構成レジスタ (PCR) と呼ばれる TPM 内のレジスタに格納します。一度 PCR に格納された値は、システムが再起動されるまで、置換または消去することはできません。BitLocker は、PCR に格納された値と TPM を使用して、VMK を保護します。
TPM は、特定の PCR の値に関連付けられたキーを作成できます。このキーの作成時に、TPM はキーを暗号化します。キーを暗号化した TPM のみが、このキーを復号化できます。さらに、その TPM がキーを復号化できるのは、現在の PCR の値が、キーの作成時に指定された値と一致する場合のみです。この暗号化操作を、TPM を使用したキーの "シール" といいます。
既定では、BitLocker は、Core Root of Trust Measurement (CRTM)、BIOS とプラットフォームの機能拡張、オプションの ROM コード、MBR コード、NTFS ブート セクタ、およびブート マネージャの計測値を使用してキーをシールします。これらの計測値のいずれかが突然変更された場合、BitLocker はドライブをロックし、アクセスまたは復号化できないようにします。
既定では、BitLocker は TPM を検出して使用するように構成されています。グループ ポリシーやローカル ポリシーの設定を使用すると、TPM が装備されていないコンピュータでも、BitLocker を動作させ、外付けの USB フラッシュ ドライブにキーを格納することができます。ただし、TPM が装備されていない場合、BitLocker はシステムの整合性を検証できません。

BitLocker を有効にする
BitLocker は、Windows Vista Enterprise と Windows Vista Ultimate で使用できます (また、Windows Server® の次期バージョンであるコード ネーム "Longhorn" でも、オプション コンポーネントとして提供される予定です)。
次の説明は、互換性のある TPM が装備された、テスト用のコンピュータがあることを前提としています。TPM が装備されていないコンピュータで BitLocker を有効にするには、補足記事「TPM が装備されていないコンピュータで BitLocker を使用する」に記載されている手順を参照してください。
TPM が装備されていないコンピュータで BitLocker を使用する
既定では、BitLocker は TPM を使用するように構成されています。コンピュータに TPM が装備されていない場合、既定の Windows では、BitLocker を有効にすることができません。ただし、次の手順 (「Windows BitLocker ドライブ暗号化のステップ バイ ステップ ガイド」から引用しました) を実行すると、TPM が装備されていないコンピュータでも BitLocker を使用できます。
これらの手順を実行するには、管理者としてログオンしている必要があります。TPM が装備されていない場合、そのコンピュータでは、起動処理中に USB フラッシュ ドライブから読み取りを実行できる必要があります。さらに、BitLocker を有効にするとき、およびコンピュータを再起動するときに、USB フラッシュ ドライブが接続されている必要があります。
互換性のある TPM が装備されていないコンピュータで BitLocker ドライブ暗号化を有効にするには、次の手順を実行します。
  1. [スタート] ボタンをクリックし、[検索の開始] ボックスに「gpedit.msc」と入力し、Enter キーを押します。
  2. [ユーザー アカウント制御] ダイアログ ボックスが表示された場合、提示された操作が目的の操作であることを確認し、[続行] をクリックします。
  3. グループ ポリシー オブジェクト エディタのコンソール ツリーで、[ローカル コンピュータ ポリシー] をクリックし、[管理用テンプレート] をクリックします。次に、[Windows コンポーネント] をクリックし、[BitLocker ドライブ暗号化] をダブルクリックします。
  4. [コントロール パネル セットアップ : 詳細なスタートアップ オプションを有効にする] をダブルクリックします。[コントロール パネル セットアップ : 詳細なスタートアップ オプションを有効にする] ダイアログ ボックスが表示されます。
  5. [有効] を選択し、[互換性のある TPM が装備されていない BitLocker を許可する] チェック ボックスをオンにして、[OK] をクリックします。これで、TPM の代わりにスタートアップ キーを使用できるように、ポリシー設定が変更されました。
  6. グループ ポリシー オブジェクト エディタを終了します。
  7. 更新されたグループ ポリシーをすぐに適用するには、[スタート] ボタンをクリックし、[検索の開始] ボックスに「gpupdate.exe /force」と入力して、Enter キーを押します。処理が完了するまで待機します。

BitLocker を有効にするには、ボリュームを正しく構成する必要があります。BitLocker がブート セクタ、ブート マネージャ、および Windows ローダー プログラム (これらのコンポーネントは、上記で説明した、システムの整合性をチェックする機能によって保護されます) を読み取るには、アクティブ パーティションが暗号化されていない状態になっている必要があります。他の Windows コンポーネントも一時的にアクティブ パーティションを使用する場合があるため、最低 1.5 GB 以上のアクティブ パーティションを用意することをお勧めします。また、NTFS アクセス許可を構成して、ユーザーが誤ってこのボリュームにデータを書き込まないようにすることもお勧めします。
Windows 自体は、暗号化が可能な、別の大きいボリュームにインストールされます。新しいシステムに Windows をインストールする場合は、「Windows BitLocker ドライブ暗号化のステップ バイ ステップ ガイド」の指示に従って、手動でボリュームを構成できます。
BitLocker ドライブ準備ツールは、BitLocker 用にシステムを構成する際に役立ちます。このツールを使用すると、ドライブの構成を簡単に実行できます。このツールは、Windows Vista Ultimate Extra として入手するか、Windows Vista Enterprise から利用できます。BitLocker ドライブ準備ツールの詳細については、support.microsoft.com/kb/930063 を参照してください。
BitLocker ドライブ準備ツールは、自動的にボリュームを圧縮 (ボリュームが 1 つのみである場合) し、2 つ目のパーティションを作成します。次に、そのパーティションをアクティブにし、必要な構成の変更をすべて行って、起動ファイルを適切な場所に移動します。
ボリュームの構成が完了したら、簡単に BitLocker を有効にすることができます。これを行うには、コントロール パネルの [セキュリティ] にある、[BitLocker ドライブ暗号化] アイコンをクリックします。UAC の確認に同意すると、図 2 のような画面が表示されます。
図 2 BitLocker の有効化
図 2 BitLocker の有効化
この後の動作は、コンピュータの TPM チップの状態によって異なります。TPM チップが初期化されていない場合、TPM 初期化ウィザードが実行されます。ウィザードの指示に従って、TPM を初期化します。この手順には、コンピュータの再起動も含まれます。
TPM が初期化されたら、[回復パスワードの保存] ページ (図 3 を参照) が表示されます。TPM で障害が発生した場合や、他の問題が発生した場合に、データを回復できるようにするには、回復パスワードが必要です。このページでは、回復パスワードを USB フラッシュ ドライブ、ローカル ディスク、またはネットワーク ディスクに保存したり、保管用に印刷したりすることができます。これらのうち、少なくとも 1 つのオプションを選択する必要があります。また、複数のコピーを保存することもできます。回復パスワードを保存したら、有効になった [次へ] ボタンをクリックします。
図 3 回復パスワードの保存
図 3 回復パスワードの保存
[選択されたディスク ボリュームの暗号化] ページが表示されます。このページでは、暗号化を開始する前にシステム チェックを実行するかどうかを選択できます。システム チェックでは、コンピュータの再起動が要求されますが、コンピュータの再起動は、TPM、BIOS、および USB ポートが BitLocker と適切に連携するかどうかを確認するのに最適な方法です。再起動後に問題が検出された場合、エラー メッセージが表示されます。検出されなかった場合は、[暗号化を実行中です] ステータス バーが表示されます。
これで完了です。暗号化はバックグラウンドで完了するため、コンピュータの使用を続行することができます。最初の暗号化が完了したら、完了を通知するメッセージが表示されます。また、ディスク ボリュームの暗号化の進捗状況を確認することもできます。これを行うには、画面の下部にあるツールバーの [BitLocker ドライブ暗号化] アイコンの上にカーソルを合わせます。詳細については、上記で紹介したステップ バイ ステップ ガイドを参照してください。
コンピュータの起動時に、確認のメッセージが表示されたり、その他の明示的な割り込みが発生したりしなかったことに驚いたユーザーもいるかもしれません。BitLocker の既定の構成では、システムの整合性チェックを行ってからボリュームのロックを解除する操作を、すべて TPM が担当するため、処理はユーザーから見て自動的かつ透過的に実行されます。
起動時に、PIN の入力を要求するか、USB フラッシュ ドライブに保存されたキーを要求するように、BitLocker を構成できます。これにより、セキュリティが強化されるため、PIN を入力する手間よりもセキュリティの強化を重視する場合は、この構成を行うことをお勧めします。個人的には、常にこの構成を行うことをお勧めします (つまり、デスクトップ パソコンでは PIN を要求し、ノート パソコンでは USB キーを要求するとよいでしょう)。

BitLocker の回復
暗号化を実行する場合、特にビジネス環境や企業環境では、通常のアクセス方法やキーを使用できない場合でも、承認されたユーザーがデータを取得できる方法を用意しておく必要があります。BitLocker では、この方法を回復と呼んでいます。
初期起動コンポーネントが突然変更された場合、USB スタートアップ キーを紛失した場合、またはユーザーが PIN を忘れた場合、BitLocker は通常の起動処理を完了できません。これは、ボリュームが BitLocker によってロックされたままになり、Windows を起動することができなくなるためです。この場合、ブート マネージャで実行される BitLocker のコードによって、テキスト画面が表示されます。USB フラッシュ ドライブに回復パスワード (回復キーと呼ぶこともあります) を保存した場合、図 4 のような画面が表示されます。
図 4 回復キーの要求
図 4 回復キーの要求
BitLocker が USB フラッシュ ドライブを読み取るには、起動時に USB フラッシュ ドライブが接続されている必要があります。このため、回復パスワードが保存された USB フラッシュ ドライブがある場合は、挿入してから Esc キーを押します。回復パスワードが保存された USB フラッシュ ドライブがない場合は、Enter キーを押して、図 5 のような画面を表示します。この画面は、回復キーを USB ドライブに保存しなかった場合にも表示されます。
図 5 BitLocker パスワードの入力
図 5 BitLocker パスワードの入力
このページでは、ドライブのロックを解除できる 48 桁の数字のパスワードが要求されます。回復パスワードの印刷を選択した場合、この数字は紙に出力されます。また、回復パスワードをフォルダに保存した場合、この数字はファイルに保存されています。
企業で回復パスワードを管理するための最も簡単な方法は、Active Directory® に回復パスワードが自動的に保存されるようにすることです。この方法の詳細については、go.microsoft.com/fwlink/?LinkId=87067 を参照してください。
続編の記事では、BitLocker の管理性について詳しく説明しますが、今回の概要の段階で知っておく必要があることは、BitLocker に完全な WMI プロバイダが含まれていることです。この WMI プロバイダを使用すると、WMI に対応した Web ベース エンタープライズ管理 (WBEM) システムから BitLocker (および TPM) を管理できるようになります。つまり、VBScript や Windows PowerShell™ など、WMI オブジェクトにアクセスできるスクリプト言語を使用して、BitLocker のスクリプトを作成することもできます。
BitLocker には、WMI プロバイダを使用して、ローカルまたはリモート コンピュータ上で BitLocker を管理できる、manage-bde.wsf というコマンド ライン ツールも含まれています。このコマンド ラインの詳細情報を表示するには、昇格したコマンド プロンプトを起動し、「manage-bde.wsf /?」と入力します。

安全な廃棄
どんなコンピュータでも、最終的には廃棄する必要があります。通常、企業は、多額の資金と作業時間を費やして、ディスク ドライブのデータがすべて削除されたことを確認してから、ディスク ドライブを処分します。ディスク ドライブから機密データを削除する処理は、時間やコストがかかり、ハードウェアが完全に使用できなくなってしまうものばかりです。BitLocker を使用すると、コスト効率を改善することができます。
BitLocker を使用すると、最初から、データがリスクの高い状態で保存されないことが保証されるため、後からデータの削除について考える必要がなくなります。ディスクに書き込まれるすべてのデータは暗号化されるため、暗号化キーのコピーをすべて破棄すれば、完全にデータにアクセスできない状態にすることができます。ハード ディスク自体への影響はまったくないため、ハード ディスクを再利用することもできます。
BitLocker によって保護されたボリュームは、さまざまな方法で廃棄できます。ボリューム メタデータからキーのコピーをすべて削除し、集中管理された安全な場所に、それらのコピーを保管することもできます。これにより、システムを安全に輸送したり、長期間使用しない場合の一時的な廃棄処理を行うことができます。また、承認されたユーザーのみがデータにアクセスでき、装置の次の所有者など、承認されていないユーザーはデータにアクセスできないようにすることができます。
また、ボリューム メタデータだけでなく、アーカイブ (Active Directory など) からもキーのコピーをすべて削除することもできます (たとえば、新しいキーを作成して、そのキーを保存しないことによって実現できます)。この場合、解読キーが存在しなくなるため、どのユーザーもデータを回復させたり取得したりすることができなくなります。
いずれの場合も、ボリューム メタデータに含まれているキーは、ほぼ瞬時に削除または破棄できます。また、管理者は、複数のシステムにまたがってこの操作を実行できます。このため、最小限の時間と作業で、非常に高いレベルの完全な保護を実現できます。Windows Vista では、フォーマット ユーティリティが更新されました。フォーマット コマンドを使用すると、ボリューム メタデータを削除し、そのボリュームのセクタを上書きして BitLocker のキーを安全に削除できるようになります。

最後に
BitLocker は、特定の脅威からコンピュータを保護するために設計された強力なツールであり、その効果も優れています。ただし、BitLocker によって、すべての脅威からコンピュータを保護できるわけではありません。常に、強力なパスワードなど、適切な防御方法と管理方法を使用することがきわめて重要です。
BitLocker は、オフライン攻撃を対象とした防御方法であり、Windows の実行中は、ボリュームのロックが解除されます。つまり、実行中のシステムを BitLocker によって保護することはできません。EFS や RMS などのテクノロジを使用すると、OS の実行中も情報が保護されるため、BitLocker の機能を補完できます。
BitLocker の詳細については、マイクロソフト Web サイト (technet.microsoft.com/windowsvista/aa905065.aspx) で提供されている記事を参照してください。TPM の仕様と TCG については、TCG Web サイト (go.microsoft.com/fwlink/?LinkId=72757) で提供される、TPM の仕様に関する情報を参照してください。

Byron Hynesは、マイクロソフトの Windows Server ユーザー アシスタンス グループに所属しています。以前は、コンサルタントやトレーナーを務めていました。彼の連絡先は bhynes@microsoft.com (英語のみ) です。


 セキュリティ: Windows ファイアウォールの調査
セキュリティ Steve Riley

Windows ファイアウォールの調査
概要:
  • 受信の保護と送信の保護
  • Windows Filtering Platform
  • Advanced Security インターフェイス
  • ネットワーク プロファイル

古いコンピューティングの時代には、個々のコンピュータにファイアウォールをインストールしようと考える人はいませんでした。そもそも必要とする人がいたでしょうか。インターネットについて聞いたことのある人はほとんどなく、TCP/IP はどこにも見えず、LAN プロトコルが建物やキャンパスから外に出ることはありませんでした。重要なデータは
メインフレームやファイル サーバーに保存されていました。人々がデスクトップ コンピュータに保持していた情報がミッション クリティカルであることはまれであり、コンピュータ自体の重さで一定量の適正な物理的セキュリティをまかなっていました。インターネットへの接続が使用可能な場合は、たいてい途中にプロトコル トランスレータがあったり、おそらく多くのルールと例外を使用して構成されたパケット フィルタリング ルーター (つまり "ファイアウォール") がエッジにあったりしました。
最近のコンピューティング環境は、そのような古い時代とは大きく異なります。すべてのものがインターネットに接続され (TCP/IP と通信し)、ポータブル デバイスが標準になっています。事業主は従業員にノート パソコンを与えることが多くなりました。それは従業員を気にかけているからではなく、従業員から多くのものを得ようとしているからです。事業主は、5 分の空き時間と Wi-Fi 接続があればいつでも仕事をするよう従業員に期待しています。ノート パソコンはデスクトップ パソコンよりもコストがかかる場合がありますが、その投資は確実に生産性で回収されます。ご存知のように、あなたやあなたの敵対者にとってノート パソコンを非常に魅力のあるものにしているのは、そのポータビリティです。
考えてみてください。ノート パソコンの電源を入れてなんらかのネットワークに接続している合計時間のうち、社内ネットワークに接続している時間は何パーセントでしょうか。筆者と同様なら、おそらく最大 20% でしょう。これは、ノート パソコンが安全な Microsoft 社内ネットワークの境界内にあり、ネットワーク周辺の防御によって外部の攻撃から保護されているのは合計時間の 20% だけであることを意味します。ノート パソコンがあらゆる実際的な目的でインターネットに直接接続されている 80% の時間についてはどうでしょうか (そして筆者は、コンピュータ セキュリティ会議におけるホテルの LAN など、世界中で最も危険なネットワークに接続することが頻繁にあります)。また、社内ネットワークに接続しているときに、その環境内の他のコンピュータから受ける脅威についてはどうでしょうか。
セキュリティ制御は脅威の後を追って (かなり遅れることもあります) 進化します。ウイルスは人々のフロッピー ディスクのやり取りを原因とするクライアントの問題であったため、最初、ウイルス対策プログラムはクライアントに出現しました。続いて、電子メールが普及し、マルウェアが電子メール配布に依存するワームに成長すると、マルウェア対策プログラムが進化して電子メール ゲートウェイに出現しました。Web が出現すると、マルウェアはトロイの木馬に成長し、マルウェア対策がインターネット アクセス プロキシ サーバーに登場しました。これは、だれも文句を付けることのない、よく理解されている進化の道筋です。
ここで、ファイアウォールに同じロジックを適用してみましょう。ネットワークのエッジにあるファイアウォールは過去の脅威に対しては十分な保護でしたが、脅威が異なり、より巧妙になり、より普及すると十分とは言えなくなります。言うまでもなく、デバイスと作業スタイルは過去とは大幅に異なります。多くのコンピュータには機密情報がローカルに保存され、社内ネットワークから離れた場所 (つまり、エッジの外) で長時間使用されます。このため、ファイアウォールは個々のクライアント保護メカニズムに進化する必要があります。間違えないでください。クライアント ファイアウォールはもはやオプションではありません。コンピュータを社内ネットワークおよびインターネットから保護するには、クライアント ファイアウォールが必須です。

クライアント ファイアウォールとセキュリティ シアター
多くの人々は、Windows® XP の初期リリースにクライアント ファイアウォールが含まれていることを認識していませんでした。ファイアウォールは既定でオフになっており、非常に多くのマウス クリックを行わないと見ることができなかったため、これは驚くことではありません。ファイアウォールは、その目的の説明や使用方法のガイダンスなしに、どちらかと言うとひそかに出現しました。しかし、ファイアウォールは機能していました。ファイアウォールを有効にしていれば、Nimda、Slammer、Blaster、Sasser、Zotob など、ネットワーク ポートで要求されていないトラフィックによる侵害を試みるあらゆる攻撃からコンピュータが保護されました。クライアント保護の重要性を認識して、Windows XP Service Pack 2 (SP2) はファイアウォールを既定で有効にし、2 つのプロファイル (インターネット用と社内ネットワーク用) を作成し、グループ ポリシーの有効化を可能にしました。
あいにく、アプリケーション上の考慮事項とセキュリティ シアター (実体のない見た目だけのセキュリティ対策) という 2 つの障壁により、Windows XP SP2 ファイアウォールの採用が遅れました。多くの人々は、ファイアウォールによってアプリケーションが正しく機能しなくなることを心配しました。しかし、ファイアウォールの設計上、これは非常にまれなケースです。ファイアウォールはすべての送信トラフィックがコンピュータから出て行くことを許可しますが、先に行われた送信要求に対する応答以外の受信トラフィックはすべてブロックされました。この設計がクライアント上のアプリケーションを中断させるのは、アプリケーションがリスニング ソケットを作成し、受信要求の受信を予期する場合だけでした。Windows XP ファイアウォールでは、プログラムまたはポートの例外の単純な構成が可能でした (しかし、残念ながらグループ ポリシーを通じた構成ではありませんでした)。
より大きな妨げは、他のクライアント ファイアウォールの製造元によって実行されるセキュリティ シアターでした。一部の人々は、Windows XP ファイアウォールの設計 (つまり、すべての送信トラフィックの自由な送信を許可すること) は、クライアント ファイアウォールにとって不十分な機能であると信じていました。十分なクライアント ファイアウォールでは、ユーザーが明示的に権限を付与したのでない限り、受信と送信のすべてのトラフィックをブロックする必要があるというのがその主張でした。
ここで少し考えてみましょう。2 つのシナリオが浮かび上がります。
  • ローカル管理者として実行し、マルウェアに感染した場合、マルウェアは単純にファイアウォールを無効にします。コンピュータは乗っ取られてしまいます。
  • ローカル管理者として実行しているのではない場合にマルウェアに感染すると、マルウェアが原因でサードパーティ ファイアウォールはダイアログを表示します。このダイアログには、ポートと IP アドレスに関する外国語と、「これを許可しますか?」という非常に深刻な質問が表示されます。もちろん、唯一の回答は「許可するよ、愚かなコンピュータめ。いちいち聞かないでくれ!」です。そして、ダイアログが消えた後、セキュリティも消えることになります。または、より一般的なケースとして、既に承認したプログラムの既存のセッションがマルウェアに乗っ取られ、ダイアログすら表示されないことがあります。この場合もコンピュータは乗っ取られます。
セキュリティについて理解する必要のある重要な原則があります。保護は、阻止しようとしているものではなく、保護する資産に属するということです。正しいアプローチは、簡潔だが効果的な Windows ファイアウォールを組織のすべてのコンピュータで実行して、世界中の他のすべてのコンピュータから各コンピュータを保護することです。既に危険にさらされているコンピュータからの送信接続をブロックしようとする場合、コンピュータが求められていることを本当に行っているかどうかはどうすればわかるでしょうか。答えは次のとおりです。できません。送信保護はセキュリティ シアターです。つまり、実際にはセキュリティを改善していないのにセキュリティを改善しているという印象を与えるだけのからくりです。このため、送信保護は Windows XP ファイアウォールに存在せず、Windows Vista™ ファイアウォールにも存在しません (Windows Vista での送信制御については後でもう少し詳しく説明します)。

Windows Vista の新機能
新しいネットワーク スタックの一部である Windows Filtering Platform は、Windows Vista ファイアウォールの基盤です。Windows XP と同様に、Windows Vista は既定で受信トラフィックをブロックします。コンピュータが使用しているプロファイルに応じて、ネットワーク サービスの既定の例外がある場合があります (プロファイルについては後で説明します)。必要に応じて、受信接続を許可するルールを作成できます。また、Windows XP と同様に、Windows Vista も対話型プロセスからのすべての送信トラフィックを既定で許可しますが、サービス制限に参加しているサービスからの送信トラフィックは制限します。この場合も、追加の送信接続をブロックするルールを作成できます。
Windows XP と Windows Vista の大きな違いは、新しい Advanced Security (セキュリティが強化された) インターフェイスと、構成とルールの完全なグループ ポリシー サポートです (図 1 を参照)。古いコントロール パネル UI は現在も存在し、新しい UI になったログとインターネット制御メッセージ プロトコル (ICMP) の設定を除いてほとんど変更されていません。この新しい UI である Advanced Security MMC スナップインは、新しい機能と柔軟性をすべて備えています。netsh コマンドの新しいコンテキスト netsh advfirewall を使用して、ルールの追加と削除のスクリプト化、グローバルおよびプロファイル単位のポリシーの設定と表示、およびファイアウォールのアクティブ状態の表示を行うことができます。また、開発者は、FirewallAPI.dll と Netfw.h を使用してファイアウォールのすべての設定をプログラムで制御できます。
図 1 セキュリティが強化された Windows ファイアウォール
図 1 セキュリティが強化された Windows ファイアウォール
Advanced Security MMC はウィザード形式です。ルールを作成する場合は、プログラム、ポート、定義済み、カスタムの 4 種類から 1 つ選択できます。詳細については、図 2 を参照してください。
Figure 2 4 種類のルール (Close Figure 2)

種類 | 目的
プログラム | 特定のプログラムのトラフィックを許可またはブロックするために使用されます。
ポート | 特定の TCP または UDP ポートでトラフィックを許可またはブロックするために使用されます。
定義済み | 既存のルール グループを使用して、ネットワーク上の Windows 機能 (ファイルとプリンタの共有やリモート アシスタンスなど) を有効にします。
カスタム | すべてのノブ、ダイヤル、ボタン、およびスイッチを公開して、特定のルールを必要に応じて構成できるようにします。
ルールを作成するときに参照できる要素は多数あり、そのすべてがローカル ルールおよびグループ ポリシーを通じて適用されるルールで使用可能です。これらの要素には、Active Directory® ユーザーとコンピュータのアカウントおよびグループ、送信元と送信先の IP アドレス、送信元と送信先の TCP ポートと UDP ポート、IP プロトコル番号、プログラムとサービス、インターフェイスの種類 (有線、ワイヤレス、またはリモート アクセス)、および ICMP の種類とコードが含まれます。
構成した後で、ファイアウォールは次の順序でルールを処理します。
サービスの制限 Windows Vista のサービスの一部は、Blaster スタイル攻撃の可能性を制限するために自身を制限します。制限の 1 つとして、サービスに必要なポートの一覧があります。ファイアウォールはこれを実施し、サービスが他のポートを使用 (または使用するよう指示) することを防ぎます。
接続セキュリティ ルール Advanced Security MMC には、IPsec とファイアウォールが組み込まれています。IPsec ポリシーを含むルールが次に処理されます。
認証済みバイパス 指定された認証済みコンピュータが他のルールをバイパスできるようにします。
ブロック ルール 指定された受信または送信トラフィックを明示的にブロックします。
許可ルール 指定された受信または送信トラフィックを明示的に許可します。
ファイアウォール ルールはレジストリに格納されますが、その正確な場所については説明しません。まあいいでしょう。これらは次の場所に見つかります。
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
レジストリのルールは直接編集しないでください。もし編集したら、あなたを探して eBay のオークションであなたのペットを売ってしまいますよ。おそらく編集はしないでしょうが、ルールを編集する唯一の方法は Advanced Security MMC を使用することです。

ネットワーク プロファイル
Windows Vista は、ドメイン、プライベート、パブリックという 3 つのネットワーク プロファイルを定義します。コンピュータがドメインに参加し、ドメインに正常にログインしている場合、コンピュータはドメイン プロファイルを自動的に適用します。この選択を自分で行うことはできません。コンピュータがドメインのない内部ネットワーク (自宅のネットワークや小規模なオフィス ネットワーク) に接続されている場合、ユーザー (または管理者) はプライベート プロファイルを適用する必要があります。最後に、コンピュータがインターネットに直接接続されている場合は、パブリック プロファイルを適用する必要があります。
Windows Vista は、この選択をどのようにして決定するのでしょうか。ネットワーク変更が行われるたび (たとえば、新しい IP アドレスを受け取ったり、新しい既定のゲートウェイを検出したり、新しいインターフェイスを取得したりするたび) に、Network Location Awareness (NLA) と呼ばれるサービスによって変更が検出されます。このサービスは、ネットワーク プロファイルを作成し、それに GUID を割り当てます。このプロファイルには、既存のインターフェイス、ドメイン コントローラでのコンピュータの認証の有無、ゲートウェイの MAC アドレスなどの情報が含まれます。NLA は、ファイアウォールに通知し、ファイアウォールは対応するポリシーを適用します (3 つのプロファイルごとにポリシーが定義されています)。
これがそれまでコンピュータに存在しなかった新しいインターフェイスであり、NLA がドメイン プロファイルを選択しなかった場合は、接続先のネットワークの種類を指定するよう求めるダイアログ ボックスが表示されます。不思議なことに、[Home] (ホーム)、[Work] (業務)、[Public] (パブリック) の 3 つの選択肢があります。[Work] (業務) はドメイン プロファイルを意味すると思われるかもしれませんが、実際にはそうではありません。思い出してください。コンピュータがドメインにログオンしたときに NLA がドメイン プロファイルを自動的に選択するため、ユーザーがドメイン プロファイルを見ることはありません。実際には、[Home] (ホーム) と [Work] (業務) はプライベート プロファイルに対応します。これらは機能的に同等で、アイコンだけが異なります (注 : プライベート プロファイルを選択するには、ローカル管理者であるか、ローカル管理者に昇格できる必要があります)。予想されるように、[Public] (パブリック) はパブリック プロファイルに対応します。
Windows Vista では、ネットワーク プロファイルはコンピュータのすべてのインターフェイスに適用されます。次に、NLA ディシジョン ツリーを要約します。
  1. 接続されているすべてのネットワークを検証します。
  2. ネットワークに接続しているインターフェイスに、パブリックとして分類されるものがありますか。答えが「はい」の場合は、コンピュータのプロファイルをパブリックに設定して終了します。
  3. ネットワークに接続しているインターフェイスに、プライベートとして分類されるものがありますか。答えが「はい」の場合は、コンピュータのプロファイルをプライベートに設定して終了します。
  4. すべてのインターフェイスがドメイン コントローラを参照し、コンピュータが正常にログオンしましたか。答えが「はい」の場合は、コンピュータのプロファイルをドメインに設定して終了します。
  5. それ以外の場合は、コンピュータのプロファイルをパブリックに設定します。
目標は、できるだけ制限的なプロファイルを選択することです。ただし、明白な副作用が 2 つあります。最初に、コンピュータのイーサネット ポートが社内ネットワークに接続され、そのワイヤレス NIC が階下のスターバックスに接続されている場合、コンピュータはドメイン プロファイルではなくパブリック プロファイルを選択します。次に、コンピュータがインターネットに (パブリック プロファイルで) 直接接続されているか、家庭内 LAN に (プライベート プロファイルで) 接続されている場合に、社内ネットワークへの VPN 接続を行うと、コンピュータはパブリックまたはプライベート プロファイルのままになります。
これは何を意味しているのでしょうか。ファイアウォールのドメイン プロファイルに対するポリシーには、リモート アシスタンス、リモート管理、ファイルとプリンタの共有などに対するルールが含まれます。クライアントにリモートでアクセスするためにこれらのルールに依存した場合、クライアントが他のプロファイルを選択した場合はアクセスできなくなります。しかし、失望しないでください。ファイアウォール ルールを作成して、必要な受信接続を許可してから、それらを VPN 接続にのみ適用することができます。これで、クライアントがドメイン プロファイルではない場合でも、VPN 上でクライアントを管理できます。

送信接続を制御する
前に筆者は、クライアント ファイアウォールでの送信保護の典型的な形式はセキュリティ シアターであると述べました。しかし、送信制御の 1 つの形式は非常に有用です。それは、許可しないことがわかっている特定の種類のトラフィックを管理的に制御することです。Windows Vista ファイアウォールは、サービス制限に対して既にこの処理を行っています。ファイアウォールでは、サービスに必要なポートでのみ通信を許可し、サービスが試行するその他すべての通信をブロックします。特定のトラフィックを許可またはブロックして組織のセキュリティ ポリシーを満たす追加ルールを作成することで、これを行うことができます (図 3 を参照)。
図 3 新しい受信ルール ウィザード
図 3 新しい受信ルール ウィザード
たとえば、ユーザーが特定のインスタント メッセージング クライアントを実行することを禁止するとします。そのクライアントについてログイン サーバーへの接続をブロックするルールを (もちろんグループ ポリシーで) 作成できます。
ただし、このアプローチには実際的な制限があります。たとえば、Windows Live™ Messenger (以前は MSN® Messenger という名前でした) には、ログインに使用できるさまざまなサーバーがあり、そのリストは常に変化しています。それに加えて、既定のポート 1863/tcp がブロックされている場合は、ポート 80/tcp を使用します。Windows Live Messenger がログイン サーバーに接続することをブロックするルールは非常に複雑で、常に変化します。管理的な送信制御が有用であることを示すために言及しましたが、ユーザーにインストールと実行を許可するソフトウェアを厳密に管理する必要がある場合に、これはソフトウェアの制限のポリシーの代わりにはなりません。

コンピュータを保護する
境界はなくなっています。すべてのコンピュータは、自身の保護について責任を持つことが必要になりました。クライアントからエッジに移行したマルウェア対策と同様に、ファイアウォールもエッジからクライアントに移行する必要があります。既にインストールしてあるファイアウォールを有効にすることで、すぐにアクションを行うことができます。
システムで Windows XP を実行しているか、既に Windows Vista に移行しているかにかかわらず、Windows ファイアウォールはすべてのクライアントで使用可能であり、モバイルを使用する従業員がオフィスから数千マイル離れている場合でも、組織内のセキュリティを高めるために必要な保護が提供されます。

詳細を知りたい方のために
  • Windows Vista TechCenter: セキュリティが強化された Windows ファイアウォールの概要
  • Windows Vista TechCenter: セキュリティが強化された Windows ファイアウォール - 診断とトラブルシューティング
  • Steve Riley の TechEd ヨーロッパ プレゼンテーション : Windows Vista ファイアウォールと IPSec の拡張
  • The Cable Guy: Windows Vista と Windows Server "Longhorn" の新しい Windows ファイアウォール
  • Windows Vista ファイアウォール仮想ラボ

Steve Rileyは、Microsoft Trustworthy Computing Group の Senior Security Strategist であり、TechNet Magazine の編集にも携わっています。また、世界中を飛び回って各種カンファレンスでの講演や、お客様のセキュリティを確保、維持するための手助けを行っています。Steve の最新の著書は、『Protect Your Windows Network』(Addison-Wesley、2005 年刊) です。連絡先は、steve.riley@microsoft.com (英語のみ) です。


 セキュリティ: セキュリティを強化する Windows Vista の新しい ACL
セキュリティ Jesper Johansson

セキュリティを強化する Windows Vista の新しい ACL
概要:
  • ACL の新機能
  • 管理者での制御の強化
  • Trusted Installer のアクセス許可
  • ユーザーとグループの変更

Windows Vista では、アクセス制御リスト (ACL) の基本構造が大きく変更されたわけではありません。しかし、認識しておくべき、小さいながらも重要な変更が数多く行われています。こうした変更の中には、
ACL が Windows® XP でいくつかの問題点の原因の一部であったために必要な変更もありました。まず、Windows XP ユーザーの大部分は管理者として実行されます。つまり、このようなユーザーはビルトイン Administrators グループに所属するアカウントを使用します。ホーム ユーザーの場合、セットアップ中に追加されるすべてのアカウントが管理者となるため、これは実際上必然的な動作です。したがって、このようなユーザーが実行するすべてのプログラムが管理者の特権で実行され、オペレーティング システムに無制限にアクセスできます。もちろん、実行されるプログラムが不正なプログラムであれば、これは大きな問題になります。
対処すべき 2 つ目の問題点は、以前のバージョンの Windows の既定の ACL で、これが Everyone や Power Users のようなグループの ACL エントリ (ACE) に含まれていることに多くのユーザーが頭を悩ませてきました。たとえば、Windows XP のブート ボリューム (通常は C:\) のルートの既定の ACL では、Everyone グループに読み取りアクセス許可が与えられ、Users グループのメンバにフォルダを作成する権限が許可されています。最後の問題点は、Windows XP では、ACL を使用してできることに制限があったことです。たとえば、Windows XP にはオブジェクトの現在の所有者にアクセス許可を割り当てる方法がありませんでした。所有者のアクセス許可を割り当てることはできましたが、所有者が変わっても、割り当てられていたアクセス許可が移行されませんでした。同様に、オブジェクトにどのようなアクセス許可を割り当てても、所有者はオブジェクトに対して常に暗黙の権利を所持していました。
マイクロソフトは、Windows Vista™ で、このような問題の多くを解決し、ユーザー アカウント制御 (UAC) などの機能のサポートを有効にするためのプロジェクトを立ち上げました。今月の記事では、アクセス制御に関連する、Windows Vista での主な変更点に重点を置いて説明します。来月もこのテーマを引き続き取り上げ、アクセス制御の管理に使用するツールを見ていく予定です。

ユーザーとグループの追加点と変更点
Windows Vista ではユーザーとグループがいくつか新しく追加され、Windows XP で使用されていた古いユーザーとグループがいくつか削除されました。また、ユーザーとグループの中には作用する方法が変更されたものもいくつかあります。各変更点は、アクセス制御を管理する方法に何らかの影響を与えます。
Administrator は既定で無効になる ビルトイン Administrator アカウント (相対識別子 (RID) 500 のアカウント) は、大半の場合に既定で無効になります。Administrator は、万策尽きた場合にコンピュータの救済に使用する緊急時のアカウントにすることが目的でした。しかし、結局、標準の管理アカウントとして使用されることが極めて多くなってしまい、いくつかのセキュリティの原則に違反することになりました。最も違反が顕著な原則は説明責任であり、システムに変更を加えたユーザーを追跡することができなくなります。そのため、このアカウントを部分的に廃止しました。マイクロソフトは、最終的にこのアカウントを全面的に廃止することを考えていますが、現状では既定で無効になります。Administrators グループに所属するローカル アカウントが他になければ、回復コンソールやセーフ モードでは RID 500 に依然として使い道がありますが、それ以外では使用できず、また使用すべきではありません。
ビルトイン Administrator アカウントと、Administrators グループに属する他のアカウントには違いがあることに注意してください。通常、RID 500 のアカウントを指す英字の "Administrator" と "管理者" は区別されます。管理者とは、ビルトイン Administrators グループに所属する他のすべてのアカウントです。グループ名も同様に英字で表記します。
Windows XP のビルトイン Administrator アカウントは、他の管理者にはない特殊な権利や特権を数多く所持しています。Windows Vista ではこうした権利や特権の多くが削除されましたが、注目すべき例外が 2 つあります。まず、他にローカル管理者がいなければ、Administrator アカウントが無効になっていても、回復コンソールではこのアカウントを使用できます。次に、Administrator は UAC が適用されないため、常に完全な管理トークンを持ちます。同じことが Domain Administrator (ドメインの RID 500) にも当てはまります。
Power Users アクセス許可の削除 従来の Power Users グループは、事実上廃止されました。グループ自体は存在していますが、このグループに許可されていたほとんどのアクセス許可は削除されました。秘密でもなんでもありませんでしたが、Power Users グループに所属するユーザーは事実上管理者と同じで、単に自身を管理者にしていないだけでした。私は自分自身に管理特権を許可することによって、Windows XP Service Pack 2 (SP2) を実行し、すべての修正プログラムが適用されたコンピュータを 45 分以内に完全に制御できるようになりました。この時間には、予備調査の時間、C++ で小さなプログラムを作成する時間、および制御権を得るためにログオフしてからログオンするまでの時間を含みます。これらすべてを行えたのは、私が Power Users のメンバであったためです。
多くの組織では Power Users グループに十分検討されたアクセス許可が与えられており、このグループに所属するユーザーを信頼しているため、Windows Vista でこのグループを削除してしまうことは実現できませんでした。ただし、マイクロソフトは今後のバーションの Windows で Power Users を完全に削除することを考えています。そのため、Power Users からの移行計画に着手することをお勧めします。
Trusted Installer ファイル システムのいたるところで Trusted Installer にアクセス許可が割り当てられているように見えますが、Trusted Installer は実際にはユーザーではなく、サービスです。サービスのセキュリティ強化機能では、各サービスを通常のセキュリティ プリンシパルとして扱うことができ、他のユーザーとまったく同様にアクセス許可を割り当てることができます。この機能の概要については、TechNet Magazine の 2007 年 1 月号の記事を参照してください。書籍『Windows Vista Security』 (Grimes と Johansson の共著、Wiley Press、2007 年刊) では、サービスのセキュリティ強化機能について詳しく調べ、ファイアウォールや IPsec などの機能からどのように利用されるかを説明しています。
サービスの SID は、以前のように NT AUTHORITY やドメインなどの機関からは発行されません。TrustedInstaller 仮想アカウントの完全な名前は NT SERVICE\TrustedInstaller で、SID は次のようになります。
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
図 1 に示すように、sc showsid コマンドを実行することで、任意のサービスの SID を表示できます。SID はサービスが存在しなくても表示されます。
図 1 sc showsid ではサービスが存在しない場合でも、任意のサービスの SID が表示される
図 1 sc showsid ではサービスが存在しない場合でも、任意のサービスの SID が表示される
この SID は S-1-5-80 から始まります。ここでは最初の副機関が 80 です。これは SECURITY_SERVICE_ID_BASE_RID を表し、この SID が NT SERVICE 副機関からサービスに発行されたことがわかります。これはすべてのサービスに当てはまります。残りの副機関と RID はサービス名自体に基づきます。このため、開発者は最初にコンピュータが変わっても変化しないサービス名を決定し、そのサービスを実際にビルドしてインストールする必要なしに、自身のサービスにアクセス許可を割り当てることができます。
サービス マネージャに TrustedInstaller サービスが見つからない場合、サービスの表示名 "Windows モジュール インストーラ" で探してください。
ヘルプとサポートのアカウントの削除 Windows Vista をクリーン インストールすると、Support_xxxxxx アカウントと HelpAssistant アカウントの両方が削除されます。ただし、以前のバージョンの Windows からアップグレードするとどちらも保持されます。Support_xxxxxx アカウントは、サポート センターからのスクリプトの実行に使用されていました。独自のヘルプ コンテンツを提供する OEM の中には、独自のサポート アカウントを用意していた OEM がありました。OEM アカウントを使って何が行われていたかは定かではありませんが、おそらく今後 OEM は単純にこうしたアカウントの作成を中止することになります。厳密に言えば、こうしたアカウントの作成は必要なくなります。実際セキュリティの観点からは、ユーザーがヘルプ センターから別のユーザーとしてスクリプトを実行できるようにすることはよい考えとはいえませんでした。そのため、こうしたアカウントはなくしてしまうのが最適です。Windows Vista では、こうした作業の実現に新しいメカニズムを導入しました。
HelpAssistant アカウントはリモート アシスタンスで使用されていました。ヘルプ センターと同様に、リモート アシスタンス機能は HelpAssistant アカウントの必要性をなくすように設計が見直され、その結果このアカウントが削除されました。
新しいネットワークの場所の SID Windows NT® ベースのオペレーティング システムには、常に、NETWORK や INTERACTIVE (ユーザーがネットワークからログオンしたこと、および対話的にログオンしたことをそれぞれ表します) など、ネットワークの場所を基にした SID があります。また、ターミナル サービス経由でログオンするユーザーに割り当てられる REMOTE INTERACTIVE LOGON SID もあります (ターミナル サービス ユーザーのトークンには、実際には、REMOTE INTERACTIVE LOGON と INTERACTIVE LOGON の両方が含まれます)。Windows Vista では、さらにDIALUP と INTERNET の 2 つが追加されます。使用可能なネットワークが電話回線だけしかないユーザーがオンラインになることがほとんどなくなっている現在、ダイヤルアップ経由のログオンを表すアカウントを追加する正確な論理的根拠は乏しいですが、現状では含まれています。INTERNET は、明らかにユーザーがローカル エリア ネットワーク外部からログオンしていることを示します。ただし、NETWORK もユーザーがネットワークからログオンしていることを表し、このネットワークにはインターネットも含みます。
OWNER RIGHTS と所有者の権利 OWNER RIGHTS の SID が追加され、ファイルにアクセスが行われる時点でそのファイルを所有しているユーザーに適用されるようになりました。これは、主に、所有者がそのファイルに行えることを制限するために使用されます。Windows XP と比較すると、所有者の権利が作用する方法が大きく 2 つ変更されました。まず、ユーザーがオブジェクトの所有者であり、そのユーザーに適用される ACE がオブジェクトにある場合、ユーザーが所有者であることよりも、ACE 内の権利が優先されます。これは大きな変更で、これまで所有者には暗黙の権利があるものとしてきたシステム管理の特定の側面に大きな影響を与えます。次に、所有者がオブジェクトを使ってできることをさらに制限するために、OWNER RIGHTS SID を使用することができます。
まず、エクスプローラでは、ファイルをコピーするにはアクセス許可を昇格する必要があることが示され、特権の昇格が求められますが、このフォルダにコピーする権利を持たないため、ファイルのコピーに失敗します。エラー メッセージには "この操作を実行するアクセス許可が必要です" と示され、(何か役立ちそうに) [再試行] ボタンと [キャンセル] ボタンが表示されます。このフォルダの所有者であるにもかかわらず、この現象が発生します。
図 2 このフォルダにはローカル システムと他に 1 人のユーザーしかアクセスしない
図 2 このフォルダにはローカル システムと他に 1 人のユーザーしかアクセスしない
Jesper がファイルの ACL の変更を試みると、この操作を行うにはトークンを昇格するように求められます。Jesper はファイルの所有者なので、この操作を実行できます。所有者には、ACL の読み取りと変更を行う暗黙の権利 (READ_CONTROL と WRITE_DAC) があります。ただし、OWNER RIGHTS の ACE がこれ以外の権利を指定する場合は除きます。
OWNER RIGHTS SID の効果を理解するために、これを上記の ACL に追加してみましょう。アクセス許可は 図 3 のようになります。
図 3 フォルダに OWNER RIGHTS 権限を追加して Jesper のアクセス許可を変更する
図 3 フォルダに OWNER RIGHTS 権限を追加して Jesper のアクセス許可を変更する
これらのアクセス許可により、Jesper のアカウントでこのフォルダにコピーを試みると、Jesper は所有者であり、適切な権利を所持しているため、この操作は成功します。しかし、Jesper がオブジェクトの ACL の変更を試みると、この操作は失敗します。OWNER RIGHTS の ACE では、所有者には変更の特権しかなく、随意アクセス制御リスト (DACL) を変更する権限はないことが指定されています。そのため、OWNER RIGHTS は主に所有者から WRITE_DAC (セキュリティ記述子を変更する権限) を削除するために使用されます。
管理者がオブジェクトの所有者を変更しても、新しい所有者には OWNER RIGHTS 権限が自動的には移行されません。この場合には、OWNER RIGHTS ACE は継承のみとマークが付けられ無効になりますが、コンテナにもオブジェクトにもこの ACE は適用されません。つまり、この ACE は何にもまったく適用されません。この動作が行われるのは、管理者がオブジェクトを完全にロック アウトしてしまわないようにするためです。OWNER RIGHTS ACE が再度効力を発揮するには、管理者が手動で ACE を再度有効にする必要があります。これを行うには、必要に応じてこのフォルダ、サブフォルダ、およびファイルに ACE を適用するマークを付けます。
OWNER RIGHTS SID が役に立つ興味深いシナリオがいくつかあります。たとえば、管理者がユーザーにファイル サーバーにファイルやフォルダを作成することは許可しても、これらのフォルダの ACL の変更を許可したくない場合などです。また、ある時点で何らかのオブジェクトを作成したユーザーがあるグループのメンバで、その後、おそらくビジネス上の理由で、そのユーザーがグループから削除されるような状況が発生することも考えられます。この時点では、ユーザーはこうしたオブジェクトの設定を変更することはできません。
OWNER RIGHTS は、サービスのセキュリティ強化機能ではかなり広範に使用されています。サービスが実行時に一時オブジェクトを作成する場合、オブジェクトの作成者は、サービス自体の SID ではなく、サービス プロセスのプライマリ SID (通常、LocalSystem、NetworkService、または LocalService) です。つまり、同じプロセス コンテキストで実行中の他のすべてのサービスがこのオブジェクトを変更でき、これはほぼ確実に望ましい状況ではありません。オペレーティング システムでは、このようなオブジェクトに OWNER RIGHTS SID を設定することにより、他のサービスからアクセスされないようにできます。

既定の ACL
Windows XP の既定の ACL は、実際にはかなり優れたものでした。ブート ボリュームのルートにファイルを配置できるような小さな問題を別にすれば、概して実用的でした。しかし、中には自社の方がセキュリティを正しく理解していると考える OEM もあるようです。図 4 の画面は、大手 OEM の Windows XP Media Center Edition を実行するコンピュータの Windows ディレクトリの ACL を示しています。この OEM は、ファイル システムのセキュリティを事実上無効にしています。
図 4 OEM が構成した ACL
図 4 OEM が構成した ACL
マイクロソフトでは、Windows Vista の ACL に少し手を加えました。まず、Windows XP を使い慣れていれば、すべての OS ファイルが Administrators グループによって所有されており、管理者にはこれらのファイルにフル コントロール権限があることを知っているでしょう。このグループのメンバであれば、こうしたファイルに自由にアクセスできました。しかし、Windows Vista では、それが不可能です。
Trusted Installer Windows Vista では、ほとんどの OS ファイルが TrustedInstaller SID によって所有され、この SID にしかフル コントロール権限がありません。これは Windows Vista のシステム整合性取り組みの一環として行われ、特に、管理者アカウントやローカル システム アカウントで実行されるプロセスがファイルを自動的に置き換えるのを防ぎます。そのため、オペレーティング システム ファイルを削除する場合は、ファイルの所有権を獲得し、ファイルを削除できる ACE を追加しなければなりません。これにより、LocalSystem で実行され、整合性のラベルが System のプロセスは簡単には削除されないように保護されます。整合性の低いプロセスは、自身の権限を昇格して所有権を変更できるとは想定されません。たとえば、ローカル システム アカウントで実行されるサービスであっても、整合性のレベルを中に設定して実行できます。このようなサービスはシステム ファイルを置き換えることができないため、いずれかのサービスを支配下に置いて悪用してもオペレーティング システム ファイルを置き換えることはできず、ルートキットなどのマルウェアをシステムにインストールすることが困難になります。また、あるシステム バイナリが単に存在するだけでも気に入らないシステム管理者が、こうしたバイナリを削除してしまうことも困難になります。
Deny ACE ファイル システムの多くのオブジェクトでは、Everyone グループに Deny ACE が設定されているのがわかるでしょう。これは、多くの管理者をかなり混乱させる原因になります。[すべてのファイルおよびフォルダを表示する] オプションをオンにしているとして、おなじみの Documents and Settings ディレクトリを見てみましょう。しかし、このディレクトリをクリックすると、アクセス拒否エラーが発生します。Documents and Settings ディレクトリで何が起こっているかを理解するために、図 5 のディレクトリ リストをご覧ください。
図 5 Documents and Settings はディレクトリではなく、接合ポイント
図 5 Documents and Settings はディレクトリではなく、接合ポイント
実際には、Documents and Settings はディレクトリではなく、接合ポイントです。以前に説明したように、接合ポイントとは単にアクセスを他の場所にリダイレクトするシンボリック リンクと同じです。この場合、C:\Users というディレクトリに接合が行われます。実際には、Windows Vista ではファイル システムの名前空間に大きな変更が行われ、ユーザー データは C:\Users に移動されることになりました。従来 "C:\Documents and Settings\<ユーザー名>" 名前空間の下にあった他の要素も移動されています。たとえば、"C:\Documents and Settings\<ユーザー名>\Application Data" は "C:\Users\<ユーザー名>\appdata\roaming" に移動されました。図 5 で行ったようにコマンド ラインで dir /a を使用すれば、この変更を非常に明確に確認できます。名前空間をこれほど大幅に変更した理由は、名前空間をユーザーにわかりやすいものにし、ドキュメントとデータを明確に区別するためです。開発者は、すべてのデータ ファイルを [マイ ドキュメント] フォルダに格納するのではなく、ユーザーのプロファイルの下に独自のフォルダを作成できるようになりました。そのため、ユーザーは自身のプロファイルの下を確認することになります。すべてのユーザーのアプリケーション データは "Documents and Settings\All Users\Application Data" の下ではなく、"%systemroot%\ProgramData" という隠しフォルダに格納されるようになりました。
古いアプリケーションでは %USERPROFILE% のような推奨環境変数を使わずに、名前を直接ハード コーディングしている可能性があるため、マイクロソフトは "C:\Documents and Settings" 名前空間を削除しませんでした。"C:\Documents and Settings" がなくなってしまうと、このようなアプリケーションは機能しなくなります。代わりに、旧バージョンとの互換性のために、こうしたディレクトリは接合ポイントやシンボリック リンクとして表されることになります。それでも、こうしたパスをハードコードしているアプリケーションは、その中のデータにアクセスしている方法によっては機能しなくなる可能性は残っています。また、英語以外の言語バージョンの Windows ではこうしたアプリケーションは機能しません。このことは実に重要です。Windows を Windows XP SP2 や Windows Vista などに更新するとサードパーティのプログラムが機能しなくなるほぼすべての原因は、プログラムの開発者がこうした間違った想定を行っているか、想定外の方法で Windows を使用していることにあります。
たとえば、"C:\Documents and Settings\<ユーザー名>\My Documents\foo.txt" を指定してファイルを開こうとする場合は、その場所に foo.txt というファイルがあると想定しています。しかし、"C:\Documents and Settings\<ユーザー名>\My Documents" を参照しようとすると、"アクセス拒否" エラー メッセージが表示されます。何が起こっているかを理解するには、図 6 の ACL を参照してください。
図 6 Documents and Settings に存在する Deny ACE
図 6 Documents and Settings に存在する Deny ACE
リスト内の最初の ACE を見てください。これがフォルダの内容を一覧する場合の Everyone に対する Deny ACE です。Everyone には "走査チェックのバイパス" 特権 (別称 SeChangeNotifyPrivilege) があるため、プログラムで接合ポイントを走査して、絶対パスを使ってドキュメントを開くことができます。ユーザーやプロセスからディレクトリを列挙する試みは、Deny ACE により失敗します。これが、C:\Documents and Settings の内部が表示できなかったり、"ディレクトリ" を削除できない理由です。Deny ACE を配置した主なポイントは、ユーザーが接合ポイントを削除して、古いアプリケーションの機能を停止させてしまうのを避けるためです。また、開発者が古い名前空間を使用してアプリケーションをコーディングすることがなく、アプリケーションが将来の変更や言語の違いに影響を受けないように、環境変数やレジストリ文字列を使用するよう注意を促す意味もあります。
こうした接合ポイントは既定では非表示になっているため、大多数のユーザーには表示されないことに注意してください。こうしたユーザーが接合ポイントを削除してしまわないように、マイクロソフトでは "フォルダの一覧" にも Deny ACE を設定しています。
走査チェックのバイパス ユーザーが権利を持たないフォルダ (または接合ポイント) の内部にあり、ユーザーが権利を持つファイルにユーザーがアクセスできる理由は、Everyone に "走査チェックのバイパス" 特権が設定されているためです。走査チェックのバイパス (SeChangeNotifyPrivilege) は、実際には Windows の最も基本的な特権で、プロセスの他のすべての特権が削除された後に許可されます。ただし、この特権も明確に削除することを求められたプロセスは除きます。この設定は、Windows Vista で runas /trustlevel:0x10000 < 行を使用してプロセスを起動したときに行われます。<コマンド> で指定されたプログラムは制限付きのトークンで実行され、プロセス トークンから SeChangeNotifyPrivilege を除くすべての特権が取り除かれます。
重要な点として、trustlevel 0x20000 では特権が取り除かれ、SID の通常のセットを備えたトークンが提供されます。0x40000 では、まったく通常のトークンが提供されます。

既定のアクセス許可
Windows Vista でのファイル システムの既定のアクセス許可は、Windows XP から少し変更されています。%systemdrive% (通常は C: ドライブ、ブート ボリューム) の ACL を表示すると、Windows XP または Windows Server® 2003 では次のようになります (以前のバージョンの Windows XP も非常によく似ていますが、一部異なります)。
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
以下は Windows Vista で表示した場合の同じディレクトリの同じ ACL です。
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
注目すべき多くの違いがあります。まず、BA (BUILTIN\Administrators) の ACE が 1 つだけではなく、2 つになりました。ただし、実質的な効果は同じです。Windows Vista では、1 つの ACE は継承されず、ルートへの完全なアクセスが許可され、もう 1 つの ACE は IO (Inherit-Only) ACE で、コンテナやオブジェクトによって継承され、GA (Generic All、つまりフル コントロール) が許可されます。同じことが SY (LocalSystem) にも当てはまり、Windows Vista では ACE が 1 つではなく、2 つに置き換わります。Windows XP では 1 つの ACE に完全なアクセスが許可され、オブジェクトやコンテナによって継承されました。ここでも、実質的な変更はありません。ACL を変更した主な理由は、ACL の管理が容易になるように特権を明確にし、準備することでした。また、将来の復元の可能性にも備えています。
さらに興味深いのは、CO (Creator/Owner) の ACE がなくなったことです。つまり、ユーザーがファイル システムのルートにオブジェクトを作成した場合、作成者には特別なアクセス許可が与えられなくなりました。
また、WD (Everyone) の ACE が削除されているのがわかります。セキュリティに関心のあった多くのユーザーは、この ACE の動作が暗黙に意味することを完全に理解できないとしても、この ACE に大きな懸念を抱いていました。マイクロソフトでは、Everyone はビルトイン Users と機能的には同じであることを長年説明してきましたが、最終的には説得をあきらめ、この ACE も削除したようです。BU (BUILTIN\Users) の ACE は同じで、コンテナとオブジェクトの両方で継承されるため、実質的な効果にはまったく変更はありません。
また、BU (ビルトイン Users) の 2 つの ACE が AU (Authenticated Users) の ACE に置き換わりました。これは、Guest アカウントが (INTERACTIVE がビルトイン Users のメンバであることが理由で) ビルトイン Users のメンバであり、Authenticated Users のメンバではないためです。Guest アカウントにファイルの読み取りと実行を許可するために、0x1200a9 (事実上 Read と Execute) ACE が BU に許可されたままです。ただし、Authenticated Users にはファイルとフォルダを作成するアクセス許可が与えられた ACE が許可されます。これは Windows XP とは異なります。Windows XP では、Guest アカウントはルートにファイルを作成できました。Windows Vista では、Guest アカウントはこのようなファイルを作成できません。ただし、Guest アカウントが有効で、ゲストが何らかの方法でブート ボリュームのルートにアクセスできない場合は議論の余地があることに留意してください。既定では、Guest アカウントが無効になっています。
最後に残った点として、上記の 2 つリストの ACE の中で非常に興味深く、一見面倒に見えるものが 2 つあります。Windows XP には、コンテナによって継承される ACE があり、ビルトイン Users に 0x100004 が示されています。この ACE はコンテナによって継承されるため、サブフォルダ、サブフォルダのサブフォルダというように、次々とサブフォルダを作成する権利が Users に許可されます。また、サブフォルダによって継承される、0x100002 で示される継承のみの ACE もあります。この ACE では、ルートに作成したフォルダにファイルやサブフォルダを作成する権利が Users に許可されます。つまり、以前に説明したように、これら 2 つの ACE により、Guest を含む Users は、ルートにファイルやフォルダを作成できます。
Windows Vista でこれに相当する ACE は継承のみの ACE で、コンテナとファイルの両方によって継承され、GR (Generic Read)、GX (Generic Execute)、および SD (Read Security Descriptor) を伴う GW (Generic Write) が許可されます。この ACE は、LC 特権が許可されるルート自体にしか適用されません。LC とは、実際には、Active Directory® の ACE に所属するショートカット表現です。Active Directory では、これは子オブジェクトを一覧できることを意味します。ただし、LC の 16 進数値は 0x4 です。ディレクトリの場合 0x4 は FILE_ADD_SUBDIRECTORY で、機能的には 0x100004 と同じになります。これは 0x1200a9 ACE から 0x100000 (同期にオブジェクトを使用する権限) が既に設定されているためです。つまり、Windows XP とまったく同じ効果が得られ、ユーザーはルートにサブフォルダを作成できます。
16 進数値はどのように求められるのでしょう。そもそも、この 16 進数値は何でしょう。既におわかりのように、アクセス制御は 0x1200a9 のように、すべて 16 進数 (base16) の数値です。これは実際にはアクセス マスク内で "オン" に設定されているビットのビットマスク表記で、ACE の明細を表すために使用されます。icacls、sc、secedit などのツールを使用して ACL を一覧すると、各ビットマスクが 1 対 1 に対応するわかりやすいテキスト文字列で表現されます。
したがって、LC の意味を調べるには、MSDN® Web サイトに移動し、文字列 LC を探し、[Access right value] 列を見て、ADS_RIGHT_ACTRL_DS_LIST を見つけるだけです。Iads.h ヘッダー ファイルを開き、この文字列を調べると、対応する値は 0x4 であることがわかります。Active Directory 以外の文字列 ("ADS_RIGHT" が前に付いていない文字列) の場合、通常、AccCtrl.h ファイルで 16 進数値が見つかります。16 進数値を見つけたら、その実際の意味を調べるのは簡単で、WinNt.h または AccCtrl.h でその値のアクセス マスクを探します。
さらに詳しい説明が必要な場合は、書籍『Protect Your Windows Network』(Jesper Johansson と Steve Riley の共著、Addison-Wesley、2005 年刊、英語) を参照できます。SDDL (Security Description Definition Language) 文字列と ACE を分析する方法は、この書籍の第 17 章で詳しく説明されています。
Windows Vista では、これらのサブディレクトリに許可されるアクセス許可は、単に (A;OICIIO;SDGXGWGR;;;AU) ACE によって管理され、これが Windows Vista と Windows XP が最も大きく異なる点です。Windows XP ではサブディレクトリの作成者にフル コントロール権限が与えられるのに対して、Windows Vista では認証済みのユーザーに変更権限が許可されます。
この新しい ACL の実質的な結果は、オブジェクトの作成者には特殊な権利がなくなり、事態が少し明確になったことです。おそらく最も大きな変更点は、管理者が作成したサブフォルダであっても、Authenticated Users に変更権限があることであり、これは Windows XP とは大きく異なります。Windows XP では、Users と Authenticated Users には管理者がルートに作成したオブジェクトに何も権利がありません。全体的に見ると、こうした ACE は一見面倒に思えるかもしれませんが、実質的な効果は Windows XP とまったく異なりません。
要約すると、Windows Vista では Guest ユーザーを含めたすべてのユーザーが、ルートにあるファイルの読み取りと実行が可能です。認証済みのユーザーのみが新しいファイルやフォルダを作成でき、ユーザーはこうしたファイルやフォルダの変更を行うときに、変更権限を得ます。つまり、Guest アカウントが既定で無効になっている点は注目すべきですが、Windows Vista では Windows XP に比べてアクセス許可がほんのわずかに厳しくなっただけです。

トークンへの変更点
Windows XP では、Administrators グループに所属するユーザーがログオンすると、そのユーザーのトークンには Administrators グループの SID が含まれ、Administrators グループが可能なことは何でも実行できます。それに対して、Windows Vista では、ユーザー アカウント制御により、このようなことはなくなりました。Administrators の SID はトークン内に依然として存在しますが、これには Deny のみが設定されています。これを示す Process Explorer のスクリーンショットを図 7 に示します。
図 7 UAC により、Administrators の SID は昇格しない限り、アクセスの拒否のみに使用される
図 7 UAC により、Administrators の SID は昇格しない限り、アクセスの拒否のみに使用される
アクセス制御を実行するときに、トークン内のこのようなエントリはアクセスの拒否のみに使用されます。つまり、DENY ACE に相当します。その SID に対して何らかの許可を行う ACE は無視されます。これは、システムに管理者としてログオンしても、常に管理者であるわけではないことを意味します。

整合性レベル
Windows では、プロセスやオブジェクトに整合性レベルのラベルを付けられるようになりました。これらの整合性レベルは、DACL 内ではなく、実際には ACE と同様に表現されます。整合性レベルは、いくつか特殊なフラグを備えた、システム アクセス制御リスト (SACL) の一部となります。たとえば、フラグ NW を使用して、整合性レベルが高いオブジェクトに整合性レベルの低いプロセスからの書き込みをブロックすることを指示します (SDDL_NO_WRITE_UP)。Mark Russinovich は、今月号の TechNet Magazine の記事「Windows Vista ユーザー アカウント制御の内部」でこの点を詳しく説明しています。

まとめ
Windows Vista ではアクセス制御に驚くような変更は 1 つも加えられていませんが、Windows 2000 で行われたように、小さな変更が数多く行われています。1 つ 1 つはそれほど大きな変更には思えませんが、これらが組み合わされると、実際には、システムを管理するために行ってきた多くのことを再検討しなければならないことを意味します。さらに、こうした変更により、主に UAC やサービスのセキュリティ強化機能など、他の多くのイニシアティブがサポートされます。管理者の中には、Windows Vista を使い始めたときに、大きな不満を感じる方もいるかもしれません。オペレーティング システムの構成要素を削除することは、私にはいささか攻撃的に思えますが、このような機能を制限すると、"暴君のようなオペレーティング システム" といったコメントが寄せられたことがあります。しかし、すべてに変更には根拠があります。少し時間をとって何が行われたかを分析すれば、おそらくその根拠を理解できるでしょう。

Jesper Johansson は、大手 E コマース企業のセキュリティ アーキテクトであり、資産やサービスの広範な領域について、アプリケーションのセキュリティ方針を担当しています。Jesper は 20 年間セキュリティに取り組んでおり、セキュリティに関する多くの記事と 2 冊の書籍を執筆しています。情報セキュリティに取り組んでいないときは、スキューバ ダイビングを教えています。


 セキュリティ: グループ ポリシーを使用してハードウェア制約を管理する
セキュリティ Jeremy Moskowitz

グループ ポリシーを使用してハードウェア制約を管理する
概要:
  • ハードウェアのインストールを制限する
  • 特定のデバイスを制限する
  • 一群のデバイスを制限する

お気付きのとおり、USB メモリをはじめとするさまざまなリムーバブル メディアは、プライベートでは便利でも、職場では厄介なものです。インストールできる
ハードウェア デバイスを制御する手段が必要です。幸い、Windows Vista™ および次期バージョンの Windows Server® (コードネーム "Longhorn") のグループ ポリシーを使用すると、USB マウスは許可しても USB ディスクオンキーは許可しない、CD-ROM リーダーは許可しても DVD ライタは許可しない、または Bluetooth は許可しても PCMCIA は許可しないといった制御が可能です。
ハードウェアのセキュリティには、グループ ポリシーの次の 2 つのセクションを利用できます。コンピュータの構成\管理用テンプレート\システム\リムーバブル記憶域へのアクセス (図 1 を参照) と、コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限 (図 2 を参照) の 2 つです。
図 1 グループ ポリシーの定義済みのハードウェアの制限
図 1 グループ ポリシーの定義済みのハードウェアの制限
図 2 制限するハードウェアの種類のカスタマイズ
図 2 制限するハードウェアの種類のカスタマイズ
1 つ目のセット (リムーバブル記憶域へのアクセス) は、読んで字のごとしです。特定のリムーバブル記憶域 (CD や DVD、フロッピーディスクなど) に対するポリシー設定を有効にすると、必要に応じてその種類のすべてのデバイスの読み取りや書き込みを制限できます。ただし、"デバイスのインストールの制限" ほどの強力な制限力はありません。
"リムーバブル記憶域へのアクセス" には、"カスタム クラス : 読み取りアクセス権の拒否" および "カスタム クラス : 書き込みアクセスの拒否" という名前のポリシー設定グループがあります。便利そうな名前ですが、"リムーバブル記憶域へのアクセス" ポリシーでは、ドライバのインストールを実際に防ぐことはできません。ハードウェアが検出された時点で、そのクラスのドライバは既にインストールされています。このポリシーの機能は、デバイスの読み取りと書き込みを防ぐことです。次のセクションでは、"デバイスのインストールの制限" ポリシー設定を取り上げ、ドライバ自体の使用を制限する方法を説明します。

クラスと ID を把握する
物事には順序があります。まず、制約する対象を把握する必要があります。この場合、大きく考えることも、小さく考えることもできます。つまり、特定の "クラス" のデバイスを制約することも、もっと細かく指定して、1 種類のハードウェアを制約することもできます。またはその逆に、USB マウスなど、特定のクラスのデバイスのみを許可することもできます。ただし、そこが面倒な部分です。本当に有効な設定を行うには、制約するハードウェアを突き止める必要があるからです。
したがって、"ジョイスティックはインストールできない" や "USB マウスのみインストールできる" という制限を設定するには、ジョイスティックと USB マウスについて把握している必要があります。または、インターネットを使用して、ハードウェア ID、互換性 ID、またはデバイス クラスを確認します。ただし、実際のデバイスが手元にあると、かなり簡単です。この場合は、コンピュータにこれを取り付け、ハードウェア ID、互換性 ID、またはデバイス クラスを自分で確認できます。一度確認できれば、そのデバイスの使用を禁止 (または許可) する方法が正確にわかります。
次の例では、Creative AutoPCI ES1371/ES1373 という特定のサウンド カード ファミリを禁止します。他のデバイス (特定の USB デバイス、USB ポートなど) を禁止する場合は、次の例を参考にして、デバイスの部分を目的のデバイスに置き換えてください。
目的のハードウェアが既にインストールされているコンピュータで、デバイス マネージャを起動します。デバイスを見つけて、右クリックし、[プロパティ] をクリックします。次に、[詳細] タブをクリックします。既定では、まず [デバイスの説明] が表示されますが、これはあまり有用な情報ではありません。[プロパティ] ボックスの一覧の [ハードウェア ID] をクリックします (図 3 を参照)。
図 3 デバイスの [詳細] タブ
図 3 デバイスの [詳細] タブ
[ハードウェア ID] を選択すると、より限定的なものからそうでないものの順に、デバイス ID が表示されます。ハードウェア ID の値の一覧で一番上に表示されている項目をよく見ると、このサウンド カードは、ES1371 サウンド ボードの Rev 2 であることがわかります。これはかなり限定的です。一覧で順番が下の項目の説明ほど、限定的でなくなり、ファミリ全体が含まれるようになります。
また、プロパティを互換性 ID に変更することもできます。これも、ハードウェアを説明する項目ですが、ハードウェア ID の情報よりも限定的ではないと見なされています。互換性 ID はより限定的でなくなり、実際に含まれる範囲が広くなることが考えられるので、互換性 ID の情報を使用して、より多くの同種のハードウェアを使用禁止一覧に加えることもできます。もちろん、これと引き換えに、制限したくないものを制限してしまう可能性はあります。
また、[プロバティ] ボックスの一覧の [デバイス クラス] をクリックすると、最も限定的でないカテゴリが表示されます。この例のサウンド カードの場合、単に "Media" と表示されます。ただし、メディアと見なされるアイテムは多数あるため、より限定的でない値を選ぶ場合は、やはり注意が必要です。
使用する値を決めたら、その値を右クリックし、[コピー] をクリックして、確実に保存しておくためにメモ帳に貼り付けます。次の手順でこの値を正確に入力する必要があるため、表示されている文字列を直接コピーすることが重要です。大文字と小文字の違いも含めて、値を正確に入力する必要があります。
ハードウェア ID またはデバイス クラスの取得に、デバイス マネージャではなくコマンド ライン コマンドを使用する場合は、Devcon コマンド ライン ユーティリティ (support.microsoft.com/kb/311272) を試してみてください。また、マイクロソフトでは、共通クラスの ID を多数提供しています。これは、デバイスを物理的に参照できない場合に便利です。詳細については、go.microsoft.com/fwlink/?LinkId=52665) を参照してください。

グループ ポリシーを使用したハードウェア アクセス制御
コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限 (図 2 参照) に含まれるすべてのポリシー設定について説明しましたが、この最初の例を完了するために必要なものは実は 1 つしかありません。
まず、グループ ポリシー オブジェクト (GPO) を作成し、制御する Windows Vista コンピュータが含まれる OU (またはドメインなど) にこの GPO をリンクします。次に、この GPO を編集します。コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限\これらのデバイス ID と一致するデバイスのインストールを禁止するに移動します。このポリシー設定で [有効] を選択し、(同じくこのポリシー設定にある) [表示] をクリックして、[内容の表示] ダイアログ ボックスで [追加] をクリックします。次に、[項目の追加] ダイアログ ボックスに、前に保存しておいたデバイス情報を貼り付けます (図 4 参照)。
図 4 デバイス ID を貼り付けて説明を正確に入力する
図 4 デバイス ID を貼り付けて説明を正確に入力する
ここで、気を付けなければならないことがあります。コンピュータに既にデバイスがインストールされている場合、このデバイスが自動的にアンインストールされ、デバイスへのアクセスが制限されることはありません。したがって、ハードウェアを制限する場合は、Windows Vista の展開プロセスの初期段階で、この設定を行う必要があります。ただし、Windows Vista は、デバイスが削除および再インストールされるたびに再度確認を行います。USB ドライブのようなアイテム (取り外され、後で再度挿入されるアイテム) は、このプロセスでの制御に適しています。Windows Vista は、デバイスが再インストールされたときのみ確認を行うので、(デバイス ドライバが既にコンピュータに読み込まれている場合でも) デバイスはその時点で制限されます。さらに問題が難しくなるのは、デバイスがコンピュータにプレインストールされていて、削除も再インストールもできない場合です。このようなデバイスには、簡単にすぐに実現できるソリューションはありません。
これまでインストールされたことのないハードウェア デバイスが取り付けられたコンピュータを起動すると、Windows はドライバのインストールを試み、進捗情報を表示します。このようなデバイスを制限するポリシーを設定している場合、図 5 のような処理結果が表示されます。
図 5 デバイスのインストールの阻止
図 5 デバイスのインストールの阻止

その他のハードウェア制限
前述の例では、1 デバイスのみを禁止しました。必要であれば、この反対の方法をとり、既定ですべてのハードウェアを制限し、そのうえで一部を許可することもできます。このようなポリシー設定も、コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限 (図 2) に含まれています。いくつか提供されている設定の中から任意のものを選択できます。
1 つ目は、"管理者によるデバイスのインストールの制限ポリシーの上書きを許可する" です。既定では、Windows Vista のローカル管理者よりも、既に設定されている制限が優先されます。この設定を有効にすると、ローカル管理者が制限を上書きし、必要なハードウェアをインストールできるようになります。
2 つ目は、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを許可する" です。このポリシー設定にデバイスの説明を入力することで、そのハードウェア デバイスのシステムへのインストールを明示的に許可します。このポリシー設定に使用できるのは、(前の例で使用した) デバイス ID ではなく、セットアップ クラスのみです。
前の例と反対の制限を行うには、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを禁止する" を設定します。
"インストールがポリシーによって禁止されている場合にカスタム メッセージを表示する (バルーン テキスト)" および "インストールがポリシーによって禁止されている場合にカスタム メッセージを表示する (バルーン タイトル)" の 2 つの設定により、メッセージをカスタマイズできます (図 5 参照)。
前述のとおり、より限定的でない形でハードウェアを説明する場合は、ハードウェア クラスを利用します。"これらのデバイス ID と一致するデバイスのインストールを許可する" ポリシー設定には、クラス ID の説明は使用できないことに注意してください。クラス ID の説明を使用するには、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを許可する" または "これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを禁止する" を使用します。後者のポリシー設定は、"他のポリシー設定で記述されていないデバイスのインストールを禁止する" と合わせて使用すると最も効果的です。すべてを禁止 (既定) したうえで、この設定を使用すると、許可するデバイスを正確に指定できます。
前の例では、"これらのデバイス ID と一致するデバイスのインストールを禁止する" ポリシーを使用して、デバイス ID を基に特定の種類のハードウェアを制限しました。デバイス クラスを使用して制限を実装する場合は、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを許可する" または "これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを禁止する" など、その他の設定を利用する必要があります。
"リムーバブル デバイスのインストールを禁止する" を使用すると、その名前が示すとおり、USB デバイスなどのリムーバブル ハードウェア デバイスを一様に簡単に制限できます。この設定はあまり限定的でないため、あまり頻繁には使用しないことをお勧めします。代わりに、前に説明した方法を使用して、ある程度限定的であるデバイス ID を取得し、この ID を持つデバイスを制限するようにします。
また、"他のポリシー設定で記述されていないデバイスのインストールを禁止する" は、包括的なポリシー設定で、何らかのデバイスのインストールを許可するよう特に定義していない限り、基本的にすべてのハードウェアを制限します。このポリシーと、各種の "～を許可する" ポリシー ("これらのデバイス ID と一致するデバイスのインストールを許可する" など) を組み合わせると、個々の環境に必要なハードウェアのみを許可する非常に強力なツールとして使用できます。

まとめ
Windows Vista のグループ ポリシーには、多数の新しい強力な機能があります。これらは、各環境に必要なハードウェアのみを使用できるようにする場合に非常に便利です。展開プロセスの初期段階でポリシー設定を実装するだけで、不要なハードウェアがネットワークに接続されないようにすることができます。
マイクロソフトでグループ ポリシーのリード プログラム マネージャを担当している、Michael Dennis へのインタビュー
最近、Michael Dennis にインタビューをする機会がありました。彼は、マイクロソフトでグループ ポリシー チームが発足された当初から、このチームの舵を取っています。Michael は現在、グループ ポリシー チームを去り、マイクロソフト内の別の職務に就こうとしています。これまでのグループ ポリシーの 9 年間を振り返り、その過去とこれからの展望について、Michael に話を聞きました。

Jeremy Moskowitz Michael さん、あなたがマイクロソフトでこれまでグループ ポリシー チームを統率してきた中で、最大の成果は何だとお考えですか。これを知りたがっている人は多いと思います。

Michael Dennis 最大の成果は、かなりさかのぼって、グループ ポリシーと呼ばれるものの開発に本格的に乗り出したときのことです。既に Windows NT® 4.0 のシステム ポリシーがあったので、このシステム ポリシーとその問題点について調査しました。このときは、Active Directory® を開発している時期だったので、クライアントとサーバーの管理性を強化する必要がある部分に注目しました。
グループ ポリシーの階層化は、それまで実現されたことがなかっただけに、とてつもない考えでした。ですから、中核となるインフラストラクチャ、クライアント プロセス、および Active Directory との統合に注力しました。
最大の成果の副産物は、最悪の成果でもありました。これは、Windows 2000 でリリースした GUI に問題があったためです。管理者がグループ ポリシーを有効に利用するには、全体がどのように機能するかを理解している必要があったため、グループ ポリシーについての博士号なみの知識が必要でした。あの当時に、グループ ポリシー管理コンソール (GPMC) とポリシーの結果セット (RSoP) を開発して提供できていたらよかったと思います (これは仕様には盛り込まれていました)。

JM グループ ポリシーに実装できていたらよかったと思うものは何ですか。

MD 嬉しいことに、Windows 2000 のリリース以降に望んでいたものが、現在 Windows Vista で実現できています。それは、RSoP、GPMC、新しい設定などです。これらをもっと早くに実現できればよかったと思います。
また、グループ ポリシーのインフラストラクチャが、パートナーがもっと拡張しやすいものであればよかったと思います。私たちのサーバー側/クライアント側拡張モデルでは、開発者がかなりの作業を行う必要があります。ただし、ADM/ADMX テンプレート構造により、拡張性の高いフレームワークが提供されているので、これは議論の余地があるところです。それでも、システムのこの部分を使用して、より多くの種類の設定を拡張できるようになっていたら、もっとよかったでしょう。
あと、GPMC レポートも、パートナーおよびサードパーティのツール開発者にとって、より拡張性の高いものであればよかったと思います。これは、サードパーティのツール ベンダから強く言われている部分です。

JM グループ ポリシー チームについて、一般に知られていないことは何ですか。

MD ときどき、グループ ポリシー チームが全体でどの位置を占めるのかが明確でないことがあります。考え方としては、インフラストラクチャ、トランスポート、およびサーバー側/クライアント側モジュールを開発するチームです。ただし、Windows Vista だけでも、マイクロソフトの他の 120 チームと協力して、このリリースに実装されている新しい設定を開発しました。
読者の方にご理解いただきたいのは、起動時やログオン時にシステムのパフォーマンスが低下する問題の原因は、グループ ポリシーではないということです。パフォーマンスの低下を引き起こしているのは、グループ ポリシーのペイロードです。何か負荷の高い作業を行うようにグループ ポリシーを設定している場合、それが実行されます。たとえば、Microsoft Office をコンピュータごとにインストールするように設定している場合は、かなり時間がかかるでしょう。しかし、グループ ポリシーは設定されたとおりの操作を実行していることをご理解ください。つまり、ログオン画面が表示される前に、Office 全体をインストールするという操作です。これは、パフォーマンスの低下と言えるでしょうか。確かに動作は遅くなりますが、展開した管理者にとっては、これこそシステムで実行されるように設定した動作そのものなのです。

JM グループ ポリシーを使用して、一番自慢したいことは何ですか。

MD 最近は、Windows Vista に組み込まれた新しい設定が自慢です。リムーバブル デバイス用の設定 (USB スティックなどを制限する設定) は、皆さんから強く要望されていた設定です。Windows Vista には、約 2,400 の設定があり、管理者はこれらを使用してかなり高度な制御を行うことができます。私は、お客様に制御したいものをたずねて、その方法をお見せするのが好きです。

JM ADM ファイルから ADMX ファイルに変更したのはなぜですか。

MD 技術的には、Windows Vista に新しい中央ストア機能を実装するために、この変更を行う必要はありませんでした。ADMX に変更した最大の理由は、多言語を適切にサポートできるようにするためでした。
これまで、多言語環境では、GPO 内部の ADM ファイルのコンテンツが、別の言語によって誤って上書きされてしまうことがありました。経緯をたどると、ADM 形式は Windows NT 4.0 から受け継いだもので、その元は Windows 98、そのまた元は Windows 95 で採用されていたものです。その頃に XML があれば、ファイル形式の候補に XML が挙がっていたでしょう。
しかし、現在は XML があります。他言語のサポートが容易になったほか、スキーマ化された言語を使用して、レジストリや設定を拡張することもできます。

JM GP チームで仕事をしている間に、乗り越えなければならなかった最大の内部の課題は何でしたか。

MD 現在もチームが直面している最大の課題は、他の Windows コンポーネントの機能をポリシーに対応させることです。
たとえば、あるチームは「このすばらしい新機能は開発が完了したばかりだ。だれがこれを無効にしたいと思うんだい」と反論するかもしれません。その気持ちはよくわかります。しかし、私たちはこのような問題を多数乗り越えてきたのです。
また、ポリシーによって機能を有効にすることには技術的な課題もあります。たとえば、新しいセキュリティが強化された Windows ファイアウォール (WFAS) がそうです。WFAS は非常に厄介でした。これを正しくポリシーに対応させるのは、簡単なことではありません。WFAS チームが Windows Vista 向けに作成したインターフェイスはすばらしいものですが、これを適切に処理することは非常に困難です。
Windows Vista より前のバージョンの Windows では、製品チーム自らが、担当コンポーネントをポリシーに対応させることを常に考慮していたわけではありません。しかし、Windows Vista の開発においては、かなりの数のチームがその方法を質問してきました。このことは印象的でした。
JM 次は何をされるのですか。

MD &quot;モバイル インフォメーション ワーカー&quot; チームに移ります。スマート フォン、Pocket PC などを担当しているチームです。私の役目は、Windows Server System の一部の管理テクノロジを Windows Mobile® デバイスに移植することです。
管理性に対するこれまでと同じビジョンと情熱をもって、新しい職務に取り組んでいくつもりです。当面の間は完全に異動せずに、私がいなくても物事が進むように、グループ ポリシー チームを離れる準備をします。

JM 他に何か読者に伝えたいことはありますか。

MD グループ ポリシーの開発を通じて常に重要だった作業の 1 つは、お客様と向き合い、お客様が何をしようとしているのかを十分に理解することでした。お客様がグループ ポリシーで対応してほしいシナリオについてよくまとまった意見をお持ちで、何かを実行するためのビジネス ケースがある場合は、それをお知らせいただく必要があります。
どなたでも利用できるすばらしいフィードバック システム (WindowsServerFeedback.com) をご用意しています。そこで、グループ ポリシー用のボタンを探してください。
"こんな問題がある、こんなビジネス ケースがある、こんなことを行うシステムが必要で、その理由はこうだ" といった情報をお寄せいただくと、非常に助かります。グループ ポリシーの今後の方針を決める担当者は、ここから寄せられたフィードバックにすべて目を通します。
繰り返しになりますが、グループ ポリシーの機能強化に一石を投じたいと思われる方は、何を必要とされているかお知らせください。ただし、理由を説明せずに、"こういうことをするポリシー設定が必要だ" という形でのご意見はご遠慮ください。「How (方法)」を解明するのが私たちの仕事です。グループ ポリシー チームが本当に知る必要があるのは、「Why (理由)」なのです。
JM マイクロソフトのグループ ポリシー チームでのご経験をお聞かせいただき、ありがとうございました。今後のご活躍をお祈りしています。
MD ありがとうございます。

Jeremy Moskowitz(グループ ポリシーの MCSE および MVP) は、グループ ポリシーのコミュニティ フォーラム、GPanswers.com を運営しています。また、グループ ポリシーについての一連の集中トレーニング ワークショップも開催しています。最近の著書には『Group Policy: Management, Troubleshooting and Security』(Sybex、2007 年) があります。Jeremy には、www.GPanswers.com から連絡してください。


 セキュリティ : すべての IT 組織が持つべき 4 つのセキュリティ テクノロジ
セキュリティ Matt Clapham and Todd Thompson

すべての IT 組織が持つべき 4 つのセキュリティ テクノロジ
概要:
  • リスク管理ダッシュボード
  • マルウェア対策
  • ネットワークの異常検出

IT セキュリティに関して言えば、対処しなければならない問題として、実際にはほとんどの企業がほぼ同じ問題を抱えています。マイクロソフトも例外ではありません。私たちは、
Microsoft® Managed Solutions (MMS) の Risk Management and Compliance チームで 2 年間過ごしてきました (MMS の詳細については、「マイクロソフトが Energizer の IT 部門を支援」を参照してください)。
Risk Management and Compliance チームは、(顧客に提供するサービスとインフラストラクチャの連携のいずれについても) すべての MMS 環境のリスク体制の定義、監視、および修正を担当しています。早くから、私たちのマネージャである Arjuna Shunn は、望ましい制御と監視を一元的かつ統合された形で提供するテクノロジ ソリューションの必要性を認識していました。この記事で取り上げるテクノロジは、この初期のアイディアから直接生まれたもので、さまざまなマイクロソフト製品やサードパーティ製の製品を私たち自身の業務で使用してきた 2 年間の経験が反映されています。
まず、3 つの主要な制御のタイプ (予防、検知、修正) をカバーしながら、監査およびレポート機能を提供できるセキュリティ テクノロジが必要でした。私たちは、このツール群を 4 つのカテゴリに分類しました。リスク管理ダッシュボード、マルウェア対策、ネットワークの異常検出、および望ましい構成の管理の 4 つです。各カテゴリにつき、少なくとも 1 テクノロジをリスク管理業務に取り込むようにしました。そして、この 4 つの領域の各テクノロジを利用することで、コストと有効性の両面から見て、バランスのとれたソリューションを実現できることがわかりました。
この方法により、私たちの 2 つの主要なリスク管理業務 (セキュリティ障害対応および遵守管理) において大きなメリットが得られましたが、最終的に目標とするツール間の連携を実現するためにはまだ取り組みが必要です。テクノロジが統合されていれば、運用効率を大幅に向上できますが、残念ながら業界にはこのような統合されたシステムは現在のところありません。
幸い、IT セキュリティ チームにとって問題解決の糸口がないわけではありません。4 種類のシステムが連携して相互に機能し、大きな効果をもたらすようになるのは、単に時間の問題です。これらのシステムすべてが連携すれば、システムのセキュリティ体制を能動的に監視できるようになるだけでなく、監査や他の所定の IT 業務にも役に立つでしょう。この記事では、実際の使用例をいくつか交えて、各システムの理想的な機能を説明します。

リスク管理ダッシュボード
私たちの考えでは、リスク管理ダッシュボード (RMD) は絶対に必要です。これは、IT セキュリティ チームの業務にとって最も重要なテクノロジです。企業における機密性、整合性、可用性、および説明責任 (CIA2) のリスクは、多くの場合、データの集計、関連付け、リスクの修復を行うための統一されたインターフェイスがないままに、別々のシステムやプロセスで監視されています。また、法規制により、ますます困難なレベルでの企業のデータの透明性が求められるようになりましたが、ポリシーの作成から企業での実施状況までを容易に追跡できる能率的なシステムはありません。このことは、企業で共通してみられるデータ取得、関連付け、評価、修復、順守の難しさにより、証明されています (ここで説明するような完全な RMD ソリューションではありませんが、図 1 に示す System Center Operations Manager 2007 は、複数のリソースを監視し、関連する警告を収集できる統一されたインターフェイスを提供しています)。
図 1 System Center Operations Manager 2007 は、警告を表示し、ネットワーク全体のリソースを管理できる統一されたインターフェイスを提供
図 1 System Center Operations Manager 2007 は、警告を表示し、ネットワーク全体のリソースを管理できる統一されたインターフェイスを提供
データ取得は、各種ソースのデータを集計して標準化できないことで、妨げられています。データの集計はそれ自体が、データの収集とレポートに使われる、連携の取れないありふれた方法から脱する必要があるため、非常に困難な作業です。データの集計が実現できたとしても、引き続き標準化がさらに大きな問題を課しています。これは、データの標準化のサポートに必要な共通フレームワークを確立することが、非常に難しいためです。この標準化が実現できなければ、異なるシステムのセキュリティ イベントや正常性関連イベントを意味のある形で比較することは不可能です。
必要な自動化を行うには、リスク管理ダッシュボードが、ここで説明するセキュリティ テクノロジ以外のソースからデータ フィードにアクセスできる必要があります。セキュリティに関連しないデータの多くは、全体的なリスク体制の特定に使用できます。ルーター ログ、資産管理、修正プログラムの状態、現在のログオン ユーザー、パフォーマンス レポート、変更管理データなどの情報は、いずれも問題の調査担当者に関連情報を提供できます。したがって、システム全体が、これらのデータすべてにアクセスできる必要があります。私たちは、企業インフラストラクチャがマイクロソフトのテクノロジを中心に構築されている場合でも、マイクロソフト以外のテクノロジが取り入れられていることに気が付きました。したがって、RMD は何らかの共通インターフェイスを利用して、マイクロソフト以外のテクノロジからのフィードも受け入れられる必要があります。
データを取得し、標準化できたら、次のステップはデータの関連付けです。目標は、一連のイベント (ネットワークの異常イベント、ウイルス対策レポート イベント、望ましい構成との不一致イベントなど) を関連付けて、実用的なリスク関連データにまとめることです。これには、意味のあるリスク ベースの警告を生み出す関連付けロジックを構築するために、かなりの手作業を必要とします。現在利用可能なテクノロジでは、この関連付けロジックは、できたとしても、実現が難しいものです。
データの評価も、かなりの手作業を必要とします。関連付けがあった場合、アナリストは関連付けられたデータを調べて、その有効性を判断する必要があります。関連付けられたデータの有効性は、それが基盤としているルールの有効性と同じにしかなりません。このため、関連付けられたデータを人間が分析して、IT 環境のリスクを評価する必要があります。このとき、明確で体系化されたリスク管理フレームワークがあると、優先順位を決定できるレベルになるまでに必要になる人的作業の量を削減できる可能性があります。このフレームワークがないと、ある実装において実用的な一連の関連付けルールを開発することは困難です。
システムがリスク評価の段階に到達したら、次のステップは自動修復です。現在、企業内で本当に利用できるのはこの部分のみですが、それでも、修正プログラム管理やウイルス対策など、限られたテクノロジに対してしか利用できません。RMD システム主導の自動修復は、許容できるレベルの IT リスクを維持するうえで IT 管理の大きな力になります。複数のリスクが同時に見つかった場合、関連付けロジックにより、資産分類データを基に問題対応の優先順位を付けられるようにする必要があります。
また、さまざまな法規制への順守を証明することは、IT 部門にとって非常に大きな課題であり、前述のとおり、このような機能をこのシステムでサポートする必要があります。ポリシーと結びついた一元的なリスク管理システムは、法令順守のレポートや証明を生成する上で大きな資産となり得ます。ただし、ポリシーは場所や理由を示す以上のものでなければなりません。自動修復を促進するには、ダッシュボードによる監視、適用、フィードバックの提供が可能な一連の標準として、ポリシーを表現する必要があります。
したがって、理想的なリスク管理ダッシュボードとは、企業環境の正常性評価、法規制やポリシーの順守、およびリスク管理プロセスをサポートする統合インターフェイスを提供する手段であると言えます。これは、さまざまなセキュリティおよび正常性関連製品やソースからの情報をまとめて、単一のリスク関連ディスプレイに統合することで、実現されます。優れた RMD ソリューションは、以下の作業を実行できる必要があります。
  • 異種ソースのデータの集計、標準化、関連付け
  • 自動化された情報収集およびリスク評価の提供
  • 法的要件のポリシーへの展開と監査およびレポートのサポート
  • 企業の要件に合わせて変更が可能な統合フレームワークの提供
リスク管理ダッシュボードは、データを意味のある形で整理および表示できる必要があります。たとえば、種類やソース システム別に最も重大な問題を表示したり、保留中の問題、解決済みの問題などを表示したりします。また、各レポート項目の詳細を確認できる必要もあります。イベントを確認するときは、すべての関連データに容易にアクセスできる必要もあります。これにより、よりすぐれた決断を迅速に下せるようになります。
RMD がセキュリティ チーム以外の管理者にとっても有用であることを指摘しておきます。このダッシュボードでは、環境全体の状態を把握できるため、全スタッフが現在の状態を確認できるようにする一元的な場所としても利用できます。たとえば、このダッシュボードでは、メッセージング チームに SMTP ゲートウェイに対するサービス拒否攻撃について通知することもできます。これは、リクス管理チームにとってはセキュリティの問題ですが、メッセージング チームにとっては可用性の問題になります。メッセージング チームには、このような問題を防いだり解決したりする責任はないかもしれませんが、自分たちが管理しているこのような資産に影響する問題を少なくとも把握しておく必要はあるでしょう。

マルウェア対策テクノロジ
包括的なマルウェア対策システムは、インフラストラクチャをコードやユーザー操作に隠れている不測の脅威から保護するうえで重要です。現在、基本的に 2 種類のマルウェア対策ツールがあります。1 つはウイルス対策で、もう 1 つはスパイウェア対策のツールです (たとえば、図 2 の Windows® Defender は、後者に分類されます)。それぞれ、異なる種類の感染の予防、検出、修正に有効です。ただし、この 2 種類の保護が 1 つのソリューションに統合されて、システム上のマルウェア対策スタックが 1 つだけになるのも時間の問題です。
図 2 Windows Defender はクライアントをスパイウェアから保護
図 2 Windows Defender はクライアントをスパイウェアから保護
完全なマルウェア対策ソリューションでは、リアルタイムの監視と定期的なスキャンを行う必要があります。既知のマルウェア (ウイルス、スパイウェア、ルートキットを含む) と、典型的な危険な動作の有無を基に特定された不明なマルウェアを一括してレポートできる必要があります。堅牢なマルウェア対策テクノロジでは、OS とアプリケーションとの緊密な統合の下で、従来のエントリ ポイント (ファイル システム、レジストリ、シェル、ブラウザ、電子メール、ネットワークに接続するアプリケーションなど) をすべて監視します。
また、マルウェア対策ソリューションには、ホスト セキュリティ以上のものが必要です。感染したファイルの侵入経路となることが多い、一般的なメッセージングおよびコラボレーション サービス (SharePoint® やインスタント メッセージングなど) を監視する必要もあります。また、(既知のまたは疑わしい) 操作を阻止すると共に、ユーザー データを慎重にスキャンして、ユーザー ドキュメントに潜んでいてもまだシステムに感染していないマクロ ウイルスなどを削除することで、自動的な防御を提供できる必要があります。
マルウェア対策は、更新を行わないと役に立たないことは言うまでもありません。最新の脅威に対抗するためには、マルウェア対策システムの署名および除去システムを最新の状態に保つ必要があります。新しい脅威が出現した場合、マルウェア対策ベンダは、次のゼロデイ攻撃が発生する前に追加の保護が適用されるようにする必要があります。管理しやすいマルウェア対策ソリューションでは、一元的な構成と更新も可能です。
もちろん、このような保護のために、パフォーマンスを犠牲にすることはできません。パフォーマンスが低下すれば、生産性が低下します。ユーザーがマルウェア対策ソリューションを無効にして、保護がまったく適用されない状態になってしまうことも考えられます。
また、マルウェア対策システムを補完するテクノロジの重要性も見過ごさないようにしてください。ファイアウォールやユーザー特権の制限などの戦略も、悪意のあるコードやユーザー操作に対する保護を強化します。

ネットワークの異常検出
マルウェア対策がシステムを監視する一方で、ネットワークの異常検出 (NAD) は一般的な経路を監視します。疑わしい動作を示す既知の現象に目を光らせ、この情報を RMD に報告して修復を促します (たとえば、図 3 のように、ファイアウォールはこのカテゴリに含まれます)。疑わしい動作とは、既知の攻撃トラフィック (ワームやサービス拒否など) や、電子メールで送られてきた、ある特定のパターンに当てはまるデータ (米国の社会保障番号など) です。
図 3 ファイアウォールはネットワークの異常検出ソリューションの重要な構成要素
図 3 ファイアウォールはネットワークの異常検出ソリューションの重要な構成要素
IT 管理でどれほど努力しても、大規模な企業ネットワークではマルウェアの問題が時折発生することは免れません。NAD は、修復を促進できる初期警告システムとなります。また、NAD のデータ監視機能と、機密情報の漏洩の特定および阻止機能は、データ漏洩と法令順守が懸案事項である環境の情報を保護するうえで便利なツールです。
マルウェア対策テクノロジと同様に、NAD も定期的に脅威や機密データの種類についての最新情報を取り入れておかなければ、その価値は大幅に減少します。また、優れた NAD システムは、実際の異常についての情報を、誤検知を最小限に抑えられるだけ十分に備えている必要があります。そうでない場合、どのレポートも誤った警告であると見なし、管理者が NAD から送られるレポートを無視してしまう可能性があります。
NAD システムは、多少の調整と学習を行うだけで、典型的なトラフィックの使用パターンを認識し、監視できる必要があります。これは、新種のマルウェアやその他の攻撃が使用パターンを変えて出現する可能性があるため、重要です。NAD ソリューションはルーター、スイッチ、およびファイアウォールからのデータを処理する必要があるため、ネットワーク機器は NAD システム全体で重要な役割を果たします。NAD の警告は、その後、RMD の関連付けエンジンによって処理されます。
ここで興味深い可能性として、ネットワークの異常検出機能を、ホストのマルウェア対策ソフトウェアやファイアウォールに組み込むことが考えられます。そうすることで、関連するすべてのコンピュータで、攻撃を監視し、攻撃が広まる前に阻止できるような保護ネットを張るようにします。

望ましい構成の管理
大規模企業の IT 部門が直面している最大の課題の 1 つは、システムを適切な構成に保つことです。システムの構成の維持を図る理由は多くあります。ほんの一例としては、管理の容易さ、スケーラビリティの簡素化、順守の徹底、さまざまな不正侵入の阻止、生産性の向上などが挙げられます。このような理由の多くは、セキュリティに関係しています。
望ましい構成の管理は、その複雑さと初期費用の高さから、ほとんどの企業があまり足を踏み入れていない領域となっています。しかし、研究によると、長期的にはシステムを管理することで、コストを削減し、信頼性を向上できることが示されています。それには、望ましい構成の監視 (DCM) ソリューションが役立ちます。
優れた DCM システムは、自動的にネットワークをスキャンして、新しいシステムが確実に望ましい構成で展開されるようにし、既存のシステムが決められた構成に従っていることを確認できる必要があります。最新の修正プログラムが展開されていることを確認するか、ドメイン特権を持つユーザーの数を最小限に抑えるかどうかにかかわらず、完全な DCM ソリューションは、システムを構成、分析し、各構成が理想の構成とどの程度近いかをレポートする必要があります。修正は簡単な処理 (ネットワーク上の新しいシステムの展開時に、そのシステムに修正プログラムを適用するなど) であることも、強制的な処理 (ユーザーの電子メール クライアントの設定を適用するなど) であることもあります。重要なことは、これらを組織のポリシーと法規制への対応に結びつけることです (DCM は、簡単な種類のマルウェアについてはスキャンの結果から容易に特定できるため、マルウェアの感染の特定と削除にも利用できます)。
DCM は、RMD の関連付けエンジンにデータを供給する主要なソースの 1 つで、DCM は問題のホストが標準からどれほど逸脱しているかについての重要な詳細情報を提供します。データがタイムリーに供給されるかどうかにより、レベル 1 の警告のセキュリティの問題になることも、レベル 5 の警告の問題になることもあります。したがって、資産はその価値に応じた頻度でスキャンする必要があります。たとえば、機密性の低い資産は 1 か月に 1 回、機密性が中程度の資産は 1 週間に 1 回、機密性の高い資産は少なくとも 1 日に 1 回スキャンするようにします。
DCM は、優れたネットワーク アクセス保護 (NAP) メカニズムの基本的な構成要素でもあります。これは、DCM が、すべての接続されたシステムが適切に構成されていることを確認し、新しいまたは不明なシステムは検証されるまで阻止できるためです。また、DCM は、構成上の脆弱性 (ある共有に対する脆弱なアクセス制御リストなど) についても検査し、管理者が適切な対応をとれるようにする必要があります。
クライアントやサーバーなどのホストしか、DCM の対象にならないとは思わないでください。ネットワーク デバイスやコア ディレクトリ自体も、DCM の対象に含めることができます。十分に汎用的なネットワーク設計であれば、理想的な DCM システムに関連デバイスの標準を適用することは容易に行えるでしょう。これは、さまざまな使い方ができます。ルーター構成を手動で調整する代わりに、DCM により実装を処理できます。または、標準のグループ ポリシー設定が特定のサーバーやクライアント群に関連付けられているとします。DCM は、これらを監視し、ドメイン設定が変更された場合に警告を送信できます。
DCM が収集するデータは、IT 監査でも使用できる適正なデータである必要があります。優れた DCM は、変更管理および法令順守コントロールと連携し、監査上の問題にタイムリーに、ほぼ継続的に対応できる必要があります。たとえば、私たちが使用しているルーチン コントロールは、MMS サーバーに対するローカル管理者のメンバシップが変更されていないことを確認するためのものです。このルールの適用こそ、DCM が作られた目的なのです。
自己修復型の CDM システムの準備が IT 部門にできていなかったとしても、望ましい構成の監視として知られるソリューションを展開して、大きな成果を上げることはできます。また、構成上の問題についてのレポートや警告も提供できますが、修復の大半を手動で行うことになるため、同程度のメリットは必ずしも実現できません。ただし、重要なことは、RMD が必要とする通知やデータは、関連付けの対象として取得できます。
ただし、1 つ注意があります。DCM は、上記のいずれの形であっても、最小限の重要な構成項目に、標準の資産収集データを合わせた範囲のみを対象とするようにします。そうでないと、IT チームが必要とする柔軟性が妨げられる可能性があります。DCM による構成の基準が古くなると、DCM はすぐに便利なツールではなく運用上の負担と見なされるようになります。したがって、資産の最適な構成方法についての最新の考え方に遅れないでいることが重要です。また、問題の資産やアプリケーションのベスト プラクティスに従って、DCM システムの構成の定義に定期的な更新を加えるようにするとよいでしょう。

まとめ
社内で開発するにしても、評判のよいベンダから購入するにしても、リスク管理ダッシュボードは非常に重要で、問題対応の主要なツールとなります。マルウェア対策も非常に重要で、日々倍増する脅威に対する保護を提供します。ネットワークの異常検出は、単なるマルウェアの署名やホストの侵入検出を超えて、データ漏洩の検出までも行えるところに来ています。また、データ漏洩の検出機能は、既知のネットワーク侵害の次の被害を防ぐうえでも有効です。望ましい構成の管理は、まだ新しい領域ですが、すぐに構成の監視と保守の主要ツールの 1 つとなるでしょう。これらのツールの提供元がどこであれ、各カテゴリにつき少なくとも 1 つのツールを装備する必要があります。
私たちが見た範囲では、4 つの領域すべてに対応できる包括的な単一のソリューションを提供しているベンダは (マイクロソフトも含めて) ありません。各自の要件に合わせて製品を選択してください。この記事が、検討する必要があることは何か、実現を図るべきことは何か、理想的なソリューションでは何が行われるかについて、洞察を提供するものになるよう祈っています。

Matt Claphamは、Microsoft IT 部門の Infrastructure and Security グループのセキュリティ エンジニアです。現職に就く前は、Microsoft Managed Solutions Risk Management and Compliance チームで 2 年間働いていました。
Todd Thompsonは、Microsoft IT 部門の Infrastructure and Security グループのセキュリティ エンジニアです。現職に就く前は、Microsoft Managed Solutions Risk Management and Compliance チームで 2 年間働いていました。


 セキュリティ: 証明書管理用の新しい強力なツール
セキュリティ Kevin Dallmann

証明書管理用の新しい強力なツール
概要:
  • ILM-CM のアーキテクチャ
  • 管理とテンプレート
  • ワークフローを作成する

想像してみてください。ある日、のんびりと仕事をしているところに、ヘルプ デスクのサポート チームから、運用システムで証明書の有効期限が切れたという問い合わせの電話がありました。現在、システムはダウンしており、証明書が更新されるまで、企業の生産性 (そして売り上げ) は失われたままです。
公開キー基盤 (PKI) 環境の管理者であれば、証明書の有効期限が突然切れたらきっと驚くでしょう。のんびりした 1 日も、今となっては夢と消えてしまいました。
Windows® 2000 と Windows Server® 2003 で PKI サービスが追加されたことにより、企業はコストをかけず簡単に、独自の PKI 環境を実装できるようになりました。残念なことに、Microsoft® PKI サービスでは、生成された証明書の有効期間を管理する機能は提供されませんでした。しかし、最近マイクロソフトは、証明書管理用の製品を買収し、Identity Lifecycle Manager (ILM) をリリースしました。この製品では、証明書管理機能と、Microsoft® Identity Integration Server (MIIS) で提供される ID のプロビジョニング機能と制御機能が組み合わされています。この記事では、組織の証明書とスマート カードの管理に ILM をどのように役立てることができるかについて説明します。

ILM-CM のアーキテクチャ
ILM Certificate Management (ILM-CM) のアーキテクチャの中核となるのは、ILM-CM サーバーと、その関連コンポーネントです (図 1 を参照)。ILM-CM サーバーは、1 つ以上の証明機関 (CA) と連携するように構成された、1 台のサーバーにインストールできます。また、ILM-CM には SQL Server™ をインストールする必要があります。SQL Server には、証明書の情報、ポリシー、および証明書環境の管理に使用されるその他のデータが格納されます。さらに、ユーザーとセキュリティ アクセス許可を管理するために、Active Directory® もインストールする必要があります。必要なコンポーネントとバージョンについては、図 2 を参照してください。
Figure 2 ILM-CM インフラストラクチャのサポート (Close Figure 2)

コンポーネント | バージョン
Active Directory | Windows Server 2003
データベース サーバー | SQL Server 2000 SP3 以降または SQL Server 2005
証明機関 | Windows Server 2003 Enterprise Edition または Data Center Edition
SMTP | SMTP サーバー
図 1 ILM-CM のアーキテクチャ
図 1 ILM-CM のアーキテクチャ
ILM-CM 環境のインストールが完了したら、その後の証明書の要求は、すべて ILM-CM サーバーに送信されます。ILM-CM サーバーは、証明書に関するすべての情報を SQL Server データベースに格納します。これらの情報は、証明書レポートの作成、警告、ワークフロー環境の保守などに使用できます。
ILM-CM のソフトウェア アーキテクチャは、大きく分けて、ILM-CM サーバー、CA プラグイン、およびクライアント側コンポーネントの 3 つから構成されます。サーバー ソフトウェアは、CA か、ILM-CM 専用のサーバーにインストールして実行できます。ILM-CM サーバーは、CA、SQL Server データベース、および Active Directory と通信します。このサーバーでは、Web ポータルも提供されます。証明書の管理者は、この Web ポータルで、証明書ポリシーと証明書ワークフローを構成できます。また、証明書のサブスクライバは、ソフトウェアの証明書を要求したり更新したりすることができます。
CA が ILM-CM サーバーと通信できるようにするには、管理するすべての CA に、ILM-CM のポリシー モジュールと終了モジュールをインストールして構成する必要があります。これら 2 つのモジュールは、証明書の情報をデータベースに記録するために使用されます。CA から証明書が発行されると、終了モジュールがその証明書の情報を ILM-CM サーバーに送信し、ILM-CM サーバーがその情報をデータベースに記録します。
環境内でスマート カードを管理する場合は、ILM-CM のスマート カード クライアント ソフトウェアをインストールする必要があります。このソフトウェアは、ILM-CM サーバーと通信する必要があるすべてのクライアント コンピュータにインストールする必要があります。

ILM-CM をインストールする
ILM-CM サーバーのインストールは非常に簡単な作業であり、ウィザードに従って完了することができます。しかし、実際にウィザードを実行する前に、いくつかの機能をあらかじめインストールしておく必要があります。
まず、ILM-CM には、Active Directory と ILM-CM スキーマ拡張が必要です。このスキーマ拡張により、ILM-CM がプロファイル テンプレートを実装するために必要な Microsoft .NET Framework のセキュリティ属性が追加されます。
また、.NET Framework 2.0 と、上記で説明したコンポーネント (SQL Server、CA、および SMTP サーバー) もインストールする必要があります。ILM-CM を CA とは別のサーバーにインストールする場合は、CA で ILM-CM のセットアップ ウィザードを実行して、CA に ILM-CM モジュールをインストールする必要があります。インストールが完了したら、ブラウザで http://hostname/CLM を参照することによって、ILM-CM のポータルに接続できます。
証明書の有効期限と更新に関する通知を有効にするには、ILM-CM サーバーで ILM-CM サービスを構成する必要があります。まず、Active Directory に適切なアカウントを作成します。次に、ILM-CM サービスのログオン アカウントとして、そのアカウントを追加します。その後、ILM-CM サーバー内のローカル管理者グループと IIS_WPG グループにそのユーザーを追加し、グループ ポリシーを使用して、"オペレーティング システムの一部として機能"、"セキュリティ監査の生成"、および "プロセス レベル トークンの置き換え" の特権をそのユーザーに割り当てます。ILM-CM サービスの構成が完了したら、ILM-CM サーバーは、SQL Server データベースをスキャンすることによって、有効期限が切れた証明書を検出し、証明書の所有者または管理者に電子メールで通知できるようになります。

ILM-CM の管理
ILM-CM は、Web インターフェイスを使用して管理します。このインターフェイスでは、ユーザー、証明書、およびスマート カードの管理タスクが、それぞれの機能領域にまとめられています。適切な管理者特権を使用して ILM-CM ポータルに接続すると、ILM-CM 環境の管理に使用できる、多くの管理タスクが表示されます (図 3 を参照)。[Common Tasks] (共通タスク) セクションでは、[Enrolling users for a new set of certificates or a smart card] (新しい証明書やスマート カードのユーザーを登録する) などの管理オプションが提供されます。また、要求を管理したり承認したりすることもできます。
図 3 ILM-CM 管理ポータルのタスク
図 3 ILM-CM 管理ポータルのタスク
ユーザーや証明書を検索する必要がある場合は、[Manage Users and Certificates] (ユーザーと証明書の管理) セクションを使用します。このセクションのタスクを使用すると、証明書の検索、復旧、失効、または更新操作を実行できます。また、失効リストの検索も実行できます。
組織でスマート カードを使用する場合、[Manage User Smart Cards] (ユーザーのスマート カードの管理) セクションが役立ちます。たとえば、あるユーザーがカードをロックした場合、証明書の管理者は、このセクションのタスクを使用して、そのカードのロックを解除できます。また、ローカル カード リーダーに挿入されているスマート カードを調べて、詳細情報を表示することもできます。
[Requests] (要求) セクションを使用すると、証明書の管理者は、ユーザーからの証明書の要求を確認および承認できます。たとえば、要求が保留状態になっているすべての証明書を表示することができます。[Administration] (管理) セクションでは、プロファイル テンプレートを作成および管理できます。最後に、[Reports] (レポート) セクションでは、ご想像のとおり、ユーザーと証明書に関連したレポートを作成できます。
ILM-CM ポータルの認証を受ける際、管理者特権を割り当てられていないアカウントを使用した場合、証明書ユーザー用のセルフサービス管理機能を提供する、サブスクライバ用のページが表示されます (図 4 を参照)。ユーザーは、このポータルから、適用されているポリシーの構成に基づいて、証明書とスマート カードを管理したり、それらの詳細情報を表示したりできます。共通タスクには、証明書やスマート カードの要求、既存の証明書の確認、スマート カードの PIN の変更などがあります。
図 4 ユーザーが各自で管理を行うための、サブスクライバ用ポータル ページ
図 4 ユーザーが各自で管理を行うための、サブスクライバ用ポータル ページ
証明書やスマート カードの発行、更新、置換、および失効操作を行うための、質の高い委任ワークフロー プロセスを提供することは、どの組織にとっても困難です。ILM-CM を使用すると、これらのタスクを委任して、高いセキュリティを保証できます。たとえば、スマート カードの PIN を忘れたユーザーがいるとします。ユーザーは、委任ワークフロー モデルを使用して、ヘルプ デスクのサポート ラインに問い合わせ、サポート スタッフからいくつか確認の質問を受けます。質問に正しく答えられた場合、サポート スタッフは、そのユーザーのスマート カードのブロックを解除します。委任ワークフローの例をもう 1 つ挙げると、ユーザーが暗号化ファイル システム (EFS) 証明書を誤って削除した場合や、ノート パソコンを紛失した場合に、その証明書を復旧するプロセスなどがあります。

プロファイル テンプレート
プロファイル テンプレートは、ILM-CM の完全なワークフロー管理プロセスを実現するための重要なコンポーネントです。プロファイル テンプレートは、1 つ以上の証明書テンプレートが含まれた、1 つの管理オブジェクトと見なされます。プロファイル テンプレートを作成および構成することにより、証明書環境で実行するワークフロー プロセスの動作を管理できます。プロファイル テンプレートの重要な特徴は、複数の証明書テンプレートを格納し、それらを 1 つのアイテムとして管理できるという点です。つまり、1 つのテンプレートで、証明書の有効期間中に、その証明書に関して行われる処理を追跡して、ユーザーを管理できるということです。
プロファイル テンプレートは、証明書をコンピュータ (ソフトウェア ベース) またはスマート カード (ハードウェア ベース) に格納するように構成できます。これらのテンプレートは、ILM-CM の管理者ポータルからサンプルを複製することによって作成できます。プロファイル テンプレート内では、いくつかの異なる管理ポリシー コンポーネントを定義できます (図 5 を参照)。
図 5 プロファイル テンプレート
図 5 プロファイル テンプレート
ポリシー コンポーネントの多くは、ソフトウェア プロファイルとスマート カード プロファイルの両方に適用できます (図 6 を参照)。ここでは、いくつかの役立つポリシーについて簡単に説明します。証明書の登録処理を行う場合、登録ポリシー コンポーネントを使用して、登録処理の流れを決定する特定の基準を定義できます。たとえば、データの収集処理を構成して、ユーザーに部門コード、電子メール アドレス、部長などの情報を入力させることができます。また、ユーザーが証明書を登録したときに、自動的に事務用の文書を印刷する定義を作成することもできます。
Figure 6 ソフトウェア プロファイル ポリシー (Close Figure 6)

コンポーネント | 説明
プロファイルの詳細 (Profile details) | プロファイル テンプレートの全般的な詳細情報を提供します。このポリシーでは、1 つ以上の証明書テンプレートをプロファイル テンプレートに追加できます。
複製ポリシー (Duplicate policy) | 既存の証明書のワークフロー エンティティを定義します。
登録ポリシー (Enroll policy) | 登録処理のワークフローを定義します。
オンライン更新ポリシー (Online update policy) | 更新ポリシー (Renew policy) と似ていますが、期限が切れる証明書、証明書の内容、テンプレート、およびスマート カードのアプレットを更新できる点が異なります。
代理復旧ポリシー (Recover on behalf policy) | ユーザーの秘密キーや証明書を復旧します。
更新ポリシー (Renew policy) | 証明書の有効期限が切れたときに使用する、更新ワークフローを定義します。
再有効化ポリシー (Reinstate policy) | 証明書を再度有効にするためのプロセスを定義します。
復旧ポリシー (Recover policy) | コンピュータに格納されているユーザー証明書が削除されたか、そのコンピュータが再構築されたり盗まれたりした場合に使用する、証明書を復旧するためのワークフローを定義します。
失効ポリシー (Revoke policy) | プロファイル内のすべての証明書を失効させるためのワークフローを定義します。
オンライン更新ポリシーは、組織にとって非常に役立ちます。このポリシーは更新ポリシーと似ていますが、証明書の内容、証明書テンプレート、スマート カード上のアプレット、および有効期限が近付いた証明書を更新できる点が異なります。このポリシーを十分に活用するには、複数の値を持つ Active Directory の属性にアクセスできるように、ILM-CM サービスを有効にし、web.config ファイルを構成する必要があります。また、クライアント コンピュータにオンライン更新サービスをインストールする必要があります。
代理復旧ポリシーは、企業で EFS 暗号化を使用している場合に役立つ可能性があります。たとえば、あるユーザーが、誤って暗号化証明書を削除したとします。この場合、代理復旧ポリシー コンポーネントを使用して、ヘルプ デスクのセキュリティ チームがそのユーザーの秘密キーを要求するワークフローを構成できます。次に、ユーザーは、ILM-CM サーバーが生成した秘密のパスワードを含む電子メールを受信することによって、秘密キーを入手できます。その後、ILM-CM サーバー上の秘密の Web リンクにアクセスし、証明書に関連付けられた秘密キーを使用して、その証明書を取得できます。代理復旧ポリシーは、退職した従業員のデータを、アーカイブ、規制遵守、またはその他の目的で復旧する必要がある場合にも役立ちます。
より安全な更新処理を提供するには、更新ポリシーを使用します。このポリシーを使用すると、ユーザーが証明書を更新するために必要な秘密キーを、1 回限り有効なパスワードを使用してアクセスするように構成して、電子メールで送信することができます。また、一度失効させた証明書を再度有効にして、その証明書を証明書失効リスト (CRL) から削除する必要がある場合は、再有効化ポリシーを使用して、その処理のワークフロー プロセスを定義できます。
スマート カードには関連付けられていない、ソフトウェア固有の証明書ポリシー コンポーネントとして、復旧ポリシーと破棄ポリシーがあります。コンピュータに格納されたユーザーの証明書が削除されたか、コンピュータ自体が再構築されたり盗まれたりした場合、復旧ポリシーを使用して、CA にアーカイブされている証明書やキーを復元するためのプロセスを定義できます。失効ポリシーを使用すると、管理者は、失効させる理由を設定して、常にその理由を使用するか、失効操作を要求したユーザーが、証明書を失効させるときに理由を指定できるようにすることができます。
スマート カード プロファイル テンプレートに固有の管理ポリシーとして、さらに 5 つのポリシーがあります (図 7 を参照)。
Figure 7 スマート カード プロファイル ポリシー (Close Figure 7)

コンポーネント | 説明
置換ポリシー (Replace policy) | ユーザーがスマート カードを紛失したり盗まれたりした場合のプロファイルを定義します。
無効化ポリシー (Disable policy) | 有効期限が切れていないスマート カード上の証明書を無効にするためのプロセスを定義します。
廃棄ポリシー (Retire policy) | スマート カード上のすべての証明書を失効させるためのプロセスを定義します。
ブロック解除ポリシー (Unblock policy) | スマート カードのユーザー PIN のブロックを解除できるユーザーを定義します。
一時カードポリシー (Temporary cards policy) | 一時的に使用する代用のスマート カードを定義します。ユーザーが受け取るのは新しい署名証明書ですが、既存のプロファイルの暗号化証明書を入手することによって、データを復号化することができます。
廃棄ポリシーには、さまざまな操作を定義できます。たとえば、スマート カード上のユーザー データを消去したり、ユーザーと管理者の PIN をブロックしたり、管理者の PIN をリセットしたりすることができます。ブロック解除ポリシーは、通常、ユーザーが PIN を忘れたときや、ILM-CM によって PIN が割り当てられた新しいカードが出荷された場合に使用します。このポリシーを使用すると、ユーザーは、スマート カードのブロックの解除を要求できます。
どんな管理用製品でも、レポート作成機能は非常に役立ちます。証明書環境やスマート カード環境の特定の時点の状態を捕捉する機能は、どの組織にとっても非常に重要です。ILM-CM では、スマート カード インベントリ、要求の概要、証明書の用途と有効期限などが含まれた、組み込みのレポートが提供されます。すべてのデータは SQL Server データベースに格納されているため、他のレポート作成システムと同様、追加のレポートを作成する必要がある場合は、カスタム クエリを記述することができます。

ワークフローを作成する
ここでは、生産的なワークフロー プロセスを定義するために、ILM-CM をどのように役立てることができるかについて説明します。たとえば、複数のシステム管理者が、システムで使用する SSL 証明書の管理と保守を担当しているとします。まず、最初に確認する必要があることは、定義するワークフロー プロセスの主な特性です。
システムの種類が異なる場合、ワークフロー プロセスでは、異なる方法を使用して証明書の要求ファイルを作成することが必要になる場合があります。このため、最初の作業は、イントラネット ページを作成し、証明書の要求を作成するための詳細な手順を、システムごとに提供することです。
管理者は、要求ファイルを作成したら、そのファイルを、証明書の承認を行う ILM-CM のユーザー ポータルに送信することができます。管理者は、ILM-CM のワークフロー プロセスを使用して、証明書の要求を確認および承認する何人かの承認者を定義できます。証明書が承認された後、ユーザーは ILM-CM から証明書を取得できます。ILM-CM は、証明書に関する情報を SQL Server データベースに格納するため、管理者は情報の履歴を取得できます。
1 年後、証明書の有効期限が近付いたら、ILM-CM は要求者に電子メールを送信し、証明書の有効期限が近付いており、証明書を更新する必要があることを通知します。このワークフロー プロセスを適切に導入すれば、証明書の有効期限が突然切れて、1 日を無駄にしてしまうこともなくなります。

まとめ
企業で Microsoft PKI 環境を使用している場合、その環境の管理に ILM-CM を役立てることができます。組織は、ILM-CM を使用すると、セキュリティ認証処理を強化し、デジタル証明書やスマート カードの管理にかかるコストや複雑さを軽減できるようになります。また、ILM-CM を基盤として、今日の多くの企業に欠けている、証明書とスマート カードに関するワークフロー プロセスを作成することもできます。
マイクロソフトは、ILM-CM 用の外部 API のサポートも実装しました。組織でカスタム アプリケーションを使用する場合、それらのアプリケーションにインターフェイスを追加して、ILM-CM API のサポートを活用できる可能性があります。
ILM-CM の詳細については、microsoft.com/technet/clm を参照してください。また、go.microsoft.com/fwlink/?LinkId=87336 で提供されている、クイック スタート ガイドも参照してください。

Kevin Dallmannは、Accenture のシニア システム エンジニア コンサルタントであり、主に大規模な企業環境の Active Directory および PKI 環境の支援を担当しています。Kevin は MCSE と MCT 認定資格を取得しており、マイクロソフト コースでの指導も行っています。


 編集者から: セキュリティに関する問題
編集者から
セキュリティに関する問題
Joshua Trupin

セキュリティ上の注意事項 の管理が最近どれくらい容易になっているのかをご存知ですか。ええ、TechNet Magazine のこの場所で、私たちはそれをすべて自分たちの手柄にしてしまおうと考えているのです。でも、このことに関わるいくつか他の要因があります。そのうちの 2 つの最大の要因は、認識と堅牢性です。
認識とは、単に潜在的な脅威とソーシャル エンジニアリングのトリックに注目することです。また、インストール済みのソフトウェアを保護する通常の修正プログラムや更新プログラムをきちんと把握します。堅牢性とは、別の見方のことです。つまり、危険にさらされている機能を既定で無効にすることによって、より一層セキュリティで保護され、攻撃面を最小限に抑えたソフトウェアを構築するアイディアのことです。
ああ、それからもう 1 つ別の要因があります。それは、定期的に TechNet Magazine を読むことです。このことをお忘れなく。今月号はセキュリティ特集です。7 個以上の記事で、会社のために優れたセキュリティ アナリストやセキュリティ専門家になるのに役立つ情報を提供しています。たとえば、Mark Russinovich が UAC の内部情報について初めて取り上げています。Steve Riley が Windows ファイアウォールに取り組んでいて、Jesper Johansson が Windows Vista での ACL の変更点について説明しています。また、Jeremy Moskowitz がグループ ポリシーとハードウェア ロックダウンについて取り上げ、Michael Murgolo がスクリプトによる昇格を行う PowerToys を提供しています。この他にもいろいろあります。まじめな話、今月号は、これまでに出されたどんな雑誌よりもすばらしいと言っても過言ではないでしょう。
集中力を保ちつつ、マイクロソフトからのセキュリティに関する最新の提供物を把握しておいてください。Microsoft Forefront は、"堅牢性" という要因を表すもので、3 つの分野に保護を提供する基幹業務セキュリティ製品です。この 3 つの分野とは、クライアント オペレーティング システム、アプリケーション サーバー、およびネットワーク エッジを指します。Microsoft Forefront には、Exchange Server と SharePoint 用のセキュリティ ツールが含まれているだけでなく、ネットワーク トラフィックに対処するために ISA Server と Intelligent Application Gateway が組み込まれています。Microsoft System Center は "認識" というパズルのピースを含んでいます。これにより、システムに関する知識の収集、運用や管理の合理化、レポートの生成、サービス提供の向上を実現できます。また、次世代の構成管理や運用監視のテクノロジも含まれています。
Forefront と System Center の詳細については、Microsoft インフラストラクチャ サイト (Microsoft.com/infrastructure) をご覧ください。セキュリティ パズルの上位のソリューションを取得するには、TechNet Magazine を読んで認識と堅牢性を保ってください。
—Joshua Trupin

次のマイクロソフト技術支援スタッフに心より感謝します。Conrad Bayer、David Cross、Michael Dennis、Shon Eizenhoefer、Jason Garms、Russ Humphries、Jesper Johansson、John Lambert、Eric Perlin、Mark Russinovich、Jon Schwartz、David Solomon、Greg Stemp、John Stephens、Kevin Sullivan、Jim Truher、Buck Woody


 ツールボックス: IT プロのための新製品
ツールボックス IT プロのための新製品 and Greg Steen
myLittleAdmin はスキンで外観を変更可能なインターフェイスを採用している
新規データベースの作成、既存データベースおよびそのコンテンツの管理、スナップショットやスキーマの操作など、多くのデータベース操作を Web ベースの UI でサポートします。既存のデータベース オブジェクトのプロパティも簡単に編集可能であり、テーブルの個々の行を変更するための優れた編集可能データ グリッドが用意されています。ツリー表示のインターフェイスは SQL Server Management Studio のツリー表示と同様であるため、アプリケーションを習得する手間が省けます。良くない点といえば、右クリックしてもお馴染みのコンテキスト メニューが表示されないということぐらいです。
myLittleAdmin には、ログイン、サーバーの役割、SQL インスタンスの資格情報を編集する機能もあります。また、バックアップ デバイスやリンク サーバーの作成や編集も可能です。これは、リモートから実行可能な便利なタスクです。
myLittleAdmin では、アドホック クエリ、データベースの接続および切断、バックアップおよび復元、CSV データのインポート、データベースの縮小などの操作も可能です。エラー ログやアクティビティ モニタを参照してトラブルシューティングを行うこともできます。
価格 : 1 サーバー ライセンス 590 ドル～、顧客向けの Web ホスティング ツールセットへの組み込み版 1 サーバー ライセンス 990 ドル


 SQL に関する Q&amp;A: 64 ビット インストール、クラスタ メモリの割り当てなど
SQL に関する Q&A 64 ビット インストール、クラスタ メモリの割り当てなど and Nancy Michell
図 1Windows Live での SQL Server Books Online 検索
しかし、SQL Server が 1 つのサーバー上にすべての RAM を持ち、SQL Server の新規インスタンスが開始するとします。元の SQL Server インスタンスのメモリはどうなるでしょうか。最悪のシナリオについて計画する必要があると思われます。つまり、1 つのノードのみ稼働し、SQL Server のすべてのインスタンスがそのノードで実行される場合です。
回答 - 一般には、最大サーバー メモリ値をマシンで使用可能な合計メモリよりも少なく設定するのが最適だという意見に賛成です。ただし、合計メモリ値の 3 分の 1 がこの状況で最適な構成だというのは疑問です。
クラスタ内の 4 つのサーバーのうち 3 つが同時にダウンし、3 つの SQL Server インスタンスが最終的に 4 つ目のノードで稼働することを心配されているようですが、このようなシナリオはめったに発生しません。
大半のケースでは、各ノードで使用可能なメモリを最大限に利用するように各インスタンスを構成する方がよいと思われます。各ノードに 32 GB の RAM があるとしましょう。最大サーバー メモリを、各インスタンスについて 28 GB などに設定するのが妥当です。
これで、ノード障害が発生した場合に、そのノードで実行されているインスタンスはパッシブ ノードにフェールオーバーし、28 GB のメモリにアクセスできる可能性があります。他の 2 つのインスタンスは影響を受けず、クラスタ内の他の 2 つのノードで稼働を続けます。
5 つの SQL Server インスタンスと 1 つの Analysis Services インスタンスがある 4 ノードのフェールオーバー クラスタについて言及されています。SQL Server 2000 を Address Windowing Extensions (AWE) と共に実行している場合、リレーショナル エンジン インスタンスは取得したメモリを解放しないため、これらのインスタンスには慎重に選択したメモリ容量を設定する必要があります。AWE を使用しても使用しなくても、広大なアドレス空間にアクセスできる、より柔軟な SQL Server 2005 と 64 ビット インスタンスの状況では話が別です。この状況では AWE を使用している場合でも、メモリ割り当ては動的であり、要求時にメモリを解放できます。このため、ボックス上で新規インスタンスが起動するフェールオーバーの状況で、元の SQL Server インスタンスおよびそのインスタンスが獲得したメモリがどうなるかという質問に対する回答は、SQL Server 2000 と SQL Server 2005 のどちらを実行しているか、また AWE を使用しているかどうかによって異なります。
最悪のシナリオについて計画することは、原則的にはよい考えですが、現実の問題としては、システムの設計が本当に極端でない限り、5 つの SQL Server リレーショナル エンジン インスタンスと 1 つの Analysis Services インスタンスを実行しているクラスタで 4 つのノードのうち 3 つがダウンすることはめったにありません。残りのノードは、同等のパフォーマンス レベルで元のインスタンスを処理するのに十分な CPU リソースを持ちません。その場合は、一般に、1 つのノードが失われても最適なパフォーマンスを維持するようなソリューションを設計する方が適切ですが、複数のノードが失われた場合には若干の手動介入が必要になることがあります。これにより、高価なリソースを適正に利用しながら、高可用性 (HA) サポートを提供することができます。
最後に、SQL Server 2005 では、エンド ユーザーは実際にはクラスタを 8 つのノードにまで拡張できます。SQL Server 2000 では、4 ノード クラスタが最大でした。

ミラーリングの制限
質問 - SQL Server 2005 データベース ミラーリングについて読んだところ、データベース ミラーリングではサーバー インスタンスあたり最大 10 個のデータベースしかサポートできないことがわかりました。別々のストレージを持つ 2 つの異なる SQL Server インスタンス、2 つのインスタンス間の自動フェールオーバー、およびデータの冗長性という要件があります。
ピアツーピア (P2P) SQL Server 2005 トランザクション レプリケーションを Microsoft® Cluster Server (MSCS) と組み合わせて使用することを計画していました。その場合、2 つのノードの 1 つをソースとするクラスタ IP があるため、すべての挿入、更新、削除、および読み取りトラフィックはクラスタ内の単一のノードに送られます。セカンダリ ノードをパッシブとして扱いますが、そのノードにはトランザクションがレプリケートされます。障害発生時に、MSCS はその IP を他のノードにフェールオーバーし、その IP は P2P および双方向として構成されているため、他のノードへのトランザクションのパブリッシュを開始するための手動プロセスはありません (バックアップ後)。MSCS 内で Majority Node Set (MNS) 構成を使用して、クォーラムの共有ディスク リソースの必要性を軽減します。
ミラーリング オプションはテーブルにまだ存在します。SQL Server クラスタあたり 1000 ～ 100 個のデータベースを削除しました。それでも、システムにその種類のリソース負荷がかかりますか。
回答 - SQL Server ミラーリングに関する情報とガイダンスについては、microsoft.com/technet/prodtechnol/sql の BOL または SQL Server Tech Center、および msdn2.microsoft.com/sql を参照してください。
この質問は多くの議論を引き起こしました。冗談はさておき、質問者のシナリオについて最適な回答を次に示します。
回答番号 1: 特定のインスタンスでミラーリングできるデータベース数に制限はありません。インスタンスあたり 10 個以下のデータベースをミラーリングするのがベスト プラクティスであるという記事をご覧になったのだと推測しますが、これは単なる概数であり、特に制限は設けられていません。すべては、ある特定のシステムで使用可能なリソースに依存します。
ミラーリングはオプションですが、非常に強力なサーバーがない限り、1,000 個のデータベースがあると確実に過負荷になります。共有ストレージを使用せず、組み込みの SQL Server テクノロジを使用する場合は、ミラーリング、ログ配布、またはレプリケーションを試すことができます。それぞれ賛否両論があります。
回答番号 2: 共有ストレージを使用しない大量のデータベースがあり、Microsoft が提供している障害回復ソリューションを使用する場合は、管理のオーバーヘッドを軽減する一連の小さなカスタム ヘルパ プログラムを使用してログ配布を調査する必要があります。プログラムは各データベースを順番にバックアップおよび復元できるため、複数のログ配布エージェントを実行する必要はなくなります。これにはある程度データ消失の可能性があることに注意してください。データ消失を防ぐために共有ストレージと DBMS のどちらも必要としない組み込みソリューションはありません。
もちろん、MSCS が検出とフェールオーバーを行う方法について問題があります。クラスタ内の MNS 構成は、通常は共有ストレージの必要性を完全に排除せず、クォーラム専用の共有 LUN を使用する必要性をなくします。計画が機能するのは、クラスタが IP とネットワーク名以外には何も管理しないように構成されている場合だけです。SQL Server は、共有ストレージがないとクラスタ化できないため、SQL サービスをクラスタ化することはできません。これは、クラスタが通常の構成の SQL Server サービスを検出および監視できないことを意味します。
SQL Server サービスは、監視対象の汎用サービスとして追加することでクラスタ化できますが、フェールオーバーで問題が生じます。サービスがクラスタ化されている場合、MSCS はフェールオーバー時にパッシブ ノードでサービスをオンラインにしようとしますが、一部の SQL サービスは既にそのノードで実行されています。もちろん、これを使用して IP とネットワーク名を単純にクラスタ化し、必要に応じて手動でフェールオーバーできます。ネットワーク負荷分散 (NLB) を使用して同じ処理を行うことができます。これは他の場所で行われます。詳細については、microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx の記事を参照してください。
サポートしようとしているデータベースが複数ある場合は、ログ配布ソリューションがより適切に機能します。もちろん、Data Transformation Services/SQL Server Integration Services (DTS/SSIS) パッケージを使用してプロセスを自動化する必要があります。そうしないと、手動バックアップ、移動、および障害時のアクティブ ログの適用に長い時間がかかる可能性があります。

次の Microsoft IT 技術支援スタッフに心より感謝します。Boris Baryshnikov、Chad Boyd、Alan Doby、Patrick Gallucci、Cindy Gross、Chuck Ladd、Pat Martin、Vipul Shah、Nelson Taggart、Kartik Tamhane、Ken Tanner、Chuck Timon、George Walters、Kevin Warren、そしてとりわけ Buck Woody。


 ユーティリティ スポットライト: Windows Vista 用のスクリプト昇格 PowerToy
ユーティリティ スポットライト Windows Vista 用のスクリプト昇格 PowerToy and Michael Murgolo
この記事で使用しているコードのダウンロード: Utility2007_06.exe (159KB)
ユーザー アカウント制御によりセキュリティは大幅に強化されますが、特定の管理者タスクおよび機能を実行するには特権の昇格機能が不可欠です。この記事では、昇格の柔軟性と機能を高める "昇格 PowerToy" を紹介します。
セキュリティの問題に対処するために Windows Vista に導入されている多くの機能の中でも、ユーザー アカウント制御 (UAC) は特に重要です。ユーザー アカウント制御では、管理者ユーザーも多くのアプリケーションを標準権限で実行しますが、一定の管理タスクやアプリケーション機能を実行するための "昇格の可能性" を
持っています。Windows Vista™ を使い慣れてくると、必要に応じてタスクやアプリケーションを昇格する習慣が身に付きます。しかし、筆者は、Windows Vista で一部のタスクを昇格しようとしたときにいくつかの難点に遭遇し、フラストレーションを感じました。
そこで、旧来の Windows® PowerToys の精神に則って、いくつかのスクリプト昇格 PowerToy を作成してその制約を克服しました。これから説明する PowerToy のコードはすべて technetmagazine.com/code07.aspx からダウンロード可能です。UAC のしくみについては、Alex Heaton による 2006 年 11 月の記事「ユーザー アカウント制御を使用して、管理者以外のユーザーの夢を実現する」(補足記事の「参考資料」を参照) をご覧ください。

昇格コマンド PowerToy
最初に困ったことは、アプリケーションをコマンド ラインや [ファイル名を指定して実行] ダイアログ ボックスで昇格する方法がなかったことです。Microsoft の社内でたずね回った後、筆者は John Stephens (Microsoft のソフトウェア デザイン エンジニア) のサンプル スクリプトにめぐり逢い、このスクリプトから必要な情報を得ることができました。ShellExecute API またはこれに相当する COM オブジェクトである Shell.Application の ShellExecute メソッドに "runas" 動詞を渡すと、起動したアプリケーションは、昇格するかどうかをユーザーに確認するようになります (詳細については、補足記事を参照)。この機能を使って、昇格コマンド PowerToy という最初の昇格 PowerToy を作成することができました。
ElevateCommand.inf、elevate.cmd、elevate.vbs の各ファイルで構成されるこのツールは、システムに昇格コマンドを追加します。このコマンドを使って、昇格の確認を要求するアプリケーションをコマンド ライン、スクリプト、または [ファイル名を指定して実行] ダイアログから起動することができます。たとえば、次のコマンドを実行すると、昇格するかどうかを確認した後、メモ帳で Win.ini を開きます。
elevate notepad c:\Windows\Win.ini
この昇格コマンドを Windows Script Host (WSH) や Windows PowerShell™ などのスクリプトで使用するときは、スクリプト ホストの実行可能ファイル (wscript、cscript、powershell など) をアプリケーションとして指定する必要があります。たとえば、vbs を実行するには、次のようにします。
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
図 2昇格された権限のプロンプト

インストールと実装
これらの PowerToy をインストールするには、INF ファイルを右クリックし、[インストール] を選択して、昇格を承認します。アンインストールするには、コントロール パネルで [プログラムと機能] を選択します。
INF ファイルの内容を調べて、なぜ 3 つの PowerToy で elevate.cmd および elevate.vbs を異なる場所にインストールするのかという疑問を持たれる方もいらっしゃると思うので、説明しておきます。多くの PowerToy は、レジストリの該当するオブジェクトの種類の HKEY_CLASSES_ROOT\objecttype\Shell キーに runas サブキーを追加して実装しています。
ただし、一部の PowerToy には、オブジェクトの種類によって昇格を伴う 2 つのコンテキスト メニュー エントリに分けたいと思うものがありました (たとえば、オブジェクトの種類が [ドライブ] または [ディレクトリ] の場合は [CMD Prompt Here as Administrator] (管理者としてコマンド プロンプトを開く) および [PowerShell Prompt Here as Administrator] (管理者として PowerShell プロンプトを開く) を使用し、すべての WSH オブジェクトに対しては [管理者として実行] および [Run as Administrator with Command Prompt] (管理者としてコマンド プロンプトを実行) を使用するというように)。オブジェクトの種類ごとに runas キーは 1 つしか存在しないため、elevate コマンドを呼び出して別のアクションを実装する必要がありました。しかし、各 INF を個別にインストールおよびアンインストールできるようにしたかったので、関連付けられた elevate.cmd および elevate.vbs を別の場所に保存しなければならなくなりました (ファイルの使用カウンタを未加工の INF ファイルからインクリメントすることはできません。それなら MSI インストーラを使えばいいだろうと思われるかもしれませんが、筆者はテキスト エディタで作成および変更が可能なインストーラが欲しかったのです)。この場合の 1 つの難点は、runas キーを使用して実装したコンテキスト メニュー エントリ以外はメニューに盾のアイコンが表示されないということです。

まとめ
今回紹介したツールが役立ち、UAC の操作性が向上することを願っています。そうなれば、あなたも自作の PowerToy を作りたいと思うようになるでしょう (Windows Vista 上で Perl や Python などのスクリプト言語を使用する場合も、その言語の "昇格スクリプト" PowerToy を簡単に作成できるはずです)。他のすべての PowerToy と同様、これらのツールにはサポートはなく、各自の責任でご使用いただくことになります。何はともあれ、昇格をご堪能ください。
参考資料
  • ユーザー アカウント制御を使用して、管理者以外のユーザーの夢を実現する
  • ユーザー アカウント制御の概要
  • ShellExecute による昇格
  • ShellExecute メソッド
  • 動詞とファイルの関連付け
  • 古い PowerToy が新しく蘇える


 The Cable Guy: Secure Socket トンネリング プロトコル
The Cable Guy Secure Socket トンネリング プロトコル and Joseph Davies
このコラムは、Windows Server のコードネーム "Longhorn" のプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。
Windows XP および Windows Server 2003 の VPN プロトコルは、一部の構成には対応していません。この記事では、これらの問題について詳しく説明し、Windows Server "Longhorn" および Windows Vista Service Pack 1 で Secure Socket トンネリング プロトコルを使用してこれらの問題を解決する方法について説明します。
Windows XP および Windows Server 2003 では、仮想プライベート ネットワーク (VPN) がサポートされているため、コンピュータがローカル イーサネット ポートに接続されているかのように、インターネット経由でプライベート イントラネットに接続することができます。ただし、Windows XP および Windows Server 2003 の VPN プロトコルは、一部のファイアウォール構成には対応しておらず、
一部の間接的な構成 (コンピュータがネットワーク アドレス変換器 (NAT) や Web プロキシ サーバーの内側に配置されている場合など) にも対応していません。これらの構成では、VPN 接続のトラフィックがブロックされます。このような問題を解決するために、Windows Server ® の次のバージョンであるコードネーム "Longhorn" と、Windows Vista™ Service Pack 1 (どちらも現在はベータ テスト段階です) では、新しい Secure Socket トンネリング プロトコル (SSTP) がサポートされます。

VPN アクセスの問題
Windows® XP と Windows Server 2003 では、インターネットを経由してイントラネットにリモート接続するための VPN プロトコルとして、Point-to-Point トンネリング プロトコル (PPTP) と、インターネット プロトコル セキュリティを使用したレイヤ 2 トンネリング プロトコル (L2TP/IPsec) を使用します。これらのプロトコルでは、リモート アクセス クライアントとそのクライアントが接続されているイントラネットとの間で送信されるパケットをカプセル化することができます。
PPTP ベースの VPN トラフィックは、トンネルのメンテナンスを行うための、VPN サーバー上の TCP ポート 1723 への TCP 接続と、Generic Routing Encapsulation (GRE) を使用してカプセル化された VPN データ パケットから構成されています。しかし、PPTP トラフィックを使用すると、ファイアウォール、NAT、および Web プロキシの通過に関する問題が発生することがあります。これらの問題を回避するには、TCP 接続と、GRE を使用してカプセル化されたデータの両方を許可するようにファイアウォールを構成する必要があります。GRE は、IP パケットをカプセル化するための標準的な方法ですが、多くのインターネット サービス プロバイダ (ISP) ではこれらのパケットをブロックしてしまうため、データの損失が発生します。また、ホテルや喫茶店で利用できる接続は、通常、標準的な Web トラフィックや電子メール トラフィック用に構成されており、PPTP トラフィックを許可しない場合があります。さらに、コンピュータが NAT の内側に配置されている場合、その NAT は GRE トラフィックを変換できる必要があります。NAT が GRE トラフィックを変換できない場合、TCP 接続は確立できますが、GRE を使用してカプセル化されたデータを送受信することはできません。最後に、PPTP トラフィックは、Web プロキシを通過することができません。
Windows XP と Windows Server 2003 で使用されるもう 1 つの VPN プロトコルである L2TP/IPsec は、インターネット キー交換 (IKE) を使用して、IPsec カプセル化セキュリティ ペイロード (ESP) による VPN トラフィックの保護をネゴシエートしますが、このプロトコルでも、ファイアウォール、NAT、および Web プロキシの通過に関する問題が発生することがあります。
このプロトコルを使用する場合、IKE トラフィックと ESP を使用してカプセル化されたデータの両方を許可するように、ファイアウォールを構成する必要があります。VPN クライアント コンピュータが NAT の内側に配置されている場合、VPN クライアントと VPN サーバーの両方で IPsec NAT-Traversal (NAT-T) がサポートされている必要があります。ただし、VPN サーバーを NAT の内側に配置することはできません。また、L2TP/IPsec トラフィックが Web プロキシを通過することはできません。

新しい VPN ソリューション
ここまでの説明からわかるように、Windows XP や Windows Server 2003 で VPN プロトコルを使用した操作を行う場合、多くの問題があります。すばらしいことに、Windows Vista Service Pack 1 と Windows Server "Longhorn" の SSTP では、HTTP over SSL (Secure Sockets Layer) を使用することにより、VPN 接続に関するこれらの問題が解決されます。SSL はトランスポート層セキュリティ (TLS) とも呼ばれます。TCP ポート 443 を使用する HTTP over SSL は、Web 上でクレジット カード番号やその他の個人データを収集するために使用されているプロトコルです。https: で始まる Web アドレスに接続するときは、必ず HTTP over SSL が使用されます。
HTTP over SSL を使用すると、VPN プロトコルの接続に関する多くの問題が解決されます。HTTP over SSL トラフィックは広く利用されているため、通常のファイアウォール、NAT、および Web プロキシでは、このトラフィックが許可されます。
SSTP は、VPN クライアントと VPN サーバーとの間で HTTP over SSL セッションを使用して、カプセル化された IPv4 パケットまたは IPv6 パケットを交換します。HTTP over SSL ベースのリモート アクセス VPN 接続は、HTTP over SSL を使用するアプリケーションによって確立される接続とは異なることに注意してください。たとえば、Outlook® Web Access (OWA) を使用すると、インターネット経由で企業の Microsoft Exchange 電子メールにアクセスすることができます。OWA では、HTTP over SSL によって暗号化されたセッションが使用されますが、このセッションはリモート アクセス接続とは異なります。OWA を使用すると、電子メールを表示することはできますが、Exchange 電子メール メッセージ内に埋め込まれているイントラネット URL によって指定された場所にアクセスすることはできません。
SSTP では、認証を使用する Web プロキシの構成はサポートされていません。認証を使用する Web プロキシの構成では、HTTP Connect 要求中に認証が実行されます。
Windows で HTTP over SSL を実装すると、リモート アクセス ソリューションを維持するためのコストが大幅に削減されます。たとえば、HTTP over SSL を使用すると、ヘルプ デスクのサポートを必要とする問題の数が減少します。また、VPN サーバーが NAT の内側に配置されていることが原因で問題が発生することもなくなります。さらに、SSTP は、ほぼすべての場所に対応しているため、ユーザーの満足度と生産性が向上します。
SSTP は Windows に組み込まれているので、クライアント コンピュータ上にサードパーティ製の VPN クライアント ソフトウェアをインストールして管理したり、VPN サーバーにソフトウェアを追加でインストールしたりする必要はありません。また、SSTP は、SSL 負荷分散装置を使用できるため、VPN 接続の負荷分散を促進することができます。
新しい SSTP の機能
  • SSTP には、ネットワーク アクセス保護 (NAP) のサポートが組み込まれています。NAP を使用すると、システムの正常性に関する要件への準拠を義務付けることができるため、ネットワーク資産の保護を強化することができます。NAP の詳細については、microsoft.com/nap を参照してください。
  • また、SSTP では、SSTP トンネル内で送信されるネイティブの IPv6 トラフィックと、IPv6 インターネットを経由した、IPv6 ベースの SSTP 接続がサポートされています。
  • さらに、SSTP では、SSTP クライアントから SSTP サーバーへの HTTP over SSL セッションが 1 つのみ確立されます。サードパーティから提供されている、他の SSL ベースの VPN ソリューションでは、2 つの HTTP over SSL セッションが使用されます。使用する HTTP over SSL セッションを単一化することにより、ネットワーク使用率が低下し、負荷分散が促進されます。
  • 最後に、SSTP は、Windows Vista Service Pack 1 と Windows Server "Longhorn" の VPN クライアント コンポーネント、および Windows Server "Longhorn" のルーティングとリモート アクセスと完全に統合されています。新たな VPN プロトコルである SSTP は、PPTP ベースまたは L2TP/Ipsec ベースの接続と同じ認証プロトコルと構成方法 ([ネットワーク接続] フォルダや接続マネージャなど) を使用できます。
Windows XP や Windows Server 2003 の PPTP プロトコルまたは L2TP/IPsec プロトコルとは異なり、SSTP ではサイト間の VPN 接続はサポートされていません。

Windows における SSTP
Windows Server "Longhorn"、およびルーティングとリモート アクセスを実行しているコンピュータは、SSTP ベースの VPN サーバーとして機能します。ルーティングとリモート アクセスは、/sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/ という特定の Uniform Resource Identifier (URI) で接続をリッスンするため、IIS をインストールする必要はありません。ただし、ルーティングとリモート アクセスと IIS を同じサーバー上で共存させることは可能です。
Windows Vista (今年の後半にリリースを予定している Service Pack 1 では、強化された機能が提供されます) または Windows Server "Longhorn" を実行しているコンピュータは、SSTP ベースの VPN クライアントとして、SSTP ベースの VPN サーバーへの SSTP 接続を開始することができます。SSTP サーバーには、サーバー認証プロパティまたは汎用的な拡張キー使用法 (EKU) プロパティが含まれたコンピュータ証明書をインストールする必要があります。このコンピュータ証明書は、SSL セッションを確立するときに、SSTP クライアントが SSTP サーバーを認証するために使用します。SSTP クライアントは、SSTP サーバーのコンピュータ証明書を検証します。コンピュータ証明書を信頼するには、SSTP サーバーのコンピュータ証明書を発行する証明機関 (CA) のルート CA が、SSTP クライアントにインストールされている必要があります。
図 1 では、Windows Server "Longhorn" および Windows Vista Service Pack 1 の各種 VPN プロトコルの属性を比較しています。また、補足記事「新しい SSTP の機能」には、SSTP の機能に関する説明が記載されています。
Figure 1 各種 VPN プロトコルの比較 (Close Figure 1)
図 2SSTP パケットの構造
まず、IPv4 パケットまたは IPv6 パケットが、PPP ヘッダーと SSTP ヘッダーでカプセル化されます。SSL セッションでは、IPv4 パケットまたは IPv6 パケット、PPP ヘッダー、および SSTP ヘッダーを組み合わせたデータがカプセル化されます。TCP ヘッダーと IPv4 ヘッダー (IPv4 インターネット経由の SSTP 接続用) または IPv6 ヘッダー (IPv6 インターネット経由の SSTP 接続用) が追加され、パケットが完成します。
SSTP の詳細については、ルーティングとリモート アクセスのブログ (blogs.technet.com/rrasblog) を参照してください。


 Windows PowerShell: Active Directory を操作する
Windows PowerShell Active Directory を操作する and Don Jones Windows PowerShell は、Get-ADSIObject コマンドレットを提供していませんが、それが理由で強力な ADSI サポートを提供できないということはありません。ここでは、型アダプタの概要を説明し、Windows PowerShell を使用してディレクトリ オブジェクトを操作する方法を学習します。
Windows PowerShell を少しでも扱ったことがあるのなら、Get-WMIObject コマンドレット (その便利なエイリアスで gwmi とも呼ばれます) を使用したことがあるのではないでしょうか。先月のコラムで説明したとおり、このコマンドレットは、Windows PowerShell がこれまでのスクリプト言語やコマンド ライン シェルに比べて優れている主な点をよく示しています
(technetmagazine.com/issues/2007/05/PowerShell を参照)。gwmi を使用すると、Windows® Management Instrumentation (WMI) にすばやく簡単にアクセスでき、複雑なスクリプトを作成しなくても、実にさまざまな操作を実現できます。
Get-WMIObject は、Windows PowerShell™ で可能なことを説明するための非常によい例で、これを授業で教えると、必ず受講者はそれを基にその他の Windows 管理に対する機能についても考えを巡らせます。そして、最初に聞かれる質問には、通常「Get-ADSIObject コマンドレットはありますか」というフレーズが付いて来ます。

Windows PowerShell での ADSI サポート
ADSI は、Active Directory® Services Interface の略です。その名前にも関わらず、ADSI は Active Directory に固有のものというわけではありません。この名称のより正確な読み方は、"Active (一息置く) Directory Services Interface" でしょう。理由は、ADSI は、Windows NT® 形式のディレクトリを含め、さまざまなディレクトリ サービスに接続できるためです。念のために申し上げておくと、これには、Windows NT ドメインだけではなく、スタンドアロン コンピュータやメンバ コンピュータ上のローカルのセキュリティ アカウント マネージャ (SAM) も含まれます。このような高い柔軟性を備えているため、Get-ADSIObject コマンドレットは間違いなく非常に便利なものになるでしょう。ただ、残念なことに、これは Windows PowerShell チームが最初のバージョンに含めることができなかったコマンドレットの 1 つです。
しかし、それは Windows PowerShell に ADSI サポートが欠けているということではありません。実際、Windows PowerShell の ADSI サポートは非常に優れていて、Get-ADSIObject コマンドレットがないことなど気にならないほどです。
このサポートはすべて [ADSI] 型アダプタを基に実現されます。型アダプタについては、少し説明が必要ですね。Windows PowerShell は、Microsoft® .NET Framework (正確には 2.0 以降) を基に構築されていることを思い出してください。このため、WMI オブジェクトからファイルやフォルダにいたるまで、Windows PowerShell の構成要素はほぼすべて、.NET Framework のオブジェクトとして表されます。ただし、Windows PowerShell チームは、.NET Framework オブジェクトをそのまま Windows 管理者に公開することに抵抗を感じていました。たとえば、多くの .NET Framework オブジェクトの動作はやや一貫性に欠けていますが、一貫性は Windows PowerShell の主要な設計目標の 1 つです。また別の理由としては、一部の .NET Framework オブジェクトは、Windows 管理に関して言えば複雑すぎますが、簡潔性も Windows PowerShell の設計上の大きな検討項目の 1 つであることも挙げられます。その結果として、型アダプタが誕生しました。
名前が示すように、型アダプタは、.NET Framework オブジェクト型をより一貫性のある、ときにはよりシンプルな形式に "適合 (adapt)" させるものです。たとえば、次のような新しい文字列変数を作成するとします。
[string]$var = “Hello”
この例では、System.String 型のインスタンスを使用していて、これが .NET アダプタによって処理されます。[ADSI] 型アダプタは、DirectoryEntry 型を含む .NET Framework DirectoryServices クラスに接続されます。

ディレクトリからオブジェクトを取得する
ディレクトリ オブジェクトへの接続は、非常に簡単です。たとえば、 Contoso.com ドメインの IT 組織単位 (OU) 内の Don という名前のユーザーに接続する場合は、次のようなコードを使用します。
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
これまでに VBScript などの言語で ADSI を扱ったことがあれば、このようなコードはおなじみのものでしょう。これは、標準のライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリ文字列で、Active Directory のアクセスにネイティブで使われます。ドメイン コントローラ (DC) 名などの詳細を指定する必要はなく、この完全修飾ドメイン名 (FQDN) の情報だけで DC を特定し、オブジェクトを取得します (もちろん、このような操作に必要なアクセス許可があることが前提です)。
ローカル セキュリティ アカウントの操作にも、LDAP プロバイダの代わりに WinNT プロバイダを使用する点を除いて、ほぼ同じプロセスを使用します。
$user = [ADSI]”WinNT://don-pc/don”
図 1オブジェクトのプロパティの一覧を取得
オブジェクトの取得は、基本的に、クエリ文字列の構築方法を知っているかどうかの問題です。WinNT プロバイダを使用することは、とても簡単です。コンピュータ名またはドメイン名、スラッシュ、オブジェクト名の形式で指定します。この手法は、Active Directory ドメインでも問題なく使用できます (結局、これにより、Windows NT ドメインとの下位互換性が保たれます)。実際、Active Directory のオブジェクトの取得に WinNT プロバイダを使用することは、最も簡単な方法である場合があります。これは、WinNT プロバイダにより、ドメインのフラット ビューが得られるためです。つまり、WinNT プロバイダは OU を参照しないため、オブジェクトが属している OU を知る必要がありません。
LDAP オブジェクトを取得する場合は、もう少し正確な指定が必要です。最初に可能な限り限定的な情報を指定します。たとえば、オブジェクトの正規名 (cn) または OU の名前を指定します。次に、まず親コンテナを指定し、その後にドメイン自体へと進む形式で、オブジェクトへの完全なパスを指定します。たとえば、Contoso.com ドメインの West OU 内の Sales OU に属しているユーザー Don のパスは、次のように指定します。
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
この形式は、多少練習が必要です。また、オブジェクトが配置されている場所を把握している必要があります。図 2 は、FQDN のさまざまな構成要素の概要を示しています。
Figure 2 FQDN コンポーネント (Close Figure 2)

コンポーネント | 目的 | 例
cn | オブジェクトの正規名。ユーザーやコンピュータなど、OU 以外のコンテナにも使用されます。 | cn=Don
ou | 組織単位。 | ou=Sales
dc | ドメイン名コンポーネント。DNS ドメイン名の各コンポーネントは、それぞれの “dc=” コンポーネントを取得します。 | dc=domain, dc=com

友からの手助け
オブジェクトを作成および削除する場合は、通常、まずオブジェクトのコンテナ (OU など) に接続し、コンテナにオブジェクトを作成または削除するように要求します。私はいつも正しい構文を忘れてしまうのですが、幸い Microsoft Scripting Guys が救いの手を ADSI Scriptomatic の形で差し伸べてくれました。
ADSI Scriptomatic はもともと VBScript 向けに作成されたものですが、実際の ADSI 構文は同じなので、Windows PowerShell でも参考にできます。たとえば、ここではこのツールをダウンロードしてから、新しいユーザーを作成することにしました。"End connect to a container" というコードの後に続く次のようなコードを除き、ツールが生成したスクリプト コードはすべて無視しました。
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
Windows PowerShell への変換は簡単です。まず、ユーザーを作成するコンテナに接続します。Scriptomatic コードとの整合性を保つため、変数 $objContainer を使用して OU を表します。また、新しいユーザー名を保持するため、$strName という変数を作成します。
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
次に、Scriptomatic コードをコピーし、VBScript Set ステートメントの名残をすべて消して、$ を変数名に追加します。
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
これだけです。新しいユーザーが、Contoso .com ドメインの Test OU に作成されました。

ディレクトリ オブジェクトを変更する
オブジェクト (ユーザーまたはグループなど) に接続すると、そのオブジェクトを変更できます。WinNT プロバイダを使用すると、図 1 に示されているようなさまざまなプロパティを直接変更できます。たとえば、ユーザーの Description プロパティを表示して変更するには、次のようにします。
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
ここで覚えておく必要があるのは、プロパティの変更はローカルのプロパティ キャッシュに対して行われることです。これは、ADSI がコンピュータ上に保持している一時記憶域です。SetInfo メソッドを呼び出すと、オブジェクトを取得したドメインまたはコンピュータにキャッシュが書き戻され、実際に変更がディレクトリに保存されます。
Active Directory オブジェクトは、ほとんどのオブジェクト属性に対して直接プロパティを提供しません。代わりに、Get メソッドと Put メソッドを使用します。
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Windows NT ディレクトリ サービスでは、ユーザーやグループなどのオブジェクトについての情報があまり保持されていなかったため、WinNT オブジェクトはかなりシンプルになる傾向があります。一方、Active Directory は、非常に多くの情報を保持しており、適切な属性名を特定することは困難な場合があります。たとえば、ユーザーの名字を変更する場合は、Sn プロパティを変更する必要があります。なぜ Sn プロパティを変更するのかおわかりですか。これは、surname ("姓" を表す英語) を表しています。
幸い、マイクロソフトは便利な対応表をオンライン (msdn2.microsoft.com/ms677286.aspx) で公開しています。この対応表では、Active Directory ユーザーとコンピュータ コンソールの主要な各領域とそれに対応する属性名が記載されています。したがって、コンソールで変更する場所がわかっている場合は、基盤の属性名を特定することができます。コンソールと属性のより包括的な対応表については、『ADSI Scripting: TFM by Cade Fassett』(SAPIEN Press、2007 年) を参照してください。

実行可能な操作
残念ながら、Windows PowerShell の ADSI サポートは、WMI などの他のテクノロジのサポートほど強力ではありません。たとえば、ローカル コンピュータのグループのメンバを列挙することは、やや困難です。Active Directory を操作する場合も、さまざまな難しい状況に遭遇します。私の経験では、基本的なオブジェクトの取得、作成、削除は問題ありません。オブジェクト プロパティの変更もほぼ問題ありませんが、一部のプロパティにはアクセスできません。最も大変な思いをしたのは、WinNT プロバイダを利用して、ローカル オブジェクトとローカル グループを操作したときです。
だからといって、まったく何もできないということではありません。操作によっては、より難しかったり、直感的に処理できなかったりするだけです。次の例を検討してみましょう。
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
これは、User1 という名前のユーザーを Techs グループに追加します。始まりの部分は、複雑ではありませんね。FQDN を使用して、グループを取得します。次に、グループの Member コレクション (具体的には、コレクションの Add メソッド) を使用して、目的のユーザーの FQDN を追加します。しかし、最後のステップは、あまり直感的ではありません。隠しクラス PSBase の CommitChanges メソッドを呼び出し、変更を保存します。
PSBase は、.NET Framework の基本オブジェクトを直接表す特殊なクラスです。この例では、CommitChanges は Windows PowerShell に直接公開されません (実際、ADSI アダプタによって公開されるメソッドはありません)。したがって、基盤のクラスを使用する必要があります。これは、不可能ではありませんが、直感的でもありません。また、ディレクトリ サービスの機能が、まだ完全には Windows PowerShell に実装されていないことを示しています。
これにはさまざまな理由があります。まず、Windows PowerShell チームが現在の ADSI サポートをシェルに追加したのは、開発サイクルの終盤でした。このシェルのアーキテクトである Jeffrey Snover がよく言うように、"リリースは選択の問題" なのです。シェルの開発とリリースの時間は限られており、次のバージョンに持ち越すものを決めなければなりませんでした。そうでなければ、機能を追加するのに容易に数年を費やし、サポート製品を実際にリリースできることは決してないでしょう。
しかし、また別の理由は、基盤の .NET Framework にあります。この DirectoryServices クラスはかなり複雑で、このような複雑なものを Windows PowerShell に実装するには、かなりの時間と慎重な計画が必要です。また、個人的な意見ですが、.NET Framework のクラスはやや Active Directory 寄りで、WinNT プロバイダには優れたサポートを提供していません。そしてもちろん、Windows PowerShell は、このような .NET Framework の制限を継承することになります。
最終的には、中継層の ADSI ではなく、.NET Framework の基盤部分での改良により、Windows PowerShell のディレクトリ サービス サポートが大幅に拡張されるものと期待しています。それまでは、Windows PowerShell の ADSI サポートにより、ユーザーの作成、一般的なユーザー プロパティの変更など、さまざまな管理作業を実行することができます。
各種ディレクトリ サービス関連作業は、WMI を使用して実現できることもお忘れなく。microsoft.com/technet/scriptcenter/scripts のスクリプトを参照してください。ADSI 自体が提供するものよりも広範なローカル グループの情報を WMI を使用して取得する素晴らしい例がいくつか紹介されています。


 Hey, Scripting Guy!: 赤い波線をスクリプトで処理する
Hey, Scripting Guy! 赤い波線をスクリプトで処理する and Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2007_06.exe (151KB)
Microsoft Word の辞書に用語を簡単に追加する方法を探していませんか。手動で一度に 1 単語ずつ追加する方法ではなく、もっと簡単な方法です。探してますよね。今月の Scripting Guys は、Microsoft Word のユーザー辞書を作成する方法と、プログラムを使用して、Word がそれらの辞書を使用するように構成する方法を紹介します。
図 1スペル ミスを示す Word の文書
おかしな点に気付きましたか。そうです。スクリプトに使用される Msgbox などの単語の下に波線が表示されています。なぜでしょうか。これは、Word がこれらの用語を認識しないからです。認識できないなんて、よしてくださいよ、Word さん。Scripting Guys は何年かの間に数百万回も Msgbox という単語を入力しましたし、さらに数百万回スペル チェックを実行して、Msgbox のスペルが正しいことを確認してきました。それなのに、まだ Msgbox、StrReverse、LTrim などの単語は、スペルが間違った単語と見なされるのですか。これはどういうことでしょう。
ここで皆さんが Word をかばう前に申し上げておくと、はい、Microsoft Word の辞書に手動でこのような単語を追加できることはわかっています。でも、ほら、私たちは Scripting Guys なんですよ。手作業のことなんて、知るわけないじゃないですか。それに、VBScript の関数や、Windows® Management Instrumentation (WMI) クラス名、Active Directory® Security Interfaces (ADSI) オブジェクトの属性を手動で追加するなんて、控え目に言っても、少しあきあきしてしまいそうです。それに、これをすべてのコンピュータ上で実行する場合はどうするのでしょう。このような正しいスペルを熱心な読者の皆さんと共有する場合はどうするのでしょう。だんだん、わかってきていただけたと思います。
何が言いたいかというと、一度に 1 単語ずつ手で追加するのではなくて、スクリプト用語を (ついでに言えば、どんな用語でも) 辞書に追加する簡単な方法があるはずです。
結局のところ、そんな方法はありませんでした。では、また来月お会いしましょう。
いえいえ、冗談です。もちろん、辞書に用語を追加するための簡単な方法があります。この方法については、すぐに説明します。しかし、まず辞書について少しお話しましょう。
そう言えば、辞書に関して面白い話があります。アメリカでは、どうして color のスペルを u を抜かして書く (colour ではなく color にする) のでしょう。アメリカでは、どうして centre ではなく center というスペルを使うのでしょう。そんなことはたずねるまでもありません。それは、初のアメリカ英語辞書を編纂した Noah Webster が、英国式のスペルが好きではなかったため、多数の語のスペルをやや独断で変えてしまったのです。
そうですか。面白くないですか。では、皆さんが辞書について何か面白い話を教えてくださいよ。
Microsoft Word では、組み込みの標準の辞書のほかに、ユーザー辞書を必要な数だけ作成できます。既定では、Word のユーザー辞書の名前は Custom.dic になり、これは通常、ユーザー プロファイル フォルダ内 (Windows XP の既定では \Documents and Settings\ユーザー名) の Application Data\Microsoft\Proof フォルダに格納されています。スペル ミスのある単語を右クリックして、[辞書に追加] をクリックすると、その単語が Custom.dic に追加されます。
結局、Custom.dic はおなじみのテキスト ファイルに過ぎません。これをメモ帳で開くと、次のような単語の一覧を確認できます。
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
これを利用して、Microsoft Word の辞書にスクリプト用語をプログラムによって追加することができます。方法としては、このような単語を含むテキスト ファイルを作成して、Word がこのファイルをユーザー辞書として使用するように構成するだけです。どれほど難しい操作を行うのでしょうか。Scripting Guys 自らこの作業を行うところを見ると、明らかに難しいものではありません。
でも、少しお待ちを。作業にかかる前に、もう 1 つ簡単に触れておきたいことがあります。Microsoft Word のオブジェクト モデルでは、ユーザー辞書についての情報は CustomDictionaries コレクションに格納されます。また、このコレクションは、Word.Application オブジェクトと CustomDictionaries プロパティを参照することで、プログラムからアクセスできます。たとえば、図 2 は、Microsoft Word に関連付けられているすべてのユーザー辞書についての情報を返すスクリプトです。
Figure 2 ユーザー辞書情報を取得するスクリプト (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
図 2 のスクリプトを実行すると、次のような情報が返されます。
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
なかなかすばらしいでしょう。
もちろん、既存の辞書についての情報を取得することは、新しいユーザー辞書を作成することとは同じではありません。これは、億万長者についての話を読むのと、億万長者になるのとの違いのようなものです。ですから、Word の新しいユーザー辞書を作成する方法を考えてみましょう。
まず、すべての VBScript 関数を Scripting.dic という名前の新しい辞書に追加します。ここでは少しやることがあるので、VBScript 関数から始めています。ただし、これが済んだら、WMI クラス、ADSI 属性、Windows PowerShell™ コマンドレットをほとんどまったく手をかけずに辞書に追加する方法をお見せします。(言うまでもないことですが、ほとんどまったく手をかけないというのは、Scripting Guys が得意とするところです。)
まず、Microsoft Word のユーザー辞書は、次のように簡単に作成できます。
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
ご覧のように、まず Word.Application オブジェクトのインスタンスを作成しています お気付きかもしれませんが、Visible プロパティを True に設定していません。したがって、Word が画面に表示されることはありません。なぜでしょうか。理由は簡単で、このスクリプトは実行に 1 秒程度しかかからないからです。このため、Word を一瞬画面に表示し、すぐに消してしまう意味はあまりないと判断しました。ただし、(スクリプトが実際に何か処理を行っているということを確認するというだけの理由で) Word を一瞬画面に表示するのであれば、次のコードをスクリプトに追加してください。
objWord.Visible = True
Word.Application オブジェクトを作成したら、次は以下のコードを使用して、CustomDictionaries コレクションへのオブジェクト参照を作成します。
Set colDictionaries = _
  objWord.CustomDictionaries
次は、Add メソッドを呼び出して、ユーザー辞書を追加します。なお、このファイルは存在している必要はありません。Word が Scripting.dic という名前のファイルを見つけられなかった場合、この名前で新しい空のファイルが作成されます。ユーザー辞書を追加するコードは、次のとおりです。
colDictionaries.Add “Scripting.dic”
新しい辞書を追加するときに、パスを指定していないことにも気が付かれたかもしれません。ここでは、単にファイル名 (Scripting.dic) を Add メソッドに渡しています。これで大丈夫です。この場合、Scripting.dic は、辞書や他の校正ツール用の既定のフォルダ (たとえば、C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof など) に作成されます。
別の場所に辞書を保存する場合はどうなるでしょうか。問題ありません。次のコマンドでは、Scripting.dic が C:\Scripts フォルダに作成されます。
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
また、後でユーザー辞書を削除することにした場合はどうでしょうか。これも、問題ありません。この場合は、問題の辞書をバインドし、Delete メソッドを使用してこれを削除します。
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
図 3ユーザー辞書を追加した後の Word 文書
Scripting.dic とユーザー辞書作成スクリプトを他のユーザーと共有できることを考えると、これは特に便利です。私たち自身が言うのですから、これは確かです。実際に共有すると、他のユーザーの Word でも、直ちに Msgbox がスペルの正しい単語として認識されるようになります。本当のところ、Scripting Guys が怠け者であれば、ここで今月のコラムを終了しても、皆さんは何かしら有益な知識を得て終わりにすることができます。でも、よく言われるように、お楽しみはこれからです。
注 : 実際、Scripting Guys は怠け者です。しかし、このコラムのスペースを埋めなければならないので、おまけのスクリプトを追加することにしました。
おそらくご存じのとおり、VBScript も Windows Script Host も何と言うか恥ずかしがりやで、自分たちのことはあまり話したがりません。しかし、WMI、ADSI、または Windows PowerShell は違います。質問するだけで、これらのテクノロジは、自分たちのクラス、プロパティ、メソッドについてすべて、こちらが知りたくないことまで語ってくれます。
たとえば、ADSI を見てみましょう。図 4 は、Active Directory スキーマにバインドし、そのユーザー アカウント オブジェクトの属性をすべて取得するスクリプトです。このスクリプトでは、次に、それらの属性を C:\Scripts\Scripting.dic に書き込みます。
Figure 4 ユーザー辞書に ADSI 属性名を追加するスクリプト (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
素敵でしょう。わずか数行のコードで、Active Directory ユーザー オブジェクトのすべての属性を含む辞書を作成しました。このコードをスクリプト仲間と共有すれば、だれも streetAddress や givenName という名前の属性が、スペルの間違った単語としてマークされることを心配する必要がなくなります。また、もちろん、これは無限に拡張できます。コンピュータ クラスのプロパティを追加しますか。その場合のコードは、次のようになります。
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
さて、WMI クラスはどうでしょう。図 5 は、root\cimV2 名前空間に含まれるすべての WMI クラスの一覧を取得して、この情報を C:\Scripts\Scripting.dic に書き込むスクリプトです。
Figure 5 ユーザー辞書に WMI クラス名を追加するスクリプト (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Windows PowerShell ユーザーは忘れられているのでしょうか。Scripting Guys はそんなことはしません。いえ、はい、実は忘れていました。しかし、きちんと思い出して、次のスクリプト コードを用意しました。このコードは、すべてのコマンドレット名を取得し、これらを C:\Scripts\Scripting.dic に書き込みます。
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
今月のコラムのよいところは、だれもが何かしらを学んだことです。皆さんは、Microsoft Word のユーザー辞書を作成する方法と、プログラムを使用して、Word がそれらの辞書を使用するように構成する方法を学習しました。そして、Scripting Guys は、何かを成し遂げようと思ったら、やはり他のだれかにやってもらうのがよいことを学習しました。ただし、他人がすべて失敗したら、いつでも自分でやることができます。


 デスクトップ ファイル: データの損失を防ぐ方法
デスクトップ ファイル データの損失を防ぐ方法 and Wes Miller 驚くべきことに、重要なデータの損失は頻繁に発生しています。しかし実際のところ、情報の損失は、ユーザーが情報の保護を怠っていることが原因で発生しています。この記事では、組織のデータをセキュリティで保護するために実施できる、また実施する必要がある重要な対策について説明します。
情報というのは漏洩しがちなものです。情報の保護をだれに委託したか、また、情報をどれだけ厳重に保護したかにかかわらず、情報が漏れ出る穴は必ずどこかに存在するものです。ニュースでは毎日、小規模および大規模なデータの損失が報じられています。重要なデータの損失が
図 2お母さんが大好きでも、使用しないほうがよいパスワード
パスワードの完全性とローカル認証は重要ですが、ローカル システム上のデータは、物理的にセキュリティ保護されているか暗号化されていなければ、当然まだ漏洩する可能性があります。パスワードだけでは、対策として不十分です。ユーザーのパスワードは、攻撃者がツールを使用せず、対話形式で直接システムにアクセスしてセキュリティを侵害しようとしている場合に、その侵害を阻止する役割を果たすことしかできません。

物理的なセキュリティ
重要なデータは、物理的に侵害されたりオフィスから持ち去られる可能性があるシステムに格納するべきではありません。Windows PE を起動してデータを取得することによってシステムが侵害されることを心配している場合、Windows PE について心配するのではなく、他の問題に対処する必要があります。この場合、次のうち 1 つ以上の問題が存在します。システムが物理的に正しく保護されていない。システムは保護されているが、システムにアクセスできるユーザーを信頼していない。物理的に保護されていない (または保護できない) システム上にデータが保存されている。システムを物理的に保護できず、物理的に侵害される可能性を低減するためのボリューム暗号化ツール (Windows Vista の BitLocker™ 機能など) も使用していない (BitLocker の詳細については、今月号の TechNet Magazine に記載されている Byron Hynes の記事を参照してください)。
攻撃を受ける可能性があるのはどのシステムなのか、考えてみてください。それらのシステムを物理的に保護することはできますか。データセンターや、アクセスが制限されたその他の場所にそれらのシステムを配置してはどうでしょうか。それができない場合や、システムがモバイル システムの場合、ボリューム暗号化ソフトウェアは使用していますか。これらの方法を 1 つも実践できない場合は、セキュリティで保護できるシステムにデータを移動するか、データを暗号化します。前述の盗難に遭ったノート パソコンの場合、安全なボリューム暗号化ツールを使用してボリュームを暗号化していたら、データの漏洩はほぼ完全に回避できていたでしょう。
システムがデータセンターにあるからといって、安全だとは限りません。インターネットに接続されている場合は、依然として危険にさらされています。インターネットに接続することによって、悪意のあるユーザーによる物理的なアクセスを受ける可能性が高まるため、システムに与えられる脅威を十分に考慮する必要があります。また、ネットワーク内の独立したセグメントにシステムを移動することを検討してください。移動先のセグメントでは、インターネットとシステムとの間に 1 つ以上のネットワーク保護機能を介在させるようにします。

データに関するリスクの軽減
実践できるもう 1 つのセキュリティ対策として、物理的に保護されたサーバーにデータを隔離し、ユーザーがアプリケーションまたはシンクライアント ツールを使用してデータにアクセスするという方法があります。この場合、外出中のユーザーがアクセスできるように、VPN 経由のアクセスを提供する必要が生じることがあります。ユーザーの物理的な制約によってデータの扱い方が決まってしまうことは避ける必要があります。データにアクセスする必要があるユーザーが、ブロードバンドやその他の高速アクセスを利用できない場所にいるからといって、データをユーザーのコンピュータのローカル インスタンスに移動しなければいけないわけではありません。システムをどうしても移動することができず、セキュリティで保護されていない場所で使用する必要がある場合は、繰り返しになりますが、ボリューム暗号化を使用してデータをセキュリティで保護します。

システム内のセキュリティ
どんなに手を尽くしても、だれかがハード ディスクを持ち去り、別の Windows システムにそのハード ディスクを取り付け、NTFS の ACL をリセットすることによって、システムを侵害する可能性はあるため、その場合の対策を準備しておく必要があります。
この対策として、Windows Vista に含まれているボリューム暗号化を使用します。Windows の他のほとんどのバージョンに対しては、多数のサードパーティ製のボリューム暗号化ツールが提供されています。これらのツールは、使いやすさもそれぞれ異なり、ボリューム全体の暗号化や、暗号化ファイル システム (EFS) による個々のファイルやディレクトリの暗号化を実行できない場合もあります。ボリュームを暗号化した場合、よほど高度な技術を持ったハッカーでなければ、データを盗むことはできません。

アーカイブのセキュリティ
バックアップ データもセキュリティで保護する必要があります。システムのバックアップがセキュリティで保護されない理由としてよく挙げられるのは、バックアップ時に暗号化を行うと時間がかかりすぎることや、使用しているバックアップ ソフトウェアで暗号化がサポートされていないことなどです。
しかし、システムをバックアップする場合、そして特に、ベスト プラクティスに従ってオフサイトでデータをバックアップする場合は、バックアップするデータをセキュリティで保護する必要があります。これを行うには、EFS (使用できる場合) やその他のボリューム暗号化ソフトウェア (Windows Vista の BitLocker 機能やサードパーティ製のソフトウェアなど) を使用してデータを暗号化するか、暗号化機能が含まれており、許容できるレベルのパフォーマンスを備えたバックアップ ソフトウェアを購入します。バックアップ テープに保存されたデータは多少わかりにくくなり、ディスク ベースのバックアップ ソリューションによって保存されたデータは細かく分解されますが、これはデータがセキュリティで保護されたことを意味しているわけではありません。転送メカニズム自体が侵害されることを想定する必要があります。

データの転送に関するセキュリティ
ネットワーク経由で送信するデータは、必ずセキュリティで保護する必要があります。リモート システムへのアクセスには、セキュリティで保護されたプロトコルのみを使用します。また、暗号化されたプロトコルのバージョンを使用し、中間者攻撃 (man-in-the-middle、MITM) 攻撃が発生することを常に念頭に置いておく必要があります。 暗号化機能が脆弱なプロトコルや、暗号化されていないプロトコルは使用しないようにし、暗号化を使用する場合は、長さが不十分な暗号化や脆弱な暗号化アルゴリズムは使用しないようにします。また、組織内のいずれかのメンバが、インフラストラクチャのシステム間で使用されている通信プロトコルと暗号化アルゴリズムをすべて理解しておく必要があります。

確実な削除
eBay や地方のフリー マーケットで買ったハード ディスクやその他の記憶装置に、科学的犯罪捜査用ソフトウェアや一般の削除取り消しユーティリティを適用したところ、機密情報、つまりドライブを売却する前に完全に消去しておく必要のあったデータが発見されたという話は、ご存知だと思います。
組織で UFD を使用している場合は、暗号化ユーティリティの使用を強制することを検討してください。リスクの高いデータが保存されたディスクは、暗号化する必要があります。処分する前にボリュームを暗号化するだけで、ディスクを安全に処分できると信じているユーザーは多いのですが、私はこれには同意できません。前述の、医療廃棄物のたとえを覚えているでしょうか。システム上のデータを有害な廃棄物と考え、信頼できるデータ削除ユーティリティをその処理方法と考えてください。使用したディスクやシステムを転売したり、組織内で別のユーザーに譲り渡したりする前に、DoD 5220.22-M 規格が実装されたデータ削除ツール (Mark Russinovich が開発した SDelete など) を使用してください。使用しなかった場合、次のユーザーは、前のユーザーのデータをすべて知ることができてしまいます。

監査
大事なことを言い忘れていましたが、データのセキュリティに関するもう 1 つの重要な要素は、組織のデータのライフサイクルを監査し、このライフサイクルにおいてデータがさらされる脅威をモデル化することです。データの漏洩を引き起こす可能性がある脆弱な部分を理解し、その部分を注意深く監視します。Windows には、いくつかの監査ツールが組み込まれています。しかし、監査を実行すると、データのオーバーフローが発生しやすくなります。監査する部分が適切であることを確認し、データのオーバーランが発生しないようにする必要があります。また、脆弱な部分を監視し、適切な緩和措置を行います。効果の低い方法を使用してデータを保護することは避けてください。また、データの取り扱い方をユーザーに正しく教えます。ユーザーは、組織内のさまざまなレベルで、重要な連結役となります。その他のガイダンスについては、補足記事の「参考資料」を参照してください。このコラムで説明したことを、すべて実践すれば、夜は心置きなく眠れるようになるでしょう。
参考資料
『コア インフラストラクチャの最適化を実装する担当者のためのリソース ガイド - 基本レベルから標準化レベルへ』には、IT インフラストラクチャを、手作業が多く受身的な基本レベルから、より多くの作業が自動化され、構成の基準が適用され、運用が改善される標準化レベルへと移行させる方法が紹介されています。このガイドは、go.microsoft.com/?linkid=5795711 からダウンロードできます。インフラストラクチャの最適化を実装する担当者のための、その他のリソース ガイドは、microsoft.com/io から入手できます。また、「セキュリティに関する 10 の鉄則」で紹介されている、セキュリティに関するヒントも参照してください。


 フィールド ノート: 開発者と話そう
フィールド ノート 開発者と話そう and David Aiken より管理しやすいアプリケーションを開発者に作成してもらうのは、それほど難しいことではありません。すべてはコミュニケーションから始まります。開発者は、管理者とは違う視点でソフトウェアをとらえています。しかし管理者は、開発者と話すことによって、自分たちにとって重要な機能を説明することができ、開発者はそれに応じて、より適切なコードを設計することができます。
奇妙に感じられるかもしれませんが、開発者は、管理者とは違う視点でソフトウェアをとらえています。開発者が扱うのは、コード、トレース、XML 構成ファイル、GUID、およびアセンブリです。管理者が扱う (少なくとも扱おうとする) のは、スクリプトと Microsoft® 管理コンソール (MMC) スナップインです。
では、一歩離れて考えてみましょう。私は、いつかソフトウェア開発プロセスは一変すると思います。開発者は、エンド ユーザーの要望を見極めるために、非常にさまざまな手段を使います。たとえば、プロトタイプを作成したり、ユーザビリティに関する調査やインタビューを実施したり、その他にもさまざまなことを行います。しかし、単純で一貫性のある管理エクスペリエンスを提供するまでには及んでいません。遠く及んでいないのです。
私は以前、ソフトウェアをインストールするには、Xcopy、Regedit、およびメモ帳を使用することが最良の方法だと考えていました。しかし、カスタマイズ、インストール、およびアンインストールが可能な Microsoft インストーラを使用することが最良の方法であることがわかりました。また、管理者が Web サービスを構成する際に、メモ帳を使用して XML を編集するのではなく、MMC スナップイン (または Windows PowerShell™ スクリプト) を使用した方が、おそらくずっと簡単であることもわかりました。さらに、ユーザーや管理者が問題の根本的な原因や解決策を知りたい場合、スタック トレースよりも、アプリケーション ログに詳しく記録されたイベントを提供した方が役に立つこともわかりました。そして、管理者が管理および操作できるソフトウェアを作成するには、管理者をユーザーに見立てる必要があることもわかりました。
管理者をユーザーに見立てて、ユース ケースの定義、プロトタイプの作成、使いやすさの調査を行うことにより、可能な限り最良のエクスペリエンスを管理者に提供できるようになります。つまり、管理者は、開発者に問い合わせなくても、ソフトウェアのインストール、構成、監視、トラブルシューティング、および修正を行うことができるようになります。管理者が使い慣れている、オペレーティング システムの組み込み管理機能を使用すれば、アプリケーションの実行にかかるコストが大幅に削減され (エスカレーションされる問題の数が減少します)、顧客の満足度が向上し (アプリケーションが停止する頻度が低くなり、問題をすばやく解決できるようになります)、管理者たちに自分が開発したソフトウェアをより多く購入してもらうことができる可能性が高くなります (そしてカリブ海の豪華な大型客船でのひとときを楽しむことができます)。
大型客船は夢かもしれませんが、より管理しやすいアプリケーションを開発者に作成してもらうことは、単なる夢ではなく、実現可能な目標なのです。そして、皆さんも一役買うことができます。今度何か問題が発生したら、ただ電子メール メッセージを転送し、陰で開発者の悪口を言うのではなく、アプリケーション ログにイベントを記録したり、パフォーマンス カウンタなどの、問題が発生したことを確認できる手段を提供してくれるように頼んでみてください。可能であれば、考えられる原因と解決策も提示してください。さらに、アプリケーションの構成に使用できる、Windows PowerShell スクリプトまたは MMC コンソールを作成してくれるように頼んでみてください。開発者は、管理者のニーズはもとより、管理者の存在にさえ気付いていない場合もあります。皆さんが教えてあげてください。


 Windows 秘話: 新規ユーザーのスタート メニューに表示される項目
Windows 秘話 新規ユーザーのスタート メニューに表示される項目 and Raymond Chen 新しく購入したコンピュータで Windows を起動し、[スタート] ボタンをクリックしたとき、空のメニューが表示されることを想像してください。ユーザーが初めて使用したときにも [スタート] メニューの最も頻繁に使用したアプリケーションのエリアに項目が表示され、すぐに操作を開始できるのは、こうした理由によるものです。これらのアプリケーションがどのように選択されるかについてご紹介します。
私たちは、この最初の空の [スタート] メニューにテキストを埋め込もうと考えました。「皆さん、この領域は現在は空ですが、プログラムを実行するにつれてそれらのプログラムが表示されるようになりますので、心配しないでください。」という具合です。これだと少しましになるかと思いましたが、使いづらいうえに見苦しくなりました。
さらなる試行錯誤が必要でしたが、最終的に Windows XP で使われている形に決まりました。先月は、頻繁に使用されたプログラムの一覧がポイント システムに基づいており、ポイントの高いプログラムがこの動的な一覧に表示されることについて示しました。まったく新規のユーザーの場合、各種プログラムに人為的なポイントを付加しました。これにより、最初の [スタート] メニューにはユーザーの興味を引くプログラムの見本が表示され、コンピュータで何を行うかについてのヒントが得られるようになります。
頻繁に使用されたプログラムの一覧に表示されるための十分なポイントが目的のプログラムに付加され、また、ユーザーが起動したプログラムが取得できる実際のポイント数を超えるほど多くのポイントが付加されないように、人為的なポイントの点数は慎重に選択されます。
ただし、Windows 2000 からのアップグレードの場合、この人為的なポイントは付加されません。この場合は、Windows 2000 の [スタート] メニューでインテリメニュー用に使用されたポイントが、Windows XP ポイント システムの設定に使用されます。この方法により、アップグレード インストールされた Windows XP の [スタート] メニューには、Windows 2000 でユーザーが頻繁に実行したプログラムが即座に反映されます。
Windows XP の最初のリリースでは、最も頻繁に使用されたプログラムの一覧の 6 つの枠のうち最初の 3 つが Windows によって選択され、最後の 3 つがコンピュータ製造元によって選択されるよう、人為的なポイントの割り当てが行われました。プレインストール版ではなく、製品版の Windows XP を購入した場合、これらの 3 つの枠のうち 2 つが Windows によって挿入され、最後の枠が空になります。そのため、ユーザーが最初に実行したプログラムが即座に [スタート] メニューに表示されます。
これらの 6 つの枠について Windows XP Service Pack 1 で若干の修正が加えられました。枠の 2 つが Windows、1 つが米司法省、最後の 3 つがコンピュータ製造元により選択されました。以前と同様、製品版の Windows XP の場合は、コンピュータ製造元の枠のうち 2 つが Windows によって割り当てられ、最後の枠が空になります。
[スタート] メニューは、Windows ユーザー インターフェイスの最も目につく部分の 1 つであり、自然で直観的なインターフェイスを模索するため多くの作業が試みられています。


 レター: 質問への回答
レター 質問への回答
Windows PE の概要
Wes Miller の記事「Windows PE の概要」 (TechNet Magazine の 2006 年 9 月号) を読んだ後、HTML for Applications (HTA) ベースのウィザードを使用してメニューを作成しました。Windows® PE 2.0 でメニューを動作させることに関していくつか質問があります。
—Andy

以下に各質問と Wes の回答を記載します。

オプションのソフトウェア コンポーネントである HTA と Windows Script Host (WSH) が手元にある ISO ファイルから実行されているかどうかを確認する方法はありますか。
ドキュメントに記載されている指示に従って ISO ファイル内のオプション コンポーネントをインストールしたのであれば、それらのコンポーネントは動作するはずです。でも、コンポーネントが動作しない 2 つの一般的なシナリオについて聞いたことがあります。1 つはイメージを準備するときに peimg の /prep を実行しなかった場合です。もう 1 つは Windows PE イメージのマウントを解除するときに、ImageX で /commit パラメータを使用してそのイメージへの変更を実際にコミットしなかった場合です。

Windows Management Instrumentation (WMI) をインストールしておく必要はありますか。その記事に掲載されていたウィザード ファイルを実行すると、Internet Explorer® エラーが発生するのです。
ウィザード ファイルは、HTA がインストールされていれば機能します。これは非常に基本的なことです。ウィザード ファイルには WMI は必要ありません。実際、WMI を Windows PE に追加できるようになったのは、ウィザード ファイルを記述した後です。

OC.bat を startnet.cmd ファイルに含めるにはどうすればよいですか。
Windows PE 2.0 を使用している場合は OC.bat を使用する必要はありません。OC.bat が必要なのは 1.x を使用している場合だけです。Windows PE 2.0 では、OC.bat によって行われる shim 操作を使用せずにコンポーネントを追加できます。

Wes のコードの一部を自分のメニューに使用しても問題ないですか。
コード サンプルはどれでもご自由にお使いください。また、必要に応じて再利用してください。ただし、サンプル コード パッケージの一環として転売したり再配布したりすることは認めていません。詳細については、TechNet Magazine Web サイトのライセンス契約をご確認ください。

Windows PE の場所
Windows PE Build Tools はどこで入手できますか。ダウンロードできますか、それとも購入する必要がありますか。
—Franklin
Windows PE Build Tools for Windows Vista™ は Windows Automated Installation Kit (WAIK) に含まれています。go.microsoft.com/fwlink/?LinkId=85377 でダウンロードを検索できます。
WAIK は Windows Vista ファミリのオペレーティング システムのみを対象にしています。Windows XP を展開する場合は、Business Desktop Deployment Solution Accelerator に同様のさまざまなツールが含まれています。ただし、Windows PE のライセンスは Windows Vista で変更されています。以前 (Windows XP のとき) は、ソフトウェア アシュアランス ライセンスを利用していないと Windows PE を入手できませんでした (詳細については、microsoft.com/licensing/sa/benefits/winpe.mspx を参照してください)。

ファイル サーバー リソース マネージャ
ファイル サーバー リソース マネージャ パッケージの Windows Server® 2003 初期リリース用のダウンロードが公開される予定はありますか。それとも、このパッケージと互換性があるのは R2 リリースだけでしょうか。
—Dan
ファイル サーバー リソース マネージャは Windows Server 2003 R2 の機能です。このバージョンでの依存関係により、現時点では以前のリリースで使用できるようにする予定はありません。

カーネルの内部
Mark Russinovich の記事「Windows Vista カーネルの内部 : 第 3 部」を読んだ後、2 つの質問が出てきました。1 つ目として、各ブート セッションで exe ファイルまたは DLL ファイルがランダムに格納される場所が Process Explorer に表示されることが気になっています。マルウェアが同じメカニズムを使用して、悪用したいコードの場所を特定できる可能性があるのではないでしょうか。2 つ目として、ランダムな選択が開始される場所が 256 か所ある場合 (私がこの記事を正しく理解していることを前提にしています)、マルウェアの "ブルート フォース" によって対象のコードがセッションに対して静的なままかどうかが調査されるのを防ぐにはどうすればよいでしょうか。
—Joe

Mark がすべての質問に回答します。

Process Explorer は、因果関係のわからない状況を示します。したがって、マルウェアは、DLL の場所情報を返す API の場所を把握できないので、DLL の場所を把握できません。マルウェアの "ブルート フォース" による調査は、当てにならない侵入方法です。マルウェアは推測が間違っていても、多くの場合、侵入対象のアプリケーションをクラッシュするためです。少なくとも、ランダムな選択によってウイルスの蔓延速度が遅くなります。最良の場合、マルウェアがシステムに侵入するのを防ぐことができます。

連絡先
質問やコメントがありましたら、遠慮しないでください。皆さまからのご連絡をお待ちしています。tnmag@microsoft.com (英語) に電子メールをお送りください。