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