1. Netwerkisolatie: Het volledig omzeilen van het publieke internet voor inferentieverkeer is ononderhandelbaar voor gevoelige workloads. Dit voorkomt veelvoorkomende netwerkgebaseerde aanvallen en data-onderschepping.
2. Perimeterbeveiliging (VPC-SC): Het instellen van vangrails tegen data-exfiltratie en ongeoorloofde projectoverschrijdende toegang. Dit fungeert als een logische luchtspleet.
3. Gegevensbescherming: Ervoor zorgen dat modellen en gegevens zowel in rust als onderweg worden versleuteld met behulp van door de klant beheerde sleutels. Dit geeft me directe controle over mijn cryptografisch materiaal.
4. Least Privilege Access: Het implementeren van granulaire IAM-rollen, waarbij de verantwoordelijkheden van modelimplementatie gescheiden worden van modelaanroep. Dit minimaliseert de impactradius van gecompromitteerde inloggegevens.
5. Modelgovernance: Het implementeren van praktijken zoals modelondertekening (bijv. met Sigstore/Cosign), kwetsbaarheidsscans van modelafhankelijkheden en uitgebreide auditlogging voor alle levenscyclusgebeurtenissen van modellen. Dit bouwt vertrouwen en traceerbaarheid op in de AI-supply chain.
6. Soevereiniteitscompliance: Het afstemmen op regelgevende kaders door gebruik te maken van specifieke cloudaanbiedingen en partnerschappen, zodat juridische en operationele controle binnen conforme jurisdicties blijft.

Zo passen deze componenten samen voor een zeer veilige Vertex AI-implementatie:

Als het gaat om netwerkisolatie, kies ik meestal voor Private Service Connect (PSC) boven VPC Peering voor verbinding met beheerde services zoals Vertex AI. Hoewel VPC Peering werkt, biedt PSC een schonere scheiding. Met PSC presenteren Vertex AI-services zich als eindpunten direct binnen mijn VPC, waarbij ze een intern IP-adres consumeren. Dit elimineert de noodzaak van transitieve routering of het beheren van peered netwerken, wat mijn netwerkarchitectuur vereenvoudigt en het aanvalsoppervlak verkleint. Het is een speciale, interne netwerkverbinding, die het publieke internet volledig omzeilt.

VPC Service Controls (VPC-SC) is mijn digitale Fort Knox-muur. Het stelt me in staat om beveiligingsperimeters te definiëren rond mijn GCP-projecten en de services daarbinnen, zoals Vertex AI en Cloud Storage. Elke poging om gegevens te verplaatsen of toegang te krijgen tot bronnen van buiten deze perimeter wordt geblokkeerd, ongeacht IAM-permissies. Dit is een kritieke verdedigingslinie tegen data-exfiltratie, die ervoor zorgt dat zelfs als een aanvaller een serviceaccount compromitteert, deze geen gegevens buiten mijn gedefinieerde perimeter kan extraheren. Het creëert effectief een op beleid gebaseerde luchtspleet voor mijn gevoelige services.

Voor gegevens in rust en onderweg zijn door de klant beheerde versleutelingssleutels (CMEK) van cruciaal belang. Hoewel Google gegevens standaard versleutelt, geeft CMEK mij cryptografische controle over de sleutels die mijn modellen in de Vertex AI Model Registry en de bijbehorende artefacten in Cloud Storage beschermen. Dit is een veelvoorkomende vereiste in gereguleerde sectoren. Voor gegevens onderweg gebruiken privé-eindpunten van Vertex AI inherent TLS (Transport Layer Security), wat ervoor zorgt dat alle communicatie tussen mijn VPC en de Vertex AI-service versleuteld en veilig is.

Tot slot moet Identity & Access Management (IAM) chirurgisch zijn. Ik pleit altijd voor afzonderlijke serviceaccounts voor afzonderlijke acties. De identiteit die een model implementeert, moet verschillen van het serviceaccount dat het eindpunt aanroept voor inferentie. Dit sluit aan bij het principe van minst privilege, waardoor de explosieradius van gecompromitteerde referenties wordt geminimaliseerd. Een model-deployer serviceaccount heeft bijvoorbeeld aiplatform.admin voor modellen, terwijl een inference-invoker serviceaccount alleen aiplatform.user heeft voor specifieke eindpunten.

In Europa intensiveert het gesprek rond data-soevereiniteit en digitaal vertrouwen. Het concept van "cloud de confiance" (vertrouwenscloud) wint terrein, met name in Frankrijk met zijn SecNumCloud-certificering. Maar om echt te begrijpen wat deze vereisten betekenen voor AI-workloads op GCP, is het de moeite waard om verder te kijken dan de namen en de mechanismen te onderzoeken waarom standaard cloudbeveiligingscontroles – zelfs geharde zoals die in deze gids worden behandeld – niet voldoende zijn voor organisaties die opereren onder Franse overheidsmandaten of strikte EU-soevereiniteitsvereisten.

Het kernprobleem: extraterritoriale wetgeving

Voordat we het over S3NS hebben, moeten we begrijpen waarom het bestaat. De US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) betekent dat een Amerikaans bedrijf – inclusief Google – gedwongen kan worden om gegevens die het controleert over te dragen, zelfs als die gegevens fysiek in Europa zijn opgeslagen. Standaard cloudbeveiligingscontroles (VPC Service Controls, CMEK, Private Service Connect) beschermen u tegen externe bedreigingen en misconfiguraties, maar ze veranderen de fundamentele jurisdictionele realiteit niet: Google is een Amerikaanse entiteit en het operationele personeel kan in theorie worden gedwongen om onder Amerikaans recht te handelen. Dit is wat SecNumCloud en S3NS rechtstreeks aanpakken.

Wat is SecNumCloud?

