Bastion/jump host для доступа к приватной инфраструктуре: Dedicated или VPS, static IP, SSH и firewall

Когда инфраструктура растёт, прямой SSH-доступ ко всем серверам быстро превращается в проблему. Сначала есть один VPS, потом появляется база данных, внутренний API, backup-сервер, monitoring, private network, GitLab, storage, панели управления и отдельные сервисы для команды. Если каждый сервер открыт в интернет по SSH, поверхность атаки растёт вместе с инфраструктурой.

Более аккуратный подход - использовать bastion host или jump host. Это отдельный сервер, через который администраторы подключаются к приватной инфраструктуре. Внешний доступ открыт только к bastion-серверу, а внутренние серверы принимают SSH только из приватной сети или с IP bastion host.

Для бизнеса это не модная security-схема, а простая логика: меньше открытых портов, меньше случайных входных точек, проще firewall, проще аудит и понятнее контроль доступа.

Что такое bastion host

Bastion host - это сервер-посредник для доступа к закрытой инфраструктуре. Его задача - быть единственной или основной точкой входа для администраторов, DevOps, разработчиков и технической поддержки.

Обычно схема выглядит так: у bastion-сервера есть публичный static IP, доступ по SSH и строгий firewall. Внутренние серверы находятся в private network и не принимают SSH из всего интернета. Администратор подключается к bastion host, а уже через него получает доступ к нужному private server.

Такой подход часто используют для баз данных, backend-серверов, internal API, staging, monitoring, backup-инфраструктуры, GitLab, Kubernetes-нод, VPN-шлюзов и серверов, которые не должны быть видны публично.

Зачем нужен jump host, если можно открыть SSH на каждом сервере

Открыть SSH на каждом сервере проще. Но простота здесь обманчивая. Каждый публичный SSH-порт - это отдельная точка атаки, отдельный firewall rule, отдельный набор ключей, отдельный риск забыть старого пользователя или оставить доступ после увольнения сотрудника.

Bastion host решает несколько задач сразу:

• снижает количество публично доступных SSH-портов;
• централизует доступ к приватным серверам;
• позволяет ограничить вход по static IP;
• упрощает firewall-правила;
• помогает вести аудит подключений;
• уменьшает риск случайно открыть базу данных или backend в интернет;
• даёт понятную точку контроля для команды.

Главная идея: приватные серверы не должны быть доступны всему интернету только потому, что администратору иногда нужно зайти по SSH.

Dedicated или VPS для bastion host

Bastion host можно разместить как на VPS, так и на dedicated server. Выбор зависит от масштаба инфраструктуры, требований к безопасности, количества пользователей и нагрузки.

VPS обычно достаточно, если:

• инфраструктура небольшая;
• через bastion подключается несколько администраторов;
• сервер используется только для SSH-доступа;
• нет тяжёлого VPN, proxy или туннелей с большим трафиком;
• важна низкая стоимость;
• нужен простой static IP и базовый firewall.

Dedicated server имеет смысл, если bastion host становится частью серьёзной инфраструктуры. Например, через него работает большая команда, идут VPN-туннели, нужен высокий bandwidth, отдельная приватная сеть, повышенный контроль, отдельный диск для логов или строгие требования к изоляции.

Для большинства компаний на старте достаточно VPS с хорошей сетевой доступностью и static IP. Но если jump host становится критичным элементом доступа к production, лучше смотреть на более надёжную конфигурацию и резервирование.

Static IP: почему он важен

Static IP нужен, чтобы доступ к инфраструктуре был предсказуемым. Если bastion host имеет постоянный IP-адрес, внутренние серверы могут разрешать SSH только с этого адреса. Это простое и эффективное firewall-правило.

Например, private database server не должен принимать SSH или административный доступ из всего интернета. Он может принимать подключение только из private network или только от bastion host. Тогда даже если кто-то знает IP внутреннего сервера, попасть на него напрямую не получится.

Static IP также удобен для документации, allowlist, monitoring, VPN, audit и работы команды. Не нужно каждый раз менять правила доступа из-за смены адреса.

Firewall: основа всей схемы

Без firewall bastion host превращается в обычный сервер с SSH. Правильная схема строится наоборот: сначала закрываем всё лишнее, потом открываем только нужное.

Минимальная логика firewall:

• на bastion host открыт только SSH и только с разрешённых IP, если это возможно;
• root-login по SSH отключён;
• доступ по паролю отключён, используются SSH-ключи;
• внутренние серверы принимают SSH только от bastion host;
• базы данных, Redis, internal API и панели не открываются в публичный интернет;
• все лишние порты закрыты;
• подозрительные попытки входа логируются и блокируются.

Если у команды динамические IP, можно использовать VPN перед bastion host или отдельную схему доступа. Но открывать SSH на 0.0.0.0/0 без дополнительных ограничений - слабое решение для production-инфраструктуры.

SSH-ключи и пользователи

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

Лучше использовать отдельного пользователя для каждого администратора. У каждого - свой SSH-ключ. При увольнении сотрудника или смене подрядчика удаляется конкретный ключ и конкретный пользователь, а не пересобирается вся инфраструктура.

Для production-доступа стоит использовать:

• персональные SSH-аккаунты;
• ключи вместо паролей;
• запрет прямого root-login;
• ограничение sudo-доступа;
• логирование входов;
• регулярную ревизию пользователей и ключей;
• отдельные доступы для подрядчиков с ограниченными правами.

Главная ошибка - держать на bastion host старые ключи людей, которые уже не работают с проектом. Это тихий риск, который всплывает слишком поздно.

ProxyJump: удобный способ работать через bastion

Современный OpenSSH позволяет подключаться к внутренним серверам через jump host без ручного входа на bastion. Для этого используется ProxyJump. Администратор подключается одной командой или через SSH config, а трафик проходит через bastion host.

