Mehr Sicherheit für Egress-Web-Traffic: Secure Web Proxy auf Google Cloud

Der GCP Secure Web Proxy ist ein vollständig verwalteter Dienst für den sicheren und zuverlässigen Zugriff auf das Internet und SaaS-Anwendungen aus Ihren Virtual-Private-Cloud-Netzwerken (VPC). Er hilft Unternehmen dabei, Sicherheitsrichtlinien durchzusetzen, sich vor webbasierten Bedrohungen zu schützen und Transparenz über den Web-Traffic zu gewinnen.

Vorteile und zentrale Funktionen des GCP Secure Web Proxy gegenüber anderen Proxy-Diensten:

• Sicherheit: Der Dienst bietet URL-Filtering, mit dem sich Zugriffsrichtlinien auf Basis von URL-Kategorien durchsetzen lassen. Er kann TLS-Traffic inspizieren und so Sicherheitsrichtlinien wie Malware-Prüfung oder Content-Filtering anwenden. Zudem ist er an die Threat Intelligence von Google Cloud angebunden und schützt vor bekannten schädlichen Websites und Phishing-Angriffen.
• Granulare Zugriffssteuerung: Mit Secure-Web-Proxy-Richtlinien (SWP) definieren Sie Regeln, die festlegen, wie ausgehender Web-Traffic von Ihren Google-Cloud-Ressourcen ins Internet fließt. Richtlinien können Traffic anhand von Quelle, Ziel, Traffic-Art oder einer Kombination dieser Faktoren einschränken.
• Sichtbarkeit und Monitoring: Der Secure Web Proxy ist in Cloud Logging und Cloud Monitoring integriert — Logs und Metriken Ihres ausgehenden Web-Traffics lassen sich so einfach erfassen und auswerten.
• Skalierbarkeit und Zuverlässigkeit: Als vollständig verwalteter Dienst skaliert der GCP Secure Web Proxy automatisch mit Ihrem Traffic und sorgt so für hohe Verfügbarkeit und Performance.
• Zeitersparnis im Betrieb: Beim Secure Web Proxy entfällt das Aufsetzen und Konfigurieren von VMs, es sind keine sicherheitsrelevanten Software-Updates nötig, und die Skalierung erfolgt elastisch. Nach der initialen Richtlinienkonfiguration läuft eine regionale Secure-Web-Proxy-Instanz sofort einsatzbereit.
• Kosteneffizienz: Die Abrechnung erfolgt nach dem Pay-as-you-go-Prinzip — Sie zahlen nur für die tatsächlich genutzten Ressourcen, ganz ohne Vorabverpflichtung.

In diesem Setup laufen die Secure-Web-Proxy-Instanzen in der Hub-VPC, die workloads in der Spoke-VPC. Sämtliche ausgehenden Anfragen werden über VPC-Peering an den Secure Web Proxy weitergeleitet.

High-Level-Architektur des Hub-and-Spoke-Beispiel-Setups

Schritt 1: Die nötigen Umgebungsvariablen setzen.

export PROJECT_ID="your-project-id"
export REGION="your-region"
export HUB_VPC="hub"
export HUB_SUBNET="hub-subnet"
export HUB_SWP_SUBNET="swp-subnet" #proxy only subnet
export SPOKE_VPC="spoke"
export SPOKE_GCE_SUBNET="spoke-gce-subnet"
export SWP_CERT_NAME="swp-certificate"
export SWP_POLICY_NAME="swp-policy"

Schritt 2: Hub-Netzwerk und Subnetz anlegen.

# Create a Hub custom Network
gcloud compute networks create $HUB_VPC \
   --project=$PROJECT_ID \
   --subnet-mode=custom

# Create the Hub nework subnet
gcloud compute networks subnets create $HUB_SUBNET \
   --project=$PROJECT_ID \
   --network=$HUB_VPC \
   --role="ACTIVE" \
   --purpose="PRIVATE" \
   --range=10.220.0.0/23 --region=$REGION

Schritt 3: Proxy-Subnetz für den Secure Web Proxy anlegen. Empfohlen wird eine Subnetzgröße von /23 bzw. 512 Proxy-only-Adressen, da der Secure Web Proxy seine Konnektivität über einen Pool reservierter IP-Adressen bereitstellt.

