Миф: свой сервер безопаснее облака

MAATRIX

«У меня свой сервер, а не чужое облако — значит, я сам решаю, кто и как к нему подключается, и никакой провайдер не сольёт мои данные третьим лицам». Логика понятна и отчасти верна. Но из неё часто делают следующий шаг: «раз сервер мой — он автоматически безопаснее». А вот это уже не логика, а самоуспокоение, и именно оно приводит к взломам.

Откуда берётся миф и в чём его рациональное зерно

Миф не на пустом месте. У «своего» сервера действительно есть реальные преимущества, которые нельзя списывать со счетов:

• Меньше юрисдикционных рисков. Данные не проходят через инфраструктуру стороннего облачного гиганта с его политиками доступа, возможными запросами от третьих лиц и условиями использования, которые вы не контролируете.
• Нет риска «утечки у соседа». В мультитенантном облаке теоретически возможны side-channel атаки между виртуальными машинами одного физического хоста (той же спекулятивной атаки класса Spectre/Meltdown в 2018 году боялись именно поэтому). На выделенном железе, которое использует только один клиент, этого вектора нет физически.
• Полный контроль над конфигурацией. Никто не меняет политики безопасности «сверху», не отключает функцию без предупреждения, не обновляет гипервизор в неудобное вам время.
• Прозрачность. Вы точно знаете, что стоит на сервере, какие логи собираются и куда они уходят — просто потому что настраивали это сами.

Более широкий разбор того, чем выделенное железо принципиально отличается от облачной инфраструктуры, — в статье «Облако против своего железа».

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

Что на самом деле определяет безопасность сервера

Безопасность — это не свойство места, а свойство процесса. Формула простая: безопасность = f(вложенные усилия в настройку и поддержку), а не f(кому физически принадлежит железо).

Один и тот же Ubuntu-сервер может быть:

• взломан за первую неделю через дефолтный SSH-порт с паролём admin123;
• или простоять годы без единого инцидента, потому что на нём настроен вход только по ключу, fail2ban, минимальный набор открытых портов и регулярные обновления.

Физически это один и тот же выделенный сервер. Разница целиком в том, что с ним сделал человек, который его администрирует. Отсюда прямой вывод: вопрос «облако или свой сервер безопаснее» сформулирован некорректно. Правильный вопрос — «кто и как будет поддерживать безопасность в каждом из вариантов». У облачного провайдера это делает штат специалистов на зарплате, у своего сервера — либо вы сами, либо никто.

Ресурсы провайдера против ресурсов одного админа

Крупные провайдеры вкладывают в безопасность инфраструктуры ресурсы, которые физически недоступны одному человеку, администрирующему свой VPS или выделенный сервер в свободное от основной работы время. Дело не в маркетинге, а в экономике масштаба: расходы на защиту делятся на тысячи клиентов, поэтому на каждого выходит немного, а суммарный бюджет — огромный.

Важный нюанс — это ровно то, что называют моделью разделённой ответственности (shared responsibility model): провайдер отвечает за инфраструктуру «под» сервером (питание, сеть, физическую защиту, гипервизор), а вот всё, что происходит внутри операционной системы — обновления, конфигурация, права доступа, — это зона ответственности клиента в обоих случаях, что в облаке, что на своём железе. Разница лишь в том, что при аренде VPS или выделенного сервера у вменяемого провайдера первый слой закрыт качественно и без вашего участия, а при по-настоящему «своём» железе (собственная стойка, свой дата-центр) вам приходится закрывать оба слоя самостоятельно.

Где реально проседает самостоятельно администрируемый сервер

Это не теория — это набор конкретных вещей, которые встречаются на подавляющем большинстве серверов, за которыми следит один человек без выделенного времени на security:

• Несвоевременные обновления безопасности. apt list --upgradable месяцами показывает пакеты с известными CVE, потому что «сейчас не время, потом накачу». Тем временем эксплойт для конкретной CVE уже публичный.
• Слабая аутентификация. Пароль вместо ключа, один и тот же ключ на десяти серверах без парольной фразы, root-логин по SSH не отключён.
• Лишние открытые порты. Поднялся для теста Redis или Elasticsearch без пароля и биндинга на localhost — и забыли закрыть. Именно так массово находят и грабят базы через 0.0.0.0:6379 или 0.0.0.0:9200.
• Отсутствие мониторинга вторжений. Без fail2ban, crowdsec или хотя бы разбора /var/log/auth.log попытки подбора пароля или брутфорса просто не видны — сервер может быть скомпрометирован неделями, а владелец узнает по счёту за исходящий трафик от майнера или спам-бота.
• Единая точка отказа для бэкапов. Бэкап лежит на том же сервере или в той же локальной сети — при взломе или сбое диска теряется всё сразу.
• Нет процесса реагирования. В облаке крупный провайдер часто сам присылает алерт при аномальном трафике или подозрительной активности аккаунта. На «своём» сервере без настроенного мониторинга первым индикатором взлома нередко становится жалоба хостера на абузу или полная неработоспособность сервиса.

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

Пример: когда вера в миф обходится дорого

Частый сценарий выглядит так. Администратор разворачивает выделенный сервер для проекта, настраивает его один раз, всё работает — и на этом внимание к безопасности заканчивается. Логика в голове звучит примерно так: «это не Amazon и не крупный банк, кому я вообще нужен, у меня свой маленький сервер, никто целенаправленно в меня не полезет».

Ошибка в этой мысли — предположение, что атаки бывают только целенаправленными. В реальности абсолютное большинство компрометаций — это не «хакер выбрал именно вас», а автоматическое сканирование целых диапазонов IP-адресов ботами, которые ищут конкретную уязвимую версию сервиса, открытый порт без аутентификации или дефолтные учётные данные. Ботам всё равно, чей это сервер и зачем он нужен — им важен только положительный результат сканирования.

Дальше события развиваются по накатанной схеме: сервер месяцами не обновляется («работает же, зачем трогать»), на нём висит открытый наружу порт панели управления или базы данных без пароля, оставленный «на время теста». Автоматический сканер находит уязвимую версию сервиса или открытый без аутентификации порт, эксплуатирует известную дыру, для которой патч вышел давно, — и на сервере оказывается майнер, шифровальщик или узел ботнета. Обнаруживается это не по алерту (его никто не настраивал), а по жалобе от дата-центра на абузу, аномальной нагрузке на CPU или внезапно возросшему трафику. Разбор похожего случая по шагам — в статье «Сервер взломали через забытый порт: реконструкция».

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

Как сделать «своё» реально безопасным

Раз безопасность — функция от усилий, а не от места, вот минимальный набор, который закрывает основную массу реальных инцидентов и не требует отдельного специалиста в штате:

1. Вход только по SSH-ключу, без пароля.

# на сервере, в /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no

После правки — systemctl restart sshd, и обязательно проверьте вход в отдельной сессии, не закрывая текущую.

1. Автоматические обновления безопасности. На Debian/Ubuntu:

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

Это закрывает большинство известных уязвимостей без ручного вмешательства — именно тот пункт, который чаще всего игнорируют «потому что руки не доходят».

1. Минимальный набор открытых портов.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Всё, что не должно быть доступно из интернета (базы данных, панели администрирования, Redis, Elasticsearch), либо биндится на 127.0.0.1, либо закрывается firewall и доступно только через VPN или SSH-туннель.

1. Защита от перебора. fail2ban с базовым jail на sshd — блокирует IP после нескольких неудачных попыток входа, что снимает основную массу автоматического брутфорса.

1. Мониторинг и алерты. Даже простой Uptime Kuma или healthchecks.io, присылающий уведомление при недоступности сервиса или подозрительном всплеске нагрузки, закрывает главный пробел «своего» сервера — отсутствие штата, который заметит проблему за вас.

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

Это не исчерпывающий список — полный порядок действий для нового сервера расписан в чек-листе безопасности нового сервера и в статье про автообновления безопасности, но именно эти шесть пунктов закрывают процентов восемьдесят реальных инцидентов на выделенных серверах и VPS. Дальше можно наращивать: двухфакторную аутентификацию для SSH, централизованный сбор логов, регулярный аудит открытых портов извне через nmap с внешнего хоста.

Частые вопросы