22 июля, воскресенье 17:22
Bankir.Ru

Объявление

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

АРМ КБР

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

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

    Комментарий


    • ЭЦП - это зашифрованная свертка последовательности байтов.
      Документ в АБС - это коллекция строк из нескольких таблиц. Строка это набор полей разных типов. Некоторые из этих типов могут быть еще и объектными.
      Подписать документ из АБС нельзя. Подписать можно результат его преобразования в промежуточный формат и конкатенации всех этих полей.
      Для того, чтобы такую ЭЦП проверить, мало знать ключ и версию криптографии. Нужно еще знание о версии базы данных (потому что структура таблиц меняется) и о версии АБС,
      Поэтому, те реализации ЭЦП которые в некоторых АБС уже есть - это внутренняя безопасность банка.
      ЦБ нужна подпись XML документа в формате УФЭБС. Значит, эти документы придется генерировать и хранить в самой базе. Например в XML репозитории или в CLOB полях.
      Логически нужен сетевой сервис, которому АБС передает ХML файл на подпись.
      Затем, уже подписанный этим сервисом XML файл должен возвращаться в АБС и проверяться на целостность, а уже потом выгружаться в УАРМ.
      Если думать об этом в категориях государственности, гражданственности и ответственности, можно было бы ждать от ЦБ ПО, реализующего такой сетевой сервис.
      Если думать о реальном положении дел - скоро к компании милых маленьких динозавриков из Юрского Периода - 2 добавится еще один претендент на угощение.

      Комментарий


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

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

        Никаких требований к организации формирования подписей в АБС в письме нет. И не может быть, так как это письмо.

        Они лишь уведомляют, что на вход в АРМ КБР теперь надо подавать файл с уже сформированными КА и ЗК, так как они формировать их отказываются. Где и когда они будут формироваться, ЦБ диктовать банкам в форме письма, к счастью, не может.

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

        Письмо в Омске - о намерениях изменить требования, им это еще предстоит сделать и оформить как положено. Они просто поделились инфой о грядущих требованиях. Когда будет распоряжение, тогда и будет обязательным формирование ЗК по 3-му варианту защиты.

        А издание нормативного акта с требованиями к формированию кодов и подписей в АБС, обязательного к исполнению, подразумевает более полную и четкую проработку вопроса, так как исполнение как-то надо контролировать.

        Комментарий


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

          Комментарий


          • Сообщение от ineshki Посмотреть сообщение
            ЭЦП - это зашифрованная свертка последовательности байтов.
            Документ в АБС - это коллекция строк из нескольких таблиц. Строка это набор полей разных типов. Некоторые из этих типов могут быть еще и объектными.
            Подписать документ из АБС нельзя. Подписать можно результат его преобразования в промежуточный формат и конкатенации всех этих полей.
            Для того, чтобы такую ЭЦП проверить, мало знать ключ и версию криптографии. Нужно еще знание о версии базы данных (потому что структура таблиц меняется) и о версии АБС,
            Поэтому, те реализации ЭЦП которые в некоторых АБС уже есть - это внутренняя безопасность банка.
            ЦБ нужна подпись XML документа в формате УФЭБС. Значит, эти документы придется генерировать и хранить в самой базе. Например в XML репозитории или в CLOB полях.
            Логически нужен сетевой сервис, которому АБС передает ХML файл на подпись.
            Затем, уже подписанный этим сервисом XML файл должен возвращаться в АБС и проверяться на целостность, а уже потом выгружаться в УАРМ.
            Если думать об этом в категориях государственности, гражданственности и ответственности, можно было бы ждать от ЦБ ПО, реализующего такой сетевой сервис.
            Если думать о реальном положении дел - скоро к компании милых маленьких динозавриков из Юрского Периода - 2 добавится еще один претендент на угощение.
            Вы просто привыкли, что АБС строятся на реляционных базах данных, вот для вас документ и является набором полей в базе.

            А есть еще документарные СУБД, которые хранят документы в XML, json или других формах. И прямо в таком виде и обрабатывают. Это бывает реализовано и как надстройка над реляционной базой, и как вообще целиком специальным ядром. Там хранить и проверять подписи для всех документов прямо в процессе обработки на уровне СУБД - не проблема. Просто это обычно работает на порядки медленнее, чем реляционные СУБД, которые за годы эволюции достаточно хорошо оптимизированы.
            А еще бывают графовые СУБД, для которых документ является набором вершин с данными и связей между ними. А база представляет собой набор документов и таких же связей. Со своими языками запросов по таким графам. Для транзакционных систем, правда, пока малопригодны.

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

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

            Комментарий


            • Кстати.

              Сообщение от IKSoft Посмотреть сообщение
              А разве, в данном случае, лицензия на "встраивание" нужна, если банк сам напишет ПО для подписи/шифрования?
              Это же не "деятельность", а "собственные нужды".
              Ни средства на счетах клиентов, ни платежи по ним, никак кроме "информация, защищаемая по закону" не описываются. И это, - ни разу не те "собственные нужды", которые в лицензионных исключениях. Увы. Юристы это нам уже 100500 раз комментировали по поводу персданных.
              /kiv

              Комментарий


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

                Если уж говорить о требованиях:

                Никаких требований к организации формирования подписей в АБС в письме нет. И не может быть, так как это письмо
                С таким подходом у ЦБ, как сейчас, у нас скоро регламент похода в туалет появится, т.к. если сотрудник покидает рабочее место, то есть риск, что он не вовремя обнаружит атаку на банк. Вот вы действительно думаете, что в конечном счёте всё это не выльется в новое положение?

                Комментарий


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

                  Вы просто привыкли, что АБС строятся на реляционных базах данных, вот для вас документ и является набором полей в базе.
                  Ну конечно привык. Современное состояние автоматизации банков не дает никаких оснований для другой привычки. Поэтому схема реальной реализации и будет выглядеть так:
                  1. АБС формирует текст XML файла.
                  2. Этот текст передается сетевому сервису на подпись.
                  3. Сетевой сервис подписывает документ и возвращает его АБС.
                  4, АБС сверяет реквизиты ЭД из файла с реквизитами ЭД в базе данных.
                  5. Подписанный документ выгужается в УАРМ и складывается в хранилище в самой БД.

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

                  Комментарий


                  • Добрый день!
                    Южное ТУ (Краснодар) разослало письмо, в котором просило считать информацию о передаче СКАД Сигнатура разработчикам АСК недействительной. Кто-нибудь что-нибудь понимает?

                    Комментарий


                    • Сообщение от pol1234 Посмотреть сообщение
                      Добрый день!
                      Южное ТУ (Краснодар) разослало письмо, в котором просило считать информацию о передаче СКАД Сигнатура разработчикам АСК недействительной. Кто-нибудь что-нибудь понимает?
                      О как, неожиданно )

                      Комментарий


                      • Сообщение от pol1234 Посмотреть сообщение
                        Добрый день!
                        Южное ТУ (Краснодар) разослало письмо, в котором просило считать информацию о передаче СКАД Сигнатура разработчикам АСК недействительной. Кто-нибудь что-нибудь понимает?
                        Напоминает женское "Ой, всё"

                        Комментарий


                        • Сообщение от pol1234 Посмотреть сообщение
                          Добрый день!
                          Южное ТУ (Краснодар) разослало письмо, в котором просило считать информацию о передаче СКАД Сигнатура разработчикам АСК недействительной. Кто-нибудь что-нибудь понимает?
                          Возможно, вы ошиблись. Похоже, речь идет только об отказе (временном?) от ранее данного разрешения на использование СКЗИ, отличных от «Сигнатуры».

                          Комментарий


                          • Цитата: "Информацию, приведенную в шестом абзаце письма ДИТ от 13,01,2017 "О передаче СКАД Сигнатура" исключить".

                            Комментарий


                            • Сообщение от pol1234 Посмотреть сообщение
                              Цитата: "Информацию, приведенную в шестом абзаце письма ДИТ от 13,01,2017 "О передаче СКАД Сигнатура" исключить".
                              А в этом абзаце разве не про альтернативные СКЗИ речь?
                              Просто нам пришло аналогичное письмо, и оно «отменяет» только альтернативные СКЗИ.

                              Комментарий


                              • А в Краснодаре вот так.

                                Комментарий


                                • Сообщение от pol1234 Посмотреть сообщение
                                  Цитата: "Информацию, приведенную в шестом абзаце письма ДИТ от 13,01,2017 "О передаче СКАД Сигнатура" исключить".
                                  У нас (Южное ГУ Отделение по РО) речь шла "о пятом абзаце". про СКЗИ, отличные от Сигнатуры
                                  Может, у вас обсчитались?

                                  Комментарий


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

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

                                    Вопрос еще и в другом: АРМКБР позволяет, и некоторые банки используют взаимодействие АБС-АРМКБР напрямую через Oracle.
                                    Каким образом в этом случае обеспечивать установку/верификацию ЗК и КА.

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

                                    Комментарий


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


                                      Вопрос еще и в другом: АРМКБР позволяет, и некоторые банки используют взаимодействие АБС-АРМКБР напрямую через Oracle.
                                      Каким образом в этом случае обеспечивать установку/верификацию ЗК и КА.
                                      АРМ КБР не умеет взаимодействие только напрямую через Oracle, как минимум хранилища exg\cli и exg\chk в АРМ КБР только файловые.

                                      Комментарий


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

                                        Криптография в АРМКБР останется.. шифрование/дешифрование никуда не переносилось, так там и останется.
                                        Откуда такая уверенность?
                                        Последний раз редактировалось Шигапов Кирилл; 31.01.2017, 17:29.

                                        Комментарий


                                        • Сообщение от Шигапов Кирилл Посмотреть сообщение

                                          Откуда такая уверенность?
                                          Из письма МЦОИ, о переносе из АРМа в АБС функции простановки КА/ЗК. Про шифрование не было ни слова. А что РБК/Лента круто облажались в своих статьях о переносе в АБС шифрования (про подпись там вообще ни слова не было), ну то такэ.

                                          Комментарий


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

                                            Комментарий


                                            • Сообщение от КрасКрипт Посмотреть сообщение
                                              Какой вообще смысл в АРМ КБР будет если ЗК/КА он не занимается, ручного ввода документов нет?
                                              Обработка входящих документов.
                                              Мониторинг.
                                              Разбор конфликтных ситуаций.
                                              Ведение архивов (кривоватое...).

                                              кто больше ?

                                              Комментарий


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

                                                Обработка входящих документов.
                                                Мониторинг.
                                                Разбор конфликтных ситуаций.
                                                Ведение архивов (кривоватое...).

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

                                                Комментарий


                                                • Сообщение от gf Посмотреть сообщение
                                                  кто больше ?
                                                  Пошли по второму кругу
                                                  Сообщение от S-H Посмотреть сообщение
                                                  Шифрование/дешифрование, сжатие, формирование служебного конверта, транспортные функции.

                                                  Комментарий


                                                  • Сообщение от КрасКрипт Посмотреть сообщение
                                                    - конфликтные ситуации это полюбому коснется ЗК/КА, которых в КБР не будет
                                                    Хм... А вот это уже вопрос. Вроде были какие-то требования из которых вытекало, что порядок разбора конфликтных ситуаций должен быть установлен.
                                                    Т.е. в данном случае ЦБ всё равно должен иметь какое-то ПО, которое будет доступно и может быть использовано для проверки подписи.

                                                    Комментарий


                                                    • Сообщение от Berckut Посмотреть сообщение
                                                      Хм... А вот это уже вопрос. Вроде были какие-то требования из которых вытекало, что порядок разбора конфликтных ситуаций должен быть установлен.
                                                      Т.е. в данном случае ЦБ всё равно должен иметь какое-то ПО, которое будет доступно и может быть использовано для проверки подписи.
                                                      КА/ЗК/Шифрование все равно будет производиться с использованием внешних сертифицированных криптосредств (та-же Сигнатура), а в Сигнатуре вроде как есть свой штатный АРМ разбора конфликтных ситуаций

                                                      Комментарий


                                                      • ЗК/КА/Шифрование, насколько я понимаю, будут использовать один комплект ключей. Т.е. один ключ придется грузить в 2 системы.

                                                        Сообщение от S-H Посмотреть сообщение
                                                        Шифрование/дешифрование, сжатие, формирование служебного конверта, транспортные функции.
                                                        По поводу транспортных функций - есть серьезные сомнения: вроде, для этого приспособили УТА.
                                                        Если известен (жестко прописан) алгоритм шифрование/дешифрования, сжатия, формирования служебного конверта, то, раз ключи уже загружены в АБС, можно там же довести отправляемые документы до "логического конца". И обратно - раскрутить транспортный конверт, расшифровать, проверить подпись.

                                                        Комментарий


                                                        • Сообщение от gf Посмотреть сообщение
                                                          ЗК/КА/Шифрование, насколько я понимаю, будут использовать один комплект ключей. Т.е. один ключ придется грузить в 2 системы.
                                                          не факт.. могут и разнести, поскольку ЗК предполагается использовать только на участке АБС-АРМКБР, а шифрование - только на участке обмена с ЦБ
                                                          Последний раз редактировалось Setevoy; 02.02.2017, 12:17.

                                                          Комментарий


                                                          • Сообщение от gf Посмотреть сообщение
                                                            ЗК/КА/Шифрование, насколько я понимаю, будут использовать один комплект ключей. Т.е. один ключ придется грузить в 2 системы.
                                                            Это уже обсуждали на 10-й странице.

                                                            Сообщение от S-H Посмотреть сообщение
                                                            И ключи у АБС и АРМ КБР будут разные.
                                                            Сообщение от S-H Посмотреть сообщение
                                                            АРМ КБР не будет иметь доступа к ключам КА/ЗК.
                                                            Сообщение от Unreg Посмотреть сообщение
                                                            Думаете, они разделят ключ (как для ФСФМ)?
                                                            Сообщение от S-H Посмотреть сообщение
                                                            Я тоже усомнился и после совещания задал вопрос ЦБ. Ответили, что разделят.
                                                            Сообщение от ForrUser Посмотреть сообщение
                                                            В заявке на изготовление ключей регистрации указывается тип ключа - совмещенный (подпись и шифрование) или раздельный (только подпись или только шифрование).


                                                            Комментарий


                                                            • Так забавно общаться с ТУ... Какой останется функционал в КБР - они не знают. Как будет организована схема работы - они не знают. Хочу получить комплект разработчика Сигнатуры - выдать не могут.

                                                              Комментарий

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

                                                              Свернуть

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

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