the Retail Finance

Плач Ярославны – ария российских банков

Павел Есаков, Заместитель директора по продажам в финансовом секторе, CompuTel
 
Одним из поводов для написания этой заметки стало участие автора статьи в банковском форуме. В рамках форума, на котором присутствовали помимо разработчиков систем ДБО и многочисленные представители банков (причем в основном именно те из них, которые связаны с дистанционным банковским обслуживанием), состоялся круглый стол. На нем обсуждался животрепещущий вопрос: «Как жить банкам после принятия закона о Национальной Платежной Системе (161-ФЗ)?». Увы, присутствие на этом мероприятии наталкивало на аналогии с арией «Плач Ярославны» из оперы «Князь Игорь», но в хоровом исполнении. Большинство из присутствующих представителей банков рыдало и выхода из создавшейся ситуации не видело или не хотело видеть…
 
 Что же послужило основанием для сетований банкиров на горькую судьбу? Вышеупомянутый закон в той части, где на банк возлагались определенные обязанности по отношению к клиенту, осуществляющему перевод электронных средств, а также излагались условия, при которых банк обязан вернуть клиенту деньги. Можно сказать, что впервые в рамках решений ДБО банкам было предложено гарантировать некоторый уровень защиты для клиента от действий третьих лиц. До этого момента вернуть деньги на расчетный счет клиентам удавалось лишь в судах, но чаще в судебном споре побеждали банки, которые сумели подстраховать себя, грамотно составляя договор об услугах ДБО. Достаточно было найти вирус на компьютере клиента, и банк был свободен от возвращения денег на его расчетный счет.
 
Крайне интересно то, что вопросов о создании системы ДБО, защищенной от мошенничества, практически не прозвучало. Именно последнее обстоятельство и создало столь печальное впечатление.
 
Поневоле приходится задаться вопросом о том, почему подавляющее большинство наших разработчиков решений ДБО по-прежнему не может жить без Электронной Цифровой Подписи в разных вариантах ее реализации. Ведь основной объем хищений денежных средств происходит именно там, где наиболее широко используется ЭЦП, – у корпоративных клиентов. На наших глазах прошло уже как минимум два жизненных этапа ЭЦП – от программной реализации до аппаратной реализации в виде USB-устройства с неизвлекаемым приватным ключом, правда, с неизменно положительным для похитителей средств результатом.
 
Если два-три года назад основным аргументом в пользу применения ЭЦП был ФЗ-1, то сейчас данный аргумент использовать невозможно – принят закон об электронных подписях 63-ФЗ, который крайне трудно интерпретировать в том же ключе, как было принято толковать ФЗ-1. Новый закон вводит понятия простой электронной подписи, усиленной и квалифицированной подписи. Так что навязать банкам мысль, что только квалифицированная подпись (а она практически и есть старая добрая ЭЦП) может использоваться для подтверждения банковских операций, стало весьма затруднительно. Усиленная подпись имеет все основания для применения ее в целях подтверждения банковских операций и соответствует Гражданскому кодексу. Большинство реализаций усиленной подписи поддерживает важный принцип, зафиксированный в качестве набора требований к устройствам формирования электронной подписи 63-ФЗ: «Подписываю то, что вижу», и, как результат, экспертное сообщество согласно с тем, что такие устройства – единственно надежный механизм для борьбы с атаками «человек-в-середине» («человек-в-браузере»). Еще одно свойство усиленной подписи – безотзывность, которая столь ценится банками при использовании ЭЦП, и каковое остается без внимания в случае усиленной электронной подписи. Если же учесть, что средства усиленной подписи могут быть использованы для любых каналов взаимодействия: интернет-банк, мобильный банк, call-центр, факс-банк и т.д., то преимущества усиленной подписи выглядят очень привлекательными.
 
Нельзя не отметить, что реализация принципа «Подписываю то, что вижу» была принята на вооружение российскими разработчиками систем для защиты ДБО. Так, появились изделия, которые создают средства отображения для USB-токенов с неизвлекаемым ключом, например, имеют сенсорный экран, с возможностью ввода PIN для подтверждения транзакций. Одним из недостатков таких устройств является то, что из-за малого объема производства стоимость устройств весьма высока, и, собственно, к стоимости устройства должна быть добавлена и стоимость USB-токена. Цена вопроса становится достаточно непривлекательной, и становится проблематичным заставить клиента (хотя бы и корпоративного) заплатить такие суммы. Непонятным становится и то, чем такое устройство лучше подключаемого токена с симметричными ключами, который стоит как минимум в пять-шесть раз меньше. И тем не менее разработок с использованием различных автономных и подключаемых токенов на порядок меньше, чем должно бы быть.
 
Так почему же решения на базе токенов с использованием симметричных криптографических алгоритмов с таким трудом приживаются на российском рынке? Поневоле приходится признать тот факт, что российские разработчики не готовы отказаться от привычных технологий в пользу новых (относительно нашей российской практики) решений. Из имеющихся у разработчиков аргументов можно привести еще один, связанный с тем, что в ЭЦП или другие разработки уже вложены деньги, и пока мы эти инвестиции не вернем, ничего нового разрабатывать не будем.
 
Еще одной из вероятных причин такого пристрастия к асимметричной криптографии среди российских разработчиков систем ДБО является основной принцип, лежащий в основе асимметричных алгоритмов: отсутствие необходимости в хранении приватного ключа клиента на стороне банка. Это всегда приводилось и приводится в качестве одного из основных преимуществ технологии – банк не отвечает за компрометацию ключа клиента, безопасность ключа полностью возлагается на клиента. Это положение, несомненно, ставит банк в более выгодное положение, чем клиента. Ведь огромное количество решений, предлагаемых пользователям систем ДБО, по-прежнему использует программную реализацию ЭЦП, где возможность похищения ключа третьими лицами более чем вероятна. Кстати, как отмечалось, и неизвлекаемость ключа не дает гарантий от хищения денежных средств.
 
Использование ЭЦП создает еще одну возможность для хищения средств клиентов, над которыми обычно даже не задумываются разработчики решений ДБО и мало задумываются российские банки. Достоверность ЭЦП пользователя подтверждает сам банк, и есть вероятность и возможность создания новой ЭЦП для существующего клиента со стороны сотрудника удостоверяющего центра, который входит в инфраструктуру самого банка. Кстати, поскольку процесс подписания сертификата клиента производится в банке программным путем, то нет каких-либо существенных препятствий для похищения приватного ключа, которым после этого можно подписывать любые сертификаты от имени удостоверяющего центра банка.
 
И банкам, и разработчикам систем ДБО необходимо понять, что ЭЦП есть один из многих инструментов для проверки подлинности клиента и сообщения, которое отправлено клиентом в банк. И подобно тому, как каждый инструмент приспособлен для выполнения определенных функций, так и для ЭЦП есть своя ниша, где данный механизм вне конкуренции. Гвозди можно забивать и микроскопом, хотя намного удобнее (и дешевле) делать это с помощью молотка.
 
Прилагаются определенные усилия по спасению ЭЦП – так, предлагается дополнительный одноразовый пароль, отправляемый в виде sms на мобильный телефон клиента, или же одноразовый пароль создается аппаратным генератором, имеющимся у клиента. Заметим, что если бы российские разработчики приложили бы те же усилия, какие затрачиваются на латание дыр, на поддержку в рамках ДБО новых технологий защиты, то эффект был бы гораздо значительнее.
 
Есть ли выход из сложившейся ситуации? Несомненно есть, но этот рецепт может не понравиться российским разработчикам систем ДБО. Многие западные вендоры уже прошли по этому пути, осознав тот факт, что вопросами безопасности должны заниматься профессионалы. Более того, уже сравнительно давно системы аутентификации пользователей и проверки достоверности транзакций выведены из состава систем ДБО и размещены в том месте инфраструктуры банков и предприятий, которое получило название «мидл-офис», подчеркивая тот факт, что эти системы не входят в состав ни фронт-офиса, ни бэк-офиса.
 
В чем смысл выделения аутентификационного решения из каналов ДБО? Как ни странно, смысл есть. Сегодня, в условиях, когда каждый канал ДБО имеет свою собственную систему аутентификации, возникает необходимость управления несколькими системами аутентификации – один и тот же клиент банка нуждается в администрировании в разных каналах ДБО. Вынесение центра аутентификации в самостоятельный компонент решает эту проблему – у нас один клиент и его средства аутентификации, которые управляются в едином центре.
 
Смена или модификация каналов ДБО в этом случае не оказывает влияния на работу центра аутентификации, что упрощает модификацию и замену фронтальных решений и подключение новых.
 
Правильно выбранная система аутентификации дает банку еще весьма значительное число конкурентных преимуществ на рынке. Опыт западных банков свидетельствует о том, что невозможно удовлетворить нужды своих клиентов с помощью устройства одного типа, зачастую невозможно создать условия для комфортной и безопасной работы пользователей в рамках одной технологии.
 
Большинство решений, лежащих в основе центров аутентификации, поддерживают несколько технологий аутентификации: PKI, EMV CAP, OATH, проприетарные токены и т.д. Это создает возможности для банка провести сегментацию клиентов, предлагая каждой клиентской группе именно тот механизм, который наиболее полно обеспечивает компромисс между уровнем безопасности, удобством пользования и стоимостью средства аутентификации.
 
Ряд аутентификационных решений поддерживают не только стандартные механизмы аутентификации, но и обеспечивают поддержку клиентских средств, предлагаемых различными вендорами – поставщиками средств аутентификации клиентов. Выбирая решение такого типа, банк избавляется от зависимости от поставщика средств для аутентификации клиентов и существенно расширяет номенклатуру устройств, которые он может предложить своим пользователям.
 
Неизменным компонентом центра аутентификации является аппаратный модуль безопасности (Hardware Security Module – HSM), который обеспечивает безопасное хранение ключей клиентов на сервере аутентификации, исключая возможность использования ключей клиентов в противоправных целях сотрудниками банка.
 
Одной из функций сервера аутентификации является ведение журналов, в которых хранятся записи о всех результатах проверки аутентификационных запросов. Многие решения для обеспечения юридической значимости журналов снабжают их контрольными суммами, что исключает возможность последующей корректировки журналов со стороны сотрудников банка.
Лицензионная политика поставщиков аутентификационных решений, как правило, базируется на подсчете рабочих мест (per seat), но имеются и приятные исключения. Некоторые поставщики стоимость лицензии определяют вне зависимости от количества клиентов, использующих тот или иной механизм аутентификации. Это позволяет существенно снизить лицензионные платежи для внедрения систем аутентификации в банковских проектах.
 
Что еще можно пожелать, выбирая аутентификационный центр? Очень интересны те решения, которые могут обеспечить наличие независимых друг от друга каналов аутентификации, – это позволит задействовать разные каналы для решения разных задач. Например, один из каналов аутентификации обеспечивает работу систем ДБО, в то время как другой, независимый канал используется для строгой аутентификации сотрудников банка в рамках его инфраструктуры. Независимость каналов делает возможным разделение ответственности между сотрудниками службы безопасности, отвечающими за каналы ДБО, и сетевыми администраторами, раздающими полномочия по доступу к приложениям внутри банка.
 
Как сдвинуть ситуацию с мертвой точки, какие меры надо предпринять для того, чтобы мотивировать разработчиков систем ДБО использовать внешние (по отношению к каналу удаленного обслуживания) системы аутентификации? Одним из возможных вариантов видится пересмотр банками требований к системам безопасности, предлагаемым поставщиками решений. Если банковское сообщество повысит требования к уровню защищенности решений ДБО, то можно рассчитывать, что интерес у разработчиков по отношению к системам безопасности тоже повысится и необходимый результат будет достигнут.
Комментарии (0)добавить комментарий
Ваш комментарий
Автор
Введите число на картинке

  • курсы
Знач. Изм.
USD ЦБ РФ 29/03 92.26 -0.3291
EUR ЦБ РФ 29/03 99.71 -0.5647