Приложение № 3
к Требованиям к техническим и программным средствам информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им
услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации
от 29.10.2018 N 573

Требования, предъявляемые к функционированию канала управления (кпд1)

1. Посредством технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), обеспечивается подключение пульта управления (далее — ПУ) и обработка поступающих запросов по кпд1 в соответствии с приведенными схемами состояний переходов.

Состояние переходов ИС ОРМ по кпд1 приведено на схеме 1:
1) ИС ОРМ по TCP-порту кпд1 находится в ожидании входящих соединений; после установления соединения с ПУ должна выполняться взаимная SSL/TLS-аутентификация;
2) если SSL/TLS-соединения по каналам управления и данных установлены, а сессия не открыта, ИС ОРМ следует реагировать только на сообщение «Запрос на открытие сессии»; при попытке посылок каких-либо других сообщений со стороны ПУ ИС ОРМ должна разорвать ТСР-соединения по каналу управления и каналу данных и перевести канальный уровень подключения в исходное состояние;
3) при получении сообщения «Запрос на открытие сессии» ИС ОРМ должна создать список поддерживаемых ИС ОРМ типов запросов, отчетов и сигналов (в том числе и предыдущих версий) и отослать его на ПУ;
4) после отсылки списка поддерживаемых типов ИС ОРМ должна ожидать от ПУ списка поддерживаемых им запросов, отчетов и сигналов; список поддерживаемых ПУ типов является подмножеством списка типов в ИС ОРМ;
5) при получении от ПУ списка поддерживаемых ПУ запросов ИС ОРМ должна послать сообщение «Ответ на согласование списка поддерживаемых типов» и создать сессию;
6) после создания сессии кпд1 ИС ОРМ должна быть переведена в режим ожидания команд от ПУ; при поступлении команды со стороны ПУ ИС ОРМ должна ее выполнить и сформировать результат, который в виде сообщения «ответа» отправляется на ПУ;

7) в случае возникновения сбоя в работе ИС ОРМ, вызванного причинами, не предусмотренными режимом нормального функционирования системы, по каналу управления должен передаваться «сигнал" — «Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна» с соответствующим описанием проблемы; все задачи, которые были в процессе выполнения, когда произошел сбой, а также данные выполненных задач, поврежденные в результате произошедшего сбоя, имеют «признак результата выполнения задачи» (TaskResult), равный значению «ошибка» (error), с соответствующим описанием проблемы; в случае, если для восстановления работоспособности ИС ОРМ требуется ее перезагрузка, то по каналу управления следует выдать прерывание «Перезапуск ПО»; в этом случае ИС ОРМ и ПУ должны закрыть все открытые на текущий момент сессии;
8) в случае наличия признаков сбоя или ошибки выполнения конкретной задачи ИС ОРМ в режиме нормального функционирования по каналу управления в автоматическом режиме передает прерывание «Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна» с соответствующим описанием проблемы; результат выполнения данной задачи имеет «признак результата выполнения задачи» (TaskResult), равный значению «ошибка» (error), с соответствующим описанием проблемы;
9) на каждый «сигнал», переданный ИС ОРМ, ПУ в автоматическом режиме направляет сообщение «подтверждение сигнала» по кпд1; отсутствие подтверждения в течение времени RequestResponseTimeout, которое задается при открытии сессии, свидетельствует о прерывании соединения и вызывает действия, согласно пункту 18 приложения N 2 к Требованиям;
10) при отсутствии команд ПУ в течение «максимального времени неактивности» (session-timeout, задается в ConnectRequest) ИС ОРМ в автоматическом режиме направляет на ПУ «сигнал» Heartbeat и ожидает его подтверждения аналогично описанному в подпункте 9 пункта 1 настоящего приложения.

2. ПУ с задаваемым интервалом выполняет попытки установления TCP-соединения с ИС ОРМ по заданному порту кпд1 (состояние переходов ПУ по кпд1 приведено на схеме 2):
1) ПУ ожидает установления соединения по кпд1; после установления соединения выполняется взаимная SSL/TLS-аутентификация;
2) после установления TCP-соединения по кпд1 и прохождения по нему взаимной аутентификации ИС ОРМ и ПУ по кпд1 послают команду создания сессии (ConnectRequest);
3) ПУ ожидает сообщения «ответ» от ИС ОРМ на отправленную команду в течение времени «таймаут ответа на запрос» (request-response-timeout);
4) если сообщение не получено в течение времени «таймаут ответа на запрос», ПУ автоматически разрывает соединения к ИС ОРМ по кпд1 и кпд2 и переводит их в начальное состояние согласно подпункту 1 пункта 2 настоящего приложения. Время ожидания сообщения «ответ» не зависит от приема сообщений «сигналов», поступающих в этот интервал времени;
5) при получении сообщения «Ответ на запрос создания сессии» пунктом управления ОРМ автоматически создается список поддерживаемых ПУ типов запросов, отчетов и сигналов, который направляется в ИС ОРМ. Список поддерживаемых ПУ типов является подмножеством списка типов ИС ОРМ согласно подпункту 3 пункта 2 настоящего приложения;
6) после отправки сообщения «Согласование поддерживаемых типов со стороны ПУ» ПУ ожидает ответа на сообщение от ИС ОРМ. Поведение ПУ при ожидании ответа должно соответствовать подпункту 4 пункта 2 настоящего приложения;
7) во время ожидания сообщения «ответ» ИС ОРМ автоматически посылается на ПУ сообщение «сигнал» (в том числе HeartBeat), а ПУ «подтверждение» о принятии «сигнала» (в том числе HeartBeat) и ожидается сообщение «ответ» на отосланную команду;
8) после создания сессии ПУ посылает поступающие команды на ИС ОРМ и ожидает сообщения «ответов» на них согласно подпунктам 3, 4 и 7 пункта 2 настоящего приложения;

9) если при ожидании поступления в ПУ команд ИС ОРМ не посылала «сигнал» (HeartBeat) в течение трех интервалов «максимального времени неактивности» (session-timeout, задается в ConnectRequest), ПУ должен разорвать соединения к ИС ОРМ по кпд1 и кпд2 и перевести их в начальное состояние согласно подпункту 1 пункта 2 настоящего приложения;
10) при поступлении сообщения «Запрос на закрытие сессии» (DisconnectRequest) ПУ должен отослать его на ИС ОРМ, ожидать сообщения «ответ» согласно подпунктам 3, 4, 7 пункта 2 настоящего приложения, после чего разорвать соединение по кпд2 и кпд1 и перевести их в начальное состояние согласно подпункту 1 пункта 2 настоящего приложения.