Безопасность приложений в Microsoft .NET.
Часть 1
Классы для регламентации доступа к защищенным ресурсам
Разрешения на доступ к ресурсам
Платформа Microsoft .NET Framework поддерживает много новых возможностей по обеспечению безопасности Windows-приложений. В настоящей статье рассматриваются вопросы, связанные с использованием средств безопасности, поддерживаемых в .NET Framework, при создании приложений с помощью средства разработки Visual C# .NET, и описываются модели безопасности, в которых применяются защищенные методы доступа к коду и ролевые политики для обеспечения защиты от несанкционированного использования приложения.
Модели безопасности .NET
ачиная с операционной системы Microsoft Windows 2000 в операционных системах указанного семейства применяется модель безопасности, предотвращающая несанкционированные обращения пользователя к операционной системе. Модель безопасности платформы .NET защищает код и данные приложений от их неправильного использования и от повреждения другими приложениями или пользователями операционной системы за счет ограничений, налагаемых на доступ к коду. Она основана на таких принципах, как безопасные типы, цифровая подпись, шифрование данных, безопасный доступ к коду, учетные записи пользователей и изолированная память для приложений.
Система безопасности платформы .NET позволяет коду пользоваться защищенными ресурсами только в том случае, если он имеет на это разрешение. Свидетельства (evidence) о .NET-сборке применяются для предоставления коду набора разрешений в соответствии с политикой безопасности. Когда код пытается осуществить доступ к любому ресурсу, система безопасности .NET проверяет у него наличие разрешения на выполнение этого действия.
Система .NET Framework также поддерживает модель безопасности, основанную на ролевых политиках. Согласно этой модели безопасности приложению предоставляется право доступа к защищаемому ресурсу после идентификации его пользователя и проверки его полномочий.
В свидетельствах содержится информация, идентифицирующая код приложения и его происхождение для операционной системы. Свидетельства могут включать:
- имя сборки, состоящее из уникального открытого ключа, «простого» идентифицирующего имени и номера версии;
- цифровую подпись разработчика операционной системы, которая обслуживает выполняемый код;
- идентификацию места происхождения приложения, например локальный компьютер, интранет, Интернет;
- идентификацию способа запуска приложения (URL, путь доступа к выполняемому файлу, локальная папка компьютера);
- криптографический кэш сборки.
Разработчик приложения может дополнительно включать в свидетельство собственные поля. Увеличение количества полей свидетельства возможно только в случае соответствующей конфигурации политики безопасности операционной системы. Возможное различие форм свидетельств потенциально позволяет создавать в будущем усиленные модели безопасности.
Например, имя сборки является сильным криптографическим фактором обеспечения безопасности, если только секретный ключ издателя не скомпрометирован. Цифровая подпись тоже является стойким криптографическим приемом обеспечения безопасности. Однако идентификацию места происхождения и способа запуска приложения гораздо проще подделать в сфальсифицированном свидетельстве. Сочетание сильных и слабых криптографических способов защиты информации часто позволяет построить достаточно эффективную политику, обеспечивающую безопасность.
Выполняемому коду предоставляются разрешения (permission) на право доступа к некоторым вычислительным ресурсам. Действия, которые регламентируются разрешением, включают операции чтения и записи в файлы из файловой системы, доступ к переменным окружения, вызов функций ADO .NET для доступа к базам данных.
 |
|
Классы для регламентации доступа к защищенным ресурсам
латформа .NET Framework имеет много предопределенных классов, регламентирующих доступ из приложения к различным защищенным ресурсам (в таблице перечислены имена классов и соответствующие им защищаемые ресурсы).
К предопределенным классам, обеспечивающим поддержку модели безопасности, разработчик может добавлять собственные классы, регламентирующие дополнительные разрешения доступа к ресурсам.
|
|
Разрешения на доступ к ресурсам
латформа .NET Framework позволяет устанавливать ограничения, связанные с безопасностью выполнения управляемого кода. Для каждой сборки, загруженной на выполнение операционной системой, устанавливаются разрешения на доступ к ресурсам, которые называются набором разрешений. Эти разрешения базируются на политике безопасности. Используя свидетельства, имеющиеся у каждой сборки, можно разрешать или запрещать ей доступ к системным ресурсам. Другими словами, платформа использует политику безопасности, основанную на свидетельствах сборки, устанавливая разрешения для этой сборки на доступ к системным ресурсам, как представлено на рисунке.
Кодовая группа состоит из идентификатора членства и набора разрешений, которые предоставляются сборке, если выполняются условия ее членства в группе. Во время выполнения сборки оцениваются членство, указанное в кодовой группе, и свидетельство. Если для сборки выполняются условия членства в группе, то она имеет право на набор разрешений, связанный с кодовой группой. В этом случае говорят, что сборка является членом группы.
Условия членства могут определяться издателями сборок, такими как операционные системы от Microsoft. Поэтому любая сборка, полученная в этих системах, удовлетворяет условиям членства и имеет право на набор разрешений, ассоциирующийся с ее кодовой группой. Например, этот набор разрешений может состоять из права на доступ к директории «C:/temp» и к переменным окружения с именем USERNAME.
Сборке предоставляется пересечение набора разрешений всех кодовых групп, к которым она принадлежит.
Политика безопасности подразделяется на различные уровни: сети, компьютера, пользователя и домена. Уровень безопасности сети определяется администратором сети и состоит из иерархии кодовых групп, которые могут быть применены ко всем сборкам, используемым в этой сети. Уровень безопасности компьютера определяется его локальным администратором и состоит из иерархии кодовых групп, которые могут применяться ко всем сборкам, используемым на этом компьютере. Уровень безопасности пользователя состоит из иерархии кодовых групп, которые применяются ко всем сборкам конкретного пользователя. Администратор компьютера или пользователь могут устанавливать дополнительные политики безопасности. Доменный уровень безопасности является необязательным; он обеспечивает изоляцию и разгрузку границ безопасности для управляемого кода. В заключение отметим, что каждая сборка в приложении может иметь свои уникальные разрешения.
В среде исполнения CLR (Common Language Runtime) для обеспечения безопасности используются следующие названия для обозначения наборов разрешений:
- ничего (nothing) — управляемый код без разрешений. Такой код не может быть выполнен. По умолчанию алгоритм безопасности устанавливает такое разрешение для зоны без доверия;
- выполняемый (execution) — предоставляет разрешение только на выполнение. Не позволяет управляемому коду использовать любой другой защищаемый ресурс;
- Интернет (Internet) — предоставляет разрешение на выполнение, создание пользовательских и системных окон (таких как окно открытия файла), на установку Web-соединения внутри одного сайта, на использование памяти с квотой. По умолчанию любой код из Интернета и доверенных зон получает этот набор разрешений. После установки Service Pack 1 для .NET Framework режим по умолчанию изменяется (разрешение отменяется);
- локальный интранет (LocalIntranet) — предоставляет разрешение на создание элементов пользовательского интерфейса без ограничений, на применение изолированной памяти без квотирования, на использование услуг DNS, на чтение переменных окружения с именами USERNAME, TEMP, TMP, на установку Web-соединения внутри одного сайта, на чтение файлов и папок из той же директории, где располагается сборка. По умолчанию любой код из зоны LocalIntranet (обычно это локальная вычислительная сеть предприятия) получает набор вышеперечисленных разрешений;
- всё (everything) — предоставляет разрешение на все предустановленные классы, обеспечивающие безопасность, кроме SecurityPermission (разрешение на отмену проверок безопасности);
- обход проверок (skip verification) — предоставляет разрешение на отмену проверок безопасности;
- полное доверие (full trust) — предоставляет полный доступ ко всем ресурсам, защищенным в соответствии со своими наборами разрешений. По умолчанию код локального компьютера получает такой набор разрешений.
Во время загрузки сборки CLR проверяет свидетельства. Таким образом, разрешения, предоставленные управляемому коду, определяются во время загрузки.
Политики состоят из иерархии кодовых групп. Корнем дерева иерархии является группа, относящаяся ко всему управляемому коду. Корневая группа имеет своих наследников, которые, в свою очередь, могут иметь собственных наследников и т.д. Код, который не является членом родительской группы, не может быть членом какой-либо другой группы, входящей в иерархию. И наоборот, код, являющийся членом родительской группы, может одновременно быть членом нескольких других кодовых групп из иерархии.
Во время выполнения используется свидетельство кода для принятия решения о том, к какой кодовой группе он принадлежит. Кодовая группа определяется по условию членства. Набор разрешений, предоставляемый коду на уровне политики безопасности компьютера, объединяется со всеми другими разрешениями кодовых групп, членом которых он является.
Процедура, основанная на свидетельствах, повторяется для каждого уровня политики безопасности. Затем система определяет пересечение наборов разрешений, которое и является итоговым. Например, если на уровне политики безопасности пользователя предоставляется набор разрешений LocalIntranet, а на уровне безопасности компьютера — FullTrust, то в итоге управляемый код будет иметь набор разрешений LocalIntranet.
|
|
Ролевая модель безопасности
олевая модель безопасности основана на аутентификации (на подтверждении подлинности) информации о пользователе, которая позволяет принять решение о его авторизации. Обычно такая информация состоит из пользовательского имени (login) и связанных с ним ролей.
Ролевая политика безопасности в .NET Framework использует две концепции: идентификационную (Identity) и ролевую (Principal). Идентификаторы (Identity) инкапсулируют в себе информацию о пользователях (login), а Principal — информацию о членстве пользователя в каких-либо ролях. Политика безопасности, основанная на ролях, позволяет разработчикам использовать учетные записи пользователей и групп пользователей системы или пользовательскую аутентификацию и авторизацию для получения данных Identity и Principal.
Аутентификация — это процесс установления (то есть проверки и подтверждения) подлинности различных аспектов информационного взаимодействия. В более узком смысле аутентификация пользователя — это доказательство им своей идентичности с целью проверки его полномочий, осуществляемых посредством протокола идентификации. Имеется большое количество разнообразных протоколов идентификации, некоторые из них могут быть использованы в .NET Framework для обеспечения ролевой политики безопасности. Например, обычно используют протоколы, включенные в операционную систему: паспорт (Microsoft Passport) и прикладные механизмы, такие как NTLM и Kerberos 5.0.
Следующим шагом после аутентификации является авторизация — процесс, который позволяет пользователю выполнить требуемые действия. При авторизации используется информация, идентифицирующая пользователя, и ролевая — для определения к каким ресурсам он имеет доступ.
В следующем номере журнала мы расскажем об установке разрешений для приложений и о модификации политик безопасности, а также рассмотрим примеры приложений с использованием запросов безопасности.
