МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

по внедрению и использованию портальной универсальной технологической
платформы, созданной в рамках Пилотного проекта в Ханты-Мансийском
автономном округе - Югре, позволяющей объединить в единой сети по работе
с обращениями граждан государственных органов и органов местного
самоуправления (ЕС ОГ) существующие в органах и организациях программно-
технические комплексы и информационные системы по работе с обращениями
граждан и организаций с возможностью получения информации о результатах
их рассмотрения, а также о принятых по ним мерах, по запросу иного органа
или организации с использованием удаленных АРМов с различным уровнем
доступа из единого хранилища данных либо распределенных баз данных

 

  1. ОБЩИЕ ПОЛОЖЕНИЯ
  • Методические рекомендации по внедрению и использованию портальной универсальной технологической платформы, позволяющей объединить в единой сети по работе с обращениями граждан государственных органов и органов местного самоуправления (далее ЕС ОГ) существующие в органах и организациях программно-технические комплексы и информационные системы по работе с обращениями граждан и организаций с возможностью получения информации о результатах их рассмотрения, а также о принятых по ним мерах, по запросу иного органа или организации с использованием удаленных АРМов с различным уровнем доступа из единого хранилища данных либо распределенных баз данных (далее – Методические рекомендации) разработаны на основании реализации пилотного проекта в Ханты-Мансийском автономном округе – Югре с целью обеспечения построения единого информационного пространства по работе с обращениями граждан и организаций в государственных органах и органах местного самоуправления, государственных и муниципальных учреждениях, иных организациях, на которые возложено осуществление публично значимых функций (далее – органы и организации).
  • Методические рекомендации призваны обеспечить:

создание единого информационного и организационного пространства по работе с обращениями граждан и организаций;

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

  • Методические рекомендации содержат:

требования к установке и внедрению в органах и организациях универсальной технологической платформы (далее – Платформа), созданной в рамках пилотного проекта в Ханты-Мансийском автономном округе – Югре и           интегрированной с системой автоматизации делопроизводства

и электронного документооборота «ДЕЛО»;

требования по интеграции с Платформой иных систем электронного систем, органов

  1. ОПИСАНИЕ ПЛАТФОРМЫ

включая возможности (письменной, электронной, устной), в интеграции с Платформой, в идентичной для всех

органов и организаций универсальной форме-конструкторе, содержащей утвержденную общую неизменяемую часть в соответствии с Методическими рекомендациями, и дополняемую часть, специфичную для органа/организации, в интеграции с Платформой;

предоставление органам и организациям, не использующим СЭД, возможности использовать функции Платформы через автоматизированное рабочее место ЕС ОГ (АРМ ЕС ОГ) для автоматизации работы с обращениями в части регистрации и рассмотрения с использованием универсальной формы-конструктора, включая направление в другие органы и организации по компетенции, в том числе в органы и организации, использующие СЭД, интегрированную с Платформой;

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

предоставление органам и организациям возможности хранения данных о зарегистрированных обращениях, в том числе о результатах рассмотрения обращений, как в распределенных базах данных СЭД, так и в локальных узлах сегмента сети ЕС ОГ;

интеграцию с информационными ресурсами и информационными системами, функционирующими в сети ЕС ОГ;

синхронизацию информации в информационных ресурсах «Личный кабинет» официальных сайтов органов и организаций в сети «Интернет»;

обеспечение контроля сроков регистрации, рассмотрения и иных сроков, определенных Федеральным законом от 2 мая 2006 года № 59-ФЗ «О порядке рассмотрения обращений граждан Российской Федерации»;

обеспечение автоматического формирования ежемесячных и промежуточных отчетов о результатах рассмотрения обращений граждан, поступающих в органы и организации, использующие и не использующие СЭД, и автоматическую передачу промежуточных отчетов о результатах рассмотрения обращений граждан в СЭД и ежемесячных отчетов в Администрацию Президента Российской Федерации;

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

2.2. Платформа представляет собой набор следующих взаимосвязанных модулей:

  • базовая система, являющаяся связующим звеном модулей Платформы и обеспечивающая общие для модулей функции;
  • модуль Платформы, отвечающий за интеграцию с внешними информационными системами, обеспечивающий регистрацию обращений в единой форме регистрации;
  • модуль Платформы, поддерживающий информационное обеспечение в рамках регистрации и рассмотрения обращений в АРМ ЕС ОГ;
  • модуль Платформы, отвечающий за интеграцию с внешними информационными системами, обеспечивающий обмен данными в процессе рассмотрения обращений;
  • модуль Платформы, отвечающий за интеграцию с внешними информационными системами, обеспечивающий формальный процесс обмена данными в процессе рассмотрения обращений в АРМ ЕС ОГ;
  • модуль Платформы, поддерживающий

обеспечение в рамках работы с дополнительными полями;

  • модуль Платформы, поддерживающий

обеспечение в рамках работы с конструктором ответов;

  • модуль Платформы, отвечающий за интеграцию     с внешними

информационными системами, обеспечивающий экспорт данных в СЭД;

  • модуль Платформы, отвечающий за предоставление данных

на ССТУ.РФ в раздел «Результаты рассмотрения обращений» в АРМ ЕС ОГ;

  • модуль Платформы, обеспечивающий сохранение информации

о структуре органа и организации и его сотрудниках;

  • модуль Платформы, обеспечивающий предоставление аналитической отчетности по данным работы Платформы;
  • данных.
  • ФУНКЦИОНАЛ МОДУЛЕЙ ПЛАТФОРМЫ

3.1. Базовая система является                 связующим звеном

Платформы и обеспечивает общие для модулей функции

Базовая система обеспечивает функциональность узла

и включает в себя следующие технологические возможности:

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

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

предоставление доступа к работе с подсистемой аудиосвязи в рамках функционала АРМ ЕС ОГ;

предоставление доступа к работе с подсистемой видеосвязи в рамках функционала АРМ ЕС ОГ;

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

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

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

  1. предоставление отдельного интерфейса распределения пользовательских функций по конкретным пользователям, работающим с различными режимами АРМ ЕС ОГ:

выделение функции (права доступа к конкретной функции в интерфейсе

 

 

 

режима в АРМ ЕС ОГ) конкретному пользователю;

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

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

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

б) предоставление отдельного интерфейса доступных возможностей по использованию подсистем аудио- и видеосвязи в рамках работы с функционалом АРМ ЕС ОГ с отображением возможностей телефонии при получении выделенного номера:

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

включения/выключения трансляции

 

предоставление возможности видеосвязи для абонента;

возможность перевести текущий

с предварительным соединением;

возможность перевести текущий

без предварительного соединения;

возможность поставить вызов возможностью снятия с удержания;

возможность завершения вызова;

возможность осуществить исходящий вызов доступному абоненту ЕС ОГ;

предоставление интерфейса поиска абонентов ЕС ОГ по ключевым критериям: ФИО, наименование органа и организации;

индикация доступности абонента для вызова (доступен, в сети/не доступен); предоставление интерфейса журнала вызовов служебной связи ЕС ОГ: Список пропущенных, список исходящих;

в) отображение данных аффилированных модулей                         Платформы

в интерфейсе режимов АРМ ЕС ОГ.

 

вызов

 

вызов

 

на

 

на другого

 

на другого

 

удержание

 

абонента ЕС ОГ

 

абонента ЕС ОГ

 

с последующей

 

3.2. Модуль Платформы, отвечающий за интеграцию с внешними информационными системами, обеспечивающий регистрацию обращений в единой форме регистрации

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

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

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

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

 

механизм поиска таких пользователей по заданным критериям), найденного в списке пользователей, имеющих доступ к возможностям модуля;

определение списка органов и организаций и/или их доступных для каждой конкретной операции;

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

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

предоставление доступа к функционалу работы по зарегистрированного обращения;

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

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

  • Модуль Платформы, поддерживающий информационное обеспечение в рамках регистрации и рассмотрения обращений в АРМ ЕС ОГ

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

а) отображение интерфейса, ответственного за регистрацию обращений граждан и организаций, включая возможность:

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

заполнения дополнительных доступных полей формы;

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

по предустановленным правилам;

отображения подсказок, в том числе на основе информации, содержащейся на информационном ресурсе ССТУ.РФ, для целей минимизации допущения ошибок при заполнении единой формы;

отображения информационных сообщений об ошибках, допущенных при заполнении;

расширенного поиска и рассматриваемых в АРМ ЕС ОГ:

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

б)   отображение интерфейса администрирования, включая возможность расширенного поиска обращений, зарегистрированных и рассматриваемых в АРМ ЕС ОГ:

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

расширенного поиска обращений, перенаправленных по компетенции в АРМ ЕС ОГ:

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

информации в АРМ ЕС ОГ:

  • по типу запроса (входящий/исходящий);
  • по наименованию органа власти или учреждению;
  • по данным уполномоченного лица;
  • по статусу запроса;
  • по датам запроса;

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

настройки маски регистрационного номера обращения (присваивается автоматически);

настройки маски регистрационного номера запроса (присваивается автоматически);

выбора алгоритма распределения по ответственным за обращений после регистрации обращения;

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

обращений);

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

доступа к дополнительным интерфейсам настройки аффилированных модулей Платформы;

в)   отображение интерфейса, ответственного за рассмотрение обращений, включая возможность:

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

расширенного поиска и рассматриваемых в АРМ ЕС ОГ:

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

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

  • регистрационный номер;
  • статус рассмотрения;
  • дата регистрации;
  • плановая дата рассмотрения;
  • фактическая дата рассмотрения (если приемлемо);
  • ФИО регистратора; отображения списка вопросов;

добавления вопросов (классификация обращений граждан и организаций по последней версии внутриведомственного классификатора, составленного на основе тематического);

отображения данных по конкретному вопросу:

  • код и наименование вопроса;
  • наименование ответственного органа и организации/ФИО

уполномоченного лица;

  • статус рассмотрения по вопросу (соответствует во многом статусу рассмотрения обращения);
  • подробные данные по вопросу;
  • данные по ответу;
  • элементы управления по смене статуса с последующим формированием ответа заявителю;
  • элементы управления по перенаправлению вопроса по компетенции в иной орган и организацию (при наличии модуля Платформы, отвечающего за интеграцию с внешними информационными системами, обеспечивающего формальный процесс обмена данными в процессе рассмотрения обращений);
  • элементы управления по запросу информации, связанной с процессом рассмотрения данного вопроса обращения (при наличии модуля Платформы, отвечающего за интеграцию с внешними информационными системами, обеспечивающего формальный процесс обмена данными в процессе рассмотрения обращений);

отображения данных по обращению:

  • тип;
  • регистратор (наименование органа

ФИО регистратора);

тип вложения; размер вложения; наименование вложения без расширения; дата вложения;

возможность скачать, просмотреть и регламентируется отдельно согласно правилам работы с файлами);

отображения журнала работ (опционально); отображения истории изменений (опционально); отображения дерева переводов (опционально); работы с комментариями:

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

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

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

перенаправить обращение (конкретный вопрос), зарегистрированное в данном органе и/или организации, по компетенции в иной орган власти и/или организацию с постановкой на контроль;

получить обращение, перенаправленное по компетенции из иного органа и/или организации;

получить обращение, перенаправленное по компетенции из иного органа и/или организации, поставленное на контроль;

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

сформировать запрос информации по обращению (конкретному вопросу или группе вопросов);

отправить запрос информации в иной орган и/или организацию; получить статус запроса информации;

получить ответ по отправленному ранее запросу информации; получить запрос информации из иного органа и/или организации; сформировать ответ на полученный запрос информации;

отправить ответ в орган и/или организацию, запросивший(ую) данную информацию.

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

  • Модуль Платформы, отвечающий за интеграцию с внешними информационными системами и обеспечивающий формальный процесс обмена данными в процессе рассмотрения обращений в АРМ ЕС ОГ

Модуль включает в себя следующие технологические возможности:

а)  доступ к программному интерфейсу модуля Платформы, отвечающего за интеграцию с внешними информационными системами, обеспечивающего формальный процесс обмена данными в процессе рассмотрения обращений, в том числе: получение доступа к списку доступных органов и организаций; перенаправление обращения (конкретного вопроса), зарегистрированного в данном органе и/или организации, по компетенции в иной орган и/или организацию;

   
   
 
   


перенаправление обращения (конкретного вопроса), зарегистрированного орган

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

формирование запроса информации по обращению (конкретному вопросу или группе вопросов);

отправка запроса информации в иной орган и/или получение статуса запроса информации;

получение ответа по отправленному ранее запросу получение запроса информации из иного органа и/или формирование ответа на полученный запрос информации;

отправка ответа в орган и/или организацию, запросивший(ую) данную информацию;

б)   определить получателя и сформировать пакет для гарантированной доставки.

Модуль включает в себя следующие функциональные возможности, доступные пользователям системы через пользовательский интерфейс:

отображение элементов управления по перенаправлению вопроса по компетенции в иной орган и/или организацию, в том числе опцию постановки обращения на контроль;

отображение элементов управления по запросу информации, связанной с процессом рассмотрения данного вопроса обращения;

вывод автоматически сформированного списка органов и/или организаций при перенаправлении обращения по компетенции или при запросе информации по рассматриваемому обращению, если ранее был отмечен конкретный вопрос, по которому производится выбор на основе компетенций, присвоенных конкретному органу и/или организации на портале ССТУ.РФ или в модуле системы «Локальный портал»;

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

  • Модуль Платформы, поддерживающий информационное обеспечение в рамках работы с дополнительными полями

Модуль обеспечивает редактирование, удаление) сформированными в соответствии с компетенцией органа власти, для работы в формах режима Информационное обеспечение АРМ ЕС ОГ и единой форме регистрации обращений граждан и организаций и включает в себя следующие технологические возможности:

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

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

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

а) отображение интерфейса администрирования, включая доступ к интерфейсу создания пользовательских полей:

  • выбор типа поля;
 
   

 

и организаций; заполнение пользовательских полей;

валидация заполнения полей на обязательность и по маске (опционально);

в)   отображение интерфейса, ответственного за регистрацию обращений граждан и организаций, включая:

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

валидация заполнения полей на обязательность и по маске (опционально);

г)   отображение интерфейса ответственного за рассмотрение обращений, включая:

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

редактирование введенных данных в пользовательские поля на этапе регистрации текстов заявителей;

валидация заполнения полей на обязательность и по маске (опционально).

  • Модуль Платформы, поддерживающий информационное обеспечение в рамках работы с конструктором ответов

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

Модуль включает в себя следующие технологические возможности: вызов веб-формы редактора ответов;

передача параметров, необходимых для формирования автоматического ответа; получение файла со сформированным в редакторе ответом.

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

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

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

  • Модуль Платформы, отвечающий за интеграцию с внешними информационными системами, обеспечивающий экспорт данных в СЭД

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

Модуль обеспечивает выгрузку в «Личный кабинет» данных, зарегистрированных и обработанных в модуле системы, поддерживающем информационное обеспечение в рамках регистрации и рассмотрения обращений посредством АРМ ЕС ОГ. Выгрузка осуществляется по правилам и в объеме, требуемом для сервисов «Личный кабинет», в соответствии с «Методическими рекомендациями по взаимодействию «Личного кабинета» раздела «Отправить письмо» официального сайта Президента Российской Федерации в сети «Интернет» и «Личных кабинетов» официальных сайтов государственных органов и органов местного самоуправления в сети «Интернет».

  • Модуль Платформы, отвечающий за предоставление данных на ССТУ.РФ в раздел «Результаты рассмотрения обращений» в АРМ ЕС ОГ

Модуль включает в себя следующие технологические возможности: доступ к программному интерфейсу серверного компонента, возможности которого описаны в документе «Порядок импорта данных из СЭД в раздел «Результаты рассмотрения обращений»;

автоматическую отправку отчетности по результатам рассмотрения обращений, рассматриваемых в АРМ ЕС ОГ, в раздел «Результаты рассмотрения обращений» ССТУ.РФ без участия пользователя.

  • Модуль Платформы, обеспечивающий сохранение информации о структуре органа власти и его сотрудников в данной структуре

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

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

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

запрос по идентификатору органа или организации списка публичных данных и контактов пользователей ЕС ОГ;

запрос статуса публичного пользователя ЕС ОГ.

Модуль включает в себя следующие функциональные возможности, доступные пользователям системы через пользовательский интерфейс, а именно:

а) в рамках веб-интерфейса модуля:

доступ к элементам управления деревом структуры органа или организации (добавление, редактирование, удаление структурных элементов);

доступ к регистрации пользователей ЕС ОГ через интерфейс данного модуля, включая:

  • связь со структурным элементом дерева органа или организации;
  • индикатор приватности/публичности данных пользователя

для внешних пользователей в рамках ЕС ОГ;

  • доступ к форме ввода данных пользователя (контакты,

профессиональные компетенции, часы работы, прочее);

  • доступ к смене статуса пользователя (в рамках ЕС ОГ для целей управления коммуникациями, в том числе межведомственными);

б) в рамках режима «Служебная связь» АРМ ЕС ОГ:

доступ к профилю пользователя «Локального портала» через интерфейс АРМ ЕС ОГ (дозаполнение, редактирование), включая:

  • связь со структурным элементом дерева органа или организации;
  • индикатор приватности/публичности данных пользователя

для внешних пользователей в рамках ЕС ОГ;

  • доступ к форме ввода данных пользователя (контакты,

профессиональные компетенции, часы работы, прочее);

  • доступ к смене статуса пользователя (в рамках ЕС ОГ для целей управления коммуникациями, в том числе межведомственными);

отображение данных публичных пользователей ЕС ОГ при использовании возможностей «Служебной связи» в АРМ ЕС ОГ, включая:

  • отображение публичных данных, включая статус по публичным пользователям ЕС ОГ;
  • отображение профиля публичных пользователей ЕС ОГ

из «Журнала вызовов» АРМ ЕС ОГ, «Поиска» АРМ ЕС ОГ;

  • отображение данных профиля публичного органа власти

или учреждения из «Поиска» АРМ ЕС ОГ.

  • Модуль Платформы, обеспечивающий предоставление аналитической отчетности по данным работы Платформы

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

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

  • Модуль Платформы, обеспечивающий резервирование основных данных

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

  1. ТРЕБОВАНИЯ К УСТАНОВКЕ И ВНЕДРЕНИЮ ПЛАТФОРМЫ

4.1. Архитектура        Платформы        в

с возможностью интеграции с СЭД

 
   

 

 
 

4.2. Технические требования к оборудованию

 

 

 

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

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

Процессор: два четырехъядерных от 2.5 ГГц и выше;

Жесткий диск: 200 Гб;

Память: 16 Гб;

ОС: Ubuntu LTS последней версии.

Сервер приложений предназначен для функционирования веб-приложений и сервисов, а именно:

сервиса аутентификации пользователей;

сервиса поиска данных органов власти, зарегистрированных на информационном ресурсе ССТУ.РФ;

сервиса поиска данных пользователей, зарегистрированных на информационном ресурсе ССТУ.РФ;

сервиса обмена данными по обращениям при перенаправлении их по компетенции и/или запросе информации;

сервиса загрузки/сохранения/скачивания приложенных файлов (вложений);

сервиса взаимодействия с тематическим классификатором вопросов; сервиса поиска по базе адресов ФИАС;

сервиса для настройки модуля системы «Интеграция с внешними информационными системами. Регистрация обращений».

Сервер приложений должен иметь следующие минимальные характеристики:

Процессор: два четырехъядерных от 2.5 ГГц и выше;

Жесткий диск: 500 Гб;

Память: 8 Гб;

ОС: Ubuntu LTS последней версии.

Клиентские станции должны иметь следующие минимальные характеристики:

процессор – Intel Core 2 Duo или другой сравнимый по производительности x86-совместимый процессор с количеством ядер 2 и более;

объем оперативной памяти – не менее 1 Гбайт; интернет-обозреватель (Google Chrome, Опера, Яндекс, Microsoft EDGE);

наличие сетевого адаптера или модема; монитор – 1280х1024.

4.3. Порядок внедрения Платформы

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

подготовить серверную инфраструктуру программного обеспечения Платформы;

разработать схему интеграции действующих комплексов и информационных систем по работе и организаций, в том числе систем электронного документооборота, в исполнительных органах государственной власти и органах местного самоуправления в части использования транспортной инфраструктуры ЕС ОГ;

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

приобрести в соответствии с федеральным законодательством в сфере закупок неисключительные права (лицензии) на использование программного обеспечения Платформы;

модернизировать действующие программно-технические комплексы и информационные системы по работе с обращениями граждан и организаций, в том числе системы электронного документооборота, в целях обеспечения интеграции с программным обеспечением Платформы, в соответствии с требованиями, указанными в приложении 1 настоящих методических рекомендаций (требования представлены разработчиком программного обеспечения Платформы и актуальны на 01.11.2020);

провести опытную эксплуатацию Платформы;

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

запустить в промышленную эксплуатацию Платформу.

4.4. Требования к подключению к ЕС ОГ

Подключение к ЕС ОГ осуществляется согласно «Техническим условиям подключения к Единой сети по работе с обращениями граждан государственных органов и органов местного самоуправления».

Схема подключения к ЕС ОГ согласовывается со Спецсвязью ФСО России или подразделением ФСО России в субъекте Российской Федерации.

 

Приложение.

Описание форматов взаимодействия программно-технических
комплексов и информационных систем по работе с обращениями граждан
и организаций и Платформы

Используемые обозначения по тексту

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

ОБОЗНАЧЕНИЕ

ОПИСАНИЕ

Полужирное

Функциональные элементы (экранные кнопки, названия

начертание

окон, полей и т.д.)

Курсив

Ссылки на страницы и разделы в руководстве

Шрифт Courier New

Параметр, используемый в формате общения с API

Примечание.

Пояснение к тексту

Внимание!

Важное замечание или предупреждение о потенциально нежелательных ситуациях

 

Определения и сокращения

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

определение

Это интерфейс программирования, интерфейс создания приложений.

Пример: готовый код, предоставляемый АПК КП ССТУ для использования внешними программными продуктами (например, СЭД).

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

Универсальная форма регистрации обращений встраиваемого модуля системы ЕС ОГ «Интеграция с внешними информационными системами. Регистрация», отвечает за обмен данными на этапе регистрации с системами электронного документооборота органа власти и/или учреждения в режиме реального времени.

Программный модуль

Предназначен для обеспечения работы ЕФР во внешних средах с данными, поставляемыми внешними программными продуктами (например, СЭД).

Единая сеть по работе с обращениями граждан государственных органов и органов местного самоуправления.

Схема интеграции

 

ОПИСАНИЕ ФОРМАТА

Примечание. Для использования API в автоматическом режиме необходима установка модуля ВИС. Регистрация на платформу.

После установки модуля можно вызывать методы API.

REST API «Интеграция с внешними системами. Регистрация обращений» работает по протоколу HTTP и представляет собой набор методов, с помощью которых совершаются запросы и возвращаются ответы для каждой операции. Все ответы приходят в виде JSON структур.

API вызывается HTTP POST-запросами вида: [корневой URL]/api/[метод].

Запросы должны иметь заголовок Content-Type: application/json, в теле запроса должны быть данные в формате JSON в кодировке UTF-8.

Типы данных

Стандартные типы данных JSON:

 
   


Строка. Спецсимволы экранируются как в JavaScript.

Может иметь значения true или false.

Значение, содержащее несколько именованных полей, например, { "number" : "000", "date" : "2016-11-15" }.

Упорядоченная последовательность значений, например,

 
   


128-битный идентификатор, например,

"6F9619FF-8B86-D011-B42D-00CF4FC964FF"

Дата в формате ISO_8601, например,

"2019-07-29T21:15:44.442Z"

Обязательность полей

Поля являются обязательными, если не указано обратное.

(МР-ХМАО.docx 22.12.2020 CП В.В.

Необязательные поля могут быть пропущены или переданы со значением null.

 
   


Возможные HTTP-ответы в случае успешного запроса

No Content. Запрос был выполнен удачно, данные в ответе на запрос не передаются.

Ok. Запрос был выполнен удачно, в теле ответа на запрос содержатся данные.

Примечание. По умолчанию возвращается ответ с HTTP-кодом 200.

403

 

ОПИСАНИЕ

 

Возможные HTTP-ответы в случае возникновения ошибки

Unauthorized. При запросе использовался невалидный или просроченный токен авторизации.

Forbidden. Пользователь, для которого был сгенерирован используемый токен, не имеет доступа к запрашиваемому контенту.

Not found. Запрашиваемый контент не был найден.

Bad Request. Запрос содержит ошибку. Ответ, помимо кода, также может содержать сообщение, поясняющее суть ошибки.

Авторизация

Процесс авторизации возможен только при наличии персонального ключа, которым в дальнейшем должен быть подписан каждый запрос к API (передается в HTTP -заголовке "Authorization").

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

POST /api/integration/auth

Content-Type: application/json

username

 

password

 

ПАРАМЕТР

 

ОПИСАНИЕ

 

Данные запроса

Логин для доступа к API конкретного органа власти.

Пароль для доступа к API конкретного органа власти.

Описание ответа

ПРИМЕР ОТВЕТА:

{

"token":

"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJVc2VySWQiOiI2NTM2NmU4NS1hOWM2 LWU2MTEtODBlOC0wMDUwNTY4MjNmZjgiLCJuYmYiOjE1NjQ0MzY4MDUsImV4cCI6MTU2ND UyMzIwNX0.royWs0L2u2OQ0mn1eOuLWJ8RU3tOKlRF9gxjrzEt5W4",

 
   

 

Токен доступа.

 

ТИП ДАННЫХ. ОПИСАНИЕ

 

}

 

"lifeTime": 86400000"

Время жизни токена (в миллисекундах).

ОПИСАНИЕ

 

Описание возможных ошибок

Пользователь с данным логином и паролем не найден.

Пользователь с данным логином не имеет лицензии на интеграцию.

Регистрация обращений в ЕФР

GET /api/integration/registrationForm

Для регистрации обращения с использованием ЕФР в интерфейсе ЕСОГ необходимо перейти по предоставленной ссылке и ввести логин и пароль учетной записи пользователя ССТУ в появившемся окне.

Зарегистрированное обращение получит уникальный идентификатор appealId, будет сохранено в ЕСОГ и доступно для дальнейшей выгрузки в СЭД.

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

Регистрация текстов заявителей

POST /api/integration/registration/applicantText

Content-Type: application/json

Текст заявителя будет сохранен в ЕСОГ независимо от результата валидации, ему будет выдан уникальный идентификатор applicantTextId. Закончить регистрацию текста заявителя в качестве обращения можно в единой форме регистрации, выбрав текст заявителя из предложенного списка.

Данные запроса

ПРИМЕР ЗАПРОСА:

{

"sourceType": "email",

"form": "inWriting",

"receiptDate": "2019-07-29T21:15:44.442Z", "applicant":

{

"responseType": "email",

"phone": "string",

"email": "string", "foreignAddress": "string", "constantWriter": true

},

"text":

"sendingDate":

"addressedTo":

"addressedToType":

"attachmentsPageCount": 0,

}

Параметры запроса должны соответствовать данным объекта текста заявителя.

Описание ответа

ПРИМЕР ОТВЕТА:

{

"applicantTextId" : "220d9b46-1954-4352-ad50-bee0606dcbeb", "resultList

[

{ "field"

{ "field"

..." }

       
   
     
 

 

}

ПАРАМЕТР

ТИП

ДАННЫХ

ОПИСАНИЕ

applicantTextId

Guid

ID текста заявителя, сохраненного в ЕСОГ.

isValid

Boolean

Итоговый признак успешности прохождения валидации.

appealValidationResult

Array <Object>

Содержит результат валидации полей обращения.

applicantValidationResult

Array <Object>

Содержит результат валидации полей объекта заявителя.

questionValidationResult

Array <Object>

Содержит результат валидации полей вопросов обращения.

 

 

Результат валидации поля

ПАРАМЕТР

ТИП

ДАННЫХ

ОПИСАНИЕ

Field

String

Наименование поля.

IsValid

Boolean

Признак валидности.

Message

String

Необязательно. Описание ошибки.

 

 

Примечание. Если текст заявителя не прошел валидацию, можно повторно отправить методу исправленные данные с указанием ранее полученного applicantTextId.

Регистрация обращений (без ЕФР)

POST /api/integration/registration/appeal

Content-Type: application/json

Чтобы зарегистрировать обращение и получить уникальный идентификатор, необходимо пройти валидацию. В случае неудачной попытки, данные обращения будут сохранены в виде объекта текста заявителя, которому будет выдан свой applicantTextId. Используя этот идентификатор, можно будет либо открыть текст заявителя в интерфейсе ЕСОГ (пункт 2.5) и зарегистрировать его как обращение, либо продолжить процесс регистрации с использованием данного метода вплоть до успешного прохождения валидации и получения applicantId.

Данные запроса

Параметры запроса должны соответствовать данным объекта текста заявителя

Описание запроса

                 
           
 
           
 

 

 

ID обращения, выданный ЕСОГ в случае успешной валидации.

По запросам информации и не обращениям appealId не выдается.

           
         
   
 

 

ID текста заявителя, сохраненного в ЕСОГ в случае неудачного прохождения валидации.

Может быть использован

 

 

27

для повторных попыток валидации данных обращения.

isValid

Boolean

Итоговый признак успешности прохождения валидации.

appealValidationResult

Array <Object>

Содержит результат валидации полей обращения.

applicantValidationResult

Array <Object>

Содержит результат валидации полей объекта

 

 

заявителя.

questionValidationResult

Array <Object>

Содержит результат валидации полей вопросов обращения.

 

Результат валидации поля

ПАРАМЕТР

ТИП

ДАННЫХ

ОПИСАНИЕ

Field

String

Наименование поля.

IsValid

Boolean

Признак валидности.

Message

String

Необязательно. Описание ошибки.

 

Доступ к тексту заявителя в интерфейсе ЕСОГ

GET /api/integration/applicantText/?applicantTextId=

URL для открытия текста заявителя в интерфейсе ЕСОГ является составным: его статическая часть – это путь к методу API, возвращающему страницу с текстом заявителя, а динамическая – это идентификатор текста заявителя.

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

 

Пример:

http://xx.xx.xx.xx/ESOG/api/integration/applicantText/?

applicantTextId=1546c67a-8d4a-40fd-9040-5a93fa4a6be

ПАРАМЕТР

ТИП ДАННЫХ

ОПИСАНИЕ

applicantTextId

Guid

ID текста заявителя, присвоенный ЕСОГ.

 

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

Доступ к обращению в интерфейсе ЕСОГ

GET /api/integration/appeal/?appealId=&token=

URL для открытия обращения в интерфейсе ЕСОГ является составным: его статическая часть – это путь к методу API, возвращающему страницу с обращением, а динамическая – это идентификатор обращения и токен авторизации.

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

Пример:

http://xx.xx.xx.xx/ESOG/api/integration/appeal/?appealId=1546c 67a-8d4a-40fd-9040-5a93fa4a6be

Необязательно.

 

ОПИСАНИЕ

 

&token=eyJVc2VySWQiOiJiNmJOGNhLWU4MTEtODEwOS0wMDUwNTY4MjNmZjgi LCJuYmYiOjE1NzzODksImV4cCI6MTU3NjU3NDc4OX0

Токен авторизации, полученный ранее.

ID обращения, присвоенный ЕСОГ.

 

Выгрузка обращений в СЭД

GET /api/integration/getAppeals

Content-Type: application/json

Данные запроса

           
           

 

           
         
   
 

 

                 
     
   
       
 
 
 
         
   
 

 

 

Способ регистрации обращений.

Принимает следующие значения:

null – все зарегистрированные обращения;

"esogOnly" – обращения, зарегистрированные через ЕФР в интерфейсе ЕСОГ (без участия СЭД);

"esogForm" - обращения, зарегистрированные через ЕФР в интерфейсе ЕСОГ, открытой из интерфейса СЭД

(т.е. с участием СЭД);

"externalSystems" - обращения, зарегистрированные через интерфейс СЭД (и прошедшие валидацию в ЕСОГ);

зарегистрированные в интерфейсе ЕСОГ СЭД), доступны только лицензии «ВИС. СЭД.

               
     
 
         
   
 

 

Список значений applicantTextId текстов заявителей, зарегистрированных в ЕСОГ.

Если текст заявителя с указанным здесь applicantTextId впоследствии был зарегистрирован в качестве обращения, то это обращение будет присутствовать в выгрузке.

ids

Array<Guid>

Необязательно.

Список значений appealId обращений, которые планируется выгрузить.

Если список не пуст, то остальные параметры игнорируется.

Описание ответа

 

ПАРАМЕТР

ТИП ДАННЫХ

ОПИСАНИЕ

appealId

Guid

Уникальный идентификатор обращения в ЕСОГ, присвоенный, если текст заявителя был успешно зарегистрирован в качестве обращения.

customFields

Array<Object>

Необязательно.

Дополнительные поля, которые могут

 

 

создаваться и заполняться при регистрации обращений в ЕСОГ.

Представляют из себя массив объектов:

{ "fieldName" : "value" }, например { "birthDate" : "2001­07-29" }

           
         
   
 

 

 

           
 

Content-Type: multipart/form-data

 
 
   

ОПИСАНИЕ

 
 
   

Файл.

 
 
   

Необязательно.

 
 
   

Необязательно.

 
           
         
   
 

 

Проект первичного поручения для СЭД.

Представляет из себя объект, поля которого перечислены в пункте 2.12.4.

Остальные параметры идентичны данным объекта текста заявителя (пункт 2.12.1)

Загрузка файла

Загрузка файлов возможна как после получения идентификатора текста заявителя или обращения в ЕСОГ (используется applicantTextId или appealId), так и до этого момента (используется correlationId).

Данные запроса

POST /api/integration/file/upload

Идентификатор текста заявителя в ЕСОГ, к которому должен быть привязан файл.

Идентификатор текста заявителя в СЭД, к которому должен быть привязан файл.

 

Идентификатор обращения в ЕСОГ,

 

ПАРАМЕТР

ТИП ДАННЫХ

ОПИСАНИЕ

 

к которому должен быть привязан файл.

 

 

Данные ответа

ПАРАМЕТР

ТИП ДАННЫХ

ОПИСАНИЕ

fileId

Guid

Идентификатор файла в ЕСОГ.

 

Выгрузка файла

Чтобы выгрузить файл из системы ЕСОГ, необходимо знать его уникальный идентификатор fileId.

Данные запроса

POST /api/integration/file/download/fileId

Content-Type: multipart/form-data

ПАРАМЕТР

ТИП ДАННЫХ

ОПИСАНИЕ

fileId

Guid

Идентификатор файла.

 

Данные ответа

В случае наличия прав на скачивание файла и доступности самого файла, начнется его скачивание.

Отправка данных поручения, связанного с обращением

Данный метод служит как для отправки данных о создании нового поручения, так и для обновления данных уже созданного и хранящегося в ЕСОГ.

Данные запроса

POST /api/integration/commission

Content-Type: application/json

ПАРАМЕТР

ТИП

ОПИСАНИЕ

 

ДАННЫХ

 

 

 

 
   

 

 
 

Данные ответа

 
                   
     
 
   
 
   
 
   
 
     
 
     
 
   


 

 

В случае удачного сохранения данных в ЕСОГ, метод вернет ответ с кодом 204.

Методы для получения данных справочников

Данные методы служат для получения значений справочников, используемых в ЕФР. В ответе на запрос будет присутствовать список объектов со следующими полями:

ПАРАМЕТР

ТИП

ОПИСАНИЕ

 

ДАННЫХ

 

String

 

value

 

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


 

ПАРАМЕТР

ТИП

ОПИСАНИЕ

 

ДАННЫХ

 

обращений в СЭД.

 

Краткое текстовое описание элемента справочника.

Необязательно.

Расширенное описание элемента справочника.

Например, элемент справочника для первичной регистрации:

"Appeal59fl",

"Обращение по 59-ФЗ",

"Обращения, подлежащие рассмотрению в порядке, установленном Федеральным законом от 2 мая

}

Базовый URL для api/integration/directories, application/json. Справочники к базовому URL названий методов, представленных в таблице:

МЕТОД

ОПИСАНИЕ

appealForm

Форма обращения.

primaryClassification

Первичная классификация.

appealSource

Канал поступления.

addresseeType

Тип адресата.

applicantType

Тип заявителя.

socialStatus

Социальное положение.

classifierType

Тип классификатора.

questionKind

Вид вопроса.

 

                                       
     
     
 
 
   
 
     
       
 
 
       
 
 
     
 
     
 
     
 
     

 

     
 

ТИП

ДАННЫХ

 
 
 

Guid

 
       
   
 
   
 
   

 

ОПИСАНИЕ

 

ПАРАМЕТР

ТИП

ОПИСАНИЕ

 

ДАННЫХ

 

                               
         
   
 
     
 
 
         
     
 
 
 
     
 
         
     
 
         
 
 
 
         
     
 
 


заявителя в ЕСОГ.

 

Порядковый номер, присвоенный обращению в системе СЭД.

Используется для генерации номера обращения по маске, заданной в настройках АРМ.

Ограничения: максимальная длина строки –

50 символов.

           
         
   
 
 

 

 

Ссылка на обращение/текст заявителя в системе СЭД.

           
         
   
 
 

 

 

Текст первичного поручения.

           
         
   
 

 

 

Принимает значения справочника appealSource

           
         
   
 
 

 

 

ПАРАМЕТР

ТИП

ОПИСАНИЕ

 

ДАННЫХ

 

Альтернативный канал поступления.

 

Принимается во внимание, когда appealSource имеет значение other.

Ограничения:

максимальная длина строки –

30 символов.

           
         
   
 



Признак «Акция» - обращения от разных заявителей по одному и то му же вопросу с типовым текстом.

           
         
   
 



Поступило от иной организации.

true – свидетельствует о том, что обращение было получено от иного органа

false – что обращение было получено напрямую от заявителя.

           
         
   
 
 

 

 

Номер сопроводительного документа, приложенного к обращению, поступившему от иной организации.

Обязательно, если поступило от иной организации.

Ограничения: максимальная длина строки –

50 символов.

           
         
   
 

 

Id, с которым организация, направившая обращение, зарегистрирована на ССТУ.РФ.

ПАРАМЕТР

ТИП

ДАННЫХ

ОПИСАНИЕ

requestingDepartmentName

String

Необязательно.

Наименование организации, направившей обращение, если организация не зарегистрирована на ССТУ.РФ.

appealForm

String

Форма обращения.

Принимает значения справочника appealForm.

primaryClassification

String

Первичная классификация.

Принимает значения справочника primaryClassification.

receipted

String($date-

time)

Дата поступления текста заявителя в орган.

applicant

Object

Объект, отражающий сущность заявителя. Параметры объекта описаны в следующей таблице.

text

String

Аннотация, краткое содержание текста заявителя.

questions

Array <Object>

Необязательно.

Вопросы обращения – список объектов, набор полей которых представлен в таблице «Вопрос обращения» данного раздела.

sendingDate

String($date- time)

Необязательно.

Дата направления обращения, либо указанная гражданином в соответствии с 59-ФЗ, либо дата сопроводительного документа при получении обращения по

 

 

ПАРАМЕТР

ТИП

ОПИСАНИЕ

 

ДАННЫХ

 

           
   
 
     
 
     


компетенции от иного органа.

 

Адресат в свободном текстовом выражении.

Ограничения:

максимальная длина строки – 255 символов.

           
         
   
 

 

 

Тип адресата.

Принимает значения справочника addresseeType.

           
         
   
 

 

 

Альтернативный тип адресата.

Принимается во внимание, если аddressedToType имеет значение other.

Ограничения: максимальная длина строки –

Необязательно.

 

Необязательно.

 

100 символов.

Список идентификаторов файлов вложений текста заявителя в ЕСОГ.

Количество листов вложений.

Обязательно, если есть вложения.

Ограничения: максимальное количество листов –

ПАРАМЕТР

ТИП

ДАННЫХ

ОПИСАНИЕ

 

 

Заявитель

Все параметры, кроме type, будут являться необязательными, если заявитель является анонимным (type имеет значение Anonymous), для иных случаев условия обязательности параметров представлены в таблице.

                     
     
         
 
 
     
     
   
 
 


Принимает значения справочника applicantType, указанного в пункте 2.11 данного руководства.

           
   
     
 
     
 
     
 
     
 
     
 



Наименование организации.

Обязательно, если тип заявителя juridicalPerson (юридическое лицо).

Ограничения:

максимальная длина строки – 100 символов.

           
         
   
 
 



Ограничения:

максимальная длина строки – 40 символов.

           
         
   
 
 

 

Ограничения:

 

ПАРАМЕТР

ТИП

ДАННЫХ

ОПИСАНИЕ

 

 

максимальная длина строки – 40 символов.

middleName

String

Необязательно.

Отчество заявителя.

Ограничения:

максимальная длина строки – 40 символов.

birthDate

String($date- time)

Необязательно.

Дата рождения заявителя.

socialStatus

String

Социальный статус.

Принимает значения справочника socialStatus, указанного в пункте 2.11 данного руководства.

altSocialStatus

String

Необязательно.

Альтернативный социальный статус в понятном текстовом выражении.

Принимается во внимание, если socialStatus имеет значение other.

Ограничения:

максимальная длина строки – 30 символов.

phone

String

Необязательно.

Номер телефона.

Ограничения:

строго 11 цифровых знаков.

email

String

Необязательно.

Адрес электронной почты.

Обязательно, если:

Форма обращения «В форме электронного документа»

 

ПАРАМЕТР

 

ТИП

ДАННЫХ

 

ОПИСАНИЕ

 

responseAddress

 

Object

 

Необязательно. Почтовый адрес РФ в формате административно­территориального деления ФИАС.

 

Обязательно, если:

 

Форма обращения «В письменной форме» и отсутствует foreignAddress

 

baseAddressId

 

Guid

 

Идентификатор адресного объекта в ФИАС.

 

foreignAddress

 

String

 

constantWriter

 

Boolean

 

building

 

String

 

Номер строения.

 

room

 

String

 

Необязательно.

Номер

помещения.

 

Необязательно. Иной адрес в свободном текстовом выражении.

 

Обязательно, если:

 

Форма обращения «В письменной форме» и отсутствует responseAddress

Ограничения:

 

максимальная длина строки – 255 символов.

 

Необязательное.

 

Признак "Много пишущий автор".

Необязательно.

Список соавторов в формате: "Name": "string"

Обязательно наличие хотя бы одного соавтора, если тип заявителя Collective (коллективное).

 

Вопрос обращения

 

 

       
 

ОПИСАНИЕ

 
 
 

Код вопроса.

 
 
 

Наименование вопроса.

 
 
 

Тип вопроса.

 
           
         
   
 

 

Вид вопроса.

Принимает значения справочника questionKind.

Принимает значения справочника questionType.

 

Принимает значения справочника сlassifierType.

Предмет ведения (уровень компетенций).

Принимает значения справочника competenceLevel.

           
     
     
   
 
 


Признак «Факт нарушения законодательства в сфере миграции».

Первичное поручение

 

       
   
 
     


Идентификатор поручения в ЕСОГ.

Необязательно.

Текст поручения.

Необязательно.

Код вопроса, по которому создано поручение.

String

 

String

 

Array <String>

 

ТИП

ДАННЫХ

 

String($date- time)

 
 
   


Необязательно.

Плановый срок исполнения поручения.

Необязательно.

             
   
 
     
 
     
 
     
 
     


Управление базами данных

Базы данных Postgresql и MS SQL реплицируются непрерывно. Балансировка запросов к мастеру и репликам осуществляется с помощью pg-pool.

Рисунок 1 — Схема репликации базы данных

 

Защита данных

Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie)
и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

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

Все токены аутентификации, использующие файлы cookie, становятся недействительными.

При выполнении следующего запроса пользователю требуется выполнить вход снова.

Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.

Длинные поля заголовка запроса

Если приложение требует поля заголовка запроса длиннее, чем разрешено параметрами прокси-сервера по умолчанию (обычно 4 или 8 КБ в зависимости от платформы), следующие директивы требуют корректировки. Применяемые значения зависят от условий. Дополнительные сведения см. в документации сервера: proxy_buffer_size proxy_buffers proxy_busy_buffers_size large client header buffers

Внимание! Не увеличивайте значение буферов прокси-сервера по умолчанию, если это не требуется. Увеличение этих значений повышает риск переполнения буфера и атак типа "отказ в обслуживании" (DoS) со стороны злоумышленников.


Защита приложения

Включение AppArmor

Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor – это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.

Настройка брандмауэра

Закройте все внешние порты, которые не используются. Незамысловатый межсетевой экран (ufw) позволяет взаимодействовать с iptables, предоставляя интерфейс командной строки для настройки межсетевого экрана.

Внимание! Неправильно настроенный брандмауэр предотвратит доступ ко всей системе. Если задать неправильный порт SSH, то при использовании SSH для подключения к системе произойдет ее блокировка. Порт по умолчанию – 22.

Установите ufw и настройте его для разрешения прохождения трафика через все необходимые порты.

bash

sudo apt-get install ufw sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable

Защита Nginx

Изменение имени ответа Nginx

Внесите изменения в файл src/http/ngx_http_header_filter_module.c: static char ngx_http_server_string[] = "Server: Web Server" CRLF;

static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Настройка параметров

Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например, ModSecurity.

Конфигурация HTTPS

Настройка приложения для безопасных (HTTPS) локальных подключений

Команда dotnet run использует файл Properties/launchSettings.json,            который настраивает

 
   


для прослушивания URL-адресов, заданных applicationUrl (например, https://localhost:5001;http://localhost:5000).

 

Настройка обратного прокси-сервера для безопасного клиентов (HTTPS):

Настройте сервер для прослушивания трафика HTTPS через порт 443, указав действительный сертификат, выпущенный доверенным центром сертификации (ЦС).

Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf. Это может быть выбор более строгого шифра и перенаправление всего                    HTTP-трафика

в HTTPS.

При добавлении заголовка HTTP Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS.

Если в дальнейшем планируется отключить HTTPS, не добавляйте заголовок HSTS или выберите соответствующий элемент max-age.

Добавьте файл конфигурации /etc/nginx/proxy.conf: nginx

proxy_redirect proxy_set_header proxy_set_header proxy_set_header proxy_set_header client_max_body_size client_body_buffer_size 128k;

proxy_connect_timeout 90;

proxy_send_timeout

proxy_read_timeout

proxy_buffers

Измените файл конфигурации /etc/nginx/proxy.conf. В этом примере показаны разделы http и server одного и того же файла конфигурации. nginx

http {

include /etc/nginx/proxy.conf;

limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;

server_tokens off;

sendfile on;

keepalive_timeout 29; # Adjust to the lowest possible value that makes sense for your use case. client_body_timeout 10; client_header_timeout 10; send_timeout 10;

upstream hellomvc{ server localhost:5000;

}

server {

listen *:80;

add_header Strict-Transport-Security max-age=15768000; return 301 https://$host$request_uri;

}

*:443 ssl;

example.com;

/etc/ssl/certs/testCert.crt;

/etc/ssl/certs/testCert.key;

TLSv1.1 TLSv1.2;

"EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"; secp384r1;

shared:SSL:10m;

off;

on; #ensure your cert is capable

on; #ensure your cert is capable

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; add_header X-Frame-Options DENY;

add_header X-Content-Type-Options nosniff;

#Redirects all traffic location / {

proxy_pass http://hellomvc;

limit_req zone=one burst=10 nodelay;

Защита Nginx от кликджекинга

Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.

Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.

Измените файл nginx.conf.

bash

sudo nano /etc/nginx/nginx.conf

Добавьте строку add_header X-Frame-Options "SAMEORIGIN";.

Сохраните файл.

Перезапустите Nginx.

Сканирование типа MIME

Этот заголовок предотвращает MIME-сканирование ответов с указанным типом содержимого в большинстве браузеров, запрещая браузеру переопределять тип содержимого ответа. Параметр nosniff означает, что, если сервер определяет содержимое как text/html, браузер будет обрабатывать его как text/html.

Измените файл nginx.conf.

bash

sudo nano /etc/nginx/nginx.conf

Добавьте строку add_header X-Content-Type-Options "nosniff" и сохраните файл, а затем перезапустите Nginx.