Push-технологии в Интернет-банкинге — преимущество или необходимость

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

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

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

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

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

Банковский сервер работает 24 часа в сутки. И клиенты банка имеют возможность круглосуточно отправлять свои платежи. Это тем более актуально, что совсем необязательно локальное время клиента совпадает с локальным временем сервера, поскольку клиент работает со своим терминалом через Интернет. Платежи клиентов могут обрабатываться и отсылаться в корреспондентские банки автоматически. Но совсем не всегда администрация банков доверяет контроль платежей компьютерной системе. Как правило, управлением платежами занимается операционист отдела казначейства. И в этом случае операционисты требуют от системы немедленного оповещения о возникновении платежей, требующих их обработки.
Клиенты банка, работающие с банковским терминалам по выделенным линиям и делающие платежи в реальном режиме времени, бывают заинтересованы в получении информации о поступлениях на свой счет сразу по факту этих поступлений.
Менеджеры банка ценят оперативность предоставления информации о финансовом состоянии банка и считают необходимым иметь возможность отслеживать изменение нормативных и аналитических показателей в режиме онлайн. Ведь чем раньше менеджер узнает о возможности возникновения критической ситуации, тем лучше он сумеет к ней подготовиться и тем большую свободу маневра он будет иметь в принятии решений.
Не секрет, что банки, работающие по Интернету, регулярно подвергаются атакам хакеров. Как правило, для преодоления защиты доступа к банковскому серверу хакеру приходится, пробуя те или иные варианты, предпринимать несколько неудачных атак, которые могут быть легко распознаны сервером. И если вместо записи информации о такой атаке в журнал сервер немедленно известит администратора системы об угрозе, администратор имеет больше шансов и времени на предупреждающие действия и даже на успех в идентификации злоумышленника.
VIP-клиентов банков привлекает такая услуга, как возможность неформального общения с операционистами банка. Предоставляя такую возможность по транспортному протоколу системы, банк получает возможность защитить конфиденциальные сведения, содержащиеся в передаваемой информации, а также протоколировать такое общение для использования в будущем при разборе возможных конфликтов.
Наконец, при проведении регламентных работ администратору системы бывает необходимо монопольное управление системой. Для соблюдения корректности в этом случае все работающие пользователи должны быть извещены об этом заранее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вениамин Дардык,
Андрей Вдовин.