1. Wprowadzenie
Cloud Secure Web Proxy
Cloud SWP to usługa działająca głównie w chmurze, która udostępnia bezpieczny internetowy serwer proxy, który pomaga zabezpieczyć wychodzący ruch internetowy (HTTP/S). Klienty konfiguruje się w taki sposób, aby jawnie używały Cloud SWP jako serwera proxy. Żądania sieciowe mogą pochodzić z tych źródeł:
- Instancje maszyn wirtualnych
- Kontenery
- Bezserwerowe środowisko korzystające z bezserwerowego oprogramowania sprzęgającego
- Zadania w połączeniu równorzędnym VPC
- Zadania spoza Google Cloud połączone przez Cloud VPN lub Cloud Interconnect
Cloud SWP umożliwia elastyczne i szczegółowe zasady oparte na tożsamościach i aplikacjach internetowych działających głównie w chmurze.
Zalety
Poniżej znajdziesz kilka przykładów korzyści, które Cloud SWP może zapewnić organizacji:
Migracja do Google Cloud
Cloud SWP ułatwia migrację do Google Cloud przy zachowaniu dotychczasowych zasad zabezpieczeń i wymagań dotyczących wychodzącego ruchu internetowego. W ten sposób możesz uniknąć używania rozwiązań innych firm, które wymagają innej konsoli zarządzania, lub ręcznego edytowania plików konfiguracji.
Dostęp do zaufanych zewnętrznych usług internetowych
Cloud SWP umożliwia stosowanie szczegółowych zasad dostępu do wychodzącego ruchu internetowego, dzięki czemu możesz zabezpieczyć sieć. Możesz tworzyć i identyfikować tożsamości zadań lub aplikacji, a następnie stosować zasady.
Monitorowanie dostępu do niezaufanych usług internetowych
Cloud SWP umożliwia monitorowanie dostępu do niezaufanych usług internetowych. Cloud SWP identyfikuje ruch, który jest niezgodny z zasadami, i loguje go w usłudze Cloud Logging (Logging). Dzięki temu możesz monitorować korzystanie z internetu, wykrywać zagrożenia w sieci i reagować na nie.
Szczegółowe ustawienia zasad dla interfejsów API Google
Za pomocą Cloud SWP możesz określić szczegółowe zasady dla interfejsów API Google. Możesz na przykład skonfigurować zasady na poziomie zasobnika/obiektu za pomocą języka CEL (Common Expression Language).
Obsługiwane funkcje
Cloud SWP obsługuje te funkcje:
Bezpośrednia usługa pośrednicząca
Klienty muszą być jawnie skonfigurowane pod kątem używania serwera proxy. Serwer proxy Cloud SWP izoluje klienty od internetu, tworząc nowe połączenia TCP w imieniu klienta.
Autoskalowanie serwerów proxy Cloud SWP Envoy
Obsługuje automatyczne dostosowywanie rozmiaru puli serwera proxy Envoy i rozmiaru puli w regionie, co umożliwia stałą wydajność w okresach dużego zapotrzebowania przy najniższym koszcie.
Modułowe zasady dostępu wychodzącego
Cloud SWP obsługuje w szczególności te zasady ruchu wychodzącego:
- Tożsamość źródłowa oparta na bezpiecznych tagach, kontach usługi lub adresach IP.
- Miejsca docelowe oparte na adresach URL i nazwach hostów.
- Żądania zależne od metod, nagłówków lub adresów URL. Adresy URL można określać za pomocą list, symboli wieloznacznych lub wzorców.
- Pełne szyfrowanie: tunele klienta proxy mogą być przesyłane przez TLS. Cloud SWP obsługuje również połączenie HTTP/S w przypadku inicjowanych przez klienta, kompleksowych połączeń TLS z serwerem docelowym.
Uproszczona integracja Cloud NAT
Cloud NAT automatycznie udostępnia dodatkowe publiczne adresy IP, gdy rośnie liczba serwerów proxy, które obsługują ruch Cloud SWP.
Ręcznie statyczne publiczne adresy IP są również opcją dla osób, które chcą mieć znane adresy IP ruchu wychodzącego.
Logi kontrolne Cloud i integracja 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ą także wskaźniki i logi transakcji dotyczące żądań obsługiwanych przez serwer proxy.
Inspekcja TLS
Bezpieczny internetowy serwer proxy oferuje usługę kontroli TLS, która umożliwia przechwytywanie ruchu TLS, sprawdzanie zaszyfrowanego żądania i egzekwowanie zasad bezpieczeństwa.
- Ścisła integracja z usługą Certificate Authority Service (CAS), która zapewnia wysoką dostępność i skalowalne repozytorium prywatnych urzędów certyfikacji.
- Możliwość wykorzystania własnego źródła zaufania w razie potrzeby. 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 przy użyciu elementów SessionMatcher i ApplicationMatcher w regułach zasad bezpiecznego internetowego serwera proxy. Te kryteria obejmują pasujące hosty obecne na listach adresów URL, 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 bezpiecznego internetowego serwera proxy można skonfigurować za pomocą własnej zasady kontroli TLS i puli urzędów certyfikacji. Z kolei kilka zasad bezpiecznego internetowego serwera proxy może współdzielić jedną zasadę kontroli TLS.
Czego się nauczysz
- Jak wdrożyć Cloud SWP i nim zarządzać.
Czego potrzebujesz
- Wiedza na temat wdrażania instancji i konfigurowania komponentów sieci
- Wiedza o konfiguracji zapory sieciowej VPC
2. Środowisko testowe
To ćwiczenie w Codelabs będzie wykorzystywać jedną sieć VPC. Zasób obliczeniowy w tym środowisku będzie wychodzący za pomocą Cloud SWP, jak widać na schemacie poniżej.
W tym module będziemy mieć 2 maszyny wirtualne zadań.
Klient A zostanie skonfigurowany tak, aby wysyłać do Cloud SWP wszystkie żądania HTTP/HTTPS.
Klient B NIE zostanie skonfigurowany tak, aby jawnie wysyłał żądania HTTP/HTTPS do Cloud SWP, ale będzie wykorzystywać Cloud NAT do obsługi ruchu związanego z internetem.
3. Zanim zaczniesz
Ćwiczenia z programowania wymagają 1 projektu.
Sprawdź w Cloud Shell, 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łącz interfejsy API, aby korzystać z usług
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. Utwórz sieć VPC, podsieć i podsieć 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 nawiązywanie połączeń z maszynami wirtualnymi, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne za pomocą IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP używane przez IAP 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. Utwórz router Cloud Router 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, który zawiera istotne informacje o zasadzie:
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ę na podstawie pliku yaml:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Tworzenie reguły zasady zabezpieczeń bramy
utworzyć plik yaml zawierający reguły; Reguły te są zapisane w języku CEL (Common Expression Language). W tym module użyjesz prostej reguły, która będzie zezwalać na ruch w domenach .com i blokować 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 zasadą 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. Utwórz certyfikat i prześlij go do menedżera certyfikatów Google Cloud
Utwórz certyfikat, aby zakończyć ruch związany z zadaniami:
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 narzędzie SWP mogło odwoływać się do niego w zasadzie 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 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
Ponieważ Cloud SWP jest jawnym serwerem proxy, musimy jawnie określić adres IP serwera proxy dla ruchu związanego z zadaniami. Instancja Compute clientA będzie miała ustawioną zmienną środowiskową. Klient B tego nie zrobi.
Utwórz instancje obliczeniowe ClientA i Klient B:
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 dopasowania sesji
Łączenie się z „klientem” przez SSH Niedawno utworzono maszynę wirtualną Compute. Ta maszyna wirtualna ma zmienną środowiskową ustawioną na korzystanie z Cloud SWP.
W Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom kwerendy sieci Web, aby sprawdzić działanie funkcji. Wymagamy ustawienia –proxy-insecure, ponieważ utworzyliśmy samodzielnie podpisany certyfikat na potrzeby tego modułu:
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. Spodziewamy się przekierowania 301, ponieważ witryna przekierowuje na https://www.google.com.
Uruchomienie następującego polecenia spowoduje wyświetlenie szczegółowych logów ze szczegółami połączenia:
curl https://google.com --proxy-insecure -v
Wyróżnij niektóre dane wyjściowe, aby wyświetlić szczegóły połączenia z serwerem 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ć działanie usługi.
Teraz wypróbujmy kilka innych domen spoza domeny .com, aby sprawdzić domyślne działanie blokujące:
curl https://wikipedia.org --proxy-insecure
Oczekiwane dane wyjściowe:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Sprawdź też 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 wypróbować także inne domeny, aby sprawdzić działanie usługi.
Wyjdź z sesji SSH dla klienta „clienta” i zainicjuj nowe połączenie SSH z klientem.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Uruchom polecenia curl, by sprawdzić działanie:
curl https://google.com
To powinno działać zgodnie z oczekiwaniami maszyny wirtualnej klienta:
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ż klient 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 za pomocą 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
Zgodnie z Twoimi ustaleniami ruch wykorzystujący Cloud SWP jest egzekwowany zgodnie ze skonfigurowaną zasadą zabezpieczeń. Ruch kierowany do domeny .com jest dozwolony, a wszystkie inne miejsca docelowe są zabronione.
Wyjdź z klienta.
14. Aktualizowanie reguły zasady zabezpieczeń bramy na potrzeby dopasowywania aplikacji
Zaktualizujmy regułę tak, aby pasowała do szczegółów na poziomie aplikacji. Stworzymy regułę sprawdzającą ścieżkę żądania i zezwalając na nią tylko wtedy, gdy pasuje ona do pliku 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 zasadą 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ą Clienta Compute przez SSH. Ta maszyna wirtualna ma zmienną środowiskową ustawioną na korzystanie z Cloud SWP.
W Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom kwerendy sieci Web, aby sprawdzić działanie funkcji. Wymagamy ustawienia –proxy-insecure, ponieważ utworzyliśmy samodzielnie podpisany certyfikat na potrzeby tego modułu:
curl http://google.com --proxy-insecure
Zwróć uwagę, że to zapytanie zakończy się niepowodzeniem, jeśli zostało przekazane wcześniej.
Access denied
Każda ścieżka żądania oprócz „index.html” powinien zostać zablokowany po wystąpieniu błędu 403. Zachęcamy do dalszego testowania.
Zmodyfikuj zapytanie, tak aby zawierał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>
Spodziewane jest przekierowanie 301, bo witryna przekierowuje na stronę http://www.google.com/index.html.
Zwróć uwagę, że jest to żądanie HTTP. Następnie musisz włączyć funkcję SWP, aby uzyskać dostęp do funkcji inspekcji TLS.
Następnie uruchom to samo zapytanie, ale z użyciem 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 zakończyć się niepowodzeniem, ponieważ narzędzie SWP nie zostało skonfigurowane do badania TLS i nie może ocenić ścieżki w odniesieniu do reguły applicationMatcher.
Wyjdź z programu Centa.
16. Włącz inspekcję TLS
Bez inspekcji TLS funkcja applicationMatcher nie będzie dopasowywać aplikacji pod kątem ruchu HTTPS.
"applicationMatcher" pozwala filtrować następujące elementy:
- Mapa nagłówków żądań
- Metoda żądania
- Host żądania
- Ścieżka żądania
- Zapytanie wysłane
- Schemat żądania
- URL pełnego żądania
- Poproś o klienta użytkownika
Utwórz konto usługi
To konto usługi będzie mieć uprawnienia do generowania certyfikatów na potrzeby kontroli TLS przy użyciu protokołu SWP.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Sprawdź, czy włączono CAS
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
Utwórz główny urząd 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 zasady wystawiania certyfikatów
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Utwórz plik 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
Utwórz zasadę inspekcji TLS
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
Zaktualizuj pulę urzędów certyfikacji, aby używać 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 Twoje konto usługi będzie mogło 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
Zaktualizuj plik yaml zasad, aby uwzględnić kontrolę 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 zastosuj zaktualizowaną zasadę
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Zaktualizuj reguły, aby uwzględnić kontrolę TLS
Następnie określ, które reguły powinny mieć kontrolę TLS „enabtlsInspectionEnabled: true” flaga.
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ą Clienta Compute przez SSH. Ta maszyna wirtualna ma zmienną środowiskową ustawioną na korzystanie z Cloud SWP.
W Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom poprzednią kwerendę sieci Web, aby sprawdzić, czy program SWP przeprowadza kontrolę TLS w celu pobrania ścieżki
curl -k https://google.com/index.html --proxy-insecure
Tym razem powinno się udać, ponieważ SWP może ocenić atrybut 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, aby zbadać TLS i ocenić logikę applicationMatcher.
Wyjście z klienta.
18. Procedura czyszczenia
W Cloud Shell usuń bramę SWP, zasadę 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 FW 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 ćwiczeń z programowania. Udało Ci się skonfigurować i wdrożyć Cloud Secure Web Proxy w Google Cloud.
Omówione zagadnienia
- Cloud SWP i korzyści