Обращение
Председателю Правления банка
Президенту банка
Руководителям структурных подразделений
Начальнику управлению ИТ
Начальника отдела маркетинга
Директору Дирекции по облуживанию клиентов
Терехина Дмитрия Игоревича
Кратко о технологиях интернетбанкинга Начну с определения интернетбанкинга. Итернетбанкинг — это частный случай системы дистанционного банковского обслуживания, использующий в качестве канала связи меж-ду клиентом и банком всемирную компьютерную сеть Internet. Банки и их клиенты пришли к пониманию необходимости дистанционного обслуживания до-вольно давно, поскольку традиционные способы обслуживания перестали устраивать обе стороны. Первоначально для совершения любой банковской операции клиент должен был прибыть в банк лично и отдать соответствующие распоряжения банкиру, который знал его в лицо. За-тем распоряжения стали отдаваться письменно — банкир знал внешний вид подписи клиента и оттиска его печати. Этот способ используется в банках до сих пор — подпись и печать на бумажном платежном поручении проверяются на соответствие карточке образцов подписей и печатей (для частных клиентов используется только образец подписи). Поскольку для доставки бумажного документа с подписью и печатью из одной точки в дру-гую требуется некоторое время, следующим эволюционным шагом стало использование телефонной связи — клиент звонил в банк по телефону и отдавал соответствующие распоря-жения. Однако при таком способе взаимодействия сразу же встала проблема аутентифика-ции (подтверждения идентичности) клиента. Отвечающий на звонок сотрудник банка дол-жен был каким-то образом убедиться, что на том конце провода действительно тот человек, которым представился звонящий. Для преодоления данной проблемы применялись (и при-меняются до сих пор) различные решения. Например, сотрудник банка должен был пере-звонить по заранее определенному клиентом номеру и уточнить, действительно ли мистер Смит желает перевести 500 долларов со своего счета по указанным реквизитам, либо за-дать звонящему вопрос, ответ на который знает только мистер Смит и т. п. Впрочем, на во-просах аутентификации мы остановимся несколько позже. Одновременно банки стали задумываться и проблеме ускорения обработки распоряжений клиентов. Поступившее на бумажном носителе или в виде голосового сообщения платеж-ное поручение необходимо было проверить и ввести в компьютерную систему банка, а для этого требовалось обязательное участие человека. Для ввода бумажных документов стали применять сканеры и системы распознавания текста (либо дублировать информацию на документе в виде штрих-кода). Однако полностью ис-ключить ручные операции не удалось — проверять подпись и печать на документе и поме-щать его в сканер все равно должен был человек. В случае использования «телефонного» способа взаимодействия задача ввода информа-ции поддавалась автоматизации более полно — клиент мог вести диалог с автоматизирован-ной банковской системой при помощи телефона с тональным набором: указать свой иден-тификатор и пароль и ввести необходимую информацию непосредственно в систему. Оче-видно, что такой способ имеет целый ряд ограничений. Во-первых, возможности ввода ин-формации при помощи кнопок телефона существенно ограничены — фактически, можно только запросить остаток средств на счете и отправить платеж по заранее заданным рекви-зитам. Во-вторых, возникает сложность в решении вопросов защиты информации.
Все эти факторы, а также развитие средств вычислительной техники и телекоммуникаций привели к тому, что взаимодействие клиента с банком стало осуществляться на уровне компьютерных систем: платежное поручение в электронном виде передавалось по каналам связи с компьютера клиента непосредственно в автоматизированную систему банка. Обыч-но для этого клиенту необходимо было установить на свой компьютер специальное про-граммное обеспечение, а передача информации происходила путем «дозвона» до банков-ского компьютера при помощи модема. Конфиденциальность передаваемой информации обеспечивалась за счет ее шифрования, а целостность и аутентичность — за счет примене-ния электронной цифровой подписи. Такие системы, называемые обычно система «Клиент-
Страница 2 из 47
банк», успешно существуют и в настоящее время. Но у них есть один серьезный недостаток — чтобы добавить в систему новую функцию, необходимо внести изменения в программное обеспечение на компьютере клиента, а это не простая задача. Примерно в это же время начала бурно развиваться всемирная компьютерная сеть Internet. Она перестала быть просто информационной магистралью или сообществом инженеров и ученых. В интернете стали появляться виртуальные представительства различных компа-ний, и банки не стали исключением. Первоначально это были просто информационные сай-ты, где можно было получить общую информацию о банке, предоставляемых им услугах, курсах валют и т. п. Но очень скоро появилось понимание того, что нужна не просто «рек-ламная витрина», а средство для взаимодействия. Первой реакцией банков на эту потребность стал банальный перевод систем «клиент-банк» на использование вместо модема сети Интернет в качестве канала связи. Так появились си-стемы «интернет-клиент-банк». Это автоматически решило проблему с организацией много-канального телефонного доступа и позволило существенно расширить географию клиентов, поскольку сдерживающим фактором в распространении «клиент-банка» была необходи-мость дозваниваться до банковского сервера по междугородним телефонным каналам свя-зи. Однако проблема оперативного обновления программного обеспечения на компьютере клиента все равно оставалась. Элегантно решить эту задачу удалось путем перехода на использование веб-технологий. При таком подходе на компьютер клиента не нужно устанавливать и настраивать специали-зированное программное обеспечение — вся прикладная логика реализована на банковском веб-сервере, с которым клиент взаимодействует при помощи браузера, стандартно уста-навливаемого в составе Windows и других операционных систем. Технологически, процесс работы в интернетбанке ничем не отличается от общения в форуме или использования лю-бого другого интерактивного веб-ресурса. Отсутствие необходимости установки и настройки сложных программных комплексов дает возможность пользоваться таким способом взаимодействия с банком не только организаци-ям, в штате которых есть программисты, но и предприятиям малого и среднего бизнеса, и даже частным клиентам. Таким образом, мы можем сказать, что системы интернетбанкинга прошли эволюционный путь от простой информационной странички до «виртуального офиса». Выражение «вирту-альный офис» — это не дань моде, а отражение реальной сущности интернетбанкинга на со-временном этапе его развития. Иными словами, интернетбанк — это не отдельная банков-ская услуга, а способ доступа к банковским услугам. В идеальном интернетбанке клиент может получить тот же самый набор услуг, что и в традиционном офисе. Кроме операций с наличными денежными средствами — передавать по каналам связи купюры и монеты чело-вечество пока не научилось. Классификация систем интернетбанкинга Любое множество объектов можно классифицировать по различным критериям, и критери-ев этих, при желании, можно подобрать бесконечно много. С практической точки зрения це-лесообразно рассмотреть классификацию по способу аутентификации и по формам реали-зации. Классификация по способам аутентификации Для начала, во избежание путаницы, дадим определение трех терминов, значение которых на бытовом уровне часто трактуется произвольно. Идентификация — процесс присвоения меток субъектам доступа. Например, ввод имени пользователя. Аутентификация — подтверждение идентичности субъекта доступа. Например, ввод па-роля пользователя. Авторизация — предоставление аутентифицированному субъекту доступа к объектам в соответствии с предопределенным набором прав доступа.
Одним из самых простых и распространенных способов аутентификации является аутенти-фикация путем проверки пароля условно-постоянного действия. Однако в последнее время этот способ уже не считается достаточно надежным, особенно при использовании его в се-тях общего пользования. В связи с этим все большее распространение получают техноло-
Страница 3 из 47
гии двухфакторной аутентификации, в которых подтверждение подлинности клиента осуще-ствляется с использованием двух факторов: знания некого секрета (something to know) и об-ладания чем-либо (something to have). И, наконец, наиболее надежным, но и более слож-ным для внедрения и эксплуатации способом аутентификации, является аутентификация на базе инфраструктуры открытых ключей. Рассмотрим эти способы, а также их комбинации, подробнее. Пароли условно-постоянного действия Пароль выдается клиенту при подключении. Как правило, клиент может сменить пароль са-мостоятельно. Для обеспечения приемлемого уровня безопасности к паролю предъявляет-ся ряд требований: минимальная длина (количество символов), случайность (в качестве па-роля нельзя использовать имя и другие осмысленные конструкции), используемые в пароле категории символов (буквы в разных регистрах, цифры и прочие символы), периодическая смена пароля (обычно, не реже 1 раза в месяц), запрет на повторное использование паро-ля. Если рассматривать проблему защиты паролей в процессе аутентификации укрупненно, то можно выделить два основных подхода. Первый подход заключается в защищенном хранении паролей на сервере. При этом, в слу-чае хищения базы с паролями, злоумышленник не сможет воспользоваться этими данными непосредственно, ему понадобится произвести некоторое количество преобразований (под-час весьма сложных), так как пароли преобразованы односторонней функцией, и узнать их можно только «прогоняя» различные варианты паролей через эту функцию и сравнивая ре-зультат; в данной ситуации, это — единственный способ восстановления. Очевидно, что при таком подходе пользователь должен предъявлять серверу пароль в открытом виде, чтобы сервер, произведя с паролем соответствующее преобразование, сравнил полученный ре-зультат с записью в базе паролей. Ну, а коль скоро пароль предъявляется в открытом виде, возможен его перехват при передаче по каналам связи. Следовательно, этот подход можно применять только при условии использования защищенных каналов связи. Другой подход направлен на невозможность перехвата пароля при его передаче. В этом случае пользователь доказывает серверу, что ему известен правильный пароль, не путем предъявления его в открытом виде, а путем вычисления над предложенным сервером чис-лом некоей функции, зависящей также и от пароля. В простейшем случае это может быть шифрование предложенного сервером числа, используя в качестве ключа пароль. Естест-венно, что для проверки значения функции, присланного пользователем, серверу необхо-димо повторить данное преобразование, а для этого, в свою очередь, он должен обладать паролем в открытом виде. Схема похожа на предыдущую, изменяется только место вычис-ления односторонней функции. Очевидно, что при этом способе осуществления аутентифи-кации, необходимо принять меры по недопущению несанкционированного доступа к базе паролей на сервере. Технологии двухфакторной аутентификации Очевидно, что использование для аутентификации пароля условно-постоянного действия не очень удобно для пользователя системы (пароль нужно запомнить и периодически ме-нять). Кроме того, такой пароль может быть скомпрометирован и использован злоумышлен-ником -например, путем подсматривания или с помощью клавиатурного шпиона. Современ-ные видеокамеры имеют настолько малые размеры, что их можно закамуфлировать под безобидный предмет и установить совсем незаметно. Клавиатурный шпион, имеющий про-граммную реализацию, может быть обнаружен при применении надежных антивирусных средств. Однако, сегодня в соответствующем сегменте рынка широко представлены отно-сительно недорогие аппаратные устройства различных модификаций. Это могут быть ми-ниатюрные изделия в форме разъема, включаемые между клавиатурой и компьютером или тонкие накладки на клавиатуру. Таким образом, уже после первого использования пароля нельзя быть на 100% уверенным, что он не стал известен злоумышленнику.
Противостоять данной угрозе можно путем использования одноразовых паролей. Самым простым способом реализации данного подхода является печать и выдача пользователю карточек с набором паролей, каждый из которых будет использован ровно один раз. Реше-ние не самое технологичное и довольно затратное — банку необходимо организовать печать карточек и ввод соответствующих таблиц в систему, а клиенту периодически наведываться в банк для получения новой порции одноразовых паролей (и постараться не потерять кар-
Страница 4 из 47
точку). Более удобным вариантом является выдача клиенту специального устройства (то-кена), генерирующего пароли по определенному алгоритму, заданному банком. Для защиты от хищения или потери токена, многие модели генерируют очередной пароль только после ввода в них ПИН-кода. В результате получаем классическую схему двухфакторной аутенти-фикации, когда клиент должен обладать чем-то (токеном) и знать секрет (ПИН-код). Обра-тите внимание, что в данном случае секрет (ПИН-код) не попадает в не доверенную среду, а вводится лишь в надежное аппаратное устройство, установка клавиатурного шпиона в ко-торое практически нереальна. Существует еще одна, достаточно оригинальная схема с одноразовыми паролями. По-скольку мобильный телефон сейчас есть практически у каждого, то очередной пароль мо-жет генерироваться в банке и высылаться клиенту в виде SMS-сообщения. Клиент заходит на сервер банка, вводит свое имя и постоянный пароль, после чего сервер отсылает на за-ранее заданный клиентом номер очередной одноразовый пароль и просит ввести его в окне браузера. Скептики могут возразить, что передача SMS-сообщений идет по практически от-крытому каналу, и уж точно к их содержимому могут получить доступ сотрудники оператора сотовой связи. Во всяком случае, у них есть техническая возможность. Но безопасность данной схемы основывается на том, что злоумышленник не сможет одновременно контро-лировать и интернет-соединение клиента и его мобильный телефон, если, конечно, ему не подконтрольны технические средства всех разведок мира. Преимущества использования одноразовых паролей и схем двухфакторной аутентифика-ции очевидны — пароль используется только один раз, и даже если злоумышленник его пе-рехватит, он не будет иметь никакой ценности, ибо действителен только для одного сеанса или даже одной операции. Но необходимо обратить внимание на то, что аутентификация при помощи паролей позво-ляет лишь установить, что сеанс инициирован легитимным пользователем, но никак не обеспечивает целостность передаваемой информации. В случае если злоумышленнику все-таки удалось «вклиниться» в канал связи между клиентом и банком, то он может незаметно изменить передаваемые данные. Например, клиент отправляет платеж на 100 рублей и в качестве подтверждения вводит очередной одноразовый пароль, а злоумышленник меняет сумму со 100 на 1000 рублей. При этом банк не заметит подмены, ведь приложенный к со-общению одноразовый пароль — правильный. Также считаю необходимым и достаточным формировать одноразовые пароли с использо-ванием английских букв и цифр, длина одноразового пароля — не менее 8 символов. Аутентификация на базе PKI Описанные проблемы могут быть решены при использовании инфраструктуры открытых ключей (PKI, Public Keys Infrastructure). Перед тем, как рассматривать применение PKI в си-стемах интернетбанкинга, необходимо дать определение РКТ и сделать краткий экскурс в область знаний, именуемую «криптография». Инфраструктура открытых ключей (ИОК, PKI) представляет собой сложное и всеобъем-лющее понятие, за которым стоит целый комплекс организационных и технических меро-приятий, включающих набор политик, процедур, служб, а также программные и аппаратные средства. Основой ИОК является удостоверяющий центр (Certification Authority, СА) и набор приложе-ний, использующих цифровые сертификаты. Инфраструктура открытых ключей позволяет: • обеспечить конфиденциальность передаваемой по каналам связи информации;
• обеспечить целостность передаваемой информации;
• гарантированно удостовериться в авторстве информации;
• обеспечить «неотказуемость» любой из участвующих в транзакции сторон от своих действий.
ИОК базируется на использовании двухключевой криптографии (криптографии с открытым ключом).
В основе криптографии с открытым ключом лежит пара взаимосвязанных ключей: публич-ный (открытый) и личный (секретный). Секретный ключ известен только его владельцу и со-держится в тайне, а открытый ключ известен всем. Открытый и секретный ключи однознач-но связаны между собой, однако невозможно вычислить секретный ключ по открытому. Точнее, если формулировать совсем строго, то в настоящий момент не найдено алгорит-
Страница 5 из 47
мов, позволяющих осуществить такое вычисление за приемлемое время, с учетом совре-менного уровня развития вычислительной техники и используемой длины ключей. Самым распространенным применением криптографии с открытым ключом является электронная цифровая подпись (ЭЦП). В отличие от других аналогов собственноручной подписи, приме-няемых только на основании статей 160—3 и 434—2 Гражданского кодекса РФ, использование ЭЦП регламентировано Федеральным законом № 1-ФЗ от 10 января 2002 года «Об элек-тронной цифровой подписи» и прочими нормативными документами российской Федера-ции(можно со списком ознакомится с конце настоящего документа) ЭЦП представляет собой некое достаточно длинное число, полученное в результате преоб-разования электронного образа защищаемого документа с использованием секретного клю-ча отправителя. Проверка ЭЦП под документом осуществляется при помощи соответст-вующих преобразований с использованием, опять-таки, электронного образа документа, от-крытого (публичного) ключа отправителя и собственно значения ЭЦП. Следует обратить внимание, что поскольку значение ЭЦП зависит от секретного ключа отправителя, который кроме отправителя никому не известен, то в отличие от большинства других аналогов соб-ственноручной подписи, ЭЦП обладает свойством неотрекаемости. Иными словами, можно объективно доказать авторство документа. Отсюда следует, что открытый ключ должен быть известен всем, кто заинтересован в полу-чении подписанных ЭЦП документов от владельца соответствующего секретного ключа. Однако, заранее раздать свой открытый ключ всем своим потенциальным корреспонден-там, по очевидным причинам, не представляется возможным. Остается размещать ключ в публичных справочниках, либо пересылать адресату вместе с подписанным документом по каналам связи. Но в этом случае получатель не может гарантировано установить, что дан-ный ключ действительно принадлежит отправителю. Злоумышленник может сгенерировать свою пару ключей, поместить в публичный справочник свой открытый ключ от имени отпра-вителя. После этого он может посылать подписанные документы от чужого имени, или пе-рехватывать подготовленные настоящим отправителем документы, вносить в них измене-ния и подписывать своей подписью. Этот тип атак на криптосистемы получил название «не-законный посредник» или «человек посередине» (англ. man-in-the-middle, MiTM). Выходов из этой ситуации два. Первый заключается в том, что абонент системы лично пе-редает свой открытый ключ всем, с кем собирается вести переписку. По очевидным причи-нам он неприемлем (не со всеми можно встретиться лично, невозможно заранее преду-смотреть всех адресатов). Второй выход заключается в создании Центра сертификации (Certificate Authority). В качестве такого центра выбирается лицо, которому все доверяют, и с которым хотя бы один раз могут встретиться лично, либо имеют надежный (т.е. не допус-кающий искажений/подделок) канал связи. После выборов такого лица, все участники обме-на генерируют свои пары ключей и предъявляют их в Центр Сертификации. Центр Серти-фикации удостоверяет личность пришедшего (потому в законе об ЭЦП данные центры име-нуются «Удостоверяющие Центры») и подписывает его открытый ключ своим секретным ключом. Кроме собственно открытого ключа, в блок подписываемых данных включаются дополнительные сведения: имя владельца, другие идентифицирующие данные, сроки дей-ствия ключа, перечень информационных систем, в которых допустимо его использовать и другая информация (см. стандарты Х. 509 или статью 6 «Закона об электронной цифровой подписи»). Все это вместе (открытый ключ, блок данных и ЭЦП) называется сертификатом открытого ключа. Вместе с сертификатом своего открытого ключа владелец ключа получает на руки сертификат и открытый ключ Центра. Так как другие участники системы также полу-чают вместе с сертификатом копию открытого ключа Центра (получают лично — самый на-дежный канал), они могут удостовериться в принадлежности любого открытого ключа, не встречаясь лично с его владельцем, потому что теперь при установлении связи абоненты обмениваются не просто открытыми ключами, а сертификатами. При интерактивном взаимодействии двухключевые криптосистемы могут использоваться для выработки так называемого «общего секрета» по алгоритму Диффи-Хеллмана. Общий секрет обычно используется в качестве сеансового ключа для шифрования канала связи между клиентом и сервером. Теперь, когда мы определились с понятием PKI, рассмотрим его применение для аутенти-фикации в системах интернетбанкинга.
Страница 6 из 47
При использовании PKI пользователю системы нет нужды предъявлять банковскому серве-ру пароль. Клиент вводит свое имя, а сервер генерирует случайное число и предлагает клиенту подписать его своей электронной цифровой подписью. Если проверка подписи прошла успешно, значит, подключившийся субъект действительно тот, за кого он себя вы-дает, если нет — происходит отказ в авторизации (предоставлении доступа в систему). Важ-ный момент: в отличие от аутентификации при помощи пароля, клиент имеет возможность проверить и легитимность сервера, с которым он соединился, т. е. аутентификация является взаимной. Все эти проверки, как правило, происходят незаметно для пользователя, т. к. яв-ляются стандартной частью процесса установления соединения в протоколах SSL (Secure Sockets Layer) и TLS (Transport Layer Security), широко используемых для организации за-щищенного обмена информацией в системах электронной коммерции вообще, и в системах интернетбанкинга в частности. При дальнейшем обмене все передаваемые сторонами данные подписываются ЭЦП, что позволяет объективно удостовериться в их целостности и авторстве. В случае использования взаимной аутентификации сервера и клиента при помощи РКТ, подсистема криптографической защиты не позволяет взаимодействовать с сервером сис-темы интернетбанкинга на прикладном уровне без обладания соответствующим криптогра-фическим ключом, что существенно ограничивает круг лиц, имеющих возможность атако-вать прикладной сервер системы. Большинство злоумышленников не является клиентами банка, и, как следствие не обладает соответствующим криптографическим ключом. Эта ка-тегория имеет возможность атаковать лишь «внешнюю оболочку» сервера. Атаковать при-кладную часть смогут лишь злоумышленники из числа клиентов банка, но они обязательно оставят юридически значимые доказательства своих действий — ведь весь злоумышленный трафик будет подписан электронной цифровой подписью. Следует отметить, что, к сожалению, не во всех системах интернетбанкинга возможности PKI используются полностью. Очень часто SSL-соединение используется только для обес-печения защиты передаваемого пароля и устанавливается только с использованием откры-того ключа (точнее, сертификата) сервера банка. Такое соединение обеспечивает лишь конфиденциальность в рамках данной конкретной сессии, но к моменту установления со-единения клиент еще не аутентифицирован — для этого по-прежнему используется пароль. Отсутствие принудительной аутентификации банковского сервера приводит к тому, что кли-ент в результате ряда манипуляций может попасть на поддельный сайт банка, который бу-дет эмулировать настоящий сайт и использовать введенную клиентом конфиденциальную информацию для доступа к его счетам. Впрочем, и при полноценном использовании PKI остается ряд угроз. Человек не может дер-жать в памяти криптографические ключи, он вынужден хранить их на носителе информации — дискете, «флешке» и т. п. Похитив или скопировав ключевой носитель, злоумышленник по-лучает возможность формировать ЭЦП от имени пользователя. На первый взгляд, пробле-ма решается просто — достаточно установить пароль на доступ к ключевому носителю. Од-нако далеко не всегда ключевой носитель используется с компьютером, в «чистоте» которо-го мы уверены. Вредоносные программы могут перехватить ввод пароля и скопировать уже разблокированный ключ. Конечно, в отличие от обычных программ перехвата паролей, «комплексные» шпионы встречаются очень редко. Это связано с тем, что «перехватчик па-ролей» — программа универсальная, а для копирования ключей вместе с паролем нужно учитывать особенности конкретной системы. Тем не менее, чисто технически, такая атака возможна. Гибридные схемы Для минимизации угроз, а в некоторых случаях и полной их нейтрализации, логично исполь-зовать сильные стороны рассмотренных видов аутентификации путем создания гибридных схем.
Очевидно, что и клиент, и банк наилучшим образом защищены при использовании аутенти-фикации на базе PKI — стороны надежно аутентифицируют друг друга, передаваемые дан-ные защищены от случайного или умышленного искажения, схема обеспечивает неотре-каемость транзакций. Но, как мы помним, остается угроза копирования секретного ключа клиента при помощи вредоносных программ. Полностью устранить данную угрозу невоз-можно: во-первых, клиент не всегда может работать с доверенного компьютера, во-вторых, даже при регулярном обновлении антивирусных программ гарантировать 100% чистоту не
Страница 7 из 47
возьмется никто. Но, несмотря на то, что мы не можем устранить саму угрозу, мы можем предотвратить (или, по крайней мере, свести к минимуму) последствия ее реализации. Одним из вариантов построения гибридной схемы может быть использование системы од-норазовых паролей в дополнение к PKI (т.е. шифрованию и ЭЦП). Высокий уровень безо-пасности этого варианта основывается на том, что даже если вредоносная программа ско-пирует секретный ключ клиента, она не сможет «скопировать» карточку с одноразовыми па-ролями, аппаратный генератор паролей или сотовый телефон, на который банк присылает очередной пароль. Легко заметить, что в последнем случае (сотовый телефон) одновре-менно реализуется и своеобразная «сигнализация» о хищении ключа. Если клиенту, кото-рый в данный момент не сидит перед компьютером и не работает в системе интернетбан-кинга, вдруг придет SMS с очередным паролем, это будет сигналом того, что кто-то завла-дел его ключом и пытается работать с системой. На первый взгляд может показаться, что вводить одноразовый пароль в дополнение к ЭЦП неудобно для клиента, и достаточно лишь сделать SMS-оповещение о факте входа в систему или попытке подписать платежное поручение. Однако в случае с подписанием «платежки» клиент получит информацию о том, что деньги уже ушли. Конечно, он сразу же заблокирует ключ и дальнейшее его использо-вание злоумышленником станет невозможным, но некоторая сумма будет потеряна. В слу-чае обязательного ввода одноразового пароля похитивший ключ злоумышленник не сможет похитить деньги со счета. Описанная гибридная схема позволяет клиенту гибко управлять рисками. Например, клиент может задать максимальную сумму платежа, который можно от-править без запроса одноразового пароля, определить, нужно ли запрашивать одноразовый пароль для просмотра остатка на счете, при входе в систему и т. п. Итак, мы рассмотрели основные способы аутентификации в системах интернетбанкинга и электронной коммерции: аутентификация при помощи пароля условно-постоянного дей-ствия, аутентификация при помощи одноразовых паролей, аутентификация на базе PKI и гибридные схемы. Также считаю необходимым и достаточным формировать одноразовые пароли с использо-ванием английских букв и цифр, длина одноразового пароля — не менее 8 символов. Перейдем к классификации систем интернетбанкинга по формам реализации. Классификация по формам реализации. «Толстый клиент»
Как уже говорилось, при обдумывании способа организации управления банковским счетом через Internet, первая же идея, приходящая в голову, заключается в переносе уже устояв-шейся технологии «клиент-банк» на новый способ взаимодействия. Для банка, работающе-го по технологии «клиент-банк» такой способ является наименее затратным, т. к. меняется только канал связи, программное же обеспечение — как на стороне банка, так и на стороне клиента — остается практически без изменений. Необходимость установки на стороне клиен-та специального программного обеспечения имеет и отрицательные стороны. Во-первых, это отсутствие (или резкое ограничение) мобильности клиента. Действительно, отправляясь в поездку и желая осуществлять работу со своим счетом из офиса делового партнера, кли-ент кроме основных атрибутов (ключевого носителя и пароля) вынужден брать с собой пор-тативный компьютер с установленным программным обеспечением либо его дистрибутив. Во-вторых, у банка сразу же появляется проблема сопровождения клиентского программно-го обеспечения. Это не только решение проблем со сбоями (писать программы без ошибок люди еще не научились), но и сложность организации перехода на новые версии. При на-хождении клиента в непосредственной близости (в одном городе) большинство вопросов можно решить по телефону, в крайнем случае, выехать к клиенту. При расположении же по-следнего на достаточном отдалении, зачастую и в другом часовом поясе, оперативное раз-решение нестандартных ситуаций и обновление программ становится затруднительным. С другой стороны, клиентское рабочее место в виде «полноценного» АРМа, является более безопасным решением, т. к. взаимодействие с банком и работа с подсистемой криптографи-ческой защиты происходит с одного и того же компьютера, который может быть оснащен средствами защиты от несанкционированного доступа, а также защищен организационными мерами. Такая конфигурация, по сравнению с «тонким клиентом» позволяет также миними-зировать затраты на подключение к Internet для взаимодействия с банком: многие операции (подготовка исходящих документов) могут быть проведены предварительно (off-line); суще-ственно ниже объем трафика при обмене (нет необходимости загружать с сервера формы,
Страница 8 из 47
скрипты, аплеты и т. п.), не нужно соединяться с банком, чтобы просто посмотреть архив до-кументов. «Истинно тонкий клиент» Данный вариант имеет принципиальное отличие от предыдущего: он не предусматривает предварительной установки на стороне клиента специализированного программного обес-печ ения, функциональность рабочего места клиента обеспечивается либо использованием штатных криптографических библиотек браузера и операционной системы, либо путем за-грузки web-браузером динамического кода (Java-аплета). Во втором случае безопасность загрузки и целостность кода обеспечиваются встроенными функциями web-браузера, одна-ко, для этого аплет должен быть подписан ключом разработчика, удостоверенным одним из мировых центров сертификации открытых ключей электронной цифровой подписи, чьи сер-тификаты, в свою очередь, поставляются со всеми распространенными web-браузерами. Проверка целостности и аутентичности аплета происходит в два этапа. На первом этапе браузер получает сертификат открытого ключа разработчика аплета и проверяет его при помощи имеющегося у него открытого ключа издателя сертификата (VeriSign, Thawte, Key-Witness, GTE Cyber Trust и т. п.). На втором этапе при помощи только что удостоверенного открытого ключа разработчика проверяется электронная цифровая подпись собственно ап-лета. Теперь, когда целостность и аутентичность загруженного аплета подтверждена, ему можно безопасно передать управление. Выполняемые аплетом или непосредственно брау-зером функции полностью совпадают с функциями стационарного программного обеспече-ния, рассмотренного в предыдущем варианте: идентификация и аутентификация сервера и клиента, шифрование трафика, электронная цифровая подпись документов, графический интерфейс пользователя, взаимодействие с банковским сервером. Данный вариант предоставляет клиенту очень высокую мобильность: он может управлять своим счетом с любого подключенного к Internet компьютера, оснащенного web-браузером, имея с собой лишь ключевой носитель (дискету) и пароль. Однако, мобильность (как и лю-бой другой показатель удобства) находится в противоречии с защищенностью: чем более защищена система, тем менее она удобна, и наоборот. Действительно, работая с «чужого» компьютера и поручая ему при этом такие «интимные» функции как считывание секретного ключа электронной цифровой подписи и проверку целостности программного обеспечения, трудно быть полностью уверенным в его «лояльности». Между тем, вирусы, троянские про-граммы, похитители паролей и другие вредоносные программы, которые могут на нем ока-заться, в состоянии скомпрометировать самую совершенную и безукоризненно реализо-ванную систему криптографической защиты. Мобильность также ограничивает возможности по ведению на стороне клиента протокола общения с банковским сервером, в частности, накопления подписанных ЭЦП банка подтверждений о приеме к исполнению документов, которые могут быть использованы в качестве доказательств при возникновении конфликт-ной ситуации. Тем не менее, этот вариант архитектуры интернетбанкинга остается чрезвы-чайно привлекательным вследствие своей платформонезависимости: веб-браузеры и вир-туальная java-машина реализованы практически для всех операционных систем и плат-форм. Более того, во многих случаях эта схема будет работать и на устройствах, не яв-ляющихся полноценными компьютерами (коммуникационные устройства, различные виды «карманных» устройств). Пример такого использования можно увидеть в продуктах следующих банков ОАО Урал-трансбанк,ОАО Уральский банк реконструкции и развития, ЗАО ВТБ24, ОАО Инвестбанк. «Тонкий клиент со вспомогательным ПО»
Это архитектурное решение является попыткой совместить два уже рассмотренных вариан-та. С одной стороны, оно не подразумевает установки «тяжелого» комплекта программного обеспечения («толстого клиента»), с другой стороны часть наиболее критичных функций вы-носится в отдельный исполняемый модуль, который является единственным клиентским ПО, которое клиенту необходимо иметь до начала работы. Это может быть, например, не-большой прокси-сервер, запускаемый на клиентском компьютере и реализующий функции шифрования трафика и электронной цифровой подписи. В этом случае интерфейс пользо-вателя может быть реализован средствами форм языка html и динамическим формирова-нием страниц (cgi, php, jsp, asp и т. п.), что позволит использовать «легкие» браузеры, в том
Страница 9 из 47
числе текстовые и не имеющие встроенной поддержки Java. Другой вариант разбивки функций — инсталляция на клиентский компьютер библиотечных модулей, реализующих не-обходимые криптографические функции, и обращение к ним непосредственно из java-аплета. Альтернативный путь использования криптографических библиотек — установка их в виде CSP (crypto service provider) и вызов необходимых функций через стандартный API, в том числе, средствами браузера. Такой комбинированный подход также имеет свои плюсы и минусы. Наличие на клиентском компьютере кода, реализующего криптографические функции, упрощает процедуру установления соединения с банковским сервером, т. к. нет необходимости в загрузке такого кода через Internet и его верификации, но в отличие от ар-хитектуры «толстого клиента» сохраняется возможность оперативного обновления при-кладной части клиентского ПО, т. к. она остается загружаемой. Использование подхода с предварительной инсталляцией библиотек в виде CSP практически лишает решение мо-бильности, а применение компактного прокси-сервера, не требующего специальной проце-дуры инсталляции, ограничивает пределы мобильности выбранной платформой (например, WI№ 32). Впрочем, высокая распространенность платформы WI№ 32 делает это ограничение несущественным. Следует также отметить, что архитектура «тонкий клиент со вспомогательным ПО» позволя-ет использовать преимущества «тонкого клиента» в случаях, когда законодательство тре-бует применять исключительно сертифицированные криптографические средства на базе российских алгоритмов. Мое личное мнение использование гибридной системы+специального устройства с вводом пароля к ЭЦП и сам ЭЦП в качестве etoken or CardReader и смарт-карта является опти-мальным решением, но обладает недостатками установки драйверов в операционную сис-тему, эту проблему могут решить производители оборудования путем направления своих драйверов разработчикам операционных систем. Мое мнение может быть субъективным и спорить о преимуществе того или иного способа удаленного доступа. Выбор того или иного способа доступа зависит от корпоративной политики Банка и требований Центрального Банка на тот момент времени.
Страница 10 из 47
Дискуссии между специалистами на тему, какой «толщины» клиентское программное обес-печение является оптимальным, являются перманентными. Как видно из приведенных вы-ше таблиц, аргументов за любое из решений достаточно много, поэтому каждый банк реша-ет данный вопрос, исходя из своих конкретных условий. Возможно, уже в ближайшем вре-мени приведенная классификация не будет соответствовать действительности, т. к. про-гресс не стоит на месте. В частности, применение технологии «Smart Update», позволяющей не загружать каждый раз java-аплет (или другой динамический компонент), размывает грань между «тонким» и «толстым» клиентом. Действительно, если аплет после первой загрузки хранится в специальном кэше на клиентском компьютере и лишь проверяется на актуаль-ность и целостность при последующих сессиях, его можно рассматривать как установлен-ное ПО. С другой стороны, развитие технологий автоматического обновления программ по-зволяет сделать синхронизацию версий клиентского ПО совершенно прозрачной для клиен-та и удобной для банка.
Достоинства
Недостатки
1 Отсутствие необходимости каждый раз проверять целостность программного обеспечения. 2. Простота реализации организационных и техни- ческих мер защиты от несанкционированного доступа к используемому компьютеру. 3. Минимизация трафика и времени подключения за счет реализации части операций off-line и от- сутствием необходимости загрузки вспомога- тельных данных (форм и т. п.). 4. Простота перехода с «традиционной» системы «клиент-банк». 5. Возможность ведения протокола с электронной цифровой подписью не только на банковском сервере, но и на стороне клиента.
1 Низкая мобильность. Необходимость предварительной установки ПО делает невозможной работу клиента с произвольного компьюте-ра, подключенного к Internet. 2. Сложность оперативного обновления версий ПО и оказания помощи при пер- вичноq установке. 3 Привязка к определенной операционной системе и платформе.
Таблица 2. Достоинства и недостатки «истинно тонкого клиента»
Достоинства
Недостатки
1 Высокая мобильность. 2. Платформонезависимость. 3. Отсутствие необходимости предварительной установки программного обеспечения 4. Возможность оптимизации трафика за счет загрузки всех необходимых форм в составе аплета. 5 Простота обновления.
1 Невозможность создания «доверенной среды функционирования(при работе с «чужого» компьютера). 2. Ограничение возможности полноценного протоколирования на стороне клиента.
Таблица 3: Достоинства и недостатки «тонкого клиента со вспомогательным ПО»
Достоинства
Недостатки
1. Выделение защитных функций в хранимый у клиента модуль обеспечивает более высокий (в сравнении с «истинно тонким» клиентом) уро- вень безопасности. 2. Простота обновления прикладной части клиент- ского программного обеспечения. 3. Отсутствие необходимости каждый раз прове- рять целостность всего программного обеспече- ния. 4. Возможность смены криптосистемы и добавле- ния других защитных функций (например, меж- сетевого экрана) независимо от прикладной ча- сти программного обеспечения. 5. Достаточно высокая мобильность (в пределах компьютеров одной платформы).
1. Ограничение мобильности привязкой к определенной платформе. 2. Невозможность создания «доверенной среды функционирования» (при работе с «чужого» компьютера). 3. Ограничение возможности полноценного протоколирования на стороне клиента.
Таблица 1 Достоинства и недостатки «толстого клиента»
Страница 11 из 47
Нельзя не вспомнить и о бурном развитии аппаратных средств, на которые можно перело-жить часть функций клиентского ПО. На рынке широко представлен целый ряд решений, позволяющих осуществлять операции с криптографическими ключами не в компьютере, а в подключаемом к нему внешнем устройстве. Это может быть USB-токен, устройство типа i-button, и, конечно же, смарт-карта. Поскольку данные устройства имеют достаточно мощный процессор, фактически, микрокомпьютер со своей ОС, и позволяют не только выполнять криптографические функции, но и безопасно хранить криптографические ключи, пароли, PIN-коды и другую конфиденциальную информацию, то они обеспечивают достаточно высо-кий уровень защиты от получения информации «грубыми» методами: существуют как обра-тимая, так и необратимая блокировки устройства при многократном неправильном вводе PIN-кода. Конечно, для нормальной работы таких устройств потребуется установка драйве-ров, что ограничивает спектр применения. Проблема может быть решена либо унификаци-ей интерфейса, либо использованием полностью автономных устройств со своей клавиату-рой, например, компаний VASCO или TODOS. В последнем случае клиент совершенно не зависит от разновидности компьютера, с которого он работает с системой интернетбанкинга — он печатает данные платежа непосредственно на клавиатуре устройства, а выданный уст-ройством ответ уже вводит в интерфейс системы интернетбанкинга. Внутреннее устройство и функциональное наполнение системы интернетбан-кинга на примере ОАО Северная Казна Архитектура Итак, мы рассмотрели классификацию систем интернетбанкинга по различным критериям. Теперь давайте остановимся на внутренней архитектуре системы интернетбанкинга и вы-полняемых ею функциях. Как уже говорилось выше, современная система интернетбанкинга — это «виртуальный офис» банка, и она должна выполнять все те же функции, что и офис традиционный. Рас-смотрим кратко процесс взаимодействия клиента с банком (Рисунок 1). Обращаясь в банк, клиент имеет дело с «фронт-офисом» («фронт-зоной»), т. е. непосредственно контактирует с сотрудником банка в отделении или филиале. Сотрудник банка идентифицирует клиента и производит необходимые действия в автоматизированной банковской системе (АБС). Под АБС в данном случае понимается не только учетно-операционное ядро, где ведутся счета клиентов, но и целый ряд других систем — система обслуживания банковских карт (процес-синг), внутренняя система электронного документооборота, скоринговая система, система уведомления поставщиков услуг о платежах (биллинг) и т. п. Как правило, в обслуживании клиента задействованы и другие подразделения банка, не контактирующие непосредствен-но с ним, так называемый «бэк-офис». Эти подразделения, в частности, обрабатывают до-кументы, связанные с банковскими картами, осуществляют выпуск карт, исполняют заявки на кредиты, производят отправку платежей в другие банки и выполняют множество других очень важных действий.
Страница 12 из 47
С другой стороны, если сервер интернетбанкинга будет работать в режиме синхронизации информации с АБС путем обмена файлами несколько раз в сутки, потеряется оператив-
Страница 13 из 47
ность: клиент не будет видеть актуальный остаток средств на счете, а отправленные доку-менты будут исполняться с задержкой. Для реализации оперативного и одновременно безопасного взаимодействия между серве-ром интернетбанкинга и АБС в современных системах интернетбанкинга используются сер-веры очередей (Рисунок 3). Бэк-офис Рисунок 3: Сервер очередей — безопасный посредник Работа сервера очередей несколько напоминает обмен файлами: одна система помещает порцию информации в виде сообщения в очередь, а другая система извлекает сообщение из очереди и обрабатывает его. Результат обработки также передается через сервер оче-редей, но уже в обратном направлении. Например, сервер системы интернетбанкинга помещает во входящую очередь для АБС со-общение с платежным поручением. АБС извлекает сообщение, проверяет платежное пору-чение, обрабатывает его и помещает сообщение с результатом обработки во входящую очередь для сервера системы интернетбанкинга. Аналогичным образом в АБС отправляет-ся запрос на получение текущей суммы средств на счете, а ответ попадает на сервер сис-темы интернет-банкинга. Описанные действия происходят во много раз быстрее, чем синхронизация при помощи файлов, и выглядят для конечного пользователя так, как будто с АБС установлена прямая связь. При этом некоторые запросы, обработка которых может потребовать длительного времени, могут выполняться в асинхронном режиме. Это означает, что, отправив запрос, сервер сис-темы интернетбанкинга не ожидает ответа сразу же, чтобы представить результат клиенту, а лишь информирует пользователя о том, что запрос отправлен, и ответ будет помещен в папку входящих документов по окончании обработки. Возможна и прямо противоположная ситуация — некоторые операции требуют успешного вы-полнения серии последовательных запросов; и если хотя бы один из запросов не выпол-нился, все остальные должны быть отменены. Типичным примером такой операции, называемой «транзакционной», является перевод средств со счета, связанного с банковской картой. Очевидно, что операция должна найти свое отражение как в учетно-операционном ядре АБС, так и в системе обслуживания бан-ковских карт. Функциональное наполнение
Как уже говорилось, система интернетбанкинга — это не услуга сама по себе, а способ досту-па к банковским услугам. Таким образом, в системе интернетбанкинга должен быть пред-ставлен максимально широкий спектр услуг. В идеале, система должна предоставлять воз-можность воспользоваться всеми теми же услугами, которые доступны клиенту в традици-
Страница 14 из 47
онном офисе. Таблица 4 иллюстрирует примерный перечень функций. Рассмотрим их под-робнее.
Таблица 4: Классификация функций системы интернетбанкинга Основные функции Плате-жи произвольные с использованием справочников по шаблонам разовые периодические автоматические в национальной валюте в иностранной валюте Работа с текущими счетами Просмотр списка счетов Получение информации об остатке на счете Получение выписки по счету Просмотр входящих и исходящих документов От-крытие счета Закрытие счета Работа с депозитами Просмотр списка депозитов Просмотр свойств депозита Управление процентами Расчет доходности Пополнение депо-зита Частичное изъятие депози-та Открытие депозита Закрытие депозита Пролонгация депозита
Работа с кредитами Просмотр списка кредитов Про-смотр свойств кредита Расчет за-долженности Расчет графика пога-шения Подача заявки на кредит — Погашение кредита Работа с банковскими картами Просмотр спи-ска карт Просмотр свойств карты Про-смотр операций по карте Просмотр за-резервированных операций по карте Перепривязка карты к счету Настройка индивидуального меню для банкоматов и создание собственных шаблонов Установка лимитов на операции с кар-той Настройка уведомлений (электронная почта, SMS, ICQ и т. п.) о событиях с картой Генерация виртуальной карты Подача заявки на выпуск карты Блокирование карты
Вспомогательные функции Ведение справочников Настройка системы Электронный документооборот Программы лояльности Допол-тельные услуги Первая группа функций связана с самой привычной для нас банковской услугой — осуще-ствлением платежей. Платеж может быть «свободным» или «стандартным». В первом случае клиент сам запол-няет абсолютно все поля платежного документа, при этом возможна некоторая автоматиза-ция, например заполнение реквизитов получателя платежа из специального справочника контрагентов. Современные системы позволяют пользователям также создавать шаблоны платежей, из которых затем можно быстро создать нужный платеж, не вводя информацию вообще, или заполнив лишь несколько полей (например, указав сумму). Стандартные платежи по своей сути являются созданными банком шаблонами, в которых большая часть реквизитов фиксирована и не подлежит изменению, а клиенту необходимо лишь указать некоторые «персонализирующие» детали. В частности, для совершения пла-тежа по стандартному шаблону оплаты услуг телефонной компании клиенту достаточно ввести лишь свой номер телефона и указать сумму, остальные данные система возьмет из своих справочников и заполнит все поля платежного документа совершенно «прозрачно» для клиента. Клиент может каждый раз сам инициировать платеж, а может дать банку задание формиро-вать платеж автоматически — с определенной периодичностью или по наступлению опреде-ленного события. Например, указывает, что поручает банку 1 числа каждого месяца пере-числять определенную сумму по указанным реквизитам, либо оплачивать выставляемые ему счета.
Обычно платеж исполняется банком сразу же послу получения от клиента платежного пору-чения или заявления на перевод. Однако клиент может задать определенную дату испол-нения данного платежа. При недостаточности средств на счете клиент может создать пла-теж и поручить банку его исполнить тогда, когда на счете появятся необходимые средства. Платеж может совершаться в национальной валюте (в рублях) или в одной из иностранных
Страница 15 из 47
валют. Несколько особняком стоит так называемый конверсионный платеж, когда клиент за одну валюту покупает другую, т. е. платит банку определенную сумму со своего счета в од-ной валюте и получает некоторую сумму на свой счет в другой валюте в соответствии с кур-сами конвертации. Платеж также может осуществляться с автоматической конвертацией. В этом случае сначала производится конвертация нужной суммы на счет в другой валюте, по-сле чего уже осуществляется платеж. Но для клиента это выглядит как одна операция. При выполнении платежа банк может также оказывать дополнительные услуги. Например, при платеже в адрес оператора мобильной связи или другого поставщика услуг, поставщик ус-луг может уведомляться о факте платежа. Это позволяет ему сразу же пополнить лицевой счет клиента в своей биллинговой системе, не дожидаясь, пока денежные средства придут на счет поставщика. Не менее важен для клиента и набор функций для работы с текущими счетами. В системе интернетбанкинга должна быть возможность просмотра списка текущих счетов клиента, по-лучения информации об остатке средств на каждом счете, запроса и получения выписки по счету, просмотра входящих и исходящих платежных документов. Очень удобны функции от-крытия и закрытия счетов через систему интернетбанкинга, однако дистанционное открытие счетов законодательно разрешено не во всех случаях. Блок функций по работе с депозитами (вкладами) включает в себя просмотр списка депо-зитов, просмотр свойств депозита, управление депозитом (пополнение с другого счета, рас-поряжение процентами, частичное изъятие средств, пролонгация или закрытие депозита), расчет дохода на определенную дату. Через систему интернетбанкинга может быть реали-зовано и открытие депозита, но с той же самой оговоркой, что и про текущий счет — законо-дательство разрешает делать это дистанционно не во всех случаях. Следующий блок функций — работа с кредитами. В нем также могут быть представлены все те же действия, которые клиент совершает при визите в банк, а именно: просмотр списка кредитов, просмотр свойств кредита (кредитного договора), расчет задолженности, расчет и просмотр графика погашения, гашение кредита, подача заявки на кредит. По мере роста распространенности банковских карт, особенно международных платежных систем, стали востребованы и соответствующие функции в системе интернетбанкинга. В этот блок функций входит просмотр списка карт, просмотр свойств карты, просмотр опера-ций по карте (в том числе зарезервированных), «перепривязка» карты к разным счетам, со-здание собственных платежных шаблонов и индивидуальных меню для банкоматов, уста-новка различных лимитов на операции с картой, настройка уведомлений (электронная поч-та, SMS, ICQ и т. п.) о событиях с картой (оплата, проверка ПИН-кода, окончание срока дей-ствия и т. п.), генерация виртуальной карты для оплаты товаров и услуг в сети Internet, пода-ча заявки на выпуск новой карты, блокирование карты. Система интернетбанкинга должна предоставлять клиенту и набор вспомогательных функций. В первую очередь это различные справочники, как создаваемые и поддерживае-мые банком (например, справочник банков Российской Федерации), так и индивидуальные справочники клиента (например, справочник контрагентов, индивидуальные и групповые шаблоны и т. п.). Клиенту также должна быть предоставлена возможность осуществлять различные настрой-ки системы интернетбанкинга. В частности, настраивать уведомления о различных событи-ях (вход в систему, приход платежа, приближение даты оплаты и т. п.) и задавать канал дос-тавки (электронная почта, SMS, ICQ и т. п.). Функции работы со средствами безопасно-сти могут включать активацию и блокировку аутентификаторов (аппаратных токенов, таб-лиц одноразовых кодов и т. п.), а также блокировку доступа к системе. Поскольку при традиционном банковском обслуживании между клиентом и банком идет об-мен не только платежными документами, в системе интернетбанкинга необходим электрон-ный документооборот. В рамках этого документооборота клиент может вести в электрон-ном виде переписку с банком, направлять в банк различные заявки (например, кассовую за-явку), заключать договоры и соглашения, формировать и передавать в банк различные ве-домости (например, зарплатные), и т. п.
В последнее время получили широкое распространение различные бонусные программы, направленные на поддержание лояльности клиентов. Банки не стали исключением и в этом процессе. Соответственно, система интернетбанкинга должна предоставлять клиенту воз-
Страница 16 из 47
можность работы с бонусной программой — просмотр накопленных бонусов, управление опциями, использование бонусов. И, наконец, в системе интернетбанкинга может предоставляться целый спектр дополни-тельных услуг. К нему можно отнести, включая, но, не ограничиваясь, следующее:
1. Аренда сейфовых ячеек
2. Покупка и продажа драгоценных металлов
3. Подача заявок на биржевые операции (фондовый рынок, форекс)
4. Приобретение паев инвестиционных фондов, размещение средств в доверительное управление
5. Формирование и передача различных видов отчетности (налоговая, пенсионная и т. п.)
6. Мини-бухгалтерия
Итак, мы рассмотрели функциональное наполнение систем интернетбанкинга. Конечно, рассмотренный перечень функций не является исчерпывающим, поскольку перечень пре-доставляемых банками услуг постоянно растет, и, соответственно, расширяется функцио-нал систем интернетбанкинга. Вместе с тем данный перечень не является и обязательным — если банк не предоставляет какую-либо услугу в обычном офисе, соответствующей функции нет и в системе интернет-банкинга. Заканчивая обзор функциональных возможностей, необходимо отметить один важный мо-мент: спектр предоставляемых через систему интернетбанкинга услуг зависит от используе-мого в системе способа аутентификации клиента и разновидности аналога собственноруч-ной подписи. Так, например, в системах, использующих только лишь пароли (одноразовые или условно-постоянного действия), как правило, не доступны функции, связанные с подпи-санием договоров, соглашений и других подобных документов. Это связано с тем, что па-роль в качестве аналога собственноручной подписи не обладает свойством неотрекаемо-сти, и потенциальная конфликтная ситуация с таким документом не может быть разрешена объективно. По этой же причине банки обычно выставляют лимит на максимальную сумму операции в таких системах, ограничивая, таким образом, свой риск до определенного уров-ня. В системах с использованием электронной цифровой подписи таких ограничений обыч-но нет. С другой стороны, поскольку системы с ЭЦП несколько сложнее в использовании, а «критичные» функции нужны клиенту не каждый день, банки иногда предлагают одновре-менно два варианта системы интернетбанкинга: «полновесную» (с ЭЦП) и «облегченную» (с другим способом аутентификации). «Облегченной» («light») версией клиент пользуется каж-дый день, в ней сосредоточен лишь небольшой набор часто используемых функций, как правило, «бытовых» платежей. Доступ к этой версии клиент может получить с целого ряда устройств, в том числе и тех, на которых использование электронной цифровой подписи за-труднено или невозможно в принципе. К «полновесной» версии он обращается лишь эпизо-дически, как правило, с доверенного компьютера, ибо подписывать договоры с банком, от-правлять крупные платежи или настраивать какие-либо параметры необходимость возника-ет далеко не каждый день.
Страница 17 из 47
Оптимизация Считаю оптимизацией в интернет банке внедрение единой подписи (ЭЦП). Ведь в ре-альном мире у человека, в каком бы качестве он ни выступал, она всегда одна. Почему в цифровом мире должно быть иначе? Зачем человеку пять электронных ключей для пяти разных счетов в одном банке? У человека могут быть личные счета в банке, в то же время он может быть и директором, и учредителем в нескольких организациях, которые обслужи-ваются здесь же, — везде подпись будет одна- считаю что данное решение более целесо-образным. Заходя со своим ключом, он видит все счета, которыми имеет права распоря-жаться. И свои личные, и счета предприятия, где является распорядителем счета. Для бизнеса и частных клиентов Используя Интернетбанк, частные пользователи могут сделать платеж со своего счета, в том числе оплачивать различные коммунальные платежи, услуги связи и т. п. Причем в по-следних случаях уже существуют готовые шаблоны. Наиболее часто используемые пла-тежи представлены уже не в форме платежного поручения, а в виде простого диалогового окна — допустим, для оплаты счета за электроэнергию — запрашивается только номер ли-цевого счета в ЕЭСК и сумма. Еще одна удобная функция — создание виртуальной карты VISA Virtuon. Пользователь генерирует виртуальную карту с заданными ограничениями и рассчитывается ею в Интернет-магазинах, не опасаясь в дальнейшем за сохранность сво-его карточного счета. Для такой карты можно задать минимально короткий срок действия — буквально вос-пользоваться для одного платежа, поставить лимит, равный нужной сумме, и без риска рас-считаться с ее помощью в Интернете. Также среди функций присутствуют или находятся в стадии разработки/внедрения заявления на выпуск карты, изменения кредитных лимитов, блокировка и другие «карточные» функции, которые можно осуществить в офисе. Кроме уже перечисленных функций, в системе очень важна форма «Письмо в банк». По-скольку отправленное таким образом послание снабжено электронной цифровой подписью, оно имеет юридическую силу. А главное, оно не потеряется, поскольку автоматически попа-дает во внутреннюю систему электронного документооборота, где будет маршрутизировано соответствующему сотруднику банка. В список функций также входит получение разного рода информации о банке, справочной экономической информации, персонализированной информации по клиентам — это может быть выписка по кредитному счету, график погаше-ния кредита и собственно функция погашения — считаю что данный функционал просто не-обходим всесторонне активным клиентам. Считаю необходимым и достаточным проводить платежи в реальном временив интернет банке, т. е. исходящий платеж обрабатывался сразу же после поступления, а входящий в ту же секунду увеличивал сумму на счете, такой режим работы даѐт клиентам возможность несколько раз обернуть свои средства в течение дня, и у них появился прямой интерес в максимально оперативном обмене информацией с банком. Интернетбанк — это возможность как частному лицу, так и распорядителю счета юридичес-кого лица — директору — главному бухгалтеру контролировать состояние своих счетов прак-тически в любой точке земного шара, где есть возможность подключиться к Интернет. Это виртуальный мобильный офис банка. Пользоваться ЭЦП достаточно просто. Чтобы подписать электронный документ, владельцу ЭЦП необходимо установить носитель закрытого ключа в USB-порт компьютера и щелкнуть мышкой выбранный документ. Все остальное компьютер сделает сам.
Электронный документ — документ, в котором информация представлена в электронно-цифровой форме. Настоящий договор предполагает обмен договорами, соглашениями, кон-трактами, письмами, заявлениями, ходатайствами, актами, анкетами, сообщениями, а рав-но финансовыми и иными документами.
Страница 18 из 47
Электронная цифровая подпись — реквизит электронного документа, предназначенный для защиты данного электронного документа от подделки, полученный в результате крипто-графического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата открытого ключа, а также установить отсутствие искажения информации в электронном документе. В простой формулировке ЭЦП — это аналог собственноручной подписи, проставленной ручкой на бумаге, но для электронных документов. Единственная разница в том, что элек-тронную цифровую подпись невозможно существующими техническими средствами подде-лать, ее подлинность всегда можно проверить и документ, подписанный ЭЦП, с помощью электронной почты попадает к адресату через считанные секунды, имея при этом такую же юридическую силу, что и документ на бумажном носителе. Владелец сертификата открытого ключа — физическое лицо, на имя которого удостове-ряющим центром выдан сертификат открытого ключа и которое владеет соответствующим закрытым ключом электронной цифровой подписи, позволяющим с помощью средств элек-тронной цифровой подписи создавать свою электронную цифровую подпись в электронных документах (подписывать электронные документы). Средства электронной цифровой подписи — аппаратные и (или) программные средства, обеспечивающие реализацию хотя бы одной из следующих функций — создание электрон-ной цифровой подписи в электронном документе с использованием закрытого ключа элек-тронной цифровой подписи, подтверждение с использованием открытого ключа электрон-ной цифровой подписи подлинности электронной цифровой подписи в электронном доку-менте, создание закрытых и открытых ключей электронных цифровых подписей. Закрытый ключ электронной цифровой подписи — уникальная последовательность сим-волов, известная только владельцу сертификата открытого ключа и предназначенная для создания в электронных документах электронной цифровой подписи с использованием средств электронной цифровой подписи. Открытый ключ электронной цифровой подписи — уникальная последовательность сим-волов, соответствующая закрытому ключу электронной цифровой подписи, доступная лю-бому пользователю информационной системы и предназначенная для подтверждения с ис-пользованием средств электронной цифровой подписи подлинности электронной цифровой подписи в электронном документе. Сертификат открытого ключа (подписи) — документ на бумажном носителе или электрон-ный документ с электронной цифровой подписью уполномоченного лица удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой подписи и которые выдаются удостоверяющим центром участнику обмена ЭД для подтверждения подл