SecNumCloud is een kwalificatiekader, gepubliceerd door ANSSI (Agence nationale de la sécurité des systèmes d'information), de Franse nationale cyberbeveiligingsinstantie. Versie 3,2 – de huidige en operationeel significante versie – omvat 276 vereisten verdeeld over 15 beveiligingsdomeinen: operationele beveiliging, cryptologie, toegangscontrole, netwerkbeveiliging, bedrijfscontinuïteit, incidentbeheer, en cruciaal, bescherming tegen extraterritoriale wetgeving. Dat laatste domein onderscheidt SecNumCloud van andere Europese beveiligingscertificeringen zoals ISO 27001 of BSI C5. Het is niet puur een cyberbeveiligingsstandaard; het is tegelijkertijd een jurisdictioneel controlekader. Een aanbieder kan alleen de SecNumCloud-kwalificatie ontvangen als deze kan aantonen dat buitenlandse regeringen geen juridisch of technisch mechanisme hebben om toegang tot klantgegevens af te dwingen.

S3NS: structuur en bedrijfsvorm

S3NS (uitgesproken als sens, Frans voor "zin") is een joint venture die is gestructureerd om vanaf het begin juridisch immuun te zijn voor Amerikaanse extraterritoriale druk. Belangrijke feiten:

• Meerderheidsbelang: Thales heeft het meerderheidsbelang; Google Cloud heeft ongeveer 20%.
• Juridische jurisdictie: S3NS is een Franse société par actions simplifiée (SAS), wettelijk uitsluitend gebonden aan Europees recht.
• Gevolg: Elk verzoek om gegevens van de Amerikaanse regering gericht aan S3NS kan – en zou – worden afgewezen; er is geen juridisch mechanisme waardoor Google S3NS eenzijdig kan dwingen om te handelen.

De bedrijfsstructuur is opzettelijke soevereiniteitsengineering: Google levert de technologie, Thales en S3NS leveren de Europese juridische omhulling en operationele controle.

Twee lagen: CRYPT3NS vs. PREMI3NS

S3NS biedt twee verschillende serviceniveaus, en het verwarren ervan is een veelvoorkomende fout:

Voor de meeste EU-organisaties in de privésector biedt CRYPT3NS zinvolle bescherming via controles op data-residentie en juridische jurisdictie. Voor organisaties die vallen onder strikte Franse regels voor openbare aanbestedingen, defensie-toeleveringsketens of sectoren die expliciet een SecNumCloud-kwalificatie vereisen, voldoet alleen PREMI3NS aan de lat.

Hoe PREMI3NS technische isolatie bereikt

Dit is de kernvraag: hoe kunnen GCP-services draaien in een datacenter waarover Google geen controle heeft?

Het antwoord is Google Cloud Dedicated – een architectuur waarbij Google zijn technologiestack (compute-, opslag- en netwerksoftware) in licentie geeft aan S3NS, die deze vervolgens volledig op zijn eigen fysieke infrastructuur implementeert en exploiteert. Verschillende bewuste controlemechanismen maken dit mogelijk:

1. Fysiek geïsoleerde infrastructuur: PREMI3NS draait op zijn eigen compute-, opslag- en netwerkhardware in Franse datacenters. Deze systemen zijn volledig gescheiden van Google's wereldwijde openbare cloud – er is geen gedeelde structuur en geen gemeenschappelijk controlepaneel toegankelijk voor Google-medewerkers.

2. Geen Google-toegang: Google-personeel heeft geen fysieke of logische toegang tot de PREMI3NS-omgeving. Operaties, beheer en ondersteuning worden uitsluitend uitgevoerd door S3NS-medewerkers binnen de EU. Escalations die normaal gesproken Google-engineering zouden bereiken, worden intern afgehandeld door S3NS.

3. Quarantainemodel voor updates: Wanneer Google een software-update uitbrengt – kernelpatches, service-updates, nieuwe functies – onderschept S3NS deze in een quarantaineomgeving. S3NS-engineers voeren geautomatiseerde reverse-engineering en beveiligingsanalyse uit op de binaries voordat ze beslissen of ze deze in productie willen implementeren. S3NS draait niet passief Google's code; het is een actieve poortwachter van elke softwarewijziging die zijn infrastructuur bereikt.

4. Soevereine cryptografische controle: S3NS beheert de cryptografische roots of trust voor de PREMI3NS-omgeving. In tegenstelling tot CMEK op standaard GCP, waar u sleutels beheert maar Google nog steeds de infrastructuur beheert, bevindt de gehele sleutelbeheerhiërarchie op PREMI3NS zich onder S3NS en klantcontrole – niet die van Google.

5. Dubbel SOC-model: S3NS opereert zijn eigen Security Operations Centre in coördinatie met Thales' ANSSI-gecertificeerde P10 SOC, en biedt dubbele monitoring voor abnormaal gedrag, inclusief elke poging om een voor Google toegankelijk toegangspad te introduceren.

Huidig serviceaanbod en de Vertex AI-roadmap

Met ingang van de kwalificatie van december 2025 dekt PREMI3NS de kerninfrastructuur voor de meeste gereguleerde workloads: Compute Engine, Cloud GPU's (NVIDIA H100s), Cloud Storage, netwerken (DNS, VPN, Load Balancing, Cloud Armor, Interconnect), BigQuery Enterprise, Pub/Sub, GKE Autopilot, Cloud SQL Enterprise Plus en operationele tools (Monitoring, Logging). Een tweede golf – Cloud Run, Cloud Build, Cloud Spanner, Cloud Bigtable, Secret Manager, Confidential VM's en Admin Access Transparency – staat gepland voor kwalificatie in H1 2026.

Voor Vertex AI specifiek staan de kernfundamenten (Model Garden voor open-weight modellen, Model Registry, Workbench en Online Inferentie) op de roadmap voor H2 2026. Gemini zal niet in de initiële Model Garden worden opgenomen – alleen open-source en open-weight modellen worden in eerste instantie opgenomen, wat een belangrijke overweging is voor het ontwerp van soevereine AI-inferentie vandaag de dag. Als u nu een SecNumCloud-gekwalificeerde inferentie nodig heeft, is de praktische weg het implementeren van uw eigen modellen op GKE Autopilot met H100 GPU's op PREMI3NS. Beheerde Vertex AI op PREMI3NS is aanstaande, nog niet geleverd.

Wanneer S3NS te gebruiken versus standaard GCP-verharding

De controles die in de rest van deze gids worden behandeld (PSC, VPC-SC, CMEK) zijn zeer effectief voor de overgrote meerderheid van gereguleerde EU-workloads. De volgende heuristiek helpt bij het bepalen welke laag geschikt is:

• Standaard verhard GCP (deze gids): voldoende voor AVG, NIS2, ISO 27001, bank-/verzekeringskaders, en elke organisatie waar operationele isolatie van de Amerikaanse wet geen expliciete inkoopvereiste is.
• CRYPT3NS: passend wanneer Franse juridische jurisdictie en garanties voor data-residentie nodig zijn, maar volledige infrastructuurisolatie niet verplicht is.
• PREMI3NS: verplicht wanneer SecNumCloud-kwalificatie vereist is – Franse OIV (Opérateurs d'Importance Vitale), defensie-toeleveringsketen, gevoelige overheidsgegevens, of elke inkoopspecificatie die expliciet verwijst naar SecNumCloud.

De toekenning van het EU-soevereine cloudcontract van €180 miljoen waarbij S3NS betrokken is, en Thales' eigen adoptie van SAP RISE op PREMI3NS, signaleren dat dit model is overgegaan van pilot naar grootschalige productie.

Eerst leg ik een privéverbinding met Vertex AI tot stand. Dit omvat het maken van een Private Service Connect-eindpunt in mijn VPC dat verbinding maakt met het Vertex AI-serviceproducentnetwerk. Merk op dat Vertex AI intern zijn eigen service-attachment voorziet; ik hoef alleen de consumentenkant in mijn project te configureren.

# 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.

Deze Terraform-configuratie zet de consumentenkant van PSC op. De sleutel is het correct identificeren van de service_attachment_names voor Vertex AI Prediction in de door u gekozen regio. Eenmaal geïmplementeerd, wordt al het verkeer van uw vertex-ai-inference-vpc naar dit eindpunt privé gerouteerd naar Vertex AI. Hoewel de output psc_endpoint_link de resourcelink biedt, interacteert u voor beheerde services zoals Vertex AI doorgaans via DNS-namen die op de achtergrond naar dit privé-IP-adres verwijzen. Raadpleeg de officiële Private Service Connect-documentatie voor de meest up-to-date service-attachmentnamen.

Vervolgens definieer ik een beveiligingsperimeter rond mijn projecten en kritieke services. Dit voorbeeld gaat ervan uit dat u een organisatie hebt gedefinieerd in GCP, wat een vereiste is voor VPC-SC.

# 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."
}

Dit Terraform-blok creëert een VPC-SC-perimeter. Ik neem aiplatform.googleapis.com en storage.googleapis.com op in restricted_services, omdat mijn modellen en datasets vaak in Cloud Storage staan. Het veld resources specificeert welke projecten door deze perimeter worden beschermd. Onthoud dat VPC-SC-beleid na IAM wordt geëvalueerd, dus zelfs als een identiteit storage.admin-permissies heeft, wordt de aanvraag geweigerd als deze buiten de perimeter valt of een toegangsniveau schendt. Dit biedt een robuuste laag voor het voorkomen van data-exfiltratie.

Opmerking: Het instellen van access_levels en access_policies vereist zorgvuldige planning op organisatieniveau. Voor een gedetailleerde handleiding, raadpleeg de VPC Service Controls-documentatie.

Het beheren van uw versleutelingssleutels is een cruciale stap voor naleving van de regelgeving. Ik zal een Cloud KMS-sleutelring en -sleutel maken en vervolgens de nodige rechten verlenen aan Vertex AI om deze te gebruiken.

# 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}"

Verwachte uitvoer (voorbeeld voor sleutelaanmaak):

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

Nu, wanneer ik een model upload of registreer bij Vertex AI, specificeer ik deze KMS_KEY_RESOURCE om ervoor te zorgen dat mijn modelartefacten worden versleuteld met mijn CMEK. Dit wordt doorgaans gedaan tijdens de Model.upload()-operatie in de Vertex AI SDK of via de 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}")

