В модели прозрачности методы, критические с точки зрения безопасности, помечаются с помощью атрибута [SecurityCritical]:
[SecurityCritical]
public Key GetTVRoomKey() { ... }
Все “опасные” методы (содержащие код, который среда CLR считает нарушающим безопасность) должны быть помечены посредством атрибута [SecurityCritical] или [SecuritySafeCritical]. В число таких методов входят:
• непроверяемые (unsafe) методы;
• методы, которые обращаются к неуправляемому коду через P/Invoke или взаимодействие с СОМ;
• методы, которые утверждают разрешения или вызывают методы с требованиями связывания;
• методы, которые вызывают методы [SecurityCritical];
• методы, которые переопределяют виртуальные методы [SecurityCritical].
Атрибут [SecurityCritical] означает: “данный метод может разрешить вызывающей сборке с частичным доверием покинуть песочницу”.
Атрибут [SecuritySafeCritical] означает: “данный метод выполняет критические с точки зрения безопасности действия — но с соответствующими защитными мерами, поэтому он безопасен для вызывающих сборок с частичным доверием”.
Методы в сборках с частичным доверием никогда не могут вызывать подобные методы в сборках с полным доверием. Методы [SecurityCritical] могут быть вызваны только следующими методами:
• другими методами [SecurityCritical];
• методами, помеченными как [SecuritySafeCritical].
Прозрачный код
В рамках модели прозрачности все методы подпадают под одну из следующих категорий:
• критические с точки зрения безопасности;
• надежные с точки зрения безопасности;
• ни те, ни другие (в этом случае они называются прозрачными).
Прозрачные методы так называются потому, что их можно игнорировать при проведении аудита кода на предмет уязвимости к атакам повышением привилегий. Понадобится лишь сосредоточить внимание на методах [SecuritySafeCritical] (привратниках), которые обычно составляют только небольшую часть методов сборки. Если сборка состоит полностью из прозрачных методов, то вся сборка может быть помечена атрибутом [SecurityTransparent ]:
[assembly: SecurityTransparent]
После этого говорят, что сборка сама является прозрачной. Прозрачные сборки не требуют аудита на предмет уязвимости к атакам повышением привилегий и неявно позволяют обращаться вызывающим сборкам с частичным доверием — применять атрибут АРТСА не нужно.
Настройка прозрачности по умолчанию для сборки
Подводя итоги сказанному ранее, существуют два способа указания прозрачности на уровне сборки.
• Применение атрибута АРТСА. Все методы станут неявно прозрачными кроме тех, которые помечены иначе.
• Применение атрибута сборки [SecurityTransparent]. Все методы станут неявно прозрачными безо всяких исключений.
Третий способ — не делать ничего. Это по-прежнему предполагает применение правил прозрачности, но с каждым методом, неявно являющимся [SecurityCritical] (кроме любых переопределенных виртуальных методов [SecuritySafeCritical], которые останутся критическими с точки зрения безопасности). Эффект заключается в том, что ваша сборка может вызвать любой желаемый метод (предполагая наличие у нее полного доверия), но прозрачные методы из других сборок не могут обращаться к вашей сборке.
http://xrust.ru/help/297908-kak-rabotaet-model-prozrachnosti-v-net-framework.html