1. Wprowadzenie
Cloud Secure Web Proxy
Cloud SWP to usługa korzystająca głównie z chmury, która zapewnia Secure Web Proxy, aby pomóc zabezpieczać wychodzący ruch internetowy (HTTP/S). Skonfiguruj klienty tak, aby wyraźnie używały Cloud SWP jako serwera proxy. Żądania internetowe mogą pochodzić z tych źródeł:
- Instancje maszyn wirtualnych
- Kontenery
- Środowisko bezserwerowe, które korzysta z bezserwerowego oprogramowania sprzęgającego
- Obciążenia w ramach połączenia równorzędnego VPC
- obciążenia poza Google Cloud połączone przez Cloud VPN lub Cloud Interconnect;
Cloud SWP umożliwia elastyczne i szczegółowe zasady oparte na tożsamościach korzystających głównie z chmury i aplikacjach internetowych.
Korzyści
Oto kilka przykładów korzyści, jakie może przynieść organizacji usługa Cloud SWP:
Migracja do Google Cloud
Cloud SWP pomaga przenieść się do Google Cloud przy zachowaniu dotychczasowych zasad bezpieczeństwa i wymagań dotyczących internetowego ruchu wychodzącego. Możesz uniknąć korzystania z rozwiązań innych firm, które wymagają dodatkowej konsoli zarządzania lub ręcznej edycji plików konfiguracyjnych.
Dostęp do zaufanych zewnętrznych usług internetowych
Cloud SWP umożliwia stosowanie szczegółowych zasad dostępu do ruchu wychodzącego do internetu, dzięki czemu możesz zabezpieczyć swoją sieć. Tworzysz i identyfikujesz tożsamości zbiorów zadań lub aplikacji, a następnie stosujesz zasady.
Monitorowany dostęp do niezaufanych usług internetowych
Możesz używać Cloud SWP, aby zapewnić monitorowany dostęp do niezaufanych usług internetowych. Cloud SWP identyfikuje ruch, który nie jest zgodny z zasadami, i rejestruje go w Cloud Logging (Logging). Możesz wtedy monitorować wykorzystanie internetu, wykrywać zagrożenia dla sieci i na nie reagować.
Szczegółowe ustawienia zasad dotyczące interfejsów API Google
Za pomocą Cloud SWP możesz określać szczegółowe zasady dotyczące interfejsów API Google. Możesz na przykład ustawić zasady na poziomie koszyka lub obiektu za pomocą języka Common Expression Language (CEL).
Obsługiwane funkcje
Cloud SWP obsługuje te funkcje:
Usługa proxy jawnego
Klienty muszą być wyraźnie skonfigurowane do korzystania z serwera proxy. Serwer proxy Cloud SWP izoluje klientów od internetu, tworząc w ich imieniu nowe połączenia TCP.
Autoskalowanie serwerów proxy Envoy Cloud SWP
Umożliwia automatyczne dostosowywanie rozmiaru puli serwerów proxy Envoy i jej pojemności w regionie, co zapewnia stałą wydajność w okresach dużego zapotrzebowania przy najniższych kosztach.
Modułowe zasady dostępu do ruchu wychodzącego
Cloud SWP obsługuje te zasady ruchu wychodzącego:
- Tożsamość źródła na podstawie bezpiecznych tagów, kont usługi lub adresów IP.
- Miejsca docelowe na podstawie adresów URL i nazw hostów.
- Żądania oparte na metodach, nagłówkach lub adresach URL. Adresy URL można określać za pomocą list, symboli wieloznacznych lub wzorców.
- Szyfrowanie end-to-end: tunele klient-proxy mogą być przesyłane przez TLS. Cloud SWP obsługuje też HTTP/S CONNECT w przypadku połączeń TLS typu end-to-end inicjowanych przez klienta z serwerem docelowym.
Uproszczona integracja Cloud NAT
Cloud NAT automatycznie udostępnia dodatkowe publiczne adresy IP, gdy zwiększa się liczba serwerów proxy obsługujących ruch Cloud SWP.
Ręczne statyczne publiczne adresy IP to również opcja dla osób, które chcą mieć znane adresy IP ruchu wychodzącego.
Integracja logów kontrolnych Cloud z pakietem operacyjnym Google Cloud
Logi kontrolne Cloud i pakiet operacyjny Google Cloud rejestrują działania administracyjne i żądania dostępu do zasobów związanych z Cloud SWP. Rejestrują też dane i logi transakcji dotyczące żądań obsługiwanych przez serwer proxy.
Inspekcja TLS
Bezpieczny internetowy serwer proxy oferuje usługę inspekcji TLS, która umożliwia przechwytywanie ruchu TLS, sprawdzanie zaszyfrowanych żądań i egzekwowanie zasad bezpieczeństwa.
- Ścisła integracja z Certificate Authority Service (CAS), która jest wysoce dostępnym i skalowalnym repozytorium prywatnych urzędów certyfikacji.
- Możliwość używania własnego głównego źródła zaufania, jeśli jest to wymagane. Możesz też użyć istniejącego głównego urzędu certyfikacji do podpisywania podrzędnych urzędów certyfikacji przechowywanych przez CAS. Jeśli wolisz, możesz wygenerować nowy certyfikat główny w CAS.
- Szczegółowe kryteria odszyfrowywania za pomocą funkcji SessionMatcher i ApplicationMatcher w regułach zasady Secure Web Proxy. Kryteria te obejmują dopasowywanie hostów występujących na listach adresów URL, w wyrażeniach regularnych, zakresach adresów IP i podobnych wyrażeniach. W razie potrzeby kryteria można łączyć z wyrażeniami logicznymi.
- Każda zasada Secure Web Proxy może być skonfigurowana z własną zasadą kontroli TLS i pulą urzędów certyfikacji. Możesz też powiązać wiele zasad Secure Web Proxy z jedną zasadą kontroli protokołu TLS.
Czego się nauczysz
- Jak wdrażać i zarządzać Cloud SWP.
Czego potrzebujesz
- umiejętność wdrażania instancji i konfigurowania komponentów sieciowych;
- Znajomość konfiguracji zapory sieciowej VPC
2. Środowisko testowe
W tym laboratorium wykorzystamy jedną sieć VPC. Zasób obliczeniowy w tym środowisku będzie wysyłać ruch wychodzący za pomocą usługi Cloud SWP, jak widać na poniższym diagramie.
W tym module będziemy mieć 2 maszyny wirtualne z obciążeniem.
Klient A będzie skonfigurowany tak, aby wysyłać wszystkie żądania HTTP/HTTPS do usługi Cloud SWP.
Klient B NIE będzie skonfigurowany do jawnego wysyłania żądań HTTP/HTTPS do usługi Cloud SWP, ale zamiast tego będzie korzystać z Cloud NAT w przypadku ruchu związanego z internetem.
3. Zanim zaczniesz
Codelab wymaga jednego projektu.
W Cloud Shell sprawdź, czy identyfikator projektu jest skonfigurowany.
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-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. Włącz interfejsy API
Włączanie interfejsów API do korzystania z usług
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. Tworzenie sieci VPC, podsieci i podsieci tylko-proxy
Sieć VPC
Utwórz sieć VPC codelab-swp-vpc:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Podsieć
Utwórz odpowiednie podsieci w wybranym regionie:
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
Podsieć tylko-proxy
Utwórz podsieć tylko-proxy w wybranym regionie:
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. Utwórz reguły zapory sieciowej
Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.
W Cloud Shell:
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. Tworzenie routera Cloud Router i Cloud NAT
Utwórz router Cloud Router dla Cloud NAT.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
Utwórz bramę Cloud NAT dla klienta 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. Tworzenie zasady zabezpieczeń bramy
Utwórz plik YAML zawierający odpowiednie informacje o zasadach:
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
Uruchom polecenie gcloud, aby utworzyć zasadę z pliku YAML:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Tworzenie reguły zasady zabezpieczeń bramy
Utwórz plik YAML zawierający reguły. Te reguły są zapisane w języku CEL (Common Expression Language). W tym ćwiczeniu użyjemy prostej reguły, która zezwala na ruch do domen .com i blokuje wszystkie inne:
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
Teraz możemy powiązać regułę z zasadami zabezpieczeń bramy:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. Tworzenie certyfikatu i przesyłanie go do Cloud Certificate Manager
Utwórz certyfikat do zakończenia ruchu zadania:
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"
Prześlij certyfikat do menedżera certyfikatów Google Cloud, aby SWP mógł się do niego odwoływać w zasadach bramy zabezpieczeń.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. Tworzenie bramy SWP
Utwórz plik YAML dla bramy SWP, aby odwoływać się do poprzednich informacji, takich jak certyfikat, zasady zabezpieczeń bramy, sieć i podsieć.
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
Utwórz bramę:
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
Sprawdź, czy brama została utworzona:
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. Tworzenie instancji Compute
Cloud SWP to serwer proxy typu explicit, dlatego musimy wyraźnie określić adres IP serwera proxy dla ruchu związanego z zadaniami. Na instancji obliczeniowej clientA zostanie ustawiona zmienna środowiskowa. KlientB nie będzie.
Utwórz instancje obliczeniowe ClientA i 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. Testowanie dopasowywania sesji
Połącz się przez SSH z ostatnio utworzoną maszyną wirtualną „clienta”. Na tej maszynie wirtualnej zmienna środowiskowa jest ustawiona tak, aby używać Cloud SWP.
W Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom kilka kwerend internetowych, aby sprawdzić działanie funkcji. Wymagamy parametru –proxy-insecure, ponieważ w tym module utworzyliśmy certyfikat podpisany samodzielnie:
curl https://google.com --proxy-insecure
Oczekiwane dane wyjściowe:
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>
Jak widać, żądanie zostało „zrealizowane”. Oczekujemy przekierowania 301, ponieważ witryna przekierowuje na adres https://www.google.com.
Uruchomienie tego polecenia spowoduje wyświetlenie szczegółowych dzienników z informacjami o połączeniu:
curl https://google.com --proxy-insecure -v
Wyróżnienie niektórych danych wyjściowych, aby pokazać szczegóły połączenia przez serwer proxy, certyfikaty i miejsce docelowe.
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! ...
Możesz wypróbować inne domeny .com, aby sprawdzić, czy funkcja działa.
Teraz wypróbujmy inne domeny, które nie są domenami .com, aby sprawdzić domyślne działanie blokowania:
curl https://wikipedia.org --proxy-insecure
Oczekiwane dane wyjściowe:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Podobnie sprawdź szczegółowe logowanie danych wyjściowych i upewnij się, że Cloud SWP blokuje ten ruch:
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
Możesz też wypróbować inne domeny, aby sprawdzić, jak działa weryfikacja.
Zakończ sesję SSH z maszyną „clienta” i zainicjuj nowe połączenie SSH z maszyną „clientb”.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Uruchom kilka poleceń curl, aby sprawdzić działanie:
curl https://google.com
Powinno to działać zgodnie z oczekiwaniami na maszynie wirtualnej clientb:
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>
Testowanie w domenie organizacji:
curl https://wikipedia.org
Działa to zgodnie z oczekiwaniami, ponieważ klientb nie korzysta z 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>
Przetestuj wysyłanie ruchu bezpośrednio przez Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Widzimy, że ten ruch jest odrzucany przez zasadę 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
Jak już potwierdziliśmy, ruch korzystający z Cloud SWP jest egzekwowany zgodnie ze skonfigurowanymi zasadami zabezpieczeń. Ruch kierowany do domeny .com jest dozwolony, a ruch kierowany do wszystkich innych miejsc docelowych jest odrzucany.
Wyjdź z klientb.
14. Aktualizowanie reguły zasady zabezpieczeń bramy dla ApplicationMatching
Zaktualizujmy regułę, aby pasowała do szczegółów na poziomie aplikacji. Utworzymy regułę, która będzie sprawdzać ścieżkę żądania i zezwalająca na nie tylko wtedy, gdy będzie ona zgodna z 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
Teraz możemy powiązać zaktualizowaną regułę z zasadami zabezpieczeń bramy:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. Testowanie reguły ApplicationMatcher
Połącz się z maszyną wirtualną klienta przez SSH. Na tej maszynie wirtualnej zmienna środowiskowa jest ustawiona tak, aby używać Cloud SWP.
W Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom kilka kwerend internetowych, aby sprawdzić działanie funkcji. Wymagamy parametru –proxy-insecure, ponieważ w tym module utworzyliśmy certyfikat podpisany samodzielnie:
curl http://google.com --proxy-insecure
Zwróć uwagę, że to zapytanie zakończy się niepowodzeniem, mimo że wcześniej działało.
Access denied
Każda ścieżka żądania inna niż „index.html” powinna być blokowana z kodem 403. Możesz to sprawdzić.
Zmodyfikuj zapytanie, aby uwzględniało ścieżkę /index.html.
curl http://google.com/index.html --proxy-insecure
To żądanie powinno zostać zrealizowane:
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>
Oczekujemy przekierowania 301, ponieważ witryna przekierowuje na adres http://www.google.com/index.html
Zwróć uwagę, że jest to żądanie HTTP. Następnie musisz włączyć SWP, aby mieć możliwość inspekcji TLS.
Następnie uruchom to samo zapytanie, ale przy użyciu protokołu TLS:
curl -k https://google.com/index.html --proxy-insecure
Oczekiwane dane wyjściowe:
curl: (56) Received HTTP code 403 from proxy after CONNECT
To żądanie powinno się nie powieść, ponieważ SWP nie jest skonfigurowany do sprawdzania TLS i nie może ocenić ścieżki pod kątem reguły ApplicationMatcher.
Wyjdź z clenta.
16. Włączanie inspekcji TLS
Bez inspekcji TLS atrybut applicationMatcher nie będzie dopasowywać ruchu HTTPS.
„applicationMatcher” umożliwia filtrowanie według tych kryteriów:
- Mapa nagłówków żądań
- Metoda żądania
- Serwer reklam w sieci wyszukiwania
- Ścieżka żądania
- Zapytanie dotyczące żądania
- Schemat żądania
- Pełny adres URL żądania
- Wysyłanie prośby o klienta użytkownika
Utwórz konto usługi
To konto usługi będzie mieć uprawnienia do generowania certyfikatów na potrzeby inspekcji TLS w ramach ochrony SWP.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Sprawdź, czy CAS jest włączony
gcloud services enable privateca.googleapis.com
Utwórz pulę urzędów certyfikacji
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
Tworzenie głównego urzędu certyfikacji
Urząd certyfikacji używany do podpisywania certyfikatów.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
Tworzenie pliku zasad wystawiania certyfikatów
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Tworzenie pliku YAML inspekcji 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
Tworzenie zasady inspekcji TLS
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
Aktualizowanie puli urzędów certyfikacji w celu używania zasady wystawiania certyfikatów
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Przyznaj uprawnienia
Dzięki temu konto usługi może używać puli urzędów certyfikacji do generowania certyfikatów.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
Aktualizowanie pliku YAML zasady w celu uwzględnienia inspekcji 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
Uruchom polecenie, aby zastosować zaktualizowane zasady.
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Aktualizowanie reguł w celu uwzględnienia inspekcji TLS
Następnie określ, które reguły powinny mieć flagę inspekcji 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
Uruchom polecenie, aby zastosować zaktualizowaną regułę
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. Testowanie inspekcji TLS
Połącz się z maszyną wirtualną klienta przez SSH. Na tej maszynie wirtualnej zmienna środowiskowa jest ustawiona tak, aby używać Cloud SWP.
W Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom poprzednie zapytanie internetowe, aby sprawdzić, czy SWP przeprowadza kontrolę TLS w celu pobrania ścieżki.
curl -k https://google.com/index.html --proxy-insecure
Tym razem powinno się to udać, ponieważ SWP może ocenić ApplicationMatcher.
Oczekiwane dane wyjściowe:
<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>
Udało nam się skonfigurować Cloud SWP do sprawdzania protokołu TLS i oceny logiki applicationMatcher.
Wyjdź z klienta.
18. Procedura czyszczenia
W Cloud Shell usuń bramę SWP, zasady zabezpieczeń, certyfikaty, instancje, Cloud NAT i 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
Usuń podsieci, reguły zapory sieciowej i sieci 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. Gratulacje!
Gratulujemy ukończenia ćwiczenia. Udało Ci się skonfigurować i wdrożyć Cloud Secure Web Proxy w Google Cloud.
Omówione zagadnienia
- Cloud SWP i korzyści z niego wynikające