Последние несколько лет растёт интерес операторов к интеграции биллинга и комплексов СОРМ3. Пик пришелся на пандемию, поэтому мы решили написать статью.

Нам интересны три законодательных акта:

• Постановление Правительства РФ № 538 от 27 августа 2005 г.
• Приказ Минсвязи и ФСБ от 1 августа 2017 г. N 391/437
• Приказ Минкомсвязи РФ № 573 от 29 октября 2018 г.

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

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

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

Это независимые задачи, которые должны выполняться всегда вовремя — именно по этой причине оператору помимо автоматизированной системы расчётов нужен специализированный комплекс по осуществлению оперативно-розыскных мероприятий. В свою очередь АСР должна иметь плотную и стабильную интеграцию с ТСОРМ.

Данные, которые нужно передавать, перечислены в приказе 538, пункты 1 и 14, и в приказе 573, шестой пункт второй части.

Из перечисленного набора информации, биллинг передаёт ряд данных об абонентах:

• ФИО, наименование, адрес регистрации, ИНН для юрлиц и т.д.
• Услуги
• Платежи
• Для телефонии — данные по звонкам CDR (условный аналог для интернета, Netflow, отдаётся в рамках СОРМ2 напрямую с коммутационного оборудования, без участия АСР)
• Логины, номера телефонов, IP-адреса

И набор справочных данных об операторе связи:

• Информация об операторе и его филиалах
• Точки установки коммутационного оборудования для присоединения к соседним операторам
• Пулы IP-адресов и номеров телефонов
• Типы и причины завершения вызовов
• Используемые платёжные системы
• Номенклатура услуг
• Типы используемых документов для идентификации личности абонентов

Приказ 573 определяет протокол обмена данными — ASN.1, это механизм взаимодействия между ИС СОРМ и ПУ.

Но так как АСР участвует в ОРМ только опосредованно, разработчики комплексов СОРМ де-факто определили другой, более распространённый формат передачи данных: АСР с определённой периодичностью формирует выгрузку из своей базы в формате CSV и отправляет на FTP-сервер.

Со своей стороны ИС СОРМ так же по протоколу FTP данные забирает.

Самая распространённая задача при интеграции — дополнить адресный справочник. Любую адресную информацию (адрес регистрации, установки оборудования, физический адрес, почтовый и т.д.) поставщики СОРМ рекомендуют передавать в структурированном виде. Мы, в свою очередь, рекомендуем заводить все адреса с использованием подсказок — так Вы можете заполнять адресный справочник вводя минимум данных вручную, а биллинг заполнит все “метаданные” из ФИАС за Вас.

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

Для различных СОРМ могут быть свои особенности интеграции. Помимо самого формата CSV (разделитель, поля в кавычках или нет) могут быть и другие, уникальные для конкретного АПК детали. Например, МФИ Софт просит выгружать IP и MAC-адреса в шестнадцатеричном (HEX) формате, а Сигналтек, в случае если данные абонента изменились, просит выгружать как "старую версию" абонента, так и "новую".

Последняя, и на самом деле пока ещё не полностью решенная задача — данные о "внутренних пользователях" абонента юрлица. Пока разработчики ТСОРМ предлагают разные способы, как эти данные отражать и схемы очень отличаются. Мы можем выделить из них три, предлагаемые разными разработчиками комплексов ТСОРМ:

• Пользователь в сети юрлица заводится подобно абоненту биллинговой системы и выгружается с привязкой к абоненту юрлицу
• Данные обо всех внутренних пользователях юрлица заводятся в единое поле CSV при передаче данных по юрлицу
• Выгрузка "внутренних абонентов" юрлиц не представлена в СОРМ

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

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

Пока мы предлагаем забирать данные у юрлиц в формате PDF или DOCX-файла и прикладывать к карточке абонента в виде файла, обычно УФСБ согласовывают такой формат отражения данных по внутренним пользователям.

Carbon Billing интегрирован с пятью из шести поставщиков АПК СОРМ3, а последний находится в стадии интеграции.

Что делать если СОРМ пока нет, но уже есть Carbon Billing 5