В документе описаны некоторые возможности, сценарии использования и рекомендации по настройке PC.
Принципы
Главный принцип, заложенный в PC, унаследованный от устройств SafeTouch — подтверждаю то, что вижу. Благодаря этому принципу вероятность подтверждения нежелательных транзакций сокращается до уровней близких к нулю, что в свою очередь, снижает риски как для конечного пользователя, так и для организации, использующей PC.
Термины и определения
Прикладная система — это внешняя по отношению к серверу PC система, использующая PC для целей запроса волеизъявления клиента, подтверждаемого электронной подписью, либо для непосредственного подписания данных. В качестве прикладных систем, может выступать ДБО, или, например, СЭД.
Для архитекторов
В разделе описаны некоторые сценарии и возможности продукта.
Тестовая среда и среда разработки
Для промышленного использования, PC всегда устанавливается в контуре заказчика. Однако для целей разработки, обкатки обновлений PC и прочих задач тестирования рекомендуется разворачивать отдельный тестовый контур также в собственной инфраструктуре. При этом требования к тестовому контуру ниже, и с точки зрения потребляемых ресурсов, и с точки зрения требований к инфраструктуре.
Для развёртывания тестовой среды в собственной инфраструктуре, пожалуйста, свяжитесь с менеджерами коммерческого блока для формирования запроса на регистрацию тестовой прикладной системы.
Кроме того, для начала имплементации PC API в прикладную систему и внедрения PC SDK в мобильное приложение, может использоваться экземпляр PC, развёрнутый на стороне производителя продукта, доступ к API которого осуществляется через Интернет.
Логотип в QR-коде
В PC есть возможность разместить собственный логотип в центр QR-кода, используемого для персонализации мобильного приложения и установить желаемый цвет QR-кода.
Для установки этих параметров, необходимо установить значения QR_LOGO_LOCATION и QR_COLOR. Подробнее про установку параметров сервера в сравочном руководстве PC, разделе PC Server.
Серверная подпись
Компонент "Серверная подпись" может быть использован в случае необходимости формирования ЭП представителем организации, использующей PC. Этот компонент обеспечивает хранение ключа ЭП на серверной стороне (в БД, в зашифрованном виде).
Возможностью формирования такой подписи будут обладать только пользователи, созданные с установленным признаком ключа "Серверная подпись". Формирование ЭП транзакций для таких пользователей будет производится сразу по факту создания транзакции и не будет требовать какого либо дополнительного подтверждения от владельца ЭП (в отличие от того, как это происходит с обычными пользователями, подтверждающими своё намерение сформировать ЭП на мобильном устройстве). Таким образом, итоговое решение сформировать ЭП для транзакции остаётся за прикладной системой.
Режим PKI
В PC с версии 5.2 добавлена поддержка возможности формировать сертификаты пользователей на стороннем УЦ, с хранением ключа ЭП также в мобильном устройстве. В настоящее время поддерживается только OpenSSL, при этом, возможна разработка кастомизированных коннекторов к другим УЦ (при наличии API-интерфейса у УЦ, или других возможностей для интеграции с ними).
При работе в режиме PKI возможно формировать значение ЭП по стандарту PKCS7 (detached mode).
Подпись PDF
В PC с версии 5.2 добавлена возможность добавления ЭП непосредственно в подписываемый документ (PDF-подпись), которая будет визуализироваться в документе, и валидироваться в просмотрщике PDF-файлов (при условии, что цепочки сертификатов для проверки доверия установлены на устройстве, на котором производится просмотр документа).
Функция PDF-подписи доступна при работе сервера PCS в режиме использования PKI.
Параметры ключей пользователя
При создании ключа пользователя могут быть установлены его параметры (подробнее о них на странице Параметры ключа). Их значения могут быть установлены как в момент отправки запроса на создание пользователя, непосредственно в теле запроса, либо путём конфигурирования значений по умолчанию на сервере (подробнее о способе их установки в статье PC Server).
Deep Links
Deep link - (рус. - Внешнее связывание или Глубинное связывание) — механизм вызова функций одного приложения из другого, работающего на том-же устройстве.
В PC этот механизм можно использовать при формировании QR-кодов, либо ссылок, при считывании или переходе по которым на мобильном устройстве будет запускаться приложение PC.
Для формированием сервером PC QR-кодов, в которых будет указана требуемая URL-схема (для приложений PayControl и PayConfirm это paycontrol:// и payconfirm:// соответственно, или другая URL-схема, зарегистрированная приложением, в которое встроен PCSDK), необходимо её задать в параметрах конфигурации прикладной системы через запрос к API PCS, подробнее в описании.
Кроме того, для каждого создаваемого ключа, при необходимости, можно опционально указывать URL-схему для формирования внешней ссылки, путём установки параметра
"url_scheme": "paycontrol"
Подробнее в описании PC API — создание пользователя
Вход по QR
Для возможности осуществления входа на портал или, например, в авторизованную зону банкомата, без использования логина и пароля используется модуль LoQR. С его помощью отсканировав QR-код приложением PC (в которое ранее уже был добавлен ключ) будет создана транзакция для подтверждения входа, которую должен подтвердить пользователь (как и любую другую транзакцию PC).
Кроме того, формирование QR-кода может быть настроено для формирования содержимого в форме Deep Link.Таки образом можно считать QR-код камерой без предварительного запуска приложения PC, оно будет запущено само.
Темы оформления мобильного приложения PC
При использовании мобильного приложения PC, скаченного из магазинов приложенйи, существует возможность стилизовать его, придав детали оформления из брендбуака компании, такие как цвет деталей оформления, логотип.
Для этого, на сервере необходимо разместить файл темы оформления, а мобильное приложение загрузит их само, при следующем соединении с сервером.
Подробнее по ссылке Темы оформления мобильного приложения
Сценарии
Обновление ключей
Ключ пользователя имеет ограниченный срок действия, который задаётся в момент выпуска ключа, на основании параметра настройки срока действия ключа, установленного на сервере в параметре user_keys_expiration_period. Подробнее о его установке в описании PC API, раздел Change System Settings.
По инициативе мобильного устройства
При истекающем сроке действия имеющегося ключа, мобильное приложение, посредством PCSDK, может само запросить перевыпуск ключа. Аутентичность получателя нового ключа обеспечивается с помощью имеющегося ключа.
По инициативе прикладной системы
В случае компрометации имеющегося ключа, или других сценариях, когда выпуск ключа с помощью подтверждения предыдущим невозможен, или недопустим, необходимо произвести выпуск нового ключа используя PC API. При этом, необходимо иметь в виду, что данное действие является высокорисковым, и качество аутентификации получателя новой ключевой информации должно быть не ниже, чем аутентификация при выпуске первого ключа.
Выпуск нового ключа возможен также двумя способами:
- перевыпуск ключа для существующего пользователя (userid)
Идентификатор пользователя остаётся неизменным, проще получить историю подтверждений и список событий для пользователя. контроль уникальности ключа для пользователя будет обеспечиваться механизмами PC.
- удаление предыдущего пользователя, и создание нового
Возникает необходимость сохранять идентификаторы всех созданных пользователей. Контроль отслеживания того, что выводимый из эксплуатации ключ действительно выведен, а не продолжает быть доступным для подтверждения должна обеспечивать прикладная система.
Временная блокировка пользователя
В случае необходимости временного отключения возможности подтверждения с помощью PC, имеется возможность заблокировать ключ пользователя, с помощью установки параметра block описании PC API в разделе Update User. При этом функция блокировки ключа обратима (с помощью параметра unblock), и не требует выпуска нового ключа.
Удаление пользователя
В PC возможно удаление пользователя, при этом, запись о пользователе, его транзакциях и прочие связанные данные помечаются в БД как удалённые, но фактически не удаляются и доступны для получения информации о пользователе и провери транзакций через интерфейс АРМ РКС или API.
Резервное копирование и восстановление ключа из хранилища
Для обеспечения возможности переноса ключа на другое мобильное устройство. Для этого формируется резервная копия, включая зашифрованную на пароле пользователя кодовую фразу. Для восстановления необходимо иметь доступ к резервной копии и использовать пароль введённый при сохранении. В процессе восстановления существующий ключ пользователя будет помечен как удалённый, и будет выпущен новый, который будет сохранён на устройстве, на котором выполняется резервное копирование. Эта функция доступна только для ключей, у которых выставлен флаг remote_update_enabled.
Резервное копирование
- Проверить, что установлен флаг
remote_update_enabled - Получить от пользователя пароль для резервного копирования
- Сформировать набор данных для восстановления (метод createBackupData)
- Положить полученный набор данных в область для сохранения резервной копии, например, это может быть:
1.
- для iOS - KeyChain, синхронизуемая область
- для Android - Google Drive
Процесс восстановления доступа
- Проверить, есть ли наборы данных для восстановления
- Запросить пароль восстановления ключа из выбранного набора
- выполнить метод restoreBackup, на выходе будет получен объект PCUser
- Выполнить обычную регистрацию и сохранение ключа.
Интеграция SDK
Подписание транзакций
Настоятельная рекомендация от разработчиков PC – перед подписанием в мобильном приложении визуализировать именно подписываемые данные, т.е. именно те, которые были получены PC SDK по getTransactionData.
Необходимость получения от сервера PC результата проверки значения ЭП
В случае, если не используется коллбэк для получения результата подтверждения ЭП транзакции, или для парирования риска "утери" коллбэка, возможно компенсировать это с помощью запроса информации об интересующей транзакции с сервера PC. При обработке информации об статусе транзакции необходимо разобрать "confirm_attempts" для выбора попытки со статусом "confirm_result": "SUCCESS", и использования значения ЭП из этой попытки как ЭП транзакции.
Для администраторов ИБ
АРМ РКС
АРМ РКС — Автоматизированное рабочее место разбора конфликтных ситуаций. Предназначено для получения подробной информации о пользователе PC, его транзакциях и событиях, а также для проверки значения ЭП с формированием акта по факту проверки, загрузки лицензионных файлов PC и получения общей информации о сервере PC. Подробная информация о компоненте доступна по ссылке для зарегистрированных на клиентском портале пользователей.
Включение HTTPS
Для обеспечения защиты передачи данных между PCSDK или приложением PC и серверной частью PC от прослушивания и атак типа MitM, необходимо обеспечить применение протокола TLS.
Включить HTTPS можно на сервере PCE, или на реверс-прокси, расположенном перед PCE, обеспечивающем TLS-offloading. Инструкция по включению HTTPS доступна в разделе Включение и конфигурирование HTTPS.
Включение HTTPS между внутренними компонентами PC
В случае существования требования обеспечить TLS защиту при взаимодействии между компонентами PC, располагающимися в сети организации, её включение производится путём генерации и установки ключей и сертификатов корпоративных УЦ в WildFly, под которым запущен компонент PC, к которому осуществляется подключение. В хранилище доверенных сертификатов Java, на котором запущен компонент PC, который осуществляет подключение, необходимо добавить цепочку сертификатов для обеспечения валидации хоста назначения. Подробнее об установке в разделе Добавление сертификатов корпоративных УЦ.
События
Для возможности интеграции с антифрод и SIEM системами предусмотрена отправка информации о событиях, возникающих на сервере PC.
Содержание
В данных о событии может содержаться информация, перечисленная в справочном руководстве, в разделе События.
Получение информации о событиях
Получать информацию о событиях можно двумя способами:
- Путём настройки на сервере PC адреса, по которому будут отправляться данные о событии с помощью HTTP POST запроса в момент их возникновения.
- Путём подключения к БД PCS, и получения информации из таблицы
pc_event.
Настройка
По умолчанию, c версии 3.6.367, сбор информации о событиях (и их запись в БД) разрешён. Однако, для того, чтобы мобильное устройство передавало информацию о событиях на сервер PCS, ключ пользователя должен быть создан с флагами, разрешающими сбор событий (и прочими, при необходимости). Подробнее по ссылке параметры ключа.
Установка названия экземпляра PCS
В случае, если модуль PCS запущен в нескольких экземплярах, то есть возможность задать названия экземпляра через в переменной окружения pc_instance_name.
Интеграция SDK
Подписание транзакций
Настоятельная рекомендация от разработчиков PC – перед подписанием в мобильном приложении визуализировать именно подписываемые данные, т.е. именно те, которые были получены PC SDK по getTransactionData.
Необходимость получения от сервера PC результата проверки значения ЭП
В случае, если не используется коллбэк для получения результата проверки ЭП транзакции, то необходимо компенсировать это с помощью запроса информации по транзакции с сервера PC. В полученном ответе, необходимо разобрать список "confirm_attempts" для выбора попытки со статусом "confirm_result": "SUCCESS".
Использование очередей для ограничения соединений от PCE к PCS
Для организаций, в которых ограничиваются входящие соединения из сегмента DMZ в сегмент, где располагается PCS, для передачи запросов от мобильных устройств возможно использовать брокер очередей. В настоящее время поддерживается брокер очередей RabbotMQ.
При необходимости обеспечения такой организации взаимодействия между PCE и PCS, в их сетевых сегментах должны быть развёрнуты модули-перекладчики, отвечающие за взаимодействие с диспетчером очередей. Возможность работать с очередью должна быть у каждого из перекладчиков.
