Хаборовчане и гости привет!

Вкратце суть того что произошло. По сути фильм ужасов от Бегет.

В ночь с 1 на 2 ноября 2026 года на нашу инфраструктуру была совершена кибератака с получением доступа к управляющему контуру всей архитектуры и последующим запуском обнуляющих скриптов.... К сожалению, бинарные бэкапы VPS полностью утеряны. Остаётся возможность восстановления данных из файловых бэкапов.... В облачной инфраструктуре (VPS, S3 и Kubernetes) все данные были утрачены.... Настройки CDN, IP утрачены. Мы не сдаёмся и продолжаем поиск способов восстановить эти данные.
Источник https://vk.ru/begetru?w=wall-2782733_35546

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

Итак, что же произошло. Из скудной информации от самой Бегет мы вряд ли узнаем в ближайшем будущем реальную картину происходящего. В начале этого инцидента они назвали это форс‑мажором и обстоятельствами непреодолимой силы. Хотя на мой взгляд следить за инфраструктурной безопасностью это ответственность поставщика и никак не может являться обстоятельством непреодолимой силы. Ну об этом уже лучше скажут юристы.

Вкратце расскажу о себе, я работаю на данный момент SRE инженером. В круг моих задач входит, в том числе делать postmortem разбор. Проще говоря, это разбор полётов после серьёзного инцидента. Мы восстанавливаем хронологию событий, выясняем, что пошло не так, почему существующие механизмы защиты не сработали и, самое главное, что нужно изменить, чтобы подобная ситуация больше не повторилась. При этом важный принцип такого разбора — не искать виноватых, а искать причины. В SRE это называется Blameless Postmortem.

Также у меня 18 летний стаж системного администратора и по совместительству девопса. Чего я только не насмотрелся и не навидался за эти годы. Экономия на людях, грязные увольнения, безалаберность и забивательство на все что связно с их работой. В общем человеческий фактор очень сильно влияет на бренд, продукт и бизнес идею. Поэтому эйчары сейчас так востребованы, им сказали искать «адекватных». И они запустили свои тесты, многоуровневые собеседования и ИИ шные авто проверки. Это то что на входе. А всегда ли есть уверенность за тех кто уже вошел?

С тем что произошло с Бегет я столкнулся в миниатюре в своей прошлой компании. И вдохновленный этой историей написал статью тут на Хабре которая называется «Побойтесь ДевОпса, сударь...». И вот то что произошло в Бегет очень мне напоминает именно этот сценарий. Почему?

Вот если подумать то кибератака она имеет более прагматичные цели — шантаж, увести данные, кого‑то разоблачить и так далее. А тут мы вошли в банк и тупо взорвали его? Нет, это не похоже на хоть сколько‑нибудь логичную цель. Я не раз попадал на различные эксплойты в своей системе. Последствиями были в лучшем случае либо майнеры, в худшем шифровщики которые хотели денег. Люди снаружи это все таки в первую очередь гости. Они не знают до мелочей как устроена ваша инфраструктура. Даже при наличии сетевых инструментов такой тщательный аудит провести значительно сложнее без предварительного доступа или знания внутренней архитектуры. Есть такая пословица — Пожар хуже вора тот хоть стены оставит. То есть грабитель, злоумышленник он оставляет хоть что‑то и неложит все напрочь.

Конечно, существуют и внешние атаки, направленные исключительно на уничтожение инфраструктуры. Но лично мне эта история напомнила другой сценарий, с которым я уже сталкивался. Сценарий, когда человек, хорошо знающий внутреннее устройство инфраструктуры, получает возможность уничтожить её изнутри. Да все что произошло в Бегет — что называется полное уничтожение инфры — больше похоже на поехавшего кукушкой админа который решил все уничтожить потому что его решили уволить или он развелся с женой. Да вот также как когда‑то пилот самолета решил врезаться в горы со всеми своими пассажирами в 2015 году (авиакатастрофа рейса Germanwings 9525, которая произошла 24 марта 2015 года во Французских Альпах. Погибло 150 человек). Эта трагедия показала, насколько катастрофическими могут оказаться последствия, когда один человек получает возможность единолично управлять критически важной системой.

Просто не проследили, не договорились. Может и нам в ИТ сфере пора заводить своих корпоративных психологов? Повод задуматься.

Такое может случиться с каждым. И в каждой крупной компании есть страх, что у админа (если он не заинтерисант и не в доле) не случится вот такого вот криза. Что же делать? Как быть уверенным что сценарий Бегет не повторится и у вас?

Что можно сделать, если ты внутри?

Есть несколько давно отработанных механизмов, которые позволяют существенно снизить риски. Причём речь не только о защите от внешних злоумышленников, но и от своих же сотрудников. Даже если у кого‑то из них однажды возникнет желание нажать на большую красную кнопку.

Первое RBAC (Role‑Based Access Control), или управление доступом на основе ролей. Суть довольно простая. Доступы выдаются не конкретному Васе или Пете, а определённым ролям. Например, разработчику совершенно необязательно иметь возможность удалять базы данных на проде, а системному администратору, который занимается сетями, незачем иметь полный доступ ко всему Kubernetes‑кластеру. Каждый должен иметь ровно столько прав, сколько ему необходимо для выполнения своих задач. И не больше. А если сотрудник увольняется или переходит в другой отдел, достаточно убрать его из соответствующих ролей, чтобы он потерял связанные с ними доступы. Роли можно сейчас создавать везде. В любой административной программе, главное не забывать об этом.

Второе IAM (Identity and Access Management), централизованное управление пользователями и доступами. Чтобы не получилось так, что человек уволился полгода назад, а его SSH‑ключ до сих пор лежит на десятке серверов. Или у бывшего девопса остался токен от облака, про который все благополучно забыли. В идеале у компании должна быть единая система, которая знает, кто ты, где работаешь и к чему имеешь доступ. Уволился человек, нажали условную кнопку Disable, и все его доступы, управляемые этой системой, стали недействительными. Конечно, при условии, что инфраструктура действительно интегрирована с IAM, а не живёт своей жизнью с локальными учётками и вечными токенами. Из ярких представителей это Keycloak или Microsoft Entra ID.

И третье Zero Trust. «Нулевое доверие». Мы по умолчанию никому не доверяем. Даже своим. Даже тому самому админу, который работает в компании десять лет и знает всю инфраструктуру лучше собственного дома. Это не значит, что мы считаем каждого сотрудника потенциальным преступником. Это значит, что мы заранее допускаем возможность компрометации любой учётной записи или человеческой ошибки. Тут даже уместно сделать цитату из Библии «Не надейтесь на князей, на сына человеческого, в котором нет спасения». Эти слова подтверждают проблему надежды на кого либо из людей и давно прочувстовали что человек может в определенной ситуации подвести.

Если кому то понадобилось что‑то сделать запросил доступ, получил необходимые права на ограниченное время, выполнил работу, доступ закончился. Например, через bastion или jump‑host (например «warpgate»), где можно контролировать подключения и вести аудит действий. Причём особо опасные операции, такие как массовое удаление виртуальных машин, хранилищ или резервных копий, вообще неплохо было бы проводить с дополнительным подтверждением. Чтобы один человек, даже обладая административными полномочиями, не мог в одиночку уничтожить всю инфраструктуру. В этом яркий представитель «Teleport» или «HashiCorp Boundary»

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

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

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

Храните все супер важные данные не у себя, а где‑то снаружи в облаке к которому есть только вход на запись. Разберитесь в этом, поверьте это не так сложно.

Мне нравятся как поступают банки. Они привлекают разные команды к своей инфраструктуре и организовывают работу так, чтобы все друг друга пасли. Каждый отвечает за свой участок.

Что можно было сделать если ты снаружи?

Что делать тем кто сейчас хостится на каких либо площадках и боится повторения сценария Бегет. Я опираясь на свой опыт уже много лет привык делать бэкапы в телегу. Делаю бота и заливаю туда. Конечно, Telegram не специализированное бэкап хранилище, и для серьёзных объёмов или чувствительных данных лучше использовать предназначенные для этого решения. Но для небольших собственных проектов такой способ у меня вполне работает.

Так же код приложений хранится на гите и в локале конечно он тоже есть.

Если есть тяжелые данные, то лучше сохранять на внешний ресурс типа Яндекс клауда. Если Яндекс пропадет, то явно не одновременно с вашим хостом и вы сможете своевременно перенести данные. Конечно при этом ваш хост и облако не должны быть в одной корзине. Лучше чтобы это были разные компании. И Главное за этим (бэкапами в облако) следить и получать уведомления если вдруг что‑то не копируется и вы забыли это проверять. То есть к примеру вы настроили копирование в Яндекс s3 а там закончилось квота — нужно чтобы вы знали об этом. И помните, наличие S3 ещё не означает наличие резервных копий. Обычно провайдеры предлагают версионирование, иногда репликацию и защиту от удаления. Но что именно доступно и как это работает, нужно выяснять отдельно. И самое главное версионирование внутри одного хранилища не заменяет независимый бэкап.

