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

Но ограничить трафик на уровне всего — не всегда подходящее решение. Бывает, нужно обеспечить контроль на уровне сетевого интерфейса конкретного инстанса, то есть виртуальной машины. Например, чтобы закрыть все порты, кроме 80, если у вас на нем работает публичный веб-сервис на nginx. Тогда на сцену выходят группы безопасности, они же — Security groups.

В этой статье мы рассмотрим, что такое группы безопасности и как они работают в теории и на практике. Подробности под катом! 

Что такое группы безопасности

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

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

Особенности решения

• Можно использовать вместе с файрволом. Такая комбинация позволит бесплатно обезопасить сетевой контур вашего проекта как на уровне подсети, так и отдельных инстансов внутри нее.

• Решение не подходит для защиты от DDoS. Так как группы безопасности работают на уровне сетевых правил для отдельных инстансов/интерфейсов, они не рассчитаны на массовые распределенные потоки, не масштабируются для больших объемов трафика и не могут отличить легитимный от атакующего трафика в таких условиях. Поэтому для защиты от DDoS необходимо использовать дополнительные услуги.

Security Center

Рассказываем о лучших практиках и средствах ИБ, требованиях и изменениях в законодательстве.

Исследовать →

Сценарии использования групп безопасности

Общая архитектура доступа к сервисам

Представьте стандартную трехуровневую архитектуру: публичный фронтенд, бизнес‑логика и база данных. Для фронтенда обычно достаточно разрешить 80/443 из интернета и SSH только с админского IP. Бэкенд и БД находятся в приватных подсетях и принимают трафик только от балансировщика или от группы фронтенда. Так вы явно фиксируете, кто с кем может говорить, и любое изменение можно внести моментально. Добавил правило — и доступ появился; убрал — закрыл старую дыру.

Главная ошибка в таких конфигурациях — открыть SSH на 0.0.0.0/0 «чтобы не заморачиваться», или дублировать правила в разных группах, из‑за чего потом теряется контроль.

Сегментация по уровням приложения

Разнести фронтенд, приложение и базу в разные группы безопасности — это не прихоть, а практическая необходимость. Фронт общается с интернетом и с приложением, приложение — только с фронтендом и базами данных, а БД — только с приложением. В облаках удобно ссылаться на сами группы как источник трафика, а не на CIDR. Это, в свою очередь, уменьшает количество ошибок при повторном развертывании.

Быстрая защита при инцидентах

Выше мы уже говорили, что группы безопасности не подходят для защиты от DDoS. Это так, но если вы замечаете странные попытки подключения или обнаружили компрометацию, группы безопасности — ваш быстрый рычаг. Ведь с помощью них можно моментально ограничить доступ по IP или временно удалить правило SSH.

Разграничение админского доступа

Ни одна инфраструктура не обходится без админского доступа. Правильный паттерн — организовать отдельный bastion/jump‑host, который слушает запросы только из корпоративного VPN или фиксированных IP. Все это можно реализовать на уровне инстанса с помощью групп безопасности.

Временные тестовые и feature‑окружения

Когда вы поднимаете окружения для QA, назначайте им отдельные группы безопасности с ограниченным доступом, чтобы все работало только по CI, а доступ был описан только для определенных IP разработчиков. После завершения тестов автоматическая очистка окружения и удаление групп избавляют от мусора и потенциальных дыр.

Как создать группу безопасности

В облачной платформе Selectel теперь можно настраивать группы безопасности. За ними можно расположить виртуальные серверы, кластеры Managed Kubernetes и облачных баз данных. А при необходимости — и выделенные серверы, если поднять ВМ, которая будет выступать в качестве прокси.

Работать с группами безопасности можно как в удобной панели управления, так и через OpenStack CLI или Terraform. В рамках статьи мы разберем работу с графическим интерфейсом, подробнее о каждом способе — в документации.

Итак, если у вас есть один или несколько серверов в одном пуле, вы можете настроить для них группы безопасности. Для этого в панели управления необходимо перейти в раздел Облачная платформа → Группы безопасности.

По умолчанию в списке групп будет default — в ней прописаны шесть основных правил, которые, по сути, разрешают все для входящего и исходящего трафика. А если в сети включена фильтрация трафика (port security), группа безопасности по умолчанию назначается на все порты в этой сети при их создании.

1. Для примера попробуем создать новую группу безопасности в пуле ru-3. Для этого нажимаем на кнопку Создать группу безопасности. 

2. В панели управления откроется вкладка Новая группа безопасности. Здесь можно выбрать регион и пул, для которого группа безопасности будет актуальна.

3. Далее можно перейти к настройке правил. При этом вы настраиваете только входящий трафик. 

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

Для примера попробуем открыть 80-й порт — его мы будем использовать для работы сервера nginx.

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

4. Далее на стороне сервера устанавливаем сервис, который хотим расположить за группами безопасности. В нашем случае — nginx. 

sudo apt update
sudo apt install -y nginx

sudo systemctl enable --now nginx

5. Отправляем запрос на необходимый порт и проверяем, работает ли сервис.

curl 185.91.53.192:80

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

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

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

6. Переходим в раздел Облачные серверы и открываем настройки своей ВМ. Переходим во вкладку Порты и удаляем default.

Отлично! Теперь ваш сервис будет доступен только через порты, обозначенные в новой группе безопасности.

ssh root@185.91.53.192
...
...
...

7. Но есть один нюанс. Если сервер используется в качестве VPN или Proxy, как в кейсе с выделенными серверами, то может понадобиться настройка  пары IP/MAC-адресов. Это нужно, чтобы чтобы избежать проблем с фильтрацией и ARP/NEIGH-расхождениями, а также — обеспечить обработку трафика с любых IP-адресов, так как по умолчанию включена защита от подмены адресов. 

Это можно сделать во вкладке Порты, нажавна кнопку Разрешить все IP-адреса для VPN.

Теперь все готово!

Другие возможности групп безопасности

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

Кроме того, теперь можно за несколько секунд создать множество правил из JSON-файла, без ручной настройки. Для этого в панели управления есть отдельная кнопка на этапе редактирования.

Заключение

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

При этом не стоит рассматривать группы безопасности как решение, которое можно использовать вместо облачного файрвола или защиты от DDoS. Это разные инструменты, которые работают на общий результат — защиту вашего проекта.