4.1. Установка Dr.Web Enterprise Agent с использованием Центра Управления Dr.Web
В иерархическом списке антивирусной сети Центра Управления отображаются компьютеры, уже включенные в состав антивирусной сети. Dr.WebEnterprise Security Suite также позволяет обнаруживать компьютеры, не защищенные антивирусным ПО Dr.Web ESS и устанавливать антивирусные компоненты удаленно.
Чтобы быстро осуществить установку ПО Агента на рабочие станции, рекомендуется воспользоваться Сканером сети (см. п. Сканер сети), который осуществляет поиск компьютеров по IP-адресам.
Для установки Агента с использованием Сканера сети:
При необходимости измените порт и значение таймаута.
Возможные виды значков
Элементы каталога, соответствующие станциям со значками 
или 
, можно дополнительно развернуть и ознакомиться с составом установленных компонентов.
При нажатии на значок 
компонента станции, подключенной к данному Серверу,будет выведено окно настроек данного компонента.
Возможно задание нескольких учетных записей администратора. Для этого:
При установке Агента сначала используется первая учетная запись из списка. Если установка под этой учетной записью завершается с ошибкой, используется следующая учетная запись и т.д.
В дальнейшем эти параметры можно изменить в настройках Enterprise Агента и свойствах станции.
Когда в своей основе антивирусная сеть уже создана и требуется установить ПО Агента на определенные компьютеры, рекомендуется воспользоваться Установкой по сети.
Для установки по сети:
Enroll on behalf of и шаблоны версии 2 и 3 – pki extensions
Сегодня хочу поговорить и обозначить неочевидные моменты, которые связаны с энроллментом сертификатов от имени другого пользователя. В определённых сценариях администратору (или агенту подачи заявок на сертификаты) требуется запрашивать сертификаты от имени другого пользователя. Как пример такого сценария — распространение смарт-карт на предприятии. В таком случае в организации выделяется специальный человек, который будет этим заниматься. Этот человек будет называться Enrollment Agent и в его задачи будет входить:
- регистрация, администрирование и замена смарт-карт;
- контроль выдачи смарт-карт. Смарт-карты могут выдаваться только после собеседования с сотрудниками, которым требуются смарт-карты;
- запрос и установка сертификатов на смарт-карты;
- выдача готовой к эксплуатации смарт-карты конечным пользователям.
Для решения этой задачи Windows CA (будь то Standalone или Enterprise CA и CA может работать под управлением любой версии Windows Server) предлагает возможность реализации данной задачи через использование Enroll On Behalf Of (EOBO). Суть метода заключается в том, что такой агент получает для себя специальный сертификат на основе шаблона Enrollment Agent (или любого другого шаблона), который отвечает двум требованиям:
- в Request Handling тип использования ключа содержит Signature;
- в Application Policies (в прошлом Extended Key Usage или просто EKU) выставлено Certificate Request Agent.
Примечание: в целях безопасности следует настроить ограничения для запроса сертификатов на основе этого шаблона и после выдачи сертификатов нужным агентам, удалить его из выдачи CA. Так же настоятельно рекомендуется сделать шаблон версии 2 и использовать CSP смарт-карты, чтобы данный сертификат не хранить в профиле пользователя, а на смарт-карте.
После этого этот агент может запрашивать сертификаты для других пользователей. Для этого агент запускает оснастку certmgr.msc, в ней переходит на Personal –> Certificates –> Action –> All Tasks –> Advanced Operations –> Enroll On Behalf Of… и начинает процесс подачи заявки на сертификат. Во втором окне мастера агенту потребуется указать свой сертификат Enrollment Agent. Этот шаг необходим для того, чтобы доказать, что агент является Enrollment Agent’ом и данный сертификат будет использоваться для подписывания запроса сертификата. В окне выбора шаблонов вы скорее всего увидите только доступные шаблоны версии 1:
У меня есть несколько шаблонов версии 2, но запрашивать для них сертификаты я не могу. Сообщение отказа в запросе таких сертификатов весьма мутное и не очень понятное. Поскольку шаблоны версии 1 не могут быть изменены, они штатно поддерживают режим EOBO. А шаблоны версии 2 и 3 следует сконфигурировать отдельно. Для этого вам нужно открыть свойства шаблона, перейти на вкладку Issuance Requirements и отредактировать его так, чтобы он выглядел как на картинке:
Т.е. вы должны указать, что запрос должен быть подписан сертификатом, Application Policies которого содержит Certifcate Request Agent.
Вообще тут разгуляться можно как следует. При наличии специальных требований, вы можете создать определённые рабочие процессы (workflows). Например, в шаблоне сертификата Enrollment Agent, который требует хранение сертификата на смарт-карте (явно указан только CSP смарт-карты) в Issuance Policies (Certificate Policies) можете создать отдельную политику выдачи, например Smart Card Enrollment Agent, назначив этой политике свой OID. Таким образом у вас может быть 2 Enrollment Agent’а, один из которых выдаёт смарт-карты с сертификатами для цифровых подписей, а другой агент будет выдавать сертификаты смарт-карт для шифрования файлов. При этом первый агент будет хранить свой сертификат Enrollment Agent на смарт-карте, а второй в профиле пользователя. В сертификате Enrollment Agent первого агента в Certificate Policies будет указан OID, который вы присвоили политике Smart Card Enrollment Agent. Сертификат второго агента не будет содержать особых политик выдачи (используется стандартный шаблон Enrollment Agent версии 1).
Чтобы разделить шаблоны между агентами вы можете их настроить вот так:
Мы теперь требуем, чтобы сертификат агента подачи заявок не только содержал определённый Application Policy, но и Issuance Policy тоже. Это означает, что агент подачи заявок, который хранит свой сертификат в профиле не будет иметь возможности запрашивать сертификаты такого шаблона. Вот вам ещё один сценарий использования OID’ов. Это на случай, чтобы вы не думали, что это какая-то мифическая никому не нужная фигня.
Собственно, после этой настройки шаблонов версии 2 и 3 вы можете их использовать в EOBO:
Помимо этого, вы можете ещё более точно очертить возможности агентов восстановления:
Начиная с Windows Server 2008, вы можете задавать более гранулированные права для enrollment agent’ов, указывая каким агентам какие сертификаты можно запрашивать с использованием EOBO.
Данный материал не претендует на статус ТЗ (Тайное Знание), но даёт огромную пищу для размышления администраторам средних и крупным компаний на предмет того, как можно расширить возможности использования PKI и создать более чёткое разделение обязанностей агентов подачи заявок (Enrollment Agent) при использовании функции Enroll On Behalf Of (EOBO). Как вы видите, Windows PKI даже из коробки позволяет достаточно просто масштабировать и управлять вашей инфраструктурой PKI. А так же мы развеваем миф о том, что инфраструктурой PKI может рулить студент-ПТУшник (петушатник?), который поднимает CA на коленке в метро.
Для больших компаний существуют ещё более мощные и гибкие средства для выполнения подобных задач, которые есть в таких продуктах как Identity Lifecycle Manager (ILM) 2007 или в Forefront Identity Manager, но о них мы говорить не будем.
Дополнительные материалы:Что в OID’е тебе моём?
Это была реклама студентов ПТУ.
Настройка клиент-серверного подписания электронных документов
В случае, если Вы используете программу 1С в серверном режиме, у Вас есть возможность настроить и серверное подписание электронных документов, т.е. когда и криптопровайдер, и электронные подписи установлены только на сервере (на “клиентах” их нет).
Принципиальное значение в реализации данного варианта имеет то, от имени какого пользователя осуществляется настройка криптографии на сервере.
Настройка должна быть выполнена от имени того пользователя, под которым запускается служба “Агент сервера 1С:Предприятия”.
По умолчанию данный пользователь именуется “USR1CV8”, см. Рис. 1.
Рис. 1.
Эта служба может быть запущена и от имени другого пользователя (например, “Administrator”) – данное правило задается системным администратором на свое усмотрение.
Поэтому, перед началом настройки серверной криптографии, обязательно нужно уточнить вышеописанный момент.
Определившись с пользователем, можно начинать.
1. Проходим на сервере аутентификацию под пользователем, под которым запускается служба “Агент сервера 1С:Предприятия”.
2. Устанавливаем криптопровайдер.
3. Месторасположение контейнеров с закрытыми ключами (реестр, жесткий диск, внешний носитель) может быть любым, с условием, что они доступны пользователю, под которым запускается служба “Агент сервера 1С:Предприятия”.
4. Устанавливаем личные сертификаты, корневые сертификаты, списки отозванных сертификатов. При этом установку можно проводить “для текущего пользователя” – нет необходимости устанавливать их “для локального компьютера”.
5. Помечаем в программе 1С галочками пункты “Проверять подписи и сертификаты на сервере” и “Подписывать на сервере” (Администрирование – Обмен электронными документами – Электронная подпись и шифрование – Настройки электронной подписи и шифрования – закладка “Программы”).
Система настроена. Подписание на “клиентах” должно проходить успешно.
При тестировании сертификата на “клиенте” нужно обращать внимание только на корректность прохождения этапов теста на сервере, см. Рис. 2.
Рис. 2.