ЭЦП

Суть проблемы

В последние годы электронные системы типа "банк - клиент" не просто получили широкое распространение во всем мире, но стали неотъемлемой частью практики банковского обслуживания юридических и физических лиц. Дело здесь не столько в абстрактном наступлении прогресса, сколько в том, что банкам гораздо удобнее так работать. Интересно отметить, что применяются различные способы давления, ненавязчиво подталкивающие клиентов к светлому электронному будущему. Европейские банки устанавливают тарифы за обслуживание счетов компаний в бумажном виде почти на порядок выше, чем в электронном, и по сочетанию "демократичность+доходчивость" такой аргумент не имеет себе равных. Российские банки распространяют системы "банк - клиент" как обязательный довесок к выдаваемым кредитам, поэтому чем хуже у компании обстоят дела с финансами - тем лучше с электронными технологиями. Проще всего поступили в Мексике, где после введения уплаты налогов юридическими лицами только в электронном виде каждая компания волей-неволей отправилась в банк за получением электронной цифровой подписи (ЭЦП).

Как строить системы "банк - клиент" с максимальной эффективностью и как ими пользоваться с минимальным ущербом? Первое больше касается банков, второе - клиентов.

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

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

Во избежание терминологических недоразумений не будем применять при обозначении электронных систем "банк - клиент", обязательным элементом которых является клиентский компьютер, любимое многими авторами выражение "Интернет-банкинг". Во-первых, потому, что часто его трактуют слишком расширительно, и, во-вторых, потому, что оно в принципе неверно, так как часть рассматриваемых систем использует прямое соединение с банковским сервером, минуя Интернет. Далее будем употреблять встречающийся в лексике иностранных банков термин e-banking (electronic banking - электронный банкинг) как наиболее корректный. Говоря о банках, будем подразумевать коммерческие банки.

Теоретическая база и реальное положение дел

К сожалению, пока не существует согласованного, ясного и последовательного подхода к построению систем e-banking. Да и откуда ему взяться? Фирмы - разработчики ПО озабочены лишь тем, чтобы их продукт был работоспособен и нравился покупателям (т. е. банкам). Эгоцентризм банков имеет свою положительную сторону, порождая технологическое разнообразие и предоставляя в итоге обширную экспериментальную информацию. Но он же становится мощным тормозом, когда наступает время обобщить итоги, сформировать единые принципы построения тех или иных систем и добиться их реализации. Ассоциация российских банков (АРБ) имеет ряд комитетов, занимающихся вопросами информационной безопасности (ИБ), Интернет-технологий, разработки электронных стандартов и т. д. Комитеты выявляют проблемы, ставят вопросы и выдают предложения. То есть идет непрерывный процесс, который должен внушать почтительное уважение. Однако во всем этом присутствует ощущение какой-то вялости и заторможенности, а результаты вызывают смешанное чувство жалости и досады. Такое впечатление, будто российское банковское сообщество не в курсе, что мировые интеграционные процессы идут не только в экономике, но и в сфере технологий, что электронные системы в коммерческом секторе (в отличие от государственного) гораздо перспективнее строить сразу на основе международных стандартов, а не вырабатывать собственные, стремясь перестраховаться из-за путаного российского законодательства в сфере ИБ. Для компании, пользующейся услугами нескольких банков, вопрос унификации и совместимости различных электронных систем и их параметров является критичным, банки же, похоже, подозревают, что унификация может пойти на пользу конкурентам. В технологическом смысле (по отношению к электронному банкингу) АРБ сейчас напоминает команду ополченцев, вооруженных чем попало и неспособных держать строй.

Не вызывает сомнения, что базисной идеей в случае e-banking-систем является оптимальное сочетание технологического удобства (ведь речь идет об обслуживании) и безопасности (ведь речь идет о деньгах) использования системы как для банков, так и для клиентов. Однако, балансируя между соблюдением собственных интересов и стремлением обеспечить привлекательность системы для клиента, банки явно отдают предпочтение первому побудительному мотиву, проявляя иногда поразительную недальновидность. Но нельзя продать пользователю услугу, которая не кажется ему привлекательной. В значительной мере именно этим объясняется фактический провал некоторых амбициозных проектов крупных российских банков в области внедрения новых технологий по обслуживанию частных лиц в 2003 г.

Ключевые технические моменты при организации систем e-banking

1. Дифференциация в обслуживании разных групп пользователей.

Как показывает международная практика, для обслуживания корпоративных клиентов (крупных и средних компаний) и физических лиц (а также малых предприятий) целесообразно использовать разные системы, поскольку то, что хорошо в одном случае, неудобно в другом, и наоборот. Назовем их Corporate Edition (CE) и Business Edition (BE).

2. Генерация открытого и секретного ключей ЭЦП.

Основным средством аутентификации и авторизации в e-banking-системах является ЭЦП. Секретный ключ ЭЦП - главная и вполне надежная защита пользователя. Но лишь до тех пор, пока никто больше не располагает его копией. Поэтому если клиент собирается держать на счете крупные суммы (особенно это актуально для CE), то весьма важно, позволяет ли банк сгенерировать ключевую пару ЭЦП на компьютере клиента или предоставляет ее в готовом виде. В последнем случае остается возможность копирования секретного ключа банковским служащим. И никакие смены паролей клиента не защитят, если администратор банковского сервера решит обойти их проверку. В итоге появляется вероятность проведения в электронном виде ложного платежного поручения по счету, которое любой арбитражный суд признает истинным. Конечно, банковский персонал весьма надежен, а добропорядочность российских банков вообще выше всяких подозрений, но зачем же искушать судьбу? Хотя сказанное кажется вполне логичным и большинство банков идут в этом вопросе навстречу клиенту, но даже среди первого десятка российских банков есть такие, которые генерируют ключи ЭЦП клиента без его участия.

3. Носители секретного ключа ЭЦП клиента.

Носители секретного ключа могут быть различны. Самым сомнительным с точки зрения безопасности является размещение на жестком диске. Самым распространенным в настоящее время - на дискете. Более удобны смарт-карты, брелоки типа touch memory, eToken, iKey и т. п. Очень важным с точки зрения безопасности является наличие у носителя микропроцессора, оперирующего секретным ключом таким образом, чтобы тот не попадал в ходе использования в оперативную память компьютера. Гораздо технологичнее, если не требуется дополнительный считыватель. С этих позиций наиболее перспективными представляются носители типа eToken и iKey, непосредственно подключаемые к обычному USB-порту.

4. Способ соединения клиентского компьютера с банковским сервером.

Соединение может идти как через Интернет, так и в режиме dial-up connection, т. е. коммутируемого соединения через модем, минуя Интернет.

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

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

Система СЕ может поддерживать как один из двух, так и оба типа соединений одновременно. Для ВЕ подходит лишь первый способ.

Использование криптографических алгоритмов и проблема технологичности

1. Технологический патриотизм как стратегия.

Российские банки во избежание осложнений с регулирующими инстанциями стремятся выполнять все не только обязательные, но и рекомендательные положения в сфере ИБ. В результате в качестве алгоритмов ЭЦП и шифрования применяются, как правило, отечественные стандарты.

Если многие заграничные банки стараются делать упор на удобство для пользователя и ради этого максимально упрощают работу клиентского модуля системы "банк - клиент" за счет применения стандартных коммерческих криптоалгоритмов, работа с которыми поддерживается всеми ОС, то российские предпочитают создавать и встраивать дополнительные модули, реализующие отечественные криптостандарты. Рассмотрим, к чему это приводит.

