Правовые аспекты систем удаленного обслуживания клиентов

Поскольку до начала «эпохи» удаленного электронного взаимодействия представители организации клиента и представители банка общались лично, способами, имеющими историю десятков, а...

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

Искандер Конеев

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

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

Естественно, одна из первых проблем, возникающих при удаленном общении, когда субъекты не видят друг друга в лицо, — это безопасность. На ней мы и остановимся.

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

Рассмотрим подробнее ключевые положения примерного договора такого типа.

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

1. Системы off-line (синонимы — почтовая система, толстый клиент). Они достаточно распространены сейчас. Более того, на постсоветской территории, где технологии удаленного обслуживания еще только набирают обороты, а линии связи оставляют желать лучшего, такие системы, видимо, составляют абсолютное большинство. Работа системы заключается в том, что на стороне клиента находится программное обеспечение и данные, необходимые для того, чтобы независимо от банка сформировать запрос в банк. На данном этапе не требуется связи с банком, связь нужна только при отправке готового запроса. Запрос (электронный документ) чаще всего представляет собой электронный файл. На стороне банка производится обработка запроса, также не требующая постоянного соединения с клиентом.
2. Системы on-line (синонимы — Web- или Internet-система, тонкий клиент). Данный тип гораздо менее распространен у нас, но за ним, несомненно, будущее (по крайней мере, учитывая тенденции развития подобных систем на Западе). Он требует постоянной связи клиента с сервером банка по той причине, что на стороне клиента нет никакого программного обеспечения и данных — только стандартный браузер (или другое средство просмотра данных на сервере банка). Запрос формируется клиентом в текущем сеансе связи и чаще всего представляет из себя запись в базе данных на сервере. Его обработка банком может происходить прямо «на глазах» у клиента в том же сеансе связи.

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

На мой взгляд, первое, что необходимо сделать, чтобы убедиться, что обе стороны говорят на одном языке, это ввести определения основных понятий, на которых базируется безопасность системы. Ряд понятий, таких как электронный документ, пароль, шифрование, электронно-цифровая подпись (ЭЦП), кажутся интуитивно понятными, но могут вызвать разногласия в дальнейшем, например при разрешении конфликтных ситуаций. А то, что принцип работы ЭЦП основан на работе с открытым и секретным (публичным и приватным) ключами, вообще может быть для клиента откровением, но без этого он не поймет, почему «половину ЭЦП он должен держать в секрете, а половину раскрыть банку».

Вот примеры таких определений.

Электронный документ — запись в базе данных Банка, оформленная соответствующим образом, содержащая платежное поручение, запрос или информационное сообщение Клиента.

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

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

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

Открытый ключ ЭЦП Клиента — ключ (последовательность бит), связанный с секретным ключом Клиента (но не позволяющий вычислить сам секретный ключ), генерируемый Клиентом и предназначенный для проверки ЭЦП электронного документа, сформированного Клиентом. Открытый ключ, соответствующий текущему секретному ключу Клиента, должен в обязательном порядке находиться в распоряжении Банка для проверки ЭЦП каждого электронным образом подписанного документа Клиента.

Идентификатор пользователя — открытая последовательность символов, представляющая имя конкретного пользователя Клиента, позволяющая Системе однозначно установить соответствие между данным пользователем и его правами в Системе.

Пароль пользователя — секретная последовательность символов, связанная с идентификатором пользователя и известная только данному пользователю, позволяющая подтвердить соответствие физической личности пользователя предъявляемому им Системе идентификатору и получить доступ к профилю пользователя (почтовому ящику пользователя).

Шифрование — обеспечение защиты данных при передаче их между Клиентом и Банком по линиям связи на основе приведения содержательной информации в нечитабельное состояние. Восстановление информации в содержательное состояние (дешифрование) производится только на основе знания ключа шифрования.

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

Определение Пользователя Клиента существенно для крупного корпоративного клиента, у которого формированием и авторизацией запросов в банк занимаются разные сотрудники.

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

• Получение доступа к ресурсам клиента возможно только в рамках установленных прав при предъявлении пользователем Системе идентификатора и пароля. Таким образом, обладание идентификатором и паролем однозначно определяет пользователя как представителя Клиента, уполномоченного производить соответствующие работы в Системе.
• Информация не может быть разглашена или изменена третьими лицами при пересылке от Клиента в Банк и обратно по линиям связи. Таким образом, изменение или разглашение информации может быть произведено только пользователями Системы — сотрудниками Клиента или Банка.
• Создание корректной ЭЦП Клиента возможно только при наличии секретного ключа Клиента. Таким образом, обладание секретным ключом однозначно определяет пользователя как представителя клиента, уполномоченного подтверждать корректность электронного документа от имени Клиента.

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

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

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

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

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

На мой взгляд, в договоре достаточно предупредить клиента, что в случае несоблюдения им РЕКОМЕНДАЦИЙ банка по безопасности он может понести серьезный ущерб.

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

Дополнительной важной статьей, вносимой в договор, является согласование таймера, то есть времени, которое будет вноситься системой в регистрационные журналы и поля записей документов. Обычно за единое принимается время на сервере банка. Кроме того, клиент и банк должны дистанцироваться от ответственности за использование противоположной стороной нелицензионного программного обеспечения (операционной системы, СУБД и пр.).

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

Вот примеры таких статей.

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

Необходимо также определить ответственность (или снять ее) за разнообразные аварийные случаи: не работают линии связи, нет света и пр.

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

Здесь необходимо решать конкретно для каждого типа системы — либо умножать количество технических приложений к договору, либо делать ссылки на инструкцию по работе с системой.

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

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

Во-вторых, следует понимать, что обычно печать и подпись на распечатке ставят для подтверждения СМЫСЛА информации, отраженной на бумаге, вне зависимости от того, каким шрифтом и в каком формате распечатана информация. В случае же с открытым ключом важен не смысл, а сама последовательность символов (если быть точнее — бит, которые она отражает). Учитывая, что буквы, ряд букв и символов имеют одинаковое отображение при разных битовых последовательностях и наоборот (например, русское р и английское р, знак номера № или #), два одинаково выглядящих на бумаге открытых ключа могут представлять из себя различные битовые последовательности.

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

В качестве конструктивной альтернативы могу предложить рассмотреть различные варианты инфраструктуры управления открытыми ключами (Public Key Infrastruc-ture — PKI), документы по которой во множестве представлены в Internet.

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

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

Комиссия должна произвести анализ сложившейся ситуации по следующим этапам.

1. Действительно ли документ был некорректно проведен (или не проведен) по балансу банка? Если фактически документ был проведен правильно, то есть в соответствии с ожиданиями клиента (на самом деле клиент просто неверно интерпретировал прохождение документа), претензия может быть снята. Если же клиент был дезинформирован по факту прохождения документа, может быть проведено дополнительное расследование.
2. Если обнаружено отражение некорректной операции в балансе, необходимо найти в системе электронный документ (или бумажную копию с печатями и подписями клиента), на основании которого была проведена некорректная операция. Если банк не может представить такой документ, вина за некорректную операцию ложится на банк.
3. Если электронный документ представлен (все реквизиты этого документа соответствуют операции, отраженной в балансе), комиссия должна произвести его экспертизу.

Возможные варианты экспертизы могут быть следующими.

1. Документ не содержит ЭЦП вообще. Вина ложится полностью на банк, ведь согласно договору, банк не имел права использовать документ без ЭЦП в качестве основания для операции.
2. ЭЦП имеется на документе, но Банк не может предъявить открытый ключ клиента, на основании которого он определил корректность ЭЦП. Вина ложится полностью на банк, банк не имел права использовать в качестве основания для операции документ с ЭЦП, не проверенной на корректность.
3. Банк предъявляет и документ с ЭЦП, и открытый ключ, но верификация данной ЭЦП данным ключом происходит с ошибкой (или не происходит — в зависимости от реализации системы). Вина ложится полностью на банк, по той же причине, что и в предыдущем пункте.

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

Однако во всех вышеописанных случаях клиент может продолжать настаивать на своей правоте, выдвигая следующие аргументы:

• предъявленный открытый ключ не принадлежит клиенту;
• хотя ЭЦП и была верифицирована, сама процедура проверки ЭЦП произведена некорректно.

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

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

Основная задача в таком случае — показать клиенту, что банк не просто голословно утверждает «банк всегда прав», а предоставляет доказательства, которые могут быть оценены самим клиентом или, по его выбору, экспертами третьей стороны.

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