15 октября, понедельник 11:07
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

АРМ КБР

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Сообщение от Unreg Посмотреть сообщение
    А они хотя бы проверку КА в АРМ-е оставят?
    Сообщение от ForrUser Посмотреть сообщение
    Это было бы логично.
    Согласен. Но у ЦБ еще нет нового АРМа, только к июню сделать обещают.

    Комментарий


    • Сообщение от Berckut Посмотреть сообщение


      Мы вчера ещё письмо с планом работ получили.
      Нам письма не было. Можно с ним ознакомиться? Адрес: se59@mail.ru

      Комментарий


      • Сообщение от se59 Посмотреть сообщение
        Нам письма не было
        На сайте ЦБ есть:
        http://www.cbr.ru/mcirabis/acyoc/Inf_Mci_3(2017).pdf

        Комментарий


        • Ну вот и нам пришло официальное письмо. Быстро они, однако.

          Согласно этому письму нужно будет каждое(!) сообщение снабжать ЗК, а потом уже пакет (файл) – КА.
          Кто-нибудь разбирался, это действительно так? Или опять очередной вброс?
          А то ведь, одно дело ЗК на весь пакет и совсем другое дело – на каждое сообщение в пакете!


          p.s.
          Зато желающим разрешили использовать КриптоПро и Валидату. Но в отличие от Сигнатуры, уже за деньги. А вот про VipNet ничего не написали.

          Комментарий


          • Сообщение от Unreg Посмотреть сообщение
            Согласно этому письму нужно будет каждое(!) сообщение снабжать ЗК, а потом уже пакет (файл) – КА. Кто-нибудь разбирался, это действительно так? Или опять очередной вброс?
            Декларировано, что формат и правила не меняются. А согласно форматам УФЭБС ЗК делается на сообщение (пакет сообщений).
            При формировании ЗК для выделения данных, защищаемых ЗК, выполняются следующие действия:

            Формируется XML-документ, корневым элементом которого является элемент, содержащий подписываемое ЭС (пакет ЭС) (со всеми его дочерними элементами и атрибутами).

            Из корневого элемента удаляются все элементы dsig:SigValue, являющиеся дочерними

            Комментарий


            • Сообщение от S-H Посмотреть сообщение
              Декларировано, что формат и правила не меняются. А согласно форматам УФЭБС ЗК делается на сообщение (пакет сообщений).
              Вот если бы!
              В действующей схеме на один файл – 1 ЗК и 1 КА.
              В новой – n * ЗК и 1 КА. (где n – количество сообщений в файле).

              Причем они хотят, что бы мы формировали ЗК сразу при вводе платежного документа. Что особенно умиляет в свете требуемого количества средств СКЗИ, периодических смен ключей и постоянных изменений в УФЭБС-ах.

              Хотя, может, одумаются и оставят схему 1 ЗК и 1 КА.

              Комментарий


              • Сообщение от Unreg Посмотреть сообщение

                ...
                В действующей схеме на один файл – 1 ЗК и 1 КА.
                В новой – n * ЗК и 1 КА. (где n – количество сообщений в файле).

                ...
                По действующей схеме УФЭБС УФЭБС_2015_4_0_Защита_ЭС.pdf КО могут использовать для защиты вариант 1 из Таблицы 1 - один КА на пакет/сообщение. Из инф. сообщения №3 явственно не следует, что КО должны теперь использовать для защиты варианты 2 или 3 - "Количество КА и ЗК на ЭС (пакете ЭС), которые передаются при обмене с КО/ОК, зависит от варианта защиты (см.т а б л и ц а 1)". ИМХО.

                Комментарий


                • И, как всегда, вопросов больше, чем ответов))). Ну хотят они убрать функцию установки КА/ЗК из АРМ-а и передать ее на сторону КО в АБС - мысль здравая с их точки зрения (они не несут ответственность за "левые" ЭС на входе в АРМ). Ну получим мы раздельные ключи (при использовании Сигнатуры)- отдельно подпись, отдельно шифрование. Ну изменится формат входного в АРМ сообщения. А дальше начинается интересное:

                  Сообщение от Unreg Посмотреть сообщение
                  Ну вот и нам пришло официальное письмо. Быстро они, однако.
                  ...
                  p.s.
                  Зато желающим разрешили использовать КриптоПро и Валидату. Но в отличие от Сигнатуры, уже за деньги. А вот про VipNet ничего не написали.
                  1. Допустим, КО для КА/ЗК использует КриптоПро. Будет ли АРМ проверять КА/ЗК на ЭС на входе по сертификату открытого ключа?
                  2. Как на стороне МЦОИ будет осуществлена проверка (и будет ли) КА/ЗК, установленных с помощью КриптоПро? Процедура передачи сертификатов в МЦОИ пока не определена. Или будет как сейчас при работе с запросами из ЦИК? Просто по почте им сертификат послать и все? Сейчас МЦОИ нам ключи выпускает - все официально, подписи/печати, отпечатки пальцев))). А так нам УЦ будет выпускать квалифицированную подпись и дальше наши действия?
                  3. Шифрование остается на Сигнатуре? Если да, то при использовании отличных от Сигнатуры СКЗИ на КА/ЗК у нас увеличивается число ключей с разными сроками действия - КриптоПро на год, Сигнатура на полтора. А оно нам надо?)))
                  4. МЦОИ на КО что будет использовать - Сигнатуру или КриптоПро/Валидату? Или так - этому Сигнатуру, а этому КриптоПро? Значит, с каждым УО надо заключать допник к договору на использование тех или иных СКЗИ. А оно им надо так усложнять?

                  Много, много вопросов. Будем посмотреть)))

                  Комментарий


                  • Сообщение от ForrUser Посмотреть сообщение
                    Из инф. сообщения №3 явственно не следует, что КО должны теперь использовать для защиты варианты 2 или 3

                    Это следует из письма нашего ТУ (см. вложение):
                    Нажмите на изображение для увеличения. 

Название:	ka_zk.jpg 
Просмотров:	1 
Размер:	192.2 Кб 
ID:	4775840

                    Остается только надеяться, что ЦБ всё-таки смягчит свои требования.

                    Комментарий


                    • Сообщение от Unreg Посмотреть сообщение


                      Это следует из письма нашего ТУ (см. вложение):

                      Остается только надеяться, что ЦБ всё-таки смягчит свои требования.
                      Как интересно - существует, как минимум 2 редакции Инф. сообщения №3. В нашем ни слова нет про "рекомендации по снижению рисков хищения"

                      Комментарий


                      • Сообщение от ForrUser Посмотреть сообщение
                        1. Допустим, КО для КА/ЗК использует КриптоПро. Будет ли АРМ проверять КА/ЗК на ЭС на входе по сертификату открытого ключа?
                        Надеюсь, иначе в чём смысл разделения? В таком сценарии будет обеспечена защита на этапе передачи.

                        Сообщение от ForrUser Посмотреть сообщение
                        2. Как на стороне МЦОИ будет осуществлена проверка (и будет ли) КА/ЗК, установленных с помощью КриптоПро? Процедура передачи сертификатов в МЦОИ пока не определена. Или будет как сейчас при работе с запросами из ЦИК? Просто по почте им сертификат послать и все? Сейчас МЦОИ нам ключи выпускает - все официально, подписи/печати, отпечатки пальцев))). А так нам УЦ будет выпускать квалифицированную подпись и дальше наши действия?
                        Ничего не изменится: "Сообщаем, что для встраивания в АСК, с возможностью организации ее взаимодействия с ПС КБР, могут также использоваться СКЗИ, отличные от СКАД «Сигнатура», производимые как ООО «КриптоПро», так и ООО «Валидата», позволяющие обеспечить возможность встречной работы со СКАД «Сигнатура» в условиях применения криптографических ключей, изготавливаемых с использованием удостоверяющих центров Банка России. Для приобретения указанных СКЗИ необходимо обращаться непосредственно к организациям-производителям".

                        Сообщение от ForrUser Посмотреть сообщение
                        3. Шифрование остается на Сигнатуре? Если да, то при использовании отличных от Сигнатуры СКЗИ на КА/ЗК у нас увеличивается число ключей с разными сроками действия - КриптоПро на год, Сигнатура на полтора. А оно нам надо?)))
                        Не проблема. Зато отправку можно отделить от подписи. Это может быть логичным и даже удобным. Часто отправкой и так ИТ подразделения занимаются (особенно в небольших банках и филиалах). Сейчас они смогут это делать официально.

                        Сообщение от ForrUser Посмотреть сообщение
                        4. МЦОИ на КО что будет использовать - Сигнатуру или КриптоПро/Валидату? Или так - этому Сигнатуру, а этому КриптоПро? Значит, с каждым УО надо заключать допник к договору на использование тех или иных СКЗИ. А оно им надо так усложнять?
                        Они все совместимы на уровне форматов. ЦБ будет всё Сигнатурой проверять.


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

                        Комментарий


                        • Сообщение от Zuz Посмотреть сообщение
                          ...
                          Ничего не изменится: "Сообщаем, что для встраивания в АСК, с возможностью организации ее взаимодействия с ПС КБР, могут также использоваться СКЗИ, отличные от СКАД «Сигнатура», производимые как ООО «КриптоПро», так и ООО «Валидата», позволяющие обеспечить возможность встречной работы со СКАД «Сигнатура» в условиях применения криптографических ключей, изготавливаемых с использованием удостоверяющих центров Банка России. Для приобретения указанных СКЗИ необходимо обращаться непосредственно к организациям-производителям".


                          Они все совместимы на уровне форматов. ЦБ будет всё Сигнатурой проверять.

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

                          Комментарий


                          • Сообщение от ForrUser Посмотреть сообщение
                            И два - при работе с ЦИКом и использовании КриптоПро необходимо подключение к Интернету для проверки подлинности сертификатов.
                            По моему, подлинность можно проверить, имея загруженный сертификат УЦ. Интернет нужен для проверки его действительности, т.е. что сертификат еще не отозвали. А сейчас сертификаты таким образом проверяются?

                            Комментарий


                            • Кто-нибудь уже говорил с разработчиками о сроках?

                              PS. Почему бы ЦБ не сделать так: Корневой УЦС (ЦБ) - промежуточный УЦС (банк) - сертификаты (оператор)?

                              UP: в принципе, так и написано: "в условиях применения криптографических ключей, изготовляемых с использованием УЦ Банка России" стр.2, абзац 2
                              Последний раз редактировалось godata; 23.01.2017, 10:00.

                              Комментарий


                              • Сообщение от ForrUser Посмотреть сообщение
                                Это все понятно. Но как будет, по их мнению, организована передача сертификатов ключей в МЦОИ, выпущенных не ЦУКС МЦОИ? Это раз. И два - при работе с ЦИКом и использовании КриптоПро необходимо подключение к Интернету для проверки подлинности сертификатов. По ИБ АБС не должна иметь доступ во вне. Как быть в таком случае? И о совместимости форматов - удалось подружить СКАД Смгнатура и, к примеру, СКЗИ КриптоПро. Вот Таском с СКЗИ КриптоПро нам удалось подружить.
                                1. Не понял, ведь, сертификаты судя из процитированного мной, делает только УЦ ЦБ.
                                2. CRL / сертификаты могут быть загружены и установлены локально. Опять же взаимодействие АБС на исходящий трафик даже в Интернет к строго контролируемым хостам не несёт особой опасности. Такие соединения теоретически можно эксплуатировать, но фактически это очень сложно. Более того они могут строго контролироваться прикладными файрволами. Хотя сейчас списки отозванных сертификатов через Интернет ЦБ не предоставляются и вряд ли будут предоставляться.
                                3. Насколько понимаю совместимость есть в рамках RFC типа RFC 7091 на ГОСТ Р 34.10-2012. Что значит "подружить"?

                                Комментарий


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

                                  Только я еще раз обращу внимание коллег, что в новом АРМе не будет ручного ввода сообщений вообще. Включая ED501, ED503, ED243 и т.д. и т.п.
                                  Или никто этим не пользуется?

                                  Комментарий


                                  • Сообщение от S-H Посмотреть сообщение

                                    По моему, подлинность можно проверить, имея загруженный сертификат УЦ. Интернет нужен для проверки его действительности, т.е. что сертификат еще не отозвали. А сейчас сертификаты таким образом проверяются?
                                    2. CRL / сертификаты могут быть загружены и установлены локально.
                                    Да, при каждой процедуре расшифрования/снятие/проверки подписи лезет в интернет и проверяет подлинность сертификата. Если нет доступа в инет - сообщение от том, что сертификат корректен, но доверия к нему нет))). Он и установлен локально, но проверка его осуществляется через инет
                                    Последний раз редактировалось ForrUser; 23.01.2017, 11:25.

                                    Комментарий


                                    • Сообщение от S-H Посмотреть сообщение

                                      ...

                                      Только я еще раз обращу внимание коллег, что в новом АРМе не будет ручного ввода сообщений вообще. Включая ED501, ED503, ED243 и т.д. и т.п.
                                      Или никто этим не пользуется?
                                      Пользуемся и очень активно, например, платежи со счета ДУ. И что теперь получается, чтобы направить запрос встречки, остатка и т.д. надо лезть в АБС?)))
                                      Кстати, тот же КриптоПро является УЦ ЦБ РФ по 63-фз

                                      Комментарий


                                      • Сообщение от Zuz Посмотреть сообщение
                                        ...
                                        3. Насколько понимаю совместимость есть в рамках RFC типа RFC 7091 на ГОСТ Р 34.10-2012. Что значит "подружить"?
                                        На практике. По описанию все хорошо.

                                        Комментарий


                                        • Сообщение от ForrUser Посмотреть сообщение
                                          И что теперь получается, чтобы направить запрос встречки, остатка и т.д. надо лезть в АБС?)))
                                          Да, надо будет лезть в АБС. Ну, или кто-то что-то придумает дополнительно... И продаст банкам за стотыщьпятьсот миллионов.

                                          Комментарий


                                          • Сообщение от S-H Посмотреть сообщение

                                            Да, надо будет лезть в АБС. Ну, или кто-то что-то придумает дополнительно... И продаст банкам за стотыщьпятьсот миллионов.
                                            Да даже ЕД999 только через АБС! Это уже перебор)))

                                            Комментарий


                                            • Сообщение от Unreg Посмотреть сообщение


                                              Это следует из письма нашего ТУ (см. вложение):
                                              Нажмите на изображение для увеличения. 

