Разбор ИБ-инцидентов: какие уроки дают утечки, месть сотрудников и открытые секреты

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

Три частых класса проблем: действия инсайдера, потеря или утечка данных и публикация секретов. Каждый из них закрывается не одним инструментом, а набором процессов.

Доступы бывших сотрудников

Один из самых неприятных сценариев — человек уходит из компании, но сохраняет доступ к системам. Иногда это забытый VPN, личный SSH key, токен в CI, сервисная учётка или доступ к облаку через старую группу.

Минимальный offboarding-процесс должен включать:

• отключение SSO и корпоративной почты;
• отзыв VPN и SSH-доступов;
• ротацию shared secrets;
• проверку cloud IAM;
• удаление из GitHub/GitLab организаций;
• отзыв токенов CI/CD;
• проверку доступов к password manager;
• аудит последних действий.

Важно, чтобы offboarding был не ручным списком в голове администратора, а повторяемой процедурой. Чем больше систем подключено к SSO и IAM, тем меньше шанс что-то забыть.

Секреты в репозиториях

Секреты в коде — классическая проблема. Токен может попасть в публичный репозиторий, лог CI, Docker image, issue или paste. Опасность в том, что сканеры злоумышленников работают быстро: иногда токен начинают использовать через минуты после публикации.

Защита строится слоями:

• pre-commit scanning;
• server-side secret scanning;
• запрет push с секретом;
• короткоживущие токены;
• минимальные scopes;
• автоматическая ротация;
• audit log использования;
• отдельные ключи для окружений.

Если секрет уже утёк, его нельзя «просто удалить из Git». Нужно отозвать и заменить. История репозитория, forks и caches могут сохранять значение.

Потеря данных

Потеря данных часто связана не с хакерами, а с ошибками эксплуатации: удалили bucket, перезаписали базу, сломали миграцию, неправильно настроили retention. Здесь спасают backup и регулярная проверка восстановления.

Правило простое: backup, который ни разу не восстанавливали, — это надежда, а не механизм защиты.

Нужны:

• расписание бэкапов;
• отдельное хранилище;
• immutable backups для критичных систем;
• тест восстановления;
• понятные RPO/RTO;
• мониторинг успешности backup jobs;
• документация rollback-процедуры.

DLP и monitoring

DLP не должен быть единственной линией защиты, но помогает находить аномалии: массовую выгрузку файлов, отправку архивов наружу, копирование клиентских баз. Для инженерной инфраструктуры аналогом служат audit logs и alerts по необычным действиям.

Полезные сигналы:

• массовое чтение данных;
• создание access keys;
• изменение IAM policies;
• отключение логирования;
• экспорт базы;
• скачивание большого объёма репозиториев;
• входы из необычных стран или устройств.

Incident response

Когда инцидент уже произошёл, важна скорость и последовательность. Нужен план:

1. подтвердить факт;
2. ограничить распространение;
3. сохранить evidence;
4. отозвать доступы;
5. восстановить сервис;
6. уведомить заинтересованных;
7. провести postmortem;
8. закрыть системные причины.

Без заранее описанного процесса команда будет спорить в момент, когда нужно действовать.

Итог

Большинство ИБ-инцидентов можно использовать как практическую проверку своей инфраструктуры. Есть ли offboarding? Сканируются ли секреты? Проверяются ли бэкапы? Видны ли аномальные действия? Есть ли incident response plan?

Безопасность — это не один продукт, а дисциплина эксплуатации. Чем скучнее и повторяемее процессы, тем меньше шанс попасть в громкий инцидент.