Что можно сделать сейчас?

Можно дождаться когда Бегет поднимет свою инфраструктуру или переехать.

Вопрос, что с данными. Что значит есть файловые бэкапы, а не бинарные? Это значит, что восстановить виртуальную машину целиком, вместе с операционной системой и её состоянием, скорее всего, уже не получится. А вот файлы приложений, конфигурации и даже базы данных вполне могут сохраниться. Но здесь уже всё зависит от того, каким способом делались эти бэкапы и насколько они пригодны для восстановления. Если файловые бэкапы снимались с работающей базы данных без учёта механизмов самой СУБД, то при восстановлении могут возникнуть серьёзные проблемы. Впрочем, многое зависит от технологии резервного копирования. Если использовались согласованные снапшоты или специализированные инструменты, шансы на восстановление могут быть достаточно высокими. Если данные хранились в S3 самого Beget, то ситуация ещё печальнее. Провайдер сообщил об их утрате, и пока нет подтверждения, что все эти данные удастся восстановить. Поэтому тем, у кого не было собственных резервных копий за пределами площадки, остаётся надеяться на результаты восстановительных работ. Диагноз не утешителен.

Как это затронуло лично меня?

Я долгое время был фрилансером и в до иишные годы успел сделать немало проектов которым нужно было где‑то хоститься. В те сладкие для программистов 2010 е года выбор пал на Бегет. Не помню по какой причине я туда пришел, но хостинг мне понравился. Приятная панель для клиентов, все юзабельно и просто в навигации. Все понятно с ценой и расчетами. Проработав несколько лет с ними и не разу не столкнувшись с какими либо серьезными проблемами уже тогда понял что буду рекомендовать эту площадку своим клиентам.

По итогу у меня там оказалось около десятка моих клиентов. И наступил черный понедельник 2026 года...
Все произошло как будто бы по сценарию Чернобыльской АЭС только в ИТ сфере. На самом деле большая трагедия. Для кого то потеря данных, для кого то потеря прибыли, для кого то, в том числе для самой Бегет массовый отток клиентов и потеря доверия которое нарабатывалось годами.

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

Вывод

Вся эта история в очередной раз показывает, насколько хрупкой может оказаться даже крупная инфраструктура, которую годами строили десятки и сотни специалистов. Можно вложить миллионы в оборудование, собрать команду профессионалов, выстроить сложную архитектуру, но в один прекрасный день всё это может перестать существовать. Что на самом деле произошло внутри Бегет, мы пока не знаем. Была ли это внешняя атака, компрометация привилегированных учётных записей или человеческий фактор покажет расследование, если его результаты вообще станут публичными. Я лишь поделился своими предположениями, основанными на многолетнем опыте работы в ИТ. И совершенно не утверждаю, что описанный мной сценарий действительно имел место. Но главное даже не в этом. Не так важно, кто именно нажал на кнопку удаления. Важно, почему у него вообще была возможность уничтожить всё. И почему механизмы защиты и восстановления не смогли предотвратить такие последствия. Для тех, кто управляет собственной инфраструктурой, это хороший повод пересмотреть права доступа, проверить резервное копирование и задать себе один неприятный вопрос: а что будет, если завтра кто‑то получит максимальные права в нашей системе? Сможет ли он удалить не только прод, но и все бэкапы вместе с ним? Для тех, кто арендует инфраструктуру у хостинг‑провайдеров, вывод ещё проще. Не стоит складывать все яйца в одну корзину. Каким бы надёжным ни казался ваш провайдер, ваши данные в первую очередь нужны вам, а значит, и ответственность за возможность их восстановления должна оставаться, в том числе на вашей стороне. Мне искренне жаль команду Бегет. За долгие годы работы с этим хостингом у меня сложилось о нём исключительно положительное впечатление. И я прекрасно понимаю, какой объём работы сейчас приходится выполнять инженерам, пытающимся восстановить то, что ещё можно восстановить. Отдельно сочувствую клиентам, для которых эта история обернулась потерей данных, денег и, возможно, собственного бизнеса. Очень хочется, чтобы Бегет всё‑таки опубликовал полноценный технический postmortem с хронологией событий, установленными причинами и выводами. Не ради публичной порки и поиска виноватых, а ради того, чтобы вся индустрия могла извлечь из этой истории уроки.

Берегите свои данные.