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

Question

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

Может ли кто-нибудь предложить какие-либо общие правила или рекомендации по использованию CAS в лучшем виде чистым способом?

Answer 1

Да и нет.

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

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

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

Answer 2

См. Также this discussion.

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

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