Обзор Security Group и Security Group Rule

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

Многие облачные сервисы могут использовать Security Group, такие как ECS, RDS, DDS, DDM, MRS, CCE, CSS, DCS (Redis 3.0), DMS, WAF и SFS.

При создании instance (например, ECS) необходимо связать его с Security Group. Если Security Group ещё нет, будет автоматически создана и связана с instance default security group. Для получения подробной информации см. Default Security Group Overview. Вы также можете создать Security Group в соответствии с требованиями сервиса и связать её с instance. У instance может быть связано несколько Security Group, и трафик к и от instance обрабатывается в порядке убывающего приоритета.

Каждая Security Group может иметь как inbound, так и outbound правила. Необходимо указать источник, порт и протокол для каждого inbound‑правила и указать назначение, порт и протокол для каждого outbound‑правила, чтобы контролировать входящий и исходящий трафик к и от instance в Security Group. Как показано на Figure 1, у вас есть VPC (VPC-A) с подсетью (Subnet-A) в регионе A. ECS (ECS-A) работает в Subnet-A и связан с Security Group Sg-A.

• Security Group Sg-A имеет пользовательское inbound‑правило, разрешающее ICMP‑трафик, поэтому запросы ping разрешены от вашего ПК к ECS-A. Однако Security Group не содержит правил, разрешающих SSH‑трафик, поэтому вы не можете удалённо войти в ECS-A с вашего ПК.
• ECS-A имеет привязанный EIP, и outbound‑правило Sg-A разрешает весь исходящий трафик от ECS-A, поэтому ECS-A может получать доступ к Интернету.

• Security Group имеет inbound и outbound правила для контроля трафика, который разрешён к instance, связанным с этой Security Group, или от них.
  • Inbound rules контролируют трафик к instance в Security Group.
  • Outbound rules контролируют трафик от instance в Security Group для доступа к внешним сетям.
• Вы можете указать протокол, порт, источник или назначение для правила Security Group. Ниже описана ключевая информация о правиле Security Group.
  • Action: Allow или Deny. Если протокол, порт, источник или назначение трафика совпадают с правилом Security Group, трафик будет разрешён или отклонён.
  • Priority: Значение варьируется от 1 до 100. Меньшее значение указывает более высокий приоритет. Правила security group сначала сопоставляются по приоритету, затем по действию. Правила Deny имеют приоритет над правилами Allow. Для получения дополнительной информации см. How Traffic Matches Security Group Rules.
  • Type: IPv4 или IPv6.
  • Protocol & Port: тип сетевого протокола и диапазон портов.
    • Protocol: протокол, используемый для сопоставления трафика. Протокол может быть TCP, UDP, ICMP или GRE.
      • TCP идеально подходит для приложений, требующих надёжных соединений и высокой целостности данных, таких как удалённый вход, веб‑просмотр, электронная почта и передача файлов.
      • UDP идеально подходит для приложений, требующих высокой скорости и низкой задержки, таких как онлайн‑игры и видеоконференции.
      • ICMP используется устройствами для передачи ошибок передачи данных в сети. Например, ping может использоваться для проверки связности между сетевыми устройствами, могут генерироваться отчёты об ошибках для O&M, а диагностическая информация может передаваться для анализа и оптимизации сети.
      • GRE широко используется и обеспечивает связь между сетями, использующими разные протоколы, путем инкапсуляции одного протокола в другой, например, инкапсуляции IP‑пакетов.
    • Port: диапазон целевых портов, используемый для сопоставления трафика. Значение варьируется от 1 до 65535.
  • Source или Destination: исходный адрес трафика во входящем направлении или целевой адрес трафика в исходящем направлении.

    Исходный или целевой адрес может быть IP‑address, security group или IP address group.

    • IP address: фиксированный IP‑address или CIDR‑блок. Поддерживаются как IPv4, так и IPv6 адреса. Например, 192.168.10.10/32 (IPv4 address), 192.168.1.0/24 (IPv4 CIDR block) или 2407:c080:802:469::/64 (IPv6 CIDR block).
    • Security group: Если выбранный security group и текущий security group находятся в одном регионе, трафик разрешается или отклоняется к приватным IP‑address всех инстансов в выбранном security group. Например, если инстанс A находится в security group A, а инстанс B — в security group B, и в security group A существует входящее правило, позволяющее трафик из security group B, трафик будет разрешён от инстанса B к инстансу A.
    • IP address group: Если у вас есть несколько IP‑address с одинаковыми требованиями к безопасности, вы можете добавить их в IP address group и выбрать эту IP address group при настройке правила, чтобы упростить их управление. Для подробностей см. IP Address Group Overview.

• Группы безопасности являются stateful. Если ваш instance инициирует запрос и его security group разрешает весь outbound traffic, соответствующий response traffic разрешён независимо от inbound правил security group. Аналогично, если security group разрешает inbound traffic, ответы на разрешённый inbound traffic разрешаются исходить независимо от outbound правил security group.
• Группы безопасности используют connection tracking для отслеживания трафика к и от instances. Изменения inbound правил вступают в силу немедленно для существующих соединений. Изменения outbound правил security group не влияют на существующие постоянные соединения и вступают в силу только для новых соединений.

  Если вы добавляете, удаляете или обновляете правила в security group, или добавляете или удаляете instances в security group, детали следующие:

  • Для соединений, установленных inbound traffic, система автоматически очищает записи connection tracking, соответствующие существующим постоянным соединениям, на основе Table 1. То есть записи connection tracking истекают заранее. Затем система повторно устанавливает соединения, чтобы соответствовать новым inbound правилам security group.
    • Если правила security group разрешают трафик соединений, соединения могут быть установлены, и сетевое взаимодействие не затронуто.
    • Если правила security group запрещают трафик соединений, соединения не могут быть восстановлены, и сетевое взаимодействие будет прервано.

    Table 1 Сценарии и политики очистки connection tracking entries

    Сценарий	Политика очистки
    Adding instances в security group A	Очистить inbound connection tracking entries у instances, недавно добавленных в security group A. Если inbound правило другого security group (например, security group B) denies доступ из security group A, очистить inbound connection tracking entries всех instances в security group B.
    Removing instances из security group A	Очистить inbound connection tracking entries всех instances в security group A. Если inbound правило другого security group (например, security group B) allows доступ из security group A, очистить inbound connection tracking entries всех instances в security group B.
    Добавление правил to security group A	Если Deny правило added в направлении inbound or outbound, очистите входящие записи отслеживания соединений всех инстансов в security group A.
    Удаление правил from security group A	Если Allow правило deleted во входящем направлении, очистите входящие записи отслеживания соединений всех инстансов в security group A.
    Изменение правил in security group A	Если приоритет, action, протокол, порт или source address правила изменены во входящем направлении, очистите входящие записи отслеживания соединений всех инстансов в security group A.
    Изменение записей IP-адресов в IP address group	Если IP address group is associated with an inbound rule в security group A, deleting or adding an IP address entry from or to the IP address group очистит входящие записи отслеживания соединений всех инстансов в security group A.

  • Существующие исходящие постоянные соединения не будут разорваны, и исходное правило по‑прежнему будет применяться. Все новые соединения будут соответствовать новым правилам.

• Правила security group работают как белый список. Если нет правил, явно разрешающих или запрещающих определённый трафик, security group отклоняет такой трафик к/от инстансов в security group.
  • Входящие правила: Если источник запроса соответствует источнику, указанному во входящем правиле, у которого Action установлен в Allow, запрос разрешён. По этой причине вам не требуется настраивать правило deny во входящем направлении.

    Входящие правила в Table 2 обеспечивают возможность инстансов в security group взаимодействовать друг с другом. Не удаляйте и не изменяйте эти правила.

  • Исходящие правила: Исходящие правила в Table 2 позволяют всему трафику покидать instances в security group, чтобы instances могли обращаться к любому внешнему IP-адресу. Если удалить эти правила, instances в security group не смогут обращаться к внешним сетям.

    Table 2 Security group rules

    Direction	Action	Type	Protocol & Port	Source or Destination
    Inbound	Allow	IPv4	All	Source: current security group
    Inbound	Allow	IPv6	All	Source: current security group
    Outbound	Allow	IPv4	All	Destination: 0.0.0.0/0
    Outbound	Allow	IPv6	All	Destination: ::/0

У инстанса может быть связано несколько security groups, и security group может содержать несколько security group rules. Security group rules сопоставляются сначала по priority, затем по action. Правила Deny имеют приоритет над правилами allow. Ниже приведён пример сопоставления security group rules для входящего трафика:

1. Сначала трафик сопоставляется на основе sequence number security groups. Вы можете изменить последовательность security groups. Меньший номер sequence number security group указывает на более высокий приоритет.

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

2. Во‑вторых, трафик сопоставляется на основе приоритетов и действий правил группы безопасности.
   1. Правила группы безопасности сначала сопоставляются по их приоритетам. Меньшее значение указывает на более высокий приоритет.

      Если приоритет правила группы безопасности A равен 1, а приоритет правила группы безопасности B — 2, приоритет правила группы безопасности A выше, чем у правила группы безопасности B. Поэтому трафик предпочтительно сопоставляется с правилом группы безопасности A.

   2. Правила Deny имеют приоритет над правилами Allow при одинаковом приоритете.
3. Трафик сопоставляется со всеми входящими правилами группы безопасности на основе протокола, портов и источника.
   • Если трафик соответствует правилу:
     • With Action set to Allow, the traffic is allowed to access the instances in the security group.
     • With Action set to Deny, the traffic is denied from accessing the instances in the security group.
   • Если трафик не соответствует ни одному правилу, доступ к инстансам в группе безопасности запрещён.

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

На Figure 3 в VPC-X находятся две подсети (Subnet-A и Subnet-B). ECS в Subnet-A связаны с Sg-A, поскольку эти ECS используются для запуска одинаковых типов сервисов и имеют одинаковые требования к сетевому взаимодействию. Аналогично, ECS в Subnet-B связаны с группой безопасности Sg-B.

• Входящее правило A01 группы Sg-A разрешает трафик от IP-адресов 172.16.0.0/24 для доступа к ECS в Sg-A по порту SSH 22 для удаленного входа в эти Linux ECS.
• Входящее правило A02 группы Sg-A разрешает ECS в этой группе безопасности взаимодействовать друг с другом, используя любой протокол и любой порт. То есть ECS в Subnet-A могут взаимодействовать друг с другом.
• Входящее правило B01 группы Sg-B разрешает ECS в Sg-A доступ к ECS в Sg-B по порту SSH 22. То есть ECS в Subnet-A могут удаленно входить в ECS в Subnet-B.
• Входящее правило B02 группы Sg-B разрешает ECS в этой группе безопасности взаимодействовать друг с другом, используя любой протокол и любой порт. То есть ECS в Subnet-B могут взаимодействовать друг с другом.
• Исходящие правила обеих групп безопасности разрешают весь трафик от ECS в этих группах безопасности.

Если вы используете промежуточный сетевой инстанс для пересылки трафика между инстансами в разных подсетях, установка источника входящего правила в группу безопасности, связанную с одноранговым инстансом, не позволяет инстансам взаимодействовать друг с другом. Чтобы включить связь, установите источник в частный IP-адрес или CIDR‑блок подсети промежуточного сетевого инстанса. Например, чтобы соединить ECS в Subnet-A и Subnet-B в Figure 4, установите источник входящего правила в виртуальный IP-адрес или CIDR‑блок подсети.

VPC-X имеет две подсети: Subnet-A и Subnet-B. ECS в Subnet-A связаны с группой безопасности Sg-A, а ECS в Subnet-B связаны с группой безопасности Sg-B. ECS-A01 и ECS-A02 в Subnet-A работают в паре активный/резервный, образуя кластер Keepalived HA. ECS используют виртуальный IP-адрес 192.168.0.21 для связи с внешними сетями.

• Входящее правило A01 группы Sg-A разрешает ECS в Sg-B доступ к ECS в Sg-A, используя любой протокол и любой порт.
• Sg-B имеет следующие входящие правила:
  • Правило B02: разрешает ECS в Sg-A использовать частные IP-адреса для доступа к ECS в Sg-B. В этой сети ECS в Sg-A должны взаимодействовать с ECS в Sg-B через виртуальный IP-адрес 192.168.0.21. Однако правило B02 не разрешает трафик от этого виртуального IP-адреса.
  • Правило B01: разрешает трафик от виртуального IP-адреса 192.168.0.21 к ECS в Sg-B, используя любой протокол и любой порт. В этой сети вы также можете установить источник в 192.168.0.0/24, CIDR‑блок Subnet-A.

В Figure 5, VPC-A и VPC-B в регионе A соединены VPC peering connection peering-AB. После настройки маршрутов для VPC peering connection, Subnet-A01 и Subnet-B01 могут взаимодействовать друг с другом. Однако ECS в двух подсетях связаны с разными группами безопасности. Чтобы разрешить ECS в Sg-A и Sg-B взаимодействовать друг с другом, необходимо:

• Добавьте правило A01 в Sg-A. У правила параметр Source установлен в Sg-B, чтобы разрешить ECS в Sg-B доступ к ECS в Sg-A.
• Добавьте правило B01 в Sg-B. У правила параметр Source установлен в Sg-A, чтобы разрешить ECS в Sg-A доступ к ECS в Sg-B.

• По умолчанию вы можете добавить до 50 правил security group в security group.
• По умолчанию вы можете связать не более пяти security group с каждым cloud server или расширенным сетевым интерфейсом. В этом случае правила всех выбранных security group объединяются и применяются.
• Security group может быть связан не более чем с 6 000 instances, иначе его производительность ухудшится.
• Для входящих правил security group суммарное количество правил, у которых Source установлен в Security group, правил, у которых Source установлен в IP address group, и правил с несмежными портами, не может превышать 120. Избыточные правила не вступят в силу. Правила security group для IPv4 и IPv6 учитываются отдельно, для каждого допускается до 120 правил.

  Для исходящих правил security group суммарное количество правил, у которых Destination установлен в Security group, правил, у которых Destination установлен в IP address group, и правил с несмежными портами, не может превышать 120. Избыточные правила не вступят в силу.

  Например, чтобы добавить входящие правила IPv4 в группу безопасности (Sg-A), вы можете обратиться к Table 4 для правил, соответствующих ограничениям. Среди этих правил правило A02 использует непоследовательные порты и также указывает группу безопасности в качестве источника. В этом случае используется только одна квота.

  Table 4 Входящие правила группы безопасности

  Rule No.	Action	Type	Protocol & Port	Source
  Rule A01	Allow	IPv4	All	Current security group: Sg-A
  Rule A02	Allow	IPv4	TCP: 22,25,27	Другой security group: Sg-B
  Rule A03	Allow	IPv4	TCP: 80-82	IP address group: ipGroup-A
  Rule A04	Allow	IPv4	TCP: 22-24,25	IP address: 192.168.0.0/16

• Трафик от балансировщиков нагрузки не ограничивается network ACL и правилами security group, если:

  Transfer Client IP Address включен для слушателей балансировщика нагрузки.

  Балансировщик нагрузки по‑прежнему может перенаправлять трафик к backend servers, даже если существует правило, запрещающее трафик от балансировщика нагрузки к backend servers.

• Instances в security group по умолчанию отклоняют все внешние запросы доступа, но вы можете добавить правила, разрешающие конкретные запросы.
• При добавлении правила security group предоставляйте минимально возможные разрешения. Например, если разрешён удалённый вход в ECS через порт 22, разрешайте вход только с конкретных IP‑адресов. Не используйте 0.0.0.0/0 (все IP‑адреса).
• Сохраняйте конфигурацию правил простой в одном security group. Для каждого security group должна быть отдельная причина. Если использовать один и тот же security group для всех ваших instances, правила в security group, вероятно, будут избыточными и сложными. Это значительно усложнит их поддержку и управление.
• Вы можете добавлять instances в разные security groups в зависимости от их функций. Например, если вы хотите предоставить веб‑службы, доступные из Интернета, вы можете добавить веб‑серверы в security group, настроенный для этой конкретной цели, и разрешить внешний доступ только через определённые порты, такие как 80 и 443. По умолчанию остальные внешние запросы доступа отклоняются. Не размещайте внутренние сервисы, такие как MySQL или Redis, на веб‑серверах, предоставляющих услуги, доступные из Интернета. Разворачивайте внутренние сервисы на серверах, которым не требуется подключение к Интернету, и связывайте эти серверы с security groups, специально настроенными для этой цели.
• Не изменяйте правила security group, находящиеся в использовании, напрямую. Прежде чем изменять правило security group, которое используется, вы можете клонировать security group и изменить правило в тестовой среде, чтобы убедиться, что изменённое правило работает. Подробнее см. Cloning a Security Group.
• После добавления instances в security group или изменения правил security group правила security group применяются автоматически. Перезапуск instances не требуется.

  If a security group rule does not take effect after being configured, see Why Are My Security Group Rules Not Working?