Для системы СЕ клиентский модуль неизбежен, поскольку у корпоративного клиента постоянно есть необходимость в длительной подготовке (в режиме off-line) пакетов платежных поручений. Другое дело - индивидуальный клиент, производящий сравнительно простые и короткие операции. Их можно позволить осуществлять и в режиме online. Пользователь может зайти на сайт банка по SSL-протоколу, идентифицироваться по персональному паролю, получить доступ к своему сектору базы данных банка, заполнить соответствующую форму и так или иначе авторизовать свою операцию. В идеале минимально, что было бы нужно, - персональный пароль для соединения, файл цифрового сертификата формата Х.509 и пароль к контейнеру секретного ключа. Отдельные европейские банки уже давно пришли к выводу, что для расширения круга лиц, использующих систему типа BE, целесообразно сделать удобным доступ не только с домашнего ПК, но и с любого компьютера, подключенного к Интернету. Для этого либо максимально простой и компактный клиентский модуль (доведенный до "уровня домохозяйки" по примеру производителей бытовой техники) свободно скачивается с сайта банка, либо сервисный клиентский модуль вообще не используется (хотя в этом случае есть некоторые нюансы).

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

Россия вовсе не единственная страна, имеющая собственные национальные стандарты на криптографические алгоритмы. Но в подавляющем большинстве государств подразумевается, что такие стандарты предназначены для защиты национальных интересов в госсекторе, а коммерческий сектор получает свободу в выборе и использовании соответствующего ПО, легально продаваемого на рынке. Не важно, что поддерживаемые операционными системами алгоритмы RSA, SHA1, MD5, 3DES, RC2 в среднем, естественно, слабее национальных. Они достаточно надежны для коммерческого уровня при разумном выборе длины ключей, и это подтверждается повседневной практикой их использования сотнями банков по всему миру. А когда через 5-10 лет они перестанут удовлетворять потребителей по стойкости, не приходится сомневаться, что Microsoft и другие международные производители либо увеличат разрядность ключей, либо введут в криптопровайдеры поддержку новых алгоритмов. Ориентация на коммерческие алгоритмы дает огромное технологическое преимущество, поскольку они не только изначально поддерживаются на каждом компьютере, но их использование унифицировано, т. е. по ним нет проблем с совместимостью. А для российских криптоалгоритмов ЭЦП и шифрования ПО от различных отечественных производителей до сих пор в общем случае несовместимо. Есть государственные сертифицирующие органы, негосударственные ассоциации и комитеты, соглашения о сотрудничестве среди производителей, развернутые инициативы, многообразные предложения и т. д. А совместимости так и нет! И это длится не год, не два, а многие годы. В итоге "сон разума рождает технологических чудовищ".

Очевидно, что использование международных коммерческих криптоалгоритмов для клиентских систем могло бы быть самым простым, технологичным, дешевым и при этом достаточно безопасным решением. Так стоит ли идти "национальным" путем там, где мировое банковское сообщество идет "интернациональным"? Ведь горький афоризм 70-х ("советский компьютер - самый большой компьютер в мире") может возродиться в новом виде: "российские e-banking-системы - самые громоздкие системы в ВТО".

2. Законодательный аспект.

Подойдем, наконец, к проблеме с позиции российского законодательства в сфере ИБ. Здесь ключевой вопрос можно сформулировать так: следует ли считать электронную систему банковского обслуживания клиентов корпоративной информационной системой (КИС) или информационной системой общего пользования (ИСОП)? КИС кардинально отличается от ИСОП тем, что внутри нее правила игры определяет сам владелец системы. Определенную невнятность, царящую в банковской сфере даже по такому основополагающему моменту, хорошо иллюстрирует концептуальное выступление начальника отдела информационной безопасности Сбербанка России С. Н. Бондарева на 6-й Всероссийской конференции по информационной безопасности ("Инфофоруме") в феврале 2004 г. В нем докладчик резко критиковал Закон об ЭЦП в связи с невозможностью добиться разумными мерами полного соответствия существующих банковских систем всем формальным положениям закона, прежде всего использованию структуры цифровых сертификатов. Судя по выступлению, Сбербанк действительно чувствует себя не вполне уверенно, построив в свое время использование ЭЦП не на цифровых сертификатах, а на элементарном поддержании базы данных открытых ключей клиентов при отсутствии какого-либо сертификационного центра. Пусть примитивная, но вполне работоспособная схема, хотя и очень неудобная с точки зрения унификации. Менять ее недешево, а потому не хочется. Но если считать систему корпоративной, то беспокоиться не о чем, поскольку внутри нее можно использовать любые (в том числе и не соблюдающие структуру "удостоверяющий центр - цифровой сертификат") средства ЭЦП.

