セキュリティ

ソフトウェア制限ポリシーを使用したアプリケーションのロックダウン

Chris Corio and Durga Prasad Sayana

概要:

• ソフトウェア制限ポリシーのしくみ
• 環境内にあるアプリケーションの一覧を作成する
• ポリシーを作成および適用する

IT プロフェッショナルが、デスクトップ コンピュータの総保有コスト (TCO) を削減しようとするとき、思い浮かぶ主な戦略は 2 つあります。1 つは、デスクトップ ユーザーの

アカウントを Administrators グループから除外することです。2 つ目は、ユーザーが実行できるアプリケーションを制限することです。企業環境でこれらの問題に取り組むことは、非常に困難な作業になる可能性がありますが、Windows Vista® では、この目標の達成に役立つテクノロジがいくつか提供されています。

Windows Vista とそのユーザー アカウント制御 (UAC) 機能により、かなり容易に企業ユーザーを Users グループのメンバ (標準ユーザー) として実行できるようになりました。UAC によって、すべてのアプリケーションの既定のセキュリティ コンテキストが、管理者ではなくユーザーのセキュリティ コンテキストに変更されました。それでも依然として、この Users グループへの移行は大変な作業ですが、業界がこの新しいパラダイムに歩調を合わせていくに従って、今よりも容易な作業になっていくでしょう。

多くの管理者は、Users グループへのユーザーの移行に伴う課題の分析を終えたときや、場合によっては分析中に、ユーザーが実行する必要があるアプリケーションを洗い出し、これらのアプリケーションのみを許可するための手順を検討します。ソフトウェア制限ポリシー機能は、まさにこの作業を支援することを目的としています。

この作業を完了するには、グループ ポリシーを使用して、実行を許可するアプリケーションを指定し、そのポリシーを展開するだけです。このようなグループ ポリシーを全社に適用することで、サポートされないアプリケーションに関する問題が制限されるため、TCO を削減できます (ソフトウェア制限ポリシーは、補足記事「必要最小限のソフトウェア制限ポリシー」で説明するような、魅力的かつ非常に極端な方法で使用することもできます)。

ソフトウェア制限ポリシーのしくみ

ソフトウェア制限ポリシーは、Windows Vista コンピュータ上でユーザーが実行できるコードを正確に制御することを目的としています。管理者は、環境内で実行できる (またはできない) アプリケーションを定義するポリシーを作成します。このポリシーは、どのような場所でコードが実行される場合でも常に評価されます。たとえば、プロセスの作成時、ShellExecute の呼び出し時、スクリプトの実行時などが考えられます (これについては、この後詳しく説明します)。

実行を許可されているアプリケーションと判断された場合、アプリケーションは起動しますが、実行を許可されていないアプリケーションと判断された場合、アプリケーションはブロックされ、ユーザーにそのことが通知されます。たとえば、[スタート] メニューからソリティアを実行しようとして、これが許可されていないアプリケーションであった場合、図 1 のようなダイアログ ボックスが表示されます。

図 1** アプリケーションがブロックされたときに表示されるダイアログ ボックス **(画像を拡大するには、ここをクリックします)

ソフトウェア制限ポリシーを定義する UI は、グループ ポリシー オブジェクト エディタ (GPOE) からアクセスでき、これを使用してロックダウン ポリシーを作成します。実行を許可または拒否するコードを定義するときは、さまざまな方法を使用できます。ポリシーが完成し、テストが完了したら、そのポリシーを展開できます。

ソフトウェア制限ポリシーを定義する

まず決定しなければならない大切なことは、既定の規則の種類を選択することです。この決定は、ソフトウェア制限ポリシーが環境内でどのように機能するかについて非常に大きな影響を及ぼします。ソフトウェア制限ポリシーは、許可リストと拒否リストという 2 種類のモードのいずれかで展開できます。基本的に、環境内で実行を許可するすべてのアプリケーションを指定するポリシーを作成するか、実行できないすべてのアプリケーションを定義するポリシーを作成します。

許可リスト モードでは、ポリシー内の既定の規則は [Restricted] (制限する) で、実行を明示的に許可していないアプリケーションがすべてブロックされます。拒否リスト モードでは、既定の規則は [Unrestricted] (制限しない) で、明示的に指定したアプリケーションのみが制限されます。

拒否リスト モードは、ご想像のとおり、TCO の大幅な削減と、アプリケーションのロックダウンによるセキュリティ上のメリットを求めている場合には、非現実的な方法です。すべてのマルウェアやその他の問題のあるアプリケーションをブロックする膨大な一覧を作成し、それを保守することは不可能に近いため、ソフトウェア制限ポリシーは、既定の規則が [Restricted] (制限する) である許可リスト モードで実装することをお勧めします。

環境内にあるアプリケーションの一覧を作成する

実行できるアプリケーションを指定するポリシーを設計する場合は、ユーザーが必要とするアプリケーションを正確に特定する必要があります。ソフトウェア制限ポリシー機能では、詳細ログ機能と、環境内で実行されるアプリケーションを正確に把握できる非常に簡潔なポリシーが提供されます。

環境内にあるコンピュータのサンプル グループを対象に、既定の規則を [Unrestricted] (制限しない) に設定し、その他の規則を削除して、ソフトウェア制限ポリシーを展開します。この目的は、ソフトウェア制限ポリシーを有効にする一方で、アプリケーションは制限されないようにすることによって、実行されようとするアプリケーションのみを監視できるようにすることです。

次に、以下のレジストリ値を作成することによって、詳細ログ機能を有効にし、ログを書き込むファイルのパスを設定します。

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

これで、アプリケーションが実行され、ソフトウェア制限ポリシーが評価される (すべてのアプリケーションの実行を許可している場合でも、ポリシーは評価されます) ときに、ログ ファイルにエントリが書き込まれるようになります。

各ログ エントリには、ソフトウェア制限ポリシーの呼び出し元、呼び出し元プロセスのプロセス ID (PID)、評価されるアプリケーション、該当するソフトウェア制限ポリシーの規則の種類、およびその規則の識別子に関する情報が含まれます。以下は、ユーザーが notepad.exe をダブルクリックしたときに書き込まれるエントリの例です。

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

このログ ファイルは、ソフトウェア制限ポリシーが有効になっており、アプリケーションをブロックするように設定されているときに、そのポリシーによって確認されるすべての実行可能コードを表します。したがって、ログ ファイルのエントリごとに、そのコードを許可リスト内に含めるかどうかを判断する必要があります。システムが機能するために必要な、Windows® を構成しているいくつかのバイナリが確認されることに注意してください。

ログを使用したこの手法によって、環境内でソフトウェア制限ポリシーによって検出されるアプリケーションを正確かつ容易に把握できますが、これ以外にも方法はあります。

Microsoft® Application Compatibility Toolkit 5.0 に含まれているインベントリ コレクタを使用すると、環境内で使用されているアプリケーションの一覧を作成できます。このツールでは、さまざまな方法を使用して、環境内にインストールされているアプリケーションを検出し、結果を集中管理用のデータベースに統合できます。

追加の規則を作成する

環境内で実行を許可するアプリケーションの一覧を作成したら、これらのアプリケーションの実行を許可する実際の規則を作成できます。ソフトウェア制限ポリシー機能では、2 とおりの方法でポリシーを指定します。1 つは、アプリケーションの暗号化プロパティ (ハッシュなど) に基づいており、もう 1 つは、信頼されたアプリケーションが格納されている信頼済みパスまたはフォルダを定義します。

図 2 は、GPOE (gpedit.msc) の [ソフトウェアの制限のポリシー] ノードで、アプリケーションの実行を許可する規則を追加する場所を示しています。環境内のアプリケーションを定義する最も簡単な方法は、ログを使用する先ほどのプロセスで検出できたすべてのバイナリに対応するハッシュの規則を作成することです。

図 2** gpedit.msc を使用したソフトウェア制限ポリシーの作成 **(画像を拡大するには、ここをクリックします)

ハッシュは、特定のビット セットに対して返される一意の値であるため、ポリシー内の各バイナリには異なるハッシュが割り当てられます。これは特に強固なセキュリティが提供される方法であり、ポリシー内で指定された特定のバイナリのみが実行を許可されます。

もちろん、この方法には欠点もいくつかあります。たとえば、環境内には少なくとも数千個のバイナリが存在します。規則の数が膨大になると、パフォーマンスに影響する可能性があるため、ソフトウェア制限ポリシーの UI からこれらのバイナリに対応する規則をすべて作成することは困難です。また、環境内のアプリケーションに適用するそれぞれの更新プログラムを環境内に展開するには、新たに 1 つ以上のハッシュの規則が必要になります。アプリケーションの更新に合わせてこのような大規模なポリシーを更新することは、非常に面倒な作業になる可能性があります。

さいわい、その他にも規則を指定する方法は 2 つあり、これらを使用することによって、環境内でソフトウェア制限ポリシーをより容易に使用できるため、この面倒は避けることができます。暗号化セキュリティを利用すると、特定の証明書によって署名されたバイナリの実行を許可する規則を作成できます。

これにより、アプリケーションの更新時に、新しいバイナリが基本的に前と同じ証明書によって署名されるため、ポリシーの一覧を容易に保守できるようになります。ただし、バイナリの以前のバージョンを環境内で実行しない場合は、実行を制限するハッシュの規則を追加して、このファイルの実行が許可されないようにします。

ソフトウェア制限ポリシーでは、証明書の規則の評価が既定で無効になっています。これには 2 つの理由があります。

1 つ目の理由は、ソフトウェア制限ポリシーに含まれる証明書の規則が、システム上の信頼された発行元のストアに格納されている証明書によって定義されるためです。信頼された発行元のストアは、ソフトウェア制限ポリシーの規則以外の目的でも使用されるため、このストアをソフトウェア制限ポリシー機能に使用する場合は、より時間をかけて入念に検討する必要があります。

2 つ目の理由は、ファイルのハッシュを取得し、これを署名情報と比較して、ファイルの署名が有効であるかどうかを判断する必要があるためです。ファイルのハッシュの作成は、処理コストが非常に高い操作です。これを行うには、ファイル全体をディスクから読み取り、ハッシュを計算する必要があります。

証明書の規則を有効にするには、[ソフトウェアの制限のポリシー] ノードを参照し、結果ウィンドウ内の [強制] オブジェクトを選択します。これをダブルクリックしてプロパティ ダイアログ ボックスを開き、証明書の規則を適用するためのオプションを選択します。

コードを指定するもう 1 つの一般的な方法は、ローカル コンピュータ上のコードのパスを使用する方法です。これは、効率的で効果的な手法ですが、1 つ欠点があります。それは、セキュリティ設定が目的のフォルダに適切に設定されるよう十分に注意しなければならないことです。

特定のパスの規則を追加し、ユーザーにこのパス (デスクトップなど) へのファイルの書き込みを許可すると、ユーザーはこのフォルダに実行可能ファイルを保存するだけで、任意のファイルを実行できるようになります。ただし、Administrators グループに属していないユーザーは、通常、Program Files または Windows ディレクトリ内のファイルを変更できません。このため、すべてのアプリケーションが Program Files ディレクトリ内にあり、ユーザーが Administrators グループに属していない場合は、パスの規則を使用して、非常に単純で効率的なポリシーを作成するとよいでしょう。

パスの規則では、他にも一部の環境に適した機能が提供されます。この規則では、ワイルドカードや環境変数を使用して、環境内の別の場所でも使用できる規則を容易に定義できます。たとえば、%systemdrive% はユーザーによっては c:\ ではない可能性があるため、この機能は便利です。

パフォーマンスと保守性を考えると、おそらくこれが最も手間をかけずにコードを指定できる方法と言えるでしょう。このパスの規則は当然使用を検討する必要がありますが、セキュリティに関するその他の考慮事項にも留意する必要があります。

ネットワーク ゾーンの規則

ソフトウェア制限ポリシーには、"ネットワーク ゾーンの規則" も含まれていますが、この規則は廃止される予定です。この規則はもともと、ある実行可能コードの提供元を特定して信頼し、その結果として、コードの実行を許可することを目的としていました。残念ながら、これは実現が非常に難しく、あまり有効に機能しませんでした。現在、この規則は、ほとんどのソフトウェア制限ポリシーのエントリ ポイントで適用されていません。

ほとんどのアプリケーションが %Program Files% ディレクトリにインストールされる場合でも、異なる場所に他の実行可能ファイルがインストールされ、それらが特定の証明書によって署名される場合は、別の種類の規則を使用したほうがよいでしょう。いくつかのハッシュの規則とパスの規則を使用すると、各環境に最適なポリシーを構成できます。

ただし、規則の処理順序が存在することに注意してください (図 3 参照)。まず証明書の規則が最も厳密で、次にハッシュの規則、パスの規則、ワイルドカードを含むパスの規則と続きます。したがって、コードがハッシュの規則とパスの規則によって指定されている場合は、ハッシュの規則のセキュリティ レベルが優先されます。

図 3** 規則の処理順序 **(画像を拡大するには、ここをクリックします)

ポリシーの適用

ソフトウェア制限ポリシー機能では、システム内のある一定の範囲に対してセキュリティ保護が提供されます。つまり、コードを実行できる場所にソフトウェア制限ポリシーが統合されるため、ポリシーを確認することによって、実行可能コードの実行を許可するかどうかが判断されます。

ソフトウェア制限ポリシーが確認される場所は多数ありますが、最もわかりやすいエントリ ポイントは CreateProcess です。CreateProcess の処理中に、ポリシーが確認され、該当するアプリケーションを表すバイナリの実行を許可するかどうかが判断されます。ポリシーの確認は SaferIdentifyLevel API (この API のドキュメントは公開されています) によって実行されます。一般的なプロセスについては、図 4 を参照してください (SaferIdentifyLevel については、この後すぐに説明します)。

図 4** バイナリが実行可能かどうかを SaferIdentifyLevel によって判断する **(画像を拡大するには、ここをクリックします)

ソフトウェア制限ポリシーが適用される API のうち、CreateProcess の次によく使用される API は ShellExecute です。この API は、[スタート] メニューに列挙されているアプリケーションをクリックするか、デスクトップ上のなんらかのオブジェクトをダブルクリックしたときに呼び出されます。

ShellExecute はさまざまなファイル形式に対して呼び出すことができます。たとえば、.txt ファイルに対して ShellExecute を呼び出しても、実際にこのファイルは実行されませんが、もちろん技術的には開かれます。このため、ソフトウェア制限ポリシーには、実行可能なファイルの種類の一覧が含まれており、この一覧によって、ShellExecute の呼び出し時に確認するファイルの種類が制御されます。この実行可能ファイルの種類の一覧は、ソフトウェア制限ポリシーの UI からカスタマイズできます。

CreateProcess と ShellExecute 以外では、他に 2 つ、ソフトウェア制限ポリシーが統合された重要なエントリ ポイントがあります。これらは、LoadLibrary とスクリプト ホストです。LoadLibrary が実行可能コードを確認する重要な場所であることは明らかですが、残念ながら LoadLibrary にはいくつか特殊な制限があります。

