Мы разворачиваем наши приложения .NET, помещая их в локальную сеть и позволяя пользователям запускать их оттуда. Мы являемся частью очень большой организации и не обладаем правами администратора на отдельные компьютеры, серверы или домен. У нас даже нет прав администратора на наши машины для разработки.
Когда пользователь запускает приложение Dot-Net из общего сетевого ресурса, происходит сбой из-за исключения безопасности. В прошлом мы использовали CASPOL (пользовательский уровень) для доверия файловому серверу, но это головная боль. Мы разработали пользовательский код для копирования сборки на локальный диск перед выполнением, эффективно обойдя проблему доверия. Ни одно из решений не является хорошим ответом. Я понимаю, что Dot Net 3.5 устранит проблему.
Когда мы обсуждали эту тему с нашим ИТ-разделом, они дали нам пустые взгляды, когда мы спросили о настройке доверия на машине или сервере.
A Сайт Microsoft говорит
Если вы являетесь разработчиком или издателем кода, вы также можете в цифровом виде
подписать его, а затем изменить политику безопасности, чтобы предоставить больше разрешений для
код с этой подписью.
Один из наших ИТ-специалистов спрашивает меня о том, что нам нужно в отношении криптографического ключа. Прежде чем ответить, я хочу убедиться, что мои предположения верны.
- Предположение, одно : ключ, сгенерированный инструментом SN.EXE , можно каким-то образом доверять как на уровне домена, так и на уровне предприятия.
- Предположение два : Как только такой ключ будет доверенным, и мы подпишем наш код с ним, сборкам будет доверено запускаться из общей сетевой папки.
- Предположение три : «Доверие» - это действие части администратора домена / предприятия и должно быть глобальным для домена / предприятия. Я предполагаю, что они добавят его в хранилище ключей предприятия / домена с помощью некоторой магии активного каталога.
Мои предположения верны, или я далеко от базы? Последний вопрос: можно ли использовать этот же ключ для подписи макросов vba?