1. Netzwerkisolation: Das vollständige Umgehen des öffentlichen Internets für Inferenz-Traffic ist für sensible Workloads nicht verhandelbar. Dies verhindert gängige netzwerkbasierte Angriffe und Datenabfangmaßnahmen.
2. Perimetersicherheit (VPC-SC): Das Einrichten von Schutzmaßnahmen gegen Datenexfiltration und unbefugten projektübergreifenden Zugriff. Dies fungiert als logische Luftspalt.
3. Datenschutz: Sicherstellen, dass Modelle und Daten im Ruhezustand und während der Übertragung mit kundenseitig verwalteten Schlüsseln verschlüsselt werden. Dies gibt mir direkte Kontrolle über mein kryptografisches Material.
4. Zugriff mit den geringsten Privilegien: Implementierung granularer IAM-Rollen, die die Belange der Modellbereitstellung von der Modellaufrufung trennen. Dies minimiert den Explosionsradius kompromittierter Anmeldeinformationen.
5. Modell-Governance: Implementierung von Praktiken wie Modellsignierung (z. B. mit Sigstore/Cosign), Schwachstellenanalyse von Modellabhängigkeiten und umfassende Audit-Protokollierung für alle Modelllebenszyklusereignisse. Dies schafft Vertrauen und Rückverfolgbarkeit in der KI-Lieferkette.
6. Souveränitätskonformität: Ausrichtung an regulatorischen Rahmenbedingungen durch Nutzung spezifischer Cloud-Angebote und Partnerschaften, um sicherzustellen, dass die rechtliche und operative Kontrolle innerhalb konformer Gerichtsbarkeiten liegt.

So fügen sich diese Komponenten für eine hochsichere Vertex AI-Bereitstellung zusammen:

Bei der Netzwerkisolation bevorzuge ich typischerweise Private Service Connect (PSC) gegenüber VPC Peering für die Verbindung zu verwalteten Diensten wie Vertex AI. Während VPC Peering funktioniert, bietet PSC eine sauberere Trennung. Mit PSC präsentieren sich Vertex AI-Dienste als Endpunkte direkt in meiner VPC und verbrauchen eine interne IP-Adresse. Dies eliminiert die Notwendigkeit für transitives Routing oder die Verwaltung von Peer-Netzwerken, vereinfacht meine Netzwerkarchitektur und reduziert die Angriffsfläche. Es ist eine dedizierte, interne Netzwerkverbindung, die das öffentliche Internet vollständig umgeht.

VPC Service Controls (VPC-SC) ist meine digitale Fort Knox-Mauer. Es ermöglicht mir, Sicherheitsperimeter um meine GCP-Projekte und die darin enthaltenen Dienste wie Vertex AI und Cloud Storage zu definieren. Jeder Versuch, Daten zu verschieben oder auf Ressourcen von außerhalb dieses Perimeters zuzugreifen, wird blockiert, unabhängig von IAM-Berechtigungen. Dies ist eine kritische Verteidigungslinie gegen Datenexfiltration, die sicherstellt, dass selbst wenn ein Angreifer ein Dienstkonto kompromittiert, er keine Daten außerhalb meines definierten Perimeters extrahieren kann. Es schafft effektiv eine richtlinienbasierte Luftschnittstelle für meine sensiblen Dienste.

Für Daten im Ruhezustand und während der Übertragung sind kundenseitig verwaltete Verschlüsselungsschlüssel (CMEK) von größter Bedeutung. Während Google Daten standardmäßig verschlüsselt, gibt mir CMEK die kryptografische Kontrolle über die Schlüssel, die meine Modelle im Vertex AI Model Registry und ihre zugehörigen Artefakte in Cloud Storage schützen. Dies ist eine häufige Anforderung in regulierten Branchen. Für Daten während der Übertragung verwenden private Vertex AI-Endpunkte inhärent TLS (Transport Layer Security), um sicherzustellen, dass die gesamte Kommunikation zwischen meiner VPC und dem Vertex AI-Dienst verschlüsselt und sicher ist.