ほとんどのアプリケーションは、1 つの実行可能ファイルと、読み込まれる複数の DLL から構成されています。また、通常は、システム上で多数のアプリケーションが実行されます。したがって、LoadLibrary では、かなりの数のポリシーの確認が必要になります。このため、コードを指定するポリシーによっては、ポリシーが適用されるエントリ ポイントとしての LoadLibrary の処理コストは非常に高くなる可能性があります。システムに読み込まれるすべての DLL のハッシュを確認する必要があるため、それらのバイナリに対応するハッシュを作成し、作成したハッシュをおそらく数千のハッシュと比較することになります。

この機能は、既定では無効になっていますが、手動で有効にできます。これを行うには、gpedit.msc で [ソフトウェアの制限のポリシー] ノードを参照し、[強制] をダブルクリックして、[ソフトウェアのファイルすべて] を選択します。

前述のとおり、ソフトウェア制限ポリシーは、システム内のほとんどのスクリプト ホストに統合されます。これに該当するのは、cmd、VBScript、Cscript、JScript® などです。これらを始めとするエントリ ポイントでは、最も重要なソフトウェア制限ポリシー API である SaferIdentifyLevel が使用されます。

SaferIdentifyLevel API は、関連するソフトウェア制限ポリシー内の ID 情報を参照することによって、指定された実行可能ファイルの実行を許可するかどうかを決定します。この API のドキュメントは公開されています。サードパーティ製のスクリプト ホストや実行可能環境でも、この API を使用してソフトウェア制限ポリシーを統合できます。これによって、ポリシーを使用して実行可能コードの実行を許可するかどうかを決定できるようになります (この方法は推奨されています)。

標準ユーザーとして実行する

あまり知られていないソフトウェア制限ポリシーの機能の 1 つに、特定のアプリケーションの特権をアプリケーションの起動時にフィルタ選択できる機能があります。これは Windows XP で導入された機能ですが、Windows Vista で初めて、ソフトウェア制限ポリシーの UI に含まれました。

この機能は、Windows Vista UAC の前身であると言えます。その理由は、この機能を使用すると、ユーザーが Administrators グループに属している場合でも、標準ユーザーとしてアプリケーションを実行できたためです。この動作は、追加の規則を作成する UI から規則を作成し、そのセキュリティ レベルを通常ユーザーに設定した場合と同じ動作です。

UAC のトークン フィルタ機能と、ソフトウェア制限ポリシーの通常ユーザーの規則は、どちらも CreateRestrictedToken API と同じ動作が実装された API を基盤として活用しています。ただし、これらのテクノロジの全体的なアーキテクチャは大きく異なります。UAC は、主に次のような点でソフトウェア制限ポリシーと異なります。

まず、Windows Vista で UAC が有効になっている場合、ユーザーが管理者であったとしても、すべてのアプリケーションは、既定で Users グループのメンバと類似したセキュリティ トークンを使用して起動します。この動作はソフトウェア制限ポリシーを使用しても実現できますが、たとえば、ユーザーがアプリケーションをインストールする必要がある場合、ユーザーの実際の管理者トークンを使用してアプリケーションを起動する手段はありません。既定のセキュリティ コンテキストを変更し、ユーザーの完全な管理者トークンを容易に利用できることは、UAC の重要な利点です。

2 つ目の違いは、実行可能ファイルを処理する場合、コード自体が、動作するために必要な特権レベルを通知することです。これによって、独立系ソフトウェア ベンダ (ISV) や開発者はコードの要件を把握できるため、これは重要な違いであると言えます。たとえば、コントロール パネル アプリケーションで、あるオブジェクトを編集するために管理者特権が必要である場合、この要件をマニフェスト内に指定できます。したがって、ISV は、アプリケーションに必要な特権を記述できるため、特権レベルを変更する手段を提供できずに、ある特権レベルをアプリケーションに強制する必要はありません。

当面は、動作を十分に理解するまで、通常ユーザーの規則を使用しないことをお勧めします。UAC は、Administrators グループからデスクトップ ユーザーを移行するときに非常に役立ちます。企業環境への UAC の実装を真剣に検討してみてください。

ソフトウェア制限ポリシーの現状

どのような状況でソフトウェア制限ポリシーを使用するかを判断する必要がある場面は、数多く想定できます。ただし、実際は想像するほどそのような場面に遭遇することはなく、現在も気付かないうちにソフトウェア制限ポリシーを使用している可能性があります。たとえば Windows Vista システムで保護者による制限機能を実行していれば、ソフトウェア制限ポリシーを使用してアプリケーションの実行を制御していることになります。

ソフトウェア制限ポリシーは、Windows XP で初めて導入された、重要な技術上の進歩です。ただし、アプリケーションのロックダウンが IT プロフェッショナルの注意を引き始めたのは、ごく最近のことです。

Windows Vista のソフトウェア制限ポリシー機能は、まだ改善の余地がありますが、環境内でどのソフトウェアの実行を許可するかをこれまでよりも容易に制御できるため、この機能を使用することをお勧めします。さいわい、このテクノロジは今後も進化し続け、システムの管理だけでなく、Microsoft Windows 環境の運用にかかるコストの削減にも役立つテクノロジとなることが予想されます。

必要最小限のソフトウェア制限ポリシー

ソフトウェア制限ポリシーの利用方法の 1 つとして、Windows をキオスク モードにロックダウンするポリシーの作成が挙げられます。マイクロソフトは、このキオスクを作成するためのツールキットである SteadyState™ を実際に作成しました。ただし、実行可能なアプリケーションのロックダウンのみを行う場合は、これよりも単純な方法を使用できます。

Windows Vista へのログオンに最低限必要なアプリケーションの実行を許可するには、%windir%\system32 からの logonui.exe と userinit.exe の実行を許可するポリシーを作成します。また、大部分のユーザーのために、次のアプリケーションの実行も許可する必要があります。

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

既定の Windows シェルが必要である場合は、%windir%\explorer.exe も追加します。

また、Internet Explorer® など、特定のアプリケーションを直接起動することもできます。その場合は、explorer.exe ではなく、iexplore.exe を一覧に追加します。

この必要最小限のポリシーのもう 1 つの特徴は、ユーザーが Administrators グループに属していないことを前提としていることです。ユーザーが Administrators グループに属している場合、ポリシーが回避される可能性があるため、この点を認識しておくことは重要です。このポリシーが適用された場合、ユーザーはごく基本的なアプリケーションしか実行できず、管理者の特権も与えられないため、アプリケーションをインストールしたり、システムを保守したりすることはできません。

必要最小限のポリシーを適用したコンピュータ上でこのような作業を実行する場合、なんらかの方法が必要になるでしょう。管理者アカウントを使用してローカルにログオンすることで、このようなコンピュータの更新と保守を行う場合は、ソフトウェア制限ポリシーをローカル管理者以外のすべてのユーザーに適用するオプションを選択します。また、ポリシーに consent.exe と cmd.exe も含めるようにします。これによって管理者は、管理者用のコマンド プロンプトから任意の管理操作を実行できるようになります。

UAC は、トークンが Administrators グループに属していないかのように扱うことで、ユーザーのセキュリティ トークンの特権を制限します。上記の設定を行って管理者にポリシーを適用しないようにしても、ユーザーにはポリシーが適用されます。UAC の昇格を行った場合のみ、管理者に完全な管理者特権が与えられ、ソフトウェア制限ポリシーの適用対象から除外されます。

Chris Corio は、5 年以上にわたりマイクロソフトの Windows セキュリティ チームに所属していました。マイクロソフトでは、主にアプリケーションのセキュリティに関するテクノロジと、Windows をセキュリティで保護するための管理テクノロジを担当していました。連絡先は winsecurity@chriscorio.com (英語のみ) です。

Durga Prasad Sayana は、Windows コア セキュリティ チームのソフトウェア デザイン エンジニア兼テスト担当者です。セキュリティに関するテクノロジとソフトウェア テストを専門に扱っています。連絡先は durgas@microsoft.com (英語のみ) です。

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