解説 インサイド .NET Framework ［改訂版］ 第8回　コード・アクセス・セキュリティ（その3） 吉松 史彰 2003/08/27

---

ポリシーの組み合わせ

　上記で解説しているとおり、アセンブリがロードされると各階層のポリシーがそれぞれ検索され、適用される。つまり、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ベースのライブラリやアプリケーションの中には、行儀の悪いことに、セットアップ・プログラムの中でポリシーを書き換えてしまうものが存在する。しかし、ポリシーの書き換えは管理者の専権事項なので、このようなアプリケーションを開発することは、そのベンダがセキュリティに無頓着であることを宣言することにほかならない。

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

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

　

「解説：インサイド .NET Framework ［改訂版］」

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