CASを正確に扱うのが難しいのはよく知られている。開発者が何らかのコードブロックに対してCASの設定を間違って適用してしまっても、その間違いを通知してくれるようなフィードバックはほとんど得られない。全く警告されないこともある。さらに、管理者にとってはもっと容認し難い状況が生まれる。というのは、CASの許可のポリシーは手動で設定しなければならないが、アプリケーションにどんな許可が必要かわかる場合はほとんどない。さらに悪いことに、.NETのバージョンごとにポリシーを作り直さなければならない。
結局、CASはセキュリティのための仕組みというより、セキュリティシアター(安心感が得られるだけで実際のセキュリティ向上には寄与しない仕組み)になってしまった。例えば、既定では共有フォルダ上の実行可能ファイルは、共有フォルダからローカルへコピーした実行可能ファイルとは異なった許可セットを持っている。また、アンマネージドの実行可能ファイルには、CASは全く適用されない。
.NET 4.0では、グローバルなCASのポリシーは既定で無効になる。代わりにシステム管理者には、WindowsのSoftware Restriction Policiesのような効果的な方法を使うことが推奨されている。もじCASが必要なら、アプリケーションごとにapp.configファイルで設定できる。app.configファイルのruntime/NetFx40_LegacySecurityPolicyenabledフラグをtureにすればいい。
また、普通に実行されるコードは既定では完全に信頼されている。この場合、許可はアプリケーションドメインのレベルで付与される。従って、複数のセキュリティレベルをあわせたポリシーを単一のアプリケーションドメインに適用されている。そして実際は、実行するアセンブリの配置URLを指定してAssembly.LoadFromメソッドが呼ばれる。このURLは完全に信頼されている。
さらに、ホストされているマネージドコードは、ホストによって決められた許可セットが設定されているサンドボックス上で実行される。SQLCLR上で実行されるマネージドアセンブリもインターネットからインストールされたクリックワンスアプリケーションも同じ仕組みだ。サンドボックス化されたアプリケーションドメインでは、アセンブリは部分信頼でも完全信頼でも実行できる。スタックの検証やリンク確認要求のような複雑な仕組みは必要ない。
この新しいセキュリティモデルでは、アプリケーションドメインが作成されたとき、部分信頼のアセンブリに適用される権限の付与をすべて明示しなければならない。同じとき、完全信頼のアセンブリはそのままアプリケーションドメインに含むことができる。
このモデルではコードを3つに分類している。最も高いレベルは“Critical”で、なんでもできる完全信頼のコードが分類される。最も低いレベルは“Transparent”で、このレベルに分類されるコードはCriticalのコードを直接呼ぶことはできない。両レベルの橋渡し役が“Safe Critical”に分類されるコードだ。TransparentとCriticalのコードは適用する場合を考えやすい。Transparentに分類されるコードはサンドボックス内で強く拘束されているし、Criticalに分類されるコードはまったく制限されていないからだ。しかし、Safe Criticalに分類されるコードについては気をつけなければならない。このレベルに分類されるコードは稀で、よく検証する必要がある。カーネルとユーザスペースを橋渡しするようなコードを書く場合、Safe Criticalに分類されるコードの部分に誤りがあったら悲惨なことになるだろう。
もしこのモデルをどこかで見たことがあるとしても、それは当然のことだ。というのは、このモデルはLevel 2 Security Transparencyとして知られ、Silverlightでは既に実績がある。MSDNのLevel 2 Security Transparencyについての記事を読めば詳細を知ることができる。