Вы, наверное, используете сильные и уникальные пароли для предотвращения взлома ваших интернет-аккаунтов, но достаточно ли этого? Может быть, да, но с достаточной долей уверенности, можно утверждать что Google и Facebook аккаунты могут быть взломаны, несмотря на очень сложные пароли, которые не могут быть легко угаданы.

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

Контрольный список по безопасности для онлайн-аккаунтов

1. Включайте опцию «Всегда использовать HTTPS» в настройках для Facebook, Twitter, Gmail, Google и всех других онлайн-сервисов, которые поддерживают безопасное HTTP. Это особенно важно при доступе к Интернету через Wi-Fi сети, потому что без HTTPS, любой (а не только квалифицированный хакер) может захватить ваши данные для входа используя Firesheep , простое расширение Firefox.
2. Если у вас есть один или несколько аккаунтов Google, используйте 2-х этапную аутентификацию. Это означает, что если кто-то пытается войти в ваш аккаунт Google с другого компьютера, им придется ввести дополнительный код, который поступает непосредственно на мобильный телефон в виде текстового сообщения SMS или через голосовой вызов.
3. Двухэтапная аутентификация может также предупредить Вас о возможной хакерской активности. Если вы когда-либо получите SMS (или голосовой вызов) от Google с проверкой кода, без вашего запроса, то это является непосредственным свидетельством того, что кто-то знает ваш пароль, хотя он и не в состоянии получить доступ без ввода кода подтверждения.
4. Подключите свой номер мобильного телефона к учетной записи Facebook. Это чрезвычайно важно, потому что в этом случае, вы будете получать SMS и мгновенные оповещения по электронной почте всякий раз, когда в Facebook аккаунт, будет совершена попытка доступа с другого компьютера или другого мобильного телефона.
5. Внимательно изучите сторонние сайты, которые имеют доступ к вашим онлайн-аккаунтам и закройте доступ для всех нежелательных приложений, которые больше не используются. Это необходимо сделать для ваших учетных записей на Facebook, Google и Twitter.
6. Используйте два адреса — один общественный, который отображается в блогах и форумах, а другой адрес электронной почты, сообщайте только доверенным пользователям. Почему? Публичный адрес электронной почты, связанный с такими сервисами как Twitter, YouTube, Facebook, Foursquare, LinkedIn, Flickr, Tumblr, Posterous, Skype и другими социальными сайтами, используйте, чтобы люди могли найти и связаться с вами, если у них есть ваш адрес электронной почты в их адресной книге. Помимо этого, используйте другой «секретный» адрес электронной почты, для сервисов типа Dropbox, Amazon, Google Apps, ваш банковкий аккаунт, хостинг, Apple ITunes, PayPal и других мест, где важность безопасности становится еще более критической. Не используйте этот адрес для связи с людьми.
7. Если вы тестируете новый онлайн-сервис, используйте одноразовые адреса электронной почты для создания тестовой учетной записи в этой службе. Правда, некоторые онлайн-сервисы не принимают одноразовые адреса для предотвращения поддельных регистраций.
8. Предпочтительно использовать виртуальную кредитную карту для торговых операций, особенно на сайтах, где вы совершаете покупку в первый раз или там где много текста написано мелким шрифтом, или есть риск того, что счет будет выставлен снова, если я не аннулировать аккаунт. Это также поможет сохранить кредитную карту в безопасности при работе с относительно неизвестными сайтами.
9. Время от времени, тестируйте самые важные онлайн-сервисы для проверки различных вариантов восстановления пароля. В случае, если вы, действительно забудете пароль или потеряете доступ к дополнительному адресу электронной почты или номеру своего мобильного телефона- это окажется весьма полезным.

Как помнить и управлять множеством различных паролей?

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

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

На основе перечисленных выше симметричных и асимметричных криптоалгоритмов строятся различные протоколы защиты информации в Интернете.

Самый известный протокол Интернета — SSL (Secure Socket Layer). Этот протокол был разработан компанией Netscape и является составной частью всех известных Интернет-браузеров и Web-серверов (сегодня используется версия 3.0 протокола SSL). Протокол реализуется между транспортным и сеансовым уровнями Эталонной модели взаимодействия открытых систем (ЭМВОС). Это, с одной стороны, означает возможность использования протокола для организации защищенной сессии между программами, работающими по различным протоколам прикладного уровня ЭМВОС (FTP, SMTP, Telnet, HTTP и т. п.), а с другой — закрытие любых данных, передаваемых в SSL-сессии, что приводит к снижению производительности протокола.

Последняя версия протокола SSL поддерживает три режима аутентификации:

• взаимную аутентификацию сторон;
• одностороннюю аутентификацию сервера (без аутентификации клиента);
• полную анонимность.

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

1. КЛИЕНТ посылает СЕРВЕРУ запрос (Client hello) на установление защищенного соединения, в котором передает некоторые формальные параметры этого соединения:

• текущее время и дату;
• случайную последовательность (RAND_CL) длиной 28 байтов;
• набор поддерживаемых клиентом симметричных криптографических алгоритмов (например, RC4_128, RC440, RC2128, RC2_40, DES40, DES56 и других) и хэш-алгоритмов (MD5, SHA-1), используемых при формировании кода для проверки целостности передаваемого сообщения (MAC — Message Authentication Code);
• набор поддерживаемых алгоритмов сжатия (все реализации протокола SSL должны поддерживать-метод CompressionMethod.null) и других.

Следует отметить, что КЛИЕНТ имеет возможность в запросе указать идентификатор SSL-сессии, которая была установлена ранее или поддерживается в настоящий момент времени. В этом случае процедура согласования параметров для устанавливаемой сессии не требуется (используются параметры, согласованные для сессии с указанным в запросе идентификатором SSL-сессии).

Кроме того, полезно отметить, что инициировать SSL-сессию может и Web-CEPBEP. Для этого СЕРВЕР может в любой момент времени направить КЛИЕНТУ сообщение Hello request, которое информирует КЛИЕНТА о том, чтобы он направил СЕРВЕРУ сообщение Client Hello.

2. СЕРВЕР обрабатывает запрос от КЛИЕНТА и в ответном сообщении (Server hello) передает ему следующий согласованный набор параметров:

• идентификатор SSL-сессии;
• конкретные криптографические алгоритмы из числа предложенных клиентом (если по какой-либо причине предложенные алгоритмы или их параметры не удовлетворяют требованиям сервера, сессия закрывается);
• сертификат сервера, заверенный цифровой подписью ЦС (в формате Х.509 v.3);
• случайную последовательность (RAND_SERV);
• цифровую подпись для перечисленных выше данных.

3. КЛИЕНТ проверяет полученный сертификат СЕРВЕРА с помощью открытого ключа ЦС, который ему известен; при положительном результате проверки КЛИЕНТ выполняет следующие действия (при отрицательном результате проверки сессия закрывается):

• генерирует случайную 48-байтную последовательность Pre_MasterSecret (часть совместного секрета, известного только СЕРВЕРУ и КЛИЕНТУ); шифрует ее на открытом ключе сервера, полученном в сертификате сервера, и посылает СЕРВЕРУ;
• с помощью согласованных хэш-алгоритмов формирует главный совместный секрет (MasterSecret), используя в качестве параметров часть совместного секрета Pre_MasterSecret, посланную СЕРВЕРУ на предыдущем шаге случайную последовательность RANDCL и полученную от него случайную последовательность RAND_SERV;
• используя MasterSecret, вычисляет криптографические параметры SSL-сессиии: формирует общие с сервером сеансовые секретные ключи симметричного алгоритма шифрования (для приема и для передачи) и секреты для вычисления MAC;
• переходит в режим защищенного взаимодействия.

4. СЕРВЕР расшифровывает полученный Pre_MasterSecret с помощью своего секретного ключа и выполняет над ним те же операции, что и КЛИЕНТ:

• с помощью согласованных хэш-алгоритмов формирует главный совместный секрет (MasterSecret), используя в качестве параметров PreMasterSecret посланную КЛИЕНТУ на предыдущем шаге случайную последовательность RANDSERV и полученную от него случайную последовательность RANDCL;
• используя MasterSecret, вычисляет криптографические параметры SSL-сессиии: формирует общие с клиентом сеансовые секретные ключи одноключевого алгоритма шифрования и секрет для вычисления MAC;
• переходит в режим защищенного взаимодействия.

5. Поскольку при формировании параметров SSL-сессии КЛИЕНТ и СЕРВЕР пользовались одними и теми же исходными данными (согласованными алгоритмами, общим секретом Pre_MasterSecret и случайными последовательностями RAND_CL и RAND_SERV), то очевидно, что в результате описанных выше действий они выработали одинаковые сеансовые секретные ключи шифрования и секреты, используемые для защиты целостности передаваемых сообщений. Для проверки идентичности параметров SSL-сессии КЛИЕНТ и СЕРВЕР посылают друг другу тестовые сообщения, содержание которых известно каждой из сторон:

• КЛИЕНТ формирует сообщение из собственных посылок в адрес СЕРВЕРА на этапе 1 (а) и посылок, полученных от СЕРВЕРА на этапе 1 (б), внося элемент случайности в виде последовательности MasterSecret, уникальной для данной сессии; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и отправляет СЕРВЕРУ;
• СЕРВЕР, в свою очередь, формирует сообщение из собственных посылок в адрес СЕРВЕРА на этапе 1 (б), посылок, полученных от КЛИЕНТА на этапе 1 (а), и последовательности MasterSecret; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и отправляет КЛИЕНТУ;
• в случае успешной расшифровки и проверки целостности каждой из сторон полученных тестовых сообщений SSL-сессия считается установленной, и стороны переходят в штатный режим защищенного взаимодействия.

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

Описанная процедура установления SSL-сессии, безусловно, не обладает полнотой изложения, однако дает представление о возможностях протокола SSL.

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

Для защиты трафика в Интернете помимо протокола SSL используется протокол S-HTTP (Secure HTTP). Этот протокол обеспечивает целостность и защиту документов, передаваемых по протоколу HTTP. В отличие от протокола SSL, расположенного между транспортным уровнем (TCP) и протоколами сеансового уровня, протокол S-HTTP находится на прикладном уровне ЭМВОС, что позволяет с его помощью защищать не транспортное соединение, а данные, передаваемые по соединению. Это повышает производительность протокола защиты информации, но ценой ограничения применимости механизма защиты только приложением HTTP.

Протокол РСТ (Private Communication Technology) обеспечивает защиту для клиент-серверных приложений. Функционально РСТ похож на SSL Так же как в SSL, при установлении сеанса связи РСТ согласует секретный ключ и симметричный алгоритм шифрования. Основное отличие от SSL в том, что РСТ отделяет аутентификацию от шифрования. Кроме того, РСТ более эффективен, поскольку использует меньшее множество сообщений и они более короткие по сравнению с SSL. РСТ поддерживает алгоритмы RSA, Diffie-Hellman, Fortezza для управления ключами; DES, RC2 и RC4 — для шифрования данных; DSA и RSA — для цифровой подписи.

РСТ реализован в Microsoft Internet Explorer версии 3 и выше, а также в Microsoft Internet Information Server версии 2 и выше.

В Интернете применяются и другие протоколы защиты информации: S/MIME — для защиты электронной почты, S/WAN — для защиты соединений (как правило, между маршрутизаторами), PGP — для защиты электронной почты, Secure Shell — для защиты сеансов telnet и передачи файлов. На этих протоколах ввиду их специального назначения,
не связанного с ЭК, мы останавливаться не будем.

Упомянем лишь протокол IPSec, предназначенный для шифрования данных на сетевом уровне (данный протокол в отличие от всех перечисленных ранее является независимым не только от приложения, но и от транспортного уровня, что, в частности, позволяет применять его для защиты данных приложений, использующих в качестве транспортного протокола UDP). IPSec состоит из трех протоколов: Authentication Header, Encapsulating Secure Payload (ESP) и Internet Key Exchange (IKE). Первый протокол обеспечивает аутентификацию источника данных, их целостность и защиту от навязывания повторных сообщений. С помощью протокола АН аутентифицируется каждый пакет, что делает программы, пытающиеся перехватить управление сеансом, неэффективными.

Протокол ESP обеспечивает шифрование потоков данных. Протокол IKE решает задачу распределения ключей на базе протокола Diffie-Hellman. В используемых протоколах в качестве алгоритма шифрования чаще всего используются DES или Triple DES, а в качестве алгоритма ЭЦП — RSA. Однако ничто не запрещает использовать в качестве алгоритма шифрования другие методы, краткий обзор которых приведен далее. В этом случае ПО отдельных компонентов ЭК должно поддерживать набор соответствующих алгоритмов шифрования.

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

Вторая конфигурация — закрытие данных внутри самой локальной сети, для чего все рабочие места и сервера сети обязаны поддерживать протокол IPSec. Сегодня большинство современных операционных систем (Windows 2000, OpenBSD, Linux, Solaris) поддерживают протокол IPSec.

Обзор методов защиты данных в Интернете не будет полным, если в нем не упомянуть о технологии межсетевых экранов (Firewall), широко используемой для защиты информации в Интернете. В ЭК межсетевые экраны, в частности, широко применяются для защиты от хакеров таких компонентов электронной коммерции, как Internet Payment Gateway, Server Based Wallet, Payment Server. Подробнее об этих компонентах будет рассказано в главе, посвященной решениям на базе протокола SET.

В основном межсетевые экраны можно разделить на три категории:

• пакетные фильтры (фильтры без памяти);
• фильтры сеансового уровня;
• фильтры прикладного уровня.

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

Другой пример успешного прохождения через пакетный фильтр — address spoofing (имитация адресов). Хакер может использовать в качестве адреса отправителя адрес авторизованного клиента, и тогда пакетный фильтр пропустит пакет хакера.

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

Фильтр сеансового уровня следит за подтверждением связи (квитированием) между авторизованным клиентом и внешним хостом, определяя, является ли запрашиваемый сеанс связи допустимым. Чтобы определить, является ли запрос на сеанс связи допустимым, шлюз сеансового уровня выполняет примерно следующую процедуру. Когда авторизованный клиент запрашивает некоторую услугу, шлюз принимает этот запрос, проверяя, удовлетворяет ли данный клиент базовым критериям фильтрации (например, может ли DNS-сервер определить IP-адрес клиента и ассоциированное с ним имя). Затем, действуя от имени клиента, шлюз устанавливает соединение с внешним хостом и следит за процедурой квитирования связи по протоколу TCP. Эта процедура состоит из обмена TCP-пакетами, которые помечаются флагами SYN (синхронизировать) и АСК (подтвердить).

Первый пакет сеанса TCP, помеченный флагом SYN и содержащий произвольное число, например 1000, является запросом клиента на открытие сеанса. Внешний хост, получивший этот пакет, посылает в ответ пакет, помеченный флагом АСК и содержащий число, на единицу большее, чем в принятом пакете (в нашем случае 1001), подтверждая таким образом прием пакета SYN от клиента. После этого осуществляется обратная процедура: хост посылает клиенту пакет SYN с исходным числом (например, 2000), а клиент подтверждает его получение передачей пакета АСК, содержащего число 2001. На этом процесс квитирования связи завершается.

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

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

Для копирования и перенаправления пакетов в шлюзах сеансового уровня используются специальные приложения, которые иногда называют канальными посредниками (pipe-proxy). Большинство шлюзов сеансового уровня не являются самостоятельными продуктами и поставляются в комплекте со шлюзами прикладного уровня. Примерами таких шлюзов являются Gauntlet Internet Firewall компании Trusted Information Systems, AltaVista Firewall компании DEC и ANS Interlock компании ANS.

Шлюз сеансового уровня выполняет еще одну важную функцию защиты — трансляцию адресов (Network Address Translation), при которой производится преобразование внутренних IP-адресов в один «надежный» IP-адрес. Этот адрес ассоциируется с фильтром, из которого передаются все исходящие пакеты. В результате в сети со шлюзом сеансового уровня все исходящие пакеты оказываются отправленными из этого шлюза, что исключает прямой контакт между внутренней авторизованной сетью и внешней сетью, а также скрывает от внешних пользователей архитектуру внутренней защищаемой сети. Таким образом, фильтры сеансового уровня защищают внутренние сети от нападений типа address spoofing (имитация адресов).

Наиболее известным стандартом для реализации шлюза сеансового уровня является протокол SOCKS. Версия 5 этого протокола включает в себя процедуры аутентификации взаимодействующих сторон, а также контроль организации сессии в протоколе UDP. Протокол SOCKS 5 поддерживается большинством имеющихся на рынке браузеров, а также поддерживается различными операционными системами, включая Unix, Windows, Mackintosh и другие.

Фильтры прикладного уровня обеспечивают высокую степень защиты, но за счет снижения производительности и увеличения сложности. Такие фильтры реализуются как выделенные межсетевые экраны. Сам сервер приложения находится в частной сети за межсетевым экраном. Внешние клиенты подключаются к последнему, который ведет себя как сервер приложения. Фактически, клиент не может обнаружить, что взаимодействует с межсетевым экраном, который в этом случае называется прикладным прокси-сервером (proxy application server).

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

В отличие от фильтра сеансового уровня, посредники прикладного уровня пропускают только пакеты, которые им поручено обслуживать. Например, программа-посредник службы Telnet может копировать, перенаправлять и фильтровать лишь трафик, генерируемый этой службой. Если шлюз прикладного уровня использует только программы-посредники служб FTP и Telnet, то он будет пропускать пакеты этих служб, блокируя при этом пакеты всех остальных служб.

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

Такие продукты, как Eagle компании Raptor Systems, ANS Interlock компании ANS, Sidewinder Security Server компании Secure Computing Corporation, Firewall-1 компании Checkpoint, включают в себя программы-посредники прикладного уровня для служб FTP, Telnet, HTTP. Утилиты этих шлюзов позволяют фильтровать определенные команды, используемые этими службами. Например, можно сконфигурировать шлюз таким образом, чтобы он предотвращал использование клиентами команды FTP Put, которая дает возможность пользователю, подключенному к FTP-серверу, записывать на него информацию.

В дополнение к фильтрации многие фильтры прикладного уровня регистрируют все выполняемые сервером действия и, что особенно важно, предупреждают администраторов о возможных нарушениях защиты (Intrusion Detection System). Например, при попытках проникновения в систему извне BorderWare Firewall Server компании Secure Computing позволяет фиксировать адреса отправителя и получателя пакетов, время, в которое эти попытки были предприняты, и используемый протокол. Продукт Black Hole компании Milkyway Networks также фиксирует все попытки проникновения в систему и предупреждает о них администратора, посылая ему сообщения по электронной почте или на пейджер.

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

• Конституции РФ,
• Гражданском Кодексе РФ,
• Федеральных законах РФ «Об информации, информатизации и защите информации», «О государственной тайне».

Федеральный закон «Об информации, информатизации и защите информации» принят Государственной Думой 25 января 1995 г., подписан Президентом РФ 20 февраля 1995 г. и с тех пор остается единственным на сегодняшний день Федеральным законом, трактующим общие вопросы регулирования отношений в области защиты информации. В сферу его действия включена защита информации, прав субъектов, участвующих в информационных процессах и информатизации (ст. 1, разд. 1).

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

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

В статье 21 «Защита информации» говорится следующее: «Режим защиты информации устанавливается: в отношении сведений, отнесенных к государственной тайне, — уполномоченными органами на основании Закона РФ «О государственной тайне» в отношении конфиденциальной документированной информации — собственником информационных ресурсов или уполномоченным лицом на основании настоящего Федерального закона».

3 апреля 1995 г. Президентом РФ был подписан указ № 334 «О мерах по соблюдению законности в области разработки, производства, реализации и эксплуатации шифровальных средств, а также предоставления услуг в области шифрования информации».

Указ носит жесткий характер, монополизирующий контролирующие функции в области разработки, производства, внедрения и эксплуатации криптографических средств за ФАПСИ. В нем, в частности, говорится:

«Запретить использованиегосударственными организациями… шифровальных средств, включая криптографические средства обеспечения подлинности информации (электронная подпись), и защищенных технических средств хранения, обработки и передачи информации, не имеющих сертификата ФАПСИ…»

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

«В интересах информационной безопасности РФ и усиления борьбы с организованной преступностью запретить деятельность юридических и физических лиц, связанную с разработкой, производством, реализацией и эксплуатацией шифровальных средств, а также защищенных технических средств хранения, обработки и передачи информации, предоставлением услуг в области шифрования информации, без лицензий, выданных ФАПСИ в соответствии с Законом РФ «О ФАПСИ».

Ситуация несколько либерализовалось весной 1998 г., когда появились новые положения Банка России о работе с электронными документами. Положение «О порядке приема к исполнению поручений владельцев счетов, подписанных аналогами собственноручной подписи, при проведении безналичных расчетов кредитными организациями» Ы17-П (далее — Положение 17-П) наконец-то делает полностью законной в рамках банковской системы России широко распространенную практику проведения коммерческими банками расчетов без обязательного предоставления клиентами платежных поручений на бумажных носителях.

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

Положение 17-П, принятое Банком России 10 февраля 1998 г., введено им в действие с момента официального опубликования 18 февраля 1998 г. в «Вестнике Банка России». В качестве его законодательной основы был взят новый Гражданский кодекс Российской Федерации, а именно ст. 160 (п. 1.1 Положения 17-П), которая трактует все возможные легальные способы оформления сделок в Российской Федерации.

Так, Гражданский кодекс РФ допускает «использование при совершении сделок… электронно-цифровой подписи либо иного аналога собственноручной подписи… в случаях и порядке, предусмотренных законом, иными правовыми актами или соглашением сторон».

В Положении 17-П основной упор делается именно на соглашение сторон, зафиксированное в виде договора, как основу их работы с электронными документами. Например, п. 1.7 гласит: «Участники документооборота устанавливают процедуру признания АСП и используют ее в порядке и на условиях, предусмотренных договором между участниками или с Администрацией».

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

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

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

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

Его роль в работе системы электронного документооборота и взаимоотношения с другими участниками определяются отдельным договором (п. 3.2).

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

Развернутое определение такого варианта АСП, как ЭЦП, дано в Положении 20-П, принятом ЦБ РФ 12 марта 1998 г. В нем ЭЦП определяется как «вид АСП, являющийся средством защиты информации и обеспечивающий возможность контроля целостности и подтверждения подлинности электронных документов. ЭЦП позволяет подтвердить ее принадлежность зарегистрированному владельцу».

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

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

Так, констатируется, что юридическая основа работы — договор между сторонами: «Для создания и проверки АСП могут использоваться программно-технические и иные средства в порядке, устанавливаемом договором между участниками документооборота или с Администрацией» (п. 2.2 Положения 17-П). Далее в нем указывается, что «платежные документы, подписанные АСП, признаются имеющими равную юридическую силу с другими формами поручений владельцев счетов, подписанных ими собственноручно» (п. 2.3). А п. 2.3 Положения 20-П констатирует, что «ответственность за содержание реквизитов электронного документа несет владелец ЭЦП, подписавший данный электронный документ, если иное не предусмотрено договором». Тем самым, эти положения официально подтверждают, что ЦБ признает правильным обязательный пункт договора между сторонами, согласно которому сторона, чей аналог подписи под электронным документом признается правильным по установленной договором сторон процедуре, принимает на себя все обязательства, вытекающие из такого документа, как это принято в бумажном документообороте.

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

Эти положения не требуют от участников придерживаться какой-то определенной процедуры подписывания и проверки электронных документов. Таким образом, полностью на усмотрение участников документооборота оставляется выбор конкретных методов и средств выполнения АСП и ее проверки. Для соблюдения требований ЦБ РФ достаточно, чтобы стороны согласовали заранее все детали процедуры выполнения АСП и проверки ее подлинности, а также официально в рамках подписываемого ими договора о работе с электронными документами подтвердили свое согласие принимать на себя все обязательства, вытекающие из тех электронных документов, которые признаются, согласно установленной процедуре проверки, подписанными.

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

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

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

Такой механизм существует в мировой практике — это технология ЭЦП с сертификатами. Она специфицирована Международным телекоммуникационным союзом в его рекомендации Х.509 и нашла свое развитие в различных приложениях, включая системы электронной коммерции, системы обработки микропроцессорных карт и т. п. Суть технологии cot гоит в том, что некоторая организация, называемая сертификационным или регистрационным центром, заверяет своей подписью образцы всех обратившихся к ней лиц. Именно для того, чтобы придать технологии ЭЦП с сертификатами юридическую силу, и необходим «Закон об электронно-цифровой подписи».

Общее мнение специалистов о «Законе об электронно-цифровой подписи» состоит в следующем. Обязательность лицензирования и получения государственных сертификатов на средства ЭЦП и деятельность регистрационных центров не должны являться категорическим императивом. В случае же введения системы лицензирования и сертификации она должна быть прозрачной и носить заявительный, а не разрешительный характер. Кроме того, необходимы альтернативные предлагаемой ФАПСИ системы сертификации, например, под эгидой Государственной технической комиссии при Президенте РФ и Госстандарта.

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