Лаборатория кода 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 (Журналирование). Затем вы можете отслеживать использование Интернета, обнаруживать угрозы для вашей сети и реагировать на угрозы.

Детализированное управление политиками для Google API

Вы можете использовать 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 к целевому серверу.

Упрощенная интеграция Cloud NAT

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

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

Интеграция журналов облачного аудита и операционного пакета Google Cloud

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

TLS-инспекция

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

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

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

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

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

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

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

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

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

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

Клиент Б НЕ будет настроен на явную отправку HTTP/HTTPS-запросов в Cloud SWP, а вместо этого будет использовать Cloud 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.

Из облачной оболочки:

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.

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

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

Создайте шлюз Cloud NAT для клиента Б.

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, чтобы указать предыдущую информацию, такую ​​как сертификат, политика безопасности шлюза, сеть и подсеть.

Примечание . В этом файле yaml адрес вручную настроен для 10.10.10.50. Это адрес, который будет использовать 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. Создание вычислительных экземпляров

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

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

Создайте вычислительные экземпляры 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 к недавно созданной виртуальной машине «клиента». Для этой виртуальной машины установлена ​​переменная среды для использования Cloud SWP.

Из облачной оболочки:

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 с «clienta» и инициируйте новое SSH-соединение с «clientb».

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, разрешен, а все остальные направления запрещены.

Выход из клиентаb.

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.

Из облачной оболочки:

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

Обновите yaml политики, чтобы включить проверку 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.

Из облачной оболочки:

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

Удалите подсети, правила FW и 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 и преимущества!