Иерархическая политика брандмауэра с тегами, управляемыми IAM

1. Введение

Межсетевой экран нового поколения в облаке (NGFW)

Cloud Next Generation Firewall — это полностью распределенный межсетевой экран с расширенными возможностями защиты, микросегментацией и повсеместным охватом для защиты ваших рабочих нагрузок Google Cloud от внутренних и внешних атак.

Облачный межсетевой экран нового поколения (NGFW) обладает следующими преимуществами:

  • Распределенная служба межсетевого экрана: Cloud NGFW обеспечивает сохранение состояния и полностью распределенное применение мер безопасности на уровне хоста для каждой рабочей нагрузки, что позволяет реализовать архитектуру безопасности с нулевым доверием.
  • Упрощенная настройка и развертывание: Cloud NGFW реализует сетевые и иерархические политики межсетевого экрана, которые можно прикрепить к узлу иерархии ресурсов. Эти политики обеспечивают единообразную работу межсетевого экрана во всей иерархии ресурсов Google Cloud.
  • Детальный контроль и микросегментация: сочетание политик межсетевого экрана и тегов, управляемых системой управления идентификацией и доступом (IAM), обеспечивает точный контроль как для трафика между центрами сети (север-юг), так и для трафика между центрами сети (восток-запад), вплоть до отдельной виртуальной машины, в сетях виртуальных частных облаков (VPC).

Политики сетевого брандмауэра

Политика сетевого брандмауэра выступает в качестве контейнера для правил брандмауэра. Правила, определенные в политике сетевого брандмауэра, не применяются нигде, пока политика не будет связана с сетью VPC. Каждая сеть VPC может иметь одну связанную с ней политику сетевого брандмауэра. Политики сетевого брандмауэра поддерживают теги (или просто теги), управляемые IAM, в правилах брандмауэра и могут использоваться для обеспечения идентификации рабочей нагрузки.

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

С внедрением политик сетевого брандмауэра, политики брандмауэра Google Cloud теперь состоят из следующих компонентов:

  1. Иерархическая политика брандмауэра
  2. Правила брандмауэра VPC
  3. Глобальная политика сетевого межсетевого экрана и региональная политика сетевого межсетевого экрана

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

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

Наконец, у нас также есть подразумеваемые правила брандмауэра , которые присутствуют в каждой сети VPC:

  • Правило исходящего трафика, действие которого — разрешить, пункт назначения — 0.0.0.0/0
  • Правило входящего трафика, действие которого — запрет, источник — 0.0.0.0/0

По умолчанию последовательность применения мер безопасности показана на следующей диаграмме:

86df8f0d19c64e80.png

Теги, управляемые IAM

Новые теги, интегрированные в правила политики брандмауэра, представляют собой ресурсы в виде пар «ключ-значение», определенные на уровне организации или проекта в иерархии ресурсов Google Cloud. Такой тег, как следует из названия, содержит управление доступом IAM, определяющее, кто и что может делать с этим тегом. Например, разрешения IAM позволяют указать, какие субъекты могут назначать значения тегам и какие субъекты могут прикреплять теги к ресурсам. После применения тега к ресурсу правила политики брандмауэра могут использовать его для разрешения и запрета трафика.

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

Не следует путать теги с сетевыми тегами ; последние представляют собой строки, которые можно добавить к экземплярам Compute Engine; они связаны с экземпляром и исчезают при выводе экземпляра из эксплуатации. Правила брандмауэра VPC могут включать сетевые теги, но поскольку они не рассматриваются как облачные ресурсы, на них не распространяется контроль доступа IAM. Подробнее о различиях см. на этой странице .

2. What you'll learn

  • Как создать теги, управляемые IAM, для использования с Cloud NGFW и в глобальной области видимости.
  • Как присвоить теги виртуальным машинам.
  • Как создать иерархическую политику брандмауэра и связать её с папкой.
  • Как создать правило брандмауэра в иерархической политике брандмауэра и указать источник и цель с помощью тегов, управляемых IAM.

3. Общая архитектура лаборатории

1bfe78ad755496e5.png

Организация и папки:

  • Вам нужно будет создать две папки, folder1 и folder2 , непосредственно в рамках вашей организации.

Проекты:

  • Внутри folder1 вы создадите проект хоста . Этот проект будет содержать сеть Shared VPC.
  • Внутри folder2 вы создадите проект службы . Этот проект будет содержать виртуальные машины, использующие общую VPC.

Сетевые технологии:

  • В основном проекте будет создана сеть VPC с именем mynet , которая будет настроена как общая сеть VPC (Shared VPC ). Это позволит ресурсам в сервисном проекте использовать эту сеть.
  • В сервисном проекте будут созданы две виртуальные машины, которые будут подключены к общей виртуальной частной сети mynet .

Теги, управляемые IAM:

  • Вам потребуется создать управляемый IAM тег с именем http_tags и двумя значениями: http_server и http_client на уровне организации. Эти теги/значения будут использоваться для идентификации виртуальных машин и применения к ним правил брандмауэра.

Политики брандмауэра:

  • Будет создана иерархическая политика брандмауэра , связанная с folder1 . Правило в рамках этой политики будет использовать теги, управляемые IAM, для разрешения трафика от http-client к http-server через порт 80.
  • В проекте хоста будет создана политика сетевого брандмауэра , связанная с VPC mynet . Эта политика будет включать правило, разрешающее доступ IAP по SSH к виртуальным машинам в целях тестирования.

4. Этапы подготовки

Для начала настройте необходимые роли IAM, сетевую инфраструктуру и экземпляры в вашей организации Google Cloud.

Для работы в лаборатории требуются роли IAM.

Начнем с назначения необходимых ролей IAM учетной записи GCP на уровне организации.

  • Администратор организации ( roles/resourcemanager.organizationAdmin ) Эта роль позволяет управлять политиками IAM и просматривать политики организации для организаций, папок и проектов.
  • Администратор тегов ( roles/resourcemanager.tagAdmin ) Эта роль позволяет создавать, обновлять и удалять защищенные теги.
  • Роль пользователя для присвоения тегов ( roles/resourcemanager.tagUser ) Эта роль позволяет получить доступ к списку защищенных тегов и управлять их связью с ресурсами.
  • Роль администратора политики брандмауэра организации вычислительных ресурсов ( roles/compute.orgFirewallPolicyAdmin ) предоставляет вам полный контроль над политиками брандмауэра организации Compute Engine.
  • Роль администратора ресурсов вычислительной организации ( roles/compute.orgSecurityResourceAdmin ) предоставляет вам полный контроль над ассоциациями политик брандмауэра Compute Engine с организацией или папкой.
  • Администратор вычислительной сети ( roles/compute.networkAdmin ) Эта роль предоставляет вам полный контроль над сетевыми ресурсами Compute Engine.
  • Администратор вычислительных экземпляров (бета-версия) ( roles/compute.instanceAdmin ) Эта роль предоставляет вам полный контроль над ресурсами экземпляра Compute Engine.
  • Администратор ведения журналов ( roles/logging.admin ) Эта роль предоставляет вам доступ ко всем разрешениям на ведение журналов, а также к зависимым разрешениям.
  • Администратор учетных записей служб ( roles/iam.serviceAccountAdmin ) Эта роль позволяет создавать и управлять учетными записями служб.
  • Администратор использования сервиса ( roles/serviceusage.serviceUsageAdmin ) Эта роль позволяет включать, отключать и проверять состояния сервиса, контролировать операции, а также управлять квотой и выставлением счетов для потребительского проекта.
  • Роль администратора общей виртуальной частной сети ( roles/compute.xpnAdmin ) позволяет администрировать общую виртуальную частную сеть (XPN).

Создавайте папки и проекты.

Внутри Cloud Shell выполните следующие действия для создания folder1 и folder2 :

gcloud auth login

export org_id=$(gcloud organizations list --format='value(ID)')
export BILLING_ACCOUNT_ID=$(gcloud billing accounts list --format='value(ACCOUNT_ID)')
export folder1=[FOLDER1 NAME]
export folder2=[FOLDER2 NAME]
export hostproject=[HOST PROJECT NAME]
export serviceproject=[SERVICE PROJECT NAME]
export regionname=[REGION NAME]
export zonename=[COMPUTE ZONE NAME]

gcloud resource-manager folders create --display-name=$folder1 --organization=$org_id
export folder1_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder1" --format="value(ID)")
gcloud resource-manager folders create --display-name=$folder2 --organization=$org_id
export folder2_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder2" --format="value(ID)")

Inside Cloud Shell, perform the following to create the host project under folder1 :

gcloud projects create  --name=$hostproject --folder=$folder1_id

Вы увидите следующее. Нажмите Y, чтобы создать проект с новым идентификатором проекта.

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

Запишите идентификатор проекта. В Cloud Shell выполните следующие действия, чтобы экспортировать его в hostproject_id:

export hostproject_id=[HOSTPROJECT ID]

Внутри Cloud Shell выполните следующие действия, чтобы связать основной проект с платежным аккаунтом:

gcloud billing projects link $hostproject_id \
--billing-account=$BILLING_ACCOUNT_ID

Внутри Cloud Shell выполните следующие действия для создания проекта службы в folder2 :

gcloud projects create  --name=$serviceproject --folder=$folder2_id

Вы увидите следующее. Нажмите Y, чтобы создать проект с новым идентификатором проекта.

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

Запишите идентификатор проекта. В Cloud Shell выполните следующие действия, чтобы экспортировать его в serviceproject_id:

export serviceproject_id=[SERVICEPROJECT ID]

Внутри Cloud Shell выполните следующие действия, чтобы связать проект сервиса с платежным аккаунтом:

gcloud billing projects link $serviceproject_id \
--billing-account=$BILLING_ACCOUNT_ID

Создание тегов, управляемых IAM.

Тег — это пара «ключ-значение», которую можно прикрепить к организации, папке или проекту. Дополнительные сведения см. в разделе «Создание и управление тегами и необходимые разрешения» .

Мы создаём один тег на уровне организации, http-tags . Назначение тега — использование Cloud NGFW. Мы не ограничиваем область действия одной сетью — тег имеет глобальную область действия. А позже мы применим этот тег к виртуальным машинам, созданным в сервисном проекте в folder2 .

Внутри Cloud Shell выполните следующие действия: 

gcloud resource-manager tags keys create http_tags \
    --parent=organizations/$org_id \
    --purpose GCE_FIREWALL \
    --purpose-data organization=auto

Мы будем использовать идентификатор ключа тега для аннотирования виртуальной машины во время её создания. В Cloud Shell выполните следующие действия, чтобы получить идентификатор ключа тега: 

export http_tags_id=$(gcloud resource-manager tags keys describe $org_id/http_tags --format="value(name)")
echo $http_tags_id

Внутри Cloud Shell выполните следующие действия, чтобы создать два новых значения тегов: http_server и http_client : 

 gcloud resource-manager tags values create http_server \
      --parent $org_id/http_tags
 gcloud resource-manager tags values create http_client \
      --parent $org_id/http_tags

Мы будем использовать идентификатор тега и идентификатор значения тега для аннотирования виртуальной машины во время ее создания. В Cloud Shell выполните следующие действия, чтобы получить идентификатор значения тега для http_server и http_client : 

export http_tags_http_server_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_server --format="value(name)")
echo $http_tags_http_server_id

export http_tags_http_client_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_client --format="value(name)")
echo $http_tags_http_client_id

Включите API в основном проекте и проекте сервиса.

Внутри Cloud Shell выполните следующие действия: 

gcloud services enable compute.googleapis.com --project=$serviceproject_id
gcloud services enable compute.googleapis.com --project=$hostproject_id

Создайте VPC в основном проекте.

В хост-проекте создайте сеть VPC с пользовательским режимом подсети и выполните следующие действия в Cloud Shell: 

gcloud compute networks create mynet \
    --subnet-mode=custom \
    --project=$hostproject_id

Создайте подсети в основном проекте.

Внутри Cloud Shell выполните следующие действия для создания подсети IPv4: 

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/28 \
    --region=$regionname \
    --project=$hostproject_id

Включите Shared VPC в основном проекте.

Внутри Cloud Shell выполните следующие действия, чтобы включить Shared VPC в проекте хоста: 

gcloud compute shared-vpc enable $hostproject_id

Подключите сервисный проект для общей VPC в хост-проекте.

Внутри Cloud Shell выполните следующие действия, чтобы подключить проект службы для общей VPC к основному проекту: 

gcloud compute shared-vpc associated-projects add $serviceproject_id --host-project=$hostproject_id

Создайте Cloud Router и Cloud NAT в проекте хоста.

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

gcloud compute routers create $regionname-cr \
   --network=mynet \
   --region=$regionname \
   --project=$hostproject_id
gcloud compute routers nats create $regionname-nat \
    --router=$regionname-cr \
    --region=$regionname \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips \
    --project=$hostproject_id

Создайте экземпляры в проекте сервиса.

In the service project, create two instances in the subnets you just created in the shared VPC in the hostproject. One instance is named http-server and we annotate the tag of http_tags with the value of http_server . The other instance is named http-client and we annotate the tag of http_tags with the value of http_client . Run the following command(s) in Cloud Shell: 

gcloud compute instances create http-client \
    --project=$serviceproject_id \
   --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_client_id

gcloud compute instances create http-server \
    --project=$serviceproject_id \
    --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_server_id \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "I am a Http Server." | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Запишите внутренний IP-адрес http-server . Мы будем использовать его на следующем этапе проверки правил брандмауэра. 

export http_server_ip=$(gcloud compute instances describe http-server --zone $zonename --format='value(networkInterfaces[0].networkIP)' --project $serviceproject_id)
echo $http_server_ip

5. Создайте глобальную политику сетевого брандмауэра в основном проекте.

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

gcloud config set project $hostproject_id
gcloud compute network-firewall-policies create  mynet-fw-policy \
--global \
--project=$hostproject_id
gcloud compute network-firewall-policies associations create \
    --firewall-policy=mynet-fw-policy \
    --network=mynet \
    --name=mynet-fw-policy \
    --global-firewall-policy \
    --project=$hostproject_id

Чтобы разрешить IAP подключаться к вашим виртуальным машинам, создайте правило брандмауэра в политике сетевого брандмауэра:

  • Применяется ко всем экземплярам виртуальных машин, к которым вы хотите обеспечить доступ с помощью IAP.
  • Разрешает входящий трафик из диапазона IP-адресов 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP-трафика. 
gcloud compute network-firewall-policies rules create 1000 \
    --action=ALLOW \
    --firewall-policy=mynet-fw-policy \
    --description="mynet-allow-iap" \
    --direction=INGRESS \
    --src-ip-ranges=35.235.240.0/20 \
    --layer4-configs=tcp:22  \
    --global-firewall-policy \
    --project=$hostproject_id

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

6. Проверьте доступ с виртуальной машины http-клиента к виртуальной машине http-сервера.

Подключитесь по SSH к виртуальной машине с именем http-client и проверьте, может ли она получить доступ к http-server по порту HTTP 80.

Внутри Cloud Shell выполните следующие действия: 

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

Для доступа к веб-серверу используйте команду curl.

curl -m 10 [http_server_ip]

Вы увидите результат выполнения команды curl. В брандмауэре отсутствует правило, разрешающее использование порта 80 для http-server .

Время ожидания соединения истекло через 10000 миллисекунд.

Чтобы вернуться в Cloud Shell, завершите сеанс SSH. 

exit

7. Создайте иерархическую политику межсетевого экрана и правила межсетевого экрана.

Мы создадим иерархическую политику брандмауэра в folder1 и свяжем эту политику с folder1 . Правила брандмауэра в этой политике будут применяться к хост-проекту в folder1 .

Создание иерархической политики брандмауэра 

gcloud compute firewall-policies create \
  --folder=$folder1_id \
  --short-name=my-folder1-fw-policy

