10 зон контроля ИБ биллинга в — почему недостаточно защитить базу данных и сеть

Когда говорят об ИБ оператора связи, обычно вспоминают защиту сети, ЦОД и мониторинг. Но есть контур, о котором забывают чаще всего — биллинговая платформа. Внешне она кажется просто системой счетов, но на практике через неё управляют клиентами, договорами, услугами, тарифами, платежами, балансами и блокировками.

Биллинг — это не один модуль, а автоматизированная система расчётов (АСР) с несколькими компонентами, в том числе OCS, AAA, rating, каталогом продуктов, интеграциями с CRM, сетью, ГИС. У каждого — своя нагрузка, критичность и требования к отказоустойчивости, журналированию и защите данных. Где же реальные зоны контроля ИБ биллинга и что упускают при аудите? В этом для читателей Кибер Медиа разберется Максим Сысоев, исполнительный директор российского разработчика BSS/OSS-решений «Форвард Телеком».

Какие данные защищает биллинговая платформа

В АСР пересекаются несколько классов чувствительных данных. И каждый диктует свои требования к ИБ.

Персональные данные абонентов — закон №152-ФЗ регулирует отношения, связанные с обработкой персональных данных, и содержит требования к принципам обработки, конфиденциальности, обязанностям оператора и мерам по обеспечению безопасности персональных данных.

Сведения, связанные с оказанием услуг связи: номера, идентификаторы SIM/eSIM, IP-адреса, логины, параметры услуг, события потребления, детализация, статусы, блокировки, данные об оборудовании и технической возможности оказания услуги. Часть таких сведений может относиться к информации, охраняемой режимом тайны связи.

А также финансовые и расчётные данные: начисления, платежи, задолженность, корректировки, скидки, бонусы, пороги блокировок, история перерасчётов.

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

Технологическая связка как объект ИБ

АСР в промышленном контуре — это не только прикладное программное обеспечение. Это целая экосистема: инфраструктура, виртуализация, операционная система, СУБД, резервное копирование, мониторинг, защита информации, прикладные модули и интеграционные механизмы. Поэтому ИБ нельзя настраивать только на уровне приложения — нужно смотреть на всю связку целиком.

Когда оператор выбирает или обновляет биллинг, он проверяет не только функции АСР, но и совместимость всех компонентов между собой. Если приложение не готово работать на нужном стеке (ОС, СУБД, оборудование), проект упирается не в бизнес-логику, а в инфраструктурные ограничения.

Что ещё нельзя оставлять на уровне инфраструктуры? Средства защиты инфраструктуры — межсетевые экраны, средства защиты от вредоносного ПО, SIEM, DLP, сканеры уязвимостей, средства резервного копирования — необходимы. Но для АСР этого недостаточно. Безопасность должна быть встроена в саму платформу и процессы её эксплуатации. Перечислим четыре встроенных механизма, без которых не обойтись.

Ролевая модель — ни один пользователь не должен иметь возможность без ограничений менять тарифы, балансы, скидки и правила расчётов. Критичные операции — по ролям, при согласовании.

Журналирование — стоит фиксировать не только входы в систему, но и смысловые действия: кто, что, когда изменил, какие данные были до и после. Это позволит объяснить любое действие системы спустя месяцы.

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

Шифрование и защищённые каналы — оператору важно оценивать не только декларацию «данные защищены», а реализацию: шифруется ли передача между компонентами, API, ГИС, CRM, платёжными системами; защищены ли резервные копии; как управляются ключи и сертификаты. И главное — чтобы защита не нарушала производительность и отказоустойчивость.

Помимо этого, не стоит забывать: АСР и смежные BSS-компоненты регулярно обмениваются данными с внешними системами. Биллинг не всегда в центре кооперации. Часть функций могут выполнять CRM, антифрод или специализированные системы. Но АСР почти всегда участвует в подготовке данных, хранении статусов и обеспечении прослеживаемости. В таких сценариях важен не просто факт интеграции, а управляемость обмена. Иначе интеграция сама становится зоной ИБ-риска.

Безопасная разработка и поставка изменений

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

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

Отдельно должны проверяться практики прикладной безопасности: управление сессиями, защита API, контроль прав на уровне функций и объектов, защита от небезопасных прямых обращений к объектам, валидация входных данных, корректная обработка ошибок без раскрытия чувствительной информации, безопасная работа с секретами — ключами, токенами, паролями, сертификатами, — журналирование критичных действий и защита административных интерфейсов.

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

10 зон контроля ИБ биллинга: чек-лист для аудита

При выборе или аудите биллинговой платформы оператору стоит смотреть не только на функциональность тарификации и расчётов. Вопросы ИБ должны быть включены в оценку с самого начала. Ответы на следующие 10 пунктов покажут готовность платформы к реальной эксплуатации.

1. Из каких компонентов состоит АСР и какие из них критичны для технической возможности оказания услуги связи. Для OCS, AAA, модулей управления доступом, расчётных и отчётных компонентов требования к доступности, отказоустойчивости, журналированию и категорированию могут различаться.
2. Какие данные обрабатывает платформа и к каким правовым режимам они относятся: персональные данные, сведения, относящиеся к тайне связи, финансовые данные, технические идентификаторы, журналы действий.
3. Как устроена технологическая связка: инфраструктура, ОС, СУБД, виртуализация, средства защиты, мониторинг, резервное копирование и прикладное ПО. Нужно понимать, какие компоненты имеют требуемые подтверждения соответствия, а какие должны быть совместимы с ними на уровне производительности, отказоустойчивости и эксплуатации.
4. Как устроена ролевая модель: можно ли ограничивать доступ по функциям, объектам, типам операций, организациям, филиалам, продуктам, группам клиентов.
5. Как журналируются действия: фиксируются ли изменения тарифов, скидок, балансов, статусов, блокировок, договорных параметров, расчётных правил и интеграционных событий.
6. Как защищены интеграции: API, сервисные учётные записи, обмен с CRM, сетью, личным кабинетом, платёжными системами, отчётностью, ГИС и регуляторными контурами.
7. Предусмотрены ли защищённые каналы и шифрование для критичных обменов: при передаче данных, межсистемном взаимодействии, интеграции с внешними системами, хранении резервных копий и формировании критичных выгрузок. Отдельно стоит проверить управление ключами, сертификатами, сроками их действия, ротацией и отзывом доступов.
8. Как соблюдаются практики безопасной разработки: защищены ли репозитории, есть ли ревью кода, проверка зависимостей, анализ уязвимостей, контроль секретов, защита API, разделение контуров и регламентированный выпуск релизов.
9. Как ограничиваются полномочия пользователей и сервисных учётных записей: применяются ли минимально необходимые права, есть ли регулярный пересмотр доступов, контролируются ли административные действия и прямой доступ к данным.
10. Как поставляются изменения: есть ли тестовый контур, программа и методика испытаний, регрессионные сценарии, контроль релизов, план отката и эксплуатационная документация.

Итого

Биллинг оператора связи — это не просто система начислений. Чаще это АСР как совокупность инфраструктуры, прикладных компонентов, системного программного обеспечения, интеграций, данных, регламентов и эксплуатационных процедур. В этом контуре пересекаются персональные данные, сведения, которые могут относиться к тайне связи, финансовые операции, техническая возможность оказания услуги, регуляторные требования и вопросы КИИ. Поэтому ИБ биллинга не может быть надстройкой, которую добавляют после внедрения. Она должна быть заложена в архитектуру платформы и всей технологической связки.