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

Меня зовут Катя Саяпина, я менеджер продукта МТС Exolve. В этом материале покажу вам, как можно использовать нашу платформу для защиты корпоративного номера.

Риски легальных инструментов

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

Как это работает? Рекламные платформы умеют обрабатывать клиентские списки. На их основе строятся аудитории для показов или звонков. Формально персональные данные не раскрываются, но на практике появляется возможность точечного взаимодействия с человеком по номеру, а значит — и косвенной идентификации.

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

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

В МТС Exolve мы превратили эту логику в конкретные механизмы защиты. В следующем разделе  разберём их на примерах сценариев и архитектуры, чтобы показать, как это работает в реальных условиях.

Решение: «Защита номера»  от МТС Exolve

Когда мы проектировали защиту номеров в МТС Exolve, задача была не «спрятать» номер в одном месте, а разорвать саму возможность его детерминированного сопоставления с человеком или компанией. То есть сделать так, чтобы в любой точке внешнего взаимодействия (звонок, SMS, интеграция с подрядчиком) использовался  временный номер.

Архитектура решения базируется на трёх принципах:

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

2. Динамическая ротация. Клиент сам управляет тем, сколько времени используется временный номер. Он задает срок и по его истечению номер выводится из обращения, и даже если такой номер «утечёт», то он уже бесполезен.

3. Централизованный контроль и логирование. Все сопоставления «основной ↔ временный» хранятся внутри МТС Exolve, с доступом только у уполномоченных администраторов.

Как это выглядит в потоке? Менеджер звонит клиенту. В телефоне клиента отображается не +7 495 XXX‑XX‑XX компании, а, например, +7 499 YYY‑YY‑YY из пула МТС Exolve. Этот номер будет работать ровно столько, сколько мы задали в политике.

Защита работает как с нашей собственной SIP‑телефонией, так и через интеграции с внешними АТС и CRM. Мы умеем управлять пулом номеров через API. Это позволяет встраивать защиту в существующие процессы без перестройки инфраструктуры.

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

В результате даже при утечке данных из CRM, логов колл‑центра или у подрядчика, злоумышленник получает только временные идентификаторы, которые уже не работают. Цепочка «номер — человек» обрывается, а значит, и сценарий «пробива» становится невозможен.

Примеры внедрения

В кейсе Banki.ru мы закрывали именно эту зону риска: коммуникации между пользователями и представителями финансовых организаций переводились на прокси-номера, чтобы основной номер не светился ни в логах подрядчиков, ни в интерфейсах сторонних систем. Защита строилась вокруг принципа «общаемся — не раскрываясь»: выделенный виртуальный номер маршрутизирует звонок по нужному сценарию, а соответствия «кто с кем говорил» остаются внутри периметра МТС Exolve, без раздачи персональных номеров вовне. В результате пользователь общается с банком, а банк — с пользователем, но прямых номеров друг друга они не видят, и это сильно усложняет любые попытки «пробива» или последующего нежелательного контакта со стороны третьих лиц.

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

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

Сценарии применения

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

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

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

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

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

Архитектура

На входе находится уровень интеграции с CRM или другой системой управления заявками. Именно она инициирует создание временной прокси‑связки, передавая в модуль защиты только служебные идентификаторы — ID клиента, ID сотрудника и сценарий вызова. Основные номера на этом этапе не передаются. Запрос уходит в API‑метод getControlCallFollowMe, который в схеме показан как отдельный элемент между CRM и модулем защиты.

Далее работает модуль защиты номеров, расположенный в центре схемы и связанный с пулом виртуальных номеров. Получив команду от CRM, он выбирает свободный номер из пула, назначает его на конкретную связку «клиент ↔ сотрудник» и применяет сценарий маршрутизации: куда направить вызов, в какое время, что делать при занятой линии. Здесь же хранятся зашифрованные соответствия между основными и виртуальными номерами, а также реализованы политики жизни прокси‑идентификаторов — от минутных до недельных, с ограничениями по времени, географии и дополнительной аутентификацией.

После этого в работу вступает уровень телефонии — облачная или локальная АТС, которая физически соединяет стороны через назначенный прокси‑номер, не раскрывая основных  номеров. На этом этапе могут включаться функции записи звонка, шифрования и фильтрации по заданным правилам.

Далее у нас аналитика и аудит: данные о каждом соединении (кто, когда, по какому сценарию связывался, длительность и статус вызова) возвращаются в систему мониторинга. Эта информация используется для SLA‑отчётности, выявления аномалий и мгновенной блокировки связок при подозрительной активности.

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