Вопросы безопасности сборок
При создании сборки можно указать набор разрешений, который требуется для ее выполнения. От свидетельства зависит, предоставляются ли сборке определенные разрешения.
Note
Безопасность доступа кода (Code Access Security) является устаревшей технологией, которая не реализована в .NET Core и .NET 5+, и не рекомендуется к использованию в .NET Framework 4.0+. Дополнительные сведения см. в разделе Большинство API управления доступом для кода устарело.
Существует два различных способа использования свидетельств.
Входное свидетельство объединяется со свидетельством, собранным загрузчиком для создания окончательного набора свидетельств, используемых для разрешения политики. К методам, использующим такую модель, относятся Assembly.Load , Assembly.LoadFrom и Activator.CreateInstance .
В качестве окончательного набора свидетельств для разрешения политики используется неизмененное входное свидетельство. К методам, использующим такую модель, относятся Assembly.Load(byte[]) и AppDomain.DefineDynamicAssembly() .
Дополнительные разрешения могут предоставляться политикой безопасности, заданной на компьютере, где будет работать сборка. Для обработки в коде всех возможных исключений безопасности необходимо выполнить одно из следующих действий.
Добавить запрос разрешения для всех разрешений, которые должны быть у кода, и заранее обрабатывать сбои загрузки, которые происходят, если такие разрешения не предоставляются.
Не использовать запросы разрешения для получения необходимых разрешений для кода, но подготовиться к обработке исключений безопасности в случае, если разрешения не будут предоставлены.
Note
Безопасность является сложной областью, допускающей много вариантов настройки. Дополнительные сведения см. в разделе Основные понятия безопасности.
В момент загрузки свидетельство сборки используется в качестве входных данных для политики безопасности. Политика безопасности устанавливается как организацией и администратором компьютера, так и параметрами безопасности пользователя, и определяет набор разрешений, предоставленных всему управляемому коду при его выполнении. Политика безопасности может устанавливаться для издателя сборки (если у него есть средство для создания цифровой подписи), для веб-узла и зоны (в терминах Internet Explorer), откуда была загружена сборка, или для строгого имени сборки. Например, администратор компьютера может установить политику безопасности, разрешающую всему коду, загруженному с веб-узла и подписанному определенной компанией-производителем программного обеспечения, иметь доступ к базе данных на компьютере, но запрещающую запись на диск компьютера.
Сборки со строгими именами и средства подписывания
Warning
Строгие имена не являются средством обеспечения безопасности. Они служат только для однозначной идентификации.
Сборку можно подписать двумя разными, но взаимодополняющими способами: с помощью строгого имени или с помощью SignTool.exe (программы подписывания). При подписи сборки строгим именем в файл, содержащий манифест сборки, добавляется зашифрованный открытый ключ. Подпись строгим именем гарантирует уникальность имени, предотвращает подмену имени и после разрешения ссылки предоставляет вызывающему объекту определенное удостоверение.
При использовании строгого имени отсутствует связанный с ним уровень доверия, поэтому важно использовать SignTool.exe (программу подписывания). У этих двух средств подписи должен быть издатель, который может доказать свою подлинность стороннему центру сертификации и получить сертификат. После этого указанный сертификат включается в файл и может использоваться администратором для решения о том, следует ли доверять подлинности кода.
Можно присвоить сборке и строгое имя, и цифровую подпись, созданные с помощью SignTool.exe (программы подписывания), или можно использовать их по отдельности. При использовании средств подписи можно подписывать одновременно только один файл; для сборки, состоящей из нескольких файлов, подписывается файл, содержащий манифест сборки. Строгое имя хранится в файле, содержащем манифест сборки, но цифровая подпись, созданная с помощью SignTool.exe (программы подписывания), хранится в зарезервированном месте переносимого исполняемого (PE) файла, содержащего манифест сборки. Подпись сборки с помощью SignTool.exe (программы подписывания) может использоваться (со строгим именем или без него), когда уже существует иерархия доверия, основанная на подписях SignTool.exe (программы подписывания), или когда в политике используется только часть ключа и не проверяется цепочка доверия.
Note
При использовании для сборки как строгого имени, так и подписи сначала необходимо назначить строгое имя.
Среда CLR также выполняет проверку хэша, поскольку манифест сборки содержит список составляющих сборку файлов, в который входит и хэш каждого файла на момент создания манифеста. При загрузке каждого файла его содержимое хэшируется и сравнивается с хэш-значением в манифесте. Если хэши не совпадают, сборка не загружается.
Так как строгое именование и подпись с помощью SignTool.exe (программы подписывания) гарантирует целостность, политику управления доступом для кода можно основать на этих двух видах свидетельства сборки. Строгое именование и подпись с помощью SignTool.exe (программы подписывания) гарантируют целостность благодаря цифровым подписям и сертификатам. Все перечисленные технологии (проверка хэша, использование строгих имен и цифровая подпись с помощью SignTool.exe (программы подписывания)) используются вместе, чтобы гарантировать, что сборка не была каким-либо образом изменена.