«Ситуации, когда после увольнения сотрудника остаётся дыра в безопасности, случаются постоянно. В большинстве случаев это связано не со злым умыслом, а с фундаментальными упущениями в управлении доступом и аутентификацией. Я столкнулся с классическим кейсом утечки через забытый ключ API и за сутки закрыл дыру, не просто удалив ключ, а перестроив всю систему учёта привилегий под российский регуляторик.»
Тихая утечка: как уволенный специалист оставил ключ от всех данных
Когда сотрудник увольняется, HR проводит собеседование и забирает пропуск. IT-отдел отключает учётную запись в корпоративной почте и VPN. На этом процесс часто заканчивается. Но в современной инфраструктуре доступ к данным редко ограничивается паролем от рабочего компьютера.
Основной вектор угрозы сместился к сервисным аккаунтам, токенам API и ключам доступа к облачным хранилищам. Эти сущности не привязаны к конкретному человеку в системе кадрового учёта. Они живут в конфигурационных файлах, переменных окружения на серверах, в коде приложений и даже в личных заметках сотрудника. Увольнение без полной ревизии этих точек доступа равносильно тому, чтобы оставить бывшему коллеге отмычку от сейфа.
В моём случае речь шла о ключе API к одному из популярных в России S3-совместимых облачных хранилищ. Ключ имел права на чтение и запись в бакете, где десятилетиями копились резервные копии баз данных, включая полную базу клиентов с контактами, историями сделок и внутренними комментариями. Разработчик, уволившийся месяц назад, использовал этот ключ для скриптов резервного копирования. Ключ хранился в открытом текстовом файле на его рабочей машине, которая после увольнения была просто перераспределена другому сотруднику без очистки.
Новый владелец компьютера, изучая старые скрипты, случайно залил папку с ними на публичный Git-хостинг. Через несколько часов ключ и путь к бакету были в открытом доступе. Инцидент обнаружился почти случайно, благодаря мониторингу логов доступа к облаку, где мы увидели аномальный всплеск запросов с неизвестных IP-адресов.
Первые 60 минут: локализация и блокировка
Когда стало ясно, что происходит утечка, счёт пошёл на минуты. Первый шаг — немедленная блокировка источника утечки. В сценарии с публичным ключом API это означало:
- Отзыв скомпрометированного ключа. В панели управления облачным провайдером мы немедленно деактивировали ключ доступа. Это действие мгновенно разорвало все активные сессии, использующие его.
- Изоляция бакета. Права доступа к бакету были сброшены до минимальных. Мы временно оставили доступ только с IP-адресов наших доверенных сетей, полностью закрыв его от внешнего мира.
- Анализ логов. Параллельно с блокировкой мы выгрузили логи доступа за последние 24 часа. Задача — понять, был ли доступ к данным и в каком объёме. Анализ показал сотни тысяч GET-запросов к файлам с именами, содержащими «backup», «dump» и «client». Факт выгрузки данных был подтверждён.
Важный нюанс: простое удаление ключа не удаляет данные, которые уже могли быть скачаны. Это лишь останавливает дальнейшую утечку. На этом этапе мы должны были действовать по принципам реагирования на инцидент ИБ: остановить кровотечение, задокументировать все действия для последующего расследования и уведомить руководство.
Не просто замена ключа: строим систему учёта привилегий
Самый простой путь — сгенерировать новый ключ API и продолжить работу. Это решение лежит на поверхности, но оно оставляет проблему системной. Через полгода история повторится с другим сотрудником или другим сервисом.
Вместо этого я начал выстраивать систему управления доступом, которая соответствовала бы не только здравому смыслу, но и требованиям регуляторов, в частности, 152-ФЗ и приказов ФСТЭК, где принцип минимальных привилегий является базовым.
Работа пошла по трём направлениям:
1. Инвентаризация всех точек доступа
Мы провели полный аудит всех сервисов, где используются долгоживущие ключи, токены или пароли приложений:
- Облачные платформы (S3, виртуальные машины, managed-базы данных).
- Внешние API (платёжные шлюзы, сервисы смс-рассылок, геокодирование).
- Внутренние системы: CI/CD, системы мониторинга, корпоративные wiki.
Для каждого ключа мы завели запись в едином реестре (простой таблицы на начальном этапе было достаточно), указав:
- Назначение ключа.
- Владельца (не человека, а сервис или команду).
- Уровень привилегий (чтение, запись, администрирование).
- Дату создания и плановую дату ротации.
Этот этап сам по себе выявил десятки «бесхозных» ключей с чрезмерными правами, оставшихся от старых проектов.
2. Внедрение политики минимальных привилегий и ротации
Для каждого нового ключа мы начали применять простой, но строгий принцип: выдавать только те права, которые необходимы для выполнения конкретной задачи, и только на конкретный ресурс. Вместо одного ключа с правами на чтение/запись всех бакетов облака, для скрипта резервного копирования был создан ключ с правами только на запись в один конкретный бакет-приёмник и чтение из одного конкретного бакета-источника.
Был установлен обязательный срок жизни для всех ключей: 90 дней для ключей сервисных аккаунтов и 30 дней для ключей, используемых в CI/CD-процессах. Процедура ротации (создания нового ключа и удаления старого) была добавлена в календарь задач ответственного инженера.
3. Защита секретов на уровне инфраструктуры
Хранение ключей в текстовых файлах было полностью запрещено. Мы перевели все секреты в специализированные хранилища, доступные в российском сегменте. Код приложений и скриптов больше не содержал явных ключей. Вместо этого в нём указывались ссылки на переменные окружения или вызовы к API хранилища секретов.
На этапе CI/CD мы настроили безопасную подстановку секретов из защищённого хранилища непосредственно перед запуском пайплайна. Это гарантировало, что даже разработчик, имеющий доступ к коду репозитория, не увидит реальные ключи доступа к продакшен-средам.
Как это связано с требованиями ФСТЭК и 152-ФЗ
Проведённые изменения — не просто технические улучшения. Они напрямую закрывают требования регуляторов по защите персональных данных и критической информационной инфраструктуры.
В Приказе ФСТЭК № 239, например, прямо прописан ряд мер, которые мы реализовали:
- Учёт и управление учётными записями (пункт 17). Наш реестр ключей, это и есть учёт нечеловеческих учётных записей (сервисных аккаунтов).
- Контроль доступа к защищаемой информации (пункт 18). Принцип минимальных привилегий — основа этого контроля.
- Ограничение неуспешных попыток доступа и регистрация событий безопасности (пункты 31, 34). Мониторинг логов, который позволил обнаружить инцидент, является частью этих требований. Теперь мы дополнили его алертами на подозрительную активность ключей.
С точки зрения 152-ФЗ, база клиентов, это массив персональных данных. Инцидент утечки подпадает под определение «нарушение безопасности обработки ПДн». Наличие задокументированной системы управления доступом, политик ротации и учёта точек доступа является ключевым доказательством для Роскомнадзора того, что оператор принимает «меры, необходимые и достаточные для обеспечения выполнения обязанностей», предусмотренных законом. Это может кардинально изменить последствия проверки после инцидента.
Чек-лист на сутки: что нужно сделать после инцидента
Исходя из опыта, вот практический план действий, который можно реализовать за 24 часа, чтобы не только устранить текущую утечку, но и заложить основы безопасности.
| Время | Действие | Результат |
|---|---|---|
| 0–1 час | Немедленно отозвать скомпрометированный ключ/токен. Заблокировать доступ к ресурсу извне. Сохранить все логи. | Утечка остановлена. Есть данные для анализа. |
| 1–4 часа | Провести первоначальный анализ: что утекло, в каком объёме. Уведомить ответственных лиц. Начать заполнение реестра ключей с найденной точки. | Понимание масштаба. Начало системной работы. |
| 4–12 часов | Для критичных сервисов (облако, платёжные системы) провести ротацию всех долгоживущих ключей. Внести их в реестр с чёткими правами. | Ликвидирован риск компрометации других старых ключей. |
| 12–24 часа | Внедрить хотя бы одно защищённое хранилище секретов для одного ключевого процесса. Настроить алерт в системе мониторинга на аномальную активность по доступу к данным. | Создан прототип безопасной инфраструктуры. Поставлен базовый контроль. |
Главный вывод этого плана: безопасность, это процесс, а не состояние. Нельзя «починить безопасность» раз и навсегда. Но можно за сутки совершить критически важный переход от хаотичного хранения ключей к началу управляемого процесса. Это тот минимум, который отделяет компанию, являющуюся лёгкой мишенью, от организации, которая хотя бы видит свои уязвимости и начинает их закрывать.
После нашего инцидента прошло несколько месяцев. Система управления ключами работает, сроки ротации соблюдаются. Каждый новый ключ проходит через утверждение и вносится в реестр. Это не даёт стопроцентной гарантии, но сводит риск повторения ситуации с уволенным сотрудником практически к нулю. Потому что теперь у него просто нет персонального «ключа от всего». Есть только временные, ограниченные по правам и времени жизни инструменты, которые перестают работать в момент, когда они перестают быть нужными.