Это удобнее и безопаснее, чем сначала заходить на bastion, а потом вручную подключаться дальше. В правильной схеме приватный ключ администратора не должен лежать на bastion-сервере. Bastion должен быть проходной точкой, а не складом ключей от всей инфраструктуры.

Для команды это сильно упрощает работу: разработчик или администратор использует привычный SSH, но инфраструктура остаётся закрытой от прямого публичного доступа.

Что не стоит хранить на bastion host

Bastion host часто ломают не из-за сложной атаки, а из-за плохой дисциплины. На нём оставляют приватные ключи, пароли от серверов, конфиги с токенами, backup-файлы, дампы баз данных и временные архивы. Так делать нельзя.

На bastion host не стоит хранить:

• приватные SSH-ключи от всей инфраструктуры;
• пароли от баз данных;
• production .env-файлы;
• дампы баз данных;
• backup-архивы;
• личные файлы администраторов;
• токены CI/CD или API-ключи;
• доступы к billing, registrar, cloud или DNS.

Bastion host должен быть максимально пустым и простым. Чем меньше на нём секретов, тем меньше ущерб при компрометации.

Нужен ли VPN перед bastion host

Для небольшой инфраструктуры можно начать с SSH по static IP и firewall allowlist. Но для более серьёзной схемы VPN перед bastion host часто даёт дополнительный уровень защиты.

Например, SSH на bastion host доступен только из VPN-сети. Пользователь сначала подключается к VPN, затем идёт на bastion, а уже потом - на private servers. Это снижает количество публичных входных точек.

Но VPN не заменяет SSH-ключи, firewall и нормальную политику пользователей. Это дополнительный слой, а не повод расслабляться.

Логирование и аудит

Если bastion host используется командой, важно понимать, кто и когда подключался. Минимум - системные SSH-логи, история входов, уведомления о подозрительных попытках и регулярная проверка пользователей.

Для более строгих требований можно добавлять session recording, централизованный сбор логов, SIEM, auditd, fail2ban, уведомления в monitoring и отдельные политики sudo. Но даже базовый аудит лучше, чем полное отсутствие следов.

Самый плохой сценарий - когда через bastion host ходят все, но никто не знает, кто реально подключался к production-серверам.

Резервирование bastion host

Один bastion host удобен, но он может стать single point of failure. Если он недоступен, команда теряет доступ к приватной инфраструктуре. Поэтому для production-среды стоит заранее подумать о резервном доступе.

Варианты:

• основной и резервный bastion host;
• VPN как дополнительный путь доступа;
• out-of-band доступ через IPMI/KVM, если речь о dedicated servers;
• документированный emergency-процесс;
• регулярная проверка резервного доступа.

Важно: резервный доступ не должен быть дырой в безопасности. Он должен быть таким же контролируемым, как основной.

Какая конфигурация нужна

Для простого bastion host не нужен мощный сервер. Если задача - только SSH-доступ, достаточно небольшого VPS с static IP, стабильной сетью, Linux, firewall и регулярными обновлениями.

Пример базовой конфигурации:

• 1-2 vCPU;
• 1-2 GB RAM;
• 20-40 GB SSD;
• static IPv4;
• Linux;
• SSH только по ключам;
• firewall allowlist;
• логирование и fail2ban.

Dedicated server нужен, если jump host выполняет не только SSH-роль, но и обслуживает VPN, туннели, large team access, monitoring, internal proxy, high traffic или строгую изоляцию для корпоративной инфраструктуры.

Что спросить у провайдера до заказа

Перед заказом VPS или dedicated server под bastion host стоит задать несколько конкретных вопросов:

• будет ли static IPv4;
• можно ли настроить private network;
• есть ли firewall на стороне провайдера;
• можно ли ограничить доступ по IP;
• есть ли DDoS-защита;
• можно ли добавить второй bastion host для резервирования;
• есть ли IPMI/KVM для dedicated server;
• можно ли подключить private VLAN между серверами;
• какая локация лучше для команды;
• кто отвечает за администрирование и hardening.

Эти вопросы важнее, чем разница в несколько долларов. Bastion host - это входная дверь в инфраструктуру. Если она настроена плохо, вся приватная сеть становится уязвимее.

Типичные ошибки

Самая частая ошибка - открыть SSH на bastion host для всего интернета и считать, что это уже безопасность. Вторая - использовать парольный вход. Третья - хранить приватные ключи на bastion. Четвёртая - давать всем общий root-доступ. Пятая - не удалять старых пользователей и ключи.

Ещё одна ошибка - открыть SSH на внутренних серверах “на всякий случай”. Если private server всё равно доступен напрямую из интернета, смысл bastion host частично теряется.

Правильная схема должна быть простой: внешний мир видит только bastion, bastion видит private servers, private servers не принимают административный доступ откуда попало.

Главный вывод

Bastion/jump host нужен, когда инфраструктура перестала быть одним сервером и появились приватные сервисы, базы данных, внутренние панели, backup-серверы и команда с разными доступами. Это простой способ уменьшить поверхность атаки и централизовать SSH-доступ.

Для небольших проектов достаточно VPS со static IP, SSH-ключами и строгим firewall. Для production-инфраструктуры, больших команд, private network, VPN и повышенных требований к доступности можно использовать dedicated server или пару bastion hosts для резервирования.

QCKL помогает подобрать VPS или dedicated server под bastion/jump host, static IP, private network, SSH-доступ, firewall и защищённый вход в приватную инфраструктуру. Можно начать с небольшого VPS для доступа к внутренним серверам, а затем построить более надёжную схему с private network, VPN и резервным bastion host.

Запросить подбор конфигурации можно на qckl.net.