解説 インサイド .NET Framework 第11回　コード・アクセス・セキュリティ（その3） インフォテリア株式会社 吉松 史彰 2002/11/29

---

ポリシーの組み合わせ

　上記で解説しているとおり、アセンブリがロードされると各階層のポリシーがそれぞれ検索され、適用される。つまり、1つのアセンブリが複数のコード・グループのメンバーシップ条件に一致することもあり得るわけだ。例えば、あるポリシーに次のようなコード・グループが定義されていたとしよう。

コード・グループの定義例1

FileReaderアセンブリは3つのすべてのコード・グループに属する。

　このとき、前述のFileReaderアセンブリは、3つのすべてのコード・グループに属するということになる。アセンブリは同時に複数のコード・グループに属することができるのだ。ただし、同時に複数のコード・グループに属せるとはいえ、次のような構成のポリシーがあった場合には注意が必要になる。

コード・グループの定義例2

FileReaderアセンブリはCG1とCG2にのみ属することになる。

　この場合は、FileReaderアセンブリはCG1とCG2にのみ属することになる。CLRは、まずCG1とCG4を確認して、FileReaderアセンブリが提供したエビデンスは、CG1のメンバーシップ条件には一致するが、CG4のメンバーシップ条件には一致しないことを発見する。すると、この時点でCG3は検証の対象外となり、アセンブリはCG1とCG2だけに属することになるのだ。つまり、同じレベルにあるコード・グループはすべて検証の対象になるが、検証の対象から外れている親を持つ子コード・グループは検証の対象から外れてしまうということだ。見方を変えると、子コード・グループとは、「親に定義されているメンバーシップ条件に一致して、かつ自分に定義されているメンバーシップ条件にも一致する」というメンバーシップ条件を持っているともいえるだろう。複数のメンバーシップ条件のAND条件を作りたい場合は、子コード・グループを定義すればよい。

　複数のコード・グループに所属できるということは、複数のアクセス許可セットが割り当てられる可能性があるということになる。そうなると、矛盾する設定になってしまう可能性も出てくる。複数のコード・グループに属しているアセンブリに実際に適用されるアクセス許可セットはどのようなものなのだろうか。

　実は、アクセス許可セットを組み合わせるときには、和になったり積になったりするので、少々ややこしい。階層が異なると積集合となり、階層が同じだと和集合になるのだ。例えば、次のようなコード・グループにアクセス許可セットが定義されていたとしよう。

コード・グループで定義されたアクセス許可セットの例

CG1からCG6までのすべてのコード・グループに属するアセンブリには、どんなアクセス許可セットが適用されることになるのだろうか。

　このとき、CG1からCG6までのすべてのコード・グループに属するアセンブリにはどんなアクセス許可セットが適用されることになるのだろうか。まず、階層が同じ場合は、アクセス許可セットは論理和となるので、次のような結果が得られる。

エンタープライズ階層
  = Internet ∪ SkipVerification
  = （2つのアクセス許可セットに含まれるアクセス許可の和集合）
コンピュータ階層 = FullTrust ∪ Nothing ∪ Nothing = FullTrust
ユーザー階層 = FullTrust

　前述のコード（サンプル・プログラム2）の実行結果を見てほしい。デフォルトでは、エンタープライズ階層とユーザー階層のAll_Codeコード・グループにはFullTrustが設定されているが、コンピュータ階層のAll_Codeコード・グループにはNothingが設定されている。これは、コンピュータ階層の中のほかのコード・グループでFullTrust以外のアクセス許可セットを指定する必要があるからだ。いくらInternet_Zoneコード・グループでNothingを設定しても、その親であるAll_Codeコード・グループでFullTrustを指定してしまったら、2つの和集合はFullTrustになってしまい、Internet_Zoneコード・グループで設定したアクセス許可セットに意味がなくなってしまうのだ。

　次に、階層が異なるとアクセス許可セットは論理積となるので、最終的にアセンブリに適用されるアクセス許可セットは次のようになる。

最終的なアクセス許可セット
  = (Internet ∪ SkipVerification) ∩ FullTrust ∩ FullTrust
  = (Internet ∪ SkipVerification)

　つまり、まず階層ごとのアクセス許可セットが評価され、その中で最も厳しいアクセス許可セットが実際に適用されるアクセス許可セットになるということだ。これによって、ユーザーの階層でいくら緩いアクセス許可セットを作成しても、エンタープライズの階層で作成されている厳しいアクセス許可セットが実際に適用されることになるわけだ。

