АРМ КБР-Н — день Х скоро придет, кто не подготовился сам виноват
Переход клиентов Банка России на новые АРМ – замена АРМ КБР:
Планируемый срок окончания миграции на новый ПК АРМ КБР-Н – 28.06.2019.
После негладкого запуска обмена через «ТШ КБР», стал более тщательно изучать дорожную карту Банка России, в части новых комплексов.
Банк России отбросил от себя часть функций (в части снабжения участников обмена программным обеспечением для выполнения всего спектра функций обмена по УФЭБС).
На сайте Банка России, выложена документация по новыми программным комплексам.
Как оказалось АРМ КБР-Н- это сильно кастрированное издание.
Сейчас при обмене через АРМ КБР можно организовать полнофункциональный обмен пакетами, см. картинку.
АРМ КБР-Н только шифрует(расшифрует) и отправляет(принимает) пакеты в(из) ТШ КБР, см. картинку.
Есть набор функций, которые однозначно не будут реализованы в новом комплексе ПК АРМ КБР-Н:
Что делать с теми функциями, которые ушли из старого АРМ КБР и не появились в новом АРМ КБР-Н:
Нашел три подходящие кандидатуры для замены старого АРМ КБР (комплексы, не интегрированные в АС-клиента):
Переход на дополнительное ПО однозначно необходим, в «блокноте» пакеты по форматам УФЭБС не напишешь.
Может есть еще и другие, готовые и оттестированные решения? Буду рад, если кто-то сообщит ссылки на них!
Попутно всплыли еще вопросы:
Проектирование АРМ работника кредитного отдела банка
Рассмотрение проектирования локального автоматизированного рабочего места (АРМ) управленческого персонала банка. Организационно-экономическая сущность задачи. Ведение автоматизированного учета и хранение сведений обо всех клиентах и договорах с ними.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 06.04.2014 |
| Размер файла | 973,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Министерство образования Российской Федерации.
Санкт-Петербургский государственный инженерно-экономический университет
Институт информационных систем в экономике и управлении
Кафедра информационных систем в экономике
по проектированию информационных систем в экономике
“ПРОЕКТИРОВАНИЕ АРМ РАБОТНИКА КРЕДИТНОГО ОТДЕЛА БАНКА”
Герасимов Дмитрий Александрович
д.э.н., проф. Соколов Роман Владимирович
3. Анализ предметной области
4. Обоснование состава задач АРМ
5. Проектирование иерархического меню
6. Описание постановки задачи
6.1 Организационно-экономическая сущность задачи
6.2 Документы предметной области, содержащие информацию, необходимую для решения задачи
6.3 Входная запросная информация
6.4 Описание выходной информации
6.5 Описание технологии и алгоритмов решения задачи
6.6 Работа пользователя с выходной информацией для принятия решений
7. Проектирование базы данных
8. Проектирование экранных форм
9. Проектирование отчётов
10. Программная реализация проекта
11. Заключение и анализ результатов
12.1 Распечатки экранов ПК
12.2 Контекстные диаграммы потоков данных
12.3 Отчеты АРМ «Кредитный отдел»
12.4 Инструкция пользователя АРМ «Кредитный отдел»
12.5 Рекламный проспект
13. Библиографический список
Целью курсового проектирования является получение практических навыков в проектировании локального автоматизированного рабочего места (АРМ) управленческого персонала. В качестве предметной области мною выбрана работа сотрудника кредитного отдела банка. Проектирование АРМ работника кредитного отдела осуществляется с использованием реляционных баз данных (на основе СУБД Microsoft Access).
Сферой применения АРМа является решение комплекса задач связанных с выдачей кредитов физическим лицам и с заключением соответствующих договоров. Этот комплекс решается в несколько этапов, каждому из которых соответствуют собственные задачи. Результатом решения задач АРМа является обеспечение автоматизированного учета договоров. автоматизированный учет банк проектирование
Пользователем АРМа является работник кредитного отдела банка. Для автоматизации задач, связанных с выдачей кредитов и разрабатывается база данных «Кредитный отдел».
3. Анализ предметной области
Согласно поставленному заданию можно представить, что экономическим объектом является коммерческий банк. Также можно предположить, что фирма является достаточно большим предприятием со своей инфраструктурой. В дальнейшем фирма будет называться ОАО «Выборгский банк».
В настоящее время фирма ОАО «Выборгский банк» является быстро развивающейся и конкурентоспособной, и для того чтобы не потерять и укрепить свои позиции на рынке, она использует новейшие технические средства и программы. Причем программы постоянно совершенствуются и создаются новые улучшенные версии, также разрабатываются новые более совершенные базы данных. Последней из таких разработок является база данных «Кредитный отдел», которая позволит организовать на более качественном уровне хранение, учет, нахождение и отображение запрашиваемой информации. Данная база будет включать в себя все необходимые сведения о договорах с клиентами.
Основные цели, для достижения которых создана база данных «Кредитный отдел»:
ь Обеспечение работникам более быстрого и удобного поиска необходимой информации;
ь Обеспечение порядка размещения уже хранящихся и поступающих данных;
ь Тщательное отслеживание изменений данных;
ь Обеспечение большей защиты информации от несанкционированного доступа.
Автоматизированный учет информации позволяет наиболее достоверно, быстро и безошибочно собирать и производить различные операции с данными. А значит, позволит быстрее и качественнее выполнять работнику заказы, не отвлекаясь на перепроверку данных.
Рис.1. Организационная структура ОАО «Выборгский банк»
4. Обоснование состава задач АРМ
Несмотря на достаточно стабильную номенклатуру банковских услуг, их реализация в виде последовательности технологических этапов и прие-мов может различаться.
Сравнивая работу различных банков и оценивая возможность автома-тизации их деятельности, приходится констатировать практическое отсут-ствие унификации и стандартизации банковских технологий. Технологии выполнения одноименных банковских операций отличаются в различных банках, наблюдается несоответствие целей и функций для одноименных автоматизированных участков, разнообразие в технологии документиро-вания одноименных операций, различие форм отчетности, периодично-сти их представления на разных участках управления в связи со специа-лизацией работников.
Использование компьютера позволяет расширить применение эконо-мико-математических методов в управлении, т.е. не просто ускорить об-работку информации методом прямого счета, а оптимизировать некото-рые процессы (например, распределение и размещение мобилизованных средств). При этом время на обработку снижается настолько, что это ска-зывается на повышении оперативности проведения расчетов и, следова-тельно, на повышении оперативности принимаемых решений. Появляет-ся возможность расширения спектра оказываемых услуг, повышения их качества и расширения географии за счет более полного использования средств телекоммуникаций.
АРМ сотрудника кредитного отдела обеспечивает заклю-чение и ведение договора, его пролонгацию и закрытие (поступление в архив), формирование графиков погашения основного долга и выплаты процентов по различным схемам, а также контроль выполнения этих гра-фиков и начисление пеней по основной части долга и по процентам. При этом формируется ряд ведомостей. АРМ поддерживает стандартные и ин-дивидуальные процентные ставки: по основной части долга, за неисполь-зованный кредит (если это не указано в договоре), за просроченный воз-врат ссуды или за несвоевременную выплату процентов за кредит.
АРМ сотрудника по работе с физическими лицами все чаще включает-ся в состав БИС, что обусловлено необходимостью привлечения средств от физических лиц, хотя эти операции связаны с большой трудоемкостью из-за массовости. В основном они носят характер депозитных операций, и поэтому данный АРМ принципиально отличается от АРМ сотрудника де-позитного отдела лишь специфическим набором оказываемых услуг.
База данных «Кредитный отдел» создается для автоматизации работы кредитного отдела по выдаче кредитов физическим лицам. Данные о договорах, вводимые в базу данных, позволят более оперативно отслеживать и находить эти договора, а также составлять отчеты о выданных кредитах.
База данных должна предоставлять пользователю возможность:
Как наладить электронный документооборот с ЦБ
К лету 2019 г. участники обмена электронными сообщениями с платежной системой Банка России должны перейти на использование новой версии программного комплекса АРМ КБР-Н. Это прекрасная возможность оптимизировать электронный документооборот с Банком России, считает Игорь Виноградов, коммерческий директор компании «Кворум».
CNews: До 28 июня 2019 года банки должны перейти на новый АРМ КБР-Н. Что это значит для банков с точки зрения технологий?
Игорь Виноградов: Любой коммерческий банк регулярно обменивается электронными сообщениями с ЦБ и с другими участниками рынка при переводе денежных средств через платежную систему Банка России. Порядок такого обмена регулируется ЦБ и определяется так называемым альбомом УФЭБС (унифицированных форматов электронных банковских сообщений).
Электронные сообщения передаются с помощью специального программного обеспечения, которое поставляет ЦБ, – АРМ КБР. Однако это ПО оказалось ненадежным с точки зрения информационной безопасности. Дело в том, что сообщения передавались из автоматизированной банковской системы (АБС) в АРМ КБР в незащищенном виде и только там подписывались ЭП. Инсайдеры научились менять реквизиты в платежном поручении, из-за чего деньги уходили не туда, куда должны были уйти. В 2014, 2015, 2016 годах из-за его компрометации в коммерческих банках были похищены огромные средства.
Центробанк решил с 28 июня 2019 года снять с себя ответственность за достоверность передаваемых банками сообщений. Фактически это означает, что из новой редакции АРМ КБР-Н исключается функционал, связанный как с защитным кодом, удостоверяющим неизменность сообщения, так и с кодом аутентификации – подписью отправителя. Теперь эти функции должны быть реализованы самими банками.
Существует еще одна проблема. Электронных сообщений, о которых я говорил, более 90 типов. За создание и обработку часто используемых сообщений, как правило, отвечают определенные прикладные системы банка. Однако время от времени возникает необходимость подготовить и отправить сообщение, которое не поддерживается имеющимися системами. До сих пор это можно было сделать с помощью АРМ КБР, в котором имелся соответствующий функционал. В новой редакции АРМа такой возможности не будет.
Определенные трудности для банков связаны еще и с тем, что ЦБ достаточно часто вносит изменения в альбом УФЭБС, добавляя в него новые типы сообщений и изменяя форматы существующих. Только в 2018 году вышло четыре квартальные версии альбома.
CNews: Что вы предлагаете?
Игорь Виноградов: Глядя на это, мы подумали, что рынку нужна замена АРМ КБР с более широким функционалом. И разработали программный модуль-посредник EDSmart, который, с одной стороны, взаимодействует со всеми информационными системами банка, может создавать и обрабатывать сообщения произвольного типа, а с другой подключается к АРМ КБР-Н и АРМ КБР-СПФС или непосредственно к Универсальному транспортному агенту для приема и передачи данных в ЦБ.
CNews: То есть EDSmart – это, фактически, модуль, обеспечивающий достоверность передаваемых банками сообщений?
Игорь Виноградов: Нет, мы решили пойти дальше и создать специализированную систему электронного документооборота. Например, наш модуль позволяет автоматизировать рекламационную переписку. Обычная ситуация – банк не может зачислить деньги на счет, потому что в реквизитах содержится неточность. Нужно сделать запрос отправителю для уточнения информации. В банках этим занимаются целые отделы. Наш модуль мгновенно перенаправляет информацию о запросе соответствующему сотруднику, который сразу начинает с ним работать.
Часто сообщения от ЦБ по тем или иным причинам не доходят до банков. Поэтому банки отправляют в ЦБ запрос с просьбой прислать список отправленных сообщений, а затем вручную проверяют, все ли они получили. Мы автоматизировали процесс такой сверки. Так же как и процесс сверки итогов по выписке – какие платежи прошли, а какие не прошли.
EDSmart спроектирован таким образом, что при смене версии УФЭБС никаких изменений в программное обеспечение модуля вносить не требуется. Например, для того, чтобы в начале января перейти на очередную версию УФЭБС 2019.1.1, нашим клиентам достаточно было скачать с сайта ЦБ РФ и загрузить в модуль набор файлов, определяющих новый состав и схемы электронных сообщений.
Таким образом, мы рассматриваем наш модуль не просто как систему, которая умеет ставить подписи, а как решение, которое позволяет создавать любые типы сообщений, автоматизировать рутинные процессы, контролировать достоверность передаваемой информации, автоматически загружать необходимые справочники и так далее.
Пока это единственное подобное решение на рынке. Разработчики встраивают электронную подпись в свои АБС, но это значит, что можно подписывать только те сообщения, которые генерирует данная АБС. Мы же предлагаем универсальное решение, которое интегрируется с разными банковскими системами.
Еще одна особенность нашего модуля – он не требует постоянного внимания. Когда происходят события, требующие вмешательства человека, система уведомит об этом. Все остальное время она работает незаметно для пользователя.
CNews: Сколько времени занимает его внедрение?
Игорь Виноградов: Развернуть систему можно за один день. На полноценное внедрение уйдет не более трех дней. Основных усилий требует интеграция модуля с информационными системами банка, которые являются либо источниками, либо потребителями информационных сообщений. Сделать это могут сами сотрудники банка при нашем удаленном участии.
У всех банков свои ИТ-ландшафты, свои требования к безопасности, свои подходы к организации информационного взаимодействия между системами. Поэтому мы предлагаем, во-первых, разнообразные технологии интеграции – начиная от простого файлового обмена и заканчивая применением интеграционных шин. Во-вторых, усиленные меры безопасности – дополнительный контур верификации финальной сверки реквизитов платежных сообщений. Это позволяет противостоять даже самым изощренным действиям злоумышленника. Если в процессе финальной сверки реквизитов выявляется малейшее расхождение, система тут же блокирует сообщение и рассылает по подписке офицерам службы безопасности банка соответствующее сообщение.
CNews: EDSmart – коробочный продукт. Не возникнут ли проблемы с его настройкой и интеграцией с уже существующими информационными системами банка?
Игорь Виноградов: Коробочный продукт – это не кот в мешке. Помимо традиционной презентации решения, где мы подробно рассказываем о его достоинствах и возможных недостатках, мы предоставляем возможность протестировать его в режиме удаленного доступа. Могу сказать, что пока все, кто воспользовался этой возможностью, остались довольны.
Наше решение кросс-платформенное – на сегодняшний день оно работает с СУБД Oracle и SQL, при наличии запросов от банков мы готовы добавить к этому списку PostgreSQL.
Оно может работать в многофилиальном банке, где процесс обработки электронных сообщений централизован. Его не надо устанавливать в каждом филиале. В то же время, в нем реализован контур предварительной подготовки электронных сообщений. Например, при заказе наличных денежных средств можно собрать предварительные заявки из разных офисов, а затем обобщить их. При этом в системе предусмотрена верификация и визирование заявок.
На сегодняшний день наша система обрабатывает около 150 000 входящих плюс примерно столько же исходящих сообщений в сутки. В целом она ориентирована на нагрузку более миллиона сообщений в течение одного операционного дня.
Пользователи системы могут получить техническую поддержку в любом регионе нашей страны, в том числе расширенную в режиме 24 на 7.
CNews: Вы планируете дальнейшее развитие решения?
Игорь Виноградов: Я думаю, нам удалось создать специализированную систему электронного документооборота, автоматизирующую общение банков с Центробанком и с другими банками. Несмотря на то, что система абсолютно новая, и аналогов ей на рынке не существует, она уже обладает достаточно развитым функционалом. Однако мы понимаем, что сегодня EDSmart находится в стадии развития. Поэтому стараемся внимательно прислушиваться к пожеланиям пользователей. Благодаря им мы уж получили и реализовали несколько новых идей. И надеемся, что чем больше банков будут использовать нашу систему, тем более полезной и функциональной она будет.
Сегодня мы планируем добавить в нее возможность работы со SWIFT-сообщениями – проверять их на соответствие формату SWIFT при получении, а также разработать интерфейс, с помощью которого можно будет создавать SWIFT-сообщения.
Надеюсь, наша система позволит облегчить тяжелый труд сотрудников банков, повысить его производительность и таким образом будет способствовать сокращению затрат бизнеса.
Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка
В первой части нашего исследования мы рассмотрели работу системы банковских безналичных платежей c экономической точки зрения. Теперь настало время посмотреть на внутреннее устройство ИТ-инфраструктуры банка, с помощью которой эти платежи реализуются.
Disclaimer
Статья не содержит конфиденциальной информации. Все использованные материалы публично доступны в Интернете, в том числе на сайте Банка России.
Глава 1. Общее описание ИТ-инфраструктуры
Основные термины
автоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;
В рамках данного исследования оба термина будут использоваться как синонимы.
Справедливость подобного подхода можно доказать тем, что в Приказе ФСТЭК России от 11.02.2013 N 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» для защиты информационных систем госрегулятор предписывает руководствоваться ГОСТами по автоматизированным системам.
Помимо информационных систем в IT-инфраструктуре банка можно выделить еще один тип элементов — информационные сервисы, или, как их часто называют, роботы.
Дать определение понятию информационный сервис довольно сложно, поэтому просто перечислим его основные отличия от информационной системы:
Автоматизированная банковская система
Ядром информационной инфраструктуры любого банка является автоматизированная банковская система или сокращенно АБС.
автоматизированная система, реализующая банковский технологический процесс.
Данное определение позволяет подвести под него практически любую IT-систему в банке. В то же время обычные банковские служащие называют АБС ту систему, которая занимается учетом банковских счетов, проводок между ними (движением денежных средств) и остатков. Второе определение не противоречит первому и более четко его детализирует, им и будем пользоваться дальше.
В современных Российских банках наиболее распространенными являются следующие АБС :
Иногда в банках параллельно используют несколько АБС различных производителей. Зачастую это происходит, когда банк пытается перейти с одной АБС на другую, но возможны и менее тривиальные причины.
Прикладные информационные системы
Несмотря на то что АБС автоматизирует довольно большое количество задач, она не покрывает все нужды банка. Есть задачи, которые АБС не делает вообще или делает не так, как хочет того банк. Поэтому к АБС подключаются (интегрируются) другие информационные системы, автоматизирующие отдельные бизнес-процессы. В дальнейшем подобные информационные системы будем называть — прикладными информационными системами.
Примерами прикладных информационных систем могут быть:
Инфраструктурные информационные системы
Помимо АБС и прикладных информационных систем, автоматизирующих основные бизнес-процессы, в банках также присутствует приличное количество вспомогательных инфраструктурных информационных систем. Примерами подобных систем могу быть:
Информационные сервисы
В банках используется гигантское количество различных информационных сервисов, выполняющих простые, рутинные функции, например, загрузка справочников БИК и ФИАС, публикация курсов валют на официальном сайте и т.д.
Клиентские части сторонних информационных систем
Отдельного упоминания стоят клиентские части внешних по отношению к банку информационных систем. В качестве примеров приведу:
Типовые способы интеграции информационных систем
Для интеграции информационных систем обычно применяются следующие механизмы:
Модули интеграции
Под модулем интеграции будем понимать виртуальный элемент IT-инфраструктуры, реализующий интеграцию других элементов IT-инфраструктуры.
Данный элемент мы назвали виртуальным, потому что его функционал может быть реализован, как в виде отдельного специализированного элемента ИТ-инфраструктуры (например, информационного сервиса), так и в виде компонентов интегрируемых информационных систем. Более того, в качестве модуля интеграции может выступать даже человек, «вручную» переносящий информацию между интегрируемыми информационными системами.
Пример ИТ-инфраструктуры банка
На Рис.1 можно увидеть фрагмент типовой информационной инфраструктуры банка, содержащий рассмотренные выше типы элементов.
Глава 2. Инфраструктура безналичных расчетов
Если посмотреть на эту схему (Рис.1) с точки зрения осуществления безналичных расчетов, то можно увидеть, что банк реализует их при помощи:
Для успешного функционирования банк обязан обеспечивать у себя информационную безопасность всех перечисленных способов осуществления платежей. Рассмотреть их в рамках одного, даже крупного исследования весьма проблематично, и поэтому мы сконцентрируемся только на одном наиболее критичном, с точки зрения возможных потерь, направлении — платежном взаимодействии банка с Банком России.
Инфраструктура обеспечения платежного взаимодействия с Банком России
Рис. 2.
IT-инфраструктуру платежного взаимодействия банка с Банком России будем рассматривать на примере исполнения платежа, отправляемого в адрес клиента другого банка.
Как мы помним из первой части, вначале клиент должен передать в банк платежное поручение. Сделать это он может двумя способами:
Если клиент передал платежное поручение на бумажном носителе, то работник банка на его основании делает электронное платежное поручение в АБС. Если распоряжение было подано через ДБО ИКБ, то через модуль интеграции оно попадает в АБС автоматически.
Доказательством того, что именно клиент сделал распоряжение о переводе денежных средств, в первом случае является лично подписанный им бумажный документ, а во втором, электронный документ в ДБО ИКБ, заверенный в соответствии с договором.
Обычно для заверения электронных документов клиентов — юридических лиц в ДБО ИКБ применяют криптографическую электронную подпись, а для документов клиентов — физических лиц коды SMS-подтверждений. С юридической точки зрения для заверения электронных документов в обоих случаях банки обычно применяют правовой режим аналога собственноручной подписи (АСП).
Попав в АБС, платежное поручение в соответствии с внутренними регламентами банка проходит контроль и передается для исполнения в платежную систему Банка России.
Технические средства взаимодействия с платежной системой Банка России
Технические средства (программное обеспечение), используемые для взаимодействия с платежной системой Банка России могут варьироваться в зависимости от территориального учреждения Банка России, обслуживающего корр. счет банка.
Для банков, обслуживаемых в Московском регионе, применяется следующее ПО:
АРМ КБР
АРМ КБР – это ПО, с помощью которого уполномоченные работники банка осуществляют шифрование и электронную подпись исходящих платежных документов, а также расшифровку и проверку электронной подписи платежных документов, поступающих из Банка России. Но, если быть более точным, то АРМ КБР в своей работе оперирует не платежными документами, а электронными сообщениями (ЭС), которые бывают двух типов:
Для того чтобы АРМ КБР мог обработать платеж, он должен быть преобразован в файл, содержащий электронное платежное сообщение формата УФЭБС. За подобное преобразование отвечает модуль интеграции АБС с платежной системой Банка России. С технической точки зрения подобные преобразования довольно просты, поскольку формат УФЭБС основан на XML.
Файлы электронных сообщений покидают модуль интеграции АБС в открытом виде и помещаются в специальную папку файловой системы (обычно это сетевая папка), которая настроена в АРМ КБР для электронных сообщений, имеющих статус «Введенные». На ранее представленной схеме (Рис. 2.) эта папка обозначена как «Папка 1».
Затем в процессе обработки электронные сообщения меняют свои статусы на «Контролируемые», «Отправленные» и т. д., что технически реализуется путем перемещения файла с электронным сообщением в соответствующие папки, которые настроены в АРМ КБР. На схеме (Рис. 2.) эти папки обозначены как «Папка 2».
В определенный момент технологической обработки (установленный внутренними регламентами банка) исходящих электронных сообщений они шифруются и подписываются электронной подписью с помощью СКАД Сигнатура и закрытых криптографических ключей ответственных работников.
СКАД Сигнатура
СКАД Сигнатура, это СКЗИ, разработанное компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ нет в открытом доступе (кроме документации, размещенной на сайте ЦБ РФ), и оно распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:
Зашифрованные и подписанные электронные сообщения помещаются в специальную папку, на схеме (Рис. 2.) это «Папка 3». УТА непрерывно мониторит эту папку и, если он видит там новые файлы, передает их в ЦБ РФ одним из следующих способов:
Следует отметить, что все электронные сообщения, с которыми работает УТА, зашифрованы и подписаны электронной подписью.
Получив зашифрованное электронное сообщение, УТА перекладывает его в папку с входящими зашифрованными сообщениями. Уполномоченный работник с помощью своих криптоключей и АРМ КБР проверяет электронную подпись и расшифровывает сообщение.
Далее обработка производится в зависимости от типа электронного сообщения. Если это платежное сообщение, то оно через модуль интеграции передается в АБС, где на его основании формируются бухгалтерские проводки, изменяющие остатки на счетах. Важно отметить, что при взаимодействии АБС (модуля интеграции) и АРМ КБР используются файлы стандартного формата в открытом виде.
В процессе функционирования АРМ КБР ведет журнал своей работы, который может быть реализован в виде текстовых файлов или с помощью БД, работающих под управлением СУБД.
Альтернативные схемы обработки
Мы рассмотрели «классическую» схему работы системы. В реальности существует множество ее разновидностей. Рассмотрим некоторые из них.
Разновидность 1. Разделение контуров отправки и приема сообщений
Реализуется схема с двумя АРМ КБР. Первый работает с участием человека и выполняет только отправку сообщений, второй работает в автоматическом режиме и выполняет только прием сообщений.
Разновидность 2. Полный автомат
АРМ КБР настраивается на работу полностью в автоматическом режиме без участия человека
Разновидность 3. Изолированный АРМ КБР
АРМ КБР функционирует как выделенный компьютер, не подключенный к сети банка. Электронные сообщения передаются на него человеком-оператором с помощью ОМНИ.
Перенос электронной подписи из АРМ КБР в АБС
Банк России планирует перейти на новую технологическую схему обработки платежей, при которой электронные сообщения будут подписываться не в АРМ КБР, как было ранее, а в АБС (точнее в модуле интеграции АБС — АРМ КБР).
Для реализации данного подхода выпущена новая версия АРМ КБР, которая стала называться АРМ КБР-Н (новая). Все основные изменения можно увидеть, если сравнить схемы информационных потоков, проходящих через АРМ КБР старой и новой версии.
Рассмотрим схему информационных потоков в классическом АРМ КБР. Источник схемы – официальная документация на АРМ КБР «АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО КЛИЕНТА БАНКА РОССИИ. Руководство программиста. ЦБРФ.61209-04 33 01».
Рис. 3.
Примечания.
Рис. 4.
С точки зрения криптографии АРМ КБР-Н отвечает за шифрование / расшифрование электронных сообщений, а также за проверку электронных подписей на них. Формирование электронных подписей перенесено в модуль интеграции АБС.
Логично предположить, что данный модуль также должен будет проверять подписи под сообщениями, полученными из АРМ КБР-Н. С технической точки зрения это не является обязательным, но с точки зрения обеспечения безопасности имеет критическое значение, поскольку обеспечивает целостность сообщений, передаваемых между АБС и АРМ КБР-Н.
Помимо файлового интерфейса взаимодействия между АБС, АРМ КБР-Н и УТА добавлен интерфейс IBM WebSphere MQ, что позволяет строить сервис-ориентированную ИТ-инфраструктуру банка и решить проблему старой схемы с организацией одновременной работы нескольких операторов, ответственных за отправку платежей.