1. Isolamento della rete: Bypassare completamente Internet pubblico per il traffico di inferenza non è negoziabile per carichi di lavoro sensibili. Questo previene attacchi comuni basati sulla rete e l'intercettazione dei dati.
2. Sicurezza perimetrale (VPC-SC): Stabilire barriere di protezione contro l'esfiltrazione dei dati e l'accesso non autorizzato tra progetti. Questo agisce come un air gap logico.
3. Protezione dei dati: Garantire che i modelli e i dati siano crittografati a riposo e in transito utilizzando chiavi gestite dal cliente. Questo mi dà il controllo diretto sul mio materiale crittografico.
4. Accesso a privilegi minimi: Implementare ruoli IAM granulari, separando le preoccupazioni della distribuzione del modello dall'invocazione del modello. Ciò minimizza il raggio d'azione di qualsiasi credenziale compromessa.
5. Governance del modello: Implementare pratiche come la firma del modello (ad esempio, utilizzando Sigstore/Cosign), la scansione delle vulnerabilità delle dipendenze del modello e la registrazione di audit completa per tutti gli eventi del ciclo di vita del modello. Ciò crea fiducia e tracciabilità nella catena di fornitura dell'AI.
6. Conformità alla sovranità: Allinearsi ai quadri normativi sfruttando offerte cloud e partnership specifiche, garantendo che il controllo legale e operativo risieda in giurisdizioni conformi.

Ecco come questi componenti si integrano per un'implementazione Vertex AI altamente sicura:

Per quanto riguarda l'isolamento della rete, di solito scelgo Private Service Connect (PSC) rispetto al peering VPC per la connessione a servizi gestiti come Vertex AI. Mentre il peering VPC funziona, PSC offre una separazione più netta. Con PSC, i servizi Vertex AI si presentano come endpoint direttamente all'interno del mio VPC, consumando un indirizzo IP interno. Ciò elimina la necessità di routing transitivo o di gestione di reti con peering, semplificando la mia architettura di rete e riducendo la superficie di attacco. Si tratta di una connessione di rete dedicata e interna, che bypassa completamente Internet pubblico.

VPC Service Controls (VPC-SC) è la mia parete digitale di Fort Knox. Mi consente di definire perimetri di sicurezza attorno ai miei progetti GCP e ai servizi al loro interno, come Vertex AI e Cloud Storage. Qualsiasi tentativo di spostare dati o accedere a risorse dall'esterno di questo perimetro viene bloccato, indipendentemente dalle autorizzazioni IAM. Questa è una linea di difesa critica contro l'esfiltrazione dei dati, garantendo che anche se un attaccante compromette un account di servizio, non possa estrarre dati al di fuori del mio perimetro definito. Crea efficacemente un air gap basato su policy per i miei servizi sensibili.

Per i Dati a riposo e in transito, le chiavi di crittografia gestite dal cliente (CMEK) sono fondamentali. Sebbene Google crittografi i dati per impostazione predefinita, CMEK mi offre il controllo crittografico sulle chiavi che proteggono i miei modelli nel registro di modelli Vertex AI e i relativi artefatti in Cloud Storage. Questo è un requisito comune nei settori regolamentati. Per i dati in transito, gli endpoint privati di Vertex AI utilizzano intrinsecamente TLS (Transport Layer Security), garantendo che tutte le comunicazioni tra il mio VPC e il servizio Vertex AI siano crittografate e sicure.

Infine, l'Identity & Access Management (IAM) deve essere chirurgico. Sostengo sempre account di servizio separati per azioni distinte. L'identità che distribuisce un modello dovrebbe essere diversa dall'account di servizio che invoca l'endpoint per l'inferenza. Questo aderisce al principio del minimo privilegio, minimizzando il raggio d'azione di qualsiasi credenziale compromessa. Ad esempio, un account di servizio model-deployer potrebbe avere aiplatform.admin sui modelli, mentre un account di servizio inference-invoker avrebbe solo aiplatform.user su endpoint specifici.

