Активное развитие сферы электронных услуг и электронного документооборота, происходящее в последние годы, несомненно увеличило объемы мошенничества. Потребовалось законодательное усиление соответствующих мер защиты, одна из которых — подтверждение подлинности получателя услуги или участника документооборота с помощью электронной подписи (ЭП). При использовании ЭП «слабым» местом, как правило, являются криптографические ключи, поэтому так важен контроль на этапах выпуска, выдачи и отзыва сертификата, ну и, конечно, соблюдение максимальных мер защиты при хранении и использовании закрытого ключа электронной подписи.
С ростом количества выпускаемых сертификатов и ужесточением законодательных норм, регулирующих область электронной подписи, становится сложнее «вручную» обеспечить деятельность удостоверяющего центра (УЦ) и органов криптографической защиты (ОКЗ). Существующие системы управления электронными ключами решают только часть задач УЦ и ОКЗ. Поэтому требуется новый взгляд на автоматизацию их деятельности. В этой статье я рассмотрю, в какую сторону могли бы развиваться системы подобного класса, а также поделюсь опытом решения таких задач.
Документооборот запросов на сертификат
В классическом варианте работы УЦ для выдачи сертификата пользователю, необходимо его бумажное заявление с копией соответствующих документов. Это может быть приемлемо, когда УЦ является коммерческим и подготовка всех необходимых документов ложится на внешнего субъекта, представителем которого может быть компетентный пользователь. А если это ведомственный или отраслевой УЦ, где уровень компьютерной грамотности заявителя может быть достаточно низким и где необходимо обеспечить максимальное удобство процесса запроса сертификата при минимальных ресурсах? Добавьте к этому территориальную распределенность по всей стране организации или всей отрасли, когда УЦ или центр сертификации, как правило, находится в центральном офисе/аппарате в Москве, и необходимость согласования такого запроса по иерархии, и вы поймете масштабы задачи. С такими вводными обеспечение качественного процесса создания и согласования запроса на сертификат возможно только при его автоматизации. Но решить эту задачу традиционными системами электронного документооборота не представляется возможным. Ведь на разных этапах создания такого запроса необходимо оперировать сущностями криптографических ключей, осуществлять взаимодействие с криптопровайдерами, центрами регистрации, а в настоящее время — еще и с системой межведомственного электронного взаимодействия (СМЭВ) и единой системой идентификации и аутентификации (ЕСИА). Кастомизировать классический СЭД, используемый в организации, будет очень трудозатратно и следовательно дорого, поэтому лучше использовать готовую систему, предоставляющую данный функционал «из коробки».
Контроль сроков действия сертификатов
Еще один важнейший аспект — это срок действия сертификатов. В самый нужный момент сертификат может оказаться просроченным. Я бы сказал, что сегодня для бизнес-руководителей это ТОП-1 среди всех проблем с сертификатами. Опять же при выпуске сертификатов для внешних пользователей, обязанность по контролю сроков действия лежит на самих пользователях и никак не влияет на деятельность УЦ, выдавшего сертификаты. Как говорится, сам виноват. Но когда речь идет о «внутреннем» УЦ, то своевременно не перевыпущенный сертификат может парализовать важные процессы организации. В таком сценарии ответственность за это скорее всего будет возложена на удостоверяющий центр. Имея сведения о пользователях и выпущенных сертификатах в единой системе, мы можем обеспечить последовательную рассылку пользователям и администраторам уведомлений о необходимости перевыпуска сертификатов. При этом, делая это заранее, можно распределить нагрузку на УЦ, чтобы не допустить пиковых нагрузок, когда в один день необходимо перевыпустить сертификаты для всей крупной организации.
Проверка сведений заявителя
Значительным изменением в законе об электронной подписи, произошедшим в конце 2015 года, стала необходимость проверки сведений заявителя (как физического, так и юридического лица) через сервисы СМЭВ, а также регистрация и публикация выпущенного сертификата в ЕСИА. Проверке подлежат: паспортные данные через сервис МВД России, СНИЛС через сервис Пенсионного фонда РФ и сведения из ЕГРЮЛ/ЕГРИП (для юридических лиц и индивидуальных предпринимателей) через сервис Федеральной налоговой службы. Текущий опыт показывает, что с учетом недостаточной стандартизации протоколов взаимодействия с сервисами СМЭВ и несовершенства технической поддержки, решение этой задачи не тривиально, и требуется достаточно много времени для разработки и особенно отладки интеграционного решения с данными сервисами. Поэтому обеспечение данной функции разумнее реализовать в комплексной системе автоматизации деятельности УЦ как «коробочное» решение.
Обучение пользователей
В соответствии с Инструкцией, утвержденной 152-м Приказом ФАПСИ РФ, для допуска пользователей к эксплуатации СКЗИ необходима их подготовка в части обеспечения безопасного использования криптосредств и соблюдения требований законодательства. Обычно это самостоятельное ознакомление с нормативными документами, а в лучшем случае — инструктаж, после чего пользователь ставит свою подпись в соответствующем журнале и допускается к работе со СКЗИ. На практике же пользователь после такого обучения вряд ли повысит свой уровень грамотности по работе со СКЗИ, что нередко приводит к печальным последствиям. Поэтому для качественного повышения уровня знаний пользователей в этой части необходимы специализированные курсы с последующим тестированием. При этом оптимальным вариантом обучения являются онлайн-курсы, позволяющие снизить вовлеченность сотрудников органа криптографической защиты в процесс обучения и контроля полученных пользователями знаний, а также автоматизировать процесс допуска к работе со СКЗИ. К счастью, в настоящее время доступно много вариантов решений, позволяют организовать такое онлайн-обучение. А за счет интеграции системы обучения с системой автоматизации деятельности УЦ/ОКЗ, использующей агентские модули для взаимодействия с криптосредствами и электронными ключами, можно обеспечить автоматизированный контроль допуска пользователей к использованию СКЗИ. То есть, если пользователь прослушал онлайн-курс и успешно сдал тест, система обучения передаст данные сведения в систему автоматизации деятельности УЦ, которая, в свою очередь, через программного агента «разблокирует» доступ пользователя к криптосредству на его рабочей станции.
Контроль среды функционирования СКЗИ
Безопасное использование СКЗИ требует соблюдения условий его функционирования в соответствии с эксплуатационной и технической документацией на СКЗИ. При этом согласно нормативным документам (в частности, 152-й Инструкции ФАПСИ) такой контроль должен быть регулярным. К техническим условиям функционирования СКЗИ обычно относятся: наличие таких дополнительных технических средств защиты, как СЗИ от НСД; антивирусной защиты с регулярными обновлениями; отсутствие средств разработки и отладки ПО; применение только лицензионного общесистемного ПО и т.д. При большом парке компьютеров вручную обеспечить меры контроля перечисленных технических условий функционирования криптосредств — это весьма трудозатратный процесс, поэтому, как правило, такой контроль просто не осуществляется. Но решить эту задачу возможно иначе — с помощью автоматизированных средств.
Для этой цели можно использовать тот же агентский модуль, упоминаемый в предыдущем разделе. Безусловно останется ряд контрольных мероприятий (в большей степени организационного характера), которые нужно осуществлять вручную. Например, размещение технических средств, наличие пломб и т.п. Но затратный по ресурсам контроль программно-технической среды функционирования криптосредств будет осуществляться автоматизировано — по заданному расписанию, а также с генерацией необходимых уведомлений и отчетов администратору безопасности.
Учет криптосредств
Еще одним из требований, введенным все той же 152-й Инструкцией и наиболее часто проверяемым надзорными органами, является «поэкземплярный учет СКЗИ, эксплуатационной и технической документации к ним, ключевых документов». Фактически это чаще всего касается учета лицензий и дистрибутивов криптосредств, ключевых носителей. В организации с распределенной структурой, число пользователей, эксплуатирующих СКЗИ, имеет три и более порядков величины. Поэтому такой учет легко может заполнить большое помещение шкафами с журналами учета. Как-либо управлять таким объемом бумажной документации силами нескольких сотрудников ОКЗ практически нереально. По крайней мере, очень велика вероятность ошибки, не говоря уже о непомерном времени, уходящем на такой бумажный учет.
Выходом из этой ситуации, как и в описанных выше задачах, является автоматизация соответствующих процессов в комплексной системе управления деятельностью УЦ/ОКЗ. В такой системе возможно автоматизированное распределение пула лицензий по территориальным подразделениям, закрепление их за пользователями в рамках workflow организации, а также поддержание журналов учета в актуальном состоянии благодаря своевременному получению из кадровой системы информации об увольнении и переводе сотрудников. При этом ведение журналов поэкземплярного учета в электронном виде не противоречит требованиям 152-й Инструкции, а опыт прохождения проверок показал, что такой подход положительно воспринимается контролирующими органами.
Управление PKI 2.0
В заключение отмечу, что все вышеперечисленные направления развития комплексной системы автоматизации деятельности удостоверяющего центра и органа криптографической защиты как готового «коробочного» программного продукта уже становятся реальностью. Совместно с коллегами из АО «Гринатом» в интересах атомной отрасли разработан концепт такой системы, который поэтапно претворяется в жизнь. Достигнутые успехи и позитивные отклики заказчиков и регуляторов на данную систему позволяют с оптимизмом смотреть в будущее нашего зрелого продукта, вышедшего на новый уровень развития и помогающего пользователям развивать свои информационные системы в соответствии с требованиями времени.
Олег Губка, директор по развитию Аванпост
Директор по безопасности
