46
Рисунок 9 Этапы получения доступа оператора в системе
Регистрация
пользователя в
системе
Идентификация
пользователя
Аутентификация
пользователя
Авторизация
пользователя
Вход
пользователя в
систему
47
Таблица 2 отображает предварительный список ролей и модель доступа к
ресурсам Фронт-Офиса:
Таблица 2
Роль
Модуль
Регистрации
Модуль
Поиска
Модуль
Статистики
Модуль
Интеграц
ии
Модуль
Печатн
ых форм
Модуль упр.
Настройкам и
пользователя
ми
Регистратор
-
региональны
й
Ограничен
но -
полный
Полный
Нет
Полный
Полны
й
Нет
Аудитор –
региональны
й
Нет
Ограничен
но -
полный
Ограничен
но -
полный
Нет
Полны
й
Нет
Аудитор –
федеральный
Нет
Полный
Полный
Нет
Полны
й
Нет
АС
Только
регистраци
я
Нет
Нет
Нет
Нет
Нет
Администра
тор –
региональны
й
Нет
Ограничен
но –
полный
Ограничен
но –
полный
Полный
Полны
й
Ограничен
но -
полный
Администра
тор –
федеральный
Нет
Полный
Полный
Полный
Полны
й
Полный
Список ролей и модель доступа
Так как система подразумевает работу на федеральном уровне, следует
разделить полномочия по регистрации, аудиту и настройки системы, на
региональный и федеральный. Уровень доступа «Ограниченно – полный»
означается полный доступ, но к заявлениям уровня региона. Таким образом для
модуля регистрации возможно чтение, редактирование и удаление заявлений,
зарегистрированных в этом регионе. При том у регионального регистратора
сохраняется возможность поиска заявлений по всем регионам, что позволяет
предотвратить, повторные и неправомерные заявления. Аналогичная ситуация и
48
у администратора, настройки пользователей можно осуществлять только для
текущего региона. В целях безопасности администраторы лишены права
управления заявлений (в части модуля регистраций)
Так же следует отметить специальную и сильно ограниченную роль «АС», под
ней следует понимать внешние автоматизированные системы, такие как Единый
Портал Государственных Услуг (ЕПГУ), Личный Кабинет Застрахованного
Лица(ЛКЗЛ) и прочие. Доверие к таким системам следует ограничивать, они
могут только регистрировать заявления, и в целях безопасности такие заявления
должны вручную обрабатываться регистраторами.
Межсетевые экраны реализуют методы контроля за информацией,
поступающей в Фронт-Офис или выходящей из него, и обеспечивающие защиту
автоматизированной системы посредством фильтрации информации на основе
критериев, заданных администратором. Процедура фильтрации включает в себя
анализ заголовков каждого пакета, проходящего через межсетевые экраны, и
передачу его дальше по маршруту следования только в случае, если он
удовлетворяет заданным правилам фильтрации. При помощи фильтрования
экраны позволяют обеспечить защиту от сетевых атак путём удаления из
информационного потока тех пакетов данных, которые представляют
потенциальную опасность для автоматизированной системы. Дополнительной и
качественной стратегией защиты информации Фронт-офиса и смежных систем
ПФРФ, является полная изоляция серверов, виртуальных машин на которых
установлены такие системы, от интернета и публичных сетей, совместно с
организацией приватных сетей VPN.
Средства анализа защищённости выделены в представленной выше
классификации в обособленную группу, поскольку предназначены для выявления
уязвимостей в программно-аппаратном обеспечении автоматизированной
системы. Системы анализа защищённости являются превентивным средством
защиты, которое позволяет выявлять уязвимости при помощи анализа исходных
текстов Фронт-офиса, анализа исполняемого кода ФО или анализа настроек
программно-аппаратного обеспечения АС. Так как Фронт-Офис использует
компоненты сторонних систем таких как библиотек JAVA и самой виртуальной –
машины JAVA, СУБД, встроенного сервера приложений, контейнера
49
виртуализации. Обновление всех компонентов до последних версий становится
должно выполняться регулярно, как администратором, так и отделом
сопровождения.
Средства антивирусной защиты являются обязательным условием.
Предназначены для обнаружения и удаления вредоносного ПО, присутствующего
на серверах автоматизированной системы. К таким вредоносным программам
относятся компьютерные вирусы, а также ПО для сбора информации изменения
системных библиотек.
3.2. Информационное обеспечение задачи
3.2.1. Информационная модель и её описание
В проектной части будет спроектирована и разработана автоматизированная
система приема и обработки заявлений. Как и любому успешному проекту,
проектной системе будет определено рабочее название. Логичнее всего назвать
систему «Фронт-Офис», так как данное название отлично описывает цели и
задачи системы.
Для взаимодействия системы с оператором будут предусмотрены экранные
формы ввода информации. В этих формах используются элементы выбора из
справочников, чтобы сократить и структурировать вводимую информацию.
Необходимо выделить и классифицировать справочники:
Справочник «Тематики» - будет предусматривать хранение перечня
тематик и содержаний обращений. Например, тематикой обращения можно
будет считать «Материнский семейный капитал», содержанием или видом
заявления в таком случае будут считаться «Заявление на получение
Материнского капитала», «Заявление на распоряжение Материнским
капиталом», «Заявление об отказе распоряжением Материнским
капиталом». При получении СНИЛС, тематикой будет считается
«Персонифицированный учет», а содержанием «Заявление на получение
СНИЛС»
Справочник «Формы» - в данном справочнике планируется хранить
описание форм регистрации в формате json. Каждая форма будет
собирается с помощью визуального конструктора (не представлено на
50
схеме информационной модели, т.к. является модулем разработки), либо
описывается вручную в текстовом редакторе отделом развития.
Справочник «Стран мира» - будет представлять собой расширенную
версию федерального справочника ОКСМ. Следует предусмотреть в
системе синхронизацию данного справочника.
Справочник «Адреса» - в системе должен быть предусмотрен импорт
справочника ФИАС
Справочник «Роли Пользователя» - описывает модель авторизации
пользователя по функционалу. К примеру, регистратор, аудитор, эксперт,
администратор.
Справочник «Пользователи» - будет описывать пользователей /
операторов, содержит данные по аутентификации, фамилии, имени,
отчеству оператора, принадлежность территориальному органу.
В информационную модель не включены специфические справочники,
которые могут быть включены по требованию изменившегося законодательства,
либо требований заказчика, следует спроектировать систему на добавление
таковых.
Введённая оператором информация должна будет где-то сохраняться, стоит
предусмотреть таблицы хранения такой информации, другими словами, бизнес-
данные:
1. Регистрация. Так как главная задача прием заявлений от граждан, то
данные по зарегистрированным заявлениям, а также содержание данных
заявлений, необходимо сохранять в отдельные таблицы.
2. Документы. Отдельно стоит выделить таблицу хранения данных по
прилагаемым документам. Таблицы с документами обязательно должны
быть связанны с таблицей регистраций. Это будет оправданно для поиска
требуемого документа или заявления по документу, например,
предполагается, что операторам будет удобно искать все заявления по
представленному паспорту.
3. Результаты рассмотрения – стоит вынести в отдельную таблицу и
аналогично документам связать с таблицей регистраций. В ней
предполагается размещать информацию по принятым решениям. Если
51
требуется посмотреть только решение по заявлению, информацию по
составу заявлений не придется возвращать из базы данных, что
положительно скажется на времени выборки.
Предварительно систему должен будет настроить администратор системы.
Администратор создаст роли и укажет функциональные возможности ролей.
После чего создает пользователей: заполнит анкетную информацию каждого
пользователя системы; установит роли каждому пользователю; укажет
информацию для аутентификации.
Для создания приложения и его информационной модели следует рассмотреть
процесс приема заявлений:
1. Гражданин обращается в управление с пакетом документов,
подтверждающих право на ту или иную услугу.
2. Оператор создает обращение, соответствующее тематике и содержанию.
3. По указанным тематике и содержанию оператор заполняет экранную
форму заявления.
4. Прикладывает к заявлению представленные гражданином документы
5. Регистрирует данное обращение в системе.
6. Система автоматически формирует печатную форму заявления и расписку-
уведомление, о принятых документа и правовых сроках оказания услуги.
7. Параллельно информация о заявлении отправляется в целевую подсистему.
Система занимается узкоспециализированной обработкой заявления.
Инициируется бизнес-процесс, в результате которого в срок,
установленный законом, выносится решение по данному заявлению.
Например удовлетворительное решение на выдачу сертификата, с
указанием реквизитов данного заявления и суммы.
8. Данные о решении передаются в Фронт-офис, где данные сохраняются.
9. По данным решений можно сформировать печатные формы, такие как:
Результат рассмотрения, сертификат МСК, СНИЛС, справку о выплатах
пенсий и иных социальных начислениях и другие.
Исходя из процесса приема заявления, структурой хранимой информации,
ограничения прав пользователей системы, задачей и целей самой системы –
можно построить основополагающую информационную модель
52
автоматизирующей системы. Информационная модель представлена ниже на
Рисунок 10 Информационная модель
Рисунок 10 Информационная модель проектной системы
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Необходимо решить задачи по обработке входной и оперативной
информации, а именно: тому, как будет определяться нужное заявление, как
оператор будет вводить данные о заявителя и его документах.
Выбор тематики заявления. Окно выбора будет содержать два связанных
между собой списка. Один список будет содержать данные о теме заявления.
Другой будет конкретизировать вид заявления. Подтверждение выбора является
клик по кнопке «Сформировать». Макет изображен на Рисунок 11 Макет выбора
заявления.
Заполнение основная форма заявления. Система должна разделять поля по
типу: свободный ввод, выбор из справочника; по обязательности; по
информационной группе: анкетные данные, данные, предъявляемые заявлением
и другие. Рисунок 12 Макет формы ввода заявления макет экранной формы
заявления.
53
3. Ввод данных о документах логичнее представить на форме заявления, где
специалист введет все данные о документах. Макет ввода документов приведен
на Рисунок 13 Макет формы ввода документов
54
Рисунок 11 Макет выбора заявления
Рисунок 12 Макет формы ввода заявления
Рисунок 13 Макет формы ввода документов
55
Таким образом входной информацией будет считаться:
1. Вид заявления.
2. Информация, введенная пользователем на форму заявления:
a. Анкетные данные заявителя
b. Данные о месте жительства, регистрации
c. Данные о представителе
d. Данные содержания заявления
e. Контактные данные
f. Данные по работе с заявлением
3. Представленные документы, переданные оператору для ввода:
a. Документы, удостоверяющие личность
b. Документы удостоверяющие полномочия
c. Правообразующие документы
Таблица №3 отображает справочники, используемые при вводе информации.
Таблица №3
Название
справочника
Ответственный
за его ведение
Средний
объём
справочника
в записях
Средняя
частота
актуализации
Средний
объем
актуализации
Справочник
адресов
Администратор
системы ОПФР
2 489 457
1 месяц
50 – 1000 /
месяц
Страны Мира
Администратор
системы ОПФР
Отдел
сопровождения
251
1 – 5 лет
0
Тематики
Отдел
сопровождения
100
1-3 месяца
1 – 3 / 6
месяцев
Формы
Отдел
сопровождения
100
1 месяц
1 месяц
Справочники проектируемой системы «Фронт-офис»