Code Access Securityは、.NET 4 Beta 2では、もう使用されない

作者 Abel Avram , 翻訳者 編集部Ｎ 投稿日 2010年1月31日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

.NET ,

セキュリティ

原文(投稿日：2010/01/26)へのリンク

.NET Framework 1.0から、Microsoftは、 Code Access Security (CAS)を、マネージコードの能力を割り当てたり、コントロールする手段として導入した。Framework 4.0 Beta 2では、CASを非推奨にして、既定ではオフにする、そして Security Transparency Level 2を導入する。

Javaに対して、.NETが優位を得るのに役立つ、すばらしいフィーチャだ、とかつては考えられたが、その複雑さと、もし適切に使われないとセキュリティホールを実際に作ってしまう可能性のために、.NET開発者の間では、CASは、不評だった。更に、ネイティブなアプリケーションすなわち、非マネージコードは、相変わらず、完全信頼 (FullTrust)で動作するので、CASは、それほど役に立たないものである。

.NET Framework 4.0では、CASは、オフなので、Windows Explorerあるいは、コマンドプロンプトから起動されたすべてのアプリケーションは、完全信頼で走る。ホストされた.NETアプリケーションすなわち、Internet Explorer や ASP.NET内で走るアプリケーションは、ホストから与えられた信頼レベル、部分信頼で走る。

この変更のために、現在開発中のコードは、警告や実行時例外を起こすかもしれない:

これらのセキュリティ・ポリシーの変更により、古くなったCASのポリシーのタイプやメンバを明示的にあるいは暗黙的に（他のタイプやメンバを通して）呼ぶと、コンパイラ警告になったり、実行時例外になったりするかもしれない。古くなったタイプやメンバとそれらの代替のリストについては、 Code Access Security Policy Compatibility and Migration（CASポリシーの互換性と移行）を参照。

実行時の設定スキーマにある <NetFx40_LegacySecurityPolicy> 設定要素 を使って、従来のCASポリシーの動きを選んで、警告やエラーを避けることができる。しかし、従来のセキュリティポリシーの使用を選ぶと、.NET Framework 4 Beta 2に移行しない限り、そのバージョン用のカスタムなCASポリシーは、含まないことになる。

.NET 4.0 Beta 2は、.NET 2.0で導入され、Microsoftの内部で使用されている Security Transparency （セキュリティ上の透過性）と呼ばれる以前のフィーチャを拡張している。サンドボックスで走るマネージコードは、透過的であると考えられる、そのホストによって許された操作しか実行できないので、結果的に安全であると考えられるからである。 Security Transparency Level 2 は、新しい要素を導入する:

.NET Framework 4 Beta 2では、透過性は、強制的なメカニズムで、インフラの一部として走るコードからアプリケーションの一部として走るコードを分離する。透過性は、ネイティブコードを呼ぶような特権的なことができるコード（クリティカルなコード）とそういうことができないコード（透過的なコード）の間に境界を設ける。透過的なコードは、動作している許可の範囲内で、コマンドを実行できるが、クリティカルなコードを実行したり、呼んだり、派生したり、あるいは含んだりすることは、できない。

透過性を強制することの第一の目的は、特権に基づいて、違うグループを隔離する簡単で、効果的なメカニズムを提供することである。サンドボックスのモデルでは、これらのグループは、完全信頼（すなわち、制限なし）と部分信頼（すなわち、サンドボックスに与えられた許可に限定）のどちらかだった。

デスクトップアプリケーションは、完全信頼で走る；透過性のモデルによって何も影響されない。

.NET 4.0では、３タイプのコードがある：transparent（透過的な）コード、security-safe-critical（セキュリティ上安全でクリティカルな）コード、そしてsecurity-critical（セキュリティ上クリティカル）なコードである:

• 完全信頼で走るコードを含んで、transparentなコードは、他のtransparentなコードかsecurity-safe-criticalしか呼べない。ドメインの部分信頼の（もしあれば）パーミッション・セットによって許されていることしかできない。transparentなコードは、次のことは、できない:

  • Assert あるいは、特権の昇格を実行する

  • 安全でないあるいは検証できないコードを含む

  • criticalなコードを直接呼ぶ

  • ネイティブなコードあるいは SuppressUnmanagedCodeSecurityAttribute 属性を持つコードを呼ぶ

  • LinkDemandによって守られたメンバを呼ぶ

  • critical なタイプから継承する

  更に、transparentなメソッドは、criticalな仮想メソッドをオーバーライドしたり、criticalなインターフェースのメソッドを実装したりできない。

• safe-criticalなコードは、完全信頼であるが、transparentなコードから呼ぶことができる。完全信頼コードの限られた表面をさらす。正しさとセキュリティの検証がsafe-criticalコードで行われる。

• security-criticalは、どのタイプのコードを呼ぶことができ、完全信頼である。transparentなコードから呼ぶことはできない。

もし以前の.NET Frameworkのバージョンで走るアプリケーションを作るのであれば、なおCASを使うことができるが、4.0 Beta 2とそれ以降で提供される最新のフィーチャを使うことは、できないだろう。その代わりに、 Windows Software Restriction Policies (SRP)を使うことが推奨されている。SRPは、マネージコードそしてネイティブなアプリケーションの両方に適用できる、より単純なセキュリティメカニズムを提供する。

• 次へ >