Кто-нибудь действительно использует Code Access Security для защиты своих сборок и / или методов? - PullRequest
4 голосов
/ 04 октября 2008

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

Может ли кто-нибудь предложить какие-либо общие практические правила / лучшие практики для чистого использования CAS в своих лучших проявлениях?

Ответы [ 2 ]

3 голосов
/ 05 октября 2008

Да и нет.

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

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

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

2 голосов
/ 05 октября 2008

См. Также это обсуждение .

Проблема исчерпана, потому что большая часть кода (возможно, слишком большая) выполняется с полным доверием. И затем единственные проверки, которые выполняются, это такие вещи, как проверки PrincipalPermissionAttribute - большинство остальных просто обойдены. Так что во многих случаях нет особого смысла! Если вы не загружаете внешние (ненадежные) файлы [и, следовательно, нуждаетесь в CAS], во многих случаях это просто не добавляет много (и да, существует множество исключений).

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

...