BIS Journal №4(35)/2019

30 декабря, 2019

Безбумажный банк

Чтобы предоставить клиенту и сотруднику самый удобный, безопасный и быстрый способ безбумажного оформления операций, разработан уникальный по своей сути омниканальный модуль подтверждения операций (модуль подтверждения). Этот модуль предоставляет продуктовым системам — потребителям следующие сервисы: проверка доступности технологии БФО в зависимости от имеющихся в учётных системах сведений о клиенте, канале и месте его обращения, типе совершаемой операции; предоставление доступных клиенту способов аутентификации клиента с использованием достоверных и удобных для клиента средств, позволяющих однозначно установить авторство документа; вывод электронных документов на устройства отображения с целью ознакомления с ними клиента и сотрудника банка; формирование и интеграция в электронный документ блока данных, составляющего простую электронную подпись клиента; формирование и проверка усиленной неквалифицированной электронной подписи сотрудника; вызов необходимых компонент для печати электронных документов по желанию клиента и (или) отправки их на верифицированный электронный почтовый адрес клиента; отправка сформированных и подписанных электронных документов на хранение в электронный архив.

 

Алгоритм работы модуля подтверждения

Ознакомиться с общей схемой алгоритма работы модуля подтверждения можно на рис.4

Рисунок 4. Общая схема алгоритма работы модуля подтверждения

 

Процесс подтверждения, как правило, начинается с инициации отправки запроса (request) от продуктовой автоматизированной системы (АС) в модуль подтверждения. Взаимодействие между модулем и продуктовой АС осуществляется с использованием современного защищённого протокола взаимодействия TLS версии 1.2 с контролем клиентского и серверного сертификата. Предусловием для отправки данного запроса является наличие идентифицированного клиента и активной сессии обслуживания, содержащей сведения об операторе, обслуживающем клиента, клиенте и канале взаимодействия. Состояние активности клиентской сессии контролируется модулем подтверждения на всех этапах во избежание несанкционированного подтверждения операции без ведома клиента.

При приёме полученного сообщения в первую очередь осуществляется его валидация на соответствие разрешённому формату, а его содержимое — эталонной XSD-cхеме. Передача данных, не прошедших проверку корректности на каком-либо этапе, категорически запрещена. Далее модуль подтверждения осуществляет логический контроль и анализ полученных данных для формирования соответствующего сценария поведения.

 

Особенности определения доступного сценария подтверждения

Во-первых, проверяется наличие у клиента подписанного ДБО. Эти сведения содержатся в тексте запроса, отправленного продуктовой АС при вызове модуля подтверждения в специальном объекте, отвечающем за предоставление полных сведений о клиенте. Если наличие подписанного клиентом ДБО не подтверждено, то проведение операции с использованием технологии БФО становится недоступным клиенту, и используется стандартный путь оформления операции с проставлением на документе собственноручной подписи клиента.

Во-вторых, анализируется возможность проведения БФО по месту обращения клиента в соответствии с установленными правилами банка. Правила параметризированы и доступны для изменения в любой момент бизнес-администратору, ответственному за процесс через специальный прикладной интерфейс. Таким образом банк может обеспечивать гибкость ведения бизнеса.

В-третьих, производится анализ способа идентификации клиента. Так, например, если идентификация клиента была произведена с использованием карты и ввода PIN, то в специальном поле, отвечающем за наличие сведений о сессии обслуживания, будут содержаться сведения об этой карте. Если идентификация клиента проведена без использования банковской карты, то дополнительно производится проверка наличия действующих карт клиента и верифицированных банком номеров мобильных телефонов клиента. Эта проверка необходима, чтобы определить приоритетный для клиента сценарий подтверждения операции, исключением являются критичные операции, где логика подтверждения определяется на основании сведений, полученных от системы фрод-мониторинга.

