Утечка через подрядчика: как это работает и что делать
Разбор механики утечек данных через внешних подрядчиков и подрядные организации - и практические меры контроля доступа.
Один из наиболее частых сценариев утечки данных, с которым я сталкиваюсь в разборах инцидентов, - это не взлом извне и не злонамеренный сотрудник. Это подрядчик или аутсорсинговая компания, у которой был доступ к системам, который никто не отзывал, не ограничивал и не контролировал должным образом.
Парадокс в том, что компании уделяют много внимания контролю доступа для штатных сотрудников - и значительно меньше для тех, кто работает снаружи, но имеет прямой вход в системы.
Типичная механика инцидента
Подрядчик нанимается для конкретной задачи - внедрение системы, разработка модуля, поддержка. Ему дают доступ: к базам данных, к внутренним инструментам, к почте или мессенджерам. Задача выполнена. Контракт закончился. Доступ никто не отозвал.
Через полгода тот же подрядчик работает у конкурента. Или учётные данные утекли в ходе взлома в самой подрядной компании - и теперь у кого-то постороннего есть рабочий вход в вашу систему.
Даже без злого умысла: сотрудник подрядчика уходит из компании, его корпоративный ноутбук продаётся или передаётся другому - а на нём сохранены ваши данные или токены доступа.
Почему это системная проблема, а не разовый сбой
Большинство компаний не ведут актуального реестра того, у кого есть доступ к каким системам. Когда я прошу такой список на аудите - обычно его нет, или он устарел на год-полтора.
Причина проста: создание доступа - это задача с конкретным исполнителем и дедлайном. Отзыв доступа - это задача без владельца и без дедлайна. Никто её не ставит в трекер. Никто её не проверяет.
В результате в любой компании с историей более 3-4 лет есть учётные записи, которые давно не должны существовать. Бывшие сотрудники. Завершённые проекты. Ушедшие подрядчики.
Что делать практически
Это не требует сложных технических решений на первом шаге. Требует организационной дисциплины:
- Реестр доступов подрядчиков. Отдельный список: кто, к каким системам, с какого по какое число. Обновляется при каждом изменении.
- Автоматическое истечение. Доступ для подрядчиков создаётся с датой окончания - привязанной к дате контракта. Продление требует явного подтверждения.
- Минимальные привилегии. Подрядчик получает доступ только к тому, что нужно для конкретной задачи. Не к боевой базе данных целиком, а к конкретной схеме. Не к почтовым ящикам всех сотрудников, а к нужной папке.
- Процедура offboarding. Завершение контракта должно включать пункт "отозвать все доступы". Это должно быть задачей в checklist-е, а не в чьей-то памяти.
- Периодический аудит. Раз в квартал - прогон по всем внешним учётным записям и сравнение с актуальным реестром контрактов.
Вопросы для самопроверки
Если хотите понять, где вы сейчас:
- Можете ли вы прямо сейчас назвать всех внешних подрядчиков, у которых есть доступ к вашим системам?
- Есть ли среди них те, чьи контракты уже завершены?
- Что произойдёт, если один из ваших действующих подрядчиков будет взломан сегодня?
Ответы на эти три вопроса дают хорошее представление о реальном уровне риска. И о том, с чего начать.