Security Groups¶

Security Groups — это виртуальный брандмауэр на уровне экземпляра (инстанса) или сетевого интерфейса в облачных вычислительных платформах (например, Amazon Web Services, Microsoft Azure, OpenStack), предназначенный для управления входящим и исходящим сетевым трафиком на основе набора правил. Security Groups действуют как фильтр пакетов, разрешая или блокируя трафик по протоколу, порту и IP-адресу источника/назначения.

¶Принцип работы

Security Groups функционируют на уровне сетевого стека гипервизора или виртуального коммутатора. Каждое правило в группе определяет:

• тип трафика (входящий — ingress, исходящий — egress);
• протокол (TCP, UDP, ICMP и др.);
• диапазон портов (например, 80 для HTTP, 443 для HTTPS);
• источник или назначение (IP-адрес, CIDR-блок, другая security group).

Правила оцениваются в порядке приоритета (если не указано иное, обычно все правила равнозначны, и применяется первое совпадение). По умолчанию все входящие соединения запрещены, все исходящие разрешены — это стандартная политика «всё запрещено, кроме явно разрешённого». При изменении правил они применяются мгновенно ко всем экземплярам, привязанным к данной группе.

¶Отличие от Network ACL

Security Groups часто сравнивают с сетевыми списками контроля доступа (Network ACL). Основные различия:

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

¶История и развитие

Концепция виртуальных брандмауэров на уровне виртуальных машин появилась в середине 2000-х годов с развитием облачных вычислений. Первой крупной платформой, внедрившей Security Groups, стала Amazon Web Services (AWS) в 2006 году с запуском Amazon EC2. Изначально Security Groups поддерживали только IPv4 и ограниченный набор протоколов. В 2013 году AWS добавила поддержку IPv6, а позже — возможность ссылаться на другие Security Groups как на источник (что позволяет строить многоуровневые архитектуры).

В Microsoft Azure аналогичная функциональность называется Network Security Groups (NSG), в OpenStack — Security Group Rules, в Google Cloud Platform — Firewall Rules (хотя они работают на уровне VPC, а не инстанса). Несмотря на разные названия, принцип остаётся общим.

¶Классификация и виды

¶По типу трафика

• Входящие (ingress) правила — контролируют трафик, поступающий на экземпляр.
• Исходящие (egress) правила — контролируют трафик, отправляемый с экземпляра.

¶По способу задания источника/назначения

• По IP-адресу или CIDR — например, 0.0.0.0/0 (весь интернет) или 10.0.0.0/8 (внутренняя сеть).
• По другой Security Group — позволяет разрешить трафик между группами экземпляров без указания конкретных IP (удобно для микросервисных архитектур).
• По тегу (tag) — в некоторых платформах (например, AWS) можно ссылаться на группы по имени или идентификатору.

¶По протоколу и порту

• TCP/UDP с указанием порта или диапазона портов.
• ICMP (для ping и диагностики).
• Специализированные протоколы (например, ESP для IPsec).

¶Применение

¶Безопасность облачных инфраструктур

Security Groups являются основным средством сетевой изоляции в облачных средах. Их используют для:

• ограничения доступа к базам данных (только с определённых IP или из определённых групп приложений);
• открытия веб-серверов для внешнего трафика (порты 80/443);
• блокировки нежелательных протоколов (например, SMB из интернета);
• создания микросегментации — каждая группа экземпляров имеет свой набор правил.

¶Типовые сценарии

1. Веб-сервер: разрешён входящий трафик на порты 80 (HTTP) и 443 (HTTPS) из 0.0.0.0/0, исходящий — любой.
2. Сервер базы данных: разрешён входящий трафик на порт 3306 (MySQL) только из Security Group веб-серверов, исходящий — только к DNS-серверам.
3. Административный доступ: разрешён входящий SSH (порт 22) только с IP-адресов офиса.

¶Ограничения и риски

• Security Groups не защищают от атак на уровне приложений (SQL-инъекции, XSS) — для этого нужны веб-брандмауэры (WAF).
• При неправильной конфигурации (например, открытый порт 22 для 0.0.0.0/0) возможен несанкционированный доступ.
• Stateful-природа может маскировать исходящие аномалии — если злоумышленник получил доступ к экземпляру, он может инициировать соединение наружу, и оно будет автоматически разрешено.

¶Примеры реализации в облачных платформах

¶Amazon Web Services (AWS)

В AWS Security Groups привязываются к сетевым интерфейсам (ENI) экземпляров EC2. Один экземпляр может иметь до 5 групп (лимит может быть увеличен). Правила не имеют приоритета — все правила равны, и трафик разрешается, если он соответствует хотя бы одному правилу. AWS также поддерживает security group rules для VPC Endpoints и Lambda-функций.

¶Microsoft Azure

В Azure Network Security Groups (NSG) привязываются к подсетям или сетевым интерфейсам виртуальных машин. Поддерживают как allow, так и deny правила, а также теги служб (например, Internet, AzureLoadBalancer). NSG могут быть применены на уровне подписки.

¶OpenStack

В OpenStack Security Groups реализованы через нейтрон (Neutron) — сетевой сервис. Правила задаются для групп, которые затем привязываются к портам виртуальных машин. Поддерживается IPv4 и IPv6, а также возможность задавать правила на основе удалённой группы.

¶Интересные факты

• В AWS Security Groups не могут блокировать трафик между экземплярами внутри одной группы — для этого нужно использовать отдельные группы.
• В Azure NSG поддерживают до 1000 правил на одну группу (лимит может быть увеличен).
• В некоторых облачных платформах (например, DigitalOcean) Security Groups называются Cloud Firewalls и работают на уровне дата-центра.
• Security Groups часто используются в сочетании с network ACL для многоуровневой защиты (defense in depth).

¶Критика и ограничения

• Сложность управления — при большом количестве групп и правил конфигурация становится запутанной, особенно в крупных организациях.
• Отсутствие логирования — по умолчанию Security Groups не ведут журнал отклонённых пакетов (хотя в AWS есть VPC Flow Logs для анализа трафика).
• Зависимость от провайдера — правила и поведение могут различаться между облаками, что усложняет миграцию.
• Риск человеческой ошибки — случайное открытие порта для всех IP может привести к утечке данных.

¶Источники

• Amazon Web Services. «Security Groups for Your VPC» — документация AWS.
• Microsoft Azure. «Network Security Groups» — документация Azure.
• OpenStack. «Security Groups» — документация OpenStack.
• Google Cloud. «VPC Firewall Rules» — документация GCP.
• «Cloud Security: A Comprehensive Guide to Secure Cloud Computing» — John R. Vacca (2017).
• «AWS Certified Solutions Architect Study Guide» — Ben Piper, David Clinton (2021).