Создание Security Group и Network ACL в VPC (AWS)

К чему служат Security Group и Network ACL

Security Group (SG) — фильтр трафика на уровне экземпляра (instance). Это stateful-брандмауэр: если вы разрешили входящий трафик, то ответный исходящий трафик для этой сессии будет автоматически разрешён.

Network Access Control List (NACL) — опциональный статeless‑фильтр на уровне подсети (subnet). NACL применяет правила отдельно для входящего и исходящего трафика и оценивает их в порядке возрастания номера правила.

Важно: SG применяются к экземплярам только если вы их явно указали, а NACL автоматически применяется ко всем экземплярам в ассоциированной подсети.

Краткое сравнение

• Уровень применения: SG — экземпляр, NACL — подсеть.
• Поведение правил: SG — только Allow, stateful; NACL — Allow и Deny, stateless.
• Обработка правил: SG — оценивает все правила (в сумме), NACL — по порядку числа правил (приоритет номера ниже — выше приоритет).
• Автоматическое применение: SG — настраивается при запуске, NACL — действует на все ресурсы в подсети.

Когда использовать какое решение

• Используйте Security Group, чтобы управлять доступом к конкретным экземплярам (например, разрешить SSH только с определённых IP).
• Используйте NACL, чтобы наложить глобальные ограничения на подсеть (например, запретить весь входящий трафик к подсети разработки из интернета).
• Комбинируйте оба: SG даёт тонкое управление на уровне инстанса, NACL — защитный щит на уровне сети.

Когда комбинация не подходит

• Если вам нужно сложное HTTP/HTTPS‑правило на уровне приложения — рассмотрите AWS WAF или прокси‑уровень.
• Если требуются политики на уровне пользователя или ролей — используйте IAM.

Примечание: NACL не заменяет мониторинг и логирование. Для аудита включайте VPC Flow Logs и интегрируйте с SIEM.

Факто́вая справка

• SG привязан к ENI (Elastic Network Interface) экземпляра.
• NACL — применим к подсетям и всегда имеет правило по умолчанию: Allow для всех или Deny, зависит от настройки VPC.
• Номера правил NACL: меньший номер = выше приоритет.

Предварительные требования

1. У вас есть аккаунт AWS и права на создание VPC/SG/NACL.

Что мы сделаем

1. Войдём в AWS Management Console.
2. Создадим Security Group.
3. Создадим Network ACL и проверим правила.

Вход в AWS

1. Перейдите по ссылке на страницу входа в AWS.

После входа откроется главная консоль AWS с перечнем сервисов.

Создание Security Group

1. Нажмите «Service» в верхнем меню, найдите «VPC» и откройте сервис VPC.

2. На панели VPC выберите «Security Groups» в левой навигации.

3. Нажмите «Create security group».

4. Задайте понятное имя и описание, чтобы коллегам было ясно, для чего эта группа.

5. После создания кликните по ID Security Group, чтобы открыть её и добавить правила.

6. Внизу вкладки нажмите «Inbound Rules» → «Edit rules» и добавьте нужные правила. В поле Source можно указать My IP, Custom или Anywhere в зависимости от требуемого источника.

7. Аналогично добавьте Outbound Rules при необходимости.

Совет: начинайте с максимально ограничительных правил и расширяйте по мере необходимости.

Создание Network Access Control List

1. В VPC выберите «Network ACLs» в левой панели.

2. Нажмите «Create» и укажите имя NACL и VPC, к которому он будет применён.

3. Выберите созданный NACL и откройте «Inbound Rules» внизу экрана.

4. Добавляйте правила с номером приоритета. Низкий номер = высокий приоритет. Например, правило с Priority 1 и Deny для порта 22 перекроет последующие Allow‑правила для тех же IP.

5. По аналогии настройте Outbound Rules.

Важно: NACL stateless — если вы разрешаете входящий трафик, не забудьте добавить соответствующее исходящее правило.

Мини‑методология: как безопасно настроить SG и NACL

1. План: опишите цели для каждой подсети и экземпляра.
2. Политики: примените принцип наименьших привилегий (least privilege).
3. Тестирование: настраивайте в тестовой среде и используйте VPC Flow Logs для валидации.
4. Документирование: добавляйте описания к каждому правилу.
5. Ревью: проводите регулярные ревью правил и удаляйте неиспользуемые.

Чек‑лист перед применением в продакшн

• Есть резервная схема доступа для администратора (например, VPN или bastion host).
• Описания в правилах понятны и включают дату/инициатора.
• Настроены VPC Flow Logs.
• Настроен мониторинг и оповещения (CloudWatch, GuardDuty).
• Проведено тестирование с разных источников.

Ролевые рекомендации

Админ/DevOps:

• Применяйте Security Group на уровне приложения и базы данных.
• Используйте NACL для изоляции сетей разработки и тестирования.

SecOps:

• Настройте логирование, мониторинг, автоматические проверки конфигураций (AWS Config).
• Проводите периодические аудиты правил.

Разработчик:

• Просите минимально необходимые порты/диапазоны.
• Пишите короткие описания причины доступа при запросе правил.

Decision flow — как выбрать между SG и NACL

flowchart TD
  A[Нужно ограничить доступ к конкретному экземпляру?] -->|Да| B[Использовать Security Group]
  A -->|Нет| C[Нужно ограничить подсеть целиком?]
  C -->|Да| D[Использовать NACL]
  C -->|Нет| E[Рассмотрите WAF/Proxy/IAM]
  B --> F[Добавить строгие inbound/egress правила]
  D --> G[Установить номера правил и тестировать]

Типичные ошибки и как их избежать

• Ошибка: разрешили Anywhere (0.0.0.0/0) для SSH или админ‑портов.
  Митигатор: используйте My IP, VPN, или ограниченные диапазоны.

• Ошибка: забыли добавить исходящие правила в NACL (stateless).
  Митигатор: всегда дублируйте парные правила для входа и выхода.

• Ошибка: смешение целей (использование NACL вместо SG для тонкой фильтрации).
  Митигатор: держите границы ответственности — SG для инстансов, NACL для подсетей.

Матрица рисков и меры

• Неправильный Allow SSH из интернета — Высокий риск. Меры: лимит по IP, MFA, bastion.
• Отсутствие логирования — Средний риск. Меры: включить VPC Flow Logs и интегрировать в SIEM.
• Перепутаны номера правил NACL — Средний риск. Меры: документировать и использовать очевидные шаги (10,20,30).

Критерии приёмки

• Доступ только к нужным портам и источникам.
• Документация правил присутствует и утверждена.
• Логи показывают ожидаемый трафик после изменения.
• Не обнаружено регрессий в доступе для сервисов.

Рекомендации по безопасности (жёсткая конфигурация)

• Принцип «разрешить только необходимое».
• Минимизируйте число публичных правил.
• Используйте ограничительные исходящие правила, где это возможно.
• Включите мониторинг, оповещения и аудит правил.

Совместимость и миграция

• При миграции VM между подсетями проверьте, какие NACL и SG применяются к новой подсети.
• Тестируйте изменения в стейдж‑окружении перед продакшном.

Краткая галерея ошибок (edge cases)

• Наличие overlapping SG с разными разрешениями — итоговый эффект суммируется.
• NACL с Deny‑правилом и большим числом правил может неожиданно блокировать трафик.

1‑строчный глоссарий

• Security Group — stateful-фильтр трафика для экземпляра.
• NACL — stateless-фильтр трафика для подсети.
• VPC Flow Logs — журнал сетевого трафика для VPC.

Заключение

Создание SG и NACL в AWS — простой процесс, но требующий дисциплины: документируйте правила, следуйте принципу наименьших привилегий, включайте логирование и тестируйте изменения. Security Group даёт гибкий контроль на уровне инстанса, а NACL — защиту на уровне подсети; вместе они формируют многоуровневую сетевую защиту.

Важно: особенно внимательно подходите к NACL — порядок правил здесь критичен.

Сводка действий: планируйте, создавайте, документируйте, тестируйте, мониторьте.