Cloud Firewalls для Droplets на DigitalOcean: руководство по защите и лучшим практикам

Быстрые ссылки

• Создать Cloud Firewall
• Создание нового Droplet
• Ограничение трафика внутри VPC
• Ограничения Cloud Firewall
• Заключение

Firewalls критичны для безопасности любого сервера. Разрешая только нужный трафик к нужным ресурсам, мы уменьшаем риск эксплойтов и вредоносных атак. DigitalOcean предоставляет виртуальные машины — Droplets — и сетевой брандмауэр уровня сети с названием Cloud Firewalls. Он фильтрует и сбрасывает трафик ещё до того, как тот достигнет Droplet, что даёт преимущества по сравнению с традиционными брандмауэрами, работающими только внутри гостевой ОС.

Кратко о возможностях Cloud Firewalls:

• Состояние соединения: входящие и исходящие stateful правила
• Именованные сервисы: SSH, HTTP(S), MySQL и др.
• Произвольные порты и диапазоны портов
• Ограничения по источникам: Droplets, Load Balancers, VPC, теги, отдельные IPv4/IPv6 CIDR

DigitalOcean также поддерживает Virtual Private Cloud (VPC) — логическую сеть для группы ресурсов. Трафик внутри VPC остаётся приватным и не «утекает» в другие VPC. Cloud Firewalls работают совместно с VPC, помогая сегментировать и защищать трафик между ресурсами.

В примере ниже используются два виртуальных сервера с конфигурацией:

• OS: Ubuntu 18.04.3 LTS x64
• Стоимость: Basic VM $5/мес
• Регион: SFO2
• Аутентификация: SSH-ключи
• Теги: test, ubuntu

Создание Cloud Firewall

После создания Linux VM одной из первых задач является защита SSH — именно этот сервис чаще всего атакуют. Создадим простой firewall, который ограничит доступ по SSH только с конкретного IP.

В нашем примере это будет адрес:

192.168.100.5

При нажатии Create Firewall откроется форма с полями: Name, Inbound Rules, Outbound Rules и ресурсами, к которым применить firewall.

• Name: ssh-limit
• Inbound Rules — SSH → 192.168.100.5

Далее взглянем на Outbound Rules. Ниже отображены правила по умолчанию: весь TCP/UDP исходящий трафик разрешён во все направления, равно как ICMP. Для многих сценариев это приемлемо, но при жёстких требованиях к безопасности исходящие правила тоже можно сузить.

Наконец, применим firewall к нашим ресурсам через тег test. Почему через тег, а не через отдельный Droplet? При применении к тегу правило автоматически распространяется на все ресурсы с этим тегом. Это автоматизирует настройки и снижает риск пропуска важной конфигурации при создании новых Droplets.

После создания вы увидите, что firewall применён к Droplet и будет сбрасывать весь трафик, который не соответствует заданным правилам, ещё до достижения виртуальной машины.

Provisioning нового Droplet и автоматическое применение правила

Если вы создаёте новый Droplet и присваиваете ему тег test, уже созданный firewall автоматически применяется. Это видно в разделе Networking созданного Droplet — правило ssh-limit будет присутствовать.

Ограничение трафика внутри VPC

Если у вас на нескольких Droplets запущены базы данных MySQL и вы хотите, чтобы порт 3306 был доступен только внутри VPC, Cloud Firewall позволяет задать правило, ограниченное CIDR-диапазоном VPC. Таким образом трафик MySQL будет разрешён лишь между ресурсами внутри приватной сети.

Если вы используете Managed Databases (MySQL, PostgreSQL, Redis), подобная модель упрощает защиту: поместите все связанные ресурсы в одну VPC и управляйте доступом через Cloud Firewalls.

Ограничения Cloud Firewall

При использовании Cloud Firewalls важно учитывать продуктовые и количественные лимиты:

• Макс. 10 индивидуально добавленных Droplets к одному firewall.
• Макс. 5 тегов на один firewall; однако теги позволяют обойти лимит в 10 Droplets (например, тег с 50 Droplets будет работать).
• Максимум 50 комбинированных входящих и исходящих правил на firewall.
• Поддерживаются только ICMP, TCP и UDP.
• Логи отброшенного трафика недоступны, так как сброс происходит на сетевом уровне.

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

Практические рекомендации и лучшие практики

• Всегда защищайте SSH: либо ограничьте IP, либо используйте VPN/Jump Host, либо управляйте доступом через централизованный bastion.
• Применяйте firewall через теги для автоматизации и единообразия конфигурации.
• Для критичных сервисов комбинируйте Cloud Firewall и OS‑уровневый брандмауэр (ufw/iptables) — defence in depth.
• Проектируйте VPC по средам: prod, staging, dev — это уменьшит риск утечек между окружениями.
• Минимизируйте исходящие разрешения для контейнеров и сервисов, которые не должны инициировать внешние соединения.

Альтернативные подходы

• OS‑уровневые брандмауэры (ufw, firewalld, iptables/nftables): дают контроль на самом хосте, позволяют логировать и создавать сложные правила. Минус — требуется поддержка и может быть сложнее в масштабировании.
• VPN или частные сети: если у вас распределённые окружения, VPN может объединять ресурсы и скрывать их из публичной сети.
• Сетевые ACL на уровне облака/провайдера (если доступны): похожи по назначению, но могут иметь другой набор возможностей и ограничений.

Когда применять: Cloud Firewall удобен для централизованного и быстрого управления доступом между ресурсами DigitalOcean; OS‑уровневые брандмауэры обязательны для логирования и защиты от локально скомпрометированных процессов.

Ментальные модели и эвристики

• Модель «белого списка»: по умолчанию запретить всё, разрешать только явно нужные соединения.
• Сегментация «по роли»: каждая роль (веб‑сервер, БД, bastion) получает свой набор правил и тега.
• Принцип наименьших привилегий: правило должно покрывать минимально необходимый набор адресов/портов.

Роль‑ориентованные чек‑листы

Администратор сети:

• Проверить соответствие правил политике безопасности компании.
• Убедиться, что нет несанкционированных открытых портов.
• Настроить мониторинг доступности сервисов.

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

• Присвоить правильные теги новым Droplets.
• Протестировать доступ к сервисам после применения правил.
• Документировать ожидания работы приложения при ограниченных исходящих соединениях.

Инженер безопасности:

• Провести ревью правил и сегментации VPC.
• Тестировать обходные пути (e.g. чрезмерно широкие CIDR).
• Проверить логи приложений на предмет отказов из‑за правил.

SOP: быстрая инструкция по настройке защиты SSH через Cloud Firewall

1. Определите IP-адрес(а) администраторов, которым нужен доступ по SSH.
2. В интерфейсе Networking → Firewalls нажмите Create Firewall.
3. Укажите имя, например ssh-limit.
4. В Inbound Rules добавьте SSH и введите конкретный IPv4 CIDR (например 192.168.100.5/32) или адрес в формате без маски, если система это поддерживает.
5. Проверить и при необходимости сузить Outbound Rules.
6. Привяжите firewall к тегу test (или конкретному Droplet) и сохраните.
7. Создайте тестовый Droplet с тем же тегом, проверьте доступность SSH с разрешённого IP и блокировку с других адресов.
8. Документируйте правило и сохраняйте версию конфигурации.

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

• SSH доступ возможен только с указанных IP-адресов.
• Правило автоматически применяется к новым Droplets с тегом.
• Нет открытых портов для сервисов, которые должны быть внутрити VPC.
• После применения правил приложение функционирует без сбоев (тестовые сценарии пройдены).

Тесты и сценарии приёмки

1. Попытка подключения по SSH с разрешённого IP должна завершаться успешно.
2. Попытка подключения по SSH с запрещённого IP должна быть отклонена (со стороны клиента — тайм-аут или отказ).
3. MySQL порт 3306 доступен только для ресурсов внутри VPC и недоступен извне.
4. При создании нового Droplet с нужным тегом firewall применяется автоматически.

Примеры отказа: когда Cloud Firewall не решит задачу

• Требуется логирование и аудит каждого отклонённого пакета — Cloud Firewall не даёт таких логов для отброшенного трафика.
• Нужна поддержка протоколов, отличных от TCP/UDP/ICMP (например, GRE) — Cloud Firewall их не обрабатывает.
• Необходима детальная переадресация или NAT на уровне приложения — это решается внутри OS или балансировщика.

Усиление безопасности

• Включите двухфакторную аутентификацию для панелей управления.
• Используйте bastion host с ограниченным доступом вместо прямого доступа к VM.
• Регулярно обновляйте образы Droplet и пакеты внутри системы.
• Разделяйте права доступа: администратор сети не должен иметь учётные данные приложения.

Факто‑блок: ключевые числа и лимиты

• 10 — максимальное число индивидуально добавляемых Droplets на один firewall.
• 5 — максимальное число тегов, которые можно привязать к одному firewall.
• 50 — максимальное число правил (входящих + исходящих) на firewall.
• Поддерживаемые протоколы: TCP, UDP, ICMP.

Миграция и практические советы

• При переносе среды в DigitalOcean заранее спланируйте теги и VPC‑сегментацию.
• Используйте инфраструктурный код (Terraform, Ansible) для хранения и воспроизведения настроек firewall.
• Тестируйте правила в staging перед применением в production.

Заключение

Cloud Firewalls — удобный инструмент для центрального управления сетевой безопасностью Droplets. Комбинация VPC и правил по тегам даёт простой механизм для автоматического применения конфигураций и сегментации окружений. Однако для полного покрытия безопасности рекомендуется использовать принцип defence in depth: сетевой firewall + OS‑уровневый брандмауэр + процессы обновления и мониторинга.

Важно: выбирая стратегию, учитывайте ограничения продукта (лимиты объектов, отсутствие логов отброшенного трафика и список поддерживаемых протоколов). Документируйте правила, автоматизируйте применение через теги и инфраструктурный код, и регулярно тестируйте сценарии доступа.

Краткая контрольная сводка:

• Защитите SSH первым.
• Применяйте правило через теги.
• Используйте VPC для приватного трафика баз данных.
• Дополняйте Cloud Firewall локальными средствами и мониторингом.