Руководство по созданию безопасной AWS VPC с нуля

Создайте безопасную AWS VPC с запланированными диапазонами CIDR, публичными и частными подсетями, таблицами маршрутизации, NAT, группами безопасности и журналами потоков.

Руководство по созданию безопасной AWS VPC с нуля

AWS VPC предоставляет вашим облачным ресурсам частную сетевую границу, но стандартная конфигурация редко подходит для продакшена. Если вы размещаете базы данных в публичных подсетях, используете пересекающиеся диапазоны CIDR или открываете широкие правила групп безопасности, вы можете создать проблемы, которые будет сложно исправить впоследствии.

Это руководство покажет вам, как создать безопасную AWS VPC с нуля, включая публичные подсети для точек входа, частные подсети для приложений и баз данных, таблицы маршрутизации, NAT, группы безопасности и базовый мониторинг.

Понимание основных концепций VPC

Прежде чем приступить к настройке, важно понять фундаментальные концепции AWS VPC:

  • VPC (Virtual Private Cloud): Виртуальная сеть, выделенная для вашего аккаунта AWS. Это логически изолированный раздел облака AWS, в котором вы можете запускать ресурсы AWS.
  • Подсеть (Subnet): Диапазон IP-адресов в вашей VPC. Вы можете запускать ресурсы AWS в созданных вами подсетях. Подсети определяются своим блоком CIDR, который является подмножеством блока CIDR VPC.
  • Таблица маршрутизации (Route Table): Набор правил, называемых маршрутами, которые используются для определения направления сетевого трафика из вашей подсети или шлюза.
  • Интернет-шлюз (IGW): Компонент VPC, который обеспечивает маршрутизацию интернет-трафика для ресурсов с публичными IP-адресами и маршрутом к шлюзу.
  • NAT-шлюз (Network Address Translation): Высокодоступный и масштабируемый сервис NAT, который обеспечивает доступ в интернет для экземпляров в частной подсети, предотвращая входящие соединения, инициированные из интернета.
  • Группа безопасности (Security Group): Действует как виртуальный брандмауэр для ваших экземпляров, контролируя входящий и исходящий трафик. Работает на уровне экземпляра.
  • Сетевой ACL (Network Access Control List): Необязательный уровень безопасности для вашей VPC, который действует как брандмауэр для контроля трафика в одной или нескольких подсетях и из них. Работает на уровне подсети.

Пошаговое создание VPC

Давайте приступим к созданию вашей безопасной VPC.

1. Планирование схемы IP-адресов

Первый и самый важный шаг — спланировать диапазон IP-адресов для VPC и ее подсетей. Это включает выбор блока Classless Inter-Domain Routing (CIDR) для вашей VPC.

  • Блок CIDR VPC: Выберите диапазон частных IP-адресов, который не пересекается с вашей локальной сетью или другими VPC AWS, к которым вы можете подключиться через VPN или Direct Connect. AWS рекомендует использовать диапазоны IP-адресов RFC 1918 (10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16). Блок CIDR может быть от /16 (65 536 IP-адресов) до /28 (16 IP-адресов).

    • Пример: 10.0.0.0/16 предоставляет большое адресное пространство для вашей VPC.
  • Блоки CIDR подсетей: Разделите блок CIDR вашей VPC на более мелкие блоки CIDR для ваших подсетей. Убедитесь, что блок CIDR каждой подсети является подмножеством блока CIDR VPC и не пересекается с другими подсетями.

    • **Пример (если VPC — 10.0.0.0/16):
      • Публичная подсеть 1: 10.0.1.0/24
      • Публичная подсеть 2: 10.0.2.0/24
      • Частная подсеть 1: 10.0.10.0/24
      • Частная подсеть 2: 10.0.11.0/24

2. Создание VPC

Перейдите на панель VPC в консоли управления AWS и создайте новую VPC.

  1. Перейдите в VPC Dashboard > Your VPCs > Create VPC.
  2. Name tag: Дайте вашей VPC описательное имя (например, MySecureVPC).
  3. IPv4 CIDR block: Введите запланированный блок CIDR (например, 10.0.0.0/16).
  4. IPv6 CIDR block: При необходимости вы можете включить блок IPv6 CIDR.
  5. Tenancy: Для большинства случаев подходит Default. Dedicated обеспечивает аппаратную изоляцию по более высокой цене.
  6. Нажмите Create VPC.

3. Создание подсетей

Теперь создайте публичные и частные подсети в вашей VPC.

  1. Перейдите в VPC Dashboard > Subnets > Create subnet.
  2. VPC ID: Выберите только что созданную VPC.
  3. Subnet name: Укажите имя (например, MyPublicSubnet-AZ1).
  4. Availability Zone: Выберите зону доступности (AZ). Рекомендуется развертывать ресурсы в нескольких AZ для обеспечения высокой доступности.
  5. IPv4 CIDR block: Введите блок CIDR для этой подсети (например, 10.0.1.0/24).
  6. Нажмите Create subnet.

Повторите этот процесс для создания всех запланированных публичных и частных подсетей, убедившись, что они находятся в разных зонах доступности для обеспечения отказоустойчивости.

4. Создание интернет-шлюза (IGW)

IGW необходим для доступа ваших публичных подсетей в интернет.

  1. Перейдите в VPC Dashboard > Internet Gateways > Create internet gateway.
  2. Name tag: MyVPCInternetGateway.
  3. Нажмите Create internet gateway.
  4. После создания выберите IGW, нажмите Actions и выберите Attach to VPC. Выберите вашу VPC и нажмите Attach internet gateway.

5. Создание таблиц маршрутизации

Таблицы маршрутизации направляют трафик внутри вашей VPC. Обычно вам понадобятся как минимум две: одна для публичных подсетей и одна для частных.

а. Публичная таблица маршрутизации:

  1. Перейдите в VPC Dashboard > Route Tables > Create route table.
  2. Name tag: MyPublicRouteTable.
  3. VPC: Выберите вашу VPC.
  4. Нажмите Create route table.
  5. Выберите только что созданную MyPublicRouteTable.
  6. На вкладке Routes нажмите Edit routes.
  7. Нажмите Add route.
  8. Destination: 0.0.0.0/0 (весь IPv4-трафик).
  9. Target: Выберите Internet Gateway и выберите ваш IGW.
  10. Нажмите Save routes.
  11. Associate Subnets: Перейдите на вкладку Subnet associations, нажмите Edit subnet associations и свяжите ваши публичные подсети с этой таблицей маршрутизации.

б. Частная таблица маршрутизации (с NAT-шлюзом):

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

  1. Создание NAT-шлюза:

    • Перейдите в VPC Dashboard > NAT Gateways > Create NAT gateway.
    • Name: MyNATGateway.
    • Subnet: Выберите одну из ваших публичных подсетей.
    • Connectivity type: Public.
    • Elastic IP allocation ID: Нажмите Allocate Elastic IP, чтобы создать и назначить новый Elastic IP-адрес.
    • Нажмите Create NAT gateway.
    • Примечание: NAT-шлюзы влекут за собой затраты. Для базового исходящего подключения убедитесь, что в вашей публичной подсети достаточно IP-адресов для NAT-шлюза..
  2. Создание частной таблицы маршрутизации:

    • Перейдите в VPC Dashboard > Route Tables > Create route table.
    • Name tag: MyPrivateRouteTable.
    • VPC: Выберите вашу VPC.
    • Нажмите Create route table.
    • Выберите MyPrivateRouteTable.
    • На вкладке Routes нажмите Edit routes.
    • Нажмите Add route.
    • Destination: 0.0.0.0/0.
    • Target: Выберите NAT Gateway и выберите ваш NAT-шлюз.
    • Нажмите Save routes.
    • Associate Subnets: Перейдите на вкладку Subnet associations, нажмите Edit subnet associations и свяжите ваши частные подсети с этой таблицей маршрутизации.

6. Настройка групп безопасности

Группы безопасности действуют как межсетевые экраны с отслеживанием состояния на уровне экземпляра. Они разрешают или запрещают трафик на основе определенных вами правил.

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

Пример: Группа безопасности для веб-сервера (WebServerSG)

  1. Перейдите в VPC Dashboard > Security Groups > Create security group.
  2. Security group name: WebServerSG.
  3. Description: Разрешить HTTP и HTTPS доступ.
  4. VPC: Выберите вашу VPC.
  5. Inbound rules:
    • Type: HTTP, Protocol: TCP, Port range: 80, Source: 0.0.0.0/0 (или более конкретный доверенный диапазон IP).
    • Type: HTTPS, Protocol: TCP, Port range: 443, Source: 0.0.0.0/0 (или более конкретный доверенный диапазон IP).
    • (Опционально) Type: SSH, Protocol: TCP, Port range: 22, Source: Ваш доверенный IP-адрес/диапазон (критически важно для управления).
  6. Outbound rules: По умолчанию разрешен весь исходящий трафик (0.0.0.0/0). При необходимости вы можете ограничить это.
  7. Нажмите Create security group.

Пример: Группа безопасности для сервера базы данных (DatabaseSG)

  1. Создайте новую группу безопасности с именем DatabaseSG.
  2. Inbound rules:
    • Добавьте правило, разрешающее трафик на порт по умолчанию вашей базы данных (например, 3306 для MySQL, 5432 для PostgreSQL) только из группы безопасности ваших серверов приложений (например, WebServerSG или AppServerSG).
    • Source: Выберите Custom, затем введите ID группы безопасности вашего сервера приложений.
  3. Outbound rules: Обычно разрешают весь исходящий трафик.

7. Настройка сетевых ACL (NACL)

Сетевые ACL — это межсетевые экраны без отслеживания состояния, которые работают на уровне подсети. Они служат дополнительным уровнем защиты.

  • Stateful vs. Stateless: Группы безопасности являются stateful (если вы разрешаете входящий трафик, исходящий ответ автоматически разрешается). NACL являются stateless (вы должны явно определить правила как для входящего, так и для исходящего трафика).

  • Лучшая практика: NACL часто оставляют с конфигурациями по умолчанию, если не требуется контроль доступа на уровне подсети. Они могут быть сложными в управлении.

Если вам нужно использовать NACL:

  1. Перейдите в VPC Dashboard > Network ACLs > Create network ACL.
  2. Name tag: MyNacl.
  3. VPC: Выберите вашу VPC.
  4. Нажмите Create network ACL.
  5. Выберите NACL и на вкладке Inbound Rules добавьте правила.
  6. Rule Numbers: NACL оценивают правила по порядку, начиная с правила с наименьшим номером. Используйте номера, такие как 100, 200, 300 и т.д., чтобы обеспечить возможность вставки правил в будущем.
  7. Allow/Deny: Укажите, разрешать или запрещать трафик.
  8. Protocol, Port Range, Source/Destination: Определите параметры трафика.
  9. Не забудьте настроить соответствующие Outbound Rules.
  10. Свяжите NACL с вашими подсетями, перейдя на вкладку Subnet Associations.

Пример сценария развертывания

Рассмотрим типичное веб-приложение:

  • VPC: 10.0.0.0/16

  • Публичная подсеть 1 (us-east-1a): 10.0.1.0/24 (Связана с MyPublicRouteTable и IGW)

  • Публичная подсеть 2 (us-east-1b): 10.0.2.0/24 (Связана с MyPublicRouteTable и IGW)

  • Частная подсеть 1 (us-east-1a): 10.0.10.0/24 (Связана с MyPrivateRouteTable и NAT-шлюзом)

  • Частная подсеть 2 (us-east-1b): 10.0.11.0/24 (Связана с MyPrivateRouteTable и NAT-шлюзом)

  • Интернет-шлюз: Подключен к VPC.

  • NAT-шлюз: Развернут в Публичной подсети 1 с Elastic IP.

  • Публичная таблица маршрутизации: Направляет 0.0.0.0/0 на IGW. Связана с публичными подсетями.

  • Частная таблица маршрутизации: Направляет 0.0.0.0/0 на NAT-шлюз. Связана с частными подсетями.

  • Группа безопасности для балансировщиков нагрузки (в публичных подсетях): Разрешает HTTP/HTTPS с 0.0.0.0/0.

  • Группа безопасности для веб-серверов (в частных подсетях): Разрешает HTTP/HTTPS из SG балансировщика нагрузки и SSH с вашего доверенного IP.

  • Группа безопасности для баз данных (в частных подсетях): Разрешает MySQL/PostgreSQL из SG веб-сервера.

Критические аспекты безопасности

  • Принцип наименьших привилегий: Предоставляйте только необходимые разрешения для ваших групп безопасности и NACL. Максимально ограничивайте исходные IP-адреса.
  • Используйте несколько зон доступности: Распределяйте подсети и ресурсы по нескольким AZ для обеспечения высокой доступности и аварийного восстановления. Это достигается созданием подсетей в разных AZ и связыванием их с соответствующими таблицами маршрутизации.
  • Регулярно проверяйте группы безопасности и NACL: По мере развития вашего приложения должны меняться и ваши правила безопасности. Периодически проводите аудит и обновляйте их.
  • Избегайте публичных подсетей для конфиденциальных ресурсов: Базы данных, серверы приложений и другие конфиденциальные ресурсы должны находиться в частных подсетях. Только ресурсы, требующие прямого доступа в интернет (например, балансировщики нагрузки или бастионные хосты), должны быть в публичных подсетях.
  • Рассмотрите бастионные хосты: Если вам нужно подключиться по SSH к экземплярам в частных подсетях, рассмотрите возможность использования защищенного бастионного хоста в публичной подсети. Ограничьте SSH-доступ к бастионному хосту известными IP-адресами.
  • Журналы потоков VPC: Включите журналы потоков VPC для сбора информации об IP-трафике, поступающем на сетевые интерфейсы в вашей VPC и исходящем от них. Это бесценно для мониторинга безопасности и устранения неполадок.
  • Сегментация сети: Используйте разные VPC и подсети для сегментации сред (например, разработка, стейджинг, продакшен) и разных уровней вашего приложения.

Заключительный вывод

Стройте VPC вокруг потока трафика: публичные подсети должны предоставлять доступ только к балансировщикам нагрузки, NAT-шлюзам или строго контролируемому бастионному доступу, в то время как ресурсы приложений и баз данных остаются частными. После запуска продолжайте проверять группы безопасности, таблицы маршрутизации и журналы потоков VPC, чтобы сеть оставалась согласованной с тем, как ваше приложение работает на самом деле.