Название:	ka_zk.jpg 
Просмотров:	1 
Размер:	192.2 Кб 
ID:	4775840

                                              Остается только надеяться, что ЦБ всё-таки смягчит свои требования.
                                              В письме рекомендация, а не требование.
                                              ЦБ вообще письмом не может устанавливать требования к организации работы в банке и к АБС банка. Для этого нужен нормативный документ - положение, указание или инструкция. И контроль за соблюдением.

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

                                              До такого уровня контроля документов в коммерческих АБС еще не дошли, дорого это и работает медленно.

                                              Никто формировать защитный код для каждого документа в АБС в момент создания или в момент выполнения проводки не заставляет. Пока еще.

                                              Комментарий


                                              • Сообщение от Полковник Посмотреть сообщение

                                                До такого уровня контроля документов в коммерческих АБС еще не дошли, дорого это и работает медленно.

                                                Никто формировать защитный код для каждого документа в АБС в момент создания или в момент выполнения проводки не заставляет. Пока еще.
                                                Что тут дорогого или медленного - в наложении ЭЦП на каждый документ? Давным-давно надо было сделать.
                                                Jeca

                                                Комментарий


                                                • Jeca

                                                  Навскидку:
                                                  Встраивать криптографию и периодически её менять. Плюс - периодически менять ключи.
                                                  А теперь посмотрим: за какой период у вас хранятся документы? И сколько раз за это время менялись ключи, не говоря даже о системах криптографии?

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

                                                  Комментарий


                                                  • Сообщение от Полковник Посмотреть сообщение
                                                    Никто формировать защитный код для каждого документа в АБС в момент создания или в момент выполнения проводки не заставляет. Пока еще.
                                                    Пока не заставят - никто делать этого не будет. И не потому, что будто бы дорого (в RS-Bank V.6 есть давно, вроде в базовой поставке) или медленно (решаемо). А потому что нет причины это делать.

                                                    Комментарий


                                                    • Сообщение от Unreg Посмотреть сообщение
                                                      Jeca

                                                      Навскидку:
                                                      Встраивать криптографию и периодически её менять. Плюс - периодически менять ключи.
                                                      А теперь посмотрим: за какой период у вас хранятся документы? И сколько раз за это время менялись ключи, не говоря даже о системах криптографии?

                                                      Полагаю, что неизменность документов можно обеспечить по-другому.
                                                      Это только кажется сложным, хотя на самом деле вопрос вполне решаем. В всяких клиент-банках криптография встроена, ключи периодически меняются, документы в базе хранятся вечно - вот Вам полная аналогия, которая прекрасно работает и не вызывает трепета и ужаса. На той же самой Украине это было сделано 20 лет тому назад - каждый документ в АБС подписан ЭЦП операциониста, внешний пакет еще подписан ЭЦП бухгалтера и ЭЦП АРМ-3 банка (по-нашему АРМ КБР). После чего аппаратно зашифрован и отправлен. Раз в два-три месяца полная смена всех ключей установленным порядком. И никаких особых тормозов.
                                                      Jeca

                                                      Комментарий


                                                      • Сообщение от Unreg Посмотреть сообщение

                                                        Остается только надеяться, что ЦБ всё-таки смягчит свои требования.
                                                        Сегодня нам пришло дополнительное письмо счастья по этому всему поводу. Цитирую то, что касается именно варианта защиты и используемых СКЗИ

                                                        =======
                                                        Отделение по Омской области Сибирского главного управления Центрального банка Российской Федерации, в дополнение к письму от 20.01.2017 № Т652-11-4-10/701 сообщает, что Банком России планируется внедрение следующих вариантов защиты электронных сообщений (ЭС) и пакетов ЭС в действующей платежной системе Банка России.

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

                                                        Все исходящие ЭС (пакеты ЭС) из платежной системы Банка России должны быть снабжены двумя электронными подписями - ЗК контура обработки и КА контура контроля.

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

                                                        В качестве срока внедрения указанной технологии планируется:
                                                        • комплексное тестирование с 28.08.2017;
                                                        • внедрение в постоянную эксплуатацию 02.10.2017.

                                                        Использование варианта защиты будет определяться индивидуально для каждого клиента путём установки соответствующего признака.

                                                        Обращаем внимание, что возможность встраивания СКЗИ, отличных от СКАД «Сигнатура», указанная в письме от 20.01.2017 № Т652-11-4-10/701, в настоящее время уточняется. До доведения дополнительной информации такие СКЗИ не должны использоваться при организации доработки автоматизированных систем клиента.
                                                        =======
                                                        /kiv

                                                        Комментарий


                                                        • Читая разборки на эту тему у меня закрались сомнения. А кто вообще как понял новые будущие требования? В смысле на каком уровне должна производиться подпись документа?
                                                          Условно АБС можно разделить на 3 части: база данных, ядро, клиент АБС.
                                                          В базе данных нечего подписываться не будет.
                                                          Если будет подписывать ядро, то значит ключи надо разместить на сервер, т.е. получаем конфликт интересов и нарушение требований 382-П, т.к. администратор сервера имеет доступ к ключам и, соответственно, может подписывать платёжные документы. Причём, если сейчас они у меня хранятся на токенах, то потом они будут лежать в открытом виде и могут быть свободно скопированы.
                                                          Если подписывает клиент АБС, то у нас появляются:
                                                          - дополнительные требования по защите канала связи между АБС и клиентом АБС;
                                                          - нам надо каким-то образом исключить возможность подписи документов на компьютерах, которые не защищены по требованиям 552-П;
                                                          - нам надо как-то исключить возможность повседневной работы на этом компьютере.

                                                          В общем, куда ни кинь всюду клин. Так всё таки, где подписывать-то должны? Я решил, что на уровне ядра АБС.

                                                          Комментарий


                                                          • Сообщение от Berckut Посмотреть сообщение
                                                            А кто вообще как понял новые будущие требования? В смысле на каком уровне должна производиться подпись документа?
                                                            Я эти требования понял буквально так, как они написаны. Да, была проблема, что в типовой концигурации на вход АРМ КБР попадал неподписанный файл из АБС, и никак невозможно было понять - этот файл вообще тот самый файл, который авторизованный пользователь АБС хотел отправить по корсчету, или какой то другой файл.

                                                            Решение принято в духе времени. "Отныне, мы принимаем только подписанные файлы". А кто, как, на каком основании подпишет этот самый файл той самой сигнатурой, каким он образом убедится, что то что он своей сигнатурой подписывает - действительно то, что нужно было подписать сигнатурой etc - это теперь не проблемы ни Банка России, ни какого либо его отдела или подразделения. А только и исключительно, - банков-участников, получите, распишитесь.

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

                                                            Хотим ли мы (банк) делать web- или какой другой api- метод, который будет ставить ЗК на УФЭБС-представление документа, зваться из АБС, и возвращаемое методом значение будет сохраняться в АБС для последующей выгрузки в пакет платежей - вопрос открытый. Мне вот не очевидно, будет ли такая схема более защищенной от инжекта, чем предыдущая, или менее. Но по крайней мере такой вариант тоже есть.
                                                            /kiv

                                                            Комментарий


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

                                                              Сообщение от Илюха Посмотреть сообщение
                                                              Хотим ли мы (банк) делать web- или какой другой api- метод, который будет ставить ЗК на УФЭБС-представление документа, зваться из АБС, и возвращаемое методом значение будет сохраняться в АБС для последующей выгрузки в пакет платежей - вопрос открытый. Мне вот не очевидно, будет ли такая схема более защищенной от инжекта, чем предыдущая, или менее.
                                                              Мне кажется, если в эту схему добавить внутренний ключ, то некоторая защищенность появляется.
                                                              Последний раз редактировалось S-H; 24.01.2017, 11:12.

                                                              Комментарий

                                                              Пользователи, просматривающие эту тему

                                                              Свернуть

                                                              Присутствует 1. Участников: 0, гостей: 1.

                                                              Обработка...
                                                              X