In Europa, la discussione sulla sovranità dei dati e sulla fiducia digitale si sta intensificando. Il concetto di "cloud de confiance" (cloud di fiducia) sta prendendo piede, in particolare in Francia con la sua certificazione SecNumCloud. Ma per capire veramente cosa significhino questi requisiti per i carichi di lavoro AI su GCP, vale la pena andare oltre i nomi e esaminare i meccanismi per cui i controlli di sicurezza cloud standard — anche quelli rafforzati come quelli trattati in questa guida — non sono sufficienti per le organizzazioni che operano sotto mandati del settore pubblico francese o rigorosi requisiti di sovranità dell'UE.

Il problema principale: la legge extraterritoriale

Prima di parlare di S3NS, dobbiamo capire perché esiste. Il US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) significa che un'azienda statunitense – inclusa Google – può essere costretta a consegnare dati che controlla, anche se tali dati sono fisicamente archiviati in Europa. I controlli di sicurezza cloud standard (VPC Service Controls, CMEK, Private Service Connect) ti proteggono da minacce esterne e configurazioni errate, ma non cambiano la realtà giurisdizionale fondamentale: Google è un'entità statunitense, e il suo personale operativo può teoricamente essere costretto ad agire secondo la legge statunitense. Questo è ciò che SecNumCloud e S3NS affrontano direttamente.

Cos'è SecNumCloud?

SecNumCloud è un quadro di qualificazione pubblicato dall'ANSSI (Agence nationale de la sécurité des systèmes d'information), l'agenzia nazionale francese per la cybersicurezza. La versione 3,2 – la versione attuale e operativamente significativa – comprende 276 requisiti in 15 domini di sicurezza: sicurezza operativa, crittografia, controllo degli accessi, sicurezza della rete, continuità aziendale, gestione degli incidenti e, in modo critico, protezione contro le leggi extraterritoriali. Quest'ultimo dominio è ciò che distingue SecNumCloud da altre certificazioni di sicurezza europee come ISO 27001 o BSI C5. Non è puramente uno standard di cybersicurezza; è contemporaneamente un quadro di controllo giurisdizionale. Un fornitore può ricevere la qualificazione SecNumCloud solo se può dimostrare che i governi stranieri non hanno alcun meccanismo legale o tecnico per costringere l'accesso ai dati dei clienti.

S3NS: Struttura e design aziendale

S3NS (pronunciato sens, francese per "senso") è una joint venture strutturata per essere legalmente immune alle pressioni extraterritoriali statunitensi fin dalla sua nascita. Fatti chiave:

• Partecipazione di maggioranza: Thales detiene la quota di maggioranza; Google Cloud detiene circa il 20%.
• Giurisdizione legale: S3NS è una société par actions simplifiée (SAS) francese, legalmente obbligata esclusivamente ai sensi del diritto europeo.
• Conseguenza: Qualsiasi richiesta di dati del governo statunitense indirizzata a S3NS può essere – e sarebbe – rifiutata; non esiste alcun meccanismo legale attraverso il quale Google possa costringere unilateralmente S3NS ad agire.

La struttura aziendale è un'ingegneria di sovranità intenzionale: Google porta la tecnologia, Thales e S3NS portano il rivestimento legale europeo e il controllo operativo.

Due livelli: CRYPT3NS vs. PREMI3NS

S3NS offre due livelli di servizio distinti, e confonderli è un errore comune:

Per la maggior parte delle organizzazioni private dell'UE, CRYPT3NS fornisce una protezione significativa tramite controlli sulla residenza dei dati e giurisdizione legale. Per le organizzazioni soggette a rigide norme sugli appalti pubblici francesi, alle catene di fornitura della difesa o ai settori che richiedono esplicitamente la qualificazione SecNumCloud, solo PREMI3NS soddisfa i requisiti.

Come PREMI3NS ottiene l'isolamento tecnico

Questa è la domanda centrale: come possono i servizi GCP funzionare in un data center sul quale Google non ha alcun controllo?

La risposta è Google Cloud Dedicated – un'architettura in cui Google licenzia la sua pila tecnologica (software di calcolo, archiviazione, rete) a S3NS, che la distribuisce e la gestisce interamente sulla propria infrastruttura fisica. Diversi meccanismi di controllo deliberati lo rendono possibile:

