Уволенный менеджер два месяца видел цены и склад компании через приложение

Данные в мобильном B2B-приложении чаще всего утекают не из-за взлома, а из-за токена доступа, который продолжает работать после увольнения сотрудника или потери телефона. Решение — короткий срок жизни токена, серверная сессия вместо локального пароля и доступ, привязанный к статусу сотрудника в 1С, чтобы отключение происходило автоматически, а не вручную.

как бывший менеджер два месяца видел остатки склада и цены компании

14 июля московский дистрибьютор строительных материалов уволил менеджера по продажам. Кадровая служба закрыла его учётную запись в 1С в тот же день, бухгалтерия подписала обходной лист, IT-отдел отключил корпоративную почту. На этом список действий закончился — про мобильное приложение, через которое сорок менеджеров смотрят остатки на складе, цены и историю заказов клиентов, никто не вспомнил.

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

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

почему выход из 1С не означает выход из приложения

В карточке 1С уволенного сотрудника в тот же день поставили статус «не работает». Формально доступа к базе у него не было. Но мобильное приложение получало данные не напрямую из 1С, а через собственный токен авторизации, который сервер приложения выдал при первом входе и который не был связан со статусом сотрудника в учётной системе — поэтому телефон продолжал получать ответы от API, как будто ничего не изменилось.

Так устроены многие корпоративные приложения, собранные без привязки к событиям в 1С: логин один раз, токен живёт неограниченное время, а отозвать его можно только руками — если кто-то вообще вспомнит, что это нужно сделать. У сорока менеджеров компании телефоны личные, IT-отдел их не администрирует, MDM на них нет, а инструкция «сдать доступ при увольнении» существует только для рабочей почты и 1С. Мобильное приложение в эту инструкцию никогда не попадало, потому что его настраивал подрядчик три года назад и с тех пор к архитектуре доступа никто не возвращался.

во что это обошлось

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

Разбор логов, поиск скомпрометированного токена и настройка процесса ручного отзыва доступа заняли у приглашённого сисадмина несколько часов работы по тарифу от 3 800 ₽/час — сумма небольшая по сравнению с тем, что компания два месяца отдавала конкуренту действующие цены. Дороже всего обошлось не расследование, а то, что дыру не заметили сразу — потому что никто не отвечал за проверку логов доступа на регулярной основе, а сам факт утечки всплыл случайно, по совпадению скидок.

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

три способа хранить доступ — и что будет при увольнении

Разница между «доступ жив после увольнения» и «доступ отключается автоматически» — это архитектурное решение, принятое на этапе разработки приложения, а не настройка, которую можно включить постфактум. Вот варианты, которые встречаются в мобильных B2B-приложениях, интегрированных с 1С, от самого уязвимого до самого надёжного.

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

⚙️ как мы строим доступ в приложениях, интегрированных с 1С

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

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

корпоративный телефон или личный — разная модель защиты

Если сотрудник работает с корпоративного телефона, на устройство можно поставить MDM-профиль: удалённая очистка данных компании при увольнении занимает несколько минут и не требует физического доступа к телефону. Если работа идёт с личного телефона сотрудника — а в B2B так чаще всего и происходит, потому что закупать сорок телефонов дороже, чем выдать доступ к приложению — MDM ставить некорректно, и вся защита ложится на архитектуру самого приложения: короткий токен, серверную сессию и синхронизацию со статусом в 1С, как в примере выше.

✅ признаки, что у вашего приложения та же уязвимость

Проверить это можно за один разговор с разработчиком — не нужен аудит на неделю.

• ✓сотрудники входят в приложение под общим логином и паролем от 1С, а не под личной учётной записью;
• ✓токен доступа не имеет срока действия или не обновляется автоматически;
• ✓увольнение сотрудника отражается в 1С и в почте, но не в мобильном приложении — отдельного шага для него нет ни у кадровика, ни у IT;
• ✓журнала входов в приложение не существует, и проверить, кто и когда заходил, невозможно;
• ✓приложение стоит на личных телефонах сотрудников без MDM, рядом с личными фото и мессенджерами.

Если совпало хотя бы два пункта из списка — доступ к приложению стоит пересмотреть до того, как это сделает кто-то другой. Разработка мобильного B2B-приложения с архитектурой, где доступ синхронизирован со статусом сотрудника в 1С, начинается от 500 000 ₽ — сумма зависит от того, нужна ли разработка с нуля или встройка такой логики в уже существующее приложение. Актуальные условия — на странице тарифов.

❓ Частые вопросы

Почему увольнение сотрудника в 1С не отключает его доступ к мобильному приложению автоматически?

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

Как понять, что в нашем мобильном приложении такая уязвимость?

Спросите разработчика, есть ли у токена доступа срок действия и происходит ли отзыв доступа автоматически при смене статуса сотрудника в 1С. Если ответ «доступ отзывается вручную» или «мы это не проверяли» — уязвимость, скорее всего, есть.

Можно ли закрыть эту дыру в уже готовом приложении без переписывания всего проекта?

Да, обычно достаточно доработать модуль авторизации: подключить короткоживущие токены с обновлением через сервер и синхронизацию со статусом сотрудника в 1С. Это отдельная задача, а не полная переработка приложения.

Нужен ли MDM, если сотрудники работают с личных телефонов?

MDM на личный телефон сотрудника ставить некорректно с точки зрения приватности. В этом случае защита строится не на управлении устройством, а на архитектуре приложения: короткий токен, серверная сессия и автоматический отзыв доступа при увольнении в 1С.

Сколько стоит разработка мобильного приложения с такой защитой доступа?

Разработка мобильного B2B-приложения с архитектурой, синхронизированной со статусом сотрудника в 1С, начинается от 500 000 ₽. Точная стоимость зависит от того, разрабатывается приложение с нуля или дорабатывается существующее.