Push технологии в Интернет банкинге. Преимущество или необходимость? Авторы: В.И. Дардык, А.Б. Вдовин, журнал «Банковские Технологии», №11/2000

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

• Защита передаваемой информации и авторизация доступа
• Функциональный состав клиента и его «толщина»

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

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

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

1. Банковский сервер работает 24 часа в сутки. И клиенты банка имеют возможность круглосуточно отправлять свои платежи. Это тем более актуально, что совсем необязательно физическое время клиента совпадает с физическим временем сервера, поскольку клиент работает со своим терминалом через интернет. Платежи клиентов могут обрабатываться и отсылаться в корреспондентские банки автоматически. Но совсем не всегда администрация банков доверяет контроль платежей компьютерной системе. Как правило, управлением платежами занимается операционист отдела казначейства. И в этом случае операционисты требуют от системы мгновенного оповещения о возникновении платежей, требующих их обработки.
2. Клиенты банка, работающие с банковским терминалам по выделенным линиям и делающие платежи в реальном режиме времени бывают заинтересованы в получении информации о поступлениях на свой счет сразу по факту этих поступлений.
3. Менеджеры банка ценят оперативность предоставления информации о финансовом состоянии банка и считают необходимым иметь возможность отслеживать изменение нормативных и аналитических показателей в режиме онлайн. Ведь чем раньше менеджер узнает о возможности возникновения критической ситуации, тем лучше он сумеет к ней подготовиться и тем большую свободу маневра он будет иметь в принятии решений.
4. Не является секретом, что банки, работающие по интернету, регулярно подвергаются атакам хакеров. Как правило, для преодоления защиты доступа к банковскому серверу, хакеру приходится, пробуя те или иные варианты, предпринимать несколько неудачных атак, которые могут быть легко распознаны сервером. И, если, вместо записи информации о такой атаке в журнал, сервер немедленно известит администратора системы об угрозе, администратор имеет больше шансов и времени на предупреждающие действия и даже на успех в идентификации злоумышленника.
5. V.I.P. клиентов банков привлекает такая услуга, как возможность неформального общения с операционистами банка. Предоставляя такую возможность по транспортному протоколу системы, банк получает возможность защитить конфиденциальные сведения, содержащиеся в передаваемой информации, а также протоколировать такое общение для использования в будущем при разборе возможных конфликтов.
6. Наконец, при проведении регламентных работ администратору системы бывает необходимо монопольное управление системой. Для соблюдения корректности в этом случае все работающие пользователи должны быть извещены об этом заранее.

Из этих и некоторых других ситуаций, имеющих место в реальности, было выделено несколько конкретных задач:

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

В соответствии с поставленными задачами сообщения были проклассифицированы по следующим разрезам:

• Источник сообщения, каковыми могут быть сама система или пользователь системы.
• Назначение сообщения. Сообщение может быть адресовано одному клиенту, некоторой группе клиентов или всем клиентам.
• Обработка сообщения на компьютере клиента.

Для решения указанных задач не годятся методы псевдо-PUSH технологий, основанные на периодическом (с малой длительностью интервала) опросе клиентом сервера из-за излишней загрузки сети при реализации.

Также такого рода задачи практически не решаются в двухслойных клиент-серверных архитектурах.

Поэтому была реализована следующая технология обработки сообщений.

Схема обработки сообщений сервер-клиент I

На приведенном рисунке приведена схема обработки сообщений в направлении от сервера к клиенту, потому что именно это направление является предметом данной статьи. Рассмотрим ее подробнее.

Источниками сообщения могут быть различные подсистемы серверного приложения, такие как транзакционный сервер, посылающий сообщение о нарушении нормативных показателей, или, например, подсистема безопасности, обнаружившая попытку несанкционированного доступа, или подсистема обработки сообщений от клиентов, получившая от клиента сообщение для передачи. В любом из этих случаев сообщение попадает в хранилище MSMQ (Microsoft Message Queue Server) на сервере. MSMQ, в свою очередь, переправляет это сообщение с помощью транспортного протокола банковской системы и соответствующих ее компонент адресатам. Адресатами сообщения, как правило, являются клиенты банковской системы. Впрочем, в некоторых случаях адресатами могут быть другие (или тот же самый) серверы системы.

Использование банковского протокола обусловлено соображениями защиты аутентификации информации, так как эта проблема решается в целом для банковской системы.

Клиентское приложение, получив сообщение, помещает его в хранилище на клиентском компьютере, откуда оно переправляется компоненте-обработчику сообщения.

Тело сообщения представляет собой текстовый поток в формате XML(Extensible Markup Language), что облегчает обработку сообщения.

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

Хотелось бы остановиться на нескольких запланированных в перспективе применениях описанной технологии обмена сообщениями.

Постольку поскольку сообщение уже попало в очередь на MSMQ, то дальнейшую его доставку и обработку, вообще говоря необязательно вести средствами банковской системы. Так нетрудно имеющимися программными средствами реализовать вариант доставки сообщения на пейджер требуемого адресата, будь то администратор системы или клиент банка. Также есть возможность огласовки сообщения и посылки его либо напрямую, либо через голосовую почту на обычный или мобильный телефон адресата.

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

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

Вениамин Дардык, ben@fininfor.ru

Андрей Вдовин, vdovin@fininfor.ru