Выбор между SSH-ключами, VPN и Bastion Host — это не выбор “что удобнее по привычке”, а выбор модели доступа к облачному серверу.
Если доступ нужен к одной-двум VM, сеть простая, а риски контролируются жёсткими правилами и ограничением входа, прямой SSH по ключам может оставаться нормальным вариантом.
Если нужен доступ не к одному серверу, а ко всему внутреннему сегменту, обычно логичнее смотреть в сторону VPN. Он даёт вход в приватный контур целиком, а не только в одну точку.
Если же рабочие VM не должны светиться наружу, давать доступ ко всему контуру не очень хочется и нужен контролируемый шлюз во внутреннюю сеть, появляется логика для Bastion Host.
Если упростить выбор, ориентир такой:
| Подход | Когда обычно подходит |
| SSH-ключи | Небольшое окружение, 1–2 VM, прямой доступ под жёстким контролем |
| VPN | Нужен доступ ко всему приватному сегменту, а не только к одному серверу |
| Bastion Host | Рабочие VM лучше скрыть, а вход собрать в одну контролируемую точку |
Выбирать здесь нужно не “любимый инструмент”, а способ доступа, который соответствует масштабу инфраструктуры, устройству сети и уровню риска.
С чего вообще начинать выбор способа доступа
Выбор доступа к облачному серверу лучше начинать не с привычного инструмента, а с более простого вопроса: к чему именно нужен доступ и через какую сеть он должен идти.
Одно дело — одна-две VM с понятным кругом администраторов. Другое — приватный сегмент, несколько внутренних сервисов, jump-сервер, рабочие машины без публичных IP и требования к более жёсткому контролю.
Из-за этого SSH-ключи, VPN и Bastion Host — это не три взаимозаменяемые кнопки. Они решают разные задачи на разных уровнях.
Почему выбирать нужно не по привычке, а по уровню риска и устройству сети
Самая частая ошибка здесь — выбирать доступ “как раньше делали”.
Например, команда по привычке открывает SSH наружу и работает только по ключам, хотя инфраструктура уже выросла и рабочие VM давно стоило бы убрать из публичного доступа. Или наоборот — сразу тянут VPN туда, где нужен доступ буквально к одному серверу и паре администраторов.
На практике полезнее смотреть на несколько простых вещей:
- Нужен доступ к одной VM или ко всему внутреннему сегменту;
- Есть ли у рабочих машин публичные IP;
- Сколько у вас администраторов и как часто они подключаются;
- Нужно ли собирать вход в одну контролируемую точку;
- Насколько критично уменьшить внешний периметр и убрать прямой доступ из интернета.
Это хорошо видно на простом примере.
Представим небольшую платформу для продажи мерча: у неё есть сайт, внутренняя панель для менеджеров, база, пара служебных VM и отдельный сервер для фоновых задач.
Если инженерам иногда нужно зайти только на один внешний Linux-сервер, то под жёсткими firewall-правилами с доступом по ключам (или пароль+ ключ для базового MFA), прямой SSH ещё может быть нормальным вариантом. Если команде нужен доступ сразу к нескольким внутренним сервисам и приватным VM, логичнее становится VPN. Если же рабочие машины вообще не должны иметь внешний адрес, а вход хочется собрать в одну точку с более понятным контролем, появляется логика для Bastion Host.
То есть порядок здесь довольно простой: сначала вы понимаете, какую модель доступа требует сама сеть, а уже потом выбираете инструмент под неё.
После этого уже можно спокойно разбирать каждый вариант по отдельности — не как “три технологии вообще”, а как ответ на конкретный сценарий доступа.
SSH-ключи: когда прямой доступ остаётся нормальным вариантом
SSH-ключи сами по себе не решают вопрос сетевой архитектуры, но в небольших и понятных сценариях прямой доступ по SSH всё ещё может быть вполне нормальным вариантом.
Это особенно заметно там, где у команды немного серверов, круг администраторов ограничен, а вход снаружи жёстко ограничен firewall с доступом только с определенных IP, применяется отключение парольного входа и другие базовые меры.
Проще говоря, SSH-ключи хорошо работают не “вместо всей модели доступа”, а в ситуации, где сама схема ещё остаётся простой.
Ниже — короткий ориентир, когда такой вариант обычно уместен:
| Сценарий | Почему прямой SSH ещё выглядит нормально |
| 1–2 внешние VM | Нет смысла строить отдельный VPN или bastion ради пары машин |
| Небольшая команда | Проще контролировать, кто и откуда подключается |
| Временные или тестовые серверы | Нужен быстрый и понятный вход без лишней инфраструктуры |
| Администрирование одного публичного хоста | Прямой доступ проще, если он хорошо ограничен по сети |
Из этого и выходит главный принцип: SSH-ключи хороши там, где доступ остаётся точечным и не разрастается в отдельный контур.
Это особенно заметно в небольшом окружении, где у команды всего одна-две внешние Linux-VM, ограниченный круг администраторов, отключён парольный вход, а доступ разрешён только с известного набора IP-адресов. В такой схеме прямой SSH по ключам часто остаётся самым простым и здравым вариантом.
Но у такого подхода довольно быстро появляется предел удобства. Как только серверов становится больше, появляются private VM, внутренние панели, базы без внешнего IP или желание вообще убрать рабочие машины из публичного доступа, прямой SSH уже начинает выглядеть слишком грубым решением. В этот момент вопрос смещается: нужен не просто вход на одну машину, а доступ ко всему внутреннему контуру или хотя бы к его контролируемой точке. Именно здесь дальше и появляется логика для VPN и Bastion Host.
VPN: когда нужен вход не к одному серверу, а во внутренний контур
VPN появляется в тот момент, когда команде уже мало просто зайти на одну конкретную машину.
Если инженерам нужен доступ сразу к нескольким private VM, внутренним панелям, базам, служебным API или другим ресурсам внутри облачной сети, логика меняется. Здесь удобнее не открывать отдельный внешний вход на каждый сервер, а сначала подключать администратора к самому приватному контуру.
Именно в этом и состоит главный смысл VPN.
Он даёт не точечный вход на один хост, а доступ внутрь сети, после которого инженер уже работает с нужными ресурсами так, будто находится внутри этого сегмента.
Ниже — короткий ориентир, когда такой вариант обычно выглядит уместно:
| Сценарий | Почему VPN подходит |
| Несколько private VM | Не нужно открывать отдельный внешний доступ на каждую машину |
| Доступ к внутренним сервисам и панелям | Инженер заходит сразу во весь нужный контур |
| Гибридная сеть | Удобно связать облако с офисом или on-premises окружением |
| Постоянная работа команды с внутренними ресурсами | Модель доступа становится более целостной и предсказуемой |
Из этого и выходит главный принцип: VPN хорош там, где нужен вход не в одну точку, а в сам внутренний периметр.
Это можно представить довольно просто.
Если команде нужно администрировать не только один Linux-сервер, а ещё внутреннюю базу, панель мониторинга, закрытый API и пару служебных VM без публичных IP, прямой SSH уже начинает расползаться в неудобную схему. VPN в такой ситуации собирает доступ в более понятную модель: сначала вход в приватную сеть, потом работа с нужными ресурсами внутри неё.
Но и у этого подхода есть граница.
VPN хорошо подходит, когда действительно нужен доступ к сегменту целиком. Если же задача уже не в том, чтобы пустить инженера во внутреннюю сеть, а в том, чтобы дать более узкий и контролируемый вход к private VM через одну точку, логика начинает смещаться в сторону bastion host.
Bastion Host: когда доступ лучше собирать в одну точку
Bastion Host нужен в тот момент, когда рабочие VM уже не хочется светить наружу, в периметр при помощи VPN пускать тоже нежелательно, но к хостам всё ещё нужен удалённый административный доступ.
В такой схеме внешним остаётся не каждый сервер по отдельности, а одна контролируемая точка входа. Сначала инженер подключается к bastion host, а уже через него — к нужной private VM по внутреннему адресу.
Главная ценность такого подхода не в “особом способе зайти по SSH”, а в том, что доступ становится более собранным и управляемым.
Вместо множества рабочих машин с отдельным входом снаружи у команды появляется один шлюз, через который проходит административный доступ. Это особенно полезно, если инфраструктура уже выросла, во внутреннем сегменте несколько private VM, а прямой доступ к ним из интернета выглядит слишком грубо. Вариант с VPN же не подходит из-за отсутствия должного контроля, или есть требования определенные требования к аудиту действий администраторов от регулятора.
Ниже — короткий ориентир, когда bastion host обычно выглядит уместно:
| Сценарий | Почему bastion host подходит |
| Private VM без внешних IP | Доступ можно дать без прямого выхода серверов в интернет |
| Несколько внутренних машин | Удобнее собрать вход в одну точку, чем открывать доступ к каждой VM |
| Более жёсткий контроль доступа | Проще ограничивать и наблюдать административный вход |
| Сегментированная сеть | Bastion становится понятным шлюзом в нужный контур |
Из этого и выходит главный принцип: bastion host хорош там, где нужно не просто подключиться к серверу, а централизовать и сузить сам вход во внутреннюю инфраструктуру.
Но и у него есть граница.
Если инженерам нужен не шлюз к нескольким private VM, а постоянный доступ ко всему приватному сегменту, VPN часто оказывается логичнее. А если инфраструктура очень маленькая и речь идёт буквально о паре машин под жёстким сетевым контролем, bastion host может стать лишним слоем по сравнению с прямым SSH.
Как не ошибиться с выбором на практике
Чем отличаются три основных подхода
Теперь полезно свести все три подхода в одну картину и посмотреть, чем они отличаются на практике.
Внимание на таблицу:
| Подход | Главная идея | Обычно подходит | Когда может быть плохой идеей |
| SSH-ключи | Прямой вход на конкретную VM | Небольшое окружение, 1–2 внешние машины, ограниченный круг админов | Когда private VM много и прямой доступ начинает расползаться |
| VPN | Вход во внутренний сегмент целиком | Несколько private VM, внутренние сервисы, гибридная сеть, постоянная работа внутри контура | Когда нужен доступ не ко всему сегменту, а только к одной-двум точкам |
| Bastion Host | Одна контролируемая точка входа к private VM | Сегментированная сеть, внутренние VM без внешних IP, более жёсткий контроль | Когда инфраструктура слишком маленькая или, наоборот, нужен полноценный сетевой доступ, а не jump-точка |
Из этой таблицы полезно вынести простую мысль: выбор здесь почти никогда не сводится к вопросу “что безопаснее вообще”.
Гораздо полезнее спрашивать другое: куда именно должен попадать инженер после подключения.
Если ему нужен вход на одну конкретную машину, это одна модель. Нужен доступ во внутреннюю сеть? Это уже другая. Ну а если необходим узкий шлюз к private VM, логика будет третьей.
Как подобрать модель доступа под свою инфраструктуру
Сначала стоит понять, сколько у вас реально точек доступа и что из этого должно быть видно снаружи.
Если у вас одна-две внешние VM, немного администраторов и понятные сетевые ограничения, прямой SSH по ключам может быть достаточно здравым стартом. Если инженеры постоянно работают с несколькими внутренними ресурсами, приватными машинами и служебными панелями, удобнее становится VPN. Если же рабочие VM вообще не должны иметь внешний доступ, а вход хочется собрать в одну точку, появляется логика для bastion host.
Потом полезно посмотреть на масштаб и частоту использования.
Для редкого доступа к одной машине строить полноценный VPN-контур бывает избыточно. Но если команда каждый день работает с внутренней сетью, прямой SSH к отдельным узлам быстро превращается в неудобную и плохо управляемую схему.
Отдельно стоит оценить и уровень контроля, который вам нужен.
Если задача — просто безопасно зайти на один сервер, хватит одной модели. Если нужно сузить внешний периметр, убрать публичные IP у рабочих VM, централизовать вход или отделить админский доступ от обычной сетевой связности, выбор уже будет другим. Google для SSH отдельно рекомендует ограничивать сетевой доступ, а bastion-подход как раз строится вокруг идеи не открывать рабочие VM наружу.
Если упростить до короткого ориентира, он выглядит так:
- SSH-ключи — когда нужен точечный доступ к небольшому числу машин;
- VPN — когда нужен вход во внутренний контур целиком;
- Bastion Host — когда нужен узкий и контролируемый шлюз к private VM.
Главное практическое правило здесь простое: выбирайте не “самый модный” способ доступа, а тот, который соответствует масштабу сети и тому, как именно инженеры работают с инфраструктурой.
Заключение
SSH-ключи, VPN и Bastion Host — это не конкуренты “на одну роль”, а три разных модели доступа.
Одна лучше подходит для точечного входа на небольшое число машин. Другая — для работы внутри приватного сегмента. Третья — для контролируемого доступа к private VM через отдельную точку входа. Поэтому хороший выбор здесь начинается не с любимого инструмента команды, а с понимания самой сети и того, что именно должно быть доступно извне.
Если нужен короткий практический вывод, он такой:
- Не тяните VPN туда, где хватает точечного доступа;
- Не держите прямой SSH наружу дольше, чем это реально оправдано;
- Не ставьте bastion host просто “потому что так солиднее”;
- Сначала определите, нужен ли вход на одну VM, во весь сегмент или в одну контролируемую точку;
- Потом уже выбирайте конкретную схему.
А компании с повышенными требованиями к безопасности могут комбинировать все подходы. Например, доступ к Bastion Host только через VPN, а доступ к конкретным VM c него - по личным SSH-ключам.
Именно в таком порядке доступ к облачному серверу перестаёт быть набором привычек и становится нормальным архитектурным решением.
FAQ
SSH-ключи и Bastion Host — это одно и то же?
Нет. SSH-ключи — это способ аутентификации и входа, а bastion host — это отдельная точка доступа к private VM. Через bastion тоже можно входить по SSH-ключам, но это уже другая модель сетевого доступа.
Если у меня всего одна VM, VPN уже лишний?
Во многих случаях да. Если доступ нужен к одной машине, а вход хорошо ограничен по сети, прямой SSH по ключам часто проще и уместнее. VPN обычно начинает оправдываться, когда нужен доступ не к одному серверу, а ко всему внутреннему сегменту.
Bastion Host безопаснее VPN?
Не “вообще”, а в своей задаче. Bastion хорош как узкая контролируемая точка входа к private VM. VPN хорош там, где нужен доступ ко всей внутренней сети. Это разные модели, и сравнивать их полезнее не по абстрактной безопасности, а по тому, какой доступ реально нужен.
Можно ли обойтись без публичных IP на рабочих VM?
Да. Именно под это часто и выбирают VPN - или bastion host, включая managed-бастионные решения.
SSH-ключи сами по себе уже решают проблему безопасности доступа?
Нет. Они важны, но без сетевых ограничений, контроля источников доступа и нормальной модели входа этого недостаточно.
Что выбрать для private VM небольшой команды?
Если нужен доступ к нескольким private VM через одну точку, обычно логичен bastion host. Если команде нужен доступ ко всему внутреннему сегменту и другим сервисам внутри сети, чаще уместнее VPN.
Список источников
1. Google Cloud — SSH best practices: Control network access
2. AWS — What is AWS Client VPN?
3. Google Cloud — Connect to Linux VMs using a bastion host
