double arrow

Манифест: описание сборки


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

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

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

Каждая сборка имеет уникальное имя, которое состоит из следующих частей: префикса, основанного на открытом ключе разработчика, простого текстового имени, номера версии и информации о локализации. Некоторые сборки могут иметь только простое текстовое имя, но в таких случаях их можно использовать только как часть другого приложения (так как иначе нельзя гарантировать их уникальность). Все остальные сборки, называемые общими или разделяемыми, сопровождаются префиксом, основанным на открытом ключе, номером версии в формате incompatible.compatible.hotfix и привязкой к локализации (указание на поддержанный язык общения с пользователем или язык по умолчанию).




Кроме того, все разделяемые сборки подписываются секретным ключом. Это подтверждает аутентичность разработчика и предотвращает несанкционированные изменения кода. И то, и другое важно в том случае, когда установка приложения происходит через Интернет.

Безопасность в .NET

Безопасность является краеугольным камнем .NET. На всех этапах создания и выполнения программ происходят самые различные проверки - от проверки прав на доступ к коду до разрешений на ресурсы. Вот некоторые из типов проверок безопасности:

1. Безопасность типов. Программы, гарантирующие безопасность данных, обращаются только к тем участкам памяти, которые были выделены для них. Доступ к объектам осуществляется только через специальные интерфейсы, в которые встроена проверка безопасности. В целом безопасность типов может быть проверена не всегда; однако ее наличие гарантирует невозможность одной из самых распространенных атак (чтение указателя большего размера, чем выделенная память).



2. Подлинность кода. Загрузчик классов сохраняет информацию об исходных текстах всех классов, которые были загружены. Таким образом, можно восстановить некоторые атрибуты кода (откуда загружен код, кто является автором и т.п.) и использовать эту информацию для дачи прав на запуск.

3. Разрешения на доступ к ресурсам. Ресурсы обычно ассоциированы с системой. В качестве ресурсов могут выступать файлы, сетевые соединения, право вызова неуправляемых API (unmanaged APIs). Отметим, что права доступа проверяются не только для вызвавшей сборки, но и для всех прочих, находящихся в данный момент в стеке вызовов. Это позволяет предотвратить классическую атаку, в которой неавторизованный компонент получает доступ к ресурсу путем обращения к нему через вызов компоненты с другими правами доступа.

4. Декларативная безопасность. Данный механизм предоставляет возможность встраивать проверки безопасности прямо в код путем аннотации классов, полей или методов. Проверка может производиться однократно при загрузке или постоянно (скажем, при каждом запуске метода).

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

Другие модели обеспечения безопасности.

· Модель политик доступа. Политики позволяют автоматически присваивать коду определенные привилегии, основываясь на том, откуда были получены исходные тексты данного приложения (понятно, что локальному коду пользователи доверяют больше, чем программам из Интернета). Пользователи могут изменять эти политики.



· Модель ролей. Эта модель безопасности проверяет, в какой роли выступает пользователь, и разрешает/отказывает в доступе в зависимости от этого. Например, в финансовых приложениях максимальный лимит транзакции может зависеть от служебного положения банковского служащего.

· Повышенная важность безопасности при удаленном выполнении.

· Криптографические методы защиты, готовые для встраивания в пользовательские приложения.

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

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







Сейчас читают про: