C# для профессионалов. Том II - Симон Робинсон

Восстановление

Автоматическое восстановление является вопросом конфигурации, оно используется для всех свойств выполняющихся в системе Windows 2000. Если процесс службы разрушается, то служба автоматически запускается снова или конфигурируется специальный файл, или автоматически перезагружается вся система. Обычно существует причина разрушения службы, и нежелательно автоматически непрерывно перезагружать систему, поэтому нужно разнообразить ответы на первую, вторую и последующие ошибки.

Приложения COM+ в роли служб

Начиная с Windows ХР (кодовое имя Whistler), приложение COM+ выполняется как служба. В Windows ХР служба имеет прямой доступ к таким службам COM+, как транзакции, пулы объектов, пулы потоков выполнения и т.д. Если желательно использовать службы COM+ в Windows 2000 как службы Windows, то создаются два отдельных приложения: одно имеет дело с функциями службы, а второе — со службами COM+. Это нам дает некоторые преимущества:

□ Легче создать служебное приложение. Нам не нужно больше иметь дело со специальной установкой службы, так как это выполняется прямо из конфигурации COM+.

□ Приложение COM+ может действовать как служба. Оно автоматически запускается во время начальной загрузки, имеет права учетной записи System и реагирует на управляющие коды службы, которые посылаются из управляющей программы службы.

□ Служебное приложение, создаваемое как приложение COM+, имеет прямой доступ к таким службам COM+, как управление транзакциями, пулы объектов, пулы потоков выполнения и т.д.

Больше о службах COM+ можно прочитать в главе 20.

Заключение

В этой главе было показано, что такое службы Windows и как они создаются с помощью .NET Framework. Приложения в службах Windows запускаются автоматически во время начальной загрузки, и мы можем использовать привилегированную учетную запись System в качестве пользователя службы. .NET Framework обладает хорошей поддержкой служб. Весь вспомогательный код, который требуется для создания, управления и установки служб, находится в классах .NET Framework в пространстве имен System.ServiceProcess. С помощью классов System.Diagnostic становятся легко доступными все технологии, необходимые для таких служб, как регистрация событий и мониторинг производительности.

Глава 25

Система безопасности .NET

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

Этот вид неявного обновления станет нормой в недалеком будущем, но очевидно, что здесь существуют проблемы, связанные с безопасностью так называемого мобильного кода. Какие имеются доказательства, что загруженный код надежен? Как узнать, что был получен именно тот модуль, который был запрошен? Что неявно делает CLR, чтобы гарантировать, например, что элемент управления на сайте Web не читает нашу почту?

Платформа .NET реализует политику системы безопасности в сборках. Она использует информацию о сборках, например, откуда они и кем опубликованы, чтобы разделить их на группы кодов с общими характеристиками. Например, весь код из локальной интранет помещается в единую группу. Он использует политику безопасности (обычно определяемую системным администратором с помощью утилиты caspol.exe или ММС) для назначения привилегий.

Политика безопасности .NET в сборках позволяет убедиться, что сборка исходит от того, кто ее опубликовал, и распределена между группами с одинаковыми характеристиками. Что необходимо сделать, чтобы инициировать систему безопасности для машины или для определенного приложения? Ничего — весь код автоматически выполняется в контексте безопасности CLR, хотя и возможно отключение системы безопасности по какой-либо причине.

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

В этой главе мы обсудим свойства управления безопасностью, доступные в .NET, включая защиту от злонамеренного кода, администрирование политиками безопасности и программный доступ к подсистеме безопасности. Мы также рассмотрим развертывание системы безопасности приложений .NET в коротких примерах приложений, которые закрепят концепции этой главы.

Система безопасности доступа к коду

Система безопасности доступа к коду является свойством .NET, которое управляет кодом в зависимости от нашего уровня доверия ему. Если система CLR достаточно доверяет коду, она начнет его выполнение. Однако в зависимости от полномочий, предоставленных сборкой, это может происходить в ограниченной среде. Если код недостаточно надежен для выполнения, или если он реализуется, но затем пытается выполнить действие, для которого не имеет соответствующих прав, порождается исключение безопасности (типа SecurityException или его подкласса). Система безопасности доступа к коду означает, что можно остановить выполнение злонамеренного кода или позволить коду выполняться в защищенной среде, где он не принесет никакого вреда.

Например, если пользователь пытается выполнить приложение, в котором помещен код, загруженный из Интернета, то используемая по умолчанию политика безопасности инициирует исключение и приложение невозможно будет запустить. Аналогичным образом, пользователь, работающий с приложением с сетевого диска, может начать его выполнение, но если приложение попытается обратиться к файлу на локальном диске, возникнет исключение и в зависимости от обработки ошибок в приложении оно либо аккуратно обработается, либо будет завершено.

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

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

Важно понимать, что система безопасности доступа к коду предназначена для защиты ресурсов (локальных дисков, сети, интерфейса пользователя) от злонамеренного кода, но она не является инструментом для защиты программного обеспечения от пользователя. Для системы безопасности, связанной с пользователями, обычно используется встроенная в Windows 2000 подсистема безопасности пользователей или система безопасности .NET на основе ролей, которая будет рассмотрена позже.

Система безопасности доступа к коду основывается на двух высокоуровневых концепциях: Code Groups (Группы кодов) и Permissions (Полномочия).

□ Группы кодов (Code Groups) собирают вместе код, который имеет общие характеристики, хотя наиболее важным свойством является источник его происхождения. Например, группы кодов "Интернет" (источники кода из Интернета) и "интранет" (источники кода в LAN). Информация, используемая для помещения сборок в группы кода, называется свидетельством (evidance). Другое свидетельство, собираемое CLR, включает издателя кода, его устойчивое имя и (где применимо) URI, из которого он был загружен. Группы кода организуются в иерархию, и сборки почти всегда соответствуют нескольким группам кода. Группа кода в корне иерархии называется "All Code" и содержит все другие группы кода. Иерархия используется для определения, каким группам кода принадлежит сборка; если сборка не предоставляет свидетельство, которое соответствует определенной группе в дереве, не делается никаких попыток отнести ее к описанным ниже группам кода.

□ Полномочия (Permissions), или права, являются действиями, которые разрешается выполнить каждой группе кода. Например, полномочия включают "возможность обратиться к интерфейсу пользователя" и "возможность обратиться к локальной памяти". Системный администратор обычно управляет полномочиями, и это можно делать на уровне предприятия, уровне машины и уровне пользователя.