Транзит 2.0 — это обновлённая система для обмена финансовыми сообщениями между корпорациями и банками, разработанная Национальным расчётным депозитарием на основе предыдущей версии — Транзит. До сих пор её основными пользователями были лишь профессиональные участники рынка ценных бумаг, обменивающиеся электронными документами друг с другом в процессе депозитарной деятельности и проведения денежных расчётов. Транзит 2.0 значительно расширяет список и возможности пользователей: систему могут использовать корпорации и банки для автоматического обмена платёжными и иными документами, включая сообщения в международном формате ISO 20022.
Транзит электронных документов через СЭД НРД обеспечивается только при условии использования отправителем и получателем одинакового типа СКЗИ (или только сертифицированных СКЗИ, или только не сертифицированных СКЗИ).
При транзите электронных документов стороной-отправителем может использоваться схема с «открытым конвертом» или схема с «закрытым конвертом».
При использовании схемы с «открытым конвертом» передаваемые электронные документы не зашифровываются. Зашифровыванию с использованием открытых ключей шифрования НРД подвергается только Пакет транзитных электронных документов. При использовании схемы с «открытым конвертом» передаваемые электронные документы могут быть расшифрованы НРД, что позволяет НРД контролировать структуру (формат, спецификацию) передаваемых файлов и гарантирует получателю получение корректного по структуре (формату, спецификации) документа.
При использовании схемы с «закрытым конвертом» отправляемые электронные документы после формирования зашифровываются с использованием открытых ключей шифрования получателя, а затем Пакет транзитных электронных документов зашифровывается с использованием открытых ключей шифрования НРД. Такая схема не позволяет получить доступ к информации со стороны НРД.
На сегодняшний день в системе возможны переводы только рублёвых платежей, валютные операции недоступны.
Участниками данной системы является: ГК «Дикси», АО «Газпромбанк», АО «Альфа банк», — других участников данной системы не обнаружено.
Владельцем системы является Национальный Расчётный Депозитарий;
SWIFT – международная межбанковская система передачи платёжных документов для запроса информации и совершения платежей. Система позволяет финансовым организациям во всём мире передавать безопасно и в стандартизированной форме отправлять и получать электронные сообщения с финансовыми операциями, такие как перевод денежных средств, запрос выписок и многие другие.
В 1968 г. был зарождён данный проект. Целью проекта было обеспечение участвующих в проекте банков и других финансовых организаций в организации защищённой сети для передачи финансовых сообщений. Система начала полноценно функционировать в начале 1970-х гг. В 1987 г. был преодолён барьер в 1 млн сообщений в день.
В качестве соучредителей выступили 248 банков из 19 стран мира, Штаб-квартира находится в Бельгии, недалеко от Брюсселя.
По состоянию на 2015 год, членами Swift сообщества являются более 11 тысяч финансовых организаций в более чем 200 стран мира, и примерно 1/11 из этих компаний являются корпорациями, например, с государственным участием или без государственного участия (Например, Apple, Microsoft, Госкорпорация «Росатом», ПАО «Ростелеком» и другие). Примерный оборот ежедневных сообщений составляет 30 миллионов, примерно в денежном эквиваленте это десятки миллиардов долларов в день.
Адресация абонентов в системе SWIFT происходит по коду Business Identifier code, присваивается в соответствии со стандартом ISO 9362.
ISO 9362 — стандарт, устанавливающий универсальный метод идентификации участников финансовых расчётов. Официальное название стандарта — «Банковское дело. Банковские телекоммуникационные сообщения. Идентификационные коды банков».
Стандарт создан на основе разработанного компанией SWIFT метода идентификации банков — членов сети SWIFT. При этом компания SWIFT закреплена в роли уполномоченного органа ISO по регистрации кодов BIC.
Приход к единым стандартам сообщений, передаваемых по сети SWIFT, был выполнен международным комитетам по стандартизации. В 1993 году сообщество SWIFT добавило новую группу финансовых стандартов для связи с национальными и глобальными сетями. В рамках системы SWIFT применяются следующие принципы:
исключается возможность различного понимая полученного или отправленного сообщения отправителем и получателем;
полный контроль передачи информации, фиксация транзакций;
возможность генерировать автоматически отчёты о проведённых операциях;
Иногда идентификация в системе SWIFT именуется как SWIFT-BIC, SWIFT ID или SWIFT code.
Финансовые сообщения формируются по формату SWIFT MT.
Основные дата центры SWIFT расположены в Америке и Европе. Эти центры связаны с региональными центрами, которые устанавливаются в странах, вступивших в сообщество SWIFT. Сообщение от банка отправителя поступает по открытым или закрытым каналам связи в региональный центр. Ответственность за передачу сообщения до регионального центра несёт инициатор сообщения. В региональном центре все сообщения проверяются на соответствие стандартам SWIFT MT, накапливаются, шифруются и передаются по назначению. В системе применяется многоуровневая защита информации, которая обеспечивает сохранность и конфиденциальность передаваемых данных. Используются криптографические методы, соответствующие стандартам ISO. Ежедневно SWIFT передаёт платёжные поручения суммарной оценочной стоимостью более $6 трлн. Каждый год SWIFT передаёт около 1,8 млрд сообщений о совершении платежей.
MT101 – это запрос на перевод, позволяющий осуществить электронный перевод средств с одного счета на другой. Средства переводятся со счета клиента, заказавшего перевод, на счёт банка или финансовой организации получателя.
Допускается применение следующего набора символов:
a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / – ? : ( ) . , ‘ + { } CR LF Space
фигурные скобки {} не могут быть использованы в сообщении, а служат только разделителем для определения различных структурных блоков SWIFT
Тире “-“ не должно быть первым символом любой стороки
Тэг 20 – Номер перевода:
Обязателен
Записывается как :20:
16 символов
Тэг 21 – Номер, заданный отправителем:
Опционально
Записывается как :21R:
16 символов
Тэг 28D – Номер сообщения/Итого сообщений:
Обязателен
Записывается как :28D:
5n/5n
Тэг 50C или 50L – Инструкции:
Опционально
Записывается как :50C: или :50L:
Зависит от типа выбранного тэга 50C (BIC) или 50L (35 символов)
Тэг 50F или 50G, или 50H – Информация отправителя:
Опционально
Записывается как :50F: или :50G:, или :50H:
Зависит от типа выбранного тэга 50F, 50G, 50H: :50F:
35 символов (номер счета)
4х35 символов (имя и адрес)
:50G:
/34 символа (счёт)
BIC (8 или 11 символов)
:50H:
/34 символа (счёт)
4х35 символов
Тэг 52A или 52C – Информация об обслуживающей счёт отправителя организации:
Опционально
Записывается как :52A: или :52C:
Зависит от типа выбранного тэга 52A или 52C:
— :52A: — BIC (8 или 11 символов)
— :52C: — /34 символа
Тэг 51A – Отправляющая организация:
Опционально
Записывается как :51A:
BIC (8 или 11 символов)
Тэг 30 – Требуемая дата исполнения
Обязательно
Записывается как :30:
Дата в формате ГГММДД
Тэг 25 – Авторизация:
Опционально
Записывается как :25:
35 символов
Детализация транзакции:
Тэг 21 – Номер транзакции:
Обязательно
Записывается как :21:
16 символов
Тэг 21F – Номер операции конвертации:
Опционально
Записывается как :21F:
16 символов
Тэг 23E – Код транзакции:
Опционально
Записывается как :23E:
4-х символьный код и опциональное продолжение до 30 символов:
можно использовать только перечисленные 4-х символьные коды: CHQB, CMSW, CMTO, CMZB, CORT, EQUI, INTC, NETS, OTHR, PHON, REPA, RTGS, URGP
Если требуется добавить символы после кода, то требуется вставить”/”. Например:23E:URGP/ITSGETTINGLATE
Тэг 32B – Валюта/Сумма транзакции:
Обязательно
Записывается как :32B
3-х символьный код валюты (ISO 4217) и 15 цифр, определяющих сумму
Тэг 50C или 50L – Инструкции:
Опционально
Записывается как :50C: или :50L:
Зависит от типа выбранного тэга 50C (BIC) или 50L (35 символов счета)
Тэг 50F или 50G, или 50H – Информация отправителя:
Опционально
Записывается как :50F: или :50G:, или :50H:
Зависит от типа выбранного тэга 50F, 50G, 50H: :50F:
35 символов (номер счета)
4х35 символов (имя и адрес)
:50G:
/34 символа (счёт)
BIC (8 или 11 символов)
:50H:
/34 символа (счёт)
4х35 символов
Тэг 52A или 52C – Информация об организации, обслуживающей счёт отправителя:
Опционально
Записывается как :52A: или :52C:
Зависит от типа выбранного тэга 52A или 52C:
— :52A: — BIC (8 или 11 символов)
— :52C: — /34 символа
Тэг 56A или 56C, или 56D– Банк посредник:
Опционально
Записывается как :56A: или :56C:, или :56D:
Зависит от типа выбранного тэга 56A или 56C, или 56D
Тэг 57A или 57C, или 57D– Банк получателя:
Опционально
Записывается как :57A: или :57C:, или :57D:
Зависит от типа выбранного тэга 57A или 57C, или 57D:
: 57A: — BIC (8 или 11 символов)
: 57C: — /34 символа
: 57D:
/34 символа(счет)
4х35 символов
Тэг 59 или 59A – Получатель:
Обязательно
Записывается как :59: или :59A:
Зависит от типа выбранного тэга 59 или 59A: :59:
/34 символа (номер счета)
4х35 символов (имя, адрес)
:59A:
/34 символа (номер счета)
BIC (8 или 11 символов)
Тэг 70 – Информация о платеже:
Опционально
Записывается как :70:
4х35 символов, могут быть использованы следующие коды: /INV/ , /IPI/ , /RFB/ , /ROC/ /TSU/
Тэг 77B – Данные для регулятора:
Опционально
Записывается как :77B:
3х35 символов:
строка 1 – 8 символов Код/Страна/Текст
Строка 2-3 — дополнительный текст
Коды:
BENEFRES – Страна получателя
ORDERRES – Страна отправителя
Тэг 33B – Валюта/Сумма в заявлении на перевод:
Опционально
Записывается как :33B:
3-х символьный код валюты (ISO 4217) и 15 цифр, определяющих сумму
Тэг 71A – Расходы по платежу:
Обязательно
Записывается как :71A:
3-х символьный код, допустимо:
BEN – все транзакционные расходы несёт получатель
OUR – все транзакционные расходы несёт отправитель
SHA – транзакционные расходы разделяют стороны платежа
Тэг 25A – Счет, с которого списываются расходы по платежу:
Опционально
Записывается как :25A:
34 символа
Тэг 36 – Курс обмена
Опционально
Записывается как :36:
12 цифр
В нижеприведённом примере сообщения SWIFT MT101 указано, что сумма 123,45 EUR оплачена со счета GB12SEPA12341234123412 в банке BANKGB01XXX поставщику (Vakurin Andrey) на его счёт GB12SEPA12341234123498 в банке BANKGB02XXX. В назначении платежа указано, что оплата по инвойсу INV-0001
:20:123456789 :28D:1/1 :50H:/GB12SEPA12341234123412 ORDERING CUST NAME ORDERING CUST ADDR LINE 1 ORDERING CUST ADDR LINE 2 ORDERING CUST ADDR LINE 3 :52A:BANKGB01XXX :30:160211 :21:11FEB2016INV1 :23E:URGP :32B:EUR123,45 :57A:BANKGB02XXX :59:/GB12SEPA12341234123498 Vakurin Andrey SUPPLIER ADDR LINE 1 SUPPLIER ADDR LINE 2 SUPPLIER ADDR LINE 3 :70:INV-0001 :77B:/BENEFRES/GB :71A:SHA
Система SWIFT планирует постепенно переходить от формата SWIFT MT к сообщениям формата SWIFT MX, которые спроектированы по методологии ISO 20022 и содержат самые актуальные требования.
Для разработки схемы взаимодействия необходимо руководствоваться следующими документами:
ЦБРФ.61209-049301«Руководством по обеспечению информационной безопасности»;
ЦБРФ.61209-049201 «Автоматизированное рабочее место клиента Банка России. Руководство пользователя»;
ЦБРФ.61209-049202 «Автоматизированное рабочее место клиента Банка России. Руководство администратора»;
ВАМБ.00106-019301 «СКАД «Сигнатура» версия 5. «Сигнатура-клиент» версия 5. Руководство администратора информационной безопасности».
АРМ КБР/ АРМ КБР СПФС – это специализированное программное обеспечение работников банков или крупных государственных организаций для подготовки и отправки финансовых сообщений в платежный контур центрального банка. Данное ПО позволяет проставлять электронную подпись на финансовые документы, проводить проверку и расшифровку электронных сообщений, поступивших из Банка России. В своей работе АРМ КБР/ АРМ КБР СПФС использует формат финансовых документов УФЭБС. Типы сообщений бывают как платежные сообщения, так и информационные (создание тестового сообщения, запрос технической информации и тд).
Для обработки электронное сообщение должно быть преобразовано в УФЭБС на АРМ КБР или преобразовано в АБС клиента и отправлено на АРМ КБР.
Электронные сообщения при работе в ручном режиме помещаются в каталог АРМ КБР c://uarm3/exg/cli. Встроенный компонент «Входной контроль» выполяет анализ поступившего ЭС. Если сообщение успешно прошло валидацию, то оно попадает во вкладку «введеные», если сообщение не прошло валидацию, то оно попадает во вкладку «Забракованное». При работе в автоматическом режиме сообщение попадает в выходную папку.
После помещения во вкладку «введеные» данному сообщению проставляется закрытый код и код аутентификации (электронная подпись директора и контролера), после успешного подписания сообщение помещается в папку c://uarm3/exg/apr и ожидают сигнала для дальнейшей отправки в платежной контур платежной системы Банка России. Подготовленные документы для обмена перемещаются из папки c://uarm3/exg/apr в папку c://uarm3/exg/out для выполнения отправки. Помещенные ЭС в папку exg\out отправляются через протокол HTTP (внутри выделенного канала VPN), аутентификация выполняется с помощью пары «логин-пароль».
Принятые сообщения из контура платежной системы принимаются в папку c://uarm3/exg/inc, после принятия сообщения выполняется проверка КА и ЗК подписи. При успешной проверки распакованное сообщение попадает в папку c://uarm3/exg/chk.
Если используется собственная АБС в банке, то принятое электронное сообщение расшифровывается транспортной подписью и перекодируется из base64. Открытое сообщение в открытом виде передается в АБС, где на его основании формируются бухгалтерские проводки, изменяющие остатки на счетах.
В процессе работы АРМ КБР ведет логирование своей работы , и в случае возникновения критической ситуации или сбоя программы она немедленно сообщает это администратору информационной безопасности.
В случаи выхода из строя канала связи предусмотрена доставка электронных сообщений на ОМНИ (отчуждаемый машинный носитель информации) с помощью курьера. Работа АРМ КБР/ АРМ КБР СПФС представлена на рисунке
Для ввода АРМ КБР/ АРМ КБР СПФС в локальную вычислительную сеть предприятия необходимо организовать и обеспечить защищённое подключение ПК АРМ КБР в ЛВС клиента, предполагающее отсутствие технической возможности доступа к ПК АРМ КБР из внешних, по отношению к ЛВС клиента, сетей, в том числе из сети Интернет.
Для решения указанной задачи необходимо обеспечить:
защиту ЛВС клиента от сетевых атак из внешних сетей, в том числе из сети Интернет, путём применения межсетевого экрана, который должен осуществлять фильтрацию сетевого графика и соответствовать требованиям руководящего документа ФСТЭК России «Средства вычислительной техники, Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации» по 4 классу защищённости;
реализацию таких схем конфигурирования ПК АРМ КБР, при которых обеспечивается невозможность вброса данных в обход заданного технологического цикла обработки данных.
Созданные файлы разработанным модулем будут помещаться в папку cli, если сообщение собственного формата, то в папку ed501in.
Разрабатываемый модуль передатчик «ПС БР» может работать как на АРМ КБР, так и на дополнительном изолированном АРМ.
Дополнительная защита от НСД обеспечивается прямым VPN соединением между организацией и ЦБ РФ. IP адреса организации используют те, которые выделяет ЦБ РФ для конкретной организации.
В рамках программного модуля «Передатчик ПС БР» предполагается реализовать следующий функционал:
создание финансовых сообщений в формате УФЭБС ED101;
создание финансовых сообщений в формате УФЭБС ED501;
создание финансовых сообщений в формате SWIFT MT101;
хранение финансовых сообщений в базе данных;
выгрузка платёжных поручений в pdf формате;
обработка принятых входящих сообщений;
Данный модуль можно считать практически полноценной АБС. Сформированные в АБС реестры будут отправляться в АРМ КБР (автоматизированное рабочее место клиента Банка России) — специальный компьютер в банке в отдельном защищённом контуре, с которого уходят платежи в ЦБ РФ.
Высокие функциональные требования к современным АБС обусловлены сложностью интеграции программного продукта, необходимостью решения широкого спектра клиентских задач, в связи с этим мой модуль должен иметь следующие критерии:
комплексное обеспечение банковской деятельности (единство документооборота, отчётности, пакетная обработка данных);
лёгкость интеграции, возможность простого модульного расширения функциональности;
защищённость, безопасность;
достоверность данных, оперативное обновление информации, учёт специфики работы коммерческой структуры.
Разработка приложения будет осуществляться в Visual Studio 2017. В качестве хранилища данных будет использоваться MS SQL Server 2019.
Версии программы будут храниться в системе хранения версий – GitHub, репозиторий https://github.com/aovakur/Peredatchik_PSBR. Количество веток – две (master и release). В ветку мастер я буду выкладывать доработанные формы и функции, в ветку релиз буду выкладывать собранный релиз со всеми библиотеками и необходимыми таблицами.
Для сохранения платёжных поручений необходимо разработать меню конфигурации (выбор сервера, базы данных, имя пользователя, пароль).
Разработанное подключение к БД представлено на рисунке 3.3. Имя и пароль пользователя будет скрыто от пользователя. По умолчанию имя пользователя – adminkbr, пароль aA12345678.
Данные для подключения будут храниться в классе DBUtils.cs, инициализация подключения будет происходить в классе DBSQLServerUtils.cs.
Глобальные настройки подключения к БД я установлю в файле app.config.
Доступ к глобальным настройкам будет происходить через СonfigurationManager и вызов функции ReadSetting, обновление через функцию AddUpdateAppSettings.
Счётчик сообщений (ed501, ed101) в течение операционного дня (текущего дня) также будет задан через глобальные настройки:
Если текущий операционной день поменялся, то происходит обнуление счётчика и первому ЭС присваивается номер 1.
Для разработки и тестирования программы я буду использовать локальный Microsoft SQL Server 2019, в будущем таблицу можно будет перенести на облачный сервер или сервер БД в организации.
Подключение к БД будет осуществлять по TCP соединению и 1433 порту. Для работы с MS SQL я буду использовать Microsoft SQL Server Management studio 2018.
Для отображения созданных и принятых электронных сообщений необходимо создать экранную форму (DataGrid).
Форма 1 будет формироваться в классе Form1.cs. Для сохранения платёжного поручения в специализированный формат необходимо разработать глобальные настройки сохранения. Настройки сохранения будут формироваться в классе settings.cs.
Для создания платёжного поручения (форма 0401060 согласно Приложению 2 Положения Банка России от 19 июня 2012 года № 383-П «О правилах осуществления перевода денежных средств» (в редакции Указаний Банка России от 15.07.2013 № 3025-У, от 29.04.2014 № 3248-У, от 19.05.2015 № 3641-У, от 06.11.2015 N 3844-У, от 05.07.2017 N 4449-У и от 11.10.2018 N 4930-У)) необходимо разработать специальный пользовательский интерфейс и механизм автоматического формирования некоторых полей.
Пользовательский интерфейс формы №0401060 представлен ниже
Данная форма является основным функционалом системы, после создания платёжного поручения его реквизиты можно передать в БД, сформировать PDF документ, отправить на печать, сохранить в соответствующий формат (ed101, ed501, MT101). Форма формируется в классе Form2.cs и используя класс pp.cs для создания нового экземпляра класса CreatePP, значения полей будет заполняться через модификатор доступа get и set. Для каждого поля ПП присвоен соответствующее название P1-P110 c модификатором доступа public и переменные p1-110 с модификатором доступа private.
Фрагмент кода приведён ниже:
private string p1;
private string p0;
private int p2;
private int p3;
private string p4;
private string p5;
public string P0
{
get { return p0; }
set { p0 = value; }
}
public int P20
{
get { return p20; }
set { p20 = value; }
}
public string Status
{
get { return status; }
set { status = «Новое»; }
}
public string P1
{
get { return p1; }
set { p1 = «Платежное поручение»; }
}
public string Date_pp()
{
DateTime dt = DateTime.Now;
string curDate = dt.ToShortDateString();
return curDate;
}
Если при сохранении были заполнены не все поля, то программа выделяет пустые поля красным цветом.
Фрагмент кода для проверки поля:
if (textBox10.Text == «»)
{
textBox10.BackColor = Color.Fuchsia;
}
После вызова функции «create_pdf» будет формироваться pdf документ с заполненными полями
В функцию «create_pdf» в качестве параметров будут передаваться значения полей, c помощью fields. SetField данные значения будут проставляться в PDF документ.
PdfReader template = new PdfReader(settings.safepathetemplate);
PdfStamper stamper = new PdfStamper(template, new FileStream(pathsafe, FileMode.Create));
AcroFields fields = stamper.AcroFields;
fields.AddSubstitutionFont(baseFont);
fields.SetField(«p4», p4);
fields.SetField(«p3», p0);
fields.SetField(«p6», p6);
Большинство полей автоматизированы и не требуют участие пользователя.
Автоматически формируется сумма пропью (согласно требованиям ЦБ), подтягивается банк плательщик, плательщик, получатель, банк получателя. По наименованию организации проставляется ИНН, КПП; по наименованию банка проставляется БИК, корреспондентский счёт.
Производим установку и запуск программы «Передатчик ПС БР» от имени пользователя. Заполняем поля платёжного поручения
Формируем документ ED101 и анализируем результат сохранения
C помощью XMLPAD проводим сопоставление нашего файла ED101 и его XSD схемы.
Наш созданный файл ED101 не имеет логических ошибок и может быть успешно перенесён в АРМ КБР (АРМ КБР СПФС) для отправки в ЦБ РФ.
Провести проверку созданного ED501 невозможно из-за отсутствия стандартизированной схемы, атрибутивный состав каждый банк выбирает самостоятельно.
Осуществляем отправку сформированного сообщения через АРМ КБР/ АРМ КБР СПФС в платёжный контур ЦБ РФ.
После отправки ЭС ED101/ED501 я получил ответную квитанцию от ЦБ РФ о о следующем статусе:
<?xml version=»1.0″ encoding=»utf-8″?><soapenv:Envelope xmlns:soapenv=»http://www.w3.org/2003/05/soap-envelope»><soapenv:Header><props:MessageInfo xmlns:props=»urn:cbr-ru:msg:props:v1.3″><props:To>uic:452500055555</props:To><props:From>uic:KBRGATE</props:From><props:MessageID>KBRGATE_guid:786df05a239943f3bc9eca41a6fc430a</props:MessageID><props:CorrelationMessageID>guid:786df05a239943f3bc9eca41a6fc430a</props:CorrelationMessageID><props:MessageType>3</props:MessageType><props:Priority>5</props:Priority><props:CreateTime>2019-08-06T07:46:04Z</props:CreateTime><props:SendTime>2019-08-06T07:46:04Z</props:SendTime></props:MessageInfo><props:AcknowledgementInfo xmlns:props=»urn:cbr-ru:msg:props:v1.3″><props:AcknowledgementType>2</props:AcknowledgementType><props:ResultCode>0000</props:ResultCode><props:ResultText>ЭС поступило в ТШ КБР:uic:777777700011. Информация о исходном сообщении: имя файла: ED997_06104603.dat. Адресная информация исходного сообщения: логический адрес отправителя: uic:452500055555, логический адрес получателя: uic:777777700011. Время формирования квитанции: 2019-08-06 07:46:04</props:ResultText>
Система разграничения доступа к информации должна содержать четыре функциональных блока:
Идентификацию и аутентификацию субъектов доступа;
Диспетчер доступа;
Криптографическое преобразование информации при ее хранении и передаче;
Очистка памяти;
Если за идентификацию и аутентификацию отвечает механизм проверки пароля и его хранение, диспетчер доступа отвечает за ролевую модель доступа, то криптографическое преобразование является одним из самых сложных функционалов системы. За криптографическое преобразование отвечает электронная подпись (открытый и закрытый ключ), хэш функция.
Электронная подпись (ЭП) — это программно-криптографическое средство. Оно обеспечивает проверку целостности документов, устанавливает лицо, которые его отправило, проверяет целостность.
Электронную подпись в праве использовать физическое и юридическое лицо, в качестве аналога собственноручной подписи. У документа, подписанного электронной подписью, возникает юридическая сила.
Электронным документом может быть финансовый документ, который был создан при помощи программы и хранится на съемном/магнитном диске.
Средствами цифровой подписи являются средства, которые обеспечивают следующие функции:
создание электронной подписи в электронном сообщении или документе;
подтверждение c использованием сертификата пользователя подлинности электронной подписи;
создание закрытых и открытых ключей;
Электронные подписи разделяются федеральным законом «Об электронной подписи» от 06.04.2011 N 63-ФЗ [17]:
простые подписи (например, коды, пароли). Данные подписи имеют самый низкий уровень защиты, а соответственно невозможно проверить автора на наличие изменений в документе;
усиленная неквалифицированная подпись. Создается с использованием криптографических средств, позволяет определить автора и проверить наличие изменений. Для создания такой подписи необходимо использовать сертификат неаккредитованного центра;
усиленная квалифицированная подпись. Создается с использованием криптографических средств, позволяет определить автора и проверить наличие изменений. Для создания такой подписи необходимо использовать сертификат аккредитованного центра ФСБ;
В основе выпуска электронной подписи лежит открытый ключ. На основе него генерируется открытый сертификат пользователя, данный сертификат содержит пользовательские данные, открытый ключ и электронную подпись. Генерация таких сертификатов возможна только с помощью удостоверяющего центра, который имеет ключ шифрования и является доверенным для сертификата пользователя.
Все сертификаты основаны на доверии к удостоверяющим центра верхнего уровня. Самым высоким уровнем является федеральный, который находится под управлением федеральных органов (в России такой федеральный орган — Минкомсвязь). Вся система иерархии сертификатов образует инфраструктуру открытых ключей. Как уже было сказано выше, при такой процедуре требуется проверка не только удостоверяющего центра, выдавшего сертификат, но и всех вышестоящих центров.
В России инфраструктура открытых ключей доступна всем желающим. Изначально она была создана агентством Росинформтехнологии на базе Общероссийского государственного информационного центра (ОГИЦ). Однако сейчас федеральный удостоверяющий центр передан в ведение «Ростелекома». Этот телекоммуникационный оператор активно предлагает развивать различные проекты с использованием инфраструктуры открытых ключей.
Электронная подпись в электронном документе равнозначна собственноручной подписи на бумажном документе при следующих условиях:
сертификат ключа пользователя не утратил силу;
осуществлена проверка подлинности электронной подписи в документе;
электронная подпись используется в соответствии со сведениями, указанными в открытом сертификате пользователя;
У каждого ключа электронной подписи существует UID, который определяет область применения электронной подписи.
Расширенная область действия ключа для финансовых документов ЦБ РФ имеет следующие значения:
1.3.6.1.4.1.10244.5.1.1.5 — UID
1.3.6.1.4.1.10244.5.1.2.2 — UID
1.3.6.1.4.1.3670.5.10.15- UID
Процесс создания цифровой подписи состоит из следующих шагов:
Выполняется подсчет контрольной суммы для исходного документа. Формируется хэш. (Изменение данных исходных недопустимо, в противном случае будет различный хэш)
Полученное значение шифруется с использованием секретного ключа отправителя. Таким образом, достигается блокировка модификаций значений контрольной суммы при передаче данных получателю.
Отправитель посылает получателю: зашифрованный текст (предполагается, что у получателя имеется открытый ключ отправителя), значение контрольной суммы.
Получатель осуществляет расшифровывание значения контрольной суммы, применяя для этого открытый ключ отправителя, полученный из его сертификата. Успешное расшифровывание контрольной суммы и проверка аутентичности сертификата отправителя гарантирует, что данные были получены из «правильного» источника.
Далее получатель, используя такие же алгоритмы хеширования, что и отправитель, вычисляет значения контрольной суммы исходных данных. Сравнив полученное значения с тем, что прислал отправитель, проверяется неизменность данных при передаче. Если значения совпали, то изменений не было, в противном случае данные были модифицированы.
Пример подписания и проверки ЭП между двумя пользователями продемонстрировано на рисунке.
Федеральный закон «Об электронной подписи» от 06.04.2011 N 63-ФЗ регулирует отношения в гражданско-правовых области, оказании государственных и муниципальных услуг, исполнении государственных и муниципальных функций, при совершении иных юридически значимых действий, в том числе в случаях, установленных другими федеральными законами.
Обязанность по изготовлению, выдачи, ведения реестра выданных и аннулированных сертификатом наделяются удостоверяющие центры, которые согласно федеральному закону проходят добровольную аккредитацию сроком на 5 лет.
Дополнительно к этому применяются следующие ограничения:
Обязательная аккредитация. В 2019 году она стала обязательным условием для подключения к крупным системам электронного документооборота (например, сайт Госуслуги, mos.ru и тд);
Техническая совместимость применяемых программно-аппаратных средств для генерации и верификации ЭЦП (USB-носители, ПО) с устройствами, которыми пользуются заявители (ПК, ноутбуками, смартфонами, планшетами) и установленными на них операционными системами;
Гарантия уникальности используемых идентификаторов: объектов, номеров электронной подписи и закрытых ключей;
В работе рассматриваются аккредитованные средства криптографической защиты информации: программно-аппаратный комплекс «Валидата УЦ», СКАД Сигнатура, Крипто Про CSP.
АПК «Валидата УЦ» — отечественная реализация инфраструктуры открытых ключей, реализована с использованием международных рекомендаций и стандартов: X.509 версии 3, RFC 5280, PKCS#10, PKCS#7. АПК «Валидата УЦ» имеет Сертификат соответствия ФСБ (СФ/128-2880) [18].
АПК «Валидата Клиент» входит в состав АПК «Валидата УЦ» и являтся клиентским программным средством криптографической защиты информации, предназначенное для установки на рабочее место пользователя. Имеет Сертификаты соответствия ФСБ России СФ/114-2810 и СФ/124-2811. Представляет собой локальный справочник сертификатов пользователя и криптографическое ядро СКЗИ «Валидата CSP».
На основе Web-сервера разработана система «Транзит» (система защищённого обмена электронными документами на основе квалифицированной электронной подписи), в нее так же водит криптографическое ядро СКЗИ «Валидата CSP».
Для защиты электронной почты разработаны средстава семейства «Курьер», которые используют СКЗИ «Валидата CSP» и входят в АПК «Валидата Клиент».
АПК «Валидата Клиент» на основе файлового обмена :
Автоматизированный клиент СКЗИ МБ предназначен для клиентов Московской Биржи. Позволяет автоматизировать обработку подписанных и зашифрованных файлов, которыми они обмениваются с Московской Биржей, на уровне файловых каталогов.
Автоматизированный клиент СКЗИ Сигнатура предназначен для клиентов Центрального банка Российской Федерации. Позволяет автоматизировать обработку подписанных и зашифрованных (со сжатием) файлов при использовании СКАД «Сигнатура».
Криптографические алгоритмы АПК «Валидата Клиент» представлены в таблице
Электронная подпись
ГОСТ Р 34.10-2012, ГОСТ Р 34.10-2001
Хэш-функции
ГОСТ Р 34.11-2012, ГОСТ Р 34.11-94
Шифрование
ГОСТ 28147-89
«СКАД Сигнатура» разработана компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:
Данное СКЗИ реализует собственную инфраструктуру открытых ключей. Справочник открытых ключей содержит сертификаты пользователя, список доверенных и отозванных сертификатов, криптографически защищен на закрытом ключе пользователя. Без ведома пользователя невозможно установить доверенный сертификат в хранилище. СКЗИ Верба-OW реализует схожую ключевую модель.
Ключи создаются децентрализованы с помощью участников обмена, в качестве центра сертификации выступает Банк России;
СКЗИ поддерживает работу с функционально-ключевыми носителями (vdToken);
Криптографические ключи, используемые для взаимодействия с платежной системой Банка России, бывают трех видов: только шифрование; шифрование и подписание; шифрование, подписание и наложение транспортной подписи;
Криптографические алгоритмы СКАД Сигнатура представлены в таблице 2.6.
Для обмена финансовых сообщений с ЦБ РФ будет использоваться ЭП по алгоритму ГОСТ Р 34.10-2012 и хэш-функция ГОСТ Р 34.11-2012.
Компания КриптоПро создана в 2000 году и в настоящее время занимает лидирующее положение по распространению средств криптографической защиты информации и электронной цифровой подписи. Основное направление деятельности компании — разработка средств криптографической защиты информации и развитие Инфраструктуры Открытых Ключей (Public Key Infrastructure) на основе использования международных рекомендаций и российских криптографических алгоритмов.Продукты компании распространяют более 850 юридических лиц на основании дилерских договоров. Компания выдала более 4 000 000 лицензий на использование СКЗИ КриптоПро CSP и свыше 800 лицензий на использование удостоверяющего центра КриптоПро УЦ, которые применяются различными государственными и коммерческими организациями в системах электронного документооборота, а также востребованы при построении глобальных общегосударственных информационных систем.
КриптоПро CSP 5.0 разработан компанией КриптоПро. Кроме КриптоПро CSP 5.0 у компании еще есть решение КриптоПро ФКН CSP/Рутокен CSP (не извлекаемые ключи на токенах с защищенным обменом сообщениями) и облачная версия — КриптоПро DSS (ключи в облаке) [19].
КриптоПро CSP 5.0 одна из последних разработок компании, в ней поддерживается широкий список платформ, алгоритмов, улучшено быстродействие, удобный пользовательский интерфейс. Работа со всеми ключевыми носителями в связке с КриптоПро DSS и КриптоПро ФКН CSP/Рутокен CSP теперь единообразна. Для переведа разработанных АБС компаний и переход на новую версию КриптоПро не требуется переработка и доработка, API и интерфейс остается единым.
Назначение КриптоПро CSP:
Создание и проверка ЭП;
Осуществление шифрования и имитозащиты;
Обеспечение защищенного соединения по протоколам TLS, и IPsec;
Контроль системного и прикладного программного обеспечения для защиты от НСД;
В КриптоПро CSP 5.0 реализованы не только актуальные криптографические алгоритмы, но еще и возможность использования привычных носителей для хранения секретных ключей RSA и ECDSA.
Криптографические алгоритмы КриптоПро CSP 5.0 представлены в таблице.
Электронная подпись
ГОСТ Р 34.10-2012, ГОСТ Р 34.10-2001, ECDSA, RSA
Хэш-функции
ГОСТ Р 34.11-2012, ГОСТ Р 34.11-94, SHA-1, SHA-2
Шифрование
ГОСТ Р 34.12-2015 («Кузнечик» — начиная с 5.0 R2), ГОСТ 28147-89, AES (128/192/256), 3DES, 3DES-112, DES, RC2, RC4
Хранение облачных ключей и их использование осуществляется с помощью CryptoAPI, чтобы обеспечивает их доступность не только пользовательскими приложениями, но и приложениями от компании Microsoft.
В КриптоПро CSP 5.0 добавлена поддержка носителей, реализующие протокол SESPAKE, в рамках которого пароль пользователя не передается, что позволяется установить защищенный канал между криптопровайдером и носителем. При использовании подобных носителей полностью решается проблема безопасной работы с неизвлекаемыми ключами.
Многие пользователи КриптоПро хотят работать с не извлекаемыми носителями информации, но не повышать их до уровня функционального ключего носителя, для них специально была добавлена поддержка популярных носителей Рутокен (ЭЦП 2.0, JaCarta-2 ГОСТ и InfoCrypt VPN-Key-TLS). Дополнительно пользователи могут работать с токенами и смарт-картами без криптографических сопроцессоров (Gemalto/SafeNet, Multisoft, NovaCard, Rosan, Alioth, MorphoKST и СмартПарк и тд).
Кроме поддержки ключей на носителях также реализовано хранение ключей в реестре Windows, на жестком диске, флеш-накопителях на различных платформах.
Унифицированные форматы электронных банковских сообщений (УФЭБС) представляют собой единый стандарт финансовых сообщений для обмена внутри Российский Федерации. Пользователями данного формата является ЦБ РФ и клиенты ЦБ РФ, расположенные на территории России, валюта списания или валюта зачисления – российский рубль. Формат сообщений основан на стандарте ISO20022.
Основными задачами формата является стандартизация обмена между клиентскими автоматизированными банковскими системами и системой Центрального Банка. Формат упрощает безналичный расчёт на территории Российской Федерации и взаимодействия с системой ЦБ, упрощает существующие форматы электронных сообщений, переходит к современным стандартам обмена коммерческой информацией в электронном виде.
Альбом УФЭБС разработаны на языке разметки XML. В таблице приведены основные форматы документов.
Перевод сообщений между участниками может быть в двух видах: полноформатный или сокращённого формата.
Обмен сообщениями сокращённого формата допускается между воинскими частями, предприятиями и организациями Министерства обороны Российской Федерации
Каждое финансовое сообщение в обязательном порядке проходит регламентные контрольные процедуры: проходит контроль подлинности, структурный контроль, контроль на уникальность и логический контроль При переводе средств между участником-плательщиком и участником-получателем на основании платёжного поручения, платёжного ордера, платёжного поручения на общую сумму с реестром участник-плательщик составляет и направляет ED101, ED105, ED108. Статусная схема процесса обмена приведена ниже.
Если формируется распоряжение на бумажные носители, но платёжная система Банка России составляет электронное сообщение ED101, ED103, ED104, ED105, ED109, ED110, ED111 и направляет участнику на сформированное распоряжение в бумажном виде. Если из-за недостатка денежных средств распоряжение не может быть исполнено, но оно помещается во внутридневную очередь, где хранится до исполнения в течение операционного дня. Если пользователь захочет данное сообщение вывести из очереди, то он отправляет сообщение ED205 или ED805. Не исполненное сообщение в течение операционного дня возвращается пользователю со статусом не исполнено. При достаточном количестве средств платёжное сообщение исполняется в соответствии с регламентом, после чего Банк Росси отправляет участнику подтверждающий документ. В нижеприведённом примере сформировано платёжное поручение (формат Ed101).
<Purpose>ОПЛАТА ПО ДОГОВОРУ 35889-ОТ 20.05.2020 Без учёта НДС 4000 РУБ</Purpose>
</ED101>
В блоке Payer содержатся данные дебитора (плательщика), в блоке Payee содержатся данные кредитора (получателя средств).
В нижеприведённом примере сформировано платёжное поручение (формат Ed501, сообщение свободного формата), согласно стандарту iso:std:iso:20022:tech:xsd:pain.001.001.06
<Ustrd> ОПЛАТА ПО ДОГОВОРУ 35889 ОТ 20.05.2020 Без учета НДС 4000 РУБ </Ustrd>
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry>
<Prtry>POD</Prtry>
</CdOrPrtry>
</Tp>
<RltdDt>2019-04-19</RltdDt>
</RfrdDocInf>
</Strd>
</RmtInf>
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>
В следующих блоках содержится следующая информация:
InitgPty содержит данные инициатора платежа;
Dbtr содержится данные дебитора (плательщика);
DbtrAcct содержится счёт дебитора;
DbtrAg содержатся данные банка плательщика (наименование банка, БИК банка);
DbtrAgtAcct содержится корреспондентский счёт банка;
CdtrAgt содержит банковские реквизиты получателя средств;
CdtrAgtAcct содержится корреспондентский счёт банка;
Cdtr содержится данные кредитора (получателя средств);
CdtrAcct содержится счёт кредитора;
Tax содержит ИНН дебитора и кредитора;
InstdAmt содержит необходимую информацию о сумме и приоритете платежа;
В рамках взаимодействия банков и их клиентов – юридических лиц для обмена финансовыми сообщениями и проверки их статуса существуют следующие форматы и схемы сообщений для обмена:
camt.052.001.08 BankToCustomerAccountReport — Промежуточное извещение об операциях по счету / BankToCustomerAccountReport;
camt.053.001.08 BankToCustomerStatement — Извещение об операциях по счету / BankToCustomerStatement;
camt.054.001.08 BankToCustomerDebitCreditNotification — Извещение о списании/зачислении / BankToCustomerDebitCreditNotification;
pain.001.001.09 CustomerCreditTransferInitiationRouble — Инициирование перевода денежных средств клиентом / CustomerCreditTransferInitiationRouble;
pain.002.001.10 CustomerPaymentStatusReport — Уведомление о результатах контроля на уровне банк-клиент / CustomerPaymentStatusReport
SWIFT откладывает начало миграции на стандарт ISO 20022 с ноября 2021 на конец 2022 года с тем, чтобы дать возможность банкам и их клиентам подготовить инфраструктуру к переходному периоду и получить максимальные преимущества от внедрения нового стандарта.
В сентябре 2018 SWIFT анонсировал сроки миграции мирового сообщества пользователей на новый стандарт, которые предусматривают поэтапный переход на обмен сообщениями ISO 20022, передаваемыми по сети SWIFT с использованием сервисов SWIFTNet и InterAct. Начало миграции (переходного периода) было запланировано на ноябрь 2021, завершение миграции – на ноябрь 2025.
Принимая во внимание отзывы и пожелания мирового финансового сообщества, SWIFT решил перенести начало миграции на сообщения ISO 20022 для трансграничных платежей и отчетности по денежным средствам на конец 2022 года. Напоминаем, что, начиная с этого момента, все пользователи SWIFT должны будут обеспечить прием и обработку сообщений ISO 20022, которые придут на смену сообщениям MT 1, 2 и 9 категорий.
Завершение миграции на ISO 20022 для трансграничных платежей остается прежним – ноябрь 2025 год. Начиная с декабря 2025 года обмен используемыми в настоящее время сообщениями MT категорий 1,2 и 9 в сети SWIFT станет недоступным.
