Как-то, у нашей компании накопился ряд задач, связанных с администрированием наших серверов, и руководство приняло решение, что всё-таки нам нужен DevOps, который закроет наши вопросы и будет в долгую сопровождать нашу команду. Решились. Разместили на https://hh.ru/ вакансию. Нашли человека в городе М.. Руководству было важно, чтобы он был с того же города, где и компания. Но мы никак не могли предположить, что этот человек, который проработал с нами буквально 6 месяцев, чуть не потопил всю нашу компанию. Но, обо всём по порядку.

Хочется для начала, тем, кто несведущ, немного прояснить — что это за должность такая DevOps. Чем он занимается, и что обычно входит в его обязанности. ИИ нам скажет, что DevOps это:

DevOps-инженер — это специалист, который соединяет разработку (Dev) и эксплуатацию (Ops). Его задача — сделать так, чтобы программные продукты быстро, стабильно и безопасно попадали в продакшен и нормально там работали. DevOps отвечает за инфраструктуру. 

Ключевая идея:

разработчики пишут код → DevOps автоматизирует его сборку, доставку, запуск и поддержку.

От себя же добавлю что у нас в России — из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание. И охватывает, по сути, все, что связано с теми, кто работает непосредственно с серверами — это в какой-то степени царь и бог для серверов, которые есть у компании. Он знает все пароли, у него есть ключи от всех врат — при условии, если вы дали эти ключи. Это все нужно ему для выполнения своих обязанностей. Ведь не имея ключа или пароля — очень сложно настроить сервер или настроить микросервис, которому нужны правильные доступы .

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

Но в начале, немного вводных данных — что мы имели на тот момент. Два контура (изолированные среды): дев (где разрабатывают и тестируют) и прод (где работают реальные пользователи). Выделенные физические сервера. Один был размещен в ДатаЦентре, который располагался в Москве. Другой в Санкт — Петербурге. Система proxmox. И десятки виртуальных машин, содержащие различные микросервисы.  Облако Яндекс — для Бэкапов.  И трафик обслуживающий, порою, несколько тысяч пользователей. Да, это не великая инфраструктура, но тем не менее административных задач хватало.

Итак, у нас возникла потребность — решить некоторые вопросы, а именно: 

• Настроить Zabbix (мониторинг работы аппаратных ресурсов, анализ трафика и т.д.). Хотя была настроена Grafana + Prometheus — но новый Тимлид решил, что лучше Zabbix

• сделать CI/CD доставку приложений через git autorun

• Так как на одном из физических серверов заканчивались аппаратные ресурсы, их нужно было расширить, но при этом попробовать оптимизировать расходы и выбрать хостера, который предложит более выгодную цену. То есть нужен был переезд с одного сервера на другой. 

Много что еще по мелочи, но тут главное — понимание, что задач хватало и на перспективу.

Как проходил непосредственно отбор кандидата мне не известно, но в какой-то момент времени в нашей команде появился он, DevOps по имени С. Человек, действительно себя на словах показал хорошим спецом и показал хорошую осведомленность в том, как работают современные решения, рассчитанные на большое количество пользователей. Он с энтузиазмом взялся за работу и мало по мало начал закрывать наши задачи. 

Все было хорошо, но с течением времени С. начал пропускать дейлики и митинги по разным причинам. Начал в долгую отвечать на рабочие вопросы и всячески показывать, что как будто бы ему не до нас. Решение каждой задачи приходилось фигурально «выбивать», и после настойчивых неоднократных просьб что-то решалось. В таком ритме работы, прошло несколько месяцев. Руководство осознало, что нашей команде с С. не по пути и приняло решение расторгнуть трудовые отношения.

Но как сделать это безопасно? Так, чтобы не пострадал наш механизм в случае, если сотрудник решит, что «разрыв» трудовых отношений произошел не по обоюдному согласию. Мало ли что человек может сделать, имея на руках чувствительные данные. И руководство предприняло ряд защитных мер, в день когда оно объявляло С. о принятом решении, оно поменяло все пароли и заблокировала все учетки связанные с С. Расторжение состоялось. Кажется все выдохнули. И тут спустя 5 дней после увольнения С. началось…

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

rm -rf /. 

Но точно мы не знаем. Судя почти по всем логам, произошло какое-то адское событие ядра, потому что в лог файлах они не просто прервались, а туда null поинтеры залогировались в промежутке до рестарта.

Так как это достаточно долгий процесс, мы успели забрать логи с сервера и впоследствии выяснить что произошло:

Итак, последовательно:

• С. за месяц до события Х. (Видимо что-то чувствовал) регистрирует нового пользователя «bin». Дает ему все самые суперские права. Делает это с польского ip адреса посредством vpn. Благо он это делает только на продовском сервере (не знаю почему, может потому что девопсы, как и большинство программистов по природе немного ленивы)

• После увольнения, через несколько часов, он авторизуется и проверяет: сохранился ли у него доступ через этого пользователя.

• Убедившись в этом, он регистрирует крон задачу на уничтожение всех файлов через 5 дней. Ровно в то время, когда у нас обычно рабочее совещание.

Потом, спустя некоторое время, от С. одному из сотрудников приходит сообщение «а вы чего сервер что ли положили, у вас ничего не работает». Далее он предложил за сумму в 1 лям все исправить. 

Конечно, нам не удалось спасти наш прод сервер. Мы потеряли все. Смысла не было там дальше что-то искать.

Это история могла бы так печально закончится, но!

У нас до устройства на работу С. было Яндекс облако, и в одном из бакетов хранились архивы всех виртуальных машин. Да, их актуальность не была до 1 дня, но к счастью большинство сервисов работали уже долгое время, и давно не обновлялись. В отношении бэкапов базы данных. Да конечно же они делались. Но были С. так же уничтожены.

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

И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти, И пожалеете вы вскоре, Когда от них хлебнете горя! 

Конечно, по идее хорошо бы иметь:

• RBAC (Role-Based Access Control) — Управление доступом по ролям. Чтобы доступ выдавался не человеку напрямую, а роли. Чтобы при увольнении было достаточно убрать роль.

• IAM (Identity and Access Management) — Централизованное управление идентификацией и доступами. Кто ты. К чему у тебя есть доступ. При увольнении — одна кнопка disable

• Zero Trust — Никому не доверяем по умолчанию. Даже своим. Доступ временный, а не вечный. Доступ к проду — через bastion / jump-host. Cron, systemd, root — под аудитом. Никто ничего физически не смог бы сделать незаметно. 

Но негоже махать руками после драки. Да и кто это все будет настраивать — он же может и сделать обратное.

Тут выводы конечно сделать сложно, что может помочь избежать подобных ситуаций и какие дать советы. Главное, наверное, чтобы заинтересованное лицо всегда знало о подобных рисках. Быть готовым к подобным выкрутасам. Делать бэкапы всего и вся. Доверять, но проверять. Думать, что я буду делать, если человек окажется неадекват и будет держать за горло всю компанию, по сути, шантажируя ее. Будьте осторожны, учитесь на чужих ошибках и берегите себя. 

Может кто-то уже сталкивался с чем то подобным и поделится своим опытом в комментариях. 

Всем лучиков добра и ясной погоды!