Дополнительно проверяются полученные номера телефона клиента на холодный период и на замену сим-карты (проверка IMSI) с целью минимизации возможного риска мошенничества. Холодный период — это время, в течение которого нельзя подтверждать операции конкретным инструментом клиента, выбранным для подтверждения (карта, смс или биометрия). Для этого производится сравнение текущего времени и даты со значением поля в объекте, отвечающем за дату последнего обновления номера телефона, дату выдачи карты или дату создания биометрического шаблона. После проведения вышеуказанных проверок модуль подтверждения возвращает в продуктовую АС ответ (response), который содержит список доступных в данном канале клиенту сценариев подтверждения операции, исходя из анализа сведений, полученных от продуктовой АС.

 

Сценарии подтверждения операции

На текущий момент доступны три типа сценария (рис.5): собственноручная подпись, карта плюс PIN или смс-код либо ЭП на отчуждаемом носителе (для корпоративных клиентов или если в процессе участвуют запросы в госорганы). В ближайшее время планируется добавление нового типа сценария — биометрия, этот сценарий будет доступен клиенту при наличии подписанного согласия на обработку биометрических персональных данных клиента и актуального биометрического шаблона.

Рисунок 5. Сценарии подтверждения операции

 

Сценарий подтверждения собственноручной подписью. Продуктовая АС формирует шаблон документа на основании введённых в систему реквизитов операции, а модуль подтверждения в свою очередь осуществляет вызов разработанного программного компонента печати. Синхронно с этим процессом производится запись в журнал аудита факта печати. При разработке любого программного компонента для конкретных задач необходимо учитывать потенциальную возможность его использования злоумышленником. Именно поэтому при разработке программных компонентов в их структуру добавляется обязательное правило — вызов функций допускается только из разрешённого домена, как правило, таким доменом является внутренняя сеть банка.

Сценарий подтверждения (аутентификации) карта плюс PIN. Общая схема данного сценария подтверждения представлена на рис.6.

Рисунок 6. Сценарий подтверждения карта плюс PIN

 

Продуктовая АС формирует текст с реквизитами операции для POS-терминала, который передаётся в модуль подтверждения в специальном поле. Модуль подтверждения осуществляет вызов специального компонента для взаимодействия с POS-терминалом, и параметры операции мгновенно передаются на экран POS-терминала для ознакомления с ними клиентом. Если клиент согласен, то он нажимает «зелёную кнопку» (процесс продолжается дальше), если не согласен, то нажимает «красную кнопку» (процесс приостанавливается, осуществляется возврат к выбору способа подтверждения операции, а на экране POS-терминала отображается окно с отображением соответствующей ошибки). Факт согласия и отказа клиента передаётся в журнал аудита в синхронном режиме с указанием: места и времени проведения операции; идентификатора клиента; идентификатора операции; даты и времени подтверждения или отказа по операции; способа подтверждения операции; идентификатора сотрудника, принявшего участие в формировании операции. Необходимость записи событий в журнал аудита обоснована эффективностью его использования при расследовании случаев мошенничества и формировании доказательной базы при создании той или иной операции.

Клиент нажал «зелёную кнопку» — осуществляется проверка наличия карты в POS-терминале, и если карта обнаружена, то с помощью программного компонента на POS-терминал отправляется команда для активирования функции ввода PIN. После ввода клиентом PINPOS-терминал отправляет запрос в процессинговую систему на проверку введённого PIN и возвращает полученный код ответа. Если от процессинговой системы получен код, соответствующий коду «PIN неверный», то клиенту предоставляется ещё одна попытка (максимально разрешено три попытки). Если от процессинговой системы вернулся код, соответствующий коду «карта заблокирована или срок действия истёк», то процесс приостанавливается, осуществляется возврат к выбору способа подтверждения операции, а на экране POS-терминала отображается окно с отображением соответствующей ошибки. Если от процессинговой системы получен код соответствующий коду «PIN верный», то осуществляется проверка принадлежности карты банку и идентифицированному в продуктовой АС клиенту.

