Сводка изменений в функции управления доступом для кода
В .NET Framework 4 произошли серьезные изменения системы управления доступом для кода (CAS) с целью упрощения системы безопасности. В предыдущих версиях платформы .NET Framework права управляемого приложения определялись правилами политики безопасности, которые устанавливались на уровне компьютера для задания параметров среды выполнения. Начиная с .NET Framework 4:
Политика безопасности больше не применяется. Разрешения по-прежнему используются; убрана только система политики.
Права доступа для приложений определяются двумя факторами: их разрешениями (набор прав, определяемый доменом приложения) и их прозрачностью. Все приложения с частичным доверием классифицируются как прозрачные. Прозрачным приложениям не обязательно заботиться о безопасности. Прозрачность была впервые использована для Microsoft Silverlight, а теперь распространена на все размещенные среды.
Приложениям, установленным на локальном компьютере и в локальной интрасети, предоставляется полное доверие.
.gif "Важное примечание") Важно |
|---|
Значительным изменением в системе управлении доступом для кода (CAS) является устранение политики безопасности.Сама система CAS сохранена; просто теперь не используются политики (и некоторые запросы разрешения). |
В этом разделе приводится краткое общее описание изменений системы CAS в .NET Framework 4. Дополнительные сведения см. в разделе Изменения системы безопасности в платформе .NET Framework 4.
Изолирование в "песочнице" и модель разрешений
В следующем списке описывается модель доверия, используемая в .NET Framework 4 для приложений, установленных на локальном компьютере, и для размещенных приложений. Дополнительные сведения см. в разделе Изменения системы безопасности в платформе .NET Framework 4.
Приложения, установленные на локальном компьютере. В предыдущих версиях платформы .NET Framework управляемым приложениям, установленным на локальном компьютере (если они не были загружены из Интернета), предоставлялось полное доверие. Приложениям, установленным в общих папках локальной интрасети, также предоставлялось полное доверие. Теперь больше нельзя использовать политику для ограничения разрешений, предоставляемых приложению, в зависимости от того, в какой папке на локальном жестком диске оно находится.
Размещенные приложения. Приложениям, выполняемым в "песочнице" (например, приложения на основе Silverlight), предоставляется ограниченный набор разрешений, определяющих, к каким ресурсам компьютера они могут обращаться (например, какие файлы разрешено использовать). "Песочницы" предоставляют возможность идентифицировать некоторые сборки в "песочнице" как частично доверенные, а некоторые — как полностью доверенные. Сборкам с частичным доверием предоставляется определенный набор разрешений, определяемый доменом приложения (System.AppDomain), создавшего песочницу. Некоторый полностью доверенный код из полностью доверенных библиотек может вызываться частично доверенным кодом. Такой доверенный код может вызывать защищенные ресурсы компьютера. Однако общедоступные полностью доверенные типы и члены, обращающиеся к защищенным ресурсам, должны пройти аудит безопасности. Такие члены классифицируются как критические с точки зрения безопасности в соответствии с обсуждением из следующего раздела. Они могут вызываться частично доверенным (прозрачным) кодом и, в свою очередь, могут вызывать критический код.
Прозрачность безопасности
Прозрачность безопасности разделяет критический для безопасности код и код, некритический с точки зрения безопасности. Она была введена в .NET Framework 2.0 для упрощения аудита безопасности путем пометки кода, который должен выполнять критические с точки зрения безопасности действия, как критического для безопасности. Это означает, что любой код, не являющийся критически важным для безопасности (то есть, прозрачный код) не требует тщательного изучения. Однако в этих ранних версиях платформы .NET Framework прозрачность использовалась только кодом Microsoft.
В .NET Framework 4 данная модель была расширена, при этом были ужесточены правила, чтобы превратить прозрачность безопасности в принудительную модель. Такая расширенная модель упрощает идентификацию важного с точки зрения безопасности кода, который может вызываться частично доверенными приложениями. Это приводит в дальнейшему уменьшению контактной зоны, требующей аудита.
В следующей таблице приведены категории прозрачности и связанные с ними атрибуты для пометки кода.
Категория безопасности |
Атрибут |
Описание |
|---|---|---|
Прозрачный |
Код, не выполняющий никаких действий, по свой сути важных с точки зрения безопасности. |
|
Critical |
Код, который может выполнять любые действия, но не может вызываться из частично доверенных приложений. |
|
Критически важный для безопасности |
Код, который может выполнять любые действия и может вызываться из частично доверенных приложений. Это уровень безопасного посредничества; он предназначен для выполнения необходимых проверок безопасности и подтверждения перед вызовом критического кода. |
Прозрачный код не может выполнять указанные ниже действия, независимо от предоставленных ему разрешений.
Содержать непроверяемый код.
Использовать вызов неуправляемого кода.
Выполнять операции Assert.
Вызывать критический код.
Являться производным от критического кода.
Вызывать код, защищенный LinkDemand (то есть, код, считающийся критическим).
Если ваш код пытается нарушить эти правила, возникают исключения (даже если ваш код обладает полным доверием). Дополнительные сведения см. в разделе Изменения системы безопасности в платформе .NET Framework 4.
Обратите внимание, что критичность с точки зрения безопасности определяется в среде CLR как действия, запрещенные для прозрачного кода. Модель прозрачности не защищает от нарушений безопасности, специфических для сценариев, таких как сохранение паролей в полях.
Принцип работы модели безопасности
С каждым доменом AppDomain связан набор разрешений, который в сценариях с размещением определяется узлом. (Для кода, который не является размещенным, в качестве набора разрешений используется полное доверие.)
Частично доверенный код всегда прозрачен; поэтому он не может выполнять действия, запрещенные для прозрачного кода (см. прозрачность).
По умолчанию полностью доверенный код является критическим, если он не был помечен как прозрачный. Если приложение, установленное на локальный компьютер, помечено как прозрачное, оно не может вызывать критический код, несмотря на то, что является полностью доверенным.
Доступ к библиотекам может предоставляться частично доверенному коду как узлом, так и платформой .NET Framework. Эти библиотеки содержат сочетание прозрачного, критического и критического для безопасности кода.
Критический с точки зрения безопасности код перед выполнением критических функций должен требовать соответствующие разрешения. Например, метод File.Open перед открытием файла требует разрешение FileIOPermission.
Критический с точки зрения безопасности код должен также выполнять любые другие проверки перед обращением и после обращения к критическим функциям. Например, может потребоваться фильтрация исключений и сообщений перед их передачей частично доверенному коду.
Если критический код вызывается из частично доверенного кода, критический код должен утверждать требуемые разрешения, так как он может выполнять операции, запрещенные для частично доверенного кода.