Лаборатория кода Cloud Secure Web Proxy (SWP)

1. Введение

Облачный защищенный веб-прокси

Cloud SWP — это облачный сервис, предоставляющий безопасный веб-прокси для защиты исходящего веб-трафика (HTTP/S). Вы настраиваете свои клиенты на явное использование Cloud SWP в качестве прокси. Веб-запросы могут поступать из следующих источников:

• Экземпляры виртуальных машин (ВМ)
• Контейнеры
• Бессерверная среда, использующая бессерверный коннектор.
• Рабочие нагрузки в рамках пиринга VPC
• Рабочие нагрузки вне Google Cloud, подключенные через Cloud VPN или Cloud Interconnect.

Cloud SWP обеспечивает гибкие и детализированные политики на основе облачных идентификаторов и веб-приложений.

Преимущества

Ниже приведены некоторые примеры преимуществ, которые Cloud SWP может предоставить организации:

Миграция в Google Cloud

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

Доступ к надежным внешним веб-сервисам

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

Контролируемый доступ к ненадежным веб-сервисам

С помощью Cloud SWP можно обеспечить контролируемый доступ к ненадежным веб-сервисам. Cloud SWP выявляет трафик, не соответствующий политике, и записывает его в Cloud Logging (Logging). Таким образом, вы можете отслеживать использование интернета, обнаруживать угрозы для вашей сети и реагировать на них.

Детальный контроль политик для API Google.

С помощью Cloud SWP можно задавать детализированные политики для API Google. Например, можно устанавливать политики на уровне сегментов/объектов, используя язык выражений Common Expression Language (CEL).

Поддерживаемые функции

Cloud SWP поддерживает следующие функции:

Явная прокси-служба

Для использования прокси-сервера клиенты должны быть явно настроены. Прокси-сервер Cloud SWP изолирует клиентов от интернета, создавая новые TCP-соединения от имени клиента.

Автомасштабирование облачных прокси-серверов Cloud SWP Envoy

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

Модульные политики доступа к выходу

Cloud SWP поддерживает следующие политики исходящего трафика:

• Идентификация источника осуществляется на основе защищенных тегов, учетных записей служб или IP-адресов.
• Направления поиска определяются на основе URL-адресов и имен хостов.
• Запросы, основанные на методах, заголовках или URL-адресах. URL-адреса могут быть указаны с помощью списков, подстановочных символов или шаблонов.
• Сквозное шифрование: туннели клиент-прокси могут передавать данные по протоколу TLS. Cloud SWP также поддерживает HTTP/S CONNECT для инициируемых клиентом сквозных TLS-соединений с целевым сервером.

Упрощенная интеграция облачного NAT

Cloud NAT автоматически выделяет дополнительные публичные IP-адреса при увеличении количества прокси-серверов, обслуживающих трафик Cloud SWP.

Также можно вручную задать статические публичные IP-адреса для тех, кто хочет иметь известные исходящие IP-адреса.

Интеграция Cloud Audit Logs и пакета инструментов Google Cloud для управления операциями.

Cloud Audit Logs и пакет инструментов Google Cloud для управления операциями регистрируют административные действия и запросы доступа к ресурсам, связанным с Cloud SWP. Они также записывают метрики и журналы транзакций для запросов, обрабатываемых прокси-сервером.

Проверка TLS

Secure Web Proxy предлагает сервис проверки TLS-трафика, который позволяет перехватывать TLS-трафик, проверять зашифрованный запрос и применять политики безопасности.

• Тесная интеграция со службой центров сертификации (CAS), представляющей собой высокодоступное и масштабируемое хранилище для частных центров сертификации.
• Возможность использовать собственный корневой центр доверия при необходимости. Вы также можете использовать существующий корневой центр сертификации для подписи подчиненных центров сертификации, хранящихся в CAS. При желании вы можете сгенерировать новый корневой сертификат в CAS.
• Детальные критерии расшифровки с использованием SessionMatcher и ApplicationMatcher в правилах политики Secure Web Proxy. Эти критерии включают сопоставление хостов, присутствующих в списках URL-адресов, регулярные выражения, диапазоны IP-адресов и аналогичные выражения. При необходимости критерии можно комбинировать с логическими выражениями.
• Каждая политика защищенного веб-прокси может быть настроена со своей собственной политикой проверки TLS и пулом центров сертификации. В качестве альтернативы, несколько политик защищенного веб-прокси могут использовать одну и ту же политику проверки TLS.

