3-уровневая сегментация подсетей веб-приложений в AWS VPC

Question

Я новичок в настройке AWS VPC для трехуровневого веб-приложения. Я создал VPC с подсетью 10.0.0.0/16, и какова лучшая практика для сегментации подсети в AWS VPC для трехуровневого веб-приложения? У меня есть ELB с 2 экземплярами EC2 и RDS и S3 в бэкэнде.

Пожалуйста, сообщите !! Спасибо.

Answer 1

Как мы это делаем:

Мы создаем VPC, который является / 16, например 172.20.0.0/16. Не используйте VPC по умолчанию.

Затем мы создаем набор подсетей для каждого «уровня» приложения.

• Public - Все, что с публичным IP. Балансировщики нагрузки и шлюзы NAT - это, пожалуй, единственное, что здесь есть.

• Web DMZ - сюда заходят веб-серверы. Все, что является целью для балансировщика нагрузки.

• Данные - ресурсы, отвечающие за хранение и извлечение данных. Экземпляры RDS, серверы баз данных EC2, экземпляры ElastiCacahe

• Частный - для ресурсов, которые действительно изолированы от интернет-трафика. Управление и отчетность. Вам может не понадобиться это в вашей среде.

Подсети все / 24. Одна подсеть на зону доступности. Таким образом, будет примерно 3 общедоступных подсети, 3 подсети Web DMZ и т. Д.

Сетевые ACL контролируют трафик между подсетями. Общедоступные подсети могут общаться с веб-DMZ. Веб-DMZ может общаться с данными. Подсети данных могут общаться друг с другом для облегчения кластеризации. Частные подсети ни с кем не общаются.

Я намеренно держу вещи очень грубыми в ACL сети. Я не ограничиваю конкретные порты / приложения. Мы делаем это на уровне Группы безопасности.

Совет для профессионалов: выровняйте группы подсетей на границе / 20, чтобы упростить правила сетевых списков ACL. Вместо того, чтобы перечислять каждую подсеть данных по отдельности, вы можете просто перечислить одну / 20, которая охватывает все подсети данных.

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

Answer 2

Общий шаблон, который вы найдете:

• VPC с / 16 (например, 10.0.0.0/16, который дает все 10.0.x.x адреса)
• Публичные подсети с / 24 (например, 10.0.5.0/24, который дает все 10.0.5.x адреса)
• Частные подсети с / 23 (например, 10.0.6.0/23, который дает все 10.0.6.x и 10.0.7.x) - это больше, потому что большинство ресурсов обычно уходят в частные подсети, и это неудобно чтобы увеличить его позже

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

Вместо создания 3-уровневой структуры рассмотрим 2-уровневую структуру :

• 1 x общедоступная подсеть на AZ для балансировщика нагрузки (и, возможно, бастион / переходная коробка)
• 1 x Частная подсеть на AZ для все остальное - приложение, база данных и т. Д.

Нет необходимости иметь приложения и базы данных в отдельных частных подсетях, если вы не параноик. Вы можете использовать Группы безопасности для настройки дополнительного уровня безопасности без использования отдельных подсетей. Это означает, что меньше IP-адресов теряется (например, в частично используемой подсети).

Конечно, вы могли бы просто использовать группы безопасности для всего и просто использовать один уровень, но использование частных подсетей дает дополнительный уровень гарантии того, что все настроено безопасно.