Защита от внешних атак

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

Так как клиент (Интернет-браузер) и клиентский BS-Defender могут функционировать физически раздельно (на разных компьютерах), в настройках BS-Defender’а предусмотрено ограничение доступа к нему ("Только с этого компьютера" — по умолчанию,

"Только допустимым узлам из списка" либо "Без ограничений"). Через один

BS-Defender возможна одновременная работа с несколькими банками или с одним банком, но под разными логинами (требует дополнительной настройки).

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

6.2.2. Аутентификация при работе с двусторонним

SSL / TLS

Для определения конкретного клиента, сервер приложений RTS, который обслуживает под-

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

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

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

6.2.3. Аутентификация при работе с односторонним SSL (парольная и криптографическая)

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

Таким образом, к WEB-серверу сможет подключиться любой пользователь, даже не обладающим правом работы с подсистемой Интернет-Клиент. Для обеспечения правомочности входа в АРМ клиента подсистемы Интернет-Клиент в обязательном порядке выполняется аутентификация с использованием пароля. Как опциональный способ аутентификации, может быть включен режим аутентификации по ключам СКЗИ («криптографической аутентификации»).

21

Защита от внешних атак

При обращении к SSL-сайту у клиента в статусной строке окна Internet Explorer появляется

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

6.2.3.1. Парольная аутентификация

Для входа в подсистему Интернет-Клиент используется пара «логин—пароль».

Назначение логина и пароля происходит в момент генерации дистрибутива АРМ клиента подсистемы Интернет-Клиент. При генерации, пароль присутствует только на бумажном носителе (распечатывается на указанном принтере, может быть применен специальный принтер, пропечатывающий значение пароля внутри закрытого конверта), в базе данных банка хранится только результат ХЕШ-функции от пароля. Таким образом, достигается секретность назначаемого пароля — все операции с паролем осуществляются только между получаемыми результатами ХЕШ-функций и сохраненными значениями ХЕШ-функций.

Логин – он же идентификатор клиента, на основе которого открывается сессия на RTS-сер- вере.

При входе в подсистему Интернет-Клиент на требование ввести логин и пароль, клиент должен будет ввести полученные с дистрибутивом значения. Если пароль будет введен трижды неверно (количество настаивается), он считается скомпрометированным, и учетная запись блокируется. Для разблокировки клиенту необходимо обращаться в Отделение Банка, выдавшего дистрибутив подсистемы Интернет-Клиент.

После входа в подсистему Интернет-Клиент, пароль может быть переназначен (изменен) самим пользователем. В этом случае, пароль в БД банка в открытом виде также не сохраняется, а сохраняется результат ХЕШ-функции от нового пароля.

К паролям пользователей могут быть предъявлены дополнительные требования: минимальная длина пароля, срок действия пароля и т.д. Также может быть запрещено использование простых паролей (см. разд. 4.8.1.2.3.4 «Обеспечение проверки идентификационных призна-

ков пользователей» док. Полное руководство пользователя).

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

6.2.3.2. Криптографическая аутентификация

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

22

Защита от внешних атак

Рассмотрим последовательность операций при криптографической аутентификации:

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

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

3.Последовательность передается на клиентскую сторону.

4.Клиент из списка возможных крипто-профилей (подписей) выбирает и подписывает выбранным полученную последовательность.

5.Подпись, без подписанной последовательности передается в банк.

6.На банковской стороне, из сессионного кеша восстанавливается уникальная последовательность.

7.Выполняется проверка полученной подписи под восстановленной последовательностью.

8.Если подпись верна, то производится снятие блокирующего флага и вход в сессию «Ин- тернет-клиента».

9.Если подпись не верна, формируется сообщения об ошибке, и возврат на пп. 4.

6.2.4.Использование сеансовых ключей при работе с подсистемой Интернет-Клиент

Дополнительно к аутентификации пользователей подсистемы "Интернет-Клиент" посредством паролей, возможно использование аутентификации пользователей по сеансовым ключам, сгенерированным в системе "ДБО BS-Client" или с помощью аппаратного устройства eToken PASS (см. разд. 4.8.2.1.1 «Генерация комплектов сеансовых ключей в системе "ДБО BS-Client"» док. Полное руководство пользователя). При использовании данного механизма пользователь получает полноценный доступ к подсистеме только после ввода запрашиваемого системой ключа. В случае если ключ не был введен пользователь получает ограниченный доступ к подсистеме, без возможности выполнения криптографических операций над документами.

6.2.5. Использование сеансовых ключей при работе с подсистемой Телефон-Клиент

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

мый «комплект», состоящий из PIN-кода и комплекта сеансовых ключей (КСК).

Как PIN-код, так и СК представляет собой набор цифр, длина которого находится в пределах от 3-х до 10-ти символов (устанавливается администратором при генерации).

23

Защита от внешних атак

PIN-код является уникальным в рамках системы "ДБО BS-Client".

СК используется для повышения уровня безопасности при доступе к данным через Телефонклиент.

СК может обладать уникальностью либо в рамках отдельного комплекта, либо в рамках системы в целом, либо не обладать уникальностью вообще. СК может быть как одноразовым, так и многоразовым.

Телефон-клиент обладает гибким механизмом настройки политики безопасности:

•ограничение срока действия набора СК;

•возможность однократного или многократного использования СК;

•разрядность PIN-кода и СК;

•различные виды уникальности СК;

•возможность замены как «конверта» в целом, так и его отдельных составляющих (PINкод, СК);

•формирование документов на основе персональных шаблонов.

6.3.Фильтрация запросов пользователей в подсистеме Интернет-Клиент по IP и MAC-

адресам

В качестве дополнительного средства защиты от внешних атак в подсистеме Интернет-Кли- ент может быть использована фильтрация запросов пользователей:

•по внутренним и внешним IP-адресам сетевого интерфейса;

•MAC-адресам сетевых карт, установленных в рабочих станциях пользователей.

Для каждого пользователя подсистемы может быть задан список разрешенных IP и MACадресов с которых может быть выполнено соединение с сайтом подсистемы (см. разд. 4.8.1.2.3.4 «Обеспечение проверки идентификационных признаков пользователей» док. Полное руководство пользователя).

24