Создайте правило брандмауэра в иерархической политике брандмауэра.

Это правило позволяет виртуальным машинам со значением тега http_tags/http_client получать доступ к виртуальным машинам со значением тега http_tags/http_server через TCP-порт 80. 

gcloud compute firewall-policies rules create 100 \
  --organization=$org_id \
  --firewall-policy my-folder1-fw-policy \
  --direction=INGRESS \
  --layer4-configs=tcp:80 \
  --action=allow \
  --src-secure-tags=$org_id/http_tags/http_client \
  --target-secure-tags=$org_id/http_tags/http_server \
  --description=folder1-allow-http

Связать иерархическую политику брандмауэра с папкой 1. 

gcloud compute firewall-policies associations create \
   --firewall-policy=my-folder1-fw-policy \
   --folder=$folder1_id \
   --name=my-folder1-fw-policy\
   --organization=$org_id

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

8. Проверьте доступ с виртуальной машины http-клиента к виртуальной машине http-сервера.

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

Внутри Cloud Shell выполните следующие действия: 

gcloud compute networks get-effective-firewalls mynet --project=$hostproject_id

Вы увидите унаследованную иерархическую политику межсетевого экрана примерно такого вида: 

TYPE: org-firewall
FIREWALL_POLICY_NAME: <NUMBER_FOR_YOUR_FW_POLICY>
FIREWALL_POLICY_PRIORITY: 
PRIORITY: 100
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES:

You will see the network firewall policy to the VPC like this:
TYPE: network-firewall-policy
FIREWALL_POLICY_NAME: mynet-fw-policy
FIREWALL_POLICY_PRIORITY: 1000
PRIORITY: 1000
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES: 35.235.240.0/20

Подключитесь по SSH к виртуальной машине с именем http-client и проверьте, может ли она получить доступ к http-server по порту HTTP 80.

Внутри Cloud Shell выполните следующие действия: 

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

Для доступа к веб-серверу используйте команду curl.

curl [http_server_ip]

Вы увидите, что команда curl успешно возвращает ответ от http-server . 

I am a Http Server.

Правило входящего трафика брандмауэра из иерархической политики брандмауэра разрешает доступ с http-client к http-server через порт 80.

Чтобы вернуться в Cloud Shell, завершите сеанс SSH. 

exit

9. Уборка

Очистка виртуальных машин в рамках проекта обслуживания

Внутри Cloud Shell выполните следующие действия: 

gcloud compute instances delete http-server --zone $zonename --project=$serviceproject_id
gcloud compute instances delete http-client --zone $zonename --project=$serviceproject_id

Очистка иерархической политики брандмауэра

Внутри Cloud Shell выполните следующие действия: 

gcloud compute firewall-policies associations delete my-folder1-fw-policy \
   --firewall-policy=my-folder1-fw-policy \
   --organization=$org_id
gcloud compute firewall-policies rules delete 100 \
  --organization=$org_id \
  --firewall-policy=my-folder1-fw-policy
gcloud compute firewall-policies delete my-folder1-fw-policy \
  --organization=$org_id

Очистка тегов на уровне организации.

Внутри Cloud Shell выполните следующие действия: 

gcloud resource-manager tags values delete $http_tags_http_server_id
gcloud resource-manager tags values delete $http_tags_http_client_id
gcloud resource-manager tags keys delete $http_tags_id

Приведите в порядок основной проект.

Внутри Cloud Shell выполните следующие действия: 

gcloud compute shared-vpc associated-projects remove $serviceproject_id --host-project=$hostproject_id 
gcloud compute shared-vpc disable $hostproject_id
gcloud projects delete $hostproject_id

Убрать с построек в рамках сервисного проекта

Внутри Cloud Shell выполните следующие действия: 

gcloud projects delete $serviceproject_id

Очистка папок

Внутри Cloud Shell выполните следующие действия: 

gcloud resource-manager folders delete $folder1_id
gcloud resource-manager folders delete $folder2_id

10. Поздравляем!

Вы успешно протестировали иерархическую политику брандмауэра с тегами, управляемыми IAM.