Schließlich muss das Identity & Access Management (IAM) chirurgisch präzise sein. Ich plädiere stets für separate Dienstkonten für unterschiedliche Aktionen. Die Identität, die ein Modell bereitstellt, sollte sich von dem Dienstkonto unterscheiden, das den Endpunkt zur Inferenz aufruft. Dies entspricht dem Prinzip des geringsten Privilegs und minimiert den Explosionsradius eines kompromittierten Anmeldeinformations. Zum Beispiel könnte ein model-deployer-Dienstkonto aiplatform.admin für Modelle haben, während ein inference-invoker-Dienstkonto nur aiplatform.user für spezifische Endpunkte hätte.

In Europa intensiviert sich die Diskussion um Datensouveränität und digitales Vertrauen. Das Konzept der „Cloud de Confiance“ (Vertrauenscloud) gewinnt an Bedeutung, insbesondere in Frankreich mit seiner SecNumCloud-Zertifizierung. Um jedoch wirklich zu verstehen, was diese Anforderungen für KI-Workloads auf GCP bedeuten, lohnt es sich, über die Namensnennungen hinauszugehen und die Mechanismen zu untersuchen, warum Standard-Cloud-Sicherheitskontrollen – selbst gehärtete wie die in diesem Leitfaden behandelten – für Organisationen, die unter französischen öffentlichen Mandaten oder strengen EU-Souveränitätsanforderungen operieren, nicht ausreichen.

Das Grundproblem: Extraterritoriales Recht

Bevor wir über S3NS sprechen, müssen wir verstehen, warum es existiert. Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) bedeutet, dass ein US-Unternehmen – einschließlich Google – gezwungen werden kann, Daten herauszugeben, die es kontrolliert, selbst wenn diese Daten physisch in Europa gespeichert sind. Standard-Cloud-Sicherheitskontrollen (VPC Service Controls, CMEK, Private Service Connect) schützen Sie vor externen Bedrohungen und Fehlkonfigurationen, aber sie ändern nicht die grundlegende rechtliche Realität: Google ist ein US-Unternehmen, und sein operatives Personal kann theoretisch gezwungen werden, nach US-Recht zu handeln. Dies ist, was SecNumCloud und S3NS direkt angehen.

Was ist SecNumCloud?

SecNumCloud ist ein Qualifizierungsrahmen, der von der ANSSI (Agence nationale de la sécurité des systèmes d'information), der französischen nationalen Cybersicherheitsbehörde, veröffentlicht wurde. Version 3,2 – die aktuelle und operativ bedeutende Version – umfasst 276 Anforderungen in 15 Sicherheitsbereichen: Betriebssicherheit, Kryptologie, Zugriffssteuerung, Netzwerksicherheit, Geschäftskontinuität, Incident Management und, kritisch, Schutz vor extraterritorialen Gesetzen. Dieser letzte Bereich unterscheidet SecNumCloud von anderen europäischen Sicherheitszertifizierungen wie ISO 27001 oder BSI C5. Es ist nicht nur ein Cybersicherheitsstandard; es ist gleichzeitig ein gerichtlicher Kontrollrahmen. Ein Anbieter kann die SecNumCloud-Qualifikation nur erhalten, wenn er nachweisen kann, dass ausländische Regierungen keinen rechtlichen oder technischen Mechanismus haben, um den Zugriff auf Kundendaten zu erzwingen.

S3NS: Struktur und Unternehmensdesign

S3NS (ausgesprochen sens, französisch für „Sinn“) ist ein Joint Venture, das von Anfang an so strukturiert ist, dass es rechtlich immun gegen US-amerikanischen extraterritorialen Druck ist. Wichtige Fakten:

• Mehrheitsbesitz: Thales hält die Mehrheitsbeteiligung; Google Cloud hält ca. 20 %.
• Gerichtsstand: S3NS ist eine französische société par actions simplifiée (SAS), die ausschließlich dem europäischen Recht unterliegt.
• Konsequenz: Jede Datenanfrage der US-Regierung an S3NS kann – und würde – abgelehnt werden; es gibt keinen rechtlichen Mechanismus, über den Google S3NS einseitig zum Handeln zwingen könnte.

Die Unternehmensstruktur ist eine absichtliche Souveränitätsarchitektur: Google bringt die Technologie, Thales und S3NS die europäische rechtliche Hülle und die operative Kontrolle.

Zwei Stufen: CRYPT3NS vs. PREMI3NS

S3NS bietet zwei verschiedene Dienstebenen an, und diese zu verwechseln ist ein häufiger Fehler:

Für die meisten europäischen Privatunternehmen bietet CRYPT3NS einen sinnvollen Schutz durch Datenresidenzkontrollen und rechtliche Zuständigkeit. Für Organisationen, die strengen französischen Regeln für das öffentliche Beschaffungswesen, Verteidigungslieferketten oder Sektoren unterliegen, die explizit eine SecNumCloud-Qualifikation erfordern, erfüllt nur PREMI3NS die Anforderungen.

Wie PREMI3NS technische Isolation erreicht

Dies ist die Kernfrage: Wie können GCP-Dienste in einem Rechenzentrum laufen, über das Google keine Kontrolle hat?

Die Antwort ist Google Cloud Dedicated – eine Architektur, bei der Google seine Technologieschicht (Compute-, Speicher- und Netzwerksoftware) an S3NS lizenziert, das sie dann vollständig auf seiner eigenen physischen Infrastruktur bereitstellt und betreibt. Mehrere bewusste Kontrollmechanismen ermöglichen dies:

1. Physisch isolierte Infrastruktur: PREMI3NS läuft auf eigener Compute-, Speicher- und Netzwerkhardware in französischen Rechenzentren. Diese Systeme sind vollständig von Googles globaler öffentlicher Cloud getrennt – es gibt keine gemeinsame Fabric und keine gemeinsame Steuerungsebene, die Google-Mitarbeitern zugänglich ist.

2. Kein Google-Zugriff: Google-Mitarbeiter haben keinen physischen oder logischen Zugriff auf die PREMI3NS-Umgebung. Operationen, Administration und Support werden ausschließlich von S3NS-Mitarbeitern innerhalb der EU durchgeführt. Eskalationen, die normalerweise das Google-Engineering erreichen würden, werden intern von S3NS bearbeitet.

3. Update-Quarantänemodell: Wenn Google ein Software-Update veröffentlicht – Kernel-Patches, Service-Updates, neue Funktionen – fängt S3NS es in einer Quarantäneumgebung ab. S3NS-Ingenieure führen automatisierte Reverse-Engineering- und Sicherheitsanalysen an den Binärdateien durch, bevor sie entscheiden, ob sie diese in der Produktion bereitstellen. S3NS führt Googles Code nicht passiv aus; es ist ein aktiver Gatekeeper jeder Softwareänderung, die seine Infrastruktur erreicht.

4. Souveräne kryptografische Kontrolle: S3NS verwaltet die kryptografischen Vertrauenswurzeln für die PREMI3NS-Umgebung. Im Gegensatz zu CMEK auf Standard-GCP, wo Sie Schlüssel verwalten, Google aber immer noch die Infrastruktur betreibt, liegt bei PREMI3NS die gesamte Schlüsselverwaltungshierarchie unter der Kontrolle von S3NS und dem Kunden – nicht der von Google.

5. Dual SOC-Modell: S3NS betreibt sein eigenes Security Operations Center in Koordination mit dem ANSSI-zertifizierten P10 SOC von Thales und bietet eine doppelte Überwachung auf abnormes Verhalten, einschließlich jedes Versuchs, einen für Google zugänglichen Zugriffspfad einzuführen.

Aktueller Servicekatalog und die Vertex AI-Roadmap

Mit Stand der Qualifizierung vom Dezember 2025 deckt PREMI3NS die Kerninfrastruktur für die meisten regulierten Workloads ab: Compute Engine, Cloud GPUs (NVIDIA H100s), Cloud Storage, Netzwerk (DNS, VPN, Load Balancing, Cloud Armor, Interconnect), BigQuery Enterprise, Pub/Sub, GKE Autopilot, Cloud SQL Enterprise Plus und Operations-Tools (Monitoring, Logging). Eine zweite Welle – Cloud Run, Cloud Build, Cloud Spanner, Cloud Bigtable, Secret Manager, Confidential VMs und Admin Access Transparency – steht für H1 2026 zur Qualifizierung an.

Für Vertex AI spezifisch sind die Kernfundamente (Model Garden für Open-Weight-Modelle, Model Registry, Workbench und Online Inference) für H2 2026 auf der Roadmap. Gemini wird nicht im anfänglichen Model Garden enthalten sein – nur Open-Source- und Open-Weight-Modelle sind zunächst enthalten, was eine wesentliche Überlegung für das souveräne AI-Inferenzdesign heute ist. Wenn Sie jetzt eine SecNumCloud-qualifizierte Inferenz benötigen, besteht der praktische Weg darin, Ihre eigenen Modelle auf GKE Autopilot mit H100 GPUs auf PREMI3NS bereitzustellen. Verwaltetes Vertex AI auf PREMI3NS steht unmittelbar bevor, ist aber noch nicht verfügbar.

Wann S3NS und wann Standard-GCP-Härtung verwenden

Die im Rest dieses Leitfadens behandelten Kontrollen (PSC, VPC-SC, CMEK) sind für die überwiegende Mehrheit der regulierten EU-Workloads sehr effektiv. Die folgende Heuristik hilft bei der Entscheidung, welche Stufe geeignet ist:

• Standard-gehärtetes GCP (dieser Leitfaden): ausreichend für DSGVO, NIS2, ISO 27001, Bank-/Versicherungsrahmen und jede Organisation, bei der die operative Isolation vom US-Recht keine explizite Beschaffungsanforderung ist.
• CRYPT3NS: angemessen, wenn französische Gerichtsbarkeit und Datenresidenzgarantien erforderlich sind, aber keine vollständige Infrastrukturisolation vorgeschrieben ist.
• PREMI3NS: obligatorisch, wenn eine SecNumCloud-Qualifikation erforderlich ist – französische OIV (Opérateurs d'Importance Vitale), Verteidigungslieferkette, sensible Regierungsdaten oder jede Beschaffungsspezifikation, die explizit auf SecNumCloud verweist.

Die Vergabe des 180 Millionen Euro schweren EU-Sovereign-Cloud-Vertrags unter Beteiligung von S3NS und die Einführung von SAP RISE auf PREMI3NS durch Thales signalisieren, dass dieses Modell von der Pilotphase zur Produktion im großen Maßstab übergegangen ist.

Zuerst stelle ich eine private Verbindung zu Vertex AI her. Dies beinhaltet die Erstellung eines Private Service Connect-Endpunkts in meiner VPC, der sich mit dem Vertex AI-Dienstproduzentennetzwerk verbindet. Beachten Sie, dass Vertex AI intern seinen eigenen Service-Anhang bereitstellt; ich muss nur die Consumer-Seite in meinem Projekt konfigurieren.

# main.tf
# Define variables for your project and region
variable "gcp_project_id" {
  description = "The ID of your GCP project."
  type        = string
}

variable "gcp_region" {
  description = "The GCP region for resources (e.g., europe-west1)"
  type        = string
  default     = "europe-west1" # Always prefer European regions
}

variable "vpc_network_name" {
  description = "The name of your existing VPC network."
  type        = string
  default     = "vertex-ai-inference-vpc" # Example VPC name
}

# Configure the GCP provider
provider "google" {
  project = var.gcp_project_id
  region  = var.gcp_region
}

# Create a Private Service Connect endpoint for Vertex AI
# This service attachment name is specific to Vertex AI Prediction
# and is a Google-managed producer endpoint.
resource "google_compute_network_attachment" "vertex_ai_psc_endpoint" {
  name        = "vertex-ai-psc-endpoint"
  project     = var.gcp_project_id
  region      = var.gcp_region
  description = "PSC endpoint for Vertex AI Prediction service."
  network     = "projects/${var.gcp_project_id}/global/networks/${var.vpc_network_name}"

  # The service_attachment_names array must reference the Google-managed producer attachment.
  # For Vertex AI Prediction, the format is 'projects/REGION-aiplatform/regions/REGION/serviceAttachments/aiplatform-producer-REGION'
  # Replace REGION with the specific region you are deploying to (e.g., europe-west1).
  service_attachment_names = ["projects/${var.gcp_region}-aiplatform/regions/${var.gcp_region}/serviceAttachments/aiplatform-producer-${var.gcp_region}"]
}

output "psc_endpoint_link" {
  description = "The self_link of the Private Service Connect network attachment."
  value       = google_compute_network_attachment.vertex_ai_psc_endpoint.self_link
}

# Note: For managed services like Vertex AI, you typically interact via DNS names
# that resolve to the private IP behind the scenes. This PSC endpoint enables that private resolution.

Diese Terraform-Konfiguration richtet die Consumer-Seite von PSC ein. Der Schlüssel ist die korrekte Identifizierung der service_attachment_names für Vertex AI Prediction in Ihrer ausgewählten Region. Sobald dies bereitgestellt ist, wird jeder Datenverkehr von Ihrem vertex-ai-inference-vpc zu diesem Endpunkt privat an Vertex AI weitergeleitet. Während die Ausgabe psc_endpoint_link den Ressourcenlink bereitstellt, interagieren Sie bei verwalteten Diensten wie Vertex AI typischerweise über DNS-Namen, die im Hintergrund zu dieser privaten IP-Adresse aufgelöst werden. Konsultieren Sie die offizielle Private Service Connect-Dokumentation für die aktuellsten Service-Anhangsnamen.

Als Nächstes definiere ich einen Sicherheitsperimeter um meine Projekte und kritischen Dienste. Dieses Beispiel geht davon aus, dass Sie eine Organisation in GCP definiert haben, was eine Voraussetzung für VPC-SC ist.

# vpc_sc.tf
resource "google_access_context_manager_service_perimeter" "vertex_ai_perimeter" {
  parent = "organizations/YOUR_ORGANIZATION_ID" # IMPORTANT: Replace with your actual organization ID
  name   = "accessPolicies/YOUR_ACCESS_POLICY_ID/servicePerimeters/vertex_ai_sec_perimeter" # IMPORTANT: Replace with your actual Access Policy ID
  title  = "vertex-ai-sec-perimeter"

  perimeter_type = "REGULAR"

  status {
    restricted_services = [
      "aiplatform.googleapis.com",
      "storage.googleapis.com" # Critical for models and artifacts in Cloud Storage
    ]

    # If you have specific access levels defined (e.g., trusted IP ranges or device policies),
    # you would list them here. For this example, we assume basic project inclusion.
    # For creating an access policy and level, refer to Google Cloud's Access Context Manager docs.
    # access_levels = [
    #   "accessPolicies/YOUR_ACCESS_POLICY_ID/accessLevels/trusted_networks_and_devices" # Example access level
    # ]

    resources = [
      "projects/${var.gcp_project_id}" # Your project where Vertex AI is deployed
    ]
  }

  description = "VPC-SC perimeter for Vertex AI and associated storage."
}

Dieser Terraform-Block erstellt einen VPC-SC-Perimeter. Ich nehme aiplatform.googleapis.com und storage.googleapis.com in restricted_services auf, da meine Modelle und Datensätze oft in Cloud Storage liegen. Das Feld resources gibt an, welche Projekte durch diesen Perimeter geschützt sind. Denken Sie daran, dass VPC-SC-Richtlinien nach IAM ausgewertet werden, sodass selbst wenn eine Identität storage.admin-Berechtigungen hat, ihre Anfrage abgelehnt wird, wenn sie sich außerhalb des Perimeters befindet oder eine Zugriffsebene verletzt. Dies bietet eine robuste Ebene zur Verhinderung von Datenexfiltration.

Hinweis: Das Einrichten von access_levels und access_policies erfordert eine sorgfältige Planung auf Organisationsebene. Eine detaillierte Anleitung finden Sie in der Dokumentation zu VPC Service Controls.

Die Kontrolle über Ihre Verschlüsselungsschlüssel ist ein wichtiger Schritt zur Einhaltung gesetzlicher Vorschriften. Ich erstelle einen Cloud KMS-Schlüsselring und einen Schlüssel und erteile dann Vertex AI die notwendigen Berechtigungen, um ihn zu verwenden.

# Step 3a: Create a KMS Key Ring and Key
# Key rings organize keys; keys perform encryption/decryption.
KMS_KEYRING_NAME="vertex-ai-model-keyring"
KMS_KEY_NAME="vertex-ai-model-key"
KMS_LOCATION="europe-west1" # Match your Vertex AI region for optimal latency
PROJECT_ID="my-gcp-project-id" # Replace with your actual project ID

gcloud kms keyrings create "${KMS_KEYRING_NAME}" \n       --location="${KMS_LOCATION}" \n       --project="${PROJECT_ID}"

gcloud kms keys create "${KMS_KEY_NAME}" \n       --keyring="${KMS_KEYRING_NAME}" \n       --location="${KMS_LOCATION}" \n       --purpose="encryption" \n       --project="${PROJECT_ID}"

# Step 3b: Grant Vertex AI Service Agent permissions to use the KMS Key
# The Vertex AI Service Agent is specific to your project and region.
# Format: service-<PROJECT_NUMBER>@gcp-sa-aiplatform.iam.gserviceaccount.com
# Get your project number:
PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
VERTEX_AI_SERVICE_AGENT="service-${PROJECT_NUMBER}@gcp-sa-aiplatform.iam.gserviceaccount.com"

KMS_KEY_RESOURCE="projects/${PROJECT_ID}/locations/${KMS_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}"

gcloud kms keys add-iam-policy-binding "${KMS_KEY_NAME}" \n       --location="${KMS_LOCATION}" \n       --keyring="${KMS_KEYRING_NAME}" \n       --member="serviceAccount:${VERTEX_AI_SERVICE_AGENT}" \n       --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" \n       --project="${PROJECT_ID}"

echo "KMS Key Resource Name: ${KMS_KEY_RESOURCE}"

Erwartete Ausgabe (Beispiel für die Schlüsselerstellung):

Created keyring [vertex-ai-model-keyring].
Created key [vertex-ai-model-key].
Updated IAM policy for key [vertex-ai-model-key].
KMS Key Resource Name: projects/my-gcp-project-id/locations/europe-west1/keyRings/vertex-ai-model-keyring/cryptoKeys/vertex-ai-model-key

Wenn ich nun ein Modell mit Vertex AI hochlade oder registriere, gebe ich diese KMS_KEY_RESOURCE an, um sicherzustellen, dass meine Modellartefakte mit meinem CMEK verschlüsselt werden. Dies geschieht typischerweise während des Model.upload()-Vorgangs im Vertex AI SDK oder über die REST-API:

# Python 3.13+ example for uploading a model with CMEK
from google.cloud import aiplatform

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
MODEL_DISPLAY_NAME = "my-secure-model"
MODEL_ARTIFACT_URI = "gs://my-secure-model-bucket/path/to/model/artifacts/" # Replace with your GCS bucket for model artifacts
SERVING_CONTAINER_IMAGE_URI = "europe-west1-docker.pkg.dev/cloud-aiplatform/prediction/tf2-cpu.2-11:latest"
KMS_KEY_RESOURCE = f"projects/{PROJECT_ID}/locations/{REGION}/keyRings/{KMS_KEYRING_NAME}/cryptoKeys/{KMS_KEY_NAME}"

# Initialize the Vertex AI SDK
aiplatform.init(project=PROJECT_ID, location=REGION)

# Upload the model with CMEK
model = aiplatform.Model.upload(
    display_name=MODEL_DISPLAY_NAME,
    artifact_uri=MODEL_ARTIFACT_URI,
    serving_container_image_uri=SERVING_CONTAINER_IMAGE_URI,
    encryption_spec_key_name=KMS_KEY_RESOURCE,
    sync=True
)

print(f"Model uploaded and encrypted with CMEK: {model.resource_name}")

Dies stellt sicher, dass Ihr Modell, wenn es im Register und den zugehörigen Cloud Storage-Buckets gespeichert wird, durch Ihre kryptografischen Schlüssel geschützt ist, wodurch eine kritische Souveränitätsanforderung erfüllt wird.

Die Implementierung des Prinzips der geringsten Privilegien ist entscheidend. Ich trenne die Berechtigungen für die Modellbereitstellung von denen für den Modellaufruf. So erstelle ich ein dediziertes Dienstkonto für die Inferenz und erteile ihm nur die notwendigen Berechtigungen.

# Step 4a: Create a dedicated service account for inference
PROJECT_ID="my-gcp-project-id" # Replace with your actual project ID
INFERENCE_SA_NAME="vertex-inference-sa"
INFERENCE_SA_DESCRIPTION="Service account for invoking Vertex AI endpoints."

gcloud iam service-accounts create "${INFERENCE_SA_NAME}" \n       --display-name="${INFERENCE_SA_DESCRIPTION}" \n       --project="${PROJECT_ID}"

INFERENCE_SA_EMAIL="${INFERENCE_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

# Step 4b: Grant necessary roles for endpoint invocation
# aiplatform.user allows invoking predictions on endpoints.
# aiplatform.endpointViewer might also be needed to view endpoint details.

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \n       --member="serviceAccount:${INFERENCE_SA_EMAIL}" \n       --role="roles/aiplatform.user" \n       --project="${PROJECT_ID}"

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \n       --member="serviceAccount:${INFERENCE_SA_EMAIL}" \n       --role="roles/aiplatform.endpointViewer" \n       --project="${PROJECT_ID}"

echo "Inference Service Account: ${INFERENCE_SA_EMAIL}"

Erwartete Ausgabe (Beispiel):

Created service account [vertex-inference-sa].
Updated policy for project [my-gcp-project-id].
Updated policy for project [my-gcp-project-id].
Inference Service Account: vertex-inference-sa@my-gcp-project-id.iam.gserviceaccount.com

Wenn Ihre Clientanwendung oder andere Dienste den Vertex AI-Endpunkt aufrufen müssen, sollten sie dieses vertex-inference-sa-Dienstkonto imitieren oder dessen Anmeldeinformationen verwenden. Dies minimiert das Risiko: Wenn dieses Dienstkonto kompromittiert wird, kann es nur Vorhersagen aufrufen und beispielsweise keine Modelle löschen oder Ihre Vertex AI-Einrichtung ändern.

Schließlich stelle ich das CMEK-verschlüsselte Modell auf einem Endpunkt bereit, der unsere private Netzwerkkonfiguration nutzt. Ich werde eine Endpunktressource definieren und das zuvor hochgeladene Modell bereitstellen.

# Python 3.13+ example for deploying to a private endpoint
from google.cloud import aiplatform

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
MODEL_RESOURCE_NAME = model.resource_name # From previous step's model upload
ENDPOINT_DISPLAY_NAME = "my-secure-inference-endpoint"

# Initialize the Vertex AI SDK
aiplatform.init(project=PROJECT_ID, location=REGION)

# Define the endpoint configuration
endpoint = aiplatform.Endpoint.create(
    display_name=ENDPOINT_DISPLAY_NAME,
    project=PROJECT_ID,
    location=REGION,
    # network and enable_private_service_connect are key for private endpoint
    # The network must be in the same region as the endpoint. This refers to your VPC.
    network=f"projects/{PROJECT_ID}/global/networks/vertex-ai-inference-vpc", # Use your defined VPC network name
    enable_private_service_connect=True,
    sync=True
)

# Deploy the model to the endpoint
# You might specify machine type and other scaling settings here.
# This example assumes a simple deployment.
endpoint.deploy(
    model=model,
    deployed_model_display_name=f"{MODEL_DISPLAY_NAME}-deployed",
    machine_type="n1-standard-4", # Example machine type
    min_replica_count=1,
    max_replica_count=2,
    sync=True
)

print(f"Model {MODEL_DISPLAY_NAME} deployed to private endpoint: {endpoint.resource_name}")

Diese Bereitstellung stellt sicher, dass Ihr Modell auf einem Endpunkt gehostet wird, der nur über Ihre konfigurierte Private Service Connect-Verbindung zugänglich ist, innerhalb des VPC Service Controls-Perimeters betrieben wird und Ihre kundenseitig verwalteten Verschlüsselungsschlüssel verwendet.

Vollständiges Beispiel-Repository: Weitere offizielle Beispiele für sichere Vertex AI-Muster finden Sie unter github.com/GoogleCloudPlatform/vertex-ai-samples/tree/main/community-content/vertex_security_examples.

Zusätzliche Codebeispiele: Für fortgeschrittene Bereitstellungsmuster und CI/CD-Integration für Vertex AI befindet sich ein Repository mit meinen komplexeren Implementierungen typischerweise in meinem privaten Workflow.

Um zu überprüfen, ob Ihr Endpunkt privat und gesichert ist, sollten Sie versuchen, ihn aus Ihrem VPC-Netzwerk aufzurufen, indem Sie das Dienstkonto mit eingeschränkten Berechtigungen verwenden.

# Python 3.13+ example for invoking the private endpoint
from google.cloud import aiplatform
from google.oauth2 import service_account

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
# Replace with your endpoint's full resource name (e.g., projects/PROJECT_NUMBER/locations/europe-west1/endpoints/ENDPOINT_ID)
ENDPOINT_RESOURCE_NAME = "projects/123456789012/locations/europe-west1/endpoints/1234567890"
INFERENCE_SA_KEY_PATH = "/path/to/your/vertex-inference-sa-key.json" # Path to the downloaded service account key file

# Initialize the AI Platform client with the service account credentials
credentials = service_account.Credentials.from_service_account_file(INFERENCE_SA_KEY_PATH)

aiplatform.init(project=PROJECT_ID, location=REGION, credentials=credentials)

# Prepare sample data for prediction (replace with actual model input format)
# This is illustrative pseudocode for data; adapt for your model's expected input.
instances = [
    {"feature_1": 1.0, "feature_2": "value"},
    {"feature_1": 2.5, "feature_2": "another_value"}
]

# Get the endpoint instance by its resource name
endpoint = aiplatform.Endpoint(ENDPOINT_RESOURCE_NAME)

try:
    prediction = endpoint.predict(instances=instances)
    print("Prediction successful:")
    print(prediction.predictions)
except Exception as e:
    print(f"Prediction failed: {e}")
    print("Verify network, IAM, and VPC-SC configurations.")

Erwartete Ausgabe:

Prediction successful:
[model output data]

Wenn Sie versuchen, diesen Endpunkt von außerhalb Ihres VPC (z. B. von Ihrem lokalen Rechner ohne VPN/Cloud Interconnect zu Ihrem VPC) oder ohne die Anmeldeinformationen von vertex-inference-sa aufzurufen, sollten Sie eine Verbindungsfehlermeldung oder eine Meldung wegen fehlender Berechtigung erwarten, was bestätigt, dass Ihre Sicherheitskontrollen aktiv sind.

1. Fehler: VPC Service Controls-Verletzung

Anfrage ist durch die Richtlinie der Organisation verboten.

**Lösung:** Dies bedeutet typischerweise, dass eine Anfrage (z. B. der Versuch, auf einen Bucket außerhalb des Perimeters oder von einer nicht konformen IP-Adresse zuzugreifen) von VPC-SC blockiert wird. Überprüfen Sie Ihre `google_access_context_manager_service_perimeter`-Konfiguration erneut. Stellen Sie sicher, dass der IP-Bereich oder die Zugriffsebene Ihres Clients in der Zugriffsrichtlinie korrekt definiert ist, wenn die Anfrage legitim ist. Überprüfen Sie auch, ob alle Dienste, auf die Ihr Vorgang angewiesen ist (wie Cloud Storage für Modellartefakte), in `restricted_services` enthalten sind und dass das Projekt in `resources` innerhalb des Perimeters aufgeführt ist. Spezifische Details zu Zugriffsebenen finden Sie in der [Google Cloud Access Context Manager-Dokumentation](https://cloud.google.com/access-context-manager/docs/overview).

1. Fehler: IAM-Berechtigung verweigert

403 Berechtigung für Ressource projects/PROJECT_NUMBER/locations/REGION/endpoints/ENDPOINT_ID verweigert

**Lösung:** Das Dienstkonto oder der Benutzer, der die Anfrage stellt, verfügt nicht über die erforderliche `aiplatform.user`-Rolle (oder `aiplatform.endpointViewer`, wenn Sie nur Endpunktdetails anzeigen möchten) für den Vertex AI-Endpunkt oder das Projekt. Überprüfen Sie die IAM-Richtlinienbindungen für Ihr Inferenz-Dienstkonto mit `gcloud iam service-accounts get-iam-policy INFERENCE_SA_EMAIL` und `gcloud projects get-iam-policy my-gcp-project-id`. Stellen Sie sicher, dass die richtigen Rollen im entsprechenden Umfang zugewiesen sind.

1. Fehler: Private Service Connect-Konnektivitätsproblem

Verbindung zum Endpunkt konnte nicht hergestellt werden. Überprüfen Sie die Netzwerkkonfiguration.

**Lösung:** Dies deutet auf ein Problem mit dem privaten Netzwerkpfad hin. Überprüfen Sie, ob Ihre `google_compute_network_attachment` korrekt bereitgestellt ist und ihr Status `ACCEPTED` ist. Überprüfen Sie die Firewall-Regeln in Ihrer VPC, um sicherzustellen, dass Datenverkehr von Ihrem Client zum IP-Bereich des PSC-Endpunkts zugelassen wird. Bestätigen Sie auch, dass die DNS-Auflösung für den Vertex AI-Endpunkt zu einer internen IP-Adresse innerhalb Ihrer VPC auflöst und nicht zu einer öffentlichen. Wenn Sie `gcloud` verwenden, stellen Sie sicher, dass Ihr Client von einer VM innerhalb derselben VPC ausgeführt wird oder über VPN/Interconnect verbunden ist.