Dieser Pool vergibt auf der Egress-Seite jedes Proxys eindeutige IP-Adressen für die Kommunikation mit Cloud NAT und Zielen im VPC-Netzwerk. Achten Sie darauf, dass sich der Proxy-Bereich nicht mit anderen Netzwerken überschneidet.

# Create proxy only subnet for SWP.
gcloud compute networks subnets create $HUB_SWP_SUBNET \
   --project=$PROJECT_ID \
   --network=$HUB_VPC \
   --role="ACTIVE" \
   --purpose="REGIONAL_MANAGED_PROXY" \
   --range=192.168.0.0/23 --region=$REGION

Schritt 4: Spoke-Netzwerk und Subnetze anlegen.

# Create a Spoke custom Network and its subnet
gcloud compute networks create $SPOKE_VPC \
   --project=$PROJECT_ID \
   --subnet-mode=custom

gcloud compute networks subnets create $SPOKE_GCE_SUBNET \
   --project=$PROJECT_ID \
     --network=$SPOKE_VPC \
   --range=10.240.0.0/23 --region=$REGION

Schritt 5: Die Standard-Internetroute der Spoke-VPC entfernen — der gesamte ausgehende Traffic läuft dann über die Hub-VPC.

# Get the Default Route internet and the delete the rule
ROUTE_NAME=$(gcloud compute routes list --filter="network: $SPOKE_VPC AND nextHopGateway:default-internet-gateway" --format="value(name)")

gcloud compute routes delete $ROUTE_NAME --quiet

Schritt 6: Test-Compute-Engine-Instanz im Spoke-Netzwerk anlegen.

# Create VM
gcloud compute instances create spoke-vm \
  --zone=${REGION}-a \
  --machine-type=e2-medium \
  --network-interface=stack-type=IPV4_ONLY,subnet=${SPOKE_GCE_SUBNET},no-address \
  --project=$PROJECT_ID

# Allow ssh via IAP
gcloud compute firewall-rules create allow-ssh-ingress \
  --project=$PROJECT_ID \
  --direction=INGRESS \
  --priority=1000 \
  --network=$SPOKE_VPC \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges="35.235.240.0/20"

Schritt 7: VPC-Peering zwischen Hub- und Spoke-VPC einrichten.

# Hub to spoke
gcloud compute networks peerings create hub-to-spoke \
   --project=$PROJECT_ID \
   --network=$HUB_VPC --peer-network=$SPOKE_VPC \
   --auto-create-routes

# Spoke to Hub
gcloud compute networks peerings create spoke-to-hub \
   --project=$PROJECT_ID \
   --network=$SPOKE_VPC --peer-network=$HUB_VPC \
   --auto-create-routes

Schritt 8: Das Secure-Web-Proxy-Gateway terminiert TLS-Traffic — dafür wird ein Zertifikat benötigt. Mit diesem Zertifikat authentifiziert sich der Client gegenüber dem Proxy. Erstellen Sie ein SSL-Zertifikat und laden Sie es in den Certificate Manager hoch.

#create the certificate
openssl req -x509 -newkey rsa:2048 \
  -keyout key.pem \
  -out cert.pem -days 365 \
  -subj '/CN=demo.swp.local' -nodes -addext \
  "subjectAltName=DNS:demo.swp.local"

#upload the certificate
gcloud certificate-manager certificates create $SWP_CERT_NAME \
   --certificate-file=cert.pem \
   --private-key-file=key.pem \
   --location=$REGION

Schritt 9: Secure-Web-Proxy-Richtlinie erstellen.

Der Secure Web Proxy bietet außerdem einen TLS-Inspektionsdienst, mit dem sich TLS-Traffic abfangen, der verschlüsselte Request prüfen und Sicherheitsrichtlinien durchsetzen lassen. Beispielkonfigurationen finden Sie im Überblick zur TLS-Inspektion.

#Sample policy without enable TLS inspection.
cat << EOF > swp-policy.yaml
description: Secure Web Proxy policy
name: projects/$PROJECT_ID/locations/$REGION/gatewaySecurityPolicies/$SWP_POLICY_NAME
EOF