Dit zorgt ervoor dat uw model, wanneer opgeslagen in de registry en de bijbehorende Cloud Storage-buckets, wordt beschermd door uw cryptografische sleutels, waarmee aan een kritieke soevereiniteitsvereiste wordt voldaan.

Het implementeren van het principe van minst privilege is cruciaal. Ik scheid de rechten voor modelimplementatie van die voor modelaanroep. Hier laat ik zien hoe ik een speciaal serviceaccount voor inferentie aanmaak en dit alleen de noodzakelijke rechten verleen.

# 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}"

Verwachte uitvoer (voorbeeld):

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

Wanneer uw clientapplicatie of andere services het Vertex AI-eindpunt moeten aanroepen, moeten ze dit vertex-inference-sa serviceaccount imiteren of diens inloggegevens gebruiken. Dit minimaliseert het risico: als dit serviceaccount wordt gecompromitteerd, kan het alleen voorspellingen aanroepen en kan het bijvoorbeeld geen modellen verwijderen of uw Vertex AI-setup wijzigen.

Tot slot implementeer ik het met CMEK versleutelde model naar een eindpunt dat gebruikmaakt van onze privénetwerkconfiguratie. Ik definieer een eindpuntbron en implementeer het model dat we eerder hebben geüpload.

# 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}")

