Безопасность доступа к коду .NET:Полезно или просто слишком сложно?

Question

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

Хочу узнать еще мнения по этому поводу...

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Однако обратите внимание на положительную сторону: начиная с .NET 3.5 вы можете запускать приложения в общей сетевой папке без CAS.

Answer 4

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

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

1. Модификаторы стека:Запретить, Только разрешить

2. Запросы на уровне сборки:RequestOptional, requestRefuse, requestMinimum

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

4. Загрузка сборки с зоной, отличной от MyComputer

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

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