gcloud network-security gateway-security-policies import $SWP_POLICY_NAME \
  --source=swp-policy.yaml \
  --location=$REGION

Schritt 10: Secure-Web-Proxy-Gateway-Instanz mit der im vorherigen Schritt erstellten Richtlinie anlegen.

# Create config file
cat << EOF > swp-gateway.yaml
name: projects/$PROJECT_ID/locations/REGION/gateways/swp-gateway
type: SECURE_WEB_GATEWAY
ports: [443]
certificateUrls: ["projects/$PROJECT_ID/locations/$REGION/certificates/$SWP_CERT_NAME"]
gatewaySecurityPolicy: projects/$PROJECT_ID/locations/$REGION/gatewaySecurityPolicies/$SWP_POLICY_NAME
network: projects/$PROJECT_ID/global/networks/$HUB_VPC
subnetwork: projects/$PROJECT_ID/regions/$REGION/subnetworks/$HUB_SUBNET
scope: basic-scope
EOF

gcloud network-services gateways import swp-gateway-instance \
    --source=swp-gateway.yaml \
    --location=$REGION

Beim Bereitstellen einer Secure-Web-Proxy-Instanz wird automatisch ein Cloud-NAT-Gateway erstellt, das den Internetzugriff ermöglicht. Nur Secure-Web-Proxy-Endpunkte derselben Region und desselben Netzwerks können dieses Cloud-NAT-Gateway nutzen. Andere Endpunkte — etwa VM-Instanzen oder Knoten der Google Kubernetes Engine (GKE) — dürfen keinen Traffic darüber leiten.

Schritt 11: Per SSH auf die Test-Instanz im Spoke-Netzwerk verbinden und die Egress-Anfragen prüfen. Da die Secure-Web-Gateway-Proxy-Richtlinie noch keine Regeln enthält, wird sämtlicher ausgehender Traffic standardmäßig blockiert.

#sample commands
#replace $SWP_HOST_IP with the IP address of the SWP Gateway IP
$export https_proxy=https://$SWP_HOST_IP
$curl -s -I --proxy-insecure https://www.example.com

Ergebnisse von der Test-Instanz

Schritt 12: Secure-Web-Proxy-Regeln anlegen, um ausgehenden Traffic gemäß Referenzarchitektur zu erlauben oder zu blockieren.

Eine Secure-Web-Proxy-Regel (SWP) ist eine Anweisung, die festlegt, wie der Proxy mit ausgehendem Web-Traffic umgeht.

Die Beispielrichtlinie erlaubt ausgehende Verbindungen anhand des Hostnamens. Die vollständige Liste der Attribute und Operatoren finden Sie in der CEL-Matcher-Sprachreferenz.

#allow www.example.com,The rule with the lowest numeric value assigned has the highest logical priority and is evaluated prior to rules with lower logical priorities.
cat << EOF > allow-example-com.yaml
name: projects/$PROJECT_ID/locations/$REGION/gatewaySecurityPolicies/$SWP_POLICY_NAME/rules/allow-example-com
description: Allow example.com
enabled: true
priority: 1000
basicProfile: ALLOW
sessionMatcher: host() == 'www.example.com'
EOF

gcloud network-security gateway-security-policies rules import allow-example-com \
    --source=allow-example-com.yaml \
    --location=$REGION \
    --gateway-security-policy=$SWP_POLICY_NAME

#allow www.doit.com
cat << EOF > allow-doit-com.yaml
name: projects/$PROJECT_ID/locations/$REGION/gatewaySecurityPolicies/$SWP_POLICY_NAME/rules/allow-example-com
description: Allow example.com
enabled: true
priority: 999
basicProfile: ALLOW
sessionMatcher: host() == 'www.doit.com'
EOF

gcloud network-security gateway-security-policies rules import allow-doit-com \
    --source=allow-doit-com.yaml \
    --location=$REGION \
    --gateway-security-policy=$SWP_POLICY_NAME

Ergebnisse von der Test-Instanz

Die Testergebnisse zeigen: Das Secure-Web-Proxy-Gateway lässt ausgehende Verbindungen ausschließlich zu den in den Regeln freigegebenen Hostnamen zu — Verbindungen zu anderen Domains werden blockiert.