Дополнительно производится обязательная проверка — находится ли карта, которой клиент подтверждает операцию, в холодном периоде. Если карта успешно прошла все проверки и не находится в холодном периоде, то продуктовая АС формирует электронный документ, соответствующий продуктовой операции и создаёт в учетной системе предварительную операцию. Модуль подтверждения в свою очередь формирует простую электронную подпись клиента и интегрирует её в электронный документ. Простая ЭП для данного сценария представляет собой совокупность следующей информации в электронном виде: фамилия, имя и отчество клиента и (или) его идентификатор в учётных системах банка; маскированный номер карты; дата и время операции; идентификатор операции; код авторизации, получаемый от процессинговой системы (по результатам проверки PIN).

Сценарий подтверждения (аутентификации) с помощью смс-кода. Ознакомиться с общей схемой сценария подтверждения с помощью смс-кода можно на рис.7.

Рисунок 7. Сценарий подтверждения с помощью смс-кода

 

В офисах банка этот сценарий очень похож на сценарий подтверждения карта плюс PIN: так, например, реквизиты операции также передаются на экран POS-терминала для ознакомления, клиент нажимает те же кнопки при принятии решения о подтверждении операции, ввод одноразового смс-кода производится также через POS-клавиатуру. А в удалённых каналах подписание документа по клиентскому опыту унифицировано с процессами подтверждения операции разовыми смс-паролями.

Однако отличия всё же есть, и дело тут не только в замене системы аутентификации и способа взаимодействия с клиентом. В отличие от процессов подтверждения операции смс-паролем, при подписании документов отсутствует возможность «запросить смс ещё раз» при превышении количества неверных вводов. Другими словами, если при подтверждении операции в веб-версии Сбербанк Онлайн после трёх неверных попыток у клиента есть возможность ещё пару раз запросить новый пароль, и он будет действительно новый, то при подписании документа после трёх ошибок ввода смс-кода клиенту будет предложен другой способ подписания, или на документе будет проставлена отметка типа «отказ в подписании», и операция будет отменена (возвращена на доработку).

Как только продуктовая АС вызвала модуль подтверждения, она создаёт специальную техническую сессию, в рамках которой происходит дальнейшая отправка одноразовых смс-кодов. Контроль активности технической сессии позволяет защитить средства клиента от действий злоумышленника при атаке типа полного перебора смс-кода (bruteforce). Техническая сессия как объект содержит идентификатор, дату и время её создания, количество оставшихся попыток ввода смс-кода (максимально три попытки), время жизни смс-кода, количество смс, которые могут быть отправлены в рамках текущей технической сессии. Активность технической сессии жёстко связана с сессией пользователя продуктовой АС: так, например, если сессия пользователя будет закрыта, то и техническая сессия будет принудительного разорвана.

Далее модуль подтверждения генерирует одноразовый пятизначный смс-код и вставляет его в текст сообщения, который был сгенерирован продуктовой АС. Генерация одноразового кода осуществляется с помощью модифицированного Java класса SecureRandom. Продуктовая АС осуществляет вызов модуля отправки уведомлений клиенту, который в свою очередь отправляет сформированное смс-сообщение клиенту через специальный шлюз доставки смс. Для обеспечения конфиденциальности передаваемого кода запросы на отправку смс-сообщений с паролями и кодами клиента всегда передаются с особым маркером типа «SecureTransfer», который сигнализирует системам банка, участвующим в отправке уведомлений клиентов, о недопустимости сохранения тела сообщения в таблицах, логах и журналах АС. А в системах защиты от НСД, наоборот, к данным запросам применяются более строгие правила контроля доступа.

После отправки кода в канал уведомления фронтальная АС ждёт ввода данного кода от клиента и осуществляет вызов модуля подтверждения для сравнения отправленного и введённого кода. Для этого на вход модулю подтверждения от продуктовой АС передаются параметры: идентификатор пользовательской сессии, идентификатор технической сессии и смс-код. Модуль подтверждения осуществляет сравнение смс-кода и возвращает ответ в продуктовую АС. Если смс-код совпадает, то продуктовая АС формирует электронный документ, соответствующий продуктовой операции, и создаёт в учетной системе предварительную операцию. Модуль подтверждения в свою очередь формирует простую электронную подпись клиента и интегрирует её в электронный документ. Простая ЭП для данного сценария представляет собой совокупность следующей информации в электронном виде: фамилия, имя и отчество клиента и (или) его идентификатор в учётных системах банка; номер мобильного телефона клиента; дата и время операции; идентификатор операции; код авторизации, получаемый от системы аутентификации (по результатам проверки смс-кода). Если смс-код не совпал, то простая ЭП клиента не формируется и, согласно установленным счётчикам, осуществляется повторный запрос ввода смс-кода.

 

Операция подтверждена клиентом. Что дальше?

После успешного исполнения сценария подтверждения клиентом по карте плюс PIN или смс производится вывод электронного документа с блоком данных, составляющих простую ЭП клиента на экран устройства отображения второму подписанту — сотруднику банка. После ознакомления с текстом документа сотрудник прикладывает свой ТМ-носитель с секретным ключом к специальному считывателю. Осуществляется программный вызов компонента для получения идентификатора ТМ-носителя с целью дальнейшего определения логина сотрудника и сбора детальной информации о нём в учётной АС банка. На основании полученной информации от учётной АС модуль подтверждения осуществляет следующие проверки: соответствие полученного логина сотрудника, выполняющего данную операцию, логину с ТМ-носителя с целью исключения нелегитимного использования чужого ТМ-носителя; наличие полномочий у сотрудника для подписи документов данного типа с целью исключения нарушения принципа минимальности полномочий; соответствие офиса обслуживания сотрудника офису, в котором выполняется операция, и наличие этого сотрудника в смене офиса с целью исключения несанкционированного подтверждения операции. Если все проверки прошли успешно, то документ с внедрённой простой ЭП клиента подписывается усиленной ЭП сотрудника. Полученная в результате криптографического преобразования кодированная подпись интегрируется в электронный документ. Результат формирования усиленной ЭП отображается сотруднику и передаётся в журнал аудита.

Сформированные в электронном виде документы по окончанию операционного дня передаются из учётной АС в электронный архив.

В дальнейшем перед каждой операцией печати электронного документа и/или его отправки по e-mail клиента производится проверка истинности усиленной ЭП сотрудника с помощью библиотеки СКЗИ. Тем самым гарантируется, что клиент получит не модифицированный документ.

 

Заключение

Описанный выше практический опыт внедрения безбумажной технологии взаимодействия с клиентом на примере Сбербанка поможет избежать основных ошибок при движении в сторону цифровой трансформации бизнеса. Масштабный переход традиционного бумажного документооборота в цифровую плоскость неизбежен, так как позволяет избежать значительных материальных затрат на этапе как формирования, так и хранения электронных документов, а трудозатраты по их обработке, верификации и транспортировке сводятся практически к нулю. Самое главное при выборе безбумажной технологии (разумеется, после экономического эффекта) — не забывать о вопросах соблюдения требований регуляторов и обеспечения кибербезопасности.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

11.12.2024
Безбумажность подождёт! «Сбербанк» возвращает «аналоговые» документы в моду
11.12.2024
«Код Безопасности» присоединился к Консорциуму для исследований безопасности ИИ-технологий
11.12.2024
Расходы на новые ИТ-активы должны будут утверждаться правкомиссией по цифровому развитию
11.12.2024
РКН покажет, где правильно хоститься
11.12.2024
Дата-центры наконец-то перестанут «крутить счётчики»
10.12.2024
Конференция «Сетевая безопасность». Эксперты — о рынке NGFW
10.12.2024
В России появится реестр «хороших мальчиков». Депутаты хотят оцифровать домашних и безнадзорных животных
10.12.2024
Период «охлаждения» приходит в сферу недвижимости
10.12.2024
Григоренко: Важно не просто заместить зарубежное ПО, но и тиражировать новое
10.12.2024
Банк России представил III квартал 2024 года в антифрод-разрезе

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных