Должен ли узел 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? Каковы преимущества их объединения?

Источник

1 ответ

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

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

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

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

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

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

Источник

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

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

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

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