Прозрачный с точки зрения безопасности код, уровень 1
Прозрачность позволяет разработчикам создавать более безопасные библиотеки .NET Framework, предоставляющие частично доверенному коду доступ к функциям. Прозрачность уровня 1 была представлена в платформе .NET Framework версии 2.0 и в основном использовалась только корпорацией Майкрософт. Начиная с версии .NET Framework 4, разработчики могут использовать прозрачность уровня 2. При этом прозрачность уровня 1 была сохранена, что позволяет определить устаревший код, который необходимо запускать с прежними правилами безопасности.
.gif "Важное примечание") Важно |
|---|
Прозрачность уровня 1 следует указывать только для совместимости, то есть уровень 1 следует отмечать только в коде, разработанном в платформе .NET Framework 3.5 или ранее и использующем AllowPartiallyTrustedCallersAttribute или не использующем модель прозрачности.Например, используйте прозрачность уровня 1 для сборок .NET Framework 2.0, которые допускают вызовы от частично доверенных вызывающих объектов (APTCA).Для кода, разработанного в .NET Framework 4, следует использовать прозрачность уровня 2. |
В этом разделе содержатся следующие подразделы.
Модель прозрачности уровня 1
Атрибуты прозрачности
Примеры использования прозрачности безопасности
Модель прозрачности уровня 1
При использовании прозрачности уровня 1 применяемая модель безопасности разделяет весь код на методы, прозрачные, надежные и критические с точки зрения безопасности.
Пометить как прозрачную для системы безопасности можно всю сборку, некоторые классы сборки или некоторые методы класса. Прозрачный для системы безопасности код не может повышать уровень привилегий. Это ограничение имеет три последствия:
Прозрачный с точки зрения безопасности код не может выполнять действия Assert.
Требования связывания, которым должен удовлетворять прозрачный для системы безопасности код, становятся полными требованиями.
Небезопасный (непроверяемый) код, который должен выполняться в рамках прозрачного для системы безопасности кода, вызывает полное требование для разрешения безопасности UnmanagedCode.
Выполнение этих требований в процессе работы кода обеспечивается средой CLR. Прозрачный для системы безопасности код передает все требования безопасности кода, возвращаемого вызывающему объекту. Требования, которые обрабатываются прозрачным для системы безопасности кодом, не могут повышать уровень привилегий. Если приложение с низким уровнем доверия обращается к прозрачному для системы безопасности коду и вызывает требование высокой привилегии, это требование будет перенаправлено обратно в код с низким уровнем доверия и не будет удовлетворено. Прозрачный с точки зрения безопасности код не может приостановить действие требования, поскольку он не может осуществлять действия Assert. При вызове того же прозрачного для системы безопасности кода из кода с полным доверием требование будет удовлетворено.
Критические важные для безопасности методы являются противоположностью прозрачных для системы безопасности методов. Критически важный для безопасности код выполняется с полным доверием и может выполнять операции с любым уровнем привилегий. Надежный с точки зрения безопасности код является привилегированным кодом, прошедшим расширенный аудит безопасности, в результате которого было подтверждено, что он не позволяет частично доверенным вызывающим объектам использовать ресурсы, на доступ к которым у них нет разрешения.
Прозрачность необходимо применять явно. Большая часть кода, отвечающая за обработку данных и логику, обычно может быть помечена как прозрачная для системы безопасности, в то время как меньшая часть, выполняющая повышение привилегий, помечается как критически важная для безопасности или защищенная, критически важная для безопасности.
| Важно |
|---|
Прозрачность уровня 1 ограничена областью сборки; она не применяется между сборками.Прозрачность уровня 1 первоначально использовалась в продуктах Майкрософт для целей аудита безопасности.К критически важным для безопасности типам и членам сборки уровня 1 может получать доступ прозрачный для системы безопасности код из других сборок.Очень важно выполнять запросы компоновки с полным доверием во всех критически важных для безопасности типах и членах уровня 1.Защищенные, критически важные для безопасности типы и члены также должны подтверждать, что вызывающие объекты обладают разрешениями на защищенные ресурсы, доступ к которым осуществляется типом или членом. |
Для обеспечения обратной совместимости с предыдущими версиями .NET Framework все члены, не аннотированные атрибутами прозрачности, считаются защищенными, критически важными для безопасности. Все непомеченные типы считаются прозрачными. Для проверки прозрачности не существует правил статического анализа. Поэтому может потребоваться отладка ошибок времени выполнения, связанных с прозрачностью.
Атрибуты прозрачности
В следующей таблице приводится описание трех атрибутов, используемых для указания прозрачности кода.
Атрибут |
Описание |
|---|---|
Применяется только на уровне сборки. Помечает все типы и участники внутри сборки как прозрачные с точки зрения системы безопасности. При этом сборка не может содержать критичный в плане безопасности код. |
|
При использовании на уровне сборки без свойства Scope помечает весь код внутри сборки как прозрачный для системы безопасности по умолчанию, однако показывает, что сборка может содержать критически важный для безопасности код. При использовании на уровне класса помечает класс или метод как критически важный для безопасности. Чтобы пометить все члены как критически важные для безопасности, установите для свойства Scope значение Everything. При использовании на уровне члена атрибут применяется только к этому члену. Класс или метод, помеченный как критически важный для безопасности, может осуществлять повышение привилегий. Важно
В прозрачности уровня 1, если критически важные для безопасности типы и члены вызываются из-за пределов сборки, они считаются защищенными, критически важными для безопасности.Чтобы предотвратить неавторизованное повышение привилегий, необходимо защитить критически важные для безопасности типы и члены запросом на компоновку с полным доверием.
|
|
Помечает критически важный для безопасности код, доступ к которому может получить прозрачный для системы безопасности код в сборке. В противном случае, прозрачный для системы безопасности код не может получить доступ к закрытым или внутренним членам, критически важным для безопасности, внутри этой же сборки. Возможность такого доступа могла бы повлиять на работу критически важного для безопасности кода и сделать возможным непредусмотренное повышение привилегий. Защищенный, криттически важный для безопасности код должен проходить строгий аудит безопасности. .gif "Примечание") Примечание
Защищенные, критьически важные для безопасности типы и члены должны проверять разрешения вызывающих объектов, чтобы определить, имеют ли они право на доступ к защищенным ресурсам.
|
Атрибут SecuritySafeCriticalAttribute позволяет прозрачному для системы безопасности коду получать доступ к критически важным для безопасности членам внутри этой же сборки. Следует стараться разграничивать прозрачный для системы безопасности и критичный в плане безопасности код внутри сборки, как если бы он принадлежал двум разным сборкам. Прозрачный для системы безопасности код не сможет получать доступ к закрытым или внутренним членам критичного в плане безопасности кода. Кроме того, для критичного в плане безопасности кода обычно применяется контролируемый доступ к его открытому интерфейсу. Доступ к закрытому или внутреннему состоянию извне сборки обычно является нежелательным. Как правило, стремятся изолировать это состояние. Атрибут SecuritySafeCriticalAttribute обеспечивает изоляцию состояния между прозрачным для системы безопасности и критичным в плане безопасности кодом, но в то же время дает возможность при необходимости переопределить изоляцию. Прозрачный для системы безопасности код может получить доступ к закрытым или внутренним членам критически важного для безопасности кода, только если эти члены помечены атрибутом SecuritySafeCriticalAttribute. Перед применением атрибута SecuritySafeCriticalAttribute проведите аудит соответствующего члена, как если бы он был открытым.
Аннотация на уровне сборки
В следующей таблице описываются последствия использования атрибутов безопасности на уровне сборки.
Атрибут сборки |
Состояние сборки |
|---|---|
Частично доверенная сборка без атрибутов |
Все типы и члены являются прозрачными. |
Полностью доверенная сборка без атрибутов (находящаяся в глобальном кэше сборок или помеченная как полностью доверенная в AppDomain) |
Все типы являются прозрачными, а все члены — средне важными для безопасности. |
SecurityTransparent |
Все типы и члены являются прозрачными. |
SecurityCritical(SecurityCriticalScope.Everything) |
Все типы являются критически важными для безопасности. |
SecurityCritical |
Код становится прозрачным по умолчанию. Однако отдельные типы и члены могут иметь другие атрибуты. |
Примеры использования прозрачности безопасности
Чтобы использовать правила прозрачности платформы .NET Framework 2.0 (прозрачность уровня 1), следует использовать в сборке следующую заметку:
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Если требуется сделать прозрачной всю сборку, указав тем самым, что она не содержит критичного кода и не может повышать уровень привилегий, можно задать прозрачность для сборки явным образом с помощью следующего атрибута:
[assembly: SecurityTransparent]
Если сборка должна содержать как критичный, так и прозрачный код, сначала следует применить атрибут SecurityCriticalAttribute ко всей сборке, чтобы указать на возможность включения в нее критичного кода. Это можно сделать следующим образом.
[assembly: SecurityCritical]
При необходимости выполнения критичных в плане безопасности операций необходимо явно применить еще один атрибут SecurityCriticalAttribute к коду, выполняющему критичную операцию, как показано в следующем примере кода.
[assembly: SecurityCritical]
Public class A
{
[SecurityCritical]
private void Critical()
{
// critical
}
public int SomeProperty
{
get {/* transparent */ }
set {/* transparent */ }
}
}
public class B
{
internal string SomeOtherProperty
{
get { /* transparent */ }
set { /* transparent */ }
}
}
Вышеприведенный код является прозрачным за исключением метода Critical, который явным образом помечен как критически важный для безопасности. Прозрачность задается по умолчанию даже при установленном на уровне сборки атрибуте SecurityCriticalAttribute.