Примечательно, что г-н Бондарев в ходе доклада, с одной стороны, решительно отмежевался со своей банковской системой от ИСОП, а с другой - выразил по поводу сложившейся ситуации крайнюю озабоченность. Следовательно, в глубине души склонялся к тому, что система все-таки - общего пользования? Занимательнее всего выходы, которые он предложил: либо добиться изменения Закона об ЭЦП (что правильно, хотя и по другим причинам, не менее уважительным, чем экономия денег на ПО для Сбербанка), либо отказаться в банковских системах от терминов "Электронный документ", "ЭЦП", а употреблять термины "Код аутентификации сообщения", "Код подтверждения достоверности и авторства сообщения", чтобы вывести эти системы из-под прямого действия Закона об ЭЦП. С учетом того, что ЭЦП является на редкость характерной процедурой, которую невозможно ни с чем спутать, второй вариант особенно восхищает. По той же логике грабитель, наставивший в темном переулке пистолет на обывателя и вежливо попросивший взаймы, может не опасаться уголовной ответственности, так как формально имел место не разбой, а беспроцентный заем на неопределенный срок.

Обратившись к первоисточникам, т. е. к определениям ИСОП и КИС, данным, например, в том же Законе об ЭЦП, любой здравомыслящий человек способен сделать вывод о принадлежности банковских систем обслуживания к категории КИС. Хотя бы потому, что в услугах ИСОП не может быть отказано любым юридическим и физическим лицам. Но разве в вопросах технического обслуживания банки не руководствуются внутренними правилами, которые фактически отсекают нежелательных пользователей? Может, и нельзя отказать в открытии счета, но кто сказал, что невозможно отказать в предоставлении услуг электронной системы, по поводу использования которой заключается отдельное соглашение? Ведь в противном случае можно договориться до того, что нельзя отказать и в кредите!

3. Выводы, которые трудно назвать практическими.

Итак, раз системы "банк-клиент" являются корпоративными, то ничто, кроме определенного неодобрения (но не запрета!) со стороны лицензирующих деятельность в области ИБ органов, не мешает (и не мешало ранее) российским банкам использовать в них международные криптоалгоритмы. Более того, уже давно АРБ могла бы на основе межбанковских соглашений создать единый корпоративный удостоверяющий центр (УЦ) ЭЦП на алгоритме RSA, который (в отличие от федерального) мог иметь не только одноуровневую, но и двухуровневую структуру, включающую подчиненные УЦ отдельных банков. Получив в одном из банков сертификат ЭЦП, пользователь в дальнейшем мог бы оперировать им и в отношениях с другими банками. Разумеется, юридически значимое использование цифровых сертификатов корпоративного УЦ требует письменного оформления взаимного признания ЭЦП, но соль состоит в том, что банки все равно не намерены в будущем отказываться от письменного договора с клиентом об обслуживании, куда такой пункт входит. Тот выигрыш, который обещают в будущем федеральные УЦ для ИСОП, т. е. избавление от двусторонних письменных соглашений, для банковской сферы не столь существен.

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

С автором статьи, кандидатом технических наук, можно связаться по адресу: vnponomarev@aeroflot.ru.