Руководство программиста банка

УТВЕРЖДАЮ От Заказчика Заместитель директора Сводного департамента анализа и регулирования внешнеэкономической деятельности Минэкономразвития России Мартинкевич Г.Г. ________________________ « » _____________ 2009 г.

УТВЕРЖДАЮ От Исполнителя Генеральный директор ООО «Интегрум Медиа» Кузнецов К.В. ________________________ « » _____________ 2009 г.

Единый портал внешнеэкономической информации Минэкономразвития РоссииРуководство программиста

Шифр темы: 1607-05-09

Листов

Москва,

СОДЕРЖАНИЕ

1. Условия применения программы

1.1.Требования к техническим средствам

Требования к техническим средствам ИС «Единый портал внешнеэкономической информации Минэкономразвития России».

Для работы Портала необходимы два высокопроизводительных сервера с конфигурацией не ниже:

Proliant DL380 G5 5160 (Rack2U XeonDC 3.0Ghz(4Mb/) 2х1Gb/P400(256Mb/RAID5/1/0)/noHDD(8)SFF/noCD.noFDD/iLO2std/2xGigEth

Proliant DL380 G5 X5160 (3.00GHz-1x4Mb) Processor Option Kit;

Slimline CD-RW/DWD-ROM Combo Option Kit;

HP 72 Gb SFF SAS 10k rpm Hot Plug Hard Drive (2,5”);

Redundant Power Supply 350/370/380 G5 Worldwide Kit.

1.2.Требования к общему программному обеспечению (ОПО)

Требования к общему программному обеспечению (ОПО), необходимому для ИС «Единый портал внешнеэкономической информации Минэкономразвития России», представлены в таблице 2.

Таблица 1.2. Требования к ОПО

Наименование	Кол-во
1. ОС Debian Server	1
2. PostgreSQL 8.4	1
3. Программные зависимости	1

1. Характеристика программы

Система рассчитана на круглосуточный режим работы в течение 365 дней в году.

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

1. Система автоматически перезапускает себя в случае некритической ошибки
2. Посылает администратору сообщение об ошибке в письме на электронную почту
3. Записывают ошибку в журнал, который находится в файловой системе в файле /var/log/messages
4. В случае невозможности совершить вышеуказанные действия, система выведет администратору ошибки прямо в браузер с конкретными данными о том, где, почему и что произошло.

Для восстановления системы необходимо обратиться к документу «Руководство администратора», в котором находится раздел «Восстановление системы после сбоя»

1. Обращение к программе

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

Внутреннее управление порталом происходит на сервере.
Структура проекта находится в папке /var/www/projects/rus-export и является полноценным набором файлов и программных компонентов для управления логикой, функциональной частью системы и ее работой.

Процесс запуска портала

Чтобы запустить портал программисту необходимо выполнить ряд шагов:

1. Авторизоваться в терминале сервера под ролью root
2. Перейти в папку проекта с помощью команды cd /var/www/projects/rus-export
3. Запустить сервер приложения: script/server

Портал должен запуститься на 80ом порту, после вывода следующих строчек:

bash-3.2# script/server

=> Booting Mongrel

=> Rails 2.3.4 application starting on http://0.0.0.0:80

=> Call with -d to detach

=> Ctrl-C to shutdown server

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

Проект состоит из следующих папок:

app – исходные коды динамической составляющей сайта разбитой по паттерну MVC

controllers – исходные коды контроллеров. Каждый контроллер управляет одной или несколькими сущностями, содержа в себе набор дейтвий. Каждое действие формирует один URL-адрес.

Для генерации  нового контроллера можно использовать команду ~/script/generate controller ‘имя контроллера’

helpers – исходные коды динамичных помошников для представлений. В текущей версии сайта дополнительные помощники определены только в глобальном файле – application_helper.rb.

models – исходные коды моделей сущностей. Каждая модель в указанной папке – отображений таблицы в базе данных с привязкой бизнес-логики.

    views – исходные коды представлений сайта.

config – конфигурационные файлы проекта

database.yml – описание конфигурации СУБД. Примеры конфигурации можно посмотреть в инструкции по установке.

locales – содержит список локализационных настроек. Каждый язык, поддерживающийся сайтом должен быть определен как ‘двухбуквенный код языка’.yml, например ru.yml или jp.yml.

routes.rb – настройки маршрутизации. Файл содержит список соответствий запрашиваемых URL к действиям контроллеров (app/controllers).

db – директория, содержащая файлы, необходимые для работы с СУБД. В случае использования SQLite, эта папка по-умолчанию будет содержать в себе файлы базы данных.

migrate – директория, содержащая миграции, скрипты наката структуры базы данных. Каждый скрипт – отдельная часть структуры. Для доработки структуры на боевой базе, необходимо создать очередной скрипт по примеру существующих. Вызов команды rake db:migrate выполнит у конкретной инсталляции все свежие скрипты. Для генерации миграцией можно использовать команду ~/script/generate migration ‘имя миграции’

doc – директория, зарезервированная под хранение внутренней документации

index – зарезервирована расширением ferret для хранения поисковых индексов

lib – отдельные классы Ruby, не подходящие для определения в моделях.

    tasks – набор задач для исполнение с помощью команды rake.

log – файлы с полным логом запросов. act_as_ferret.log содержит в себе лог работы Ferret.

public – исходные коды статической части сайта

    images – картинки сайта и административной панели

    javascripts – JS-скрипты сайта и административной панели

    stylesheets – CSS-стили сайта и административной панели

script – набор автоматизирующих скриптов, использующихся для генерации, тестирования, снятия бэкапов

test – директория для хранения тестов, как Unit, так и приемочных.

tmp – директория для хранения временных файлов

vendor – внешние зависимости

    plugins – интегрированные в поставку расширения: ACL_System2, paperclip и другие

1. Входные и выходные данные

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

Внесение  изменений в инсталляцию

Внесение изменений  в работающую версию будет принято  после перезапуска сервера. Перезапуск сервера может быть осуществлен  как с остановкой HTTP-сервера и прерыванием соединений, так и без них.

Полная перезагрузка HTTP-сервера nginx в среде Linux выполняется  с помощью команды /etc/init.d/nginx restart. Для мягкой перегрузки программной  среды, необходимо выполнить команду touch ~/tmp/restart.txt.

Полная перезагрузка требуется в крайне редких случаях  и в условиях эксплуатации к использованию  рекомендована мягкая перегрузка.

Процедура автоматизированного  внедрения изменений

Для автоматизации  внесения изменений при активной разработки, в поставке сайта содержатся настройки утилиты Capistrano. Для автоматизации обновления при постоянных изменениях ее можно использовать без перенастройки со следующим окружением:

• nginx

• mod_passenger

• ssh-ключ для выкладывающего пользователя

• система контроля версий Git

Для выкладывания необходимо использовать команду cap deploy. Основные настройки выкладывания расположены  в файле ~/config/deploy/staging.rb.

Их описание: 

set :repository, «svn+ssh://»

Расположение  репозитория Git. 

set :deploy_to, «/var/www/#{application}»

Путь расположения на сервере. 

set :user, «deployer»

Имя пользователя, от лица которого Capistrano будет действовать  на сервере. Этот пользователь должен иметь возможность получить исходные коды из системы контроля версий и быть доступным тому, кто запускает команду cap deploy. 

server «

rus-export.dv-t.net«, :app, :web

server «

rus-export.dv-t.net«, :db, :primary => true

Имена серверов для программного окружения и  СУБД.

1. Сообщения

В ходе выполнения программы, программисту выдаются сообщения. Здесь приводится описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
Возможные ошибки, которые могут появиться при заходе на веб-страницу единого портала:
dispatch.fcgi
505 Rails application failed to start
Решение: мягкая перезагрузка http-сервера

Возможные ошибки в журнале ошибок (файл /var/log/messages в файловой системе сервера):

[warn] mod_fcgid: Read data error, fastcgi server has close connection

[error] [client xxx.xxx.xxx.xxx] Premature end of script headers: dispatch.fcgi
Решение: мягкая перезагрузка http-сервера
Возможные ошибки в любом из мест:

PGSQL: Connection pool ended

IO: Too much open files
Решение: необходимо ввести в терминале сервера команду fs.filemax=16452

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

ППО	Прикладное программное обеспечение
ИС	Информационная система «Единый портал внешнеэкономической информации Минэкономразвития России»
СУБД	Система Управления Базами Данных

Рис. 1.

О чем исследование

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

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

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

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

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

автоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

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

информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;

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

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

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

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

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

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

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

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

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

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

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

• Diasoft FA#,
• Инверсия XXI век,
• RS-Bank,
• ЦФТ-Банк.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АРМ КБР

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

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

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

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

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

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

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

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

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

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

УТА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.

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

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

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

Заключение

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

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

Назначение руководства программиста

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

Примерами могут служить:

– библиотека функций;

– платформа или среда для разработки ПО;

– ПО с открытым кодом.

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

– назначение, структуру входных и выходных данных программных функций;

– возможности по созданию программного кода, особенности его интерпретации и компиляции;

– синтаксические особенности используемого языка программирования;

– возможные правила и ограничения при работе с программным кодом;

– различные инструкции по работе с программой.

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

Состав типового руководства программиста

В соответствии с требованиями ГОСТ руководство программиста должно содержать следующие разделы:

– Назначение и условия применения программы, где указывают область применения ПО и технические требования, необходимые для его работы.

– Характеристика программы, где описывают режим работы программы, показатели скорости ее работы и другие важные для использования характеристики.

– Обращение к программе, где указывают способы и параметры запуска программы;

– Входные и выходные данные, где описывают формат, способ организации и другие требования к входным и выходным данным;

– Сообщения, где приводят тексты сообщений, выдаваемых программой в различных ситуациях и действия, которые необходимо при этом предпринять.

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

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

ГОСТы регламентируют и этот документ, в данном случае это ГОСТ 19.504. В соответствии с ним определяется структура и содержание Руководства программиста.

Стоимость разработки руководства программиста

Наименование документа	Наименование стандарта	Стоимость разработки
Руководство программиста на ПО	ГОСТ 19.504	100 тыс. р.

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

Возможно, вас также заинтересует:

– разработка руководства администратора;
– создание руководства пользователя;
– разработка руководства оператора.

---

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

• монитор 17″;

• жесткий магнитный диск не менее 20 Гб;

• оперативная память не менее 512 Мб;

• процессор с частотой не менее 1,7 ГГц;

• манипулятор “мышь”;

• стандартная клавиатура;

• видеоадаптер VGA;

• лазерный принтер А4.

В качестве необходимого информационного
обеспечения следует отметить, что на
персональном компьютере должна быть
установлена операционная система
семейства Windows, а также
пакет офисных программ MS
Office.

2.4. Руководство оператора

Назначение программы: ввод, хранение и
использование данных по работе аптеки.
Таких как:

• Информация о поставщиках аптеки: адрес,
  телефон, электронный адрес, номер
  лицензии.

• Информация о поставках: дата поставки,
  название товара.

• Информация по товарам: название товара,
  к какой категории и виду относиться,
  срок годности, наценка и др.

• Данные по продажам и заказам товаров:
  количество, наименования, даты продажи
  заказанных товаров.

• Данные по работникам аптеки: фамилия,
  имя, отчество, адрес, телефон, должность,
  стаж и др.

• Покупатели аптеки: фамилия, имя, отчество,
  адрес, телефон, заказанные товары.

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

Выполнение программы: запуск файла
«База данных аптеки.accdb».
Откроется основное окно программы (Рис.
2.8.)

Рис.2.8.Основное окно программы

Далее необходимо с помощью форм заполнить
информацию в таблицах. После заполнения
базы данных мы можем приступить к
непосредственному управлению информацией
– запрашивать необходимые нам данные
с помощью форм, просматривать их с
помощью отчетов и выводить на печать
(Рис. 2.9, 2.10).

Рис. 2.9. Пример отчета

Рис.2.10. Пример формы

2.5. Тестирование программного продукта

Тестирование – процесс выполнения
прикладных программ с целью выявления
ошибок.

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

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

Программный продукт имеет сложную
структуру. В связи с этим тестирование
производилось поэтапно в процессе
создания. Каждый модуль тестировался
по отдельности. Далее модули объединялись
и повторно проходили тестирование. Это
делалось для проверки логических связей.
Выявленные на стадии обработки ошибки
исправлялись.

Отдельно проводилось тестирование
всего программного продукта после
завершения программирования. Для этих
целей в качестве оператора (пользователя)
привлекали несколько человек, не имеющих
отношение к программированию. На этом
этапе проверялась понятность программы
для неопытного пользователя.

В процессе тестирования использовались
следующие методы:

1. Тестирование по методу «черного ящика».

При тестировании по методу «черного
ящика», программа не дает никаких сбоев.
К данному тестированию можно отнести:

• не введение значений ключевых полей;

• различные переключения между режимами
  работы программы.

• ввод символов другого формата в поле
  таблицы.

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

1. Тестирование по методу «белого ящика».

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

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

Выводы

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

В соответствии с поставленной целью в
ходе выполнения работы были получены
следующие результаты:

• выполнено исследование предметной
  области;

• произведен обзор существующего
  программного обеспечения, подходящего
  для решения поставленной задачи
  автоматизации;

• выбраны инструментальные средства
  разработки программного продукта;

• выполнено проектирование базы данных;

• разработана и протестирована
  автоматизированная система обеспечения
  работы фирмы;

• проведено тестирование продукта.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #