Как реализовать и защитить облачную электронную подпись
В России электронная подпись (ЭП) используется, практически, во всех сферах, и многие сталкиваются с ЭП на своей работе.
Электронная подпись состоит из двух частей – закрытой, ее также называют «ключом», и открытой части, сертификата проверки электронной подписи. Понятие «облачная ЭП» означает, что сертификат и закрытая часть ЭП хранится, не как мы все привыкли – на носителе, а внутри инфраструктуры организации, которая произвела изготовление данной подписи. Модуль, отвечающий за хранение закрытых частей, называется HSM (Hardware Security Module).
Большинство крупных организаций создают свой собственный Удостоверяющий центр (УЦ). Кто-то организует квалифицированный, кто-то неквалифицированный, в зависимости от назначения ЭП, а кто-то – и те, и другие. И далеко не всем пользователям удобно использовать множество носителей для получения доступа к той или иной информационной системе, использующей идентификацию на основе ЭП. Решить эту проблему может, так называемая, «облачная электронная подпись».
Рассмотрим сертифицированный в России программно-аппаратный криптографический модуль КриптоПро HSM. Совокупность веб-приложений, работающих с базами данных (БД), и непосредственно модуль КриптоПро HSM содержатся в программном решении КриптоПро DSS - интегрируется с УЦ на базе MSCA (КриптоПро УЦ 2.0, КриптоПро 1.5), обеспечивая возможность оператору УЦ изготавливать ключи прямо из приложения КриптоПро DSS. Совокупность приложений в данном решении состоит из: Центра идентификации (ЦИ), веб-интерфейса пользователя, сервиса электронной подписи, сервиса аудита. В случае распределения всех приложений по разным серверам обеспечивается безопасность на сетевом уровне, так как все приложения ведут обмен информацией на одноразовых сертификатах, которые изготавливаются на основе ключа, указанного на этапе внедрения системы. Для обеспечения дополнительной безопасности, серверы БД принято устанавливать отдельно.
Решение, о котором мы хотим рассказать, обеспечит защиту хранилища ЭП от внешних и внутренних нарушителей. Предположим, у вас построен УЦ на базе компонентов КриптоПро или же его аналогов, с которыми совместимо решение КриптоПро DSS. В контролируемой зоне УЦ устанавливается HSM-модуль, на нем, как уже описывалось, будут храниться закрытые ключи пользователей. На границе контролируемой зоны УЦ устанавливается межсетевой экран и криптографический шлюз («Континент»). Он обеспечит защищенное соединение с компонентами КриптоПро DSS и компонентами УЦ. В контролируемой зоне УЦ, сразу за «Континентом» устанавливаем WAF (Web Application Firewall). Данный продукт будет отслеживать передаваемые методы для работы с БД из зоны КриптоПро DSS в зону УЦ. Также по политикам защиты WAF организует защиту веб-приложений от возможного перехвата злоумышленником обращения к веб-узлам УЦ. На границе систем DSS и УЦ устанавливается криптографический шлюз для организации шифрованного канала связи. На границе DSS, контактирующей с основной сетью предприятия, устанавливаются WAF и межсетевой экран. На данном оборудовании задаются правила межсетевого экранирования и настраиваются политики WAF на защиту веб-приложений, описываются методы, которые запрещают обращение к БД. На данном этапе мы организовали контролируемые зоны, и настало время для организации сегмента DSS.
Исходя из соображений информационной безопасности, предлагается каждый компонент DSS размещать на отдельном сервере. Это снизит возможные нагрузки на серверы, а также позволит организовывать отдельно стоящие серверы БД. Серверы БД настраиваем в «горячем» резерве по принципу «always-on». Если на предприятии имеется большое количество пользователей, то стоит поставить балансировщик нагрузки и организовать кластер серверов БД. Это касается и серверов веб-приложений. Далее начинается установка ЦИ КриптоПро DSS. ЦИ отвечает за идентификацию пользователей в системе. Идентификация пользователя возможна как однофакторным методом, используя только логин и пароль, так и двухфакторным, когда пользователю необходимо указать дополнительный одноразовый пароль. Одноразовый пароль может высылаться на email, мобильный телефон или на токен идентификации. Сопоставление пользователя с токеном идентификации производится Оператором при подтверждении регистрации пользователя, либо самим пользователем после прохождения процедуры регистрации и первого входа на веб-портал пользователя DSS. Для работы ЦИ требуется БД.
После того как пользователь авторизовался на ЦИ, он попадает в веб-интерфейс пользователя. Веб-интерфейс пользователя — это отдельное веб-приложение, осуществляющее интерактивное объединение всего комплекса DSS и обеспечивающее удобную навигацию по комплексу. Из данного приложения пользователь может самостоятельно управлять своими контейнерами ЭП, вести подписание электронных документов и т.п., переходя в приложение «Сервис ЭП», проводить аудит действий в личном кабинете (сервис аудита). После установки ЦИ и веб интерфейса пользователя производится настройка доверия между приложениями путем указания отпечатков сертификатов данных веб-приложений и настройки WS-federation. Таким образом, пользователь при входе в свой личный кабинет может быть уверен, что его сессия будет доверенной и валидной только между ним и сервисами DSS. Соединения между ЦИ и веб-интерфейсом будут распределены между разными физическими машинами, а также будут использовать одноразовые токены для обмена сообщениями. Перехватив сессию и подложив идентификатор, злоумышленник не получит доступа к передаваемой информации, так как используемый токен уже не будет ликвидным. Для работы веб-интерфейса требуется БД, в ней хранятся данные о зарегистрированных пользователях.
Следующий этап настройки заключается в установке и настройке компонента DSS – «Сервис ЭП». Настройка веб-приложения производится по аналогии. Дополнительно, при настройке «Сервиса ЭП» указываются адрес веб-узла центра регистрации и сертификаты операторов системы DSS, также можно указать оператора УЦ и присвоить ему роль оператора DSS. Таким образом, обеспечивается единый оператор УЦ и DSS, что позволит централизованно работать с совокупностью данных систем. Оператор DSS выполняет роль проверяющего органа, то есть проверяет предоставленные документы для изготовления ЭП пользователя и проводит процедуру регистрации пользователя в системе УЦ. По факту данный оператор отправляет запрос на регистрацию пользователя в системе Центра Регистрации и не может управлять одобрением данной регистрацией. Также оператор DSS производит процедуру администрирования пользователя, может сбросить ему пароль, указать новый способ вторичной идентификации, сменить контактную информацию. Все описанные действия пользователь может провести совместно с оператором по телефону. Для работы сервиса ЭП требуется наличие БД, которая хранит все действия зарегистрированного пользователя с сертификатами.
Следующий этап установки DSS – это установка сервис аудита, она проводится также. Сервис аудита хранит в БД всю хронологию совершенных действий по зарегистрированным пользователям, являясь централизованной точкой сбора логов по всем веб-приложениям DSS.
Последующие действия пользователя производятся по аналогии со стандартной схемой использования сертификатов на рабочем месте. Сертификат устанавливается с использованием веб-интерфейса пользователя. Помимо возможности работы через веб-интерфейс, пользователь может использовать криптопровайдера, умеющего использовать облачную ЭП, к примеру, КриптоПро CSP 5.0. В настройках данного провайдера указывается адрес ЦИ и адрес сервиса ЭП. Далее все происходит по аналогии с использованием стандартной ЭП. При просмотре сертификата в контейнере возникает окно идентификации, где пользователь вводит свои данные. После успешной авторизации пользователь видит все свои контейнеры с ЭП, откуда производит установку сертификата. После данных действий сертификат готов к работе. При подписании документа ЭП, пользователь идентифицируется в соответствующем окне и в результате успешной идентификации, пользователь имеет успешно подписанный документ.
В настоящей статье произведен краткий обзор процедуры установки сервисов КриптоПро DSS, их принципиальной схемы работы. Описано, каким образом WAF и «Континент» могут обеспечить дополнительную защиту инфраструктуры служб облачной ЭП.
Константин Золотарев,
ведущий инженер Angara Professional Assistance
Опубликовано 23.01.2020