　前述のコードの実行結果をもう一度見てほしい。エンタープライズ階層とユーザー階層のアクセス許可セットの計算結果はFullTrustである。実際には何も設定していないも同然なので、Nothingと指定したくなるところだが、エンタープライズ階層かユーザー階層のいずれかでNothingを設定してしまうと、積集合の計算の結果は必ずNothingになってしまうのだ。積集合に影響を与えないために、FullTrustを設定しなければいけないのである。

今回のまとめ

　今回は、エビデンスを入力してアクセス許可セットを出力するポリシーについて解説した。ポリシーは、階層ごとに管理者が指定しなければならないセキュリティ上のルールである。.NET Frameworkベースのライブラリやアプリケーションの中には、行儀の悪いことに、セットアップ・プログラムの中でポリシーを書き換えてしまうものが存在する。しかし、ポリシーの書き換えは管理者の専権事項なので、このようなアプリケーションを開発することは、そのベンダがセキュリティに無頓着であることを宣言することにほかならない。

　次回はアクセス許可を取り上げて、それが適用されるタイミング、コードに対して許可が与えられているかどうかをチェックしたり、悪意のあるコードから自分自身を守るためにアクセス許可のオブジェクトを利用したりする方法などを解説する。

.NET Frameworkの普及を切に願う者からのお願い 　アプリケーションやライブラリ・ベンダの皆さんとフリー・ソフトウェアやシェアウェア作者の皆さん、セットアップ・プログラムを使って黙ってポリシーを書き換えるようなことはやめてください。そのアプリケーションを動作させるためにどうしてもポリシーの変更が必要な場合は、アプリケーションをインストールするセットアップ・プログラムと、ポリシーを変更するプログラムを別々に提供して、管理者向けにポリシー変更の影響について詳述したドキュメントを用意してください。また、下記の1行を含むプログラムを絶対に出荷しないでください。 　管理者の皆さん、外部から持ち込んだ.NET Frameworkベースのアプリケーションを、各ユーザーのローカル・コンピュータに配布する場合には、まずテスト用の環境にインストールして、インストール後のポリシーを確認してから社内に配布するようにしてください。行儀の悪いアプリケーションをチェックする方法は残念ながら1つしかありません。.NET Framework Configuration管理ツールを起動して、ポリシーの現状を確認することです。もっとも、これだけでは防ぐことができない重大な機能を.NET Frameworkが提供していることもお忘れなく。次のコードが実行されるといったい何が起きるのか、ぜひ確認してみることをお勧めします。このようなコードを実行するアプリケーションが存在しないとも限りません。残念ながら、現状ではレジストリを直接確認する以外に、このコードが実行されたかどうかを確認する方法はありません。 （C#） System.Security.SecurityManager.SecurityEnabled = false; （VB.NET） System.Security.SecurityManager.SecurityEnabled = False 　ユーザーが管理者の知らないところで勝手に行儀の悪いアプリケーションをインストールしてしまう場合、ポリシーの改ざん（あえて改ざんと書きます）を防ぐには、ポリシーのファイル（特にエンタープライズ階層用のenterprisec.configファイル）のNTFSアクセス権を厳密に設定するのが有効です。管理しているネットワークがActive Directory環境であれば、この設定はグループ・ポリシーの機能で自動化できます。グループ・ポリシーではレジストリの値を設定することも可能なので、上記のコードの実行結果を強制的に元に戻すこともできます。また、各ユーザーからマシンのAdministrator権限を取り上げるのも効果的です。 　Windows上で動作するウイルス対策ソフトウェアのベンダの皆さん、上記のコードが実行された状態で、しかもネットワークに接続されているシステムについて、ウイルス警告を発するようにしてはいかがでしょうか。 　最後にマイクロソフトさま、上記の1行が実行されたことを確認する簡単な方法を早急に提供してください。 .NET Frameworkの普及を切に願う者のうちの1人 吉松 史彰 fumiaki_y@hotmail.com * なお、上記のお願いの内容は筆者が関連する企業、団体、そのほかのグループとは一切関係ありません。上記のお願いに関する責任はすべて1人筆者個人に帰属します。そのため、メールアドレスもHotmailになっていることをご了承ください。

　

INDEX
	解説 インサイド .NET Framework
	第11回　コード・アクセス・セキュリティ（その3）
	1．コード・グループとメンバーシップ条件
	2．アクセス許可セットとは
	3．アクセス許可の一覧
	4．管理ツールによるセキュリティ・ポリシーの編集
	5．ポリシーの組み合わせ

　

「解説：インサイド .NET Framework 」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）