FIREWALL¶
Обзор иерархических политик брандмауэра¶
https://cloud.google.com/vpc/docs/firewalls
Иерархические политики брандмауэра позволяют создавать и применять согласованную политику брандмауэра в вашей организации. Вы можете назначить иерархические политики брандмауэра организации в целом или отдельным папкам. Эти политики содержат правила, которые могут явно запрещать или разрешать подключения, как и правила брандмауэра виртуального частного облака (VPC). Кроме того, правила иерархической политики брандмауэра могут делегировать оценку политикам более низкого уровня или правилам сетевого брандмауэра VPC с действием goto_next.
Правила более низкого уровня не могут переопределять правило с более высокого места в иерархии ресурсов. Это позволяет администраторам всей организации управлять критически важными правилами брандмауэра в одном месте.Технические характеристики
Иерархические политики брандмауэра создаются на узлах организации и папок. Создание политики не приводит к автоматическому применению правил к узлу. Политики, однажды созданные, могут быть применены к (связанным с) любым узлам в организации. Иерархические политики брандмауэра являются контейнерами для правил брандмауэра. Когда вы связываете политику с организацией или папкой, все правила немедленно применяются. Вы можете поменять политики для узла, который атомарно меняет местами все правила брандмауэра, применяемые к экземплярам виртуальных машин (ВМ) на этом узле. Оценка правил является иерархической на основе иерархии ресурсов. Оцениваются все правила, связанные с узлом организации, за которыми следуют правила папок первого уровня и так далее. В правилах иерархической политики брандмауэра есть новое действие goto_next, которое можно использовать для делегирования оценки подключения на более низкие уровни иерархии. Правила иерархической политики брандмауэра могут быть нацелены на определенные сети VPC и виртуальные машины, используя целевые ресурсы для сетей и целевые учетные записи служб для виртуальных машин. Это позволяет создавать исключения для групп виртуальных машин. Правила иерархической политики брандмауэра не поддерживают таргетинг по тегам экземпляров. Каждое правило иерархической политики брандмауэра может включать диапазоны IPv4 или IPv6, но не оба. Для обеспечения соответствия требованиям и отладки правила брандмауэра, применяемые к экземпляру виртуальной машины, можно проверить с помощью страницы Сведений о сети VPC и страницы сведений о сетевом интерфейсе экземпляра виртуальной машины.
Иерархия ресурсов¶
Вы создаете и применяете политики брандмауэра как отдельные шаги. Вы можете создавать и применять политики брандмауэра в узлах организации или папок иерархии ресурсов. Правило политики брандмауэра может блокировать подключения, разрешать подключения или откладывать оценку правил брандмауэра для папок более низкого уровня или правил брандмауэра VPC, определенных в сетях VPC.
Организация - это узел верхнего уровня в иерархии ресурсов в Google Cloud, где вы можете создавать или связывать иерархические политики брандмауэра. Все папки и сети VPC в организации наследуют эту политику.
Папки - это узлы среднего уровня в иерархии облачных ресурсов Google, расположенные между организацией и проектами, где вы можете создавать или назначать иерархические политики брандмауэра. Все папки и сети VPC в папке наследуют связанную с ней политику.
Проект находится в папке или организации. Вы можете перемещать проекты между узлами в организации. Проекты содержат сети VPC. Иерархические политики брандмауэра нельзя назначать проектам, только организации или папкам.
Сеть VPC - это раздел Google Cloud для изолированной внутренней IP-связи. Это уровень, на котором определяются и применяются маршруты и традиционные правила брандмауэра VPC. Правила иерархической политики брандмауэра могут переопределять правила сетевого брандмауэра или делегировать им оценку подключения.
По умолчанию все правила иерархической политики брандмауэра применяются ко всем виртуальным машинам во всех проектах в организации или папке, с которыми связана политика. Однако вы можете ограничить, какие виртуальные машины получают данное правило, указав целевые сети или учетные записи целевых служб.
Уровни иерархии, на которых теперь могут применяться правила брандмауэра, представлены на следующей диаграмме. Желтые поля представляют иерархические политики брандмауэра, содержащие правила брандмауэра, в то время как белые поля представляют правила брандмауэра VPC.
Оценка правил¶
Правила иерархической политики брандмауэра применяются на уровне виртуальной машины, как и правила брандмауэра VPC. То есть они не применяются на границе сети, как это было бы с традиционными брандмауэрами.
Google Cloud оценивает правила иерархической политики брандмауэра и правила брандмауэра VPC в следующем порядке:
Если политика брандмауэра связана с организацией, Google Cloud оценивает правила этой политики, применяемые к виртуальной машине. Каждое правило приводит к разрешению или запрещению подключений, или правило может предписать оценке брандмауэра перейти на следующий уровень иерархии, который является либо папкой, либо сетью VPC.
Google Cloud оценивает правила политики, связанные с каждой папкой, начиная с верхней папки в организации и заканчивая дочерними папками, если таковые имеются.
Оценка каждого правила приводит к разрешению или запрещению подключений, или правило может предписать оценке брандмауэра перейти на следующий уровень иерархии, который является либо другой папкой, либо сетью VPC.
Наконец, оцениваются правила брандмауэра VPC. Правила брандмауэра VPC либо разрешают, либо запрещают подключения.
Сведения об иерархической политике брандмауэра¶
Правила иерархической политики брандмауэра определяются в ресурсе политики брандмауэра, который действует как контейнер для правил брандмауэра. Правила, определенные в политике брандмауэра, не применяются до тех пор, пока политика не будет связана с узлом (организацией или папкой).
Одна политика может быть связана с несколькими узлами. Если вы измените правило в политике, это изменение правила будет применено ко всем текущим связанным узлам.
С узлом может быть связана только одна политика брандмауэра. Иерархические правила политики брандмауэра и правила брандмауэра VPC оцениваются в четко определенном порядке.
Политика брандмауэра, не связанная ни с какими узлами, является несвязанной иерархической политикой брандмауэра.
Названия политик¶
Когда вы создаете новую политику, Google Cloud автоматически создает идентификатор для этой политики. Кроме того, вы также указываете краткое название политики. При использовании интерфейса gcloud для обновления существующей политики вы можете ссылаться либо на сгенерированный системой идентификатор, либо на комбинацию короткого имени и идентификатора вашей организации. При использовании API для обновления политики необходимо указать сгенерированный системой идентификатор.
Приоритет¶
В отличие от правил брандмауэра VPC, где несколько правил могут иметь одинаковый приоритет, правила иерархической политики брандмауэра должны иметь определенный приоритет, и каждый приоритет должен быть уникальным в рамках политики брандмауэра.
Правила иерархической политики брандмауэра не имеют имен. Вместо этого сама политика брандмауэра имеет идентификатор и имя, и каждое правило в ней имеет уникальный номер приоритета.
В рамках иерархической политики брандмауэра правила брандмауэра оцениваются в порядке приоритета, начиная с правила с наивысшим приоритетом (наименьшим числом). Таким образом, правило с приоритетом 0 в политике, назначенной узлу организации, переопределяет любое другое правило в организации. Хорошей практикой является присвоение правилам номеров приоритета, которые позволяют вставлять их позже (например, 100, 200, 300).
Action on match (Действия при совпадении)¶
allow(позволять)¶
Иерархическое правило разрешения политики брандмауэра переопределяет любое правило запрета с более низким приоритетом или на более низком уровне иерархии. Используйте правила разрешения в политике организации или папок, чтобы безоговорочно разрешить определенные типы подключений ко всем виртуальным машинам в этом узле иерархии.
Например, если у вас есть централизованно управляемые проберы, которые отслеживают все виртуальные машины в вашей организации, вы можете создать правило разрешения на уровне организации, чтобы гарантировать, что запросы с IP-адресов проберов не блокируются какой-либо сетью в любом проекте.
deny отрицать¶
Правило запрета иерархической политики брандмауэра переопределяет любое правило разрешения с более низким приоритетом или на более низком уровне иерархии.
Например, если вы хотите убедиться, что ни к одной из виртуальных машин в вашей организации нельзя получить доступ из определенного диапазона IP-адресов, вы можете создать правило запрета для этого диапазона.
goto_next¶
Указывает брандмауэру переместить оценку брандмауэра на следующий более низкий уровень иерархии. Вы можете использовать это для делегирования определенных типов соединений для управления более низкими уровнями.
Цели¶
Вы можете указать, к каким целевым сетям и учетным записям целевых служб применяется правило иерархической политики брандмауэра.
Целевые сети (целевые ресурсы)¶
Вы можете указать целевые сети, чтобы ограничить правило политики иерархического брандмауэра виртуальными машинами в указанных сетях. Указание сетей VPC в правиле позволяет вам контролировать, какие сети настроены с помощью этого правила.
В сочетании с goto_next или allow указание целевых сетей позволяет создавать исключения для определенных сетей, когда вы хотите определить политику ограничений в противном случае.
Целевые учетные записи служб¶
Вы можете указать целевые учетные записи служб, чтобы ограничить правило политики иерархического брандмауэра виртуальными машинами, которые работают с доступом к указанным учетным записям служб.
Направление правила определяет, являются ли целевые объекты правила экземплярами источника или назначения. Экземпляры включают экземпляры виртуальных машин, кластеры GKE и экземпляры гибкой среды App Engine.
Если направление правила - вход, цель определяет экземпляры назначения.
Если направление правила - исходящее, цель определяет исходные экземпляры.
Указание целевых сетей и учетных записей целевых служб необязательно:
Если целевые сети не указаны, правило применяется ко всем сетям VPC в узле, с которым связана политика.
Если учетные записи целевых служб не указаны, правило применяется ко всем экземплярам виртуальных машин на узле, с которым связана политика.
Если указаны как целевые сети, так и учетные записи целевых служб, правило применяется только к экземплярам виртуальных машин, которые соответствуют обоим целевым критериям.
Протоколы и порты¶
Как и в правилах брандмауэра VPC, при создании правила необходимо указать один или несколько ограничений протокола и порта. При указании TCP или UDP в правиле вы можете указать протокол, протокол и порт назначения или протокол и диапазон портов назначения; вы не можете указать только порт или диапазон портов. Кроме того, вы можете указать только порты назначения. Правила, основанные на исходных портах, не поддерживаются.
Для ICMP IPv4 укажите icmp. Правила брандмауэра не поддерживают указание типов и кодов ICMP.
В правилах брандмауэра можно использовать следующие имена протоколов: tcp, udp, icmp (для ICMP IPv4), esp, ah, sctp и ipip. Для всех остальных протоколов используйте номера протоколов IANA
Многие протоколы используют одно и то же имя и номер как в IPv4, так и в IPv6, но некоторые протоколы, такие как ICMP, этого не делают.
Протокол IPv6 “Переход за переходом” не поддерживается в правилах брандмауэра.
Регистрация¶
Ведение журнала для правил иерархической политики брандмауэра работает так же, как и для ведения журнала правил брандмауэра VPC, за исключением следующего:
Поле ссылки содержит идентификатор политики брандмауэра и номер, указывающий иерархический уровень узла, к которому прикреплена политика. Например, 0 означает, что политика применяется к организации, а 1 означает, что политика применяется к папке верхнего уровня в организации.
Журналы для правил иерархической политики брандмауэра включают поле target_resource, которое определяет сети VPC, к которым применяется правило.
Ведение журнала может быть включено только для правил разрешения и запрета; оно не может быть включено для правил goto_next.
Заранее определенные правила¶
Все иерархические политики брандмауэра имеют четыре предопределенных правила goto_next с наименьшим приоритетом. Эти правила применяются к любым подключениям, которые не соответствуют явно определенному правилу в политике, в результате чего такие подключения передаются в политики более низкого уровня или сетевые правила.
Правила IPv4:
Исходящее правило, назначением которого является 0.0.0.0/0, с очень низким приоритетом (2147483646), которое отправляет обработку соединения на следующий более низкий уровень оценки (goto_next).
Правило входа, источником которого является 0.0.0.0/0, с очень низким приоритетом (2147483647), которое отправляет обработку соединения на следующий более низкий уровень оценки (goto_next).
Правила IPv6:
Исходящее правило, адресатом которого является ::/0, с очень низким приоритетом (2147483644), которое отправляет обработку соединения на следующий более низкий уровень оценки (goto_next).
Правило входа, источником которого является ::/0, с очень низким приоритетом (2147483645), которое отправляет обработку соединения на следующий более низкий уровень оценки (goto_next).
Эти предопределенные правила видны, но их нельзя изменить или удалить. Эти правила отличаются от подразумеваемых и предварительно заполненных правил сети VPC.
Компоненты правил брандмауэра¶
Каждое правило брандмауэра состоит из следующих компонентов конфигурации:
Направление подключения: правила входа применяются к входящим подключениям из указанных источников к целевым объектам Google Cloud, а правила выхода применяются к подключениям, отправляемым в указанные пункты назначения из целевых объектов.
Числовой приоритет, который определяет, применяется ли правило. Применяется только правило с наивысшим приоритетом (номер с наименьшим приоритетом), другие компоненты которого соответствуют трафику; конфликтующие правила с более низкими приоритетами игнорируются.
Действие при совпадении, либо разрешающее, либо запрещающее, которое определяет, разрешает ли правило или блокирует соединения.
Статус применения правила брандмауэра: Вы можете включать и отключать правила брандмауэра, не удаляя их.
Целевой объект, определяющий экземпляры (включая кластеры GKE и экземпляры гибкой среды App Engine), к которым применяется правило.
Фильтр источника для входных правил или фильтр назначения для выходных правил.
Протокол (например, TCP, UDP или ICMP) и порт назначения.
Опция логических журналов, которая регистрирует соединения, соответствующие правилу, в облачном журнале.
Роли управления идентификацией и доступом (IAM)¶
Примечание. В предварительных версиях иерархических политик брандмауэра использовались роли IAM compute.orgsecuritypolicyadmin и compute.orgsecuritypolicyuser. Эти роли объединяли разрешения для иерархических политик брандмауэра и облачных доспехов Google. Чтобы разделить эти разрешения, мы переходим к ролям compute.orgfirewallpolicyadmin и compute.orgfirewallpolicyuser для иерархических политик брандмауэра. Предыдущие роли продолжают работать, но мы рекомендуем перейти на новые роли как можно скорее. Важно: Облачная консоль еще не поддерживает новые роли compute.orgfirewallpolicyadmin и compute.orgfirewallpolicyuser. В настоящее время пользователям облачной консоли необходимо иметь роли compute.orgsecuritypolicyadmin и/или compute.orgsecuritypolicyuser для создания и использования иерархических политик брандмауэра. Новые роли поддерживаются в инструменте командной строки gcloud и API.Роли
IAM управляют следующими действиями в отношении иерархических политик брандмауэра:
Создание политики, которая находится на определенном узле
Связывание политики с определенным узлом
Изменение существующей политики
Просмотр действующих правил брандмауэра для конкретной сети или виртуальной машины
В следующей таблице описано, какие роли необходимы для каждого шага: