Windows の管理

Windows Vista の ActiveX インストーラ サービス

Rob Campbell and Joel Yoker

概要:

• ActiveX コントロールに関する一般的な課題
• ActiveX コントロールのインストール方法
• 危険なアクセス許可
• Windows Vista でのより安全な処理

いつも決まってそうなのですが、セキュリティを大幅に強化するには、自由や柔軟性をある程度犠牲にしなければなりません。お使いの環境が多くの組織と同様なら、セキュリティが確保されたコンピューティング環境をエンド ユーザーに提供するために、デスクトップ オペレーティング システムを強化したいという非常に強い要望を

お持ちでしょう。通常、IT 管理者は、デスクトップのセキュリティを確保するという課題に取り組む場合、セキュリティ ポリシー設定、ユーザーのアクセス許可、ファイルとレジストリのアクセス制御リスト (ACL)、およびシステム サービスの制限を組み合わせて利用します。

セキュリティが確保されたデスクトップ環境を構築する上での一般的な問題の 1 つが、お使いの環境でアプリケーションの互換性を適切なレベルに保ったまま、悪意のある ActiveX® コントロールに関連する脅威を軽減するにはどうすればよいかということです。これは何年もの間、デスクトップ オペレーティング システムに関する課題でした。さいわい、Windows Vista™ で導入された ActiveX インストーラ サービス (AxIS) が、企業環境での ActiveX コントロールの管理固有の問題に対処します。AxIS には、標準ユーザー (通常、ActiveX コントロールのインストールを許可されていません) が承認済み Web サイトから ActiveX コントロールをインストールするための、簡単で管理しやすい方法が用意されています。AxIS はグループ ポリシーで制御されるため、IT 管理者は、ユーザーのアクセス許可に関係なく、ユーザーがインストールできるコントロールを決定できます。

この記事では、ActiveX コントロールに関連する管理上の課題、以前のバージョンの Windows® ではこうした課題への対処がどのように行われていたか、および Windows Vista の AxIS ではどのようにして独自の効率的な ActiveX コントロールのインストールの管理方法を提供するかについて説明します。

ActiveX コントロールとは

ActiveX コントロールは、ユーザーが Internet Explorer® 経由でインストールし実行する、実行可能なコード (通常、キャビネット ファイルにパッケージ化された OCX ファイル) です。Web 開発者は、標準の HTML や単純なスクリプトでは簡単に実現できない機能を Web アプリケーションに追加するために、ActiveX コントロールを作成します。

ActiveX コントロールの重要な特性は、"ダウンロードして実行する" という単純な展開モデルにあります。ActiveX コントロールのインストールと実行は、HTML オブジェクト タグで行われます。このタグには CODEBASE という属性があり、ユーザーのコンピュータにコントロールがまだインストールされていない場合に、(URL を使用して) Internet Explorer にコントロールの取得先を通知します。これにより、関連するインストール パッケージがダウンロードされ、オブジェクトの信頼性検証が行われ、ユーザーにインストールの許可を問い合わせるメッセージが Internet Explorer の情報バーに表示されます (図 1 参照)。インストール時に、表示中のページによってコントロールが登録され実行されます。いったんインストールされれば、すべての標準ユーザーがこのコントロールを実行できるようになります。この、配布と実行の単純なメカニズムにより、開発者には Web アプリケーションのユーザーにコンポーネントを配布する簡単な方法が提供されます。この配布方法の問題点は、インストールを完了するには管理者特権が必要になるため、標準ユーザーが ActiveX コントロールを直接インストールすることができない点にあります。

図 1** ActiveX コントロールのインストールについての情報バー **

Internet Explorer 4.0 で ActiveX コントロールが初めて導入されたときは、インターネットは今よりずっと友好的な場所だと考えられていました。現在では、Web 経由で配布される実行可能なコードが深刻な脅威を意味するようになってきました。そのため、Windows では、ローカル管理者権限のあるユーザーのみが、しかも、ポリシー設定に従ってインストールが承認されている場合にだけ、ActiveX コントロールをインストールできるようにしています。管理者がいったん ActiveX コントロールをインストールすれば、システムのすべてのユーザーがそれを実行できます。この動作は、Windows のファイルとレジストリの ACL のセットによって容易になります。これにより、標準ユーザーによる ActiveX コントロールのインストールは防止されますが、ActiveX コントロールをインストールするローカル管理者と (既定のアクセス許可を変更した) 標準ユーザーへのリスクは軽減されません。

Windows の既定の保護 (管理者特権のあるユーザーだけにインストールの実行を許可する) は、個人レベルでは ActiveX コントロールに対処されますが、大規模組織全体で ActiveX コントロールを管理する方法には対応していません。企業環境での一般的な課題は、信頼されていない外部コントロールによってもたらされる潜在的脅威を軽減しながら、IT 組織が信頼している ActiveX コントロールの使用を許可するには、どうすればよいかということです。結局、特定の ActiveX コントロールをインストールするかどうかの決定は、良くも悪くも、多くの場合、権限に応じて個々のユーザーに一任されてしまいます。脅威に対抗するために、すべての ActiveX コントロールをブロックする組織もあれば、エンド ユーザーによるインストールを許可し、すべてのマルウェアのインストールを管理しようとする組織もあります。

悪意のあるコントロールのインストールを防ぐには、標準ユーザーの権限の制限を徹底し、必要なコントロールを IT 管理者がデスクトップ プラットフォームにすべてプレインストールしておくという方法もあります。この方法は、使用する ActiveX コントロールが変更されることが本質的に比較的少なく、定期的なリリース プロセスとデスクトップ更新の併用によって変更が管理される場合、または組織で Systems Management Server などのソフトウェア配布メカニズムを使用している場合に効果があります。しかし、継続的な管理、社内アプリケーション開発者の刻々と変化するニーズ、外部コントロールへの依存などが、引き続き、こうしたアプローチの課題として残るでしょう。

ユーザーに管理者特権があると問題は異なってきます。こうしたユーザーによる承認されていないコントロールのインストールを防止することが必要になります。このような場合、ユーザーには管理者特権があるため、エンド ユーザーに ActiveX コントロールをインストールする権限があると考えられます (エンド ユーザーをローカル管理者として運用する方法は、組織に高いリスクが生じる可能性があるため、ほとんどの企業環境にはお勧めしません)。

1 つの解決策は、承認済みコントロールをホストするインターネット コンポーネント ダウンロード サーバーを社内に用意することです。この解決策では、クライアントのレジストリ内の CodeBaseSearchPath 文字列を変更する必要があります。要求された HTML ページ内に CODEBASE 属性を含むオブジェクト タグが見つかると、通常、Windows クライアントは CodeBaseSearchPath データで指定された場所にリダイレクトされます。既定では、このレジストリ文字列には、CODEBASE キーワードと、ActiveX コントロール ギャラリーのインターネット URL を含みます。インターネット コンポーネント ダウンロード サーバーを実装するには、CodeBaseSearchPath 内の既定のデータを、組織が承認済みコントロールをホストする社内サーバーの URL に置き換える必要があります。前のアプローチと同様、この解決策でも継続的な管理が必要であり、ActiveX コントロール用に社内サーバーをホストするという、コストがかかる複雑な作業が必要になります。

他にも、Internet Explorer ゾーンの URLAction を変更する、管理者が承認済みコントロールをグループ ポリシーで指定する、すべてのコントロールのインストールをファイアウォール ルールによって境界でブロックするなどの解決策もあります。しかし、おわかりのように、これらすべての方法にはそれぞれ問題があり、多くは柔軟性に欠けるため、やがて廃止されます。さらに悪いことに、これらの解決策の中には、ユーザーに管理者権限が必要なものもあります。結局、こうした解決策では、ActiveX コントロールの発行元、呼び出し元などを制御する (またはブロックする) など、問題の一部に対処しようとしていますが、管理者権限のないユーザーが ActiveX コントロールをインストールできないという根本的な問題は軽減されません。

AxIS で可能な作業

企業管理者は Windows Vista の AxIS を使用して、ユーザーを既定のファイル システム設定を持つ標準ユーザーとして実行させることで、強力なセキュリティ体制を維持したまま ActiveX コントロールを管理することができます。AxIS には、ActiveX コントロールの信頼できる発行元を構成するためのグループ ポリシー オプション、およびこれらの信頼できる発行元から標準ユーザーに代わってコントロールをインストールする仲介プロセスがあります。主なメリットは、管理制御を一元的に行うと同時に、管理以外のセキュリティ体制をユーザーのワークステーションでメンテナンスできることです。AxIS では、ActiveX コントロールの信頼できる発行元 (通常、インターネットまたはイントラネットの URL) の特定は IT 管理者が行います。オブジェクト タグから Internet Explorer にコントロールの実行指示が出ると、AxIS によって次の手順が実行されます。

1. コントロールがインストールされているかどうかチェックします。インストールされていなければ、使用前にインストールする必要があります。
2. コントロールが信頼できる発行元からのものかどうか確認するために、AxIS のポリシー設定をチェックします。特定チェックで、オブジェクト タグの CODEBASE 属性で指定された URL のホスト名を、ポリシーで指定された信頼できる場所の一覧と照合します。
3. ユーザーに代わって、コントロールのダウンロードとインストールを行います。

発行元 URL のホスト名が AxIS のポリシー設定の一覧にない場合は、通常のユーザー アカウント制御 (UAC) プロンプトが起動され、インストールを完了するために管理者権限が要求されます。また、AxInstallService をソースとする ID 4097 のイベントがアプリケーション イベント ログに記録され、試行された ActiveX コントロールのインストールの概要とコントロールの具体的なダウンロード パスが示されます。4097 イベントの例を図 2 に示します。企業管理者は、このイベント ログ エントリのデータを使用してグループ ポリシーを変更でき、次にその Web サイトにアクセスする際に AxIS によってコントロールをインストールできるようになります。

図 2** 4097 AxInstallService イベント **

AxIS は、Windows Vista Business、Enterprise、および Ultimate の各 SKU に付属するオプション コンポーネントで、無人オプションまたは [Windows の機能] ダイアログ ボックス (コントロール パネルで、[プログラム]、[プログラムと機能]、[Windows の機能の有効化または無効化] の順にクリック) を使用して有効にすることができます (図 3 参照)。一度有効にすれば、Internet Explorer からコントロールが要求されるたびに上記の手順が実行されます。

図 3** コントロール パネルで AxIS を有効にする **

Windows Vista では、タスクをイベントに添付できるので、管理者は、ActiveX コントロールのインストールがブロックされる際などに AxIS サービスから簡単に通知を受け取ることができます。必ずしも、エンド ユーザーが各自の Web サイトからアクセスしているのと同じ URL ホスト名から ActiveX コントロールがインストールされるとは限らないことに注意が必要です。このため、AxInstallService 4097 (試行されたインストール) イベントによって提供される情報は、コントロールのインストールがどのホストから試みられたかを特定するのに非常に役立つことがあります。

イベントから提供される情報を使用して、グループ ポリシー内の信頼できる場所を構成することができます。ローカル ポリシーまたはグループ ポリシー内の AxIS 設定は、[コンピュータの構成] の設定にあります (図 4 参照)。“ActiveX コントロールの承認されたインストール サイト” のポリシー設定で、信頼できる場所のホスト URL を指定することができます (図 5 参照)。承認されたサイトの設定には、ActiveX コントロールのインストール元となる可能性のある場所、およびインストールの動作という 2 つの情報が必要です。

図 4** グループ ポリシー オブジェクト エディタの設定 **

図 5** AxIS によって承認されたインストール サイト **

1 つは、前述のように、コントロールの信頼できる場所を示すホスト URL です。従来の解決策では、コントロールの CLSID (開発者がコントロールを改訂すると頻繁に変更されます) を認識している必要がありましたが、AxIS ではこうした解決策とは異なり、信頼できる場所からすべてのコントロールをインストールすることができ、全体的な管理上の負担が軽減されます。もう 1 つの情報は、4 つの値をコンマで区切った文字列で、それぞれの値が ActiveX コントロールのダウンロード エクスペリエンスの動作を指定します。これらの値は、TPSSignedControl、SignedControl、UnsignedControl、ServerCertificatePolicy という 4 つのプロパティを指定します。最初の 2 つのプロパティ (TPSSignedControl と SignedControl) には、0、1、2 のいずれかの値を指定できます。これらの値は、URLAction の設定値と似ています。値が 0 の場合はコントロールのインストールは禁止され、値が 1 の場合はユーザーにインストールの許可を求めるメッセージが表示され、値が 2 の場合はユーザーに代わってコントロールがサイレントにインストールされます。未署名のコントロールはサイレントにインストールできないので、UnsignedControl の値には 0 か 1 しか指定できません。ポリシーが指定されていない場合、既定値の 2、1、0 が使用されます。

最後のプロパティは、署名済みコントロールの証明書の設定を基に、インストールの動作を指定します。ほとんどの SSL サイトと同様、証明書が有効であることを保証するためには、その証明書が一連のセキュリティ テストに合格する必要があります。現実の署名済み ActiveX コントロールの実装では、証明書のプロパティが無効になっていることがあります。管理者は AxIS を構成することで、証明書から提示されることのある無効な情報を URL 単位で軽減することができます。最後のプロパティは、図 6 に示す、値のビットマスクの組み合わせとして表されます。

Figure 6 ServerCertificatePolicy

既定の設定は 0 であり、AxIS によってインストールが完了する前に、すべてのセキュリティ チェックに合格する必要があることを意味します。ホストの設定とこれらの 4 つの値の組み合わせは、ポリシー設定で指定されます (図 7 参照)。

図 7** 承認された AxIS ホスト URL **

まとめ

AxIS を使用すると、管理者特権や複雑な構成なしでユーザーがインストールできる ActiveX コントロールを制御するように、グループ ポリシーを構成できます。このレベルの制御は、以前のバージョンの Windows では困難な場合があり、また従来から使用できる解決策には、多くの場合、深刻な制限や管理オーバーヘッドの増加が伴いました。AxIS では、デスクトップ システムのエンド ユーザーの権限に対して最小特権アプローチをとるためのさらなるツールを組織に提供し、エンド ユーザーに管理者特権が必要ない、標準ユーザー モデルの実装を可能にします。Windows Vista を使用すると、企業環境内で信頼する ActiveX コントロールをエンド ユーザーではなく組織が決定し、選択できることにより、IT 管理者が再び主導権を握ることができます。

Rob Campbell は、マイクロソフトの連邦政府チームのシニア テクニカル スペシャリストです。米国連邦政府の顧客向けにセキュリティ ソリューションを開発し展開することを専門としています。

Joel Yoker は、マイクロソフトの連邦政府チームのシニア コンサルタントです。米国連邦政府の顧客向けにセキュリティ ソリューションを開発し展開することを専門としています。

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