Использование механизмов безопасности в .NET

В настоящее время .NET становится основной платформой для разработки приложений [1,2]. Одним из основных приоритетов в разработке приложений является безопасность.
Грамотно организованная система безопасности приложения – это дополнительная гарантия сохранности и конфиденциальности данных, защита от несанкционированного доступа и многое другое [3]. Библиотека .NET Framework предоставляет для этого все необходимые средства.

Система безопасности в .NET состоит из нескольких служб, управление которыми доступно как администраторам, так и прикладным программистам. Основными из этих служб являются следующие: безопасность типов, аутентификация, авторизация, полномочия, политики безопасности, происхождение кода [3].

Безопасность типов играет одну из ключевых ролей – именно благодаря этому есть возможность изолировать сборки друг от друга, что дает возможность использовать в рамках одного процесса несколько сборок с разным уровнем доверия. Например, загрузив из интернета безопасную сборку, можно быть уверенным, что она не вызовет WinAPI функцию, которая отформатирует жесткий диск. Также есть гарантия того, что безопасный код работает с другими объектами только дозволенным способом (например, не будет пытаться вызывать private методы другого объекта). Само собой разумеется, что есть возможность отключить процесс проверки безопасности типов, однако, для того чтобы это сделать, нужны достаточно серьезные полномочия.

Аутентификация представляет собой процесс проверки регистрационной информации пользователя [3]. Приложения в .NET Framework могут использовать большинство из доступных на настоящий момент механизмов аутентификации [1]. Примерами таких механизмов аутентификации являются Digest, Passport, аутентификация на основе служб предоставляемых операционной системой либо на основе механизмов, определенных в приложении. Управляемый код может получить регистрационную информацию и роли пользователя через объект Principal (интерфейс IPrincipal), который также содержит ссылку на Identity.

Авторизация – это процесс проверки прав текущего пользователя на выполнение запрошенного действия [3]. В процессе авторизации проверяется принадлежность пользователя к определенным ролям, и на основе этой информации принимается решение о предоставлении доступа к ресурсу.

В .NET Framework код может выполнить какое-либо действие только в том случае, если у него на это есть достаточные права [1,3]. Все это контролируется специальными объектами – Permissions. В свою очередь полномочия покрывают три области:
 Code Access Permissions. Предоставляют доступ к защищенному ресурсу, либо возможность выполнить некую закрытую операцию.
 Identity Permissions. Это группа характеристик, которые идентифицируют сборку. Common Language Runtime (CLR) создает эти полномочия на основе происхождения сборки. Identity permissions позволяют защитить код от не авторизированного доступа.
 Role-based Permissions. Эта группа полномочий предоставляет механизм для проверки того, что вызывающий пользователь (либо агент, действующий от его имени) принадлежит к определенной роли.

Тут можно также отметить, что как полномочия, так и пользователи в .NET имеют мало общего с аналогичными сущностями в Windows. Как пример: права на доступ к файлу, лежащему на диске с NTFS – пользователь, запустивший .NET приложение, может иметь соответствующие права на доступ в NTFS, но CLR все равно может не предоставить доступа к диску (если приложение запущено из сети), так и наоборот – CLR может разрешить действие с файлом, но ошибка проявится уже на уровне NTFS.

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

В .NET Framework определено четыре группы политик [3]. Каждый из уровней содержит свой набор правил, на основе которых определяется, какие права можно предоставить коду.

Уровень Enterprise распространяется на каждый компьютер в домене и обычно управляется администраторами домена. По умолчанию на этом уровне всем сборкам (независимо от их происхождения) предоставляются полные права;
Уровень Machine распространяет свое действие на весь компьютер и может администрироваться локальным администратором или администратором домена. По умолчанию именно на этом уровне определяется большинство настроек безопасности.
Уровень Personal. Используется для управления настройками безопасности текущего пользователя. По умолчанию, как и на уровне Enterprise, всем сборкам даются полные права.

Уровень AppDomain. Это специальный уровень, и его настройки можно изменить только программно.
В момент загрузки кода происходит определение набора прав, которые предоставляются на каждом уровне, и после этого вычисляется минимальное множество прав, которое и будет ему гарантировано. И, если не менять никаких настроек, все реальные права определяются на уровне Machine (все остальные уровни предоставляют полный доступ).

Для назначения прав загруженному коду нужна информация о его происхождении. Происхождение кода и другая информация описывается специальным объектом Evidence [2,3]. С точки зрения среды исполнения, объект Evidence – это коллекция идентификаторов, каждый из которых предоставляет разнообразную информацию о происхождении кода; она может быть двух видов: предоставленной тем, кто загружает сборку, или содержащейся внутри сборки.
Таким образом, использование механизмов безопасности при разработке приложений в .NET, повышает надежность приложений и обеспечивает сохранность и конфиденциальность данных.

Литература.

1. Нейгел, Кристиан, Ивьен и др. C# 2005 и платформа .NET 3.0 для профессионалов.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008. – 1376 с.: ил.
2. Рихтер Дж. Программирование на платформе Microsoft .NET Framework / Пер. с англ. – 2-е изд., испр. – М.: Издательско-торговый дом «Русская редакция», 2003 – 512 стр.: ил.
3. Тимофей Казаков. Механизмы безопасности в .NET // RSDN Magazine, №4, 2003 – стр. 24-43.