Подмена контактных данных — один из самых коварных сценариев ущерба базе: карточки на месте, менеджеры «работают», но звонки и письма уходят не туда. Разберем расследование такого инцидента по шагам — независимо от того, каким инструментом вы его обнаружили.
Как выглядит инцидент
Типичная картина: за короткое окно (минуты — часы) один сотрудник или технический аккаунт заменяет телефоны и email у десятков карточек. Значения меняются на:
- подставные номера (уводят клиента «в тень»);
- личные контакты сотрудника;
- адреса одного внешнего домена (перенаправление на конкурента);
- пустые значения (очистка).
Шаг 1. Зафиксируйте масштаб
Определите границы: период, автор, типы объектов, количество изменений. В штатной истории Bitrix24 придется пройтись по карточкам вручную; системы контроля изменений показывают выборку сразу. В Veriqon такой инцидент создается автоматически правилами пакета «Подмена контактных данных» — с окном, автором и списком затронутых объектов; см. разбор сценария массовой замены контактов.
Шаг 2. Проверьте источник
Массовые изменения — не всегда человек:
- Импорт файла мог переписать поля при совпадении ключей.
- Интеграция (телефония, маркетинговый сервис) могла синхронизировать данные с ошибкой.
- Вебхук или приложение могли выполнить массовое обновление.
Если источник технический — это тоже инцидент, но другого рода: проверьте, кто владеет ключом и почему операция не была заявлена. Ручной реестр штатных источников (в Veriqon — Центр доверия) сокращает эту проверку до секунд.
Шаг 3. Изучите паттерн новых значений
Ключевой вопрос: на что заменены контакты?
- Один и тот же номер/адрес у многих карточек — явный признак подставных данных.
- Один внешний домен у новых email — вероятное перенаправление.
- Пустые значения — зачистка перед уходом или заметание следов.
Сравнение выполняйте по маскированным значениям или отпечаткам — тиражировать открытые персональные данные в отчетах о расследовании не стоит. В Veriqon история критичных полей хранит маскированные было/стало, а дубли ищутся по HMAC-отпечаткам.
Шаг 4. Проверьте контекст автора
- Время: рабочее или ночь/выходные?
- Принадлежность объектов: свои клиенты или чужие?
- Смежные действия: просмотры перед заменами, удаления, изменения сделок?
- Статус сотрудника: нет ли поданного заявления об уходе?
Совокупность контекста отличает ошибку от умысла лучше любого отдельного факта.
Шаг 5. Восстановите данные
- История изменений карточки в Bitrix24 хранит прежние значения полей.
- При импорте-перезаписи поможет резервная выгрузка, если она велась.
- Восстановление проводите проверяемо: список карточек, кто восстановил, по какому источнику.
Шаг 6. Закройте расследование решением
Зафиксируйте: что произошло, кто выполнил, какие объекты затронуты, подтвержден ли риск, какие меры приняты. Даже если это оказалась ошибка импорта — расследование с выводами предотвращает повторение.
Профилактика
- Ограничьте массовое редактирование и импорт правами.
- Ведите реестр интеграций и плановых операций.
- Включите контроль порогов замен: минуты обнаружения вместо недель.
- Проверьте остальные настройки по чеклисту безопасности Bitrix24.