.NET Code Access Security: полезный или просто сложный?

см. также "Безопасность доступа к коду" любое использование в реальном мире?

Я хочу получить другие мнения по этому поводу...

Мне нравится идея Code Access Security для настольных приложений. Но в течение жизни .NET я должен признать, что у меня никогда не было ситуации, когда CAS фактически заблокировал что-то в мою пользу.

Однако у меня было много раз, когда что-то такое же простое, как обмен быстрым .NET-приложением через сопоставленный диск, становится кошмаром доступа к коду предприятия. Чтобы разбить caspol.exe для создания правил доверенного пути и не иметь четкого способа узнать, почему что-то не удалось, похоже, что CAS добавляет больше разочарования в процессе разработки и развертывания, чем это предлагает в безопасности.

Я бы хотел услышать какие-то ситуации, когда CAS действительно помог больше, чем повредить, или если есть другие люди, разочарованные его текущей реализацией и стандартами по умолчанию.

ОТВЕТЫ

Ответ 1

Команда .NET, которую они сами, согласилась с тем же самым заключением, что безопасность доступа к сборке перерабатывается для .NET # 4. Взгляните на этот блог за дополнительной информацией: . Блог безопасности NET

Ответ 2

Здесь, здесь! Я разделял многие из тех же разочарований. И, конечно же, чрезмерное усложнение и ужасная документация в основном побуждают разработчиков обойти его или использовать слишком широкие правила. Безопасность всегда будет жестким орехом для всех, но CAS действительно трудно сделать правильно.

Ответ 3

Мне приходилось иметь дело с CAS, но это было не слишком сложно, так как мне пришлось развернуть его на десятках рабочих станций или около того. Вы также можете вывести необходимые настройки с помощью групповой политики.

Но чтобы ответить на ваш вопрос, нет, я не думаю, что он когда-либо помогал.

Посмотрите на яркую сторону, хотя, начиная с .NET 3.5, вы можете запускать приложения через сетевой ресурс без CAS.

Ответ 4

После долгих поисков я наткнулся на эту запись в блоге из команды CLR, которая не только подтверждает, что CAS уходит в .NET 4, но также дает отличное руководство о том, что сломается и как перейти к новой модели sandbox: Новая модель безопасности: переход на лучшую песочницу. Из статьи:

В версиях .Net Framework до v4, у нас было много способов ограничить разрешений сборки или даже определенный путь кода в сборке:

  • Модификаторы стека: Запретить, PermitOnly

  • Запросы на уровне сборки: RequestOptional, RequestRefuse, RequestMinimum

  • Изменения политики: caspol и AppDomain.SetPolicyLevel

  • Загрузка сборки с помощью зоны, отличной от MyComputer

В прошлом эти API были источник путаницы для хоста и писателей приложений. В .Net Framework 4, эти методы ограничения разрешения отмечены как устаревшие, и мы надеемся удалить их в определенный момент в будущее.

Наиболее тревожным является тот факт, что все эти устаревшие методы создания песочницы начнут бросать NotSupportedException. Это исключительно опасно для любых бедных душ (таких, как я), которые по какой-либо причине требуются для внедрения CAS в их организации в настоящее время. Вы были предупреждены.