Deze implementatie zorgt ervoor dat uw model wordt gehost op een eindpunt dat alleen toegankelijk is via uw geconfigureerde Private Service Connect-link, binnen de VPC Service Controls-perimeter opereert en gebruikmaakt van uw door de klant beheerde versleutelingssleutels.

Volledige voorbeeldrepository: U kunt meer officiële voorbeelden van veilige Vertex AI-patronen vinden op github.com/GoogleCloudPlatform/vertex-ai-samples/tree/main/community-content/vertex_security_examples.

Extra codevoorbeelden: Voor geavanceerde implementatiepatronen en CI/CD-integratie voor Vertex AI bevindt een repository met mijn complexere implementaties zich doorgaans in mijn privé-workflow.

Om te controleren of uw eindpunt privé en beveiligd is, moet u proberen het aan te roepen vanuit uw VPC-netwerk, met behulp van het serviceaccount met beperkte rechten.

# 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.")

Verwachte uitvoer:

Prediction successful:
[model output data]

Als u probeert dit eindpunt aan te roepen van buiten uw VPC (bijv. vanaf uw lokale machine zonder VPN/Cloud Interconnect naar uw VPC), of zonder de vertex-inference-sa-referenties te gebruiken, dan zou u een verbindingsfout of een 'toegang geweigerd'-bericht moeten verwachten, wat bevestigt dat uw beveiligingscontroles actief zijn.

1. Fout: VPC Service Controls-schending

Verzoek is verboden door het beleid van de organisatie.

**Oplossing:** Dit betekent doorgaans dat een verzoek (bijv. een poging om toegang te krijgen tot een bucket buiten de perimeter of vanaf een niet-conform IP) wordt geblokkeerd door VPC-SC. Controleer uw `google_access_context_manager_service_perimeter`-configuratie nogmaals. Zorg ervoor dat het IP-bereik of toegangsniveau van uw client correct is gedefinieerd binnen het toegangsbeleid als het verzoek legitiem is. Controleer ook of alle services waarop uw bewerking afhankelijk is (zoals Cloud Storage voor modelartefacten) zijn opgenomen in `restricted_services` en dat het project is vermeld in `resources` binnen de perimeter. Voor specifieke details over toegangsniveaus, raadpleeg de [Google Cloud Access Context Manager-documentatie](https://cloud.google.com/access-context-manager/docs/overview).

1. Fout: IAM-toestemming geweigerd

403 Toestemming geweigerd voor resource projects/PROJECT_NUMBER/locations/REGION/endpoints/ENDPOINT_ID

**Oplossing:** Het serviceaccount of de gebruiker die de aanvraag indient, beschikt niet over de noodzakelijke `aiplatform.user`-rol (of `aiplatform.endpointViewer` als u alleen endpointdetails probeert te bekijken) voor het Vertex AI-eindpunt of -project. Controleer de IAM-beleidsbindingen voor uw inferentie-serviceaccount met `gcloud iam service-accounts get-iam-policy INFERENCE_SA_EMAIL` en `gcloud projects get-iam-policy my-gcp-project-id`. Zorg ervoor dat de juiste rollen op het juiste bereik zijn toegekend.

1. Fout: Private Service Connect-connectiviteitsprobleem

Kan geen verbinding maken met het eindpunt. Controleer de netwerkconfiguratie.

**Oplossing:** Dit duidt op een probleem met het privé-netwerkpad. Controleer of uw `google_compute_network_attachment` correct is ingericht en de status `ACCEPTED` heeft. Controleer firewallregels in uw VPC om ervoor te zorgen dat verkeer van uw client naar het IP-bereik van het PSC-eindpunt is toegestaan. Controleer ook of de DNS-resolutie voor het Vertex AI-eindpunt wordt omgezet naar een intern IP-adres binnen uw VPC, niet naar een openbaar IP-adres. Als u `gcloud` gebruikt, zorg er dan voor dat uw client vanuit een VM binnen dezelfde VPC draait of is verbonden via VPN/Interconnect.