Что вы узнаете

• Как развернуть и управлять Cloud SWP.

Что вам понадобится

• Знание развертывания экземпляров и настройки сетевых компонентов.
• Знания по настройке межсетевого экрана VPC

2. Тестовая среда

В этом практическом занятии будет использоваться одна VPC. Вычислительные ресурсы в этой среде будут выходить через Cloud SWP, как показано на диаграмме ниже.

В этой лабораторной работе у нас будет 2 виртуальные машины с рабочей нагрузкой.

Клиент A будет настроен на отправку всех HTTP/HTTPS-запросов в облачный SWP.

Клиент B НЕ будет настроен на явную отправку HTTP/HTTPS-запросов в облачный SWP, а вместо этого будет использовать облачный NAT для трафика, направленного в интернет.

Примечание: Cloud SWP поддерживает общие VPC, рабочие нагрузки в пиринговых VPC, а также рабочие нагрузки за пределами Google Cloud, подключенные через Cloud VPN или Cloud Interconnect.

3. Прежде чем начать

Для работы в Codelab требуется всего один проект.

Внутри Cloud Shell убедитесь, что идентификатор вашего проекта указан правильно.

Примечание : идентификатор организации можно получить с помощью консоли Cloud Console или gcloud projects get-ancestors [project-id] .

Примечание : Если вы уже работали с GCP и у вас установлен gcloud , он обновлен и авторизован для работы в вашем проекте, вы можете использовать свой локальный компьютер вместо Google Cloud Shell для выполнения этой лабораторной работы. Если не указано иное, все команды gcloud следует запускать с компьютера, на котором уже установлен gcloud или Cloud Shell.

export project_id=`gcloud config list --format="value(core.project)"`
export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"`
export region=us-west1
export zone=us-west1-a
export prefix=codelab-swp
export member="serviceAccount:service-$[e-mail]"

4. Включите API.

Разрешите использование продуктов через API.

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com

5. Создайте сеть VPC, подсеть и подсеть только для прокси.

Примечание : Убедитесь, что API Compute Engine включен. Если при выполнении приведенных ниже команд вы получаете сообщение об ошибке или не уверены, выполните команду gcloud services enable compute.googleapis.com и попробуйте снова.

Сеть VPC

Создайте VPC codelab-swp-vpc:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

Подсеть

Создайте соответствующие подсети в выбранном регионе:

gcloud compute networks subnets create $prefix-vpc-subnet \
   --range=10.10.10.0/24 --network=$prefix-vpc --region=$region

Подсеть только для прокси

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

gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23

6. Создайте правила брандмауэра.

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

• Применяется ко всем экземплярам виртуальных машин, к которым вы хотите обеспечить доступ с помощью IAP.
• Разрешает входящий трафик из диапазона IP-адресов 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP-трафика.

Из Cloudshell:

gcloud compute firewall-rules create $prefix-allow-iap-proxy \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20

7. Создайте облачный маршрутизатор и облачный NAT.

Создайте облачный маршрутизатор для облачного NAT.

gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc

Создайте облачный NAT-шлюз для клиента B.

gcloud compute routers nats create $prefix-nat-gw-$region \
--router=$prefix-cr \
--router-region=$region \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges

8. Создайте политику безопасности шлюза.

Создайте YAML-файл, содержащий необходимую информацию для политики:

cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF

Выполните команду gcloud, чтобы создать политику из YAML-файла:

gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}

9. Создайте правило политики безопасности шлюза.

Создайте YAML-файл, содержащий правила. Эти правила представлены в формате Common Expression Language (CEL). В этой лабораторной работе будет использоваться простое правило, которое разрешит трафик к доменам .com и заблокирует все остальные:

cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF

Теперь мы можем привязать это правило к политике безопасности шлюза:

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

10. Создайте сертификат и загрузите его в Cloud Certificate Manager.

Создайте сертификат для завершения обработки трафика рабочей нагрузки:

openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \
  "subjectAltName = DNS:www.codelab-swp.com"

Загрузите сертификат в Cloud Certificate Manager, чтобы SWP мог ссылаться на него в политике шлюза безопасности.

gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem

11. Создайте шлюз SWP.

Создайте YAML-файл для шлюза SWP, в котором будут указаны ранее такие данные, как сертификат, политика безопасности шлюза, сеть и подсеть.

Примечание : Адрес для IP-адреса 10.10.10.50 задается вручную в этом YAML-файле. Именно этот адрес будет использовать SWP, и все рабочие нагрузки будут явно настраивать HTTP/HTTPS-трафик на этот адрес:

cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF

Создайте шлюз:

gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}

Подтвердите создание шлюза:

gcloud network-services gateways describe ${prefix}-swp --location ${region}

12. Создание вычислительных экземпляров

Примечание : В целях безопасности в этом практическом задании предполагается, что включена функция Identity-Aware Proxy для пересылки TCP-пакетов , позволяющая осуществлять SSH-доступ без назначения публичных IP-адресов экземплярам. Пожалуйста, настройте её перед продолжением.

Поскольку Cloud SWP использует явный прокси-сервер, нам необходимо явно указать IP-адрес прокси для трафика рабочей нагрузки. У клиента A вычислительного экземпляра будет установлена ​​переменная среды. У клиента B — нет.

Создайте вычислительные экземпляры ClientA и ClientB:

gcloud compute instances create clienta \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.10 \
   --zone $zone \
   --metadata startup-script='#! /bin/bash
apt-get update
sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment
sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment
'

gcloud compute instances create clientb \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.200 \
   --zone $zone \
   --metadata startup-script='#! /bin/bash
apt-get update
'

13. Сопоставление тестовых сессий

Подключитесь по SSH к недавно созданной вычислительной виртуальной машине "clienta". Для этой виртуальной машины установлена ​​переменная среды, позволяющая использовать Cloud SWP.

Из Cloudshell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Выполните несколько веб-запросов для проверки работоспособности. Нам требуется параметр –proxy-insecure, поскольку для этой лабораторной работы мы создали самоподписанный сертификат:

curl https://google.com --proxy-insecure

Ожидаемый результат:

davidtu@clienta:~$ curl https://google.com --proxy-insecure
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

Как видите, запрос был "успешным". Ожидаемо, что мы увидим перенаправление 301, поскольку веб-сайт перенаправляет на https://www.google.com .

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

curl https://google.com --proxy-insecure -v

Выделены некоторые выходные данные, отображающие сведения о прокси-подключении, сертификаты и пункт назначения.

davidtu@clienta:~$ curl https://google.com --proxy-insecure -v
* Uses proxy env variable https_proxy == 'https://10.10.10.50:443/'
*   Trying 10.10.10.50:443...
* Connected to 10.10.10.50 (10.10.10.50) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Proxy certificate:
*  subject: CN=www.codelab-swp.com
*  start date: Dec 12 17:16:35 2022 GMT
*  expire date: Dec 12 17:16:35 2023 GMT
*  issuer: CN=www.codelab-swp.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* allocate connect buffer!
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.74.0
> Proxy-Connection: Keep-Alive
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< date: Mon, 12 Dec 2022 19:22:04 GMT
< 
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
...

Вы можете попробовать другие домены .com, чтобы проверить их работоспособность.

Теперь давайте попробуем другие домены, отличные от .com, чтобы проверить поведение блокировки по умолчанию:

curl https://wikipedia.org --proxy-insecure

Ожидаемый результат:

curl: (56) Received HTTP code 403 from proxy after CONNECT

Аналогичным образом, просмотрите подробные журналы событий и убедитесь, что Cloud SWP блокирует этот трафик:

curl https://wikipedia.org --proxy-insecure -v

davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v
* Uses proxy env variable https_proxy == 'https://10.10.10.50:443/'
*   Trying 10.10.10.50:443...
* Connected to 10.10.10.50 (10.10.10.50) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Proxy certificate:
*  subject: CN=www.codelab-swp.com
*  start date: Dec 12 17:16:35 2022 GMT
*  expire date: Dec 12 17:16:35 2023 GMT
*  issuer: CN=www.codelab-swp.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* allocate connect buffer!
* Establish HTTP proxy tunnel to wikipedia.org:443
> CONNECT wikipedia.org:443 HTTP/1.1
> Host: wikipedia.org:443
> User-Agent: curl/7.74.0
> Proxy-Connection: Keep-Alive
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 403 Forbidden
< content-length: 13
< content-type: text/plain
< date: Mon, 12 Dec 2022 19:35:09 GMT
< connection: close
< 
* Received HTTP code 403 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Received HTTP code 403 from proxy after CONNECT

Для проверки работоспособности можете попробовать и другие домены.

Завершите SSH-сессию с клиентом "cienta" и установите новое SSH-соединение с клиентом "cientb".

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

Выполните несколько команд curl, чтобы проверить работу системы:

curl https://google.com

Это должно работать как ожидалось на виртуальной машине клиента:

davidtu@clientb:~$ curl https://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

Тестирование на домене организации:

curl https://wikipedia.org

Это работает как положено, поскольку clientb не использует Cloud SWP:

davidtu@clientb:~$ curl https://wikipedia.org
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p>
</body></html>

Протестируйте отправку трафика непосредственно через Cloud SWP:

curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure 

Мы видим, что этот трафик отклоняется политикой Cloud SWP:

davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
curl: (56) Received HTTP code 403 from proxy after CONNECT

Как вы уже подтвердили, трафик, использующий Cloud SWP, обрабатывается в соответствии с настроенной политикой безопасности. Трафик, предназначенный для домена .com, разрешен, а все остальные направления запрещены.

Выход из clientb.

14. Обновите правило политики безопасности шлюза для ApplicationMatching.

Давайте обновим правило, чтобы оно соответствовало деталям на уровне приложения. Мы создадим правило, которое будет проверять путь запроса и разрешать его только в том случае, если он соответствует index.html.

cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF

Теперь мы можем привязать обновленное правило к политике безопасности шлюза:

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

15. Тестирование правила ApplicationMatcher

Подключитесь по SSH к виртуальной машине клиента. Для этой виртуальной машины установлена ​​переменная среды, позволяющая использовать Cloud SWP.

Из Cloudshell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Выполните несколько веб-запросов для проверки работоспособности. Нам требуется параметр –proxy-insecure, поскольку для этой лабораторной работы мы создали самоподписанный сертификат:

curl http://google.com --proxy-insecure

Обратите внимание, что этот запрос завершится ошибкой, хотя ранее он выполнялся успешно.

Access denied

Любой запрос, кроме "index.html", должен блокироваться с ошибкой 403. Можете проверить это подробнее.

Измените запрос, добавив путь /index.html

curl http://google.com/index.html --proxy-insecure

Этот запрос должен быть успешно выполнен:

davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/index.html">here</A>.
</BODY></HTML>

Ожидается, что мы увидим перенаправление 301, поскольку веб-сайт перенаправляет на http://www.google.com/index.html

Обратите внимание, что это HTTP-запрос. Далее вам потребуется включить SWP для обеспечения возможности проверки TLS.

Далее выполните тот же запрос, но по протоколу TLS:

curl -k https://google.com/index.html --proxy-insecure

Ожидаемый результат:

curl: (56) Received HTTP code 403 from proxy after CONNECT

Этот запрос должен завершиться неудачей, поскольку SWP не настроен на проверку TLS и не может оценить путь в соответствии с правилом applicationMatcher.

Выезд из Кленты.

16. Включить проверку TLS.

Без проверки TLS applicationMatcher не будет сопоставлять трафик с HTTPS.

Функция "applicationMatcher" позволяет фильтровать данные по следующим параметрам:

• Карта заголовков запроса
• Метод запроса
• Запрос хоста
• Путь запроса
• Запрос
• Схема запроса
• Полный URL-адрес запроса
• Запросить усеранта

Создать учетную запись службы

Данная учетная запись службы будет иметь права на генерацию сертификатов для проверки SWP TLS.

gcloud beta services identity create \
    --service=networksecurity.googleapis.com \
    --project=$project_id

Убедитесь, что CAS включен.

gcloud services enable privateca.googleapis.com

Создайте пул центров сертификации.

gcloud privateca pools create $prefix-ca-pool \
    --tier=devops \
    --project=$project_id \
    --location=$region 

Создать корневой центр сертификации

Центр сертификации используется для подписания сертификатов.

gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \
  --location=$region \
  --auto-enable \
  --subject="CN=my-swp-ca, O=SWP LLC"

Создайте файл политики выдачи сертификатов.

cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
  caOptions:
    isCa: false
  keyUsage:
    extendedKeyUsage:
      serverAuth: true
EOF

Создайте YAML-файл для проверки TLS.

cat > /tmp/tls-inspection-policy.yaml << EOF
caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection
EOF

Создать политику проверки TLS

gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
    --source=/tmp/tls-inspection-policy.yaml \
    --location=$region

Обновите пул центров сертификации, чтобы он использовал политику выдачи сертификатов.

gcloud privateca pools update $prefix-ca-pool    --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region

Предоставление разрешений

Это позволяет вашей служебной учетной записи использовать пул центров сертификации для генерации сертификатов.

gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
    --member=$member \
    --role='roles/privateca.certificateManager' \
    --location=$region

Обновите файл PolicyYAML, чтобы включить проверку TLS.

cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF

Выполните команду для применения обновленной политики.

gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}

Обновить правила, включив в них проверку TLS.

Далее укажите, для каких правил следует установить флаг проверки TLS "enabtlsInspectionEnabled: true".

cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF

Выполните команду, чтобы применить обновленное правило.

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

17. Проверка TLS-проверки.

Подключитесь по SSH к виртуальной машине клиента. Для этой виртуальной машины установлена ​​переменная среды, позволяющая использовать Cloud SWP.

Из Cloudshell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Выполните предыдущий веб-запрос, чтобы проверить, выполняет ли SWP проверку TLS для получения пути.

curl -k https://google.com/index.html --proxy-insecure

На этот раз все должно пройти успешно, поскольку SWP может оценить ApplicationMatcher.

Ожидаемый результат:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/index.html">here</A>.
</BODY></HTML>

Мы успешно настроили Cloud SWP для проверки TLS и оценки логики applicationMatcher!

Выход из клиентского приложения.

18. Этапы очистки

В Cloud Shell удалите шлюз SWP, политику безопасности, сертификаты, экземпляры, Cloud NAT и Cloud Router:

gcloud -q network-services gateways delete ${prefix}-swp --location=${region}

gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy

gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}

gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}

gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region

gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region

gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period

gcloud -q privateca pools delete $prefix-ca-pool --location=$region

gcloud -q compute instances delete clienta --zone=$zone

gcloud -q compute instances delete clientb --zone=$zone

gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region

gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region

Удалите подсети, правила межсетевого экрана и VPC:

gcloud -q compute networks subnets delete $prefix-vpc-subnet \
    --region $region

gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
    --region=$region

gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy

gcloud -q compute networks delete $prefix-vpc

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

Поздравляем с завершением практического задания! Вы успешно настроили и развернули Cloud Secure Web Proxy в Google Cloud.

Что мы рассмотрели

• Облачный SWP и его преимущества!