.NET Code Access Security: полезно или просто слишком сложно? - PullRequest
Новая
       5

.NET Code Access Security: полезно или просто слишком сложно?

14 голосов
/ 26 июня 2009

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

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

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

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

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

Ответы [ 4 ]

7 голосов
/ 26 июня 2009

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

4 голосов
/ 26 июня 2009

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

1 голос
/ 26 июня 2009

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

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

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

0 голосов
/ 23 марта 2010

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

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

  1. Модификаторы стека-обхода: Deny, PermitOnly

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

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

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

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

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

...