私には、ほとんどの開発者がこの機能を完全に無視しているようです。人々は、セキュリティを強化する CAS の方法を使用することを学ぶよりも、標準的な Windows の役割と権限に依存する一般的なものとしてセキュリティ例外を処理することを好みます。おそらく、CAS はそのロジックと命名において非常に混乱しているためです。
クリーンな方法で最高の状態で CAS を使用するための一般的な経験則/ベスト プラクティスを提案できる人はいますか?
2 に答える
3
はいといいえ。
残念ながら、その通りです。開発者がCASを使用することはめったになく、CASを最大限に活用することは言うまでもありません。ごくわずかな状況で、彼らが実際にこれを行っているのを目にします（わかりました、実際にはプログラマーではなく、組織が彼らを強制しています...）
ユーザーがインターネットからダウンロードするアセンブリを制限できるようにするために使用されることに加えて（たとえば）、これがSilverlightの外部に展開されることはめったにありませんが、CASの2つの主な用途を見てきました。
1つは、一般的なポリシーの制限です。これは、CASで足を濡らす最も簡単な方法です（特に、VSがポリシーファイルを自動生成できるため）。機密性の高い企業（銀行など）が、安全でなければならないシステムのサードパーティのカスタム開発を行っている場合に、これが（まれに）使用されているのを目にしました。これは、プログラマーが行っていることを知らないことに追加の制限を追加することで、彼らに利益をもたらす可能性があります。
2つ目は、モジュールが比較的高い特権で実行されていて、特定のアセンブリのみをモジュールに呼び出したいという（これもまれな）状況での、非常に具体的なリンク要求です。たとえば、先週、ActiveDirectoryに書き込むモジュールを備えたクライアントがあり、特定のシステムからのみこの関数へのアクセスを制限したいと考えていました。
もちろん、CASはこれよりもはるかに大きいですが、これらは実際に開始するのに最適な2つの場所です。原則として、これはもちろんすべてに当てはまりますが、必要に応じない限り、そこにあるという理由だけで使用することを決定しないでください。ポリシーは最も単純であり、事前に実施するのが最も理にかなっています。
于 2008-10-05T00:18:24.263 に答える
2
この議論も参照してください。
多くのコード (おそらく多すぎる) が完全な信頼で実行されるため、問題は悪化します。そして、実行される唯一のチェックは PrincipalPermissionAttribute チェックのようなものです - 残りのほとんどは単純にバイパスされます。したがって、多くの場合、あまり意味がありません。外部の (信頼されていない) ファイルを読み込んでいない限り [したがって CAS が必要です]、多くの場合、多くの追加はありません (もちろん、多くの例外があります)。
CAS は、サンドボックスで実行されているクライアント (たとえば、インターネットからダウンロードしたもの) にとってはるかに便利です。Sliverlight は、通常の .NET よりも厳しい規則 (特にリフレクションに関する) を使用して、これを極限まで進めています。
于 2008-10-04T21:12:27.557 に答える