14

「コードアクセスセキュリティ」は実際に使用されていますか？も参照してください。

これについて他の意見を聞きたいです...

デスクトップアプリケーション用のコードアクセスセキュリティのアイデアが好きです。しかし、.NETの存続期間中、CASが実際に私の利益のために何かをブロックしたという状況が実際に発生したことは一度もないことを認めなければなりません。

ただし、マップされたドライブ間で高速の.NETアプリケーションを共有するだけの簡単なことが、エンタープライズコードアクセスの悪夢になることが何度もありました。信頼できるパスルールを作成するためにcaspol.exeを分割する必要があり、何かが失敗した理由を明確に知る方法がないため、CASはセキュリティで提供するよりも開発および展開プロセスにはるかにフラストレーションを加えるように見えます。

CASが実際に害を及ぼすだけでなく、現在の実装とデフォルトに不満を持っている人が他にいる場合の状況を聞きたいと思います。

4

4 に答える 4

7

.NET チーム自身も、アセンブリ アクセス セキュリティが .NET#4 用に作り直されているという同じ結論に達しました。詳細については、このブログをご覧ください: .NET セキュリティ ブログ

于 2009-06-26T05:39:38.373 に答える
4

ここここ！私は同じ欲求不満の多くを共有しました。そしてもちろん、過度に複雑で恐ろしいドキュメントは、基本的に開発者がそれをバイパスするか、過度に広いルールを使用することを奨励します。セキュリティは誰にとっても常に難しいものですが、CASを正しく実行することは非常に困難です。

于 2009-06-26T04:04:01.810 に答える
1

CASに対処する必要がありましたが、数十台のワークステーションにデプロイするだけでよいので、それほど難しくはありませんでした。グループポリシーを使用して、必要な設定をプッシュすることもできます。

しかし、あなたの質問に答えるために、いいえ、私はそれがこれまで役に立たなかったと思います。

ただし、明るい面を見てください。.NET3.5以降では、CASなしでネットワーク共有全体でアプリを実行できます。

于 2009-06-26T04:12:23.153 に答える
0

よく検索した結果、CLR チームからのこのブログ エントリに出くわしました。これは、.NET 4 で CAS がなくなることを確認するだけでなく、何が壊れ、新しいサンドボックス モデルに移行する方法についての優れたガイドも提供します:新しいセキュリティ モデル: より良いサンドボックスへの移行。記事から：

v4 より前のバージョンの .Net Framework では、アセンブリのアクセス許可、またはアセンブリ内の特定のコード パスさえも制限する多くの方法がありました。

  1. スタック ウォーク修飾子: Deny、PermitOnly

  2. アセンブリ レベルの要求: RequestOptional、RequestRefuse、RequestMinimum

  3. ポリシーの変更: caspol、および AppDomain.SetPolicyLevel

  4. MyComputer 以外のゾーンでアセンブリをロードする

これまで、これらの API は、ホストおよびアプリケーションの作成者にとって混乱の原因でした。.Net Framework 4 では、アクセス許可を制限するこれらの方法は廃止され、将来的に削除される予定です。

最も厄介なのは、サンドボックスを作成するこれらの非推奨の方法がすべてNotSupportedException. これは、何らかの理由で現時点で組織に CAS を実装する必要がある貧しい魂 (私のような) にとって非常に不安定です。あなたは警告されました。

于 2010-03-23T16:00:19.630 に答える