本当にコードアクセスセキュリティを使用してアセンブリやメソッドを保護している人はいますか？

Question

ほとんどの開発者は、この機能を完全に無視しています。 CASはセキュリティを強化する方法を学ぶことよりも、標準的なWindowsの役割と権利に依存する汎用例外としてセキュリティ例外を処理することを好むでしょう。

CASを最高の状態でクリーンに使用するための一般的な経験則/ベストプラクティスを提案できる人はいますか？

Answer 1

はい、いいえ。

残念ながら、あなたは正しいです-開発者はCASを使用することはめったにありません。ごく少数の状況で、実際にこれを実行しているのを見ます（まあ、実際にはプログラマーではなく、組織がそれらを強制します....）

ユーザーがインターネットからダウンロードされるアセンブリを制限できるようにするために使用されていることに加えて（たとえば）-これはSilverlightの外部に展開されることはめったにありません-私はCASの2つの主な用途を見てきました。
1つ目は一般的なポリシーの制限です。一般的には、CASを使用する最も簡単な方法です（VSはポリシーファイルを自動生成できるため）。機密性の高い企業（銀行など）が、安全である必要のあるシステムのサードパーティのカスタム開発を使用しているときに、（まれに）これが使用されているのを見てきました。これは、プログラマーが何をしているかわからないことに制限を追加することで、彼らに利益をもたらします。
2つ目は、非常に特殊なリンク要求です。比較的高い特権で実行されているモジュールがあり、モジュールを呼び出す特定のアセンブリのみが必要な（再びまれな）状況です。たとえば、先週、ActiveDirectoryに書き込むモジュールを持つクライアントがあり、特定のシステムからのみこの機能へのアクセスを制限したいと考えていました。

もちろん、CASはこれよりもはるかに大きくなりますが、実際には、これらが最初に最適な2つの場所です。原則として、これはもちろんすべての場合に当てはまりますが、必要があると答えない限り、使用することに決めてはいけません。ポリシーは最も単純で、事前に導入するのが最も理にかなっています。

Answer 2

このディスカッションも参照してください。

多くのコード（おそらく多すぎる）が完全な信頼で実行されるため、問題は悪化します。そして、行われる唯一のチェックは、PrincipalPermissionAttributeチェックのようなものです-残りのほとんどは単純にバイパスされます。したがって、多くの場合、あまり意味がありません！外部（信頼されていない）ファイルを読み込む場合（つまりCASが必要な場合）を除き、多くの場合、追加することはほとんどありません（そして、はい、多くの例外があります）。

CASは、サンドボックスで実行しているクライアント（たとえば、インターネットからダウンロードしたクライアント）にとって非常に便利です。 Sliverlightはこれを極限まで進めており、通常の.NETよりも厳格なルール（特にリフレクションに関するルール）を使用しています。