ДБО BS-Client

Система "ДБО BS-Client"
Версия 017.8.0 , Распределенная схема
Документация подразделения банка. Комплект администратора
Защита информации в системе
"ДБО BS-Client"
© 2011 ООО "БСС"
Система "ДБО BS-Client"
Версия 017.8.0 , Распределенная схема
Документация подразделения банка. Комплект администратора
Дополнительные материалы
Защита информации в системе "ДБО BS-Client"
Опубликовано 2011
Листов 64
© 2011 ООО "БСС"
Настоящий документ содержит информацию, актуальную на момент его составления. ООО "БСС" не
гарантирует отсутствия ошибок в данном документе. ООО "БСС" оставляет за собой право вносить
изменения в документ без предварительного уведомления.
Никакая часть данного документа не может быть воспроизведена или передана в какой бы то ни было
форме и какими бы то ни было средствами без письменного разрешения ООО "БСС".
ООО "БСС" не гарантирует, что специфицированное в настоящем документе программное обеспечение
не содержит дефектов, будет работать в произвольно выбранных условиях и при этом удовлетворять
всем требованиям, которые могут быть к нему предъявлены.
ООО "БСС" не гарантирует работоспособность нелегально полученного программного обеспечения.
Нелегальное использование программного обеспечения и документации на него преследуется законом.
, продукты и их наименования "Система ДистанНаименование ООО "БСС", товарный знак
ционного Банковского Обслуживания BS-Client" ("ДБО BS-Client") являются интеллектуальной собственностью ООО "БСС" и охраняются действующим законодательством.
Все иные упомянутые в настоящем документе марки, названия продуктов и фирм могут являться интеллектуальной собственностью соответствующих владельцев.
© 2011 ООО "БСС"
Содержание
Введение ............................................................................................................................. 6
Глоссарий ........................................................................................................................... 9
1. Общая структурная схема каналов передачи данных в системе "ДБО BS-Client" .......... 10
2. Защита передаваемых данных внутри банковской сети между компонентами системы
"ДБО BS-Client" ................................................................................................................. 12
3. Защита передаваемых данных в подсистеме «толстый» клиент ДБО (шифрация, подпись, транспорт) ................................................................................................................ 13
3.1. Решаемые задачи ................................................................................................. 13
3.2. Реализация ЭЦП в «Банк-Клиенте» .................................................................... 13
3.3. Организация транспортной подсистемы .............................................................. 13
4. Защита передаваемых данных в подсистеме Интернет-Клиент ...................................... 15
4.1. Защита данных при использовании BS-Defender ................................................. 15
4.2. Защита данных при использовании SSL / TLS .................................................... 16
4.3. Сравнение различных способов защиты канала .................................................. 17
5. Защита передаваемых данных в подсистеме Телефон-Клиент ....................................... 19
6. Защита от внешних атак ................................................................................................. 20
6.1. Фильтрация неподписанных пакетов в ядре транспорта классического клиента ............................................................................................................................... 20
6.2. Аутентификация пользователей в подсистеме Интернет-Клиент ........................ 20
6.2.1. Подпись трафика BS-Defender’a ............................................................... 20
6.2.2. Аутентификация при работе с двусторонним SSL / TLS .......................... 21
6.2.3. Аутентификация при работе с односторонним SSL (парольная и криптографическая) .................................................................................................. 21
6.2.4. Использование сеансовых ключей при работе с подсистемой ИнтернетКлиент ............................................................................................................... 23
6.2.5. Использование сеансовых ключей при работе с подсистемой ТелефонКлиент ............................................................................................................... 23
6.3. Фильтрация запросов пользователей в подсистеме Интернет-Клиент по IP и
MAC-адресам ............................................................................................................ 24
7. Защита от внутренних атак ............................................................................................ 25
7.1. Аутентификация и авторизация внутренних пользователей ................................ 25
7.2. Права пользователей в системе ........................................................................... 26
7.2.1. Общее описание системы прав ................................................................. 26
7.2.2. Система прав доступа к СУБД и серверу ДБО .......................................... 27
7.2.3. Система прав разграничения доступа по документам ............................... 27
7.3. Ограничение доступа к БД через внешние средства ............................................ 28
7.4. Аудит действий пользователей ........................................................................... 30
7.5. Журналирование процессов, происходящих внутри системы ............................. 30
7.5.1. Фиксация смены статусов документов ..................................................... 30
7.5.2. Системные журналы ................................................................................. 31
7.5.3. Журналы макроязыка ............................................................................... 32
8. Обеспечение целостности и аутентичности информации передаваемой от клиентов в
банк и обратно ................................................................................................................... 33
8.1. Использование подписи под документами .......................................................... 33
8.1.1. Общие сведения ....................................................................................... 33
8.1.2. Подпись документов и квитанций ............................................................ 33
8.1.3. Возможность разбора конфликтных ситуаций .......................................... 34
8.2. Использование подписи при передаче транспортного трафика .......................... 34
3
Защита информации в системе "ДБО BS-Client"
8.3. Использование подписи при передаче трафика BS-Defender ............................... 35
8.4. Использование механизмов аутентичности двустороннего SSL (TLS) ................ 35
8.4.1. Общие сведения ....................................................................................... 35
8.4.2. Исходные требования ............................................................................... 35
8.4.3. Технология связи клиента и банка по каналу «Двусторонний SSL /
TLS» .................................................................................................................. 36
8.5. Сеансовые ключи при заведении клиентом документов в подсистеме ТелефонКлиент ....................................................................................................................... 38
8.6. Аутентичность выписок, остатков и другой информации выдаваемой банком в
подсистеме Телефон-Клиент ..................................................................................... 38
9. Работа с криптографическими ключами и сертификатами ............................................. 40
9.1. Описание особенностей СКЗИ ............................................................................ 40
9.2. Основные понятия ............................................................................................... 41
9.2.1. Записи о ключах ....................................................................................... 41
9.2.2. Криптографический профиль (абонент) ................................................... 42
9.2.3. Право подписи для документов системы "ДБО BS-Client" ....................... 42
9.2.4. Право шифрации (связь по транспорту «Банк-Клиент») ........................... 43
9.2.5. Право защиты канала («Интернет-Клиент») ............................................. 43
9.3. Менеджмент ключей. Права на криптографические операции. Привязка к пользователю ................................................................................................................. 43
9.4. Начальное заведение ключей, Технологический ключ ........................................ 44
9.5. Перегенерация клиентского ключа (в толстом и тонком клиенте) ....................... 45
9.5.1. Удаленная перегенерация ключей толстого и тонкого клиента ................ 46
9.6. Перегенерация банковского ключа ..................................................................... 47
9.7. Использование списков отозванных сертификатов. Компрометация ключа ........ 48
9.8. Использование списков отозванных сертификатов (СОС) .................................. 49
9.9. Использование USB-токенов ............................................................................... 49
10. Конфликтные ситуации и способы их решения ............................................................ 50
10.1. Общие положения, типы конфликтных ситуаций .............................................. 50
10.2. Разбор конфликтов в случае «толстого клиента» ............................................... 51
10.3. Разбор конфликтов в «BS-Defender» ................................................................. 51
10.4. Разбор конфликтов в одностороннем и двустороннем SSL (сохраняемые подписи под документами) .............................................................................................. 52
10.5. Разбор конфликтов в Телефон-клиенте ............................................................ 53
11. Соответствие системы "ДБО BS-Client" стандартам ЦБР ............................................. 54
12. Список рекомендуемой литературы ............................................................................. 56
A. Криптографические справочники, используемые в системе "ДБО BS-Client" ............... 57
A.1. Справочник количества подписей в документах (CryptoNumOfSigns) ................ 57
A.2. Справочник сертификатов (CryptoUID) .............................................................. 57
A.3. Справочник криптографических профилей (CryptoProfile) ................................. 57
A.4. Справочник рабочих мест абонентов СКЗИ (CryptoWorkPlace) ......................... 57
A.5. Справочник пользователей абонентов СКЗИ (CryptoLogin) ............................... 57
A.6. Справочник абонентов СКЗИ для пользователей подсистемы Интернет-Клиент (RemoteCryptoProfile) .......................................................................................... 58
A.7. Общие справочники ........................................................................................... 58
A.7.1. Справочник клиентов (PostClnt) .............................................................. 58
A.7.2. Справочник организаций (Customer) ....................................................... 58
A.7.3. Справочник пользователей подсистемы Интернет-Клиент ...................... 58
A.7.4. Справочник организаций пользователей Интернет-Клиент
(RemoteIDS) ....................................................................................................... 58
4
Защита информации в системе "ДБО BS-Client"
B. Пример регламента разбора конфликтных ситуаций в системе "ДБО BS-Client" .......... 59
B.1. 1. Общий порядок разбора конфликтной ситуации ............................................. 59
B.2. 2. Действия по общему анализу конфликтного документа ................................. 60
B.3. 3. Разбор конфликта вида «Отказ любой из сторон от ЭЦП под созданным этой
стороной документом» .............................................................................................. 60
B.4. Разбор конфликта вида «Отказ любой из сторон от сформированной ею квитанции на документ» ................................................................................................. 61
C. Схема компонентов системы "ДБО BS-Client" .............................................................. 64
5
Введение
Настоящий документ является частью документации по системе "ДБО BS-Client" версии
017.8.0, функционирующей в режиме Распределенной схемы.
На кого ориентирован документ
Документ предназначен для администратора подразделения банка.
Назначение документа
Назначение документа состоит в предоставлении информации о методах и средствах, используемых для защиты данных в системе "ДБО BS-Client".
Организация документа
В гл. 1 «Общая структурная схема каналов передачи данных в системе "ДБО BSClient"» [стр. 10] приведена общая структурная схема каналов передачи данных в системе
"ДБО BS-Client".
В гл. 2 «Защита передаваемых данных внутри банковской сети между компонентами системы
"ДБО BS-Client"» [стр. 12] приведены наиболее распространенные конфигурации компонентов системы "ДБО BS-Client".
В гл. 3 «Защита передаваемых данных в подсистеме «толстый» клиент ДБО (шифрация, подпись, транспорт)» [стр. 13] описаны средства защиты передаваемых данных, реализованные
в подсистеме «толстый» клиент ДБО.
В гл. 4 «Защита передаваемых данных в подсистеме Интернет-Клиент» [стр. 15] описаны
средства защиты передаваемых данных в подсистеме Интернет-Клиент
В гл. 5 «Защита передаваемых данных в подсистеме Телефон-Клиент» [стр. 19] описаны
средства защиты передаваемых данных в подсистеме Телефон-Клиент.
В гл. 6 «Защита от внешних атак» [стр. 20] описаны средства защиты от внешних атак,
реализованных в системе "ДБО BS-Client".
В гл. 7 «Защита от внутренних атак» [стр. 25] описаны средства защиты от внутренних атак,
реализованных в системе "ДБО BS-Client".
В гл. 8 «Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно» [стр. 33] описаны механизмы обеспечения целостности и аутентичности
данных, передаваемых в системе "ДБО BS-Client".
В гл. 9 «Работа с криптографическими ключами и сертификатами» [стр. 40] описаны методы
работы с криптографическими ключами и сертификатами в системе "ДБО BS-Client".
В гл. 10 «Конфликтные ситуации и способы их решения» [стр. 50] описаны возможные
конфликтные ситуации и способы их решения.
6
Введение
В гл. 11 «Соответствие системы "ДБО BS-Client" стандартам ЦБР» [стр. 54] описано соответствие системы "ДБО BS-Client" стандартам ЦБР.
В гл. 9 «Работа с криптографическими ключами и сертификатами» [стр. 40] приведен список
рекомендумой литературы для дополнительного ознакомления со средствами защиты информации.
Дополнительная информация приведена в приложениях:
•
прил. A «Криптографические справочники, используемые в системе "ДБО BSClient"» [стр. 57].
•
прил. B «Пример регламента разбора конфликтных ситуаций в системе "ДБО BSClient"» [стр. 59].
•
прил. C «Схема компонентов системы "ДБО BS-Client"» [стр. 64].
Рекомендации по использованию документа
Документ рекомендуется использовать и в качестве ознакомительного материала, и в качестве справочника при работе с системой "ДБО BS-Client". Документ рекомендован как для
последовательного, так и для выборочного изучения.
Внимание!
Материал может содержать большое количество перекрестных ссылок на другие части документации. Для интенсивного изучения материала, быстрого поиска необходимой информации и
удобного перехода по ссылкам рекомендуется воспользоваться контекстной справкой системы
"ДБО BS-Client": в справке содержится наиболее полная информация о системе и порядке работы
с ней. Контекстная справка вызывается из системы по нажатии клавиши F1.
Соглашения по оформлению
Кавычками выделяются значения полей экранных форм и различных параметров.
Наименования разделов и пунктов меню отделяются друг от друга символом →.
Для выделения блоков текста используются специальные средства оформления, представленные ниже.
Примечание
Служит для выделения дополнительной или разъясняющей информации, в том числе ссылок на
фрагменты документации, содержащие более подробные сведения. В основном следует непосредственно за элементом, к которому оно относится, но может предшествовать целой главе или
разделу.
Внимание!
Служит для выделения важной информации, на которую следует обратить внимание.
Служит для выделения дополнительной информации, рекомендованной для углубленного изучения системы. В основном информация, помеченная подобным образом, представляет собой
7
Введение
описание редко используемых возможностей системы. Данную информацию можно пропустить
при ознакомительном чтении.
8
Глоссарий
Glossary
Glossary
Glossary
9
Глава 1. Общая структурная
схема каналов передачи данных
в системе "ДБО BS-Client"
Рекомендованная структурная схема передачи данных в системе «Клиент-банк» в случае использования классического («толстого») клиента с TCP-транспортом и «Интернет-клиента»
приведена на следующем рисунке:
Рис. 1.1. Схема организации безопасности соединений
Данная схема предполагает следующую конфигурацию:
•
наличие firewall на входе и на выходе из ДМЗ ЛВС банка;
•
наличие отдельного сервера BS-Defender (в случае использования данного типа защиты
канала), расположенного в ДМЗ ЛВС банка;
•
наличие Сервера Приложений ДБО, Сервера СУБД, Интернет-сервера и сервера АБС в
закрытом сегменте ЛВС банка.
10
Общая структурная схема каналов передачи данных в системе "ДБО BS-Client"
Примечание
На схеме указаны номера TCP-портов, используемые по умолчанию. Их значения в общем случае
могут быть переопределены.
Помимо конфигурации, изображенной на схеме, возможны другие варианты, например, разнесение IIS и RTS на разные сервера и вынос сервера IIS в ДМЗ или размещение сервера для
транспорта «толстого» клиента в ДМЗ.
11
Глава 2. Защита передаваемых
данных внутри банковской сети
между компонентами системы
"ДБО BS-Client"
Система "ДБО BS-Client" является легко масштабируемой и допускающей различные способы и конфигурации внедрения. Таким образом, отдельные компоненты системы могут быть
по-разному размещены на отдельных серверах (также см. прил. C «Схема компонентов системы "ДБО BS-Client"» [стр. 64]).
В наиболее распространенной конфигурации, существуют следующие каналы связи между
компонентами системы "ДБО BS-Client":
•
BS-Defender – IIS+BSI+RTS;
•
Сервер приложений ДБО – Сервер СУБД;
•
IIS+BSI+RTS – Сервер СУБД;
•
Сервер приложений ДБО – Сервер АБС.
При передаче информации по внутренним каналам связи в системе "ДБО BS-Client" используются стандартный протокол межсетевого взаимодействия TCP / IP и его надстройки –
DCOM и протоколы взаимодействия с СУБД. В общем случае информация передается в открытом виде в форматах, установленных техническими требованиями к правилам обмена
информацией между компонентами системы.
В данном случае уровень безопасности по внутренним каналам связи в ЛВС определяется
необходимыми и достаточными требованиями к системе корпоративной внутрибанковской
безопасности и не является зоной ответственности компании разработчика программного
продукта "ДБО BS-Client".
В случае невозможности обеспечения необходимого уровня безопасности внутренней сети,
с помощью сторонних средств и организационных мер, в отдельных случаях возможно обеспечить шифрацию передаваемых по внутренним каналам данных. Так СУБД MS SQL
поддерживает защиту трафика взаимодействия с СУБД. Протокол DCOM также можно настроить на передачу с шифрацией трафика. Однако использование этих средств требует
взвешенного подхода, так как может привести к существенному падению производительности системы "ДБО BS-Client".
12
Глава 3. Защита передаваемых
данных в подсистеме «толстый»
клиент ДБО (шифрация,
подпись, транспорт)
Одной из подсистем, реализованной в рамках системы "ДБО BS-Client" является «классический» или «толстый» Банк-Клиент. Данная подсистема может являться как самостоятельным
продуктом, так и частью комплексной системы "ДБО BS-Client", и ориентирована, в первую
очередь, на средних и крупных и / или «консервативных» клиентов банка — юридических
лиц, а также на банки-корреспонденты и подразделения банка (филиалы, отделения, обменные пункты и т.п.).
3.1. Решаемые задачи
•
Формирование, доставка и обработка различных типов платежных и иных формализованных документов от клиента банку и от банка клиенту (в том числе выписок по счетам).
•
Обмен сообщениями произвольного формата (с возможностью включения файлов).
•
Обеспечение гарантированного уровня безопасности на базе использования механизма
ЭЦП финансовых документов.
•
Обеспечение шифрования / дешифрования данных, передаваемых по открытым каналам
связи.
•
Импорт / экспорт данных в / из сторонних систем.
3.2. Реализация ЭЦП в «Банк-Клиенте»
Документы, содержащие финансовую и иную ценную для банка или клиента информацию,
заверяются ЭЦП отправляющей стороны. Это обеспечивает целостность и юридическую
значимость вышеупомянутых документов. ЭЦП документа хранится в Базе Данных системы
в одной записи таблицы вместе с самим документом (см. разд. 8.1 «Использование подписи
под документами» [стр. 33]).
3.3. Организация транспортной
подсистемы
В системе "ДБО BS-Client" организована собственная транспортная подсистема, представленная ядром подсистемы и набором настраиваемых шлюзов, реализующих тот или иной
способ коммуникации. В стандартной поставке представлены шлюзы TCP / IP, файловый, EMail (POP3, SMTP). Шлюз представлен как подключаемый библиотечный модуль *.dll,
который принимает и отправляет пакеты информации.
Основными положениями, на базе которых разработана транспортная система, являются:
13
Защита передаваемых данных в подсистеме «толстый» клиент ДБО (шифрация,
подпись, транспорт)
•
Многопоточность – как ядро транспорта, так и шлюз поддерживают работу с произвольным настраиваемым количеством потоков процесса Windows, в котором запускается
серверный или клиентский модуль ДБО. Например, шлюз TCP / IP позволяет одновременно обслуживать любое количество клиентов, ограничиваемое только пропускной
способностью канала связи и аппаратными ресурсами.
•
Подключение шлюзов через общие интерфейсы ядра транспорта для каждого подключенного шлюза, например, автоматическое разбиение большого пакета для некоторых
типов электронной почты.
•
Возможность одновременного использования нескольких шлюзов. Таким образом, поддерживается работа клиентов по различным каналам связи, существование резервных
каналов и т.д.
•
Возможность архивации всех входящих и исходящих пакетов по каждому шлюзу, что
обеспечивает протоколирование и аудит всех событий в системе внешнего документооборота.
•
Поддержка ядром транспорта шифрования и сжатия информации (c возможностью подключения различных внешних криптосистем и архиваторов, а также произвольных процедур обработки пакетов).
Общая схема работы транспорта приведена на следующей схеме:
Рис. 3.1. Схема работы транспорта системы "ДБО BS-Client"
14
Глава 4. Защита передаваемых
данных в подсистеме ИнтернетКлиент
Целостность и конфиденциальность передаваемых данных в подсистеме Интернет-Клиент может быть обеспечена комплексным применением:
•
Межсетевого экранирования;
•
СКЗИ («КриптоПро CSP», «Message-Pro», «Верба-OW» и др.) для защиты канала;
•
Аутентификации, авторизации, протоколирования;
•
Штатных средств защиты ОС и СУБД;
•
Организационно-административных мероприятий.
В контексте данной главы рассмотрим способы защиты передаваемых данных при работе
подсистемы Интернет-Клиент. На данный момент реализованы три варианты подобной защиты:
•
использование «BS-Defender»;
•
использование одностороннего SSL / TLS;
•
использование двухстороннего SSL / TLS.
Рассмотрим каждый способ подробно.
4.1. Защита данных при использовании BSDefender
BS-Defender является отдельным приложением, состоящим из двух частей: клиентской и
серверной. Клиентская часть обычно устанавливается на рабочее место клиента и входит в
состав клиентского дистрибутива системы ИК. Серверная часть располагается в DMZ Банка.
Функционально BS-Defender представляет собой HTTP прокси-сервер со встроенным механизмом защиты трафика с помощью ассиметричной криптографии (криптографии с открытым ключом).
В функции BS-Defender входят:
•
фильтрация трафика, относящегося к подсистеме Интернет-Клиент и его маршрутизация;
•
вызов внешних систем криптозащиты для шифрования / дешифрования трафика;
•
протоколирование (логирование) всего трафика, прошедшего по системе;
15
Защита передаваемых данных в подсистеме Интернет-Клиент
•
сжатие / распаковка сообщений, проходящих по системе.
Работа пользователя выглядит при этом таким образом:
•
Если адрес в передаваемом URL присутствует в списке защищаемых адресов, то клиентская часть BS-Defender перенаправляет траффик на серверный BS-Defender. В этом случае
осуществляется шифрация и подпись трафика.
•
Если адрес в передаваемом URL не соответствует ни одному адресу из списка защищаемых адресов, то BS-Defender работает как обычный «прозрачный» http-прокси, безо
всякой шифрации/подписи трафика.
Схема работы BS-Defender представлена на следующей схеме:
Рис. 4.1. Схема работы BS-Defender
В действительности, нет необходимости устанавливать клиентскую часть BS-Defender на отдельную рабочую станцию, ее обычно ставят непосредственно на ту рабочую станцию, где
будет использоваться подсистема Интернет-Клиент.
4.2. Защита данных при использовании
SSL / TLS
Безопасность канала связи клиента с банком, в случае отсутствия модуля Defender может
быть обеспечена на уровне стандартных возможностей протокола межсетевого взаимодействия SSL или его более нового варианта – TLS.
В системе "ДБО BS-Client" допускается использование протокола SSL / TLS с различной
степенью защиты, в зависимости от используемых механизмов аутентификации. Тип аутен16
Защита передаваемых данных в подсистеме Интернет-Клиент
тификации по указанным протоколам определяется настройкой защищенного WEB-сервера
банка. Допускается как применение «одностороннего» SSL / TLS (только аутентификация
сервера клиентом), так и «двухстороннего» (аутентификация обоих партнеров).
В случае использования одностороннего SSL сертификат имеется только у веб-сервера, но
не у клиента. Таким образом, аутентификация клиентом Web-сервера происходит посредством использования сертификата, а аутентификация клиента сервером ДБО при помощи
логина и пароля клиента.
В случае использования двухстороннего SSL / TLS для установления соединения необходимо, чтобы произошла взаимная аутентификация клиента и сервера. В случае если сертификат
клиента принят сервером, а сертификат сервера клиентом, происходит установление защищенного соединения.
В определенных случаях использование криптографических алгоритмов на территории России регулируется федеральным законодательством, что необходимо учитывать при заключении договорных отношений по использованию системы "ДБО BS-Client" с государственными структурами и организациями. Так, при построении системы защиты на основе
протокола SSL / TLS необходимо принять во внимание, что стандартная реализация рассматриваемого протокола в ОС Windows не позволяет применять алгоритмы защиты информации, отличные от RSA, (который не является сертифицированным на территории РФ).
В связи с этим при построении защиты канала на основе протокола SSL / TLS рекомендуется
воспользоваться специальным пакетом Crypto-Pro TLS, который совместно с СКЗИ CryptoPro, позволяет использовать в рамках протокола сертифицированные в России алгоритмы
защиты информации (алгоритмы шифрования в соответствии с ГОСТ 28147-89, хеширования
в соответствии с ГОСТ Р 34.11-94). При этом в случае использования двухстороннего протокола SSL / TLS в рамках ДБО возможно использовать только СКЗИ Crypto-Pro в качестве
средства защиты информации. В случае использования одностороннего SSL / TLS данное
ограничение не накладывается.
Необходимо отметить, что построение защиты канала на основе одностороннего SSL / TLS
без установки Crypto-Pro TLS (т.е. с применением RSA сертификата WEB-сервера) технически допустимо, но не рекомендуется в связи с вышеописанными ограничениями федерального законодательства.
4.3. Сравнение различных способов
защиты канала
Ниже приведены преимущества и недостатки применения следующих типов защиты:
1.
Преимущества и недостатки применения типа защиты BS-Defender.
a.
Преимущества:
•
Использование «криптографической аутентификации».
•
Отсутствие обмена ключевой информацией по открытым каналам.
•
Возможность использования «нетиповых» СКЗИ для защиты канала передачи
данных, как-то «Верба» или «Excellence».
17
Защита передаваемых данных в подсистеме Интернет-Клиент
b.
2.
Недостатки:
•
Для использования защиты необходима установка на компьютер клиента дополнительного ПО (клиентской части BS-Defender).
•
Возможны проблемы при использовании в ЛВС клиента некоторых проксисерверов.
•
Большее использование системных ресурсов, нежели при использовании SSL /
TLS, т.к. криптографические операции по алгоритмам с открытым ключом более требовательны к ресурсам.
•
Наличие дополнительного программного обеспечения, которое потребляет системные ресурсы, подлежит настройке и т.д.
Преимущества и недостатки применения типа защиты SSL / TLS.
a.
b.
Преимущества:
•
Использование стандартного защищенного протокола, интегрированного в
ОС.
•
Меньшее потребление системных ресурсов.
Недостатки:
•
Есть обмен ключевой информацией.
•
Для защиты канала с помощью сертифицированных в России алгоритмов необходима установка Crypto Pro CSP / TLS.
•
Необходимость дополнительной настройки web-сервера, создание пользовательских исключений, в случае обращения клиента без установленного Crypto
Pro TLS.
18
Глава 5. Защита передаваемых
данных в подсистеме ТелефонКлиент
В настоящий момент в подсистеме Телефон-Клиент не предусмотрена возможность защиты
передаваемой информации, таким образом, данные от клиента к системе и обратно передаются в открытом виде по открытым каналам связи.
Однако, при необходимости возможна защита передаваемой информации посредством шифрования, как информации, так и канала передачи данных. Устройства, производства третьих
фирм решающие данную задачу в достаточном количестве представлены на рынке, и выбор
решения зависит от уровня желаемой защиты.
Системы защиты информации могут быть установлены и использоваться независимо от подсистемы Телефон-Клиент и не влияют на алгоритм и режим работы системы.
19
Глава 6. Защита от внешних атак
Настоящий раздел посвящен вопросам защиты от внешних атак, т.е. от действий лиц не
являющихся пользователями системы и не имеющими прямого физического доступа к компонентам системы. Рассматриваются вопросы аутентификации и авторизации внешних пользователей при установлении соединений через внешние каналы связи.
6.1. Фильтрация неподписанных пакетов в
ядре транспорта классического клиента
Для обеспечения аутентичности передаваемых и принимаемых транспортных пакетов в ядре
транспорта классического («толстого») клиента предусмотрена возможность шифрования и
применения электронной подписи (см. разд. 3.3 «Организация транспортной подсистемы» [стр. 13]): при отправке пакета от клиента в банк (и, соответственно, наоборот) пакет
проходит обработку специальной функцией (вид и параметры функции задаются в настройках), в результате работы которой к пакету присоединяется электронная подпись.
На принимающей стороне производится обратное действие – пакет расшифровывается и
проходит проверку на достоверность электронной подписи; только лишь в случае успеха этих
двух процедур пакет поступает на дальнейшую обработку. Таким образом, входящий пакет,
не имеющий электронной подписи (в то время как настройками предписывается применять
электронную подпись), либо пакет, подпись которого не прошла проверку на подлинность,
считается ошибочным и к дальнейшей обработке не допускается.
Реакция ядра транспорта на появление ошибочного входящего пакета определяется соответствующими настройками: такой пакет может быть:
•
отброшен (физически удален);
•
сохранен в виде файла в специально выделенном каталоге или / и помещен в ту же таблицу
БД, что и прочие пакеты, но со специальным статусом, позволяющим при необходимости
выбрать все подобные пакеты и принять по ним соответствующее решение.
На максимальный суммарный объем ошибочных пакетов, сохраняемых как в виде файлов,
так и в БД, накладываются ограничения, что не позволит вызвать дефицит физических ресурсов системы по злому умыслу.
6.2. Аутентификация пользователей в
подсистеме Интернет-Клиент
6.2.1. Подпись трафика BS-Defender’a
Установление соединения клиентского BS-Defender’а с банковским происходит следующим
образом: клиент формирует запрос, подписывает его и отправляет в адрес банковского BSDefender. Банковский BS-Defender определяет подлинность подписи полученного запроса и
сверяет идентификатор клиентского ключа (UID) со списком известных значений (В заголовке запроса, переданного на Web-сервер содержится идентификатор подписи. Далее,
этот идентификатор передается компонентом BSI серверу задач (RTS). По нему RTS опре20
Защита от внешних атак
деляет клиента, и, в случае наличия необходимых прав у клиента, предоставляет ему доступ
к системе). Если такая проверка дает ошибку — запрос отвергается. Проверка идентификатора клиентского ключа происходит при каждом запросе, что исключает подделку запросов
и / или ответов.
Так как клиент (Интернет-браузер) и клиентский 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
Глава 7. Защита от внутренних
атак
Настоящий раздел посвящен вопросам защиты от внутренний атак и непреднамеренных действий людей, имеющих физический доступ к компонентам Системы. Рассматриваются вопросы аутентификации и авторизации внутренних пользователей, организации системы прав
доступа, организации журнализации и протоколирования событий, происходящих в системе,
а также ряд смежных вопросов.
7.1. Аутентификация и авторизация
внутренних пользователей
Комплекс системы "ДБО BS-Client" (банковская часть) поддерживает одновременную работу
в системе нескольких пользователей. Как правило, эти пользователи исполняют различные
роли («Администратор системы», «Администратор безопасности», «Операционист» и т.п.).
Для обеспечения ограничения доступа пользователей к функциям системы и последующему
назначению прав на функции системы в "ДБО BS-Client" используется механизм аутентификации пользователей.
В "ДБО BS-Client" используется механизм парольной аутентификации / авторизации. Каждому пользователю системы "ДБО BS-Client" назначается свой собственный уникальный
логин в систему. Вход в систему данного пользователя происходит только после корректного
ввода пользователем его пароля. Для каждого из пользователей можно задать политику безопасности, накладывающую ограничения на парольную аутентификацию / авторизацию.
Эта политика может включать в себя:
•
запрет изменения собственного пароля;
•
максимальное количество попыток ввода пароля (по истечении количества неправильно
введенных паролей пользователь блокируется);
•
минимальная длина пароля;
•
дата истечения действия пароля;
•
период принудительной смены пароля (допустим принудительная смена пароля каждый
месяц);
•
временные интервалы действия пароля (например, с 10:00 до 18:00);
•
запрет использования простых паролей;
•
запрет повторного использования собственных паролей (при принудительной смене паролей).
Любой пользователь может сменить свой пароль как в процессе плановой процедуры смены
пароля, так и по собственному желанию (если это не запрещено политикой безопасности).
Механизм смены пароля пользователем также защищен парольной аутентификацией/авто25
Защита от внутренних атак
ризацией. То есть при смене пароля пользователь должен обязательно пройти аутентификацию / авторизацию на старом пароле. Кроме того, Администратор безопасности может
принудительно сменить пароль пользователю или заблокировать пользователя.
Чтобы повысить защищенность парольной аутентификации / авторизации от внутренних атак
в системе "ДБО BS-Client" не используется прямое хранение парольной информации. Вместо
этого используется схема авторизации подписью. При заведении пароля по нему однозначно
строится закрытый криптографический ключ по ассиметричному криптографическому алгоритму. По этому закрытому ключу генерируется открытый ключ, который и сохраняется в
базе данных в качестве парольной информации.
При аутентификации пользователя ядро системы генерирует случайный набор данных и передает системе аутентификации. Система аутентификации запрашивает у пользователя пароль. По введенному паролю опять строится закрытый ключ и этим ключом подписываются
переданные случайные данные. Подпись передается обратно ядру. Далее ядро проверяет
подпись под данными при помощи, открытого ключа, сохраненного в базе данных. Если
подпись верна, то введенный пароль совпадает с паролем, заведенным в системе.
Такая схема дает несколько преимуществ:
•
Информация о пароле, хранящаяся в базе (открытый ключ), не является секретной и не
позволяет восстановить пароль (или закрытый ключ, соответствующий паролю).
•
Информация, передаваемая между ядром системы и системой аутентификации, не является секретной, так как она не содержит не только самого пароля, но даже и фиксированного хэша от него. Передается только подпись паролем случайных данных. Так как
при аутентификации случайные данные всякий раз другие, то перехват этой информации
не позволяет взломать систему.
7.2. Права пользователей в системе
7.2.1. Общее описание системы прав
Система прав, реализованная в системе "ДБО BS-Client" базируется на системе привилегий,
ролей и профилей. Определение данных терминов в контексте Системы дано ниже.
Привилегия – право (или наоборот запрет) на совершение некоторого действия в системе.
Системные привилегии заданы раз и навсегда и означают строго фиксированное действие.
Например, привилегия «VIEW_ANY_USER_TABLE» позволяет просматривать любые несистемные таблицы. Привилегия может иметь один или несколько параметров. Так, например, привилегия «EDIT_TABLE_RECORD» имеет два параметра (имя таблицы и фильтр).
К существующему в системе перечню привилегий можно добавить новые привилегии. В этом
случае сама система никак не будет их обрабатывать, но внешние модули получат возможность узнать, есть ли права на эту привилегию у текущего пользователя и самим обработать
ситуацию недостаточности прав и т.п.
Роль – набор привилегий. Задается списком привилегий (с заполненными параметрами) и
списком ролей включенных в данную роль. Причем привилегии могут быть указаны как
предоставленными (granted), так и запрещенными (revoked). Все привилегии, содержащиеся
во вложенных ролях, автоматически считаются принадлежащими данной роли. Запрет при26
Защита от внутренних атак
вилегии всегда мажорирует ее разрешение. Роли могут редактироваться и являются настраиваемыми.
Профиль – набор правил работы с паролем (время истечения, временные ограничения и т.п.)
и самой системой (имя главной формы, язык и т.п.). Набор параметров здесь строго фиксирован; меняются только их значения. В системе можно завести произвольное количество
профилей.
Пользователь – пользователь системы. Каждый пользователь имеет свой идентификатор
(«логин») и пароль. Пользователю всегда назначен только один профиль и одна или несколько
ролей, а также отдельные привилегии.
7.2.2. Система прав доступа к СУБД и серверу ДБО
Для повышения защищенности в системе "ДБО BS-Client" произведено разделение понятий
«пользователь системы» и «пользователь базы данных».
Так, соединение с базой данных, в общем случае, выполняется с одним именем пользователя
и паролем, а вход в систему "ДБО BS-Client" – с другим. В общем случае эти вещи между
собой никак не связаны. Пароль пользователя, точнее информация для его проверки
(см. разд. 7.1 «Аутентификация и авторизация внутренних пользователей» [стр. 25]) хранится
в DSP-структуре соответствующей пользователю и является максимально защищенным (не
взламывается и восстановлению не подлежит).
При определенных настройках, пароль к базе данных вообще не хранится на клиенте и конфиденциальность пароля обеспечивается средствами СУБД. Таким образом, в общем (максимально защищенном случае) пользователю предлагается ввести пароль к базе данных и
пароль в систему.
7.2.3. Система прав разграничения доступа по
документам
В "ДБО BS-Client" присутствует система разграничения прав доступа по документам на банковской стороне, реализованная на прикладном уровне. Она называется системой Кураторов.
Кураторы – пользователи системы "ДБО BS-Client", ответственные за сопровождение фиксированного набора организаций клиентов.
Система подразумевает жесткое разграничение прав просмотра кураторами документов только клиентов, на которые им выданы соответствующие права администратором сервера ДБО.
Ограничение касается как входящих, так и исходящих документов организаций клиентов.
Примечание
Реализация Кураторов в Системе сделана независимо от системы привилегий, описанных
в разд. 7.2.1 «Общее описание системы прав» [стр. 26], используя механизм фильтрации записей
в визуальном интерфейсе.
27
Защита от внутренних атак
7.3. Ограничение доступа к БД через
внешние средства
Одним из видов внутренней атаки на систему является попытка прямой работы с СУБД, в
которой хранятся данные системы не через легальные средства самой системы, а через внешние приложения. Для осуществления такой атаки необходимо получить логин и пароль к
СУБД, а также обладать необходимыми правами на доступ к объектам СУБД.
Для защиты от подобных атак в системе "ДБО BS-Client" предусмотрено несколько механизмов. Часть из них используется в стандартной поставке, а часть может быть подключена
к системе дополнительно при соответствующем пожелании банка. Данные механизмы включают в себя:
•
использование каждым пользователем системы уникального логина в СУБД;
•
использование операторами системы скрытого пароля к СУБД;
•
использование механизма внешней аутентификации пользователей;
•
использование механизмов СУБД для ограничения доступа к базе данных.
Рассмотрим далее эти механизмы подробнее.
Одним из простейших способов ограничить доступ злоумышленника к СУБД является парольная защита, которая присутствует во всех поддерживаемых СУБД. ДБО позволяет
использовать парольную аутентификацию СУБД. Для этого каждому пользователю системы
"ДБО BS-Client" выдается определенный логин в СУБД. При входе пользователя в систему
он помимо пароля пользователя должен также ввести пароль в СУБД. Таким образом, злоумышленник не являющийся пользователем системы "ДБО BS-Client", не сможет получить
доступ к базе данных.
Для упрощения процедуры аутентификации можно указать системе, что пароли пользователя
в ДБО и СУБД совпадают. В этом случае у пользователя будет запрашиваться только один
пароль.
Система "ДБО BS-Client" позволяет запретить прямой доступ внешними средствами к СУБД
даже тем пользователям, которые являются пользователями "ДБО BS-Client". Для этого можно задействовать режим, при котором пароль к СУБД не запрашивается у пользователя, а
вводится автоматически на основании информации в файле настроек default.cfg. В этом
файле пароль в СУБД хранится в зашифрованном виде, что ограничивает возможности пользователя по его вскрытию. Таким образом, пользователь системы "ДБО BS-Client" вообще
не знает пароль, с помощью которого происходит взаимодействие с СУБД и, следовательно,
не может использовать внешние средства для работы с СУБД.
Самым защищенным способом аутентификации пользователей в СУБД является способ
внешней аутентификации. Он не входит в стандартную поставку системы, но в случае необходимости может быть добавлен по требованию банка.
В этом случае пароль к СУБД не запрашивается у пользователя и не хранится на локальном
компьютере пользователя и, следовательно, даже теоретически не может быть использован
для доступа к СУБД через внешние средства.
28
Защита от внутренних атак
Подключение к СУБД в этом случае происходит следующем образом.
1.
При входе пользователя в систему происходит обращение по DCOM к вешнему серверу
аутентификации.
2.
Далее этот сервер на основании стандартного механизма аутентификации Windows
определяет пользователя домена, обратившегося к нему.
3.
На основании этого имени сервер аутентификации определяет логин и пароль в СУБД
для данного пользователя.
4.
Полученные логин и пароль передаются (с использованием защищенного протокола)
обратно в приложение оператора.
5.
Далее происходит подключение в СУБД с использованием полученных параметров. В
этом случае пользователь вообще не вводит и не знает свой пароль в СУБД. Схема данного механизма аутентификации изображена на следующей схеме:
Рис. 7.1. Схема внешней аутентификации приложений
Помимо встроенных в систему "ДБО BS-Client" механизмов защиты можно использовать и
механизмы защиты, предоставляемые самими СУБД. Поскольку такие механизмы существенно зависят от используемой СУБД, то в стандартную поставку они не входят, но могут
быть настроены самим банком или специалистами БСС в каждом конкретном случае. В частности те или иные СУБД поддерживают следующие механизмы (приведены только некоторые примеры):
•
Использование механизма аутентификации Windows вместо парольной аутентификации
доступа к СУБД.
•
Разграничение прав пользователей на объекты СУБД (запрет просмотра или изменения
отдельных таблиц, например).
•
Ограничение списка компьютеров, с которых разрешен доступ к СУБД;
29
Защита от внутренних атак
•
Применение криптографии.
Также в качестве дополнительного механизма защиты можно рекомендовать использовать
запрет для рядовых пользователей возможности прямого доступа к СУБД на сетевом уровне
путем межсетевого экранирования в ЛВС.
В совокупности описанные механизмы гарантируют невозможность взлома системы через
доступ к СУБД внешними средствами.
7.4. Аудит действий пользователей
Аудит действий пользователей системы "ДБО BS-Client" осуществляется с использованием
так называемого «журнала событий» (доступен в серверной части и «толстом» клиенте ДБО).
Журнал событий, ведущийся в системе "ДБО BS-Client", соответствует следующим требованиям:
•
наличие информации обо всех событиях произошедших в системе;
•
периодическое обновление информации в «окне событий»;
•
возможность оповещения администратора вызовом заданной операции, например, выводом предупреждения на экран или формированием сообщения MS-Exchange при появлении в журнале записи (записей), удовлетворяющих заданному условию.
Использование данного интерфейса позволяет получить информацию о:
•
пользователях, зарегистрированных в системе;
•
текущим статусе (подключен / не подключен) каждого из пользователей;
•
последнем событии, произведенное пользователем и его время;
•
полном списке действий выбранного пользователя за указанный период времени с возможностью фильтрации по типу событий.
7.5. Журналирование процессов,
происходящих внутри системы
В процессе работы системы ведутся различные журналы (лог-файлы). Они отражают действия и операции, выполняемые системой. Есть журналы, которые ведутся всегда, создание
других можно настроить. Создание журналов бывает полезно как для получения отладочной
информации, так и для дополнительного аудита работы системы.
7.5.1. Фиксация смены статусов документов
Для всех финансовых документов, имеющих хождение в системе "ДБО BS-Client" предусмотрен механизм журнализации истории смены статусов документа. Данные о дате и времени
смены статуса, значении исходного и конечного статуса при смене, а также имя пользователя,
выполнявшего процедуру, приведшую к смене статуса документа доступны из визуального
интерфейса «толстого» клиента и серверной части системы "ДБО BS-Client" (Системные поля
документа—История).
30
Защита от внутренних атак
7.5.2. Системные журналы
Системные журналы в системе делятся на два типа:
•
системные журналы ошибок необходимы для выяснения причин сбоев и ошибок в системе, и создаются в обязательном порядке;
•
системные информационные журналы осуществляют полное логирование, могут быть
отключены.
7.5.2.1. Системные журналы «толстого» клиента и сервера
ДБО
Таблица 7.1. Системные журналы «толстого» клиента и сервера ДБО
Наименование журнала
Описание
Журнал ошибок (error.log) Файл error.log создается в каталоге запуска программы. При появлении ошибок и сбоев в работе они отражаются в данном файле; в
том числе и ошибки, которые появляются на экране в процессе работы
программы.
Таблица 7.2. Системные журналы подсистемы Интернет-Клиент
Наименование журнала
Описание
Журнал запросов / ответов, проходящих через BSDefender
В данный файл заносятся запросы и / или ответы (в зависимости от параметров), проходящие
через BS-Defender. При этом тела http-пакетов
зашифрованы.
Журнал ошибок BSI
В данный файл заносятся записи о нештатных
ситуациях, возникающих при работе модуля
bsi.dll
Журнал ошибок RTS (rtserror.log)
В файл записываются все ошибки (нештатные
ситуации), возникающие при работе приложения RTS.
Журнал проходящего трафика RTS (внутренняя трас- В данный файл заносятся запись событий расировка)
боты RTS.
Таблица 7.3. Системные журналы подсистемы Телефон-Клиент
Наименование журнала
Описание
Журнал работы «Телефон-Клиент» Все действия подсистемы по отношению к клиенту (озвучивание
голосовой информации, запросы и получение информации от клиента). Классифицируется по номеру канала и календарной дате
(путь относительно стандартной установки %BSSROOT%
\BSPhone\Logs\).
Журнал трассировки запросов
Журнал, отражающий основные этапы обработки запросов от Информационно-Речевого Сервера к БД (путь относительно стандартной установки %BSSROOT%\Subsys\Logs\Phone\).
31
Защита от внутренних атак
Наименование журнала
Описание
Журнал ошибок
Все ошибки (нештатные ситуации), возникающие при работе приложения на Информационно-Речевом Сервере (путь относительно стандартной установки %BSSROOT%\Subsys\Logs\Error
\).
Журнал посещаемости
Факт использования клиентом системы определенного функционала (например, авторизация, остаток на счете, выписка на факс и
др.). Заполняется в БД (таблица CT_PHONELOG). По данным журнала возможно формирование отчета (см. документацию по администрированию).
7.5.3. Журналы макроязыка
Журналы макроязыка ведутся модулями и подпрограммами, написанными на макроязыке.
Такие журналы хранятся в каталоге %BSSRoot%\SubSys\LOGS. Каждый тип таких журналов ведется в отдельном подкаталоге. Журналы за каждый день ведутся в отдельном файле
с именем yyyymmdd.log.
В таблице 5 приведены наиболее важные журналы макроязыка.
Таблица 7.4. Таблица 5. Журналы макроязыка
Наименование каталога Содержание
CheckSgn
Содержит детальную информацию обо всех вызовах криптографических
функций.
Controls
Журнал работы контролей документов.
Crypto
Содержит итоговую информацию обо всех криптографических операциях
(инсталляция подписи, подпись / проверка подписи документов, регистрация новых ключей подсистемы Интернет-Клиент).
LinkABS
Содержит всю информацию об операциях импорта / экспорта документов
из / в АБС (выгрузка, выписки, квитовка, отзыв документа).
Print
Трассировка менеджера печати документов.
RBase
Журнал работы подсистемы удаленных обновлений.
RPL
Журнал работы подсистемы репликации данных.
SHEDULER
Журнал работы менеджера автопроцедур.
Следует заметить, что информация из журналов, особенно при включении максимальной
подробности логирования может содержать ценную информацию, утечка которой крайне
нежелательна. Сотрудникам банка рекомендуется уделять повышенное внимание разграничению прав доступа на файлы и каталоги журналов системы.
32
Глава 8. Обеспечение
целостности и аутентичности
информации передаваемой от
клиентов в банк и обратно
Настоящий раздел посвящен механизмам обеспечения целостности и аутентичности данных,
передаваемых в системе "ДБО BS-Client".
8.1. Использование подписи под
документами
8.1.1. Общие сведения
Подпись документа в системе «Клиент-банк» осуществляется СКЗИ, поставляемой сторонними производителями (перечень библиотек, применение которых возможно приведен
в разд. 9.1 «Описание особенностей СКЗИ» [стр. 40]).
Поскольку все поддерживаемые СКЗИ работают с блоком бинарных или текстовых данных,
то для подписи документа (который является просто записью в таблице) необходимо решить
задачу представления документа в таком виде. При этом соответствие между документом и
блоком подписываемых данных должно быть всегда взаимнооднозначным.
В различных версиях «Клиент-банка» использовались разные алгоритмы формирования данных для подписи. При этом более поздние версии «Клиент-банка» всегда поддерживают все
предыдущие алгоритмы, т.е. сохраняется обратная совместимость.
В системе "ДБО BS-Client" могут подписываться две основные бизнес-сущности:
•
документы: как финансовые, так и не финансовые (служебные, например, репликации);
•
транспортные пакеты.
8.1.2. Подпись документов и квитанций
Процедура подписи документов и квитанций выполняется в следующем порядке:
1.
При простановке подписи под документом подписываемые бинарные данные формируются по перечню подписываемых полей (т.н. «схема составления документа» или
ССД, которая расположена в ветке DCMethods в документарной схеме операции).
2.
При простановке ЭЦП под документом сами значения подписи сохраняются в служебном поле Signatures, входящим в каждую из документарных таблиц.
3.
Подписанные блоки данных в Системе не хранятся, а формируются каждый раз согласно
п.1. при простановке или проверке ЭЦП.
33
Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно
4.
В отличие от документов, подпись под квитанциями на документ не проставляется. Однако есть возможность подписывать транспортные пакеты, содержащие в себе квитанции. При этом всегда существует однозначное соответствие между квитанцией и
транспортным пакетом, в котором она содержится, а значит ЭЦП транспортного пакета
может «играть роль» ЭЦП квитанции.
5.
Квитанции на документ хранятся не в документарных таблицах, а внутри транспортных
пакетов, содержащихся в таблице транспортных пакетов (TransPakets). Для поиска квитанций, соответствующих данному документу внутри транспортных пакетов (например,
при разборе конфликтных ситуаций), существует специальная функция в ядре системы.
8.1.3. Возможность разбора конфликтных ситуаций
В системе предусмотрен функционал для осуществления действий по разбору конфликтных
ситуаций.
В случае необходимости выполнения разбора конфликтной ситуации выполняются следующие действия:
•
определение всех пакетов, в которых передавалась информация по документу и его квиткам;
•
проверка ЭЦП всех указанных пакетов;
•
формирование информации для отображения документа (и квитков документа в виде отдельных документов специального вида);
•
выгрузка всех указанных пакетов в виде отдельных файлов;
•
выгрузка ЭЦП всех указанных пакетов в виде отдельных файлов.
На основании выгруженных пар файлов (пакет + ЭЦП пакета) может быть выполнен анализ
подлинности ЭЦП пакетов, содержащих документ и его квитки в сторонних системах СКЗИ.
8.2. Использование подписи при передаче
транспортного трафика
При использовании «Толстого клиента» системы "ДБО BS-Client" передача данных от клиентов в банк и обратно осуществляется исключительно посредством передачи / приема
транспортных пакетов.
Для обеспечения аутентичности передаваемых и принимаемых транспортных пакетов в ядре
транспорта предусмотрена возможность шифрации и применения электронной подписи: при
отправке пакета от клиента в банк (и, соответственно, наоборот), пакет проходит обработку
специальной функцией, (вид и параметры функции задаются в настройках), в результате работы которой, к пакету присоединяется ЭЦП.
На принимающей стороне производится обратное действие – пакет расшифровывается и
проходит проверку на достоверность ЭЦП; только лишь в случае успеха этих двух процедур
пакет поступает на дальнейшую обработку.
34
Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно
Таким образом, входящий пакет, не имеющий ЭЦП (в то время как настройками предписывается применять электронную подпись), либо пакет, подпись которого не прошла проверку
на подлинность, считается ошибочным и к дальнейшей обработке не допускается.
8.3. Использование подписи при передаче
трафика BS-Defender
Каждый запрос и ответ, передаваемые от клиентского BS-Defender к банковскому и обратно,
шифруются и подписываются (см. разд. 4.1 «Защита данных при использовании BSDefender» [стр. 15]). Аутентичность пакетов гарантируется криптостойкостью используемой
СКЗИ.
8.4. Использование механизмов
аутентичности двустороннего SSL (TLS)
В данном разделе приведено общее описание способа соединения с Интернет-Клиент по
каналу, защищаемому двусторонним SSL (TLS). Однако, данная глава не содержит руководства по настройке SSL / TLS в Интернет-Клиент, а также технических подробностей,
касающиеся параметров и настроек.
8.4.1. Общие сведения
Аутентификация при защите соединения двусторонним SSL (TLS) — аналогична применяемой в типе соединения «BS-Defender». Канал защищается как со стороны клиента, так и со
стороны сервера персональными криптографическими ключами. Криптографические операции выполняются на клиентской стороне — WEB-браузером, на серверной стороне — WEBсервером.
8.4.2. Исходные требования
Ниже перечислены основные требования:
1.
Компьютер клиента: Персональный справочник текущего пользователя содержит сертификат клиента с установленной на уровне ОС связкой с контейнером секретных
ключей. Область расширенного применения ключа данного сертификата должна допускать применение сертификата для аутентификации клиента (Client authentification).
Кроме этого в справочник доверенных сертификатов корневых центров сертификации (Trusted Root Certification Authorities) текущего пользователя должен быть установлен сертификат корневого центра сертификации.
2.
Компьютер банковского WEB-сервера: Банковский WEB-сервер должен быть настроен
на использование защищенного соединения (https) с контролем клиентского сертификата. Сертификат банковского WEB-сервера должен содержаться в персональном справочнике локального компьютера с установленной на уровне ОС связкой с контейнером
секретных ключей. Область расширенного применения ключа данного сертификата должна допускать применение сертификата для аутентификации сервера (Server
authentification). Кроме этого в справочник доверенных сертификатов корневых центров
35
Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно
сертификации (Trusted Root Certification Authorities) локального компьютера должен
быть установлен сертификат корневого центра сертификации.
Примечание
Механизм и описание того, что является справочником сертификатов, в данном документе не
рассматривается. В грубом приближении, это место, куда складываются открытые ключи и где
устанавливаются ссылки на расположение секретных ключей.
Установленный в открытом ключе, как клиента, так и банка параметр, ссылающийся на ресурс
хранящий списки отозванных сертификатов — доступен.
8.4.3. Технология связи клиента и банка по каналу
«Двусторонний SSL / TLS»
Клиент инициирует соединение, вписывая в строку браузера ссылку на WEB-сайт банка (или
открывает иным способом в браузере сайт банка). В строке запроса явным образом указывается, что соединение будет происходить по защищенному каналу — применяется именование протокола "https://" вместо "http://" (например, "https://
www.bank.ru").
Протоколы TLS подразумевают, что в качестве транспортного протокола используется протокол с установлением логических соединений (например, TCP) и состоят из двух слоев.
Первый слой включает в себя прикладной протокол и три так называемых handshake-протокола: протокол установления SSL-сессии (Handshake Protocol), протокол смены спецификации шифра (Change Cipher Spec Protocol) и протокол сигнальных сообщений (Alert Protocol).
Второй слой — это т.н. Record Protocol, схематически это можно изобразить так:
Рис. 8.1. Технология связи клиента и банка по каналу «Двусторонний SSL / TLS»
Handshake-протоколы отвечают за установление или возобновление защищенных сессий.
Record protocol выполняет следующие функции:
•
Разбивает данные, получаемые от прикладного уровня на блоки и собирает входящие
блоки для передачи на прикладной уровень.
•
Компрессирует исходящие данные и декомпрессирует входящие.
•
Прикрепляет MAC или хэш к исходящим блокам данных и использует прикрепленный
MAC для проверки целостности входящих.
36
Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно
•
Шифрует исходящие и расшифровывает входящие блоки данных.
В момент обработки первого запроса на соединение с WEB-сервером происходит так называемый HandShake. В этой процедуре происходит следующее:
•
WEB-сервер определяет, что для работы с данным WEB-сайтом необходимо шифровать
соединение от имени серверного сертификата (выполняется процедура установления действительности собственного сертификата путем обращения к узлу с перечнем отозванных
сертификатов).
•
Если серверный сертификат признан годным, сервер определяет по настройке, нужно ли
требовать от клиента предоставить свой клиентский сертификат.
•
Сертификат банка передается в WEB-браузер клиента, также, если это обусловлено настройкой, передается сигнал о предоставлении сертификата клиента Web-серверу.
•
Получив от WEB-сервера ответ, содержащий сертификат банка и требование о передаче
клиентского сертификата, браузер выполняет два действия:
•
1.
устанавливает действительность банковского сертификата;
2.
обращается за информацией к справочнику сертификатов, и предлагает клиенту
диалоговое окно с перечнем сертификатов, которые могут быть использованы клиентом для защиты соединения.
Удостоверившись в сертификате банка и получив указатель на клиентский сертификат,
сертификат клиента передается на WEB-сервер, где уже сервер выполняет процедуру
удостоверения в достоверности клиентского сертификата.
После того как процедура HandShake выполнена, начинается штатная шифрация трафика.
Для шифрования передаваемых данных используются симметричная криптография, т.е. одним и тем же ключом можно как зашифровать, так и расшифровать зашифрованные данные.
Таким образом, на каждой стороне есть комплект из двух ключей (одинаковый для обоих
сторон), используемый для шифрации принимаемых / передаваемых данных, и комплект из
двух ключей, используемый для формирования MAC (HMAC).
37
Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно
Рис. 8.2. Схема взаимодействия клиента, сервера и приложений при организации соединения
«двусторонний SSL / TLS».
8.5. Сеансовые ключи при заведении
клиентом документов в подсистеме
Телефон-Клиент
Сеансовые ключи, запрашиваемые у клиента при авторизации в подсистеме Телефон-клиент могут рассматриваться в качестве аналога собственноручной подписи для документов,
сформированных в течение текущего сеанса связи.
В случае повышенных требований к безопасности, возможно, запрашивать проверку СК каждый раз для подтверждения клиентом введенных данных, а также при запросе клиента
подтверждения возможности прохождения документом стандартных банковских контролей.
8.6. Аутентичность выписок, остатков и
другой информации выдаваемой банком в
подсистеме Телефон-Клиент
Аутентичность информации, передаваемой в канале Банк ↔ Телефон-клиент обеспечивается
на уровне системных библиотек, поскольку приложение Телефон-клиент расположено в ЛВС
банка и работает напрямую с сервером приложений системы "ДБО BS-Client".
Потеря аутентичности возможна лишь на уровне Телефон-клиент ↔ Клиент, при наличии
искажений сигнала в канале связи (телефонной линии).
38
Обеспечение целостности и аутентичности информации передаваемой от клиентов
в банк и обратно
Для уменьшения вероятности технических накладок, при формировании документов, перед
проведением транзакции, клиенту озвучиваются все введенные им параметры платежа и вид
платежа.
39
Глава 9. Работа с
криптографическими ключами и
сертификатами
В настоящем разделе описана инфраструктура, использующаяся для встраивания в систему
"ДБО BS-Client" средств криптозащиты информации.
9.1. Описание особенностей СКЗИ
В системе "ДБО BS-Client" реализована связка со следующими средствами криптографической защиты информации, разработанными российскими и зарубежными производителями:
Таблица 9.1. Используемые в системе "ДБО BS-Client" средства защиты информации
№
Наименование Алгорит- Макс. длимы ЭЦП на открытого ключа
(бит)
Сертификат
ФАПСИ
Открытый
Поддержка
ключ / серти- списков отозфикат
ванных сертификатов (CRL)
1.
Excellence 4.0
ГОСТ Р
34.10-94
512
Отсутствует
Открытый ключ
Отсутствует
2.
LAN Crypto/
2.35
ГОСТ Р
34.10-94
512
Отсутствует
Открытый ключ
Отсутствует
3.
Verba 4
ГОСТ Р
34.10-94
512
Отсутствует
Открытый ключ
Отсутствует
4.
Verba 5
ГОСТ Р
34.10-94
1024
Имеется
Открытый ключ
Отсутствует
5.
Crypto Com/2.2
ГОСТ Р
34.10-94
512
Отсутствует
Сертификат
Отсутствует
6.
Message Pro
1.1-1.2
RSA
768
Отсутствует
Сертификат
X509
Имеется
7.
Message Pro
1.3x
ГОСТ Р
34.10-94
1024
Имеется
Сертификат
X509
Имеется
8.
Message Pro 2.x
ГОСТ Р
34.10-2001
–
Имеется
Сертификат
X509
Имеется
9.
Crypto Pro CSP
1.1
ГОСТ Р
34.10-94
1024
Имеется
Сертификат
X509
Имеется
10.
Crypto Pro CSP ГОСТ Р
2.0
34.10-2001
–
Имеется
Сертификат
X509
Имеется
11.
OpenSSL
RSA
1024
Отсутствует
Сертификат
X509
Имеется
12.
Validata
ГОСТ Р
34.10-2001
–
Имеется
Сертификат
X509
Имеется
40
Работа с криптографическими ключами и сертификатами
№
Наименование Алгорит- Макс. длимы ЭЦП на открытого ключа
(бит)
13.
Crypto-C
ГОСТ Р
34.10-2001
Сертификат
ФАПСИ
Имеется
–
Открытый
Поддержка
ключ / серти- списков отозфикат
ванных сертификатов (CRL)
Открытый ключ
Отсутствует
Так как правила защиты финансовой информации для государственных структур на текущий
момент регламентируются федеральным законом об электронно-цифровой подписи, при выборе средства защиты информации для использования в рамках системы "ДБО BS-Client" в
таких организациях, необходимо особое внимание уделить наличию сертификата ФАПСИ,
удостоверяющего правомерность применения того или иного средства для защиты финансовой информации.
В рамках системы "ДБО BS-Client" реализована также универсальная связка с единым криптографическим интерфейсом Windows Microsoft Crypto API 2.0. Данная связка позволяет
использовать в качестве средства защиты информации любой криптопровайдер
(Cryptographic Service Provider) из установленных на компьютере пользователя. Однако, изза особенностей работы различных провайдеров, гарантировать полнофункциональную работу такого решения без проведения тщательного тестирования нельзя.
9.2. Основные понятия
Примечание
В данном разделе под термином «сертификат» подразумевается электронный сертификат ключа
подписи, т.е. электронный документ с электронной цифровой подписью уполномоченного лица
удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой подписи и которые выдаются удостоверяющим центром участнику информационной системы для
подтверждения подлинности электронной цифровой подписи и идентификации владельца сертификата ключа подписи.
9.2.1. Записи о ключах
Понятие «запись о ключах» в системе "ДБО BS-Client" включает в себя:
•
идентификатор (UID);
•
криптографические параметры: пути к секретным ключам, каталогу ЦС, справочнику
сертификатов других абонентов и прочие параметры;
•
признак активности: «активный» / «не активный» / «запрещен» / «переходный»;
•
признак временного сертификата: «технологичный» / «рабочий».
Признак «активный» указывает на текущий рабочий сертификат (открытый ключ) абонента.
Признак «не активный» — на старый сертификат (открытый ключ), который был сменен в
результате плановой смены сертификата.
Признак «запрещен» – на сертификат (открытый ключ), который был скомпрометирован.
41
Работа с криптографическими ключами и сертификатами
Признак «переходный» — на новый сертификат (открытый ключ), который появляется в
процессе плановой смены сертификата (открытого ключа) и сменит текущий активный сертификат (открытый ключ).
Признак временности сертификата («технологичный»), ограничивает права этого сертификата (открытого ключа) на подпись документов в системе "ДБО BS-Client". Таким сертификатом (открытым ключом) можно подписывать только те документы, для которых в
справочнике подписей под документами указана эта возможность.
Обычно этот признак используется для первично сгенерированных сертификатов (открытых
ключей), выданных клиенту банком вместе с дистрибутивом Системы. Такие сертификаты
(открытые ключи) подлежат обязательной перегенерации (смене) на клиенте после установки
у него системы "ДБО BS-Client".
9.2.2. Криптографический профиль (абонент)
Под криптографическим профилем в системе "ДБО BS-Client" подразумевается набор данных
соответствующий абоненту, владеющий секретным ключевым носителем и набором сертификатов (открытых ключей), необходимых для криптографических операций (подпись, проверка подписи, шифрация, дешифрация).
Данное понятие включает в себя:
•
название абонента (профиля);
•
тип криптографии: Excellence/4.0, LAN Crypto/2.35, Message-PRO 1.1, M-Pro v1.34 (GOST
PSE), M-Pro v2.x, Open SSL, CryptoPro CSP/1.1, Verba-OW/4, Crypto COM/2.2, Crypto-C,
Ms Crypto API 2.0, Агава-С;
•
признак: «запрещен» / «разрешен»;
•
список сертификатов (открытых ключей) и соответствующих им секретных ключей, принадлежащих абоненту.
При этом следует отметить, что хотя к профилю относится целый список сертификатов (открытых ключей), в конкретный момент активным является только один из них. Остальные
сертификаты (открытые ключи) отражают историю плановой смены сертификатов (открытых
ключей).
Выставление профилю признака «запрещен» равносильно его удалению. Профиль будет недоступен для любых криптографических операций.
9.2.3. Право подписи для документов системы
"ДБО BS-Client"
Под правом подписи в системе "ДБО BS-Client" понимается право подписи абонента (профиля) под документами "ДБО BS-Client". Различаются следующие права подписи:
•
единственная – при наличии такой подписи документ считается полностью подписанным;
•
первая – право первой подписи под документами;
42
Работа с криптографическими ключами и сертификатами
•
вторая – право второй подписи под документами;
•
расширенное – более тонкая настройка прав подписи. Задается право подписи в зависимости от организации, типа документа, его данных (с ограничениями по суммам), вплоть
до возможности вызова внешних модулей.
Понятие «право подписи» распространяется как для клиентов подсистемы «Банк-Клиент»
так и для клиентов подсистемы Интернет-Клиент.
Примечание
В системе "ДБО BS-Client" не регламентируется временная последовательность простановки
первой и второй подписей. Т.е. возможно как подписание документа первой подписью после
второй, так и второй после первой.
9.2.4. Право шифрации (связь по транспорту «БанкКлиент»)
Право шифрации дает абоненту возможность подписывать, проверять подпись под транспортными пакетами, а так же шифровать и дешифровать транспортные пакеты. Это право
применимо только для клиентов подсистемы толстого клиента «Банк-Клиент».
9.2.5. Право защиты канала («Интернет-Клиент»)
Право защиты канала дает абоненту возможность криптографической защиты интернет-канала «BS-Defender» и / или канала двустороннего SSL (TLS).
Это право применимо только для клиентов подсистемы Интернет-Клиент.
9.3. Менеджмент ключей. Права на
криптографические операции. Привязка к
пользователю
Архитектура подсистемы криптозащиты системы "ДБО BS-Client" позволяет гибко настраивать контекст использования ключей абонентов подсистемами "ДБО BS-Client" Банк-Клиент и Интернет-Клиент.
Подсистема криптозащиты позволяет использовать криптографический профиль (ключи абонента) не только для одного клиента, но и для нескольких клиентов одновременно. При этом
права на криптографические операции данного абонента у данного клиента задаются индивидуально. Все такие отношения задаются с помощью справочника рабочих мест абонентов
СКЗИ.
Для собственных абонентов СКЗИ в подсистеме Банк-Клиент с помощью справочника пользователей абонентов СКЗИ, задаются пользователи ДБО и абоненты СКЗИ, с которыми
он работает. Допустимо использование одного и того же абонента СКЗИ несколькими пользователями "ДБО BS-Client".
В подсистеме Интернет-Клиент, для пользователей используемые абоненты СКЗИ задаются
с помощью справочника абонентов СКЗИ для пользователей подсистемы Интернет-Кли43
Работа с криптографическими ключами и сертификатами
ент. При этом, допускается использование только тех абонентов СКЗИ, организации которых
указаны в справочнике организаций пользователей Интернет-Клиент.
Архитектурная схема системы криптозащиты приведена на следующем рисунке:
Рис. 9.1. Архитектурная схема системы криптозащиты
Для настройки криптографических прав абонентов СКЗИ, их привязки к клиентам "ДБО BSClient" (АРМ), пользователям подсистемы Интернет-Клиент, привязки к пользователям
системы "ДБО BS-Client" (подсистема Банк-Клиент) предусмотрены соответствующие мастера настроек («визарды»).
9.4. Начальное заведение ключей,
Технологический ключ
Для заведения нового абонента СКЗИ в системе "ДБО BS-Client" есть соответствующий мастер («визард»), который позволяет по существующему набору ключевого носителя и сертификата абонента, зарегистрировать его в системе "ДБО BS-Client". Этот мастер позволяет
последовательно задать все параметры нового абонента: название, привязку к клиентам системы "ДБО BS-Client" (АРМ) и их индивидуальные криптографические права и в случае
расширенных прав подписи — задать их для всех документов и для всех организаций привязанных клиентов, привязку к пользователям системы "ДБО BS-Client", параметры криптографического сертификата.
В случае отсутствия первоначального ключевого носителя и сертификата абонента, в "ДБО
BS-Client" также предусмотрена возможность первичной генерации секретного ключа и запроса на сертификат в ЦС. Следует отметить, что такая возможность существует не для всех
типов СКЗИ, так как не все производители стороннего ПО систем криптозащиты предоставляют соответствующий программный интерфейс.
При первичной регистрации клиентского абонента СКЗИ на банке рекомендуется выставить
его сертификату признак «технологичный». Такие сертификаты подлежат обязательной пе44
Работа с криптографическими ключами и сертификатами
регенерации на клиенте после установки у него системы "ДБО BS-Client". Этот признак
сертификата ограничивает его права на подпись документов "ДБО BS-Client". Таким сертификатом можно подписывать только те документы, для которых в справочнике подписей под
документами выставлен соответствующий признак. Таковым, по умолчанию, является документ "ДБО BS-Client" с запросом на новый сертификат.
Таким образом, клиент не сможет отправлять в банк финансовые документы до тех пор, пока
он не сформирует новый секретный ключевой носитель и сертификат. Такая процедура гарантирует клиенту полную защиту секретного ключевого носителя, т.к. он генерируется
непосредственно на рабочем месте пользователя и может быть известен только пользователю.
9.5. Перегенерация клиентского ключа (в
толстом и тонком клиенте)
Все средства криптографической защиты информации, используемые в "ДБО BSClient" (см. разд. 9.1 «Описание особенностей СКЗИ» [стр. 40]) основаны на ассиметричных
криптографических алгоритмах. Указанные алгоритмы используют т.н. «ключевые пары» –
набор из секретного и открытого ключа.
Секретный ключ (файл секретного ключа, либо ключ, записанный на специальный ключевой
носитель) является конфиденциальной информацией.
Примечание
Полное определение согласно закону об ЭЦП: закрытый ключ электронной цифровой подписи –
уникальная последовательность символов, известная владельцу сертификата ключа подписи и
предназначенная для создания в электронных документах электронной цифровой подписи с использованием средств электронной цифровой подписи.
Организацию защиты данного ключа от несанкционированного копирования должен обеспечивать владелец ключа. При выдаче набора ключей пользователю системы, последний
должен быть поставлен в известность относительно правил хранения секретных ключей и
недопустимости доступа третьих лиц к носителю секретного ключа.
Некоторые из СКЗИ обеспечивают дополнительную функцию защиты секретного ключа с
помощью мастер-ключа или пароля.
В этом случае все правила хранения секретного ключа распространяется на мастер-ключ, сам
секретный ключ в этом случае не требует специальной защиты и может быть расположен на
накопителях общего пользования. В случае защиты секретного ключа паролем необходимо
придерживаться тех же правил, что и при хранении ничем не защищенного ключа. Дело в
том, что пароль не обеспечивает должный уровень криптостойкости защищенных им данных.
Второй частью ключевой пары является открытый ключ. Как правило, в большинстве современных криптопровайдеров, открытый ключ распространяется в виде сертификата.
Сертификат представляет собой открытый ключ, заверенный цифровой подписью центра
сертификации (ЦС) – специального органа, в функции которого входит выдача сертификатов.
Примечание
Полное определение согласно закону об ЭЦП: сертификат ключа подписи – документ на бумажном носителе или электронный документ с электронной цифровой подписью уполномоченного
45
Работа с криптографическими ключами и сертификатами
лица удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой
подписи и которые выдаются удостоверяющим центром участнику информационной системы
для подтверждения подлинности электронной цифровой подписи и идентификации владельца
сертификата ключа подписи.
Открытый ключ не является конфиденциальной информацией и может распространяться по
открытым каналам связи, без дополнительной защиты.
Для выполнения различных операций криптографических преобразований используются
различные части ключевой пары.
Таблица 9.2. Использование криптографических ключей
Наименование операции
Используемые ключи
Формирование цифровой подписи Секретный ключ подписывающего
Проверка цифровой подписи
Открытый ключ (сертификат) подписавшего
Шифрование данных
Открытый ключ (сертификат) получателя шифрованных данных
Расшифровка данных
Секретный ключ получившего зашифрованные данные
Из представленной выше таблицы видно, что для реализации защиты информационного обмена между двумя абонентами каждый из них должен наряду со своим секретным ключом
иметь также открытый ключ (сертификат) своего абонента. Кроме этого, в случае использования сертификатов (открытых ключей, заверенных подписью ЦС) каждый из абонентов
должен располагать сертификатом ЦС для проверки действительности используемых сертификатов.
В связи с тем, что ключи имеют ограниченный период действия, а также могут быть скомпрометированы, в системе "ДБО BS-Client" предусмотрен набор специальных алгоритмов,
позволяющих без обрыва соединения осуществить плавный переход с одних криптографических ключей на другие.
9.5.1. Удаленная перегенерация ключей толстого и
тонкого клиента
Алгоритм смены клиентских ключей состоит из следующих основных этапов:
1.
2.
Клиент инициирует удаленную перегенерацию ключей через прикладной интерфейс
системы "ДБО BS-Client".
•
Клиент генерирует новые секретный ключ и открытый ключ (запрос на сертификат).
•
Открытый ключ (запрос на сертификат) помещается в специальную структуру, защищенную от искажения ЭЦП, выработанной на текущих ключах клиента.
•
Сформированная структура пересылается в банк.
На банковской стороне осуществляется проверка ЭЦП под полученной структурой, если
в структуре находится открытый ключ – переход на п. 4, если в структуре находится
запрос на сертификат – он передается в удостоверяющий центр для формирования сертификата.
46
Работа с криптографическими ключами и сертификатами
3.
На банковской стороне из удостоверяющего центра получен новый сертификат клиента,
сформированный на основе запроса на сертификат, полученного от клиента.
4.
На банковской стороне полученный открытый ключ (сертификат) включается в список
сертификатов, пригодных к использованию для соответствующего клиента.
5.
На банковской стороне открытый ключ (сертификат) помещается в специальную структуру, защищенную от искажения ЭЦП, выработанной на текущих ключах банка.
6.
Полученная на шаге 5 структура переправляется клиенту.
7.
Клиент, получив сформированную в банке структуру, проверяет ЭЦП банка под ней,
далее полученный в структуре открытый ключ / сертификат проверяется на соответствие
новому секретному ключу клиента. В случае их соответствия происходит замена рабочих
ключей клиента на новые.
8.
После завершения замены ключей клиент сообщает банку о завершении процедуры смены ключей. Для этого служит первый пришедший от клиента документ, подписанный
новыми ключами.
9.
На банковской стороне старый сертификат клиента исключается из списка сертификатов, пригодных для использования клиентом.
Для пользователя все указанные выше операции скрыты. В общем случае, для смены ключей
пользователю необходимо совершить только два действия:
1.
Инициализировать смену ключа (через прикладной интерфейс клиентского места);
2.
Завершить процедуру смены ключа, когда из банка придет новый сертификат клиента
(также через прикладной интерфейс).
Примечание
Подробное описание алгоритмов удаленной перегенерации выходит за рамки настоящего документа и подробно изложено в документе «Техническое задание на реализацию сервиса управления ключевой информацией в системе "ДБО BS-Client"».
9.6. Перегенерация банковского ключа
В предыдущем разделе дано краткое описание алгоритма удаленной перегенерации клиентских ключей. Но необходимость в смене ключей может возникнуть и у банковского администратора. В этом случае процесс смены ключей происходит иначе, чем для ключей клиента.
Смена ключей банковского администратора состоит из следующих основных этапов:
1.
Генерация новых банковских ключей.
2.
Рассылка нового банковского сертификата всем клиентам, связанным с банковским администратором, ключи которого подлежат замене.
3.
Смена текущих банковских ключей на новые.
Как и при смене клиентских ключей, новый открытый ключ банка высылается в специальной
структуре, заверенной подписью, выработанной на текущих ключах банковского админи47
Работа с криптографическими ключами и сертификатами
стратора. При использовании такого подхода пользователь застрахован от регистрации открытых ключей (сертификатов), произведенных третьими лицами.
9.7. Использование списков отозванных
сертификатов. Компрометация ключа
В предыдущих двух пунктах кратко описаны алгоритмы плановой смены клиентских и банковских ключей. Данные операции могут быть произведены без ущерба для стойкости
защиты только в том случае, если на период выполнения описанных процедур старый ключ
пригоден к использованию. Но при работе с криптографическими ключами также возможны
внештатные ситуации, в результате которых использование тех или иных ключей становится
недопустимым с точки зрения защиты информации.
Классическим примером такой ситуации является утеря пользователем своего секретного
ключа (вместе с носителем). В этом случае ключ считается скомпрометированным и непригодным к дальнейшему использованию.
В случае компрометации клиентского ключа, клиенту необходимо как можно раньше сообщить в банк об этом. Банковский администратор, сразу после поступления подобного заявления от клиента, должен заблокировать соответствующий сертификат на банковской
стороне (пометить его, как скомпрометированный (поставить признак «запрещен») в соответствующем криптопрофиле клиента).
После этого ключ клиента становится непригодным к использованию в рамках системы
"ДБО BS-Client". Это справедливо как для криптографий с открытыми ключами, так и для
криптографий, использующих сертификаты. Отсутствие отличий между этими двумя видами
криптографий объясняется схемой передачи данных между клиентской и банковской частью
"ДБО BS-Client". Дело в том, что прямую связь между клиентами с помощью рабочих мест
"ДБО BS-Client" установить невозможно. В любом случае, данные пересылаются через банковскую часть, на которой происходит контроль ЭЦП клиента.
Таким образом, в случае исключения скомпрометированного открытого ключа (сертификата)
из списка допустимых к использованию клиентских ключей, в момент приема информации
банковской стороной, она будет забракована, как подписанная недопустимыми для использования ключами.
После блокирования скомпрометированных ключей на банковской стороне необходимо сгенерировать новый комплект ключей для клиента и зарегистрировать их на банковской
стороне, как допустимые к использованию данным клиентом. После этого новый комплект
ключей необходимо выдать клиенту.
Т.к. комплект содержит обе части ключевой пары (открытый и секретный ключ) пересылка
комплекта по открытым каналам связи не допускается. Новый комплект должен быть выдан
клиенту в банке лично, с выполнением всех необходимых формальностей, определенных
службой безопасности банка. После получения нового комплекта клиент получит возможность воспользоваться описанным выше механизмом перегенерации ключей для смены
ключей, полученных в банке на сгенерированные самостоятельно.
48
Работа с криптографическими ключами и сертификатами
9.8. Использование списков отозванных
сертификатов (СОС)
Списки отозванных сертификатов (СОС, CRL), применяются в СКЗИ, использующих сертификаты. Данные списки формируются на уровне центров сертификации (ЦС) и служат для
блокирования скомпрометированных по тем или иным причинам сертификатов, срок действия которых еще не истек.
При проверке действительности сертификата (такая операция производится каждый раз при
проверке ЭЦП, и при шифровании), при наличии актуального на момент проверки СОС, осуществляется поиск сертификата в СОС. В случае обнаружения проверяемого сертификата в
СОС, сертификат признается недействительным.
Как было отмечено ранее в системе "ДБО BS-Client" для блокирования клиентского сертификата в рамках системы "ДБО BS-Client" нет необходимости обязательно оповещать об этом
всех клиентов. Достаточно заблокировать скомпрометированный клиентский сертификат на
стороне банка. Для выполнения указанной блокировки можно воспользоваться механизмом,
предоставляемым СОС. Для блокирования сертификатов, включенных в СОС, при каждом
выпуске СОС в удостоверяющем центре, необходимо обновить используемый список для
всех банковских ключей.
9.9. Использование USB-токенов
Для безопасного хранения ключевой информации в системе "ДБО BS-Client" могут быть использованы USB-токены: eToken и Rutoken. Недопустимо одновременное использование
токенов различного типа.
Для обеспечения поддержки использования токенов необходимо выполнить настройку банковской части системы (см. разд. 4.7.2.6 «Использование USB-токенов для хранения ключевой информации» док. Полное руководство пользователя).
Для большинства токенов возможность их использования пользователями клиентской части
системы доступна после установки соответствующих драйверов. Перечень СКЗИ и драйвера,
необходимые для работы с USB-токенами, отражены в разд. A.1.1 «Общий перечень поддерживаемого ПО» док. Инструкция по установке и начальной настройке системы.
49
Глава 10. Конфликтные ситуации
и способы их решения
10.1. Общие положения, типы
конфликтных ситуаций
В системах документооборота, в частности в системе "ДБО BS-Client", возможны два класса
конфликтных ситуаций, связанных с подлинностью электронных документов (ЭД):
1.
Отказ Стороны от ЭД (Сторона утверждает, что ее абонент не подписывал принятый
другой Стороной ЭД, другая Сторона утверждает обратное).
2.
Отказ Стороны от факта получения ЭД (Сторона утверждает, что посланный ею ЭД был
принят другой Стороной, другая Сторона это отрицает).
Таким образом, в системе Банк-клиент могут возникнуть 4 конфликтных ситуации:
•
отказ банка от ЭД;
•
отказ клиента от ЭД;
•
отказ банка от факта получения ЭД;
•
отказ клиента от факта получения ЭД.
Наибольший интерес представляют ситуации «Отказ клиента от ЭД» и «Отказ банка от факта
получения ЭД» т.к. финансовые ЭД требующие исполнения пересылаются от клиента в банк,
но не наоборот.
Более подробно данные конфликтные ситуации и способы их разбора рассмотрены далее.
Обычно предполагается, что сторона-инициатор рассмотрения конфликтной ситуации должна подготовить и направить другой Стороне документ (заявление), подписанный уполномоченным должностным лицом, с изложением обстоятельств случившегося. После этого
должна быть сформирована комиссия по разбору конфликтной ситуации (подробности формирования такой комиссии и регламент ее работы определяется, как правило, юристами банка
и включаются в договора с клиентами банка).
До подачи заявления Заявителю рекомендуется убедиться в неизменности используемой
ключевой информации, а также отсутствии несанкционированных действий со стороны персонала, обслуживающего систему (например, используя анализ журналов работы или механизм аудита действий пользователей).
50
Конфликтные ситуации и способы их решения
10.2. Разбор конфликтов в случае
«толстого клиента»
В системе предусмотрен штатный функционал для осуществления действий по разбору конфликтных ситуаций (подробное описание приведено в разд. 4.11 «Разбор конфликтных
ситуаций» док. Полное руководство пользователя).
В случае необходимости выполнения разбора конфликтной ситуации выполняется:
•
Определение всех транспортных пакетов, в которых передавалась информация по ЭД и
его квиткам.
•
Проверка ЭЦП всех указанных пакетов.
•
Формирование информации для визуального отображения документа и квитков документа в виде отдельных документов специального вида.
•
Выгрузка всех указанных пакетов, а также самого ЭД в виде отдельных файлов.
•
Выгрузка ЭЦП всех указанных пакетов и ЭД в виде отдельных файлов.
На основании выгруженных пар файлов (пакет + ЭЦП пакета) может быть выполнен анализ
подлинности ЭЦП пакетов, содержащих документ и его квитки в сторонних системах СКЗИ.
Пример регламента разбора конфликтных ситуаций, приведен в Приложение B.
10.3. Разбор конфликтов в «BS-Defender»
Для возможности решения конфликтных ситуаций между банком и пользователем подсистемы Интернет-Клиент, работающим через «BS-Defender» предусмотрен штатный механизм разбора конфликтных ситуаций.
При работе через «BS-Defender» вся информация, которой обмениваются банк и клиент передается в подписанном и зашифрованном виде. При включении соответствующих настроек
весь переданный трафик записывается в специальные журналы. При этом данные в журналах
сохраняются в зашифрованном виде и с теми подписями, которые были при передаче.
При возникновении конфликтной ситуации между банком и клиентом должна быть создана
комиссия по разбору конфликтной ситуации. Эта комиссия получает от клиента и банка соответствующие журналы, содержащие переданную информацию.
Далее при помощи криптографических ключей, использовавшихся на момент создания конфликтного документа, журналы расшифровываются, после чего проверяется подпись под
переданными данными.
После подтверждения аутентичности переданной информации производится анализ содержимого журнала. Информация о переданных документах или показанных выписках хранится
в журнале в виде XML-сообщений. Используя форматы передачи данных (могут быть запрошены у разработчиков Системы), производится поиск конфликтного документа или
выписки и проверяется его содержимое.
51
Конфликтные ситуации и способы их решения
10.4. Разбор конфликтов в одностороннем
и двустороннем SSL (сохраняемые подписи
под документами)
Подсистема Интернет-Клиент имеет встроенный механизм, позволяющий в интерфейсе
клиента осуществить получение клиентом заверенной ЭЦП банка информации, подтверждающей действия банка в отношении его документов (прием, исполнение). Также в интерфейсе клиента реализована возможность проверки подлинности полученной информации.
Информация (далее «Квитанция») предоставляется клиенту для отдельного выбранного клиентом документа по запросу клиента. Информация предоставляться только для документов,
отображающихся клиенту со статусами «Принят» и «Исполнен».
Предоставляемая клиенту информация включает в себя:
•
Отображение выбранного документа в виде обычной (для документа данного типа) печатной формы с добавлением информации о дате и времени формирования квитанции,
статусе документа, даты и времени получения статуса, реквизитах ответственного исполнителя банка, реквизитах ЭЦП банка и самой ЭЦП в шестнадцатеричном коде с возможностью вывода отображенных данных на печать.
•
Массив данных, включающих в себя пересылаемые поля выбранного документа, а также
информацию о статусе документа, даты и времени получения статуса, реквизитах ответственного исполнителя банка и реквизитах ЭЦП банка, которой подписана данный массив
данных. Массив формируется как набор полей записи БД, аналогично процессу формирования массива данных входящих в ССД ЭЦП для подписания значимых полей документа. Клиенту предоставляется возможность сохранить указанный массив данных в виде
файла (далее — «Квиток»).
•
ЭЦП указанного массива данных. В случае если клиент сохраняет массив данных в виде
файла ЭЦП, то он сохраняется в виде файла автоматически (далее — «ЭЦП квитка»).
Предоставляемая квитанция из банка не может быть просмотрена клиентом в виде документа.
Клиент может получить по одному документу несколько квитанций (каждый раз формируется новая квитанция).
Клиенту предоставляется возможность проверки подлинности полученной информации (т.е.
ранее полученной квитанции) для отдельного выбранного клиентом документа по запросу
клиента. Проверка выполняться только для документов, отображающихся клиенту со статусами «Принят» и «Исполнен».
Разбор конфликтных ситуаций, требующих предоставление клиентом квитанций банка производиться комиссией по разбору в следующем порядке:
•
выполняется проверка соответствия предоставленной клиентом ЭЦП квитка — квитку,
предоставленному клиентом;
•
разбор данных, содержащихся в квитке для восстановления значений в полях документа.
52
Конфликтные ситуации и способы их решения
Примечание
Следует иметь в виду, что информация в квитке содержит часть информации не в виде подлежащего прочтению текста, а в виде бинарных данных (поля типа Integer, LongString, BLOBtable
и т.п.).
10.5. Разбор конфликтов в Телефонклиенте
В процессе функционирования подсистемы Телефон-Клиент могут возникнуть конфликтные
ситуации, требующие детального разбора. В системе для этого ведется пошаговое протоколирование действий пользователя и работы системы в целом, при этом информация классифицируется по каналу и календарной дате. В добавок к этому используется штатный для
комплекса "ДБО BS-Client" механизм протоколирования (ошибки, трассировка, и др.,
см. табл. 7.3 «Системные журналы подсистемы Телефон-Клиент»).
Однако протоколирования в рамках комплекса "ДБО BS-Client" недостаточно для представления полной картины событий. Необходимо также выполнять пошаговый сбор информации о работе пограничных с комплексом систем (в нашем случае протоколирование и
хранение данных о работе АТС в отношении абонентских номеров, закрепленных за комплексом или использующихся при его работе).
53
Глава 11. Соответствие системы
"ДБО BS-Client" стандартам ЦБР
26 января 2006 года распоряжением ЦБР № Р-27 принят и введен в действие Стандарт ЦБР
СТО БР-1.0-2006 «Обеспечение информационной безопасности организаций банковской системы Российской федерации. Общие положения» (далее – СТАНДАРТ).
СТАНДАРТ распространяется на организации банковской системы Российской Федерации
и устанавливает положения (политики, требования и т.п.) по обеспечению информационной
безопасности в организациях БС РФ.
Данный СТАНДАРТ рекомендован для применения путем включения ссылок на него и использования устанавливаемых в нем положений во внутренних нормативных и методических
документах организаций БС РФ, а также в договорах.
Положения СТАНДАРТА применяются на добровольной основе, если только в отношении
конкретных положений обязательность не установлена действующим законодательством
Российской Федерации, нормативным правовым актом Банка России или условиями договора.
Основные цели стандартизации по обеспечению ИБ организаций БС РФ:
•
повышение доверия к БС РФ;
•
повышение стабильности функционирования организаций БС РФ и на этой основе – стабильности функционирования БС РФ в целом;
•
достижение адекватности мер по защите от реальных угроз ИБ;
•
предотвращение и / или снижение ущерба от инцидентов ИБ.
Основной идеей СТАНДАРТА информационной безопасности является противоборство банка (в лице службы информационной безопасности, или IT-департамента, или службы контроля бизнес процессов) и злоумышленника за контроль над информацией, хранящейся в
информационных сетях банка или передаваемой по ним. Кроме того, СТАНДАРТ охватывает
еще некоторые незлоумышленные действия, которые тоже могут создать инцидент в сфере
информационной безопасности.
В таблице табл. 11.1 «Соответствие пунктов СТАНДАРТА разделам документа» представлено соответствие пунктов СТАНДАРТА разделам настоящего документа.
Таблица 11.1. Соответствие пунктов СТАНДАРТА разделам документа
Пункты стандарта
Пункты документа
8.2.3.7.
Все пункты документа
6.2.3., 8.2.1.3., 8.2.2.3.
7.2.
8.2.1.3.
7.1., 8.2.
8.2.4.2.
10.1.
54
Соответствие системы "ДБО BS-Client" стандартам ЦБР
Пункты стандарта
Пункты документа
8.2.6.
5, 8.2., 11.3, 11.4.
8.2.7.
4.2., 9, 10.
8.2.7.4.
7.4., 7.5.
8.2.8.10.
7.1., 7.2., 8, 9.
55
Глава 12. Список рекомендуемой
литературы
1.
Стандарт ЦБР СТО БР-1.0-2006 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения» (принят и введен
в действие 26 января 2006 г. распоряжением ЦБР № Р-27).
2.
Федеральный закон от 20 февраля 1995г № 24-Ф3 . «Об информации, информатизации
и защите информации».
3.
Федеральный закон от 10 января 2002 г. N 1-ФЗ «Об электронной цифровой подписи».
4.
ГОСТ Р ИСО/МЭК 15408-1-2002. Информационная технология. Методы и средства
обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. -- М.: ИПК Издательство стандартов, 2002.
5.
ГОСТ Р ИСО/МЭК 15408-2-2002. Информационная технология. Методы и средства
обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. -- М.: ИПК Издательство
стандартов, 2002.
6.
ГОСТ Р ИСО/МЭК 15408-3-2002. Информационная технология. Методы и средства
обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности. -- М.: ИПК Издательство стандартов,
2002.
7.
ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.
8.
RFC 2246 The TLS Protocol Version 1.0.
9.
Основы защиты сетей. Приложения и стандарты. М.: Вильямс, 2002.
56
Приложение A.
Криптографические
справочники, используемые в
системе "ДБО BS-Client"
A.1. Справочник количества подписей в
документах (CryptoNumOfSigns)
В этом справочнике для каждого типа документа и для каждого клиента системы "ДБО BSClient" задается количество подписей, требуемое под данным документом от данного клиента
и допустимость подписи данного документа технологическим сертификатом. В системе
предполагается по умолчанию возможность подписи технологическим сертификатом только
документов с запросом клиентов на новый сертификат. В справочнике также возможно указывать количество подписей сразу для всех типов документов и / или для всех клиентов. При
этом если есть запись по конкретному типу документа, то она имеет больший приоритет, чем
по всем документам. В случае если еще есть и запись по конкретному клиенту, то она имеет
больший приоритет. Если же записей для документа и клиента нет, то по умолчанию считается, что требуется одна подпись рабочим (не технологическим) сертификатом.
A.2. Справочник сертификатов (CryptoUID)
Этот справочник содержит список всех криптографических сертификатов.
A.3. Справочник криптографических
профилей (CryptoProfile)
Этот справочник содержит список всех абонентов СКЗИ, и связанный с ним справочник сертификатов.
A.4. Справочник рабочих мест абонентов
СКЗИ (CryptoWorkPlace)
В этом справочнике задаются криптографические права абонентов для разных клиентов:
право подписи, право шифрации, право защиты канала. При этом допустимо использование
одного и того же абонента для разных клиентов, с индивидуальными правами.
A.5. Справочник пользователей абонентов
СКЗИ (CryptoLogin)
В этом справочнике задаются пользователи системы "ДБО BS-Client" и абоненты СКЗИ, с
которыми он работает. Допустимо использование одного и того же абонента СКЗИ несколь57
Криптографические справочники, используемые в системе "ДБО BS-Client"
кими пользователями "ДБО BS-Client". Этот справочник используется только в подсистеме
«Банк-Клиент», и содержит записи только для «собственных» пользователей и абонентов
СКЗИ.
A.6. Справочник абонентов СКЗИ для
пользователей подсистемы ИнтернетКлиент (RemoteCryptoProfile)
Справочник содержит список абонентов СКЗИ. для каждого пользователя подсистемы Интернет-Клиент.
A.7. Общие справочники
A.7.1. Справочник клиентов (PostClnt)
Этот справочник содержит информацию обо всех клиентах — удаленных АРМ, работающих
в системе "ДБО BS-Client".
A.7.2. Справочник организаций (Customer)
Справочник содержит для каждого клиента системы "ДБО BS-Client" (АРМ) все его организации.
A.7.3. Справочник пользователей подсистемы
Интернет-Клиент
Справочник содержит данные всех пользователей подсистемы Интернет-Клиент. В нем задается имя пользователя, его логин, тип защиты канала (отсутствует / односторонний SSL /
двусторонний SSL / «BS-Defender»), язык и др.
A.7.4. Справочник организаций пользователей
Интернет-Клиент (RemoteIDS)
В справочнике содержится информация обо всех организациях, с которыми работает пользователь подсистемы Интернет-Клиент. Допустимо использование одной и той же организации несколькими пользователями.
58
Приложение B. Пример
регламента разбора
конфликтных ситуаций в системе
"ДБО BS-Client"
B.1. 1. Общий порядок разбора
конфликтной ситуации
Разбор конфликтов на клиентском месте системы "ДБО BS-Client" осуществляется при разборе следующих ситуаций:
•
Отказ клиента от факта отправки документа в банк. Банк должен предъявить электронный
документ, подписанный ЭЦП клиента.
•
Отказ клиента от соответствия исполненного банком документа документу составленному и отправленному в банк клиентом. Банк должен предъявить электронный документ,
подписанный ЭЦП клиента.
•
Отказа клиента от получения документа из банка. Банк должен предъявить электронный
документ, отправленный им клиенту и имеющий квитанцию (квиток) о получении документа. Транспортные пакеты, содержащие квиток, должны быть подписаны ЭЦП клиента.
Разбор конфликтов на банковском месте системы "ДБО BS-Client" осуществляется при разборе следующих ситуаций:
•
Отказа банка от получения документа от клиента. Клиент должен предъявить электронный документ, отправленный им банку и имеющий квитанцию (квиток) о получении
банком данного документа. Транспортные пакеты, содержащие квиток, должны быть
подписаны ЭЦП банка.
•
Отказ банка от выполнения над документом действия, которое клиент считает банком
выполненным. Клиент должен предъявить электронный документ, отправленный им банку и имеющий квитанцию (квиток) о совершении банком указанного действия. Транспортные пакеты, содержащие квиток, должны быть подписаны ЭЦП банка.
•
Отказ банка от соответствия полученного клиентом документа документу составленному
и отправленному клиенту банком. Клиент должен предъявить электронный документ,
подписанный ЭЦП банка.
В случае необходимости производится исследование истории создания, пересылки и обработки конфликтного документа.
В случае необходимости выполняется экспертиза ЭЦП конфликтного документа.
59
Пример регламента разбора конфликтных ситуаций в системе "ДБО BS-Client"
Сторонам рекомендуется предоставить также несколько контрольных неконфликтных документов, подписанных теми же ЭЦП, что и конфликтный документ, созданных и исполненных
в те же даты, что и конфликтный документ.
B.2. 2. Действия по общему анализу
конфликтного документа
1.
2.
Общий анализ конфликтного документа производится с целью:
•
Установления соответствия предъявляемых сторонами копий документа на бумажных носителях и электронных документов, содержащихся в системе.
•
Установления точности иных претензий по части содержания конфликтного документа, выдвигаемых сторонами, и электронных документов, содержащихся в системе.
И на АРМ клиента "ДБО BS-Client", и на клиентском месте Сервера ДБО общий анализ
конфликтного документа должен производиться в следующем порядке:
•
Анализируется содержимое документа, отображаемое в визуальной форме документа. Отмечаются расхождения в содержании полей предъявляемого документа (или в
содержании материалов, явившихся причиной создания комиссии) и электронного
документа, отображаемого в визуальной форме. Отклонение в формате отображения
дат, сумм, наименованиях полей не являются существенными, если они не изменяют
смыслового значения документа и не изменяют значения юридически значимых полей. Несущественные отклонения могут не фиксироваться по решению комиссии.
•
В случае необходимости выполняется печать электронного документа. Отмечаются
расхождения в содержании полей предъявляемого документа и электронного документа, отображаемого в визуальной форме. Отклонение в формате отображения дат,
сумм, наименованиях полей не являются существенными, если они не изменяют
смыслового значения документа и не изменяют значения юридически значимых полей. Несущественные отклонения могут не фиксироваться по решению комиссии.
B.3. 3. Разбор конфликта вида «Отказ
любой из сторон от ЭЦП под созданным
этой стороной документом»
1.
Сторона, отказывающаяся от ЭЦП под созданным этой стороной документом, является
Ответчиком. Сторона, настаивающая на признании ЭЦП — Истцом.
2.
В обязательном порядке на рабочем месте Истца выполняется общий анализ конфликтного документа (см. п.2.). На рабочем месте Ответчика общий анализ документа может
не производиться.
a.
В случае если Истец не может предъявить электронный документ для проведения
общего анализа комиссия должна признать правоту Ответчика (конфликт решается
в пользу Ответчика), так как следует считать, что Истец не смог предъявить документ, соответствующий своему иску.
60
Пример регламента разбора конфликтных ситуаций в системе "ДБО BS-Client"
3.
b.
В случае если электронный документ, предъявляемый Истцом, не соответствует
(имеет существенные отличия) от предъявляемой Истцом бумажной копии документа или от данных, изложенных Истцом в материалах, явившихся причиной
создания комиссии, комиссия должна признать правоту Ответчика (конфликт решается в пользу Ответчика). Исследование ЭЦП Ответчика не производится, так
как следует считать, что Истец не смог предъявить документ, соответствующий
своему иску.
c.
В случае если электронный документ, предъявляемый Истцом, соответствует (не
имеет существенных отличий) от предъявляемой Истцом бумажной копии документа или от данных, изложенных Истцом в материалах, явившихся причиной
создания комиссии, производится анализ ЭЦП Ответчика.
Для выполнения анализа ЭЦП Ответчика на клиентском месте Истца выполняется процедура экспертизы ЭЦП. Экспертиза выполнятся в следующем порядке:
•
Конфликтный документ выбирается в скроллере документов.
•
, имеющаяся в визуальной форме скроллера, выАктивируется штатная кнопка
зывающая визуальную форму выбора действия.
•
В указанной выше визуальной форме выбирается пункт «Разбор конфликтной ситуации».
•
В появившейся визуальной форме «Разбор конфликтных ситуаций» отображены
транспортные пакеты, относящиеся к документу. Необходимо найти пакет, содержащий в себе документ и задействовать кнопку «выгрузка документа для проверки
подписи».
•
Соответствие выгруженных данных документа и ЭЦП под документом может быть
проверено в сторонних программных модулях (АРМ-ах разбора конфликтных ситуаций), поставляемых разработчиками СКЗИ.
1.
В случае если экспертиза устанавливает подлинность всех ЭЦП Ответчика, комиссия должна признать правоту Истца (конфликт решается в пользу Истца).
2.
В противном случае комиссия должна признать правоту Ответчика (конфликт
решается в пользу Ответчика).
B.4. Разбор конфликта вида «Отказ любой
из сторон от сформированной ею
квитанции на документ»
1.
Сторона, отказывающаяся от сформированной ею квитанции документ, является Ответчиком. Сторона, настаивающая на существовании квитанции — Истцом.
2.
В обязательном порядке на рабочем месте Истца выполняется общий анализ конфликтного документа (см. п.2.). На рабочем месте Ответчика общий анализ документа может
не производиться.
61
Пример регламента разбора конфликтных ситуаций в системе "ДБО BS-Client"
a.
В случае если Истец не может предъявить электронный документ для проведения
общего анализа, комиссия должна признать правоту Ответчика (конфликт решается
в пользу Ответчика), так как следует считать, что Истец не смог предъявить документ, соответствующий своему иску.
b.
В случае если электронный документ, предъявляемый Истцом, не соответствует
(имеет существенные отличия) от предъявляемой Истцом бумажной копии документа или от данных, изложенных Истцом в материалах, явившихся причиной
создания комиссии, комиссия должна признать правоту Ответчика (конфликт решается в пользу Ответчика). Исследование ЭЦП Ответчика не производится, так
как следует считать, что Истец не смог предъявить документ, соответствующий
своему иску.
c.
В случае если электронный документ, предъявляемый Истцом, соответствует (не
имеет существенных отличий) от предъявляемой Истцом бумажной копии документа или от данных, изложенных Истцом в материалах, явившихся причиной
конфликта, производится экспертиза ЭЦП Истца. Исследование производится в порядке, изложенном в п.3.). В случае если экспертиза не устанавливает подлинность
всех ЭЦП Истца комиссия должна признать правоту Ответчика (конфликт решается
в пользу Ответчика), так как следует считать, что Истец не смог предъявить документ, соответствующий своему иску.
3.
В случае если электронный документ, предъявляемый Истцом, соответствует (не имеет
существенных отличий) от предъявляемой Истцом бумажной копии документа или от
данных, изложенных Истцом в материалах, явившихся причиной конфликта, производится анализ конфликтной квитанции (квитка), полученной от Ответчика к исследованному документу.
4.
Экспертиза ЭЦП Ответчика, которой подписана квитанция, выполняемая в следующем
порядке:
•
Конфликтный документ выбирается в скроллере документов.
•
Активируется штатная кнопка
, имеющаяся в визуальной форме скроллера,
вызывающая визуальную форму выбора действия.
•
В указанной визуальной форме выбирается пункт «Разбор конфликтной ситуации»,
взывающий скроллер квитанций, относящихся к документу.
•
В появившейся визуальной форме «Разбор конфликтных ситуаций» отображены
транспортные пакеты, относящиеся к документу. Необходимо найти пакет, содержащий в себе квитанцию на документ и задействовать кнопку «выгрузка пакета для
проверки подписи».
•
Соответствие выгруженных данных пакета (а значит и квитанций на документ) и
ЭЦП под пакетом может быть проверено в сторонних программных модулях (АРМах разбора конфликтных ситуаций), поставляемых разработчиками СКЗИ.
a.
В случае если экспертиза устанавливает подлинность всех ЭЦП Ответчика, которыми подписана квитанция, комиссия должна признать правоту Истца (конфликт решается в пользу Истца).
62
Пример регламента разбора конфликтных ситуаций в системе "ДБО BS-Client"
b.
В противном случае комиссия должна признать правоту Ответчика (конфликт
решается в пользу Ответчика).
63
Приложение C. Схема
компонентов системы "ДБО BSClient"
Ниже отображена схема взаимодействия компонентов системы "ДБО BS-Client":
Рис. C.1. Схема компонентов системы "ДБО BS-Client"
64