Сервер взломали не у вас, а у хостера
У хостинга FirstVDS уязвимость в системе виртуализации открыла доступ к файлам арендованных серверов: пароли, приватные ключи, доступы к облакам. Вы могли всё сделать правильно и всё равно оказаться под ударом.
Разберём без техножаргона. Ваш сервер у хостера — как офис в арендованном здании. Если у арендодателя сломалась система охраны, неважно, какой замок вы поставили на свою дверь: файлы, которые лежали внутри, могли увидеть посторонние.
Больше всего в таких историях страдают те, у кого на сервере лежит всё сразу: сайт, учётная система, резервные копии и файлы с паролями. Утекает не «сервер», а ключи ко всему остальному бизнесу.
Чем это грозит бизнесу
• Пароли и ключи с сервера окажутся у чужих: через них заходят в облако, почту, банк-клиент.
• Простой: пока меняете все доступы, сайт и сервисы могут не работать.
• Деньги и репутация: если через ваш доступ ушли данные клиентов, объясняться придётся вам, а не хостеру.
Что сделать уже сегодня
1. Выпишите, что лежит на арендованных серверах: пароли, ключи, выгрузки, документы. Всё, чему там не место, уберите.
2. Перевыпустите пароли и ключи, которые хранились на сервере, начиная с доступов к облаку и платёжным сервисам.
3. Включите двухфакторную защиту везде, где есть вход в личный кабинет хостера и облака.
4. Храните резервные копии отдельно от основного сервера, лучше у другого провайдера.
После этих шагов картина меняется: раньше один сбой у хостера означал доступ ко всему, теперь украденный пароль уже ничего не открывает, а копии остаются целыми.
Про права доступа я знаю не понаслышке
Недавно я лично вёл перенос рабочих мест 220 сотрудников одной группы компаний. После первого прогона все файлы были на месте и отчёты показывали успех, но почти половина пользователей осталась без единого права совместного доступа. Гигабайты переносятся почти всегда, а вот права почти…
· 19.10
Перевыпустите пароли и ключи, которые хранились на сервере, начиная с доступов к облаку и платёжным сервисам. - вот тут все и "ляжет" из за hardcoded значений :) (все верно пишите, это скорее про "похохмить").
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 19.10
Сергей, это правда больная тема. На практике так и выходит: пока не сделан нормальный секрет-менеджмент, любая ротация ключей превращается в quest — что-то обязательно зашито в коде или в конфиге, который никто не трогал два года. В разборе кейса как раз про это: находят пароли и ключи прямо в .env и текстовых файлах на сервере, и первая реакция «поменять ключ» часто ломает то, что на нём завязано. Поэтому ротация без переноса секретов в отдельное хранилище и без перехода на минимальные права — это тушение одного пожара с риском тут же зажечь другой.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён