Пять серверов, и никто не знает, у кого остался доступ

Бизнес живёт на нескольких серверах: сайты, CRM-интеграции, боты, аналитика. За годы к ним подключались подрядчики, сотрудники, сервисы. Потом уходит человек, который всё это настраивал, и возникает простой вопрос: а что у него осталось? Ответить на него не может никто.

У нас серверов пять. Сразу после ухода технического специалиста мы проверили доступы. Закладок не нашлось, но доступ администратора на всех пяти серверах и рабочие токены у него всё ещё были.

Доступы раздают «по-быстрому»: нужно срочно починить — дали ключ. Ключи безымянные, списка нет, и через год уже никто не помнит, чей какой. Когда мы свели всё в один реестр, в нём оказалось 28 ключей, и про восемь из них не знал никто: сервисные связки, ключи хостинга, старые ноутбуки.

Мониторинг входов, который должен это ловить, у нас был. Но он поднимал тревогу на свои же автоматические подключения — до 2 100 сообщений в сутки. Такой мониторинг перестают читать, и настоящий сигнал тонет среди ложных.

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

И последнее: журнал действий на серверах хранил около двух часов истории. Разбирать что-то задним числом было бы не по чему.

Завели реестр доступов без самих секретов: чей ключ, куда пускает, где лежит значение и кто за него отвечает. Реестр один и сам разъезжается по всем серверам, поэтому каждый вход теперь подписан именем, а свои сервисные подключения больше не будят.

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

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

С чего начать инвентаризацию, если серверов и подрядчиков много, а времени мало. В каком порядке снимать доступы, чтобы не отрезать себе бэкапы и оплату. Что проверить в первую очередь, если человек уходит со скандалом.

Это разбираем на созвоне — по вашей инфраструктуре, без передачи паролей.