Назад | Перейти на главную страницу

Если хост NAT быть отдельным от хоста Bastion

Иметь частную сеть с серверами, которым требуется доступ по SSH. Поскольку экземпляры находятся в частной подсети, к ним нельзя получить доступ напрямую через SSH, и для доступа к ним требуется общедоступный хост Bastion.

Workstation -> via SSH -> Bastion -> via SSH Forwarding -> private subnet instnce

Мы используем NAT-хост в качестве публичного шлюза в частную сеть.

User -> via HTTP -> NAT -> via private networking -> private subnet instance

Каковы преимущества разделения хостов Bastion и NAT? Каковы преимущества их сочетания?

С технической точки зрения вы можете использовать свой NAT как хост-бастион, но с архитектурной точки зрения ты никогда не должен этого делать. И вот почему:

Ваш бастионный хост является точкой входа в вашу внутреннюю инфраструктуру, а ваш NAT обычно подключает важные службы, такие как ваша база данных, к Интернету. Так что оба должны быть максимально защищены.

Ваш хост-бастион и ваш NAT выполняют противоположные роли:

  • Хост-бастион должен позволять инициировать подключения из Интернета (из ограниченного диапазона IP-адресов) и запрещать весь инициирующий трафик в Интернет.
  • NAT должен запрещать весь исходящий трафик из Интернета и разрешать инициировать трафик из внутренней сети в Интернет.

Кроме того, хост-бастион - это просто сервер управления, поэтому обычно достаточно дешевого экземпляра, тогда как NAT должен иметь возможность потенциально маршрутизировать большой объем трафика.

Нет никакой разумной причины, по которой вы должны использовать NAT в качестве хоста-бастиона, за исключением того, что вы не заботитесь о безопасности ;-)

Хост Bastion, который вы описали, в двух словах - это хост перехода, который позволяет централизованно управлять доступом на уровнях OSI, начиная с «Networking» и затем выше. Вы можете ограничить доступ к такому единственному хосту с помощью имени пользователя и ключей, и этого будет достаточно. Вы также можете развернуть там все виды аудита / регистрации команд.

NAT означает сетевой уровень только - вы можете контролировать протоколы, IP-адреса источника и назначения (и порты), но в основном это все.

Когда мы говорим об их объединении, единственное возможное влияние может быть связано с нежелательным вмешательством между этими двумя. Наихудшие сценарии:

  • Неправильное использование NAT позволяет SSH входить в сам хост-бастион (маловероятно, почти невозможно)
  • Пользователи, которым разрешено входить в узел перехода, испортят правила NAT (теоретически возможно, но относительно легко ограничить, и мы должны помнить, что пользователи SSH являются надежными по определению - то есть это незначительное возражение)
  • Следы смешиваются. Если не разделить принудительно, вы не сможете отличить трафик локальных пользователей хоста Bastion от NAT. С должным ведением журнала проблем нет. Использование выделенных IP-адресов для среды NAT и SSH также решает эту проблему. Это не проблема, если локальным пользователям Bastion по SSH также не разрешено устанавливать исходящие соединения.