Доступ подрядчиков и вендоров: недооценённая точка риска
Третьи стороны с доступом к вашим системам - один из самых слабо контролируемых периметров безопасности. Как думать об этом управленчески.
Большинство серьёзных инцидентов с безопасностью происходит не там, где их ждут. Периметр собственной инфраструктуры компании сегодня более-менее понятен: есть межсетевые экраны, есть политики, есть ответственный за ИБ. Но есть другая точка риска, которая контролируется значительно хуже.
Я говорю о доступе, который компания предоставляет третьим сторонам: подрядчикам, интеграторам, поставщикам ПО, аутсорсинговым командам. Этот доступ часто выдаётся быстро, в рамках конкретного проекта - а потом не отзывается годами.
Как выглядит типичная картина
Компания нанимает интегратора для внедрения CRM. Интегратору выдают доступ к базе данных, к системам, возможно к почте. Проект завершается. Часть доступов отзывается, часть - нет, потому что "вдруг понадобится поддержка". Через год команда интегратора сменилась, но учётные данные живут.
Или: компания работает с аутсорсинговой командой разработки. Разработчики имеют доступ к репозиторию, к staging-среде, иногда к prod. Сотрудничество заканчивается. Доступ остаётся.
Я спрашиваю об этом у клиентов почти в каждом проекте, и стандартный ответ: "у нас это как-то регулируется, но честно говоря, точного реестра нет". Точного реестра нет почти нигде.
Почему это настоящий риск, а не теоретический
В 2019 году несколько публично известных инцидентов было связано именно с доступом через третьих лиц. Атакующие всё чаще предпочитают компрометировать менее защищённую цепочку поставок, а не атаковать целевую компанию напрямую. Подрядчик, у которого есть привилегированный доступ к вашей инфраструктуре, но нет вашего уровня защиты - это прямой маршрут.
Это не гипотеза. Атака на Target в 2013 году началась через подрядчика по HVAC-системам, у которого был доступ к сети. Подобная схема воспроизводится с тех пор регулярно.
Что нужно сделать
Первое - провести инвентаризацию. Составить список всех третьих сторон, которые имеют или имели доступ к вашим системам. Для каждой: что именно за доступ, с какого момента, кто выдал, актуален ли он сейчас.
Второе - принцип минимального доступа. Подрядчик должен иметь доступ только к тому, что нужно для конкретной задачи. Не ко всей базе данных - к конкретной таблице. Не ко всему репозиторию - к конкретному проекту.
Третье - срок действия и отзыв. Доступ для временного проекта должен иметь срок действия или быть явно отозван по завершении. Это организационная процедура, а не технический вопрос - нужно, чтобы кто-то был ответственен за это действие.
Четвёртое - разделение сред. Подрядчик, которому нужна production-база для работы, - это исключение, которое требует отдельного обоснования. По умолчанию - staging, анонимизированные данные, ограниченная среда.
Практическая проверка
Три вопроса, которые дают быстрый срез ситуации:
- Можете ли вы прямо сейчас назвать полный список активных учётных записей, принадлежащих не вашим сотрудникам?
- Когда последний раз проводился аудит доступа третьих сторон?
- Есть ли процедура отзыва доступа при завершении проекта - и кто за неё отвечает?
Если на первый вопрос ответ "нет" или "не знаю" - это достаточная причина, чтобы поставить эту задачу в приоритет на ближайший квартал.