«Считается, что мессенджеры для бизнеса, это безопасно. На практике можно увидеть, что безопасность не в протоколах, а в умах людей, которые их используют. Тот же инструмент, который должен упрощать общение с клиентами, легко превращается в люк, ведущий к финансовым данным целой компании, если его настраивать по принципу ‘лишь бы работало’.»
Почему мессенджер для бизнеса вызывает больше доверия, чем обычный
Когда компания переходит на специальную версию мессенджеров, это выглядит как осознанный шаг. Платформа маркируется как «Для бизнеса», появляется зелёная галочка верификации, функция автоматических ответов и каталог товаров. Всё это создаёт иллюзию надёжности — раз сервис позиционируется для делового общения, значит, и безопасность в нём продумана.
Но фундаментально технология передачи данных — шифрование, протоколы — часто остаётся той же, что и в потребительской версии. Разница в восприятии. Контрагенты и клиенты охотнее пересылают в такой чат важные документы, логины и даже реквизиты для оплаты, полагая, что канал заведомо защищён. Психологический эффект «зелёной галочки» или официальной карточки компании перевешивает базовые правила информационной гигиены.
Типичный сценарий: настройка как повод для ошибки
Администратор подключает бизнес-профиль, чтобы сотрудники отдела продаж или поддержки могли отвечать клиентам. Важная задача — обеспечить непрерывность работы. Поэтому доступ к аккаунту часто выдают нескольким сотрудникам, используя один и тот же телефон для регистрации, но подключая к нему веб- или десктоп-версию на разных компьютерах.
Ситуация усугубляется, когда сотрудник, отвечающий за бухгалтерию или финансовые вопросы, для скорости тоже начинает использовать этот «общий» рабочий чат. Ведь там уже есть история общения с контрагентом, и проще отправить счёт или акт прямо в него. Настройки безопасности при этом сводятся к минимуму: двухфакторная аутентификация не включается, чтобы не усложнять доступ, сессии в веб-версии не контролируются и не закрываются месяцами.
В результате мессенджер, зарегистрированный на служебный телефон отдела продаж, становится точкой входа для финансового документооборота. Достаточно получить доступ к одному из компьютеров с активной сессией — и вся история переписки, включая чувствительные данные, окажется в руках злоумышленника.
Технические бреши, которые мало кто проверяет
Даже если компания использует корпоративный мессенджер, его безопасность зависит не только от разработчиков, но и от настроек.
Неограниченное количество активных сессий
Веб-версия и приложения для компьютеров могут работать одновременно на множестве устройств. Если сотрудник авторизовался на рабочем ПК, домашнем ноутбуке и планшете, все эти сессии остаются активными. Увольняясь или теряя устройство, он может забыть выйти из аккаунта. Контроль за сессиями — ручной и часто отсутствует.
Отсутствие сегментации данных
Бизнес-мессенджеры редко разграничивают доступ внутри одного аккаунта. Если бухгалтер, менеджер и директор общаются с клиентами через один профиль, то получивший к нему доступ увидит всё: от коммерческих предложений до внутренних обсуждений зарплат и платежей.
Резервное копирование в облако
Для удобства многие включают автоматическую загрузку резервных копий чатов в облачное хранилище. Если учётная запись этого хранилища защищена слабым паролем, то компрометация облака приводит к утечке всей истории переписки, включая удалённые сообщения.
От чата до 1С: как данные утекают дальше
Получив доступ к истории бизнес-чата, злоумышленник видит не просто разговоры. Он находит цепочки, где:
- Бухгалтер отправляет клиенту скан подписанного счёта с реквизитами компании и суммой.
- Менеджер в ответ получает от клиента скриншот или документ об оплате с данными плательщика.
- Обсуждаются детали договоров, иногда с указанием контактных лиц и их прямых номеров.
- Пересылаются логины и пароли для доступа к тестовым окружениям или клиентским кабинетам на сторонних площадках.
Этих данных часто достаточно для социальной инженерии. Например, позвонив от имени бухгалтера и сославшись на «только что обсуждавшийся в чате» вопрос, можно запросить уточнённые реквизиты или даже попытаться инициировать перевод на новый счёт. Контекст из переписки придаёт атаке правдоподобность.
Что можно сделать, чтобы не оказаться в такой истории
Запретить мессенджеры — нереально. Но можно минимизировать риски, введя простые правила.
Разделение профилей по функциям
Создайте отдельный бизнес-аккаунт исключительно для обсуждения финансовых и юридических вопросов. Доступ к нему должен быть у ограниченного круга лиц, а сессии строго контролироваться. Общение с клиентами по общим вопросам должно вестись через другой, отдельный профиль.
Жёсткий контроль сессий и аутентификации
- Включите двухфакторную аутентификацию для регистрации аккаунта.
- Регулярно просматривайте список активных устройств и сессий и отзывайте те, что не используются или вызывают подозрения.
- Настройте автоматический выход из неактивных сессий на компьютерах, например, каждую неделю.
Запрет на пересылку критичных данных
Чётко определите, какую информацию нельзя пересылать даже в «безопасный» чат. К такой информации относятся пароли, полные банковские реквизиты (особенно с подписями), сканы паспортов, внутренние учётные записи. Используйте для их передачи специализированные, лучше отечественные, сервисы с журналированием и контролем доступа.
Отключение облачных резервных копий
Если функционал не критичен, отключите автоматическую выгрузку истории чатов в сторонние облачные хранилища. Локальные резервные копии, если они необходимы, должны храниться на защищённых корпоративных ресурсах.
Итог: безопасность, это процесс, а не галочка
История с доступом к бухгалтерии через мессенджер — не про уязвимости в коде приложения. Она про то, как удобство и доверие к бренду сервиса размывают границы безопасного поведения. Любой инструмент, даже самый «защищённый», может стать ахиллесовой пятой, если его внедрять без анализа реальных рабочих процессов и рисков. Зелёная галочка «Для бизнеса» — не щит, а лишь указатель. Что находится за ним — грамотно настроенная система или хаотичный обмен критичными данными — зависит уже не от разработчика, а от тех, кто этот инструмент использует.