1. Infrastruttura fisicamente isolata: PREMI3NS funziona sul proprio hardware di calcolo, archiviazione e rete in data center francesi. Questi sistemi sono completamente separati dal cloud pubblico globale di Google – non esiste un tessuto condiviso e nessun piano di controllo comune accessibile ai dipendenti di Google.

2. Nessun accesso a Google: Il personale di Google non ha accesso fisico o logico all'ambiente PREMI3NS. Le operazioni, l'amministrazione e il supporto sono eseguiti esclusivamente da dipendenti S3NS situati all'interno dell'UE. Le escalation che normalmente raggiungerebbero l'ingegneria di Google sono gestite internamente da S3NS.

3. Modello di quarantena degli aggiornamenti: Quando Google rilascia un aggiornamento software – patch del kernel, aggiornamenti di servizio, nuove funzionalità – S3NS lo intercetta in un ambiente di quarantena. Gli ingegneri S3NS eseguono analisi di reverse-engineering e sicurezza automatizzate sui binari prima di decidere se distribuirli in produzione. S3NS non esegue passivamente il codice di Google; è un guardiano attivo di ogni modifica software che raggiunge la sua infrastruttura.

4. Controllo crittografico sovrano: S3NS gestisce le radici crittografiche di fiducia per l'ambiente PREMI3NS. A differenza di CMEK su GCP standard, dove si gestiscono le chiavi ma Google gestisce ancora l'infrastruttura, su PREMI3NS l'intera gerarchia di gestione delle chiavi è sotto il controllo di S3NS e del cliente, non di Google.

5. Modello SOC doppio: S3NS gestisce il proprio Security Operations Centre in coordinamento con il SOC P10 certificato ANSSI di Thales, fornendo un doppio monitoraggio per comportamenti anomali, inclusi eventuali tentativi di introdurre un percorso di accesso accessibile a Google.

Catalogo servizi attuale e la roadmap di Vertex AI

A partire dalla qualificazione di dicembre 2025, PREMI3NS copre l'infrastruttura di base per la maggior parte dei carichi di lavoro regolamentati: Compute Engine, Cloud GPU (NVIDIA H100s), Cloud Storage, networking (DNS, VPN, Load Balancing, Cloud Armor, Interconnect), BigQuery Enterprise, Pub/Sub, GKE Autopilot, Cloud SQL Enterprise Plus e strumenti operativi (Monitoring, Logging). Una seconda ondata – Cloud Run, Cloud Build, Cloud Spanner, Cloud Bigtable, Secret Manager, Confidential VMs e Admin Access Transparency – è in attesa di qualificazione per il primo semestre 2026.

Per Vertex AI in particolare, le fondamenta principali (Model Garden per modelli a peso aperto, Model Registry, Workbench e inferenza online) sono nella roadmap per il secondo semestre 2026. Gemini non sarà incluso nel Model Garden iniziale – inizialmente sono inclusi solo modelli open-source e a peso aperto, il che è una considerazione materiale per la progettazione dell'inferenza AI sovrana oggi. Se hai bisogno di inferenza qualificata SecNumCloud in questo momento, il percorso pratico è la distribuzione dei tuoi modelli su GKE Autopilot con GPU H100 su PREMI3NS. Vertex AI gestito su PREMI3NS è imminente, non ancora consegnato.

Quando utilizzare S3NS vs. l'indurimento standard di GCP

I controlli trattati nel resto di questa guida (PSC, VPC-SC, CMEK) sono altamente efficaci per la stragrande maggioranza dei carichi di lavoro UE regolamentati. La seguente euristica aiuta a decidere quale livello è appropriato:

• GCP standard rafforzato (questa guida): sufficiente per GDPR, NIS2, ISO 27001, framework bancari/assicurativi e qualsiasi organizzazione in cui l'isolamento operativo dalla legge statunitense non è un requisito esplicito di approvvigionamento.
• CRYPT3NS: appropriato quando sono necessarie la giurisdizione legale francese e garanzie di residenza dei dati, ma non è richiesta l'isolamento completo dell'infrastruttura.
• PREMI3NS: obbligatorio quando è richiesta la qualificazione SecNumCloud — OIV francesi (Operatori di Importanza Vitale), catena di approvvigionamento della difesa, dati governativi sensibili o qualsiasi specifica di approvvigionamento che faccia esplicito riferimento a SecNumCloud.

L'assegnazione del contratto cloud sovrano dell'UE da 180 milioni di euro che coinvolge S3NS, e l'adozione da parte di Thales di SAP RISE su PREMI3NS, segnalano che questo modello è passato dalla fase pilota alla produzione su larga scala.

Innanzitutto, stabilisco una connessione privata a Vertex AI. Ciò comporta la creazione di un endpoint Private Service Connect nella mia VPC che si connette alla rete del produttore di servizi Vertex AI. Si noti che Vertex AI provvede internamente al proprio allegato di servizio; devo solo configurare il lato consumer nel mio progetto.

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

Questa configurazione Terraform imposta il lato consumer di PSC. La chiave è identificare correttamente i service_attachment_names per Vertex AI Prediction nella regione scelta. Una volta distribuito, qualsiasi traffico dalla tua vertex-ai-inference-vpc a questo endpoint verrà instradato privatamente a Vertex AI. Sebbene l'output psc_endpoint_link fornisca il link alla risorsa, per i servizi gestiti come Vertex AI, si interagisce tipicamente tramite nomi DNS che si risolvono nell'IP privato dietro le quinte. Consulta la documentazione ufficiale di Private Service Connect per i nomi di allegati di servizio più aggiornati.

Successivamente, definisco un perimetro di sicurezza attorno ai miei progetti e ai servizi critici. Questo esempio presuppone che tu abbia un'organizzazione definita in GCP, che è un prerequisito per 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."
}

Questo blocco Terraform crea un perimetro VPC-SC. Ho incluso aiplatform.googleapis.com e storage.googleapis.com in restricted_services perché i miei modelli e dataset risiedono spesso in Cloud Storage. Il campo resources specifica quali progetti sono protetti da questo perimetro. Ricorda che le policy VPC-SC vengono valutate dopo IAM, quindi anche se un'identità ha autorizzazioni storage.admin, se si trova al di fuori del perimetro o viola un livello di accesso, la sua richiesta verrà negata. Questo fornisce un robusto livello di prevenzione dell'esfiltrazione dei dati.

Nota: La configurazione di access_levels e access_policies richiede un'attenta pianificazione a livello di organizzazione. Per una guida dettagliata, fare riferimento alla documentazione di VPC Service Controls.

Prendere il controllo delle proprie chiavi di crittografia è un passo vitale per la conformità normativa. Creerò un anello di chiavi Cloud KMS e una chiave, quindi concederò le autorizzazioni necessarie a Vertex AI per utilizzarla.

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

Output atteso (esempio per la creazione della chiave):

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

Ora, quando carico o registro un modello con Vertex AI, specifico questa KMS_KEY_RESOURCE per garantire che i miei artefatti del modello siano crittografati con la mia CMEK. Questo viene tipicamente fatto durante l'operazione Model.upload() nell'SDK di Vertex AI o tramite l'API REST:

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

Ciò garantisce che il tuo modello, quando archiviato nel registro e nei bucket Cloud Storage associati, sia protetto dalle tue chiavi crittografiche, soddisfacendo un requisito critico di sovranità.

L'implementazione del principio del minimo privilegio è cruciale. Separo le autorizzazioni per la distribuzione del modello da quelle per l'invocazione del modello. Ecco come creo un account di servizio dedicato all'inferenza e gli concedo solo le autorizzazioni necessarie.

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

Output atteso (esempio):

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

Quando la tua applicazione client o altri servizi devono chiamare l'endpoint Vertex AI, dovrebbero impersonare questo account di servizio vertex-inference-sa o utilizzare le sue credenziali. Questo minimizza il rischio: se questo account di servizio viene compromesso, può solo invocare previsioni e non può, ad esempio, eliminare modelli o modificare la tua configurazione Vertex AI.

Infine, distribuisco il modello crittografato con CMEK a un endpoint che sfrutta la nostra configurazione di rete privata. Definirò una risorsa endpoint e distribuirò il modello che abbiamo caricato in precedenza.

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

Questa distribuzione garantisce che il tuo modello sia ospitato su un endpoint accessibile solo tramite il tuo link Private Service Connect configurato, operando all'interno del perimetro di VPC Service Controls e utilizzando le tue chiavi di crittografia gestite dal cliente.

Repository di esempio completo: Puoi trovare altri esempi ufficiali di pattern di Vertex AI sicuri su github.com/GoogleCloudPlatform/vertex-ai-samples/tree/main/community-content/vertex_security_examples.

Esempi di codice aggiuntivi: Per modelli di deployment avanzati e integrazione CI/CD per Vertex AI, un repository con le mie implementazioni più complesse si trova tipicamente nel mio flusso di lavoro privato.

Per verificare che il tuo endpoint sia privato e protetto, dovresti provare a invocarlo dall'interno della tua rete VPC, utilizzando l'account di servizio con autorizzazioni limitate.

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

Output atteso:

Prediction successful:
[model output data]

Se si tenta di chiamare questo endpoint dall'esterno della propria VPC (ad esempio, dalla propria macchina locale senza VPN/Cloud Interconnect alla propria VPC), o senza utilizzare le credenziali vertex-inference-sa, ci si dovrebbe aspettare un errore di connessione o un messaggio di autorizzazione negata, il che conferma che i controlli di sicurezza sono attivi.

1. Errore: Violazione dei controlli di servizio VPC

La richiesta è proibita dalla politica dell'organizzazione.

**Soluzione:** Ciò significa in genere che una richiesta (ad esempio, il tentativo di accedere a un bucket al di fuori del perimetro o da un IP non conforme) viene bloccata da VPC-SC. Ricontrolla la tua configurazione `google_access_context_manager_service_perimeter`. Assicurati che l'intervallo IP o il livello di accesso del tuo client siano correttamente definiti all'interno della policy di accesso se la richiesta è legittima. Verifica anche che tutti i servizi su cui la tua operazione si basa (come Cloud Storage per gli artefatti del modello) siano inclusi in `restricted_services` e che il progetto sia elencato in `resources` all'interno del perimetro. Per dettagli specifici sui livelli di accesso, fai riferimento alla [documentazione di Google Cloud Access Context Manager](https://cloud.google.com/access-context-manager/docs/overview).

1. Errore: Autorizzazione IAM negata

403 Autorizzazione negata sulla risorsa projects/PROJECT_NUMBER/locations/REGION/endpoints/ENDPOINT_ID

**Soluzione:** L'account di servizio o l'utente che effettua la richiesta non dispone del ruolo `aiplatform.user` necessario (o `aiplatform.endpointViewer` se si sta solo tentando di visualizzare i dettagli dell'endpoint) sull'endpoint o sul progetto Vertex AI. Verifica le associazioni delle policy IAM per il tuo account di servizio di inferenza utilizzando `gcloud iam service-accounts get-iam-policy INFERENCE_SA_EMAIL` e `gcloud projects get-iam-policy my-gcp-project-id`. Assicurati che i ruoli corretti siano concessi all'ambito appropriato.

1. Errore: Problema di connettività Private Service Connect

Impossibile connettersi all'endpoint. Controllare la configurazione della rete.

**Soluzione:** Questo implica un problema con il percorso di rete privata. Verifica che il tuo `google_compute_network_attachment` sia stato correttamente provisionato e che il suo stato sia `ACCEPTED`. Controlla le regole del firewall nella tua VPC per assicurarti che il traffico dal tuo client all'intervallo IP dell'endpoint PSC sia consentito. Inoltre, conferma che la risoluzione DNS per l'endpoint Vertex AI si risolva in un IP interno all'interno della tua VPC, non in uno pubblico. Se utilizzi `gcloud`, assicurati che il tuo client sia in esecuzione da una VM all'interno della stessa VPC o sia connesso tramite VPN/Interconnect.