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

Почему в AWS считается, что EC2 за шлюзом NAT в частной зоне безопаснее, чем в публичной подсети?

Я уже несколько лет использую четыре сервера на AWS. Это для хобби-проекта. Все серверы находятся в одной подсети в одном VPC.

Чтобы упростить управление учетными записями и разрешениями, я решил использовать Active Directory. Это означает установку контроллера (ов) домена. В документации указано, что для использования сервисов контроллеров домена AWS контроллеры домена должны находиться в частной подсети VPC. Продолжая свое исследование частных подсетей (термин, мне незнакомый), я узнал, что EC2 в частной подсети должны находиться за шлюзом NAT - по крайней мере, это серьезная рекомендация.

Рекомендация разместить контроллеры домена в частной подсети за шлюзом NAT, очевидно, основана на предоставляемых преимуществах безопасности. Это приводит к моему вопросу: В чем именно заключаются эти преимущества безопасности?

Вот почему я спрашиваю ...

Каждый из моих существующих четырех серверов имеет частный IP-адрес и маршрутизируемый («эластичный») IP-адрес, но брандмауэр не позволяет кому-либо подключаться к последнему, если я не создаю правило безопасности, которое позволяет это. Почему это должно быть иначе для контроллеров домена? Я понимаю, что контроллеры домена будут использоваться только серверами в моей сети и никогда не будут использоваться случайными внешними сторонами в Интернете, но разве это не будет просто положением дел по умолчанию, если я не создам правило безопасности для входящего трафика, противоположное? Какой смысл разделять эти контроллеры домена в изолированной подсети с собственным шлюзом NAT? Кажется, что это добавляет сложности, но не дает реальных преимуществ. Ну предположительно там является положительный момент, и я просто не знаю, что это такое, поэтому мой вопрос.

(Я хобби, а не профессионал, поэтому, если вы считаете, что этот вопрос больше подходит для SuperUser, я удалю его и перепубликую там. Я просто подумал, поскольку он связан с сервером, этот сайт может быть более подходящим.)

Если у экземпляра есть Публичный / эластичный IP Я могу атаковать его напрямую. Возможно, вы оставили открытыми некоторые ненужные порты в группе безопасности, которые я могу использовать.

Если у него нет Публичный / эластичный IP он почти невидим для Интернета, и я не могу напрямую настроить таргетинг на него извне.

Представьте себе дом - если у него дверь прямо на улицу, безопасность вашего дома зависит от дверного замка. Однако, если он находится в секции за прочной стеной, гораздо труднее даже добраться до двери и попытаться взломать замок. Даже если вы по ошибке оставите дверь незапертой, вы все равно будете в безопасности.

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

Надеюсь, это поможет :)

Это не более безопасно, если правила брандмауэра были созданы правильно и у вас есть только один сервер. Причина, по которой вам нужен частный диапазон IP-адресов, заключается в том, что он обеспечивает безопасную связь между несколькими серверами. Возьмем, к примеру, веб-сервер и контроллер домена. Вы хотели бы, чтобы веб-сервер мог безопасно взаимодействовать с контроллером домена через частную сеть, и вы также хотели бы разрешить внешний доступ к порту 80/443. Для этого нужно просто перенаправить порт 80 и 443 напрямую на сервер www. Эта конфигурация защитит трафик контроллера домена, не открывая его для общедоступной сети.

Помимо сетевых соображений, подумайте об изоляции сервисов. В идеале AD DS + DNS + файловый сервер - единственные роли на хостах контроллеров домена. Вероятно, вам не нужен общедоступный веб-сервер в одном ящике с учетными данными в вашей сети.

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


Безопасные сети возможны с частным или публичным IP. Разница заключается в личном предпочтении того, насколько очевидным вы хотите сделать изоляцию.

Давайте посмотрим на «частную подсеть» и «за шлюзом NAT» по отдельности.

Отделение подсети администратора от подсети общедоступной сети делает очевидной границу между зонами безопасности. На первый взгляд, IP может быть внутренним или внешним. Между ними можно добавить сетевые ACL AWS или сторонний брандмауэр. (Помимо групп безопасности, связанных с экземплярами, а не подсетями.)

Шлюз NAT на самом деле не добавляет безопасности. Входящие подключения не разрешены, но это также возможно с группами безопасности.

NAT сохраняет адреса IPv4. Или IPv6 с выходным интернет-шлюзом использует нулевые адреса IPv4.