Приказ Минкомсвязи России от 23.07.2015 N 279
МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРИКАЗ
от 23 июля 2015 г. N 279
ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ
К ОБОРУДОВАНИЮ И ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ ОПЕРАТОРОВ
ПОЧТОВОЙ СВЯЗИ ДЛЯ ОБЕСПЕЧЕНИЯ ДОСТУПА К БАЗАМ ДАННЫХ
ОБ ОКАЗАННЫХ УСЛУГАХ ПОЧТОВОЙ СВЯЗИ И ПОЛЬЗОВАТЕЛЯХ
УСЛУГАМИ ПОЧТОВОЙ СВЯЗИ ПРИ ПРОВЕДЕНИИ
ОПЕРАТИВНО-РОЗЫСКНЫХ МЕРОПРИЯТИЙ
В целях реализации требований части 2 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; N 52, ст. 5038; 2004, N 35, ст. 3607; N 45, ст. 4377; 2005, N 19, ст. 1752; 2006, N 6, ст. 636; N 10, ст. 1069; N 31, ст. 3431, ст. 3452; 2007, N 1, ст. 8; N 7, ст. 835; 2008, N 18, ст. 1941; 2009, N 29, ст. 3625; 2010, N 7, ст. 705; N 27, ст. 3408; N 31, ст. 4190; 2011, N 9, ст. 1205; N 25, ст. 3535; N 27, ст. 3880; N 29, ст. 4291; N 30, ст. 4590; N 45, ст. 6333; N 49, ст. 7061; N 50, ст. 7351, ст. 7366; 2012, N 31, ст. 4322, ст. 4328; N 53, ст. 7578; 2013, N 19, ст. 2326; N 27, ст. 3450; N 43, ст. 5451; N 44, ст. 5643; N 48, ст. 6162; N 49, ст. 6339, ст. 6347; N 52, ст. 6961, ст. 5038; 2014, N 6, ст. 560; N 14, ст. 1552; N 19, ст. 2302; N 26, ст. 3366; N 30, ст. 4229), пунктов 4, 6, 11 Правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность, утвержденных постановлением Правительства Российской Федерации от 27 августа 2005 г. N 538 (Собрание законодательства Российской Федерации, 2005, N 36, ст. 3704; 2007, N 48, ст. 6010; 2008, N 42, ст. 4832; 2013, N 15, ст. 1804), приказываю:
1. Утвердить прилагаемые Требования к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий (далее - Требования).
2. Операторы почтовой связи обязаны обеспечить выполнение Требований не позднее одного года со дня утверждения плана мероприятий по внедрению технических средств, предусмотренного Правилами взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность, утвержденными постановлением Правительства Российской Федерации от 27.08.2005 N 538.
3. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.
4. Контроль за исполнением настоящего приказа возложить на заместителя Министра связи и массовых коммуникаций Российской Федерации М.Я. Евраева.
Министр
Н.А.НИКИФОРОВ
Утверждены
приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ
К ОБОРУДОВАНИЮ И ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ ОПЕРАТОРОВ
ПОЧТОВОЙ СВЯЗИ ДЛЯ ОБЕСПЕЧЕНИЯ ДОСТУПА К БАЗАМ ДАННЫХ
ОБ ОКАЗАННЫХ УСЛУГАХ ПОЧТОВОЙ СВЯЗИ И ПОЛЬЗОВАТЕЛЯХ
УСЛУГАМИ ПОЧТОВОЙ СВЯЗИ ПРИ ПРОВЕДЕНИИ
ОПЕРАТИВНО-РОЗЫСКНЫХ МЕРОПРИЯТИЙ
1. Общие требования к информационным системам,
содержащим базы данных абонентов оператора связи
и предоставленных им услугах связи
Технические средства оперативно-розыскных мероприятий, содержащие базы данных операторов почтовой связи (далее - ОПС <1>), необходимые для обеспечения проведения оперативно-розыскных мероприятий на сетях почтовой связи, предназначены для накопления, хранения, обработки и предоставления уполномоченным государственным органам, осуществляющим в соответствии с Федеральным законом от 12.08.1995 N 144-ФЗ "Об оперативно-розыскной деятельности" (Собрание законодательства Российской Федерации, 1995, N 33, ст. 3349; 1997, N 29, ст. 3502; 1998, N 30, ст. 3613; 1999, N 2, ст. 233; 2000, N 1, ст. 8; 2001, N 13, ст. 1140; 2003, N 2, ст. 167; N 27, ст. 2700; 2004, N 27, ст. 2711; N 35, ст. 3607; 2005, N 49, ст. 5128; 2007, N 31, ст. 4008, ст. 4011; 2008, N 18, ст. 1941; N 52, ст. 6227, ст. 6235, ст. 6248; 2011, N 1, ст. 16; N 48, ст. 6730; N 50, ст. 7366; 2012, N 29, ст. 3994; N 49, ст. 6752; 2013, N 14, ст. 1661; N 26, ст. 3207; N 44, ст. 5641; N 51, ст. 6689) оперативно-розыскную деятельность (далее - уполномоченные органы), информации о пользователях услуг связи, оказанных им услугах связи, а также иной информации.
--------------------------------
<1> Перечень используемых терминов и сокращений содержится в Приложении N 9 к настоящим требованиям.
1.1. Настоящие требования распространяются на ТС ОРМ, используемые и/или подлежащие установке на сетях операторов связи, осуществляющих деятельность в области оказания услуг почтовой связи.
1.2. Устанавливаемые операторами связи на информационные системы операторов почтовой связи ТС ОРМ должны представлять собой АПК, обеспечивающий процессы сбора, регистрации, обработки, хранения и передачи уполномоченным органам информации о пользователях услугами почтовой связи и предоставленных им услугах связи, поступающей от одного или нескольких операторов почтовой связи.
1.3. ИС ОПС обеспечивают передачу на ТС ОРМ информации обо всех оказанных услугах почтовой связи и пользователях услугами почтовой связи в соответствии с Приложением N 1.
2. Общие функциональные (технические) требования
2.1. Построение ТС ОРМ должны обеспечивать:
2.1.1. организацию БД для накопления, хранения в течение трех лет и обработки информации о пользователях услуг связи, оказанных им услугах связи, иной информации;
2.1.2. прием и первичную обработку информации о пользователях услуг связи и оказанных им услугах связи из ИС ОПС от одного или нескольких операторов связи для занесения в БД ТС ОРМ;
2.1.3. добавление в БД ТС ОРМ информации об оказанных услугах почтовой связи, независимо от. того, присутствует или нет в БД ТС ОРМ информация об абонентах (пользователях), которым услуги связи предоставляются;
2.1.4. ИС ОПС выполняют передачу информации на ТС ОРМ о пользователях услуг связи и оказанных им услугах почтовой связи не реже одного раза в час;
2.1.5. защиту от несанкционированного доступа к данным ТС ОРМ с помощью программных и технических средств, а также организационных мер;
2.1.6. круглосуточный автоматизированный удаленный доступ к ТС ОРМ со стороны ПУ уполномоченных органов;
2.1.7. прием из ПУ различных видов запросов о пользователях услуг связи и оказанных им услугах связи;
2.1.8. передачу на ПУ из ТС ОРМ информации в соответствии с запросами;
2.1.9. регистрацию и хранение поступающих запросов, удаление запросов уполномоченными пользователями.
2.2. ТС ОРМ должны являться завершенным модульным АПК, предоставляющим возможность оператору связи ввода в эксплуатацию с любого набора услуг, согласно лицензиям на предоставление услуг связи. Модульное построение должно обеспечивать возможность расширения (замены) состава аппаратных и программных средств ТС ОРМ для улучшения эксплуатационных характеристик ТС ОРМ по мере увеличения количества абонентов, возрастания объемов обрабатываемой информации, расширения функций системы без изменения информации, хранящейся в уже сформированных базах данных.
2.3. ТС ОРМ должны содержать ПО мониторинга и управления КТС ТС ОРМ со стороны ПУ.
2.4. ТС ОРМ должны вести системные журналы, включающие в себя:
- информацию о сессиях;
- информацию о запросах на получение данных;
- информацию об ответах на запросы о получении данных;
- информацию об отчетах;
- информацию о текущей конфигурации КТС, системного и прикладного ПО;
- информацию об изменениях в конфигурации КТС, системного и прикладного ПО;
- информацию о неполадках в КТС, системном и прикладном ПО;
- информацию о доступе технического персонала оператора связи к ТС ОРМ;
- информацию о НСД и попытках НСД.
ТС ОРМ не должны фиксировать в системных журналах никакой информации, относящейся к идентификаторам, содержимому поисковых задач ПУ.
2.5. Доступ технического персонала оператора связи к ТС ОРМ должен осуществляться через модуль доступа, который обеспечивает запись команд управления ТС ОРМ и построение парольной системы.
Технический персонал оператора связи должен иметь доступ только к системным журналам ТС ОРМ, системному ПО и КТС, входящим в ТС ОРМ для проведения ремонтных работ.
2.6. ТС ОРМ должны исключать возможность передачи любой информации, касающейся функционирования ТС ОРМ на оборудование ИС ОПС.
2.7. ТС ОРМ независимо от своего функционального состояния не должны нарушать работу ИС ОПС.
2.8. Проведение организационно-технических мероприятий должно обеспечивать защиту ТС ОРМ от несанкционированного доступа:
- производителя ТС ОРМ;
- неавторизованных пользователей;
- технического персонала оператора связи;
- третьих лиц.
2.9. Защита информации должна осуществляться при:
- загрузке информации в ТС ОРМ;
- получении ТС ОРМ запросов;
- обработке информации в ТС ОРМ;
- хранении запросов к ТС ОРМ и результатов их выполнения;
- передаче на ПУ результатов обработки запросов;
- получении ТС ОРМ информации от ИС ОПС.
2.10. К ТС ОРМ должны иметь доступ:
- программные средства ИС ОПС о пользователях услуг связи и оказанных им услугах связи (источник информации);
- технический персонал оператора связи;
- ПУ уполномоченных органов.
2.11. Источник информации должен иметь возможность осуществлять ввод информации в ТС ОРМ в согласованном с поставщиком ТС ОРМ формате в автоматическом и/или автоматизированном режиме.
2.12. Для технического персонала оператора связи ТС ОРМ должны предоставлять следующие функции:
- доступ к журналу ошибочных блоков переданных отчетов и возможность редактирования ошибочных записей соответствующих отчетов;
- доступ к аппаратным и программным компонентам ТС ОРМ для проведения регламентных и ремонтных работ.
2.13. Технический персонал оператора связи, обслуживающий ТС ОРМ, должен иметь доступ только через специальные технические средства защиты.
2.14. Если в связи со структурой организации сети связи ОПС обслуживает одновременно несколько входящих в его структуру территориально-распределенных филиалов по субъектам Российской Федерации (отдельных юридических лиц), то ТС ОРМ могут накапливать информацию об абонентах и оказанных им услугах связи для нескольких филиалов ОПС.
При обращении ПУ с поисковыми задачами к ТС ОРМ ПУ должен иметь возможность явно задавать перечень филиалов, для которых должна выполняться поисковая задача.
При явном указании списка филиалов оператора в параметрах поисковой задачи, запрос в целом должен выполняться в соответствии с временными характеристиками, приведенными в Разделе 3 "Требования, предъявляемые к временным характеристикам ТС ОРМ и БД" настоящих Требований. Обновление в БД ТС ОРМ информации об абонентах и оказанных им услугах связи по каждому филиалу (другому юридическому лицу) должно выполняться в соответствии с п. 2.1.4 настоящих Требований.
2.15. В случае, если какая-либо составная часть информации об абонентах оператора связи хранится в неструктурированном строковом виде (т.е. не разделенная на составные части в соответствии с описанием таких данных об абонентах согласно Приложению N 7), при выполнении запросов об абонентах ТС ОРМ должны осуществлять полнотекстовый поиск по такой неструктурированной информации, используя поисковые критерии задачи.
3. Требования, предъявляемые к временным характеристикам
ТС ОРМ и БД
3.1. Время выполнения задач в БД ТС ОРМ поиска информации о пользователях и оказанных им услугах связи не превышает значений, приведенных в Таблице 1.
Требования к временным характеристикам поиска информации в ТС ОРМ разделяются по следующим классам:
- класс 1 (К1) включает критерии:
- идентификатор почтового отправления;
- класс 2 (К2) включает критерии:
- фамилия, имя, отчество (при наличии), наименование организации пользователя услугами почтовой связи;
- почтовый адрес пользователя услугами почтовой связи;
- паспортные данные пользователя услугами почтовой связи;
- номер договора на оказание услуг почтовой связи;
- класс 3 (К3) включает критерии, состоящие из атрибутов записи о почтовом отправлении.
Таблица 1
Класс параметра запроса
Временной интервал
до суток
до 1 месяца
до 6 месяцев
до 1 года
до 3 лет
К1
< 2 сек.
< 5 сек.
< 15 сек.
< 20 сек.
< 40 сек.
К2
< 5 сек.
< 30 сек.
< 60 сек.
< 80 сек.
< 180 сек.
К3
< 5 сек.
< 20 сек.
< 40 сек.
< 60 сек.
< 90 сек.
Примечание: для отсутствующих в таблице идентификаторов время выполнения задачи в ТС ОРМ может быть больше приведенного.
3.2. ТС ОРМ должны поддерживать возможность выполнения комбинированных запросов. Комбинированными запросами являются поисковые критерии согласно п. 3.1, объединенные логическими операциями.
ТС ОРМ должны поддерживать следующие логические операции для объединения критериев: "И", "ИЛИ" операции группировки критериев "(", ")" и логическое "НЕ".
Использование критериев с использованием операции логического "НЕ" допускается только совместно с другими критериями, не являющимися логическим отрицанием, и объединяется с ними с помощью логических операций объединения критериев. Результирующий критерий должен иметь хотя бы одну логическую операцию "И".
К времени поиска информации в БД ТС ОРМ при выполнении комбинированных поисковых запросов предъявляются следующие требования:
- при выполнении поискового запроса по двум поисковым критериям в зависимости от вида логической операции:
- для операции "И": T(AB) - максимум (T(A), T(B)) * C, но меньше, чем T(A) + T(B), где C - константа (допускается значение больше единицы), T(A), T(B) - время выполнения поисковых запросов по каждому из критериев, T(AB) - время выполнения поискового запроса по критериям, объединенным операцией "И");
- для операции "ИЛИ": T(AB) меньше или равно T(A) + T(B), где A, B - поисковые критерии, T(A), T(B) - время выполнения поисковых запросов по каждому из критериев, T(AB) - время выполнения поискового запроса по критериям, объединенным операцией "ИЛИ");
- для операции "НЕ": T(A("НЕ" B)) меньше либо равно T(AB), где A, B - поисковые критерии, T(AB) время выполнения поискового критерия без операции логического "НЕ";
- при выполнении комбинированного поискового запроса по большему числу критериев (больше двух), требования ко времени поиска должны формироваться аналогично описанному выше способу с учетом операций группировки критериев:
- для последовательного объединения поисковых критериев T(ABC) больше или равно максимум (T(AB), T(C)) * C, где T(AB) определяется аналогично варианту комбинирования двух критериев, а C - константа больше единицы;
- для объединения критериев с операциями группировки T(A(BC)) меньше или равно T(A) + T(BC), где T(BC) определяется аналогично варианту комбинирования двух критериев.
Приложение N 1
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ
К СОСТАВУ НАКАПЛИВАЕМОЙ ТС ОРМ ИНФОРМАЦИИ, ПОЛУЧАЕМОЙ
С ИС ОПС
1.1. ТС ОРМ должны позволять накапливать следующую информацию о пользователях услугами почтовой связи:
- для абонента - юридического лица:
- полное наименование юридического лица;
- ИНН;
- ОГРН;
- ОКПО;
- почтовый индекс;
- для юридических лиц, с которыми заключен договор на оказание услуг связи:
- идентификатор филиала оператора связи;
- дата и время заключения договора;
- номер договора;
- дата и время расторжения договора;
- банк абонента для расчетов с ОПС;
- номер счета абонента в банке, используемого для расчетов с ОПС;
- корреспондентский счет;
- КПП;
- БИК;
- информация о контактных лицах, включающая:
- фамилию, имя, отчество (при наличии) контактного лица;
- контактные телефоны;
- список контактных электронных адресов;
- адреса и их почтовые индексы, указанные в заключенном договоре.
Информация накапливается для юридических лиц, заключивших договоры на предоставление услуг почтовой связи.
1.2. ТС ОРМ должны позволять накапливать следующую информацию об отправителе, получателе почтового отправления:
- для абонента - физического лица:
- фамилия, имя, отчество (при наличии);
- дата рождения;
- паспортные данные, в т.ч.:
- вид документа, удостоверяющего личность;
- серия, номер удостоверения личности;
- когда и кем выдано;
- контактные телефоны;
- номер договора;
- контактный адрес абонента;
- для абонента - юридического лица:
- полное наименование юридического лица;
- фамилия, имя отчество (при наличии) отправителя (контактного лица);
- контактные телефоны;
- почтовый индекс;
- номер договора;
- контактный адрес абонента.
1.3. ТС ОРМ должны позволять накапливать следующую информацию об оказанных услугах почтовой связи:
- идентификатор филиала оператора связи;
- идентификатор почтового отправления;
- дата регистрации почтового отправления оператором связи;
- идентификатор региона отправителя;
- идентификатор региона получателя;
- атрибут операции по обработке почтового отправления;
- описание операции по обработке почтового отправления;
- информация об отправителе (юридическое или физическое лицо);
- информация о получателе (юридическое или физическое лицо);
- информация об узле назначения (получателя):
- индекс отделения почтовой связи;
- наименование отделения почтовой связи;
- тип операции по обработке отправления на узле почтовой связи;
- информация об узле обработки почтового отправления:
- индекс отделения почтовой связи;
- наименование отделения почтовой связи;
- адрес доставки отправления;
- дата и время отправления (отправителем, на узле почтовой связи);
- дата и время получения (на узле почтовом связи, получателем);
- информация о почтовом отправлении, в т.ч.
- письмо;
- посылка;
- денежный перевод;
- бандероль;
- секограмма;
- почтовая карточка;
- экспресс-отправление;
- пакет;
- мешок, международное отправление;
- характеристики отправления, в т.ч.:
- вес почтового отправления в граммах;
- объявленная ценность почтового отправления;
- общее количество составных частей отправления;
- идентификатор составной части отправления;
- информация об оплачивающей отправление третьей стороне (юридическое или физическое лицо).
1.4. ТС ОРМ должны позволять накапливать следующую справочную информацию:
- информация об операторах связи (филиалах оператора связи), обслуживаемых ТС ОРМ, в т.ч.:
- идентификатор оператора (филиала);
- время начала действия;
- время окончания действия;
- описание (наименование) оператора (филиала);
- информация об отделениях почтовой связи оператора (операторов), в т.ч.:
- идентификатор оператора (филиала);
- индекс отделения почтовой связи;
- тип отделения почтовой связи;
- время начала действия;
- время конца действия;
- полное наименование отделения почтовой связи;
- адрес отделения почтовой связи;
- контактные телефоны;
- информация о пункте коллективного доступа, расположенного в отделении почтовой связи;
- информация о типах документов, удостоверяющих личность, в т.ч.:
- идентификатор оператора (филиала);
- идентификатор типа документа;
- время начала действия;
- время конца действия;
- описание (наименование) типа документа.
Приложение N 2
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ,
ПРЕДЪЯВЛЯЕМЫЕ К ИНТЕРФЕЙСУ ВЗАИМОДЕЙСТВИЯ МЕЖДУ ПУ И ТС ОРМ
1.1. ТС ОРМ должны подключаться к ПУ в точках подключения. Интерфейс в точке подключения должен соответствовать спецификации Ethernet 10/100/1000 Base-T либо 100 Base-FX, 1000 Base-LH по согласованию с уполномоченными органами.
1.2. В качестве протокола передачи данных должен использоваться протокол ТСР/IP.
1.2.1. Сетевой интерфейс первого уровня с протоколом ТСР/IP используется для первичного подключения аппаратуры передачи данных - модемов, маршрутизаторов и т.п.
1.2.2. Для каждой ТС ОРМ внутри сетевого интерфейса первого уровня рекомендуется создавать свою виртуальную сеть VPN (Virtual Private Network) для туннелирования всего рабочего ТСР/IP трафика между ТС ОРМ и пунктом управления, которая должна соответствовать спецификации L2TP, IPSec VPN.
1.3. Пропускная способность каналов передачи данных между ТС ОРМ и ПУ в точках подключения соответствует данным, приведенным в Таблице 1 Приложения N 2:
Таблица 1
Количество почтовых отправлений ОПС (миллион/сутки), не более
0,
1
1
10
100
Скорость передачи данных (кбит/сек.), не менее
1
024
20
48
10
000
10000
1.4. Взаимодействие ТС ОРМ с оборудованием ПУ на транспортном уровне осуществляется по схеме "клиент - сервер":
- в качестве "сервера" должна выступать ТС ОРМ;
- в качестве "клиента" выступает оборудование ПУ.
1.4.1. Для взаимодействия ТС ОРМ и ПУ организованы четыре канала передачи данных:
- кпд 1 - канал управления;
- кпд 2 - канал данных;
- кпд 3 - канал мониторинга;
- кпд 4 - канал неформатированных данных.
1.4.2. Канал управления (кпд 1) служит для передачи:
- от ПУ в ТС ОРМ запросов (команд);
- от ТС ОРМ на ПУ ответов и "сигналов".
1.4.3. Канал данных (кпд 2) служит для передачи:
- от ТС ОРМ на ПУ блоков данных отчетов генерируемых ТС ОРМ в качестве ответов на запросы из ПУ, "сигнала" Heartbeat;
- от ПУ в ТС ОРМ подтверждений о принятии блоков данных отчетов.
1.4.4. Канал мониторинга (кпд 3) служит для передачи:
- от ПУ в ТС ОРМ запросов о текущей конфигурации оборудования, системного и прикладного ПО ТС ОРМ и запросов на модификацию конфигурации;
- от ТС ОРМ на ПУ ответов на запросы ПУ, "сигналов".
1.4.5. Канал неформатированных данных (кпд 4) служит для передачи:
- от ПУ в ТС ОРМ команд на виды передаваемых неформатированных данных;
- от ТС ОРМ на ПУ неформатированных данных, "сигналов".
1.4.6. кпд 1, кпд 2, кпд 3, кпд 4 представляют собой ТСР-соединения, создаваемые для подключения на заранее определенные порты оборудования ТС ОРМ. ТС ОРМ выполняет прослушивание данных портов для создания ТСР-соединений с ПУ.
1.5. ПУ выполняет попытки установления подключения с ТС ОРМ в соответствии с задаваемым интервалом по предоставленным ТС ОРМ ТСР-портам.
1.5.1. Установление ПУ соединений с ТС ОРМ по каналам кпд 1, кпд 2 осуществляется в следующей последовательности:
- ПУ устанавливает ТСР-соединение с ТС ОРМ по порту канала кпд 1;
- выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения;
- ПУ устанавливает ТСР-соединение с ТС ОРМ по порту канала кпд 2;
- выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения
- после успешной аутентификации ПУ выполняет создание сессии с ТС ОРМ;
- ПУ должен ожидать данных и сигналов по кпд 2 только после того, как была создана сессия по каналу кпд 1. При приеме данных и сигналов по кпд 2 при отсутствии установленной сессии по кпд 1 ПУ должен разрывать соединение по кпд 2.
1.5.2. Установление ПУ соединений с ТС ОРМ по каналам кпд 3 и кпд 4 осуществляется независимо друг от друга и от наличия установленных соединений по каналам кпд 1 и кпд 2:
- ПУ устанавливает ТСР-соединение с ТС ОРМ по ТСР-порту канала кпд 3/кпд 4;
- выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения;
- после успешной аутентификации ПУ выполняет создание сессии с ТС ОРМ.
1.6. После успешной аутентификации ПУ посылает на ТС ОРМ команды в соответствии с Приложением N 7.
1.7. ПУ разрывает соединения с ТС ОРМ, если в течении трех периодов приема "сигнала" Heartbeat в каналах не было сетевой активности. При отсутствии подтверждения посланного "сигнала" Heartbeat в течение времени "максимальный размер задержки подтверждения запроса или сигнала" ТС ОРМ разрывает соединения с ПУ по соответствующему каналу.
1.8. ТС ОРМ должны обеспечивать одновременное подключение нескольких ПУ. Максимальное количество одновременно подключенных ПУ для одной ТС ОРМ - 100. ТС ОРМ обслуживает подключенные ПУ независимо друг от друга.
1.9. В ТС ОРМ на одновременном выполнении могут находиться не менее 50 одновременно запущенных задач, осуществляющих подготовку данных.
1.10. Каждому идентифицированному на ТС ОРМ ПУ назначается приоритет выполнения задач. В случае поступления на ТС ОРМ задач от различных ПУ вероятность постановки на выполнение задачи конкретного ПУ зависит от назначенного приоритета данного ПУ и приоритетов других ПУ. Распределение вероятности запуска задач от различных ПУ задается приоритетом каждого конкретного ПУ. Конфигурация по умолчанию должна обеспечивать равномерное распределение вероятности запуска задач от каждого ПУ. ТС ОРМ должны обеспечивать возможность конфигурирования приоритетов ПУ. ТС ОРМ должны обеспечивать одновременное выполнение задач по каждому идентифицированному ПУ:
- по информации об оказанных услугах почтовой связи - не менее 3;
- по пополнению справочников - не менее 1;
- по принадлежности абонентов - не менее 4.
1.11. Единицей обмена в кпд 1, кпд 2, кпд 3 и кпд 4 является "Сообщение" (Message). Форматы "Сообщений" описаны в Приложении N 7 на языке абстрактного описания синтаксиса (ASN.1) согласно ГОСТ Р ИСО/МЭК 8824-1-2001. Способ кодирования сериализованных "Сообщений" соответствует отличительным (DER) по ГОСТ Р ИСО/МЭК 8825-1-2003.
1.12. Интерфейс взаимодействия между ПУ и ТС ОРМ предусматривает наличие следующих видов "Сообщений":
- "запросы" - передаются от ПУ в ТС ОРМ по кпд 1;
- "ответы" - передаются из ТС ОРМ на ПУ по кпд 1;
- "сигналы" - передаются из ТС ОРМ на ПУ по кпд 1 и кпд 2 (для кпд 2 только "сигнал" Heartbeat);
- "отчеты" - формируются ТС ОРМ в качестве ответов на запросы из ПУ, передаются на ПУ по кпд 2;
- "подтверждения" о принятии "отчетов" - передаются из ПУ в ТС ОРМ по кпд 2;
- "подтверждения" о принятии "сигналов" - передаются из ПУ в ТС ОРМ по кпд 1 и кпд 2 (для кдп 2 только для "сигнала" Heartbeat).
1.13. Интерфейс взаимодействия между ПУ и ТС ОРМ по каналу кпд 3 предусматривает наличие следующих видов "Сообщений":
- "запросы";
- "ответы";
- "сигнал" Heartbeat;
- подтверждения о принятии "сигнала" Heartbeat и ответов.
1.14. Интерфейс взаимодействия между ПУ и ТС ОРМ по каналу кпд 4 предусматривает наличие следующих видов "Сообщений":
- "запросы" - передаются от ПУ в ТС ОРМ;
- "ответы" - передаются из ТС ОРМ на ПУ;
- "сигналы" - передаются из ТС ОРМ на ПУ;
- "отчеты" - формируются ТС ОРМ в качестве ответов на запросы из ПУ;
- "подтверждения" о принятии "отчетов" - передаются из ПУ в ТС ОРМ;
- "подтверждения" о принятии "сигналов" - передаются из ПУ в ТС ОРМ.
1.15. ТС ОРМ выполняет любые действия, связанные с выдачей информации о пользователях услуг связи и предоставленных им услугах связи, управлением и мониторингом КТС и ПО ТС ОРМ только по "запросам" ПУ.
1.15.1. ТС ОРМ обеспечивает прием и обработку следующих "запросов", передаваемых с ПУ по кпд 1:
- "Запрос на открытие сессии" (ConnectRequest);
- "Запрос на закрытие сессии" (DisconnectRequest);
- "Запрос готовности данных" (DataReadyRequest);
- "Запрос загрузки данных" (DataLoadRequest);
- "Запрос удаления данных" (DataDropRequest);
- "Запрос прерывания загрузки данных" (DataInterruptRequest);
- "Запрос на создание задачи по обработке информации" (CreateTaskRequest);
- "Запрос на постановку/снятие объекта наблюдения на контроль" (UNIControlTaskRequest);
- "Запрос на создание задачи по обработке неформализованных данных" (NonFormalizedTaskRequest).
1.15.2. ТС ОРМ должны обеспечивать одновременную передачу блоков данных отчетов для нескольких завершенных поисковых задач по каналу кпд 2. ТС ОРМ должны обеспечивать возможность многократной передачи отчетов выполненных задач на ПУ.
1.15.3. По запросу ПУ "Запрос загрузки данных" канала кпд 1 ТС ОРМ должны обеспечивать передачу блоков отчетов по каналу кпд 2 по запрошенной задаче без внесения дополнительных временных задержек между операциями по получению записей результата задачи и преобразования их в блоки.
1.15.4. На каждый "запрос" по кпд 1 ТС ОРМ на ПУ посылается "ответ" о принятии к обработке этого запроса. ТС ОРМ обеспечивают посылку по кпд 1 на ПУ следующих "ответов":
- "Ответ на запрос открытия сессии" (ConnectResponse);
- "Ответ на запрос закрытия сессии" (DisconnectResponse);
- "Ответ на запрос готовности данных" (DataReadyResponse);
- "Ответ на запрос загрузки данных" (DataLoadResponse);
- "Ответ на запрос удаления данных" (DataDropResponse);
- "Ответ на запрос прерывания загрузки данных" (DataInterruptResponse);
- "Ответ на запрос создания задачи" (TaskResponse);
- "Ответ на запрос на постановку/снятие объекта наблюдения на контроль" (UNIControlTaskResponse);
- "Ответ на запрос создания задачи по обработке неформализованных данных" (NonFormalizedTaskResponse).
1.15.5. По "Запросу на создание задачи по обработке информации" ТС ОРМ обеспечивают подготовку и выдачу информации из БД ТС ОРМ для следующих групп задач:
- "Задачи пополнения справочников (нормативно-справочная информация)" (DictionaryTask);
- "Задачи поисков по принадлежности абонентов" (AbonentsTask);
- "Задачи поисков по соединениям абонентов" (ConnectionsTask);
- "Задачи предоставления сведений о наличии данных" (PresenseTask).
В группу "Задачи пополнения справочников (нормативно-справочная информация)" входят запросы на получение информации справочников:
- операторы почтовой связи и их филиалы, связи, обслуживаемые ТС ОРМ;
- справочник типов документов, удостоверяющих личность;
- справочник узлов почтовой связи.
В группу "Задачи поисков по принадлежности абонентов" входят:
- "Задача на поиск информации об идентификаторах абонентов сети оператора связи, зарегистрированных на физическое или юридическое лицо" (AbonentsTask).
Поиск информации выполняется в накапливаемой ТС ОРМ информации о юридических лицах, заключивших договоры на предоставление услуг почтовой связи.
В группу "Задачи поисков по соединениям абонентов" входят:
- "Задача на поиск соединений абонентов" (ConnectionsTask).
В случае, если в качестве параметров "задачи на поиск соединений абонентов" указаны только диапазон времени и (опционально) филиал оператора связи, ТС ОРМ должны сформировать результат выполнения поисковой задачи, содержащий все соединения всех абонентов за указанный диапазон времени.
В группу "Задачи предоставления сведений о наличии данных" (PresenseTask) входят:
- запрос наличия информации по пользователям услугами почтовой связи;
- запрос наличия информации об оказанных услугах почтовой связи;
- запрос наличия справочников.
1.15.6. По "Запросу на создание задачи по обработке неформализованных данных" ТС ОРМ обеспечивают подготовку и выдачу информации из БД ТС ОРМ по следующим видам запросов:
- "запрос получения списка типов сущностей" неформализованных данных ТС ОРМ (GetEntities);
- "запрос получения списка атрибутов сущности" (GetEntityAttributes);
- "задача поиска неформализованных данных" (ValidateN onFormalizedTask);
- "задача предоставления сведений о наличии неформализованных данных" (NonFormalizedPresenseTask).
1.15.7. По "Запросу на постановку/снятие объекта наблюдения на контроль";
- "запрос на создание объекта наблюдения и постановки его на контроль" (CreateUNIRequest);
- "запрос на снятие объекта наблюдения с контроля и удаление объекта наблюдения" (DropUNIRequest).
1.15.8. ТС ОРМ по "задаче поиска неформализованных данных" могут предоставлять доступ ПУ к системным журналам ТС ОРМ.
1.15.9. ТС ОРМ должны обеспечивать выполнение поисковых задач по строковым критериям, содержащими символы маскирования, включающие:
- "*" - обозначает любую комбинацию символов;
- "?" - обозначает любой один возможный символ.
ТС ОРМ должны обеспечивать выполнение поисковых задач по критериям, содержащим последовательность цифр с символом маскирования пробел (" "), означающим любую одну цифру.
Результат выполнения поисковой задачи с критерием, содержащим символы маскирования, должен содержать все записи, соответствующие заданной маске.
1.15.10. В случае возникновения в ТС ОРМ исключительных ситуаций на ПУ передаются следующие "Сообщения" типа "Сигналы", содержащие информацию об уровне важности исключительной ситуации, ее влиянии на сохранность данных и выполнение задач:
- "Нет данных (связи) с ИС ОПС" - посылается в случае отсутствия от ИС ОПС информации в течение трех часов либо при отсутствии связи с ИС ОПС;
- "Перезапуск ПО" (RestartDB);
- "Попытка несанкционированного доступа" (UnauthorizedAccess);
- "Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна" (CriticalError);
- "Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна" (MajorError);
- "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" (MinorError);
- "Тестовый пакет" (Heartbeat). Единственный, из "сигналов", передающийся по кпд 1, кпд 2, кпд 3, кпд 4 в отсутствие иной сетевой активности.
В ответ на "сигналы", поступившие от ТС ОРМ, ПУ должно передавать "подтверждения сигнала" об их приеме.
1.15.11. ТС ОРМ по "Запросу удаления данных" (DataDropRequest) должны:
- прерывать задачу, находящуюся на выполнении;
- удалять данные отчета по завершившейся задаче.
1.16. Требования к функционированию канала кпд 1 приведены в Приложении N 3.
1.17. Требования к функционированию канала кпд 2 приведены в Приложении N 4.
1.18. Требования к функционированию канала кпд 3 приведены в Приложении N 5.
1.19. Требования к функционированию канала кпд 4 приведены в Приложении N 6.
1.20. При установлении соединения ПУ и ТС ОРМ должны быть взаимно аутентифицированы. Аутентификация выполняется установлением SSL/TLS-соединения поверх установленного ТСР-соединения между ПУ и ТС ОРМ. Для взаимной аутентификации ПУ и ТС ОРМ предварительно создаются Х.509-сертификаты, которые сообщаются ПУ и ТС ОРМ. В случае невозможности аутентифицировать одну из сторон ТСР-соединение разрывается. Созданный для ПУ сертификат используется для аутентификации только одного данного ПУ на одной ТС ОРМ по всем каналам передачи данных - кпд 1, кпд 2, кпд 3, кпд 4. ПУ и ТС ОРМ должны использовать TLS версии 1.0. Требования к сертификатам (длины ключей, прочие параметры) должны согласовываться для каждой пары ТС ОРМ и ПУ отдельно.
1.21. Открытие сессии осуществляется выполнением процедуры аутентификации согласно п. 1.20 настоящего Приложения перед началом выполнения всех запросов. Открытие сессии осуществляется посылкой по каналу управления от ПУ к ТС ОРМ "Запроса на открытие сессии" (ConnectRequest).
1.22. "Запрос на открытие сессии" устанавливает следующие параметры сессии:
- "максимальное время отсутствия активности сессии" (session-timeout) - интервал времени, по истечении которого сессия принудительно прерывается от ТС ОРМ;
- "максимальный размер блока данных отчетов" (max-data-length) в строках записей БД;
- "размер окна для канала передачи данных" (data-packet-window-size);
- "максимальная длительность задержки начала передачи блоков отчетов" (data-load-timeout);
- "максимальный размер задержки подтверждения о получении данных" (data-packet-response-timeout);
- "максимальный размер задержки подтверждения запроса или сигнала" (request-response-timeout).
Любое сообщение в соответствии с ASN.1-протоколом взаимодействия ТС ОРМ и ПУ (Приложение N 8) считается сетевой активностью.
1.22.1. ТС ОРМ при получении сообщения "Запрос на открытие сессии" анализируют параметр "размер окна для канала передачи данных", определяет максимально возможный размер окна, не превышающий полученного от ПУ. ТС ОРМ определяют минимальные значения таймаутов из параметров сессии, выбирая их не меньше, чем переданные в сообщении "Запрос на открытие сессии" (ConnectRequest). Рассчитанные значения размеров окна и таймаутов ТС ОРМ передает на ПУ в сообщении "Ответ на открытие сессии" (ConnectResponse). Полученные ПУ значения в сообщении "Ответ на открытие сессии" являются параметрами сессии между ПУ и ТС ОРМ.
1.23. Закрытие сессии осуществляется посылкой по каналу управления или каналу мониторинга от ПУ к ТС ОРМ "Запроса на закрытие сессии" или по истечению допустимого времени отсутствия активности ТС ОРМ, с посылкой сообщения-сигнала "Прерывание текущей сессии по таймауту". При этом ТС ОРМ и ПУ осуществляют разрыв текущих ТСР соединений канала управления и канала данных или канала мониторинга или канала неформатированных данных
1.24. ПУ посылает ТС ОРМ "запросы" асинхронно, независимо от получения от ТС ОРМ "ответа" о приеме предыдущего "запроса".
1.25. "Запрос на создание задачи по обработке информации" приводит к созданию в ТС ОРМ задачи по обработке данных в БД ТС ОРМ, которой присваивается номер (идентификатор) задачи, передаваемый в "Ответе на запрос создания задачи" (TaskResponse). Идентификаторы задач генерируются ТС ОРМ независимо от сессий и являются уникальными в данной ТС ОРМ. ТС ОРМ присваивают идентификаторы задачам и выполняет обработку задач независимо для различных ПУ.
1.26. ПУ получает информацию о ходе выполнения и завершения обработки задач в ИС, посылая запрос "Запрос готовности данных". После завершения выполнения задачи, данные, сформированные в результате выполнения задачи, становятся доступными для загрузки в ПУ или для удаления.
1.27. ТС ОРМ при получении "Запрос загрузки данных" по кпд 1 формируют сообщения типа "отчет", состоящие из блоков данных обработанной задачи и передает их на ПУ по кпд 2.
1.28. Количество строк в каждом блоке не превышает параметр "максимальный размер блока данных отчетов", заданный при открытии сессии.
1.29. В каждом последовательном блоке данных из серии указываются идентификатор задачи, сгенерировавшей данный отчет, общее количество блоков в отчете, порядковый номер каждого блока.
1.30. Данные задачи, полученные в одной сессии, могут быть считаны и/или удалены в другой сессии ПУ, инициировавшим данную задачу. Данные по завершенной задаче доступны между сессиями по тому же идентификатору задачи. При получении задачи "запрос загрузки данных" (DataLoadRequest) от ПУ, не являющегося инициатором данной задачи, ТС ОРМ посылают ответ на "запрос загрузки данных", в котором указывается отсутствие результата исполнения задачи (data-exists), а в поле "краткое описание ошибки" (error-description) записывается расшифровка отказа в доступе к данным задачи. Далее ТС ОРМ посылают на этот ПУ "сигнал" попытки несанкционированного доступа (unauthorized-access) и ожидают его подтверждения.
1.31. ТС ОРМ производят уничтожение данных, сформированных в результате выполнения задачи и самой выполненной задачи после поступления с ПУ запроса на удаление данных.
1.32. В случае возникновения в ТС ОРМ или каналах передачи данных исключительных ситуаций на ПУ передаются "Сообщения" типа "Сигнал".
Приложение N 3
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ФУНКЦИОНИРОВАНИЮ КАНАЛА КПД 1
1.1. Диаграмма состояний переходов ТС ОРМ по кпд 1 приведена на
1.1. Рисунок 1.
Рисунок 1. Диаграмма состояний перехода ТС ОРМ по кпд 1
(не приводится)
ТС ОРМ по ТСР-порту кпд 1 ожидают входящих соединений. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.2. Если SSL/TLS-соединения по каналам управления и данных установлены, а сессия не открыта, ТС ОРМ должны реагировать только на сообщение "Запрос на открытие сессии". При попытке посылок каких-либо других сообщений со стороны ПУ ТС ОРМ должны разорвать ТСР соединения по каналу управления и каналу данных и перевести канальный уровень подключения в исходное состояние.
1.3. При получении сообщения "Запрос на открытие сессии" ТС ОРМ создают список поддерживаемых ТС ОРМ типов запросов, отчетов и сигналов (в том числе и предыдущих версий) и отсылают его.
1.4. После отсылки списка поддерживаемых типов ТС ОРМ ожидают от ПУ списка поддерживаемых им запросов, отчетов и сигналов. Список поддерживаемых ПУ типов должен являться подмножеством списка типов в ТС ОРМ.
1.5. При получении от ПУ списка поддерживаемых ПУ запросов ТС ОРМ посылают сообщение "Ответ на согласование списка поддерживаемых типов" и создает сессию.
1.6. После создания сессии кпд 1 ТС ОРМ переводятся в режим ожидания команд от ПУ. При поступлении команды со стороны ПУ производится ее выполнение и формируется результат. Результат в виде сообщения "ответа" отправляется на ПУ.
1.7. В случае серьезного сбоя в ТС ОРМ, вызванного причинами, не предусмотренными режимом нормального функционирования системы, по каналу управления передается "сигнал" - "Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна", с соответствующим описанием проблемы. Все задачи, которые были в процессе выполнения, когда произошел сбой, а также данные выполненных задач, поврежденные в результате произошедшего сбоя, имеют "признак результата выполнения задачи" (TaskResult) равный значению "ошибка" (error) с соответствующим описанием проблемы. В случае, если для восстановления работоспособности ТС ОРМ требуется их перезагрузка, то по каналу управления выдается прерывание "Перезапуск ПО". В этом случае ТС ОРМ и ПУ закрывают все открытые на текущий момент сессии.
1.8. В случае наличия признаков сбоя или ошибки выполнения конкретной задачи ТС ОРМ в режиме нормального функционирования по каналу управления передается прерывание "Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна", с соответствующим описанием проблемы. Результат выполнения данной задачи имеет "признак результата выполнения задачи" (TaskResult), равный значению "ошибка" (error), с соответствующим описанием проблемы.
1.9. На каждый "сигнал", переданный ТС ОРМ, ПУ должно ответить сообщением "подтверждение сигнала" по кпд 1. Отсутствие подтверждения в течение времени RequestResponseTimeout, которое задается при открытии сессии, свидетельствует о прерывании соединения и должно вызывать действия, описанные в п. 1.23 настоящего Приложения.
1.10. При отсутствии команд ПУ в течение "максимального времени неактивности" (session-timeout, задается в ConnectRequest), ТС ОРМ посылают на ПУ "сигнал" Heartbeat и ожидает его подтверждения аналогично описанному в п. 1.8 настоящего Приложения.
1.11. Диаграмма состояний переходов ПУ по кпд 1 приведена на 1 настоящего Приложения.
Рисунок 1. Диаграмма состояний перехода ПУ по кпд 1
(не приводится)
1.12. ПУ с задаваемым интервалом выполняет попытки установления ТСР-соединения с ТС ОРМ по заданному порту кпд 1. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.13. ПУ ожидает установления соединения по кпд 2.
1.14. После установления ТСР-соединения по кпд 2 и прохождения по нему взаимной аутентификации ТС ОРМ и ПУ, ПУ по кпд 1 посылает команду создания сессии (ConnectRequest).
1.15. ПУ ожидает сообщения "ответ" от ТС ОРМ на отправленную команду в течение времени "таймаут ответа на запрос" (request-response-timeout).
1.16. Если сообщение не получено в течение времени "таймаут ответа на запрос", ПУ разрывает соединения с ТС ОРМ по кпд 1 и кпд 2 и переводит их в изначальное состояние (п. 1.12). Время ожидания сообщения "ответ" не зависит от приема сообщений "сигналов", поступающих в этот интервал времени.
1.17. При получении сообщения "Ответ на запрос создания сессии" ПУ создает список поддерживаемых ПУ типов запросов, отчетов и сигналов и отправляет его ТС ОРМ. Список поддерживаемых ПУ типов должен быть подмножеством списка типов ТС ОРМ, полученных в п. 1.15 настоящего Приложения.
1.18. После отправки сообщения "Согласование поддерживаемых типов со стороны ПУ" ПУ ждет ответа на сообщение от ТС ОРМ. Поведение ПУ при ожидании ответа аналогично описанному в п. 1.16 настоящего Приложения.
1.19. Если во время ожидания сообщения "ответ" ТС ОРМ посылают на ПУ сообщение "сигнал" (в т.ч. Heartbeat), то ПУ посылает "подтверждение" о принятии "сигнала" (в т.ч. Heartbeat) и продолжает ожидать сообщение "ответ" на отосланную команду.
1.20. После создания сессии ПУ посылает поступающие команды на ТС ОРМ и ожидает сообщений "ответов" на них в соответствии с п. 1.15, 1.16, 1.19 настоящего Приложения.
1.21. Если при ожидании поступления в ПУ команд ТС ОРМ не посылала "сигнал" Heartbeat в течение трех интервалов "максимального времени неактивности" (session-timeout, задается в ConnectRequest) ПУ разрывает соединения с ТС ОРМ по кпд 1 и кпд 2 и переводит их в изначальное состояние (п. 1.12 настоящего Приложения).
1.22. При поступлении команды "запрос на закрытие сессии" (DisconnectRequest) ПУ отсылает ее на ТС ОРМ, ожидает сообщения "ответ" в соответствии с п. 1.15, 1.16, 1.19 настоящего Приложения, после чего разрывает соединение по кпд 2 и кпд 1 и переводит их в изначальное состояние (п. 1.12 настоящего Приложения).
Приложение N 4
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ФУНКЦИОНИРОВАНИЮ КАНАЛА КПД 2
1.1. ТС ОРМ обеспечивают подключение ПУ и обработку поступающих запросов по каналу кпд 2 в соответствии с приведенными диаграммами состояний переходов.
Диаграмма состояний переходов ТС ОРМ по кпд 2 приведена на
1.2. Рисунок Приложения 4.
Рисунок 1. Диаграмма состояний перехода ТС ОРМ по кпд 2
(не приводится)
1.3. ТС ОРМ по ТСР-порту кпд 2 ожидают входящих соединений. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.4. Если на ТС ОРМ была передана "запрос загрузки данных" (DataLoadRequest), ТС ОРМ посылают "ответ на запрос загрузки данных" (DataLoadResponse) по каналу кпд 1 и начинает передачу данных блоков отчетов по кпд 2 при их наличии. ПУ может получить блоки отчетов по кпд 2 до получения "ответа на запрос загрузки данных" (DataLoadResponse) по кпд 1.
1.5. Если количество переданных без получения "подтверждения" о принятии серии блоков "отчетов" по всем задачам, по которым выполняется загрузка на ПУ данных, меньше "окна канала передачи данных" (параметр data-packet-window-size в запросе создания сессии ConnectRequest), то ТС ОРМ выполняют подготовку новых блоков отчетов по загружаемым задачам и посылают их на ПУ. Количество подготовленных и переданных без получения "подтверждения" блоков не должно превышать размера окна канала передачи данных.
1.6. Максимальная задержка подтверждения приема блока данных со стороны ПУ не превышает параметр "таймаут подтверждения приема блока данных отчета" (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не отправляются и по каналу управления передается "сигнал" "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" с соответствующим описанием проблемы, при этом в поле "reference-message" сообщения "сигнал" указывается идентификатор сообщения блока отчета, по которому не поступило подтверждение приема.
1.7. При получении "подтверждения" блока "отчета" ТС ОРМ должны записать информацию об ошибочно принятом ПУ блоке и ошибочных записях в блоке в специальный журнал, передача последующих блоков по задаче на ПУ не прерывается. ТС ОРМ должны предоставлять техническому персоналу оператора связи доступ к журналу с записями об ошибочно принятых на ПУ блоках отчетов и средства исправления ошибочных данных в отчетах. Подтвержденные блоки исключаются из окна канала передачи данных (в окне канала передачи данных остаются только неподтвержденные блоки).
1.8. В случае разрыва TCP/IP соединения кпд 2 при существующем соединении кпд 1 по кпд 1 передается прерывание "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" с соответствующим описанием проблемы, работа в данном случае не прекращается, выполняется установление соединения по кпд 2 в соответствии с п. 1.20 Приложения 2.
1.9. Передача блоков данных может быть прервана в случае получения ТС ОРМ "запроса прерывания загрузки данных".
1.10. Если по кпд 2 не производится передача блоков отчетов в течение "максимального времени неактивности" (session-timeout при создании сессии ConnectRequest), ТС ОРМ посылают на ПУ "сигнал" Heartbeat и ожидает его подтверждения аналогично описанному в п. 1.9 Приложения 3.
1.11. Диаграмма состояний переходов ПУ по кпд 2 приведена на Рисунок Приложения N 4.
Рисунок 2. Диаграмма состояний перехода ПУ по кпд 2
(не приводится)
1.12. ПУ с задаваемым интервалом выполняет попытки установления ТСР-соединения с ТС ОРМ по заданному порту кпд 2. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.13. При поступлении "запроса загрузки данных конкретной задачи" (DataLoadRequest) ПУ ожидает начала передачи данных в течение времени "таймаут начала передачи блоков отчетов" (data-load-timeout в ConnectRequest). Если данные не поступают в течение вышеописанного периода, то ПУ разрывает соединения по каналам кпд 1 и кпд 2 и переводит соединения в изначальное состояние (п. 1.12 Приложения 3, п. 1.12 настоящего Приложения).
1.14. При поступлении блока отчета ПУ производит декодирование полученного блока и сохранение декодированных данных.
1.15. В ответ на переданный блок данных ПУ посылает сообщение "подтверждение" получения блока отчета. Количество последовательно переданных ТС ОРМ блоков данных без подтверждения со стороны ПУ определяется параметром "размер окна канала передачи данных", который согласовывается при создании сессии. При подтверждении блока отчета ПУ может сигнализировать об ошибке декодирования блока. В этом случае в сообщении "подтверждение" приема для ошибочно декодированного блока ПУ, в случае возможности, указывает номер записи в блоке, начиная с которой декодирование не удалось.
1.16. Если при ожидании поступления в ПУ блоков отчетов ТС ОРМ не посылала "сигнал" Heartbeat в течение трех интервалов "максимального времени неактивности" (session-timeout, задается в ConnectRequest), ПУ разрывает соединения с ТС ОРМ по кпд 1 и кпд 2 и переводит их в изначальное состояние (п. 1.12 Приложения N 3, п. 1.12 настоящего Приложения).
Приложение N 5
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ФУНКЦИОНИРОВАНИЮ КАНАЛА КПД 3
1.1. ТС ОРМ обеспечивают подключение ПУ и обработку поступающих запросов по каналу кпд 3 (канал мониторинга).
1.2. ТС ОРМ обеспечивают прием и обработку следующих видов запросов от ПУ по каналу кпд3 (канал мониторинга):
- запрос на получение структуры ТС ОРМ - КТС и списка модулей прикладного ПО ТС ОРМ ("GetStructureRequest");
- запрос на получение конфигурации КТС/модуля ПО ТС ОРМ ("GetModuleConfigRequest");
- запрос на изменение конфигурации КТС/модуля ПО ТС ОРМ ("SetModuleConfigRequest");
- запрос на получение состояния модуля КТС/модуля ПО ТС ОРМ ("CheckModuleRequest").
1.3. На каждый запрос по кпд3 ТС ОРМ посылает ответ на ПУ, содержащий результат обработки соответствующего запроса - "ManagementResponse".
1.4. Диаграммы состояний перехода ТС ОРМ и ПУ по кпд 3 соответствуют диаграммам для кпд 1 (
1.5. Рисунок 1, Рисунок Приложения N 3).
1.6. ТС ОРМ по ТСР-порту кпд 3 ожидают входящих соединений. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.7. Если SSL/TLS-соединение по кпд 3 установлено, а сессия не открыта, ТС ОРМ должны реагировать только на сообщение "Запрос на открытие сессии". Создание сессии аналогично описанному в пп. 1.2 - 1.4 Приложения N 3. При попытке посылок каких-либо других сообщений со стороны ПУ ТС ОРМ должны разорвать ТСР соединение по кпд 3 и перевести канальный уровень подключения в исходное состояние.
1.8. После создания сессии ТС ОРМ переводятся в режим ожидания команд от ПУ. Обработка поступающих команд и посылка сигналов производится аналогично описанному в пп. 1.5 - 1.9 Приложения N 3.
1.9. ПУ с задаваемым интервалом выполняет попытки установления ТСР-соединения с ТС ОРМ по заданному порту. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.10. ПУ по кпд 3 посылает команду создания сессии (ConnectRequest).
1.11. Ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ТС ОРМ сигналов по кпд 3 производится ПУ аналогично описанному в пп. 1.15 - 1.21 Приложения N 3.
1.12. ТС ОРМ должны обеспечивать получение следующих видов информации о структуре и функционировании ТС ОРМ по запросу ПУ:
- о структуре и составе КТС ТС ОРМ, составе и состоянии интерфейсов взаимодействия КТС ТС ОРМ;
- об установленном на КТС ТС ОРМ общесистемном и специальном программном обеспечении ТС ОРМ, перечне и состоянии программных модулей в составе специального программного обеспечения ТС ОРМ;
- о точках подключения ТС ОРМ к сети оператора связи и интерфейсах ввода информации в ТС ОРМ.
1.13. В части структуры и состава КТС ТС ОРМ, состава и состоянии интерфейсов взаимодействия КТС ТС ОРМ, ТС ОРМ должны по запросу ПУ предоставлять следующую информацию:
- перечень коммутационного и серверного оборудования, средств хранения данных с его идентификацией;
- идентификацию интерфейсов подключения КТС ТС ОРМ друг к другу;
- предоставление следующих параметров для серверного оборудования (на момент формирования ПУ запроса):
- общий и занятый объем оперативной памяти;
- количество сетевых интерфейсов с их идентификацией, текущая нагрузка;
- общее количество процессоров, текущая загрузка;
- общий объем дискового пространства, объем свободного пространства;
- предоставление следующих параметров о технических средствах хранения данных:
- перечень модулей, составляющих средства хранения данных с их идентификацией;
- для каждого входящего в состав средств хранения данных модуля:
- общий объем дискового пространства;
- объем свободного дискового пространства;
- текущее состояние модуля (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя.
1.14. В части точек подключения ТС ОРМ к сети оператора связи, интерфейсов ввода информации в ТС ОРМ, ТС ОРМ должны по запросу ПУ предоставлять текущую информацию на момент формирования запроса, содержащую:
- перечень точек подключения к сети связи и точек ввода информации в ТС ОРМ с их идентификацией;
- для каждой точки подключения предоставлять информацию:
- вид поступающих в ТС ОРМ сведений (об абонентах, об оказанных услугах связи);
- состояние точки (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;
- сведения об объеме поступающей информации в секунду, в т.ч.: количество записей, объем (байт);
- период, в течение которого на точку подключения/ввода информации в ТС ОРМ не поступала информация.
1.15. В части состава общесистемного и специального программного обеспечения ТС ОРМ, их текущего состояния, ТС ОРМ по запросу ПУ следующую информацию:
- перечень установленного общесистемного программного обеспечения с его идентификацией;
- предоставление для общесистемного программного обеспечения информации:
- идентификатора КТС, на котором установлены ТС ОРМ;
- наименование общесистемного программного обеспечения;
- текущее состояние (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;
перечень установленного специального программного обеспечения ТС ОРМ с его идентификацией;
- предоставление для специального программного обеспечения ТС ОРМ информации:
- идентификатора КТС, на котором установлены ТС ОРМ;
- назначение (определяется разработчиком ТС ОРМ);
- текущее состояние (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;
- список контролируемых параметров (определяется разработчиком ТС ОРМ).
1.16. ТС ОРМ должны предоставлять возможность изменения отдельных параметров функционирования КТС ТС ОРМ общесистемного и специального программного обеспечения по запросу ПУ посредством кпд 3.
Приложение N 6
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ФУНКЦИОНИРОВАНИЮ КАНАЛА КПД 4
1.1. ТС ОРМ обеспечивают подключение ПУ и обработку поступающих запросов по каналу кпд 4 (канал неформатированных данных).
1.2. ТС ОРМ обеспечивает прием и обработку следующих видов запросов от ПУ по каналу кпд 4:
- "запрос проверки наличия вида неформатированных данных в ТС ОРМ" (DataTypesRequest);
- "запрос на начало передачи неформатированных данных" (DataStartRequest);
- "запрос на остановку передачи неформатированных данных" (DataStopRequest).
1.3. На каждый запрос по кпд 4 ТС ОРМ посылают ответ на ПУ, содержащий результат обработки соответствующего запроса.
1.4. ТС ОРМ должны накапливать информацию с неформатированными данными в специальном буфере. Данные в буфере упорядочиваются согласно времени их поступления. Длительность временного хранения информации в буфере - 10 суток.
1.5. ТС ОРМ должны записывать в буфер информацию об оказанных услугах связи, абонентах, с которыми заключены договоры на оказание услуг почтовой связи и справочные данные об операторах (филиалах оператора почтовой связи), отделениях почтовой связи и типах документов, удостоверяющих личность, в виде текстовых файлов.
1.6. ТС ОРМ должны записывать информацию в буфер циклически, т.е. при переполнении буфера старая информация в нем перезаписывается.
1.7. Диаграмма состояний переходов ТС ОРМ по кпд 4 приведена на Рисунок Приложения N 6.
Рисунок 1. Диаграмма состояний перехода ТС ОРМ по кпд 4
(не приводится)
1.8. ТС ОРМ ожидают и устанавливают соединение аналогично описанному в пп. 1.5, 1.6 Приложения N 5.
1.9. После создания сессии ТС ОРМ переводятся в режим ожидания команд. Обработка команд и посылка "сигналов" осуществляется аналогично описанному в пп. 1.5 - 1.9 Приложения N 3, за исключением команд "запрос на начало, остановку передачи неформатированных данных" (DataStartRequest/ DataStopRequest).
1.10. При приеме команды "запрос на начало передачи неформатированных данных" ТС ОРМ, находясь в режиме ожидания команд, отсылает "ответ на запрос начала передачи неформатированных данных" и переводит канал кпд 4 в режим передачи данных.
1.11. При приеме команды "запрос на остановку передачи неформатированных данных" ТС ОРМ, находясь в режиме ожидания команд, посылает "ответ на запрос остановки передачи неформатированных данных" с отрицательным результатом.
1.12. В режиме передачи данных посылка блоков отчетов и их подтверждение производится аналогично описанному в пп. 1.5, 1.7, 1.10 Приложения N 4.
1.13. Максимальная задержка подтверждения приема блока данных со стороны ПУ не превышает параметр "таймаут подтверждения приема блока данных отчета" (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не отправляются, ТС ОРМ разрывают соединение по кпд 4 и переводит кпд 4 в изначальное состояние. Передача неформатированных данных соответствующего типа производится из буфера кпд 4 (см. п. 1.5 настоящего Приложения).
1.14. При приеме команды "запрос на остановку передачи неформатированных данных" ТС ОРМ, находясь в режиме передачи данных, посылает "ответ на запрос остановки передачи неформатированных данных", завершает посылку блоков данных и переводится в режим ожидания команд.
1.15. При приеме команды "запрос на начало передачи неформатированных данных" ТС ОРМ, находясь в режиме передачи данных, посылает "ответ на запрос начала передачи неформатированных данных" с отрицательным результатом, при этом передача неформатированных данных не прекращается.
1.16. Исходные данные о соединениях в виде неформатированных данных записываются в буфер независимо от текущего режима работы канала кпд 4 ТС ОРМ.
1.17. Если команда "запрос на остановку передачи неформатированных данных" поступила в момент передачи из буфера файловых данных, то передаваемый файл должен сохраняться в буфере и быть доступным для передачи после посылки команды "запрос на начало передачи неформатированных данных" с учетом ограничений по длительности хранения, указанным в п. 1.5.
1.18. Диаграмма состояний переходов ПУ по кпд 4.
Рисунок 2. Диаграмма состояний перехода ПУ по кпд 4
(не приводится)
1.19. ПУ с задаваемым интервалом выполняет попытки установления ТСР-соединения с ТС ОРМ по заданному порту. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
1.20. ПУ по кпд 4 посылает команду создания сессии (ConnectRequest).
1.21. Ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ТС ОРМ сигналов по кпд 4 производится ПУ аналогично описанному в пп. 1.15 - 1.21 Приложения N 3, за исключением команд "запрос на начало, остановку передачи неформатированных данных" (DataStartRequest/DataStopRequest).
1.22. При посылке команды "запрос на начало/остановку передачи неформатированных данных", ПУ ожидает результата (DataStartResponse) аналогично описанному в пп. 1.15 - 1.16 Приложения 3, после чего переводит канал кпд 4 в режим передачи данных.
1.23. В режиме передачи данных ПУ производит прием, декодирование и подтверждение приема данных аналогично описанному в пп. 1.14 - 1.15 Приложения 4.
1.24. При приеме команды "запрос на остановку передачи неформатированных данных" (DataStopRequest) ПУ, находясь в режиме передачи данных, завершает прием блоков данных и переводится в режим передачи команд.
Приложение N 7
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ТРЕБОВАНИЯ К ФОРМАТАМ СООБЩЕНИЙ ТС ОРМ
1.1. Структура разделения ASN.1 модулей протокола взаимодействия ПУ и ТС ОРМ приведена на Рисунке 4 Приложения N 7.
1.2. Модуль Classification.asn задает правила, в соответствии с которыми:
- выполняется расширение:
- списка типов запросов к ТС ОРМ;
- списка видов поисковых критериев к ТС ОРМ;
- списка типов отчетов, формируемых ТС ОРМ;
- выполняется ввод новых версий сообщений протокола.
1.3. Структура разделения ASN.1 "Сообщений" протокола приведена на Рисунок.
sorm
message
session
trap
fask
report
management
unformatted
Рисунок 1. Структура видов сообщений протокола
взаимодействия ПУ и ТС ОРМ
1.4. В соответствии с Рисунок, Рисунок в протокольных ASN.1-модулях выполняется подстановка соответствующих версий форматов поисковых критериев, отчетов, справочников, "сообщений" интерфейса взаимодействия ПУ и ТС ОРМ.
1.5. ASN.1-модуль "Classification.asn" содержит кодированные в иерархическом виде идентификаторы:
- видов "Сообщений" верхнего уровня интерфейса взаимодействия ПУ и ТС ОРМ, составляющих кпд 1, кпд 2, кпд 3, кпд 4;
- видов поисковых критериев для формирования задач к ТС ОРМ;
- видов форматов отчетов, формируемых ТС ОРМ.
1.6. Соответствующие идентификаторы используются в других ASN.1-модулях интерфейса взаимодействия ПУ и ТС ОРМ (Рисунок настоящего Приложения с модулями), при этом идентификатор определяет конкретную версию и расширения формата соответствующего элемента (поисковых критериев, отчетов, справочников "сообщений" - в соответствии с Рисунок, Рисунком 3 настоящего Приложения).
1.7. Предоставленный ТС ОРМ при создании сессии перечень идентификаторов и согласованное из него ПУ подмножество в целом определяют конкретные возможности взаимодействия ПУ и ТС ОРМ в соответствии с выбранными идентификаторами.
1.8. Расширение интерфейса взаимодействия ПУ и ТС ОРМ обеспечивается введением новых идентификаторов, определяющих соответствующие расширенные элементы (поисковые критерии, отчеты, справочники, "сообщения"). Кодирование новых вводимых идентификаторов элементов осуществляется в соответствии со структурами на Рисунок, Рисунок настоящего Приложения и стандартным кодированием ASN.1-модуля "Classification.asn".
Рисунок 2. Структура разделения поисковых критериев кпд 1
Рисунок 3. Структура разделения видов отчетов кпд 2
Приложение N 8
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ASN.1-СПЕЦИФИКАЦИЯ ПРОТОКОЛА ВЗАИМОДЕЙСТВИЯ ПУ И ТС ОРМ
Приложение N 9
к Требованиям к оборудованию
и программному обеспечению операторов
почтовой связи для обеспечения доступа
к базам данных об оказанных услугах
почтовой связи и пользователях
услугами почтовой связи при проведении
оперативно-розыскных мероприятий,
утвержденным приказом Минкомсвязи России
от 23.07.2015 N 279
ПЕРЕЧЕНЬ ТЕРМИНОВ И СОКРАЩЕНИЙ
АПК - аппаратно-программный комплекс.
БД - база данных.
Время выполнения задачи в ТС ОРМ - временной интервал между началом исполнения поисковой задачи в БД ТС ОРМ и временем завершения формирования результата в БД ТС ОРМ.
ИС - информационная система.
Источник информации - аппаратно-программные средства оператора связи, обеспечивающие ввод в ТС ОРМ информации о пользователях услуг почтовой связи и оказанных им услугах почтовой связи.
КТС - комплекс технических средств.
НСД - несанкционированный доступ.
ОПС - оператор почтовой связи.
ПУ - пункт управления.
ПО - программное обеспечение.
СПО - специальное программное обеспечение.
ТС ОРМ - технические средства оперативно-розыскных мероприятий.