Что такое Security Groups и как они защищают облачные серверы

TL;DR

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

Главная польза Security Groups в том, что они резко сокращают лишнюю сетевую поверхность. Вместо сервера, который “торчит в интернет” всеми портами сразу, вы оставляете только те направления трафика, которые реально нужны: например, HTTPS для веб-сервиса, SSH только с доверенного IP, а доступ к базе — вообще только от приложения, а не от всего мира.

Но Security Groups не стоит воспринимать как полную защиту сервера. Они не исправляют уязвимый код, не заменяют патчи, IAM, WAF и нормальную архитектуру доступа. Их задача уже и проще: не пускать ненужный трафик туда, где ему делать нечего.

Что Security Groups делают хорошо, а чего от них ждать не стоит:

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

Как облачный сервер получает только нужные подключения

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

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

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

Как это работает на понятном примере

Представим обычный сервер с веб-приложением. Ему не нужен “весь интернет” сразу. Ему нужны только конкретные вещи: HTTPS для пользователей, SSH для администратора и, возможно, доступ к базе данных — но не от любого адреса, а только от самого приложения.

Именно здесь такая схема и становится полезной. Она позволяет описать сетевую логику не как “сервер открыт”, а как “этому серверу разрешено только вот это и только отсюда”. Например, для публичной части сайта можно оставить открытым только порт 443, для админского доступа — 22 порт, но лишь с одного офисного IP, а базу данных вообще не публиковать наружу.

Хороший пример — трёхзвенная схема: load balancer → web → database. В ней веб-слой может принимать HTTPS от пользователей, база — только подключения от приложения, а не из интернета. Если кто-то попытается подключиться к базе напрямую, соединение упрётся не в сам сервер и не в ошибку логина, а в сетевой фильтр, который просто не пропустит такой трафик.

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

Что именно они фильтруют: IP, порт, протокол и направления трафика

На практике правила строятся вокруг нескольких простых вещей: откуда идёт трафик, куда он направляется, по какому протоколу работает и на какой порт пытается попасть.

Если перевести это на понятные сценарии, получится примерно так:

• HTTPS для пользователей — разрешаем входящий трафик TCP 443 (не забываем UDP, если используем QUIC) со всех адресов;
  
• SSH для администратора — разрешаем TCP 22, но только с конкретного IP;
  
• База данных — разрешаем, например, 5432 или 3306, но только от приложения, а не от всех подряд;
  
• Ping или другой служебный трафик — либо разрешаем отдельно, либо не открываем вообще, если он не нужен.

То есть фильтрация здесь строится не вокруг абстрактно “опасного” трафика, а вокруг очень конкретных сетевых параметров. За счёт этого сервер получает не расплывчатую защиту, а чётко очерченный список того, что ему действительно разрешено.

Есть и две важные технические особенности, из-за которых такая схема остаётся удобной в работе. Во-первых, фильтрация здесь stateful: если входящее соединение уже разрешено, ответный трафик проходит автоматически. Проще говоря, если пользователь открыл сайт по HTTPS, серверу не нужно отдельное правило только для того, чтобы отдать страницу в ответ.

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

Именно поэтому Security Groups удобны как первый сетевой фильтр перед сервером: они пропускают только то, что действительно нужно приложению, и отсекают всё лишнее ещё до попытки подключения.

От каких ошибок и угроз Security Groups реально защищают

Security Groups особенно полезны там, где проблема начинается не со сложной атаки, а с лишней сетевой доступности.

Самый частый случай — открытые наружу сервисы, которым там делать нечего. Например, серверу нужен только HTTPS для пользователей, а вместе с ним случайно доступны SSH, база данных или внутренний служебный порт. Чем больше таких лишних входов, тем шире поверхность атаки.

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

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

Четвёртая - неограниченный исходящий трафик. Например, если на сервер проберётся вирус - при настроенных исходящих ограничениях он не сможет установить соединение с хакером. Рекомендуется исходящий трафик также ограничивать максимально (только нужные интеграции).

На практике это помогает избежать вполне конкретных проблем:

• База данных не торчит в интернет;
  
• SSH не открыт для всех подряд;
  
• Внутренний сервис не принимает внешний трафик;
  
• Один компонент не ходит туда, куда ему не нужно.

Представим магазин, который продаёт носки с капибарами, динозаврами и кусками пиццы. Покупатель должен видеть только витрину сайта. Сам сайт может обращаться к приложению, а приложение — к базе заказов. Но база не должна быть доступна ни покупателю, ни случайному внешнему сканеру. Если это ограничено на сетевом уровне, часть ошибок просто не доходит до самого сервера.

Но на этом роль Security Groups не заканчивается только в теории — у них есть и вполне жёсткие практические границы. Дальше как раз разберём, где они уже не помогают сами по себе и с какими механизмами их чаще всего путают.

Где Security Groups не спасают сами по себе и что с ними часто путают

Почему это не замена обновлениям, IAM и защите приложения

Если у сервера открыт только нужный трафик, это уже хорошо. Но Security Groups не исправляют уязвимый код, не закрывают дыры в старой версии CMS, не лечат слабые пароли и не заменяют контроль прав доступа. Они не анализируют содержимое HTTP-запроса и не понимают, что перед ними — попытка SQL-инъекции, эксплуатация бага в приложении или украденная сессия. Их задача уже: либо пропустить соединение по заданным сетевым правилам, либо не пропустить его.

На примере магазина с носками с капибарами это выглядит просто. Можно идеально закрыть сервер по портам: оставить только HTTPS, ограничить SSH и спрятать базу от интернета. Но если админка магазина уязвима, а учётка администратора без MFA и с лишними правами, одни только Security Groups это не исправят. Тут уже нужны обновления, нормальная IAM-модель и защита самого приложения.

Поэтому их полезно воспринимать не как “всю облачную безопасность”, а как один конкретный барьер перед ресурсом. Они хорошо уменьшают сетевую поверхность, но не заменяют остальные уровни защиты.

Чем они отличаются от firewall rules, NACL и других сетевых правил

Теперь важно развести не ограничения Security Groups, а их место в самой сетевой схеме. Их часто ставят в один ряд с NACL и host firewall, хотя эти механизмы работают на разных уровнях и решают разные задачи.

Проще всего держать в голове такую логику: Security Groups работают у самого ресурса, NACL — на уровне подсети, а host firewall — уже внутри самой операционной системы. Они не дублируют друг друга один в один и не заменяют друг друга автоматически.

Сначала полезно сравнить Security Groups и NACL, потому что именно их чаще всего смешивают.

Security Groups и NACL: в чём разница на практике:

Возвращаясь к нашему примеру это выглядит так: Security Groups решают, может ли веб-сервер принимать HTTPS и может ли база отвечать только приложению. NACL уже задают более общий фильтр для всей подсети, где живут эти ресурсы.

Но на этом путаница не заканчивается. Отдельно стоит развести Security Groups и обычный firewall внутри самого сервера.

Где проходит граница между security Groups и host firewall:

Иными словами, Security Groups, NACL и host firewall — это не три названия для одного и того же, а три разных уровня сетевого контроля. Именно поэтому их лучше рассматривать не как конкурентов, а как части одной общей схемы защиты.

Заключение

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

Но это только один слой защиты. Он не исправляет уязвимый код, не заменяет контроль прав и не закрывает остальные риски сам по себе.

FAQ

Это то же самое, что cloud firewall?

Не совсем. Это один из облачных механизмов фильтрации трафика, но не универсальное название для всей сетевой защиты в облаке.

Нужны ли такие правила, если сервер и так не открыт в интернет напрямую

Да. Даже у внутреннего ресурса лучше заранее ограничить, кто именно может к нему обращаться и по каким портам.

Могут ли они защитить от взлома сайта

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

Чем опасно правило 0.0.0.0/0

Тем, что оно открывает доступ для любого IP-адреса. Иногда это оправдано для публичного HTTPS, но для SSH, базы данных или админских сервисов такое правило обычно слишком широкое.

Можно ли обойтись только такими правилами без host firewall

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

Что важнее: такие правила или IAM

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

Список источников

1. AWS — Control traffic to your AWS resources using security groups

2. AWS — Security group rules

3. AWS — Amazon EC2 security group connection tracking

4. AWS — Control subnet traffic with network access control lists