Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка



    Рис. 1.

    О чем исследование
    Ссылки на другие части исследования


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

    Disclaimer
    Статья не содержит конфиденциальной информации. Все использованные материалы публично доступны в Интернете, в том числе на сайте Банка России.

    Глава 1. Общее описание ИТ-инфраструктуры


    Основные термины


    В 90-x годах прошлого века в ГОСТах и нормативных документах ФСТЭК России (тогда еще Гостехкомиссии при Президенте РФ) часто употреблялся термин — автоматизированная система. «ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» дает следующее определение данного термина:
    автоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

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

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

    Справедливость подобного подхода можно доказать тем, что в Приказе ФСТЭК России от 11.02.2013 N 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» для защиты информационных систем госрегулятор предписывает руководствоваться ГОСТами по автоматизированным системам.

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

    Дать определение понятию информационный сервис довольно сложно, поэтому просто перечислим его основные отличия от информационной системы:

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

    Автоматизированная банковская система


    Ядром информационной инфраструктуры любого банка является автоматизированная банковская система или сокращенно АБС.

    Стандарт Банка России СТО БР ИББС-1.0-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения» определяет АБС следующим образом:
    автоматизированная система, реализующая банковский технологический процесс.

    Данное определение позволяет подвести под него практически любую IT-систему в банке. В то же время обычные банковские служащие называют АБС ту систему, которая занимается учетом банковских счетов, проводок между ними (движением денежных средств) и остатков. Второе определение не противоречит первому и более четко его детализирует, им и будем пользоваться дальше.

    В современных Российских банках наиболее распространенными являются следующие АБС :


    Некоторые, особо большие банки используют не тиражные, а специально разработанные под них АБС. Но подобные случаи единичны, собственно как и особо большие банки.

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

    Прикладные информационные системы


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

    Примерами прикладных информационных систем могут быть:


    • системы дистанционного банковского обслуживания Интернет Клиент-Банк (ДБО ИКБ, например, iBank2, BS-Client, InterBank),
    • процессинг платежных карт (например, TranzWare, SmartVista, Way4),
    • системы автоматизации контакт-центров (например, Avaya Call Center, Cisco Unified Contact Center),
    • системы автоматического скоринга заемщиков (например, FICO),
    • и др.

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

    Инфраструктурные информационные системы


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

    • служба каталогов Active Directory,
    • служба доменных имен (DNS),
    • корпоративная электронная почта,
    • службы предоставления доступа работников в Интернет;
    • системы контроля и управления доступом (СКУД) в помещения;
    • IP-видеонаблюдение;
    • IP-телефония;
    • и многое другое.

    Информационные сервисы


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

    Клиентские части сторонних информационных систем


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

    • модули интеграции с государственными информационными системами: ГИС ГМП, ГИС ЖКХ;
    • клиентские части внешних платежных систем;
    • биржевые торговые терминалы;
    • и так далее.

    Типовые способы интеграции информационных систем


    Для интеграции информационных систем обычно применяются следующие механизмы:

    1. Интеграция через API (например, Web-сервисы).
    2. Интеграция через СУБД:
      • путем предоставления доступа только к хранимым процедурам;
      • путем предоставления доступа к хранимым процедурам и таблицам баз данных.
    3. Файловый обмен:
      • через компьютерную сеть;
      • через отчуждаемые машинные носители информации (ОМНИ, например – флешки).
    4. Реализация сервис ориентированной архитектуры (SoA).

    Модули интеграции


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

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

    Пример ИТ-инфраструктуры банка


    На Рис.1 можно увидеть фрагмент типовой информационной инфраструктуры банка, содержащий рассмотренные выше типы элементов.

    Глава 2. Инфраструктура безналичных расчетов


    Если посмотреть на эту схему (Рис.1) с точки зрения осуществления безналичных расчетов, то можно увидеть, что банк реализует их при помощи:

    • прямых корреспондентских отношений с банком-партнером,
    • международной платежной системы (МПС) (например, VISA, MasterCard).
    • корреспондентских отношений с Банком России.

    Технически прямые корреспондентские отношения с банками-партнерами могут быть организованы с помощью:

    • обычных систем ДБО ИКБ, применяемых банками для обслуживания юридических лиц (в рассматриваемом примере (Рис.1) используется именно этот способ);
    • межбанковских платежных систем (например, SWIFT);
    • специализированных систем обмена платежными сообщениями (например, REX400, TELEX);
    • специализированного ПО, разработанного одним из взаимодействующих банков.

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

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

    Инфраструктура обеспечения платежного взаимодействия с Банком России




    Рис. 2.
    IT-инфраструктуру платежного взаимодействия банка с Банком России будем рассматривать на примере исполнения платежа, отправляемого в адрес клиента другого банка.

    Как мы помним из первой части, вначале клиент должен передать в банк платежное поручение. Сделать это он может двумя способами:

    1. Явиться лично в отделение банка и передать заверенное платежное распоряжение на бумажном носителе.
    2. Направить платежное распоряжение через систему ДБО ИКБ.

    Тут важно отметить, что системы ДБО ИКБ — это лишь системы, обеспечивающие юридически значимый электронный документооборот между клиентом и банком, самостоятельно они платежи не проводят. Именно поэтому, когда клиент открывает расчетный счет в банке, он обычно заключает два договора. Первый – договор обслуживания банковского счета, второй – договор на осуществление электронного документооборота с помощью системы ДБО ИКБ. Если второй договор заключен не будет, то клиент все равно сможет пользоваться своим счетом, но только при личном визите в отделение банка.

    Если клиент передал платежное поручение на бумажном носителе, то работник банка на его основании делает электронное платежное поручение в АБС. Если распоряжение было подано через ДБО ИКБ, то через модуль интеграции оно попадает в АБС автоматически.

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

    Обычно для заверения электронных документов клиентов — юридических лиц в ДБО ИКБ применяют криптографическую электронную подпись, а для документов клиентов — физических лиц коды SMS-подтверждений. С юридической точки зрения для заверения электронных документов в обоих случаях банки обычно применяют правовой режим аналога собственноручной подписи (АСП).

    Попав в АБС, платежное поручение в соответствии с внутренними регламентами банка проходит контроль и передается для исполнения в платежную систему Банка России.

    Технические средства взаимодействия с платежной системой Банка России


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

    Для банков, обслуживаемых в Московском регионе, применяется следующее ПО:

    • АРМ КБР – автоматизированное рабочее место клиента Банка России;
    • УТА – специальное программное обеспечение файлового взаимодействия клиента Банка России (универсальный транспортный адаптер);
    • СКАД Сигнатура — средство криптографической защиты информации (СКЗИ) «Аппаратно-программный комплекс Сигнатура-клиент» версия 5, сертификаты ФСБ России – СФ/114-2680 (уровень криптозащиты КС1), для уровня криптозащиты КС2 – СФ/124-2681 (уровень криптозащиты КС2). СКАД расшифровывается как система криптографической аутентификации документов.

    АРМ КБР


    АРМ КБР – это ПО, с помощью которого уполномоченные работники банка осуществляют шифрование и электронную подпись исходящих платежных документов, а также расшифровку и проверку электронной подписи платежных документов, поступающих из Банка России. Но, если быть более точным, то АРМ КБР в своей работе оперирует не платежными документами, а электронными сообщениями (ЭС), которые бывают двух типов:

    • электронные платежные сообщения (ЭПС), например, ED101 «Платежное поручение»;
    • электронные служебно-информационные сообщения (ЭСИС), например, ED201 «Извещение о результатах контроля ЭС».

    Перечень и форматы электронных сообщений устанавливает Банк России, путем выпуска Альбома унифицированных форматов электронных банковских сообщений (УФЭБС).

    Для того чтобы АРМ КБР мог обработать платеж, он должен быть преобразован в файл, содержащий электронное платежное сообщение формата УФЭБС. За подобное преобразование отвечает модуль интеграции АБС с платежной системой Банка России. С технической точки зрения подобные преобразования довольно просты, поскольку формат УФЭБС основан на XML.

    Файлы электронных сообщений покидают модуль интеграции АБС в открытом виде и помещаются в специальную папку файловой системы (обычно это сетевая папка), которая настроена в АРМ КБР для электронных сообщений, имеющих статус «Введенные». На ранее представленной схеме (Рис. 2.) эта папка обозначена как «Папка 1».

    Затем в процессе обработки электронные сообщения меняют свои статусы на «Контролируемые», «Отправленные» и т. д., что технически реализуется путем перемещения файла с электронным сообщением в соответствующие папки, которые настроены в АРМ КБР. На схеме (Рис. 2.) эти папки обозначены как «Папка 2».

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

    СКАД Сигнатура


    СКАД Сигнатура, это СКЗИ, разработанное компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ нет в открытом доступе (кроме документации, размещенной на сайте ЦБ РФ), и оно распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:

    1. Данное СКЗИ, в отличии от других распространенных в деловых кругах России СКЗИ (например, как Крипто-ПРО CSP, VIPNET CSP и др.), реализует собственную, изолированную от операционной системы инфраструктуру открытых ключей (PKI). Это проявляется в том, что справочник открытых ключей, содержащий сертификаты, список доверенных сертификатов, список отозванных сертификатов, и т. д. криптографически защищен на закрытом ключе пользователя, что не позволяет злоумышленнику внести в него изменения, например, установить доверенный сертификат без ведома пользователя.
      Примечание. СКЗИ Верба-OW реализует схожую ключевую модель.
    2. Следующая особенность вытекает из предыдущей. В СКЗИ для того, чтобы сделать рабочие ключи, необходимо сначала создать справочник сертификатов с помощью специальных ключей регистрации. По истечении срока действия рабочих ключей генерируются новые, но для того, чтобы их сгенерировать, нужно обладать действующими предыдущими рабочими ключами. Ключи создаются по децентрализованной схеме с участием Банка России в качестве Центра Сертификации.
    3. СКЗИ поддерживает работу с функционально-ключевыми носителями (vdToken), выполняющими функции электронной подписи и шифрования у себя на борту, без передачи закрытых ключей в память ЭВМ.
    4. Криптографические ключи, используемые для взаимодействия с платежной системой Банка России, бывают двух видов:
      • «Только шифрование» – позволяют зашифровывать / расшифровывать электронные сообщения.
      • «Шифрование и подпись» – делают то же самое, что и в первом случае, а также позволяют подписывать электронные сообщения.

    УТА


    Зашифрованные и подписанные электронные сообщения помещаются в специальную папку, на схеме (Рис. 2.) это «Папка 3». УТА непрерывно мониторит эту папку и, если он видит там новые файлы, передает их в ЦБ РФ одним из следующих способов:

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

    Достучавшись до ЦБ (первым или вторым способом), УТА передает электронные сообщения через публикуемый ЦБ API. Во время сеансов связи УТА также получает из ЦБ входные электронные сообщения.

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

    Получив зашифрованное электронное сообщение, УТА перекладывает его в папку с входящими зашифрованными сообщениями. Уполномоченный работник с помощью своих криптоключей и АРМ КБР проверяет электронную подпись и расшифровывает сообщение.

    Далее обработка производится в зависимости от типа электронного сообщения. Если это платежное сообщение, то оно через модуль интеграции передается в АБС, где на его основании формируются бухгалтерские проводки, изменяющие остатки на счетах. Важно отметить, что при взаимодействии АБС (модуля интеграции) и АРМ КБР используются файлы стандартного формата в открытом виде.

    В процессе функционирования АРМ КБР ведет журнал своей работы, который может быть реализован в виде текстовых файлов или с помощью БД, работающих под управлением СУБД.

    Альтернативные схемы обработки


    Мы рассмотрели «классическую» схему работы системы. В реальности существует множество ее разновидностей. Рассмотрим некоторые из них.

    Разновидность 1. Разделение контуров отправки и приема сообщений
    Реализуется схема с двумя АРМ КБР. Первый работает с участием человека и выполняет только отправку сообщений, второй работает в автоматическом режиме и выполняет только прием сообщений.

    Разновидность 2. Полный автомат
    АРМ КБР настраивается на работу полностью в автоматическом режиме без участия человека

    Разновидность 3. Изолированный АРМ КБР
    АРМ КБР функционирует как выделенный компьютер, не подключенный к сети банка. Электронные сообщения передаются на него человеком-оператором с помощью ОМНИ.

    Перенос электронной подписи из АРМ КБР в АБС


    Банк России планирует перейти на новую технологическую схему обработки платежей, при которой электронные сообщения будут подписываться не в АРМ КБР, как было ранее, а в АБС (точнее в модуле интеграции АБС — АРМ КБР).

    Для реализации данного подхода выпущена новая версия АРМ КБР, которая стала называться АРМ КБР-Н (новая). Все основные изменения можно увидеть, если сравнить схемы информационных потоков, проходящих через АРМ КБР старой и новой версии.

    Рассмотрим схему информационных потоков в классическом АРМ КБР. Источник схемы – официальная документация на АРМ КБР «АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО КЛИЕНТА БАНКА РОССИИ. Руководство программиста. ЦБРФ.61209-04 33 01».


    Рис. 3.
    Примечания.

    • Условное обозначение «АС КБР» (автоматизированная система клиента Банка России) соответствует условному обозначению АБС на предыдущих схемах.
    • Условное обозначение «СПО СВК» соответствует условному обозначению УТА на предыдущих схемах.
    • КА – код аутентификации (электронная подпись) электронного сообщения.
    • ЗК – защитный код еще один вид электронной подписи, но в отличии от КА, который формируется исходным сообщением без изменений, ЗК формируется только под значащими данными без учета разметки. Более подробно о технических нюансах КА и ЗК можно почитать в документации УФЭБС «Защита электронных сообщений (Пакетов ЭС)». С юридической точки зрения ЗК – технологическая мера защиты информации, в то время как КА, согласно договорам и правилам платежной системы Банка России, признается электронной подписью.

    Теперь взглянем на аналогичную схему для нового АРМ КБР-Н. Источник «АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО КЛИЕНТА БАНКА РОССИИ НОВОЕ. Руководство программиста. ЦБРФ.61289-01 33 01»


    Рис. 4.

    С точки зрения криптографии АРМ КБР-Н отвечает за шифрование / расшифрование электронных сообщений, а также за проверку электронных подписей на них. Формирование электронных подписей перенесено в модуль интеграции АБС.

    Логично предположить, что данный модуль также должен будет проверять подписи под сообщениями, полученными из АРМ КБР-Н. С технической точки зрения это не является обязательным, но с точки зрения обеспечения безопасности имеет критическое значение, поскольку обеспечивает целостность сообщений, передаваемых между АБС и АРМ КБР-Н.

    Помимо файлового интерфейса взаимодействия между АБС, АРМ КБР-Н и УТА добавлен интерфейс IBM WebSphere MQ, что позволяет строить сервис-ориентированную ИТ-инфраструктуру банка и решить проблему старой схемы с организацией одновременной работы нескольких операторов, ответственных за отправку платежей.

    Заключение


    Мы рассмотрели внутреннее устройство платежной ИТ-инфраструктуры банка. В следующих частях рассмотрим угрозы информационной безопасности, которые здесь возникают.
    Поделиться публикацией
    Комментарии 41
      0
      Коль скоро вы рассматриваете информационную безопасность, то неплохо бы упомянуть основную причину внедрения АРМ КБР-Н, а именно потенциальную незащищенность канала АБС <=> «старый» АРМ КБР.
        0
        Угрозы ИБ будут рассмотрены в следующих частях. Забегая вперед можно сказать что АРМ КБР-Н увеличит безопасность только при ОЧЕНЬ качественной реализации функций подписи в модулях интеграции АБС. Если все будет как обычно, то станет только хуже.
          0
          Под «как обычно» имеете в виду реализацию наложения ЗК и КА во внешнем по отношению к АБС модуле? Ну, так-то да, имеет место, если не хотят обращаться к вендору АБС. Кроилово ведет к попадалову.

          А реализация внутри АБС и передача в АРМ КБР-Н уже защищенного файла, ИМХО, больших рисков не несет.
            0
            Многие АБС построены на базе СУБД, работающей под ОС *nix семейства. Далеко не факт, что технически будет возможно установить на сервер АБС СКАД Сигнатуру, а с учетом того, что в больших АБС серверов значительно больше 1, то идея установки «СКЗИ на АБС» превращается в сложно реализуемую.

            Таким образом в большинстве случаев криптография будет реализовываться внешним отношению к АБС модулем. В данном исследовании мы их называем модуль интеграции АБС-АРМ КБР. То есть то, о чем вы и сказали — «кроилово».

            В данном случае незащищенный канал АБС-АРМ КБР, может поменяется на незащищенный канал АБС-модуль интеграции АБС-КБР. Плюс к этому появятся дополнительные угрозы свалянные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.

            Конечно можно сделать все и по уму — защищая канал АБС-модуль интеграции АБС-АРМ-КБР. Все будет зависеть от конкретной реализации.
              0
              Многие АБС построены на базе СУБД, работающей под ОС *nix семейства. Далеко не факт, что технически будет возможно установить на сервер АБС СКАД Сигнатуру.

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

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

              В-третьих, хотя СУБД и на *nix, сервер приложений, запускающий криптографию, вполне может быть под Windows.

              Смотрите, сейчас я вас раскручу на все секреты из вашей следующей статьи :)
                0
                Кстати, по поводу *nix — оказывается Сигнатура и для Linux есть:
                www.x509.ru/forum/viewtopic.php?id=14889
                  0
                  Да, есть.
                  Но с *nix тема в том, что СКЗИ может не подойти именно под ваш *nix.
                    0
                    А на первой картинке АБС работает на MSSQL, т.е. WinServer. Я даже затрудняюсь сказать, что за АБС такая — Юнисаб?
                      0
                      Например, Diasoft
                        0
                        Ё, точно же! Ну значит для половины российских банков проблемы нет :)
                          +1
                          Если грамотно строить безопасность проблем не будет вообще.
                0
                Плюс к этому появятся дополнительные угрозы связанные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.

                А в чем угроза из-за появления второго СКЗИ?
                  0
                  СКЗИ — одно из наиболее критичных с точки зрения атаки мест. Появление второго СКЗИ, создает дополнительное критичное место.
                    0
                    Слишком общий ответ. Можете предложить возможный кейс?
                      0
                      Безопасность платежей на 99% обеспечивается применением шифрования и ЭП.

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

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

                      Если оба СКЗИ работают на разных ключах, и оба выполняют и шифрование и ЭП (эшелонированная защита), то подобных проблем не будет.

                      В случае применения АРМ КБР-Н, такого нет. ЭП подпись выполняется на стороне АБС, а шифрование выполняется на стороне АРМ КБР-Н.

                      Более чем уверен, что будут банки которые это будут делать на базе одних и тех же ключей.
                        +1
                        В случае применения АРМ КБР-Н, такого нет. ЭП подпись выполняется на стороне АБС, а шифрование выполняется на стороне АРМ КБР-Н.
                        По-моему, ЗК на сообщение и шифрование уже сейчас, со старым АРМ, могут быть сделаны на разных ключах. Только пока это по желанию банка.
                        Более чем уверен, что будут банки которые это будут делать на базе одних и тех же ключей.
                        По-моему, ЦБ при переходе на АРМ КБР-Н будет обязывать использовать раздельные ключи, АРМ КБР-Н уже предварительно проверяет верность ЗК в сообщениях, полученных от АБС.

                        Я все жду, когда ЦБ потребует использовать или хотя бы реализует callback из АРМ-а в АБС с вопросом — «ты правда посылал такой платеж?». Сами рекомендовали, но ничего не делают.
                          0
                          По Альбому УЭФБС применение ЗК для банков не обязательно, применяют только КА.

                          По-моему, ЗК на сообщение и шифрование уже сейчас, со старым АРМ, могут быть сделаны на разных ключах. Только пока это по желанию банка.

                          Да, могут.

                          По-моему, ЦБ при переходе на АРМ КБР-Н будет обязывать использовать раздельные ключи, АРМ КБР-Н уже предварительно проверяет верность ЗК в сообщениях, полученных от АБС.

                          Пока таких требований не видел.

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

                          Данное исследование и было предпринято, как раз что бы и банки и ЦБ смогли в комплексе увидеть все нюансы безопасности.
                      +1
                      Наиболее критичное место это файл. В АРМ-КБР он отдавался без средств контроля неизменности от момента формирования и выгружался из нее так же так же обычный xml. Изменить в нем счет получателя относительно несложно, защита правами на запись давно уже не является защитой.
                        0
                        Да, это так, АРМ КБР-Н как раз должен это поправить.
                        Но надо смотреть на всю картину в целом, а не только на КБР.
                          0
                          Если раньше надо было взломать АРМ КБР и незаметно подменить реквизиты в файле перед подписью, то теперь надо взламывать АБС, чтобы подменить там перед подписью.
                          Больше напоминает перераспределение отвественности. АБС это точно вотчина банка, а АРМ КБР-Н, это просто транспорт который и ломать теперь смысла особого нет.
                          Ну и взлом АБС требует болеет высокой квалификации хакера, особенно если все операции подписи будут производиться на лету внутренней логикой системы. Это не файлик на диске поправить.
                            0
                            Про перенос ответственности вы это здорово подметили.

                            Я думаю проблема в том, что мы сейчас стали заложниками подхода ФСБ в части регулирования криптографии.

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

                            Но что есть, то есть. Наверно решения ФСБ основываются на той информации и тех подходах которые нам неизвестны.
                              0
                              Нет никакой проблемы стойко шифровать средствами SQL сервера. Или на сервере. Отдельным процессом/потоком/службой. Вопрос в ключах. У кого они? То же самое с ЭП, вопрос опять же в ключах, вся «элегантность» подписи на сервере ломается необходимостью передать ключ на этот сервер, опять все упрется в защиту канала. С точки зрения же возможных последствий от его компрометации лучше гонять платежный документ (его можно сверить перед отправкой), чем ключ, которым можно заверить документ созданный вообще не в банке.
                                0
                                Шифровать на SQL-сервере нельзя с точки зрения «нормативки» и договоров с ЦБ.

                                Для шифрования должна использоваться только СКАД Сигнатура.
                                  0
                                  Шифрование и дешифрование происходит в АРМ КБР-Н, а там вопрос с SQL-сервером, передачей ключей и Сигнатурой не стоит.
                                    0
                                    Использование АРМ КБР-Н не является обязательным. Шифровать можно и другим ПО, главное использовать форматы и ключи ЦБ. Кстати, оно в отличи от АРМ КБР-Н может быть сертифицировано ФСТЭК/ФСБ и проведен контроль влияния среды на СКЗИ. Другой вопрос — зачем? В АРМ КБР-Н приходит защищенный минимум одной ЭП файл. Шифрование там выполняет функцию защиты от компрометации, целостность защищена уже в АБС простановкой ЭП.
                                    0
                                    Не только. Можно использовать криптосервер той же «Валидаты». Другой вопрос, что это ничего дополнительно не улучшает, после постановке подписи (ЗК) документ менять нет смысла, а ЗК можно (нужно!) проставлять в доверенном контуре.
                                      0
                                      В договоре с ЦБ прописана необходимость использования СКАД Сигнатуры и ПО для АРМ (это может быть АРМ КБР или другое ПО, предоставляемое ЦБ).
                                      Договор об обмене электронными сообщениями
                                      при переводе денежных средств
                                      в рамках платежной системы Банка России

                                      2.5. Для выполнения условий Договора Стороны применяют средство криптографической защиты информации «Система криптографической авторизации документов «Сигнатура»» (далее СКЗИ СКАД «Сигнатура»).

                                      3.1.2. Заключает договор с Банком, в соответствии с которым получает от Банка:
                                      — ПО для АРМ,
                                      — СКЗИ.


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

                                      Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись. См. Альбом УФЭБС и договор с ЦБ.
                                        0
                                        В своих презентациях ЦБ упоминал про сервер «Валидаты», для того, чтобы его использовать нужно пере заключать договор.

                                        Теоретически. Практически в документе нет информации о ПО, которым была наложена подпись. Если бы не особый OID то и КриптоПро без проблем бы подписывал ГОСТом с ключами «Сигнатуры».

                                        Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись.

                                        Пока не ставят и то не все. Смотрите третий вариант защиты. Но это не суть, можно ставить КА и/или ЗК+КА. Не важно, суть в том, что после простановки ЭП (и ЗК и КА на самом деле ЭП) документ изменять/подменять бессмысленно.
                                          0
                                          В комментарии выше я указывал на то, что в договоре явно прописано использование СКАД Сигнатуры.

                                          Действительно в подписанном ЭС нет сведений о том, с помощью какого СКЗИ оно подписано и соответственно теоретически можно использовать любое другие средства подписи, хоть даже написать самому.

                                          НО регуляторный риск (нарушение договора, нарушение 552-П) ставит на всем этом крест, слишком дорогие возможные последствия — расторжение договора с МЦИ / нарушение требований ЦБ -> отзыв лицензии.
                                            0
                                            отзыв лицензии.

                                            ...->расстрел… )))
                                            Даже расторжения нет по причине использования иного ПО для простановке ЭП. Указание использования СКАД «Сигнатура» вписано в «Общие положения», ни в условиях ни в перечне причин расторжения нет пункта о расторжении по причине неиспользования Сигнатуры. Зато есть требования ФСБ о необходимости соблюдать требования формуляров к СКЗИ, в котором у «Сигнатуры» есть требование проводить «оценку влияния...» при встраивании. В АРМ_ах «Сигнатура» встроена, а оценки влияния нет! Какое из нарушений более существенно? Я не призываю использовать криптосервер, повторюсь, там другие проблемы есть. Подписать документ нужно как можно в более доверенной среде и не загруженный файл, а после совершения расчетной операции! В полном соответствии приложением 2 к письму 58 МЦИ.
                                              0
                                              Наказание за несоблюдение всегда интересная тема для дискуссии.

                                              Приведу свои аргументы за то, что использование стороннего СКЗИ может послужить поводом к расторжению договора и отзыву лицензии.

                                              Договор об обмене электронными сообщениями
                                              при переводе денежных средств
                                              в рамках платежной системы Банка России


                                              1. Предмет договора

                                              1.1. Договор определяет… а также требования к защите информации в платежной системе Банка России.

                                              2. Общие положения
                                              2.5. Для выполнения условий Договора Стороны применяют средство криптографической защиты информации «Система криптографической авторизации документов «Сигнатура»» (далее СКЗИ СКАД «Сигнатура»).
                                              Для защиты ЭС от доступа к ним посторонних лиц при передаче по незащищенным каналам связи применяется шифрование.
                                              Порядок управления ключами КА (ЭП) и ключами шифрования, применяемыми при обмене ЭС при переводе денежных средств в рамках платежной системы Банка России, определяется в Приложении 6 к настоящему Договору.
                                              Порядок обеспечения информационной безопасности при использовании СКЗИ определяется в Приложении 7 к настоящему Договору.

                                              3. Условия участия в обмене ЭС, приостановления
                                              И прекращения участия в обмене ЭС
                                              3.1. Клиент для участия в обмене ЭС выполняет следующие действия.
                                              3.1.5. Выполняет требования к защите информации в платежной системе Банка России для клиентов Банка России, в том числе требования к защите информации при обмене ЭС, приведенные в приложении 1 к настоящему Договору.
                                              3.5. Клиент до начала обмена ЭС представляет акт о готовности к обмену электронными сообщениями с Банком России при переводе денежных средств в рамках платежной системы Банка России по форме, приведенной в Приложении 3 к настоящему Договору.

                                              5.2. Клиент обязан:
                                              5.2.7. Использовать актуальные версии ПО для АРМ, СКЗИ, нормативно-справочной информации.

                                              9. Срок действия договора, порядок его изменения и расторжения
                                              9.5.4. При нарушении Клиентом требований к обмену ЭС и обеспечению безопасности при обмене ЭС, предусмотренных законодательством Российской Федерации, и условий Договора.


                                              Приложение 3 к договору (Акт готовности)
                                              4. Все АРМ паспортизованы. Значения результатов вычисления хэш-функции исполняемых модулей (контрольных сумм) программного обеспечения (далее — ПО) СКАД «Сигнатура», утвержденные руководителем и заверенные печатью организации, зафиксированы в Приложении к настоящему Акту. Указанное Приложение является неотъемлемой частью Акта.


                                              Приложение 6 к договору (Порядок управления ключами)

                                              1. Общие положения.
                                              1.2. В ходе функционирования Клиентом должны формироваться и храниться в бумажном виде следующие документы СКАД «Сигнатура»:…

                                              2.2. Основными функциями Клиента являются следующие:
                                              — ответственное хранение хэш-функций ПО СКАД «Сигнатура»;


                                              Приложение 7 — Порядок обеспечения информационной безопасности при использовании СКЗИ

                                              1. Установка и настройка СКЗИ на АРМ выполняются с учетом требований, изложенных в эксплуатационной документации на СКЗИ, в присутствии АИБ, назначаемого Клиентом. При каждом запуске АРМ должен быть обеспечен контроль целостности установленного программного обеспечения СКЗИ.


                                              Положение Банка России от 24 августа 2016 г. № 552-П “О требованиях к защите информации в платежной системе Банка России”
                                              2.4. Участники должны обеспечивать выполнение требований эксплуатационной документации на системы защиты информации от несанкционированного доступа (далее — СЗИ от НСД), СКЗИ, средства защиты от воздействий вредоносного кода (далее — СЗ от ВВК), применяемые на участке ПС БР, в течение всего срока их эксплуатации, в том числе при установке и настройке, а также обеспечить восстановление указанных технических средств защиты информации в случаях сбоев и (или) отказов в их работе.


                                              Итого по расторжению договора:
                                              1. Согласно договору СКЗИ — СКАД Сигнатура
                                              2. Согласно Приложению 3 — Расчет хэш-сумм идет для СКАД Сигнатура
                                              4. Согласно Приложению 6 — Банк оформляет сертификаты ключей для СКАД Сигнатура
                                              3. Согласно Приложению 7 — СКЗИ должно устанавливать в соответствии с документацией на СКАД Сигнатуру

                                              Таким образом, считаю что использование другого СКЗИ может быть основанием для Расторжения договора по пункту 9.5.4. или на основании п. 2.1. ст. 450 ГК РФ

                                              Итого по отзыву лицензии:
                                              Использование другого СКЗИ, вместо СКАД Сигнатуры будет нарушением п.2.4 552-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.

                                              Нарушение нормативных документов ЦБ, согласно п.6 ст. 20 Закона о банках и банковской деятельности может являться основанием для отзыва лицензии.
                                                0
                                                Использование другого СКЗИ, вместо СКАД Сигнатуры будет нарушением п.2.4 552-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.

                                                Документация на СКЗИ никак не договор, а Формуляр, по которому для использования в АРМ должно быть заключение ФСБ России по результатам оценки влияния среды функционирования СКЗИ. Может быть для «АРМ» оно уже появилось и пропустил это? Чему противоречит использование сертифицированного СКЗИ КС «Валидата» в соответствии с его формуляром?
                                                  0
                                                  Касательно контроля корректности встраивания СКАД Сигнатура в АРМ КБР.

                                                  Да, должно быть. Зона ответственности ЦБ. Поскольку именно он делал встраивание.

                                                  Документация на СКЗИ никак не договор

                                                  Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.

                                                  Если посмотреть на данный вопрос по другому. К вам пришла проверка и говорит (гипотетически): «Почему при работе АРМ КБР вы не соблюдаете требования док-ции СКЗИ „Вебра-OW?“. Ваш резонный ответ будет: „Договором обмена ЭС с МЦИ ЦБ РФ предусмотрено применение СКАД Сигнатура, а не Верба-OW“

                                                  Чему противоречит использование сертифицированного СКЗИ КС «Валидата» в соответствии с его формуляром?

                                                  Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.
                                                    0
                                                    Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.
                                                    Закон иного мнения. Нормативка по СКЗИ определяет алгоритм, наличие лицензий у разработчика и сертификацию ПО. КС разработан разработчиком с лицензией, имеет сертификат ФСБ, использует отечественную предписанную криптографию. С «необычными» OID работает. То есть законодательству РФ соответствует и технологически подписывает/шифрует правильно. Более того, разработчик один и тот же. Так что пунктики про именно «Сигнатуру» могут быть от отсутствия альтернативы на момент написания шаблона. А если завтра разработчик сервер «Сигнатурой» назовет? Или СКАД назовет «Валидата»? Уточните в ЦБ, что в этом случае делать!?!?
                                                    Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.

                                                    В 552-П нет ничего про договор. Есть формуляр на используемое СКЗИ. СКЗИ используется в соответствии с ним. Это если по существу.
                                                      0
                                                      Чтобы дальнейшая дискуссия была предметной предлагаю разбить рассуждения на пункты с которыми можно будет либо соглашаться либо дополнять /изменять.

                                                      (1) Законодательная база
                                                      Закон иного мнения. Нормативка по СКЗИ определяет алгоритм, наличие лицензий у разработчика и сертификацию ПО.

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

                                                      Для банка как для коммерческой организации (в случае если он не лицензиат ФСБ) обязательными требованиями ФСБ России будет только Приказ 378. ПКЗ-2005, Приказ ФАПСИ 152 будут носить только рекомендательный характер.

                                                      Приказ 378 говорит о том, что если для защиты ПДн применяется СКЗИ, то они должны быть сертифицированы и по соответствующему классу. Таким образом, нормативка ФСБ не обязывает использовать для взаимодействия с ЦБ серт. СКЗИ и тем более СКАД Сигнатуру (требования по обеспечению конфиденциальности ПДн при передаче могут быть закрыты использованием спец. операторов связи).

                                                      В тоже время, для банка обязательными будут требования нормативных документов Банка России и договора с МЦИ.

                                                      Нормативка ЦБ (552-П) не определяет конкретное СКЗИ, а говорит лишь о том, что оно должно правильно использоваться.

                                                      Договор в свою очередь уточняет какое конкретно СКЗИ должно использоваться.

                                                      (2) Технические возможности.
                                                      Говоря о совместимости сертифицированных СКЗИ, помимо реализации базовых рекомендованных криптоалгоритмов (ГОСТ Р 34.10-2012 и т.д.) следует также учитывать то, каким рекомендациям ТК26 СКЗИ соответствует. Например, как вырабатываеться общий ключ при шифровании файлов при передаче между абонентами (например, СХЕМЫ ВЫРАБОТКИ ОБЩЕГО КЛЮЧА С АУТЕНТИФИКАЦИЕЙ
                                                      НА ОСНОВЕ ОТКРЫТОГО КЛЮЧА
                                                      ). Если СКЗИ используют разные схемы, то они будут между собой не совместимы.

                                                      Говорить о совместимоти только на основании обработки «хитрого» OID на мой взгляд не совсем корректно. Так как OID это всего лишь параметр в сертификате.

                                                      Но скорее всего, учитывая то, что Валидата КС и СКАД Сигнатура одного производителя, то они предположительно совместимы между собой.

                                                      И еще, если мы говорим про альтернативы, почему бы тогда не рассмотреть VIPNET CSP? Он тоже сертифицированный, да и к тому же бесплатный. Ну или например, КриптоПРО HSM — он секъюрный.

                                                      (3) Альтернативы ЦБ
                                                      Так что пунктики про именно «Сигнатуру» могут быть от отсутствия альтернативы на момент написания шаблона.

                                                      Договор, есть договор. Чем руководствовалось ЦБ при его написании известно только ЦБ. Предлагаю исключить это из дальнейшего рассуждения.

                                                      А если завтра разработчик сервер «Сигнатурой» назовет? Или СКАД назовет «Валидата»? Уточните в ЦБ, что в этом случае делать!?!?


                                                      Если Валидата КС станет называться СКАД Сигнатура, то ЦБ должен будет ее всем раздать и получить взамен Акты готовности с новыми хэщ-суммами.

                                                      Если измениться название СКЗИ, то вносить изменение в договор, а ЦБ может это сделать в одностороннем порядке со всему дальнейшими процедурами — организацией перехода, раздачи СКЗИ и т.д.
                                                        0
                                                        Договор, есть договор.

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

                                                          0
                                                          Все бумажные договора с МЦИ, которые мне приходилось видеть в точности совпадали с действовавшими на тот момент типовым договорами.

                                                          Поэтому в данном рассуждении я принял, что подписанный бумажный договор = заполненный типовой договор.
                                      0
                                      Слайд с презентации ЦБ
                                      Способы формирования и простановки КА/ЗК

                                      Способы формирования и простановки КА/ЗК
                                      1. «Встраивание» СКЗИ в ПО АС клиента
                                      2. Разработка промежуточного ПО между АС клиента и ПК обеспечения электронного обмена вместо ПС КБР
                                      3. Использование Криптографического сервера разработки ООО «Валидата»
                                        0
                                        Слайд видел.

                                        Пока это только «идеи» ЦБ. Для их реализации нужно перезаключать договор между Банком и ЦБ.
                                  0
                                  Если раньше надо было взломать АРМ КБР и незаметно подменить реквизиты в файле перед подписью
                                  Чтобы подменить реквизиты в файле, не нужно было взламывать АРМ КБР. Целью атаки являлся канал.
                                  Больше напоминает перераспределение ответственности.
                                  Именно так. Представители ЦБ нам прямо сказали, что ЦБ не собирается отвечать за действия, происходящие вне его контроля. Собственно, это единственная причина появления АРМ КБР-Н. Остальные плюшки (отсутствие ручного ввода и, следовательно, нет необходимости его поддерживать, повышение защищенности платежной системы в целом) идут бонусом.
                  0
                  Видимо, чтобы не подставлять некоторые крупные банки, АБС которых всё ещё не может подписывать посылки в АРМ КБР

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

                  Самое читаемое