Questo documento fornisce best practice per i team della piattaforma, gli ingegneri della sicurezza e gli architetti cloud che eseguono il deployment di carichi di lavoro AI su Google Kubernetes Engine (GKE). Puoi utilizzare GKE per proteggere la proprietà intellettuale proprietaria, ad esempio i pesi dei modelli, salvaguardare la reputazione del brand filtrando i contenuti e migliorare la conformità normativa.
Implementa queste best practice in aggiunta ad altre best practice per la sicurezza dei workload GKE e AI, ad esempio:
- Best practice per la sicurezza dell'AI generativa
- Best practice per rafforzare la sicurezza del cluster
Comprendere le responsabilità in materia di sicurezza
La security posture dei tuoi workload AI dipende da vari livelli del tuo ambiente, ad esempio l' Cloud de Confiance by S3NS infrastruttura e i modelli che utilizzi. La tabella seguente descrive questi livelli, chi è responsabile della protezione di ciascun livello e le responsabilità di sicurezza per quel livello:
| incorporato | Descrizione | Responsabilità |
|---|---|---|
| Infrastruttura | L'infrastruttura sottostante, come macchine virtuali (VM), componenti di rete e hardware di archiviazione su cui vengono eseguiti i tuoi carichi di lavoro di AI. Cloud de Confiance Possiede l'infrastruttura e fornisce una solida base di sicurezza. | Gli amministratori della piattaforma della tua organizzazione implementano controlli per migliorare la sicurezza nei seguenti ambiti:
|
| Modello | Il modello, i pesi del modello, la pipeline di addestramento e le proprietà di sicurezza. Se esegui modelli che hai addestrato o ottimizzato, allora sei responsabile della protezione del livello del modello. Se esegui modelli gestiti di fornitori di terze parti (come Gemini), il fornitore è responsabile della sicurezza del modello. | A livello di modello, il proprietario del modello è responsabile della sicurezza nelle seguenti aree:
|
| Applicazione | I prompt, il codice, le istruzioni di sistema e l'esperienza utente finale. Gli operatori delle applicazioni e gli amministratori della piattaforma della tua organizzazione sono responsabili della sicurezza a livello di applicazione. | A livello di applicazione, gli operatori di applicazioni, gli sviluppatori e gli amministratori della piattaforma sono responsabili della sicurezza nelle seguenti aree:
|
Applichi i controlli per proteggere i livelli di cui sei responsabile. Gli esempi seguenti mostrano i tipi di deployment comuni per i clienti GKE e le responsabilità di sicurezza corrispondenti per questi deployment:
- Esegui un modello gestito, come Gemini: applichi i controlli a livello di infrastruttura e applicazione. Anche quando utilizzi un modello gestito con filtri di sicurezza integrati, possiedi comunque le difese di prompt injection necessarie per proteggere la logica specifica della tua applicazione.
- Esegui il tuo modello: se esegui un modello perfezionato, un modello open source o un modello che hai addestrato, sei responsabile della sicurezza a ogni livello.
- Sei un fornitore di servizi di AI multi-tenant: se fornisci servizi di AI ai tuoi utenti finali eseguendo il tuo modello su GKE ed esponendo endpoint di inferenza a più tenant, sei responsabile di controlli aggiuntivi. Questi controlli multi-tenant includono l'isolamento logico e fisico dei tenant (ad esempio node pool, spazi dei nomi e criteri di rete dedicati), la limitazione di frequenza per tenant e la crittografia dei dati dei tenant at-rest utilizzando chiavi di crittografia gestite dal cliente (CMEK) distinte.
Migliorare la sicurezza a livello di infrastruttura
A livello di infrastruttura, Cloud de Confiance e GKE forniscono una security posture di base che implementa vari controlli di sicurezza per impostazione predefinita. Per migliorare la sicurezza della tua infrastruttura per i workload AI, configura controlli di sicurezza aggiuntivi in base al tipo di workload AI che esegui e agli obiettivi di sicurezza specifici che vuoi raggiungere. Le sezioni seguenti descrivono i prodotti e i servizi che puoi utilizzare per proteggere vari componenti della tua infrastruttura AI.
Proteggere i nodi GKE
Utilizza i seguenti servizi per proteggere i dati sensibili, ad esempio i workload di inferenza che elaborano prompt e risposte o i workload di addestramento che accedono a modelli proprietari:
Cripta i dati sensibili in uso con l'attestazione hardware: esegui i tuoi carichi di lavoro di inferenza su Nodi Confidential Google Kubernetes Engine, estendendo la crittografia della memoria a livello hardware agli acceleratori, tra cui GPU e TPU, oltre alle CPU AMD SEV-SNP o Intel TDX. Utilizza i nodi GKE confidenziali per deployment regolamentati e workload di inferenza sensibili. I Confidential GKE Nodes non proteggono i workload da exploit a livello di applicazione o da utenti autorizzati che hanno accesso a livello di nodo.
Per i provider i cui clienti hanno requisiti di isolamento rigorosi (come i carichi di lavoro sovrani), GKE Hypercluster fornisce l'attestazione crittografica che nemmeno l'operatore dell'infrastruttura sottostante,Cloud de Confiance, può ispezionare i dati dei tenant.
Riduzione del rischio di rappresentazione non autorizzata dei nodi: esegui i workload su nodi GKE schermati, che forniscono attestazioni verificabili dell'integrità e dell'identità dei nodi. Utilizza i nodi GKE schermati per tutti i tipi di workload.
Elimina l'utilizzo di credenziali statiche per i workload: utilizza la federazione delle identità per i workload per GKE per accedere ai servizi Cloud de Confiance dal codice dell'applicazione utilizzando credenziali federate di breve durata ed evita che i metadati non essenziali di Compute Engine vengano esposti alle applicazioni. Utilizza Workload Identity Federation for GKE in tutti i cluster di produzione, soprattutto quando devi accedere a dati che si trovano in servizi esterni al cluster.
Implementare i controlli di rete
Puoi utilizzare le seguenti funzionalità e prodotti per migliorare la sicurezza di rete per i carichi di lavoro AI:
Utilizza intervalli di indirizzi IP alias: i cluster VPC nativi utilizzano intervalli di indirizzi IP alias per instradare il traffico tra i pod anziché utilizzare route statiche nella rete VPC. Utilizza sempre cluster nativi di VPC.
Limita l'accesso alla rete ai nodi: utilizza i nodi privati per impedire il traffico tra i nodi e la rete internet pubblica per impostazione predefinita. Gli endpoint di inferenza che devono essere esposti devono avere un servizio gestito come Google Cloud Armor tra gli endpoint e internet.
Nega il traffico in-cluster per impostazione predefinita: utilizza Kubernetes NetworkPolicies per negare il traffico tra i pod, tra gli spazi dei nomi e il traffico in uscita verso internet. Consenti il traffico di rete solo per le applicazioni che richiedono un accesso specifico.
Aggiungi protezione perimetrale agli endpoint internet: puoi utilizzare Google Cloud Armor per proteggere gli endpoint di inferenza esposti a internet implementando la limitazione di frequenza, la protezione DDoS, il controllo dell'accesso basato sulla posizione geografica e la mitigazione degli attacchi di livello 7. Se hai API AI rivolte al pubblico, utilizza Cloud Armor per gestire gli attacchi volumetrici e a livello di applicazione prima che raggiungano la tua infrastruttura di calcolo. Combina Cloud Armor con nodi privati per ottimizzare la sicurezza degli endpoint di inferenza.
Impedisci l'esfiltrazione di dati durante un attacco: utilizza i Controlli di servizio VPC per creare un perimetro di sicurezza intorno alle tue risorse Cloud de Confiance . Anche se le credenziali vengono compromesse, gli aggressori non possono estrarre i dati dal perimetro. Utilizza i Controlli di servizio VPC per i carichi di lavoro regolamentati.
Gestisci l'identità e l'accesso
Per identificare gli utenti e controllare l'accesso a cluster e workload, utilizza i seguenti meccanismi di autorizzazione:
Controlla l'accesso alle Cloud de Confiance risorse: utilizza le policy di accesso Cloud de Confiance Identity and Access Management (IAM) per controllare quali entità possono interagire con i cluster e i nodi GKE.
Controlla l'accesso alle risorse Kubernetes nei cluster: utilizza i criteri di controllo dell'controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per controllare cosa possono fare i vari principali alle risorse API Kubernetes all'interno di ogni cluster.
Configura l'accesso zero-trust agli endpoint di inferenza e alle interfacce di amministrazione: utilizza un servizio come Chrome Enterprise Premium per configurare l'accesso degli utenti in base all'identità e al livello di sicurezza del dispositivo anziché alla topologia di rete.
Gestire chiavi e secret
Conserva tutte le chiavi di crittografia e i dati sensibili, come chiavi API e credenziali, al di fuori del cluster. I seguenti prodotti possono aiutarti a memorizzare queste risorse:
Gestisci le chiavi di crittografia: utilizza Cloud Key Management Service per gestire tutte le chiavi di crittografia. Puoi anche creare chiavi di crittografia gestite dal cliente (CMEK) in Cloud KMS per criptare i dati con chiavi che controlli, il che è spesso un requisito nei settori regolamentati.
Archivia dati sensibili delle applicazioni: utilizza Secret Manager per archiviare dati sensibili utilizzati dai carichi di lavoro, come i secret delle applicazioni, le chiavi API e le credenziali. Per leggere questi dati dai pod, utilizza Workload Identity Federation for GKE per concedere a identità di workload specifiche l'accesso solo alle risorse necessarie ai pod.
Migliorare la sicurezza della catena di fornitura
I seguenti servizi Cloud de Confiance possono aiutarti a migliorare la sicurezza in tutta la catena di fornitura del software:
- Esegui la scansione per rilevare vulnerabilità nelle immagini container: archivia le immagini container nei repository Artifact Registry in cui l'analisi delle vulnerabilità è abilitata per impostazione predefinita. Attiva il rilevamento continuo delle CVE su ogni immagine nel tuo registro.
Consenti solo alle immagini verificate di raggiungere la produzione: utilizza Autorizzazione binaria per applicare l'autorizzazione basata su policy delle firme delle immagini container al momento del deployment. Solo le immagini attestate raggiungono la produzione.
Configura la gestione della postura e il rilevamento della sicurezza: utilizza Security Command Center per visualizzare i risultati della gestione della postura e del rilevamento delle minacce specifiche per l'AI, ad esempio endpoint della piattaforma Gemini Enterprise Agent configurati in modo errato o bucket di dati di addestramento esposti. Security Command Center integra questi risultati dell'AI con le vulnerabilità di Artifact Registry e l'analisi IAM per una visione completa della tua flotta.
Monitora gli artefatti AI: utilizza strumenti di distinta materiali creati per i carichi di lavoro AI di Kubernetes, come
k8s-aibom, per generare inventari completi di modelli, set di dati e framework.
Migliorare la sicurezza a livello di modello
Se esegui modelli che hai addestrato o ottimizzato o modelli open source che hai configurato, devi configurare vari controlli per migliorare la sicurezza del modello. Se esegui modelli gestiti di fornitori di terze parti, questo livello non si applica al tuo caso. Le sezioni seguenti descrivono cosa puoi fare per migliorare l'integrità, la riservatezza e la sicurezza dei tuoi modelli.
Migliorare l'integrità del modello
Migliora l'integrità dei tuoi modelli in modo da poter trovare prove di manomissione prima che il modello sia accessibile in un endpoint di inferenza. Le seguenti linee guida possono aiutarti a migliorare l'integrità del modello:
- Firma gli artefatti del modello: firma crittograficamente i pesi del modello prima di pubblicarli nel registro. Quando esegui il deployment del modello, verifica la firma utilizzando le attestazioni di Autorizzazione binaria. La firma e la verifica degli artefatti del modello ti aiutano a identificare se i modelli sono stati manomessi durante l'archiviazione o il transito e ti forniscono una catena di custodia verificabile per i modelli di produzione.
- Trova modifiche post-addestramento: lo scanner del modello di attivazione (AMS) open source rileva i modelli che sono stati modificati dopo l'addestramento (ad esempio, per aggiungere backdoor, perturbazioni del peso o perfezionamenti non autorizzati) analizzando le firme di attivazione del modello rispetto a una baseline. Esegui uno scanner come AMS come parte della pipeline CI/CD prima di pubblicare i modelli nei registri di produzione. Per i modelli di alto valore o regolamentati, pianifica scansioni AMS periodiche sugli artefatti di produzione per rilevare manomissioni che si verificano dopo la pubblicazione iniziale.
Proteggere la riservatezza del modello
Se hai pesi del modello sensibili, ad esempio perfezionamenti proprietari, modelli addestrati su dati regolamentati o proprietà intellettuale competitiva, utilizza le seguenti linee guida per proteggere i pesi:
Cripta i pesi inattivi: archivia i pesi in un archivio di oggetti criptato, ad esempio nei bucket Cloud Storage, con accesso IAM limitato. Per impostazione predefinita, Cloud Storage cripta i contenuti inattivi dei clienti. Se vuoi, puoi utilizzare le chiavi CMEK per criptare i dati con chiavi che controlli, il che è spesso un requisito nei settori regolamentati. Per saperne di più, consulta la sezione Opzioni di crittografia dei dati nella documentazione di Cloud Storage.
Proteggi i pesi in uso: esegui i modelli su Confidential GKE Nodes per assicurarti che i pesi siano criptati in memoria durante l'inferenza. I nodi GKE confidenziali possono aiutarti a proteggere la tua proprietà intellettuale da compromissioni a livello di hypervisor e accessi non autorizzati da parte dell'operatore dell'infrastruttura. Confidential GKE Nodes non protegge da exploit a livello di applicazione o da utenti autorizzati con accesso a livello di nodo.
Controlla tutto l'accesso ai pesi: registra tutto l'accesso agli artefatti del modello in storage. Utilizza le policy di accesso IAM per limitare l'accesso a service account e utenti specifici che hanno un'esigenza di accesso documentata. Limita rigorosamente l'accesso amministrativo al cluster, incluso l'accesso alla shell ai container, l'accesso SSH alle VM dei nodi o il debug a livello di nodo, utilizzando i criteri RBAC di Kubernetes e Chrome Enterprise Premium. Queste misure possono aiutarti a proteggere i pesi del modello dagli utenti che hanno accesso a livello di nodo, che non è coperto da Confidential GKE Nodes.
Migliorare le proprietà di sicurezza del modello
Puoi implementare varie impostazioni di sicurezza per i modelli durante l'addestramento. Se stai addestrando o ottimizzando il tuo modello, investi in un addestramento sulla sicurezza pertinente al caso d'uso del modello. Le proprietà di sicurezza dei modelli includono il comportamento di rifiuto, l'addestramento all'allineamento e la resistenza ai jailbreak. Se utilizzi un modello preaddestrato, scegli un modello con proprietà di sicurezza che corrispondano ai requisiti della tua applicazione.
Gli sviluppatori e gli operatori di applicazioni possono implementare vari controlli a livello di applicazione per migliorare la sicurezza in aree che il modello non può coprire.
Migliorare la sicurezza a livello di applicazione
Il livello applicativo è quello in cui operatori e sviluppatori hanno il massimo controllo sulle configurazioni di sicurezza specifiche per l'AI. A livello di applicazione, puoi implementare controlli di sicurezza che proteggono i dati, creare richieste ben formate e proteggere prompt e risposte. Questi controlli sono in genere utili per i carichi di lavoro di inferenza, che gestiscono prompt, sessioni e risposte degli utenti. Le sezioni seguenti descrivono vari controlli, prodotti e servizi che potrebbero aiutarti a raggiungere obiettivi di sicurezza specifici a livello di applicazione.
Difenditi dalle minacce a livello di contenuti
Esamina tutti i prompt e le risposte per rilevare problemi di sicurezza come prompt injection, esposizione di dati sensibili e contenuti dannosi. Poiché i nodi GKE sono progettati per non avere accesso ai contenuti, esegui il deployment di Model Armor tra l'applicazione e l'endpoint di inferenza. Model Armor ha principi di gestione e archiviazione dei dati specifici progettati per migliorare la privacy dei tuoi dati durante la scansione.
Proteggere i prompt di sistema
Filtra gli output per la perdita di prompt e configura il rilevamento dell'esfiltrazione di dati di Model Armor per rilevare i pattern di estrazione. Per istruzioni altamente sensibili, elaborale in una chiamata che non restituisce testo all'utente.
Gestire sessioni e routing
Quando esponi gli endpoint di inferenza agli utenti finali, utilizza GKE Inference Gateway. Inference Gateway estende l'API Gateway per instradare il traffico in base a metriche e dati specifici per i carichi di lavoro di inferenza AI. Puoi scalare automaticamente i carichi di lavoro per soddisfare la domanda e integrarli con Model Armor e Apigee per il filtro dei contenuti, l'osservabilità a livello di sessione e l'applicazione delle quote.
Migliorare la sicurezza degli agenti AI
Se il tuo workload AI è un agente, hai bisogno di controlli aggiuntivi a livello di applicazione come i seguenti:
- Limita l'accesso alle API Cloud de Confiance : utilizza Workload Identity Federation per GKE con criteri di accesso IAM per limitare le API a cui possono accedere i pod del workload dell'agente. Utilizza un service account Kubernetes dedicato per ogni agente e concedi a questa entità solo le autorizzazioni IAM necessarie per il workload.
- Esegui l'esecuzione di codice o strumenti non attendibili in sandbox: esegui agenti che eseguono codice generato o interagiscono con strumenti di terze parti non verificati in ambienti sandbox utilizzando la sandbox agente. Agent Sandbox utilizza un meccanismo di isolamento come GKE Sandbox o Kata Containers per proteggere dagli escape dei container.
Configurare l'osservabilità e la risposta agli incidenti
Raccogli i log e monitora varie metriche per identificare in anticipo potenziali attacchi e limitare l'impatto degli exploit. Le sezioni seguenti forniscono linee guida che potrebbero aiutarti a migliorare il rilevamento e la risposta.
Raccogliere log e metriche
Per identificare le minacce il più rapidamente possibile, implementa il maggior numero possibile delle seguenti best practice di osservabilità:
- Raccogli i log GKE.
- Abilita gli audit log di accesso ai dati per le operazioni sensibili, come l'utilizzo delle chiavi KMS.
- Non registrare i contenuti dei prompt o dei completamenti, a meno che le tue norme non lo consentano esplicitamente. Se raccogli dati di prompt e risposta multimodali (anteprima), elimina o limita l'accesso ai dati archiviati in base alle tue norme di sicurezza.
- Raccogli le metriche importanti per i tuoi SRE.
- Configura il monitoraggio automatico delle applicazioni per tipi specifici di server di modelli di AI.
- Aggrega i log in Cloud Logging o nella tua piattaforma SIEM (Security Information and Event Management).
- Utilizza le metriche basate su log per creare metriche basate sui contenuti dei log.
Rilevare minacce specifiche per l'AI
Configura gli avvisi in Logging e Cloud Monitoring per rilevare varie minacce specifiche per l'AI. I criteri di avviso specifici che configuri dipendono dai tipi di log che raccogli e dai requisiti della tua organizzazione. Per saperne di più sulle policy di avviso disponibili, consulta Confronto tra le opzioni di avviso. Configura avvisi per minacce specifiche dell'AI come le seguenti:
| Minacce e indicatori specifici per l'AI | |
|---|---|
| Prompt injection | Log di Model Armor per la sanitizzazione o il rifiuto dei prompt |
| Estrazione del prompt di sistema | Anomalie di Model Armor e successo della cache |
| Esposizione di dati sensibili | Log delle risposte di Model Armor |
| Abuso dei costi di inferenza | Utilizzo dei token a livello di sessione dalle metriche di Inference Gateway |
| Manipolazione della sessione | Velocità delle nuove sessioni per tenant dalle metriche del gateway di inferenza |
| Fingerprinting del modello | Pattern di probing delle funzionalità |
| Canale laterale di temporizzazione | Mitigazione architetturale (partizionamento della cache) |
Stabilire un processo di risposta agli incidenti
Il modo in cui rispondi ai vari incidenti dipende dalla struttura organizzativa e dai requisiti di sicurezza. Le seguenti linee guida descrivono cosa fare quando rilevi tipi specifici di minacce ai tuoi carichi di lavoro AI:
Rilevamenti di contenuti in Model Armor: blocca la richiesta, documenta l'evento e configura un avviso per informarti se la frequenza supera una soglia. Configurare la limitazione della frequenza per gli utenti che hanno commesso violazioni ripetute.
Rilevamenti di inferenza: limita i tenant utilizzando Inference Gateway. Termina le sessioni per abusi confermati.
Correlazione cross-layer:un rilevamento di Model Armor più un pattern di abuso di token indica un abuso coordinato. Definisci le regole di correlazione e identifica una soglia di affidabilità dopo la quale il rischio di un avviso di falso positivo è basso. Automatizzare la chiusura delle sessioni che superano questa soglia.
Implementare la sicurezza durante il ciclo di vita del deployment
Ottimizza i tuoi deployment di AI per la sicurezza durante tutto il ciclo di vita del deployment. Durante fasi specifiche del ciclo di vita, implementa controlli che proteggono uno o più livelli. Le sezioni seguenti forniscono linee guida per ogni fase del ciclo di vita.
Esegui il deployment dell'infrastruttura
Quando crei o progetti l'infrastruttura che esegue i carichi di lavoro AI, implementa il maggior numero possibile dei seguenti controlli:
| Categoria | |
|---|---|
| Nodi GKE |
|
| Networking |
|
| Gestione di identità e accessi |
|
| Gestione dei dati sensibili |
|
| Osservabilità |
|
Gestire i workload e l'infrastruttura
Quando esegui il deployment dei tuoi workload AI ed esegui un sistema di produzione, implementa il maggior numero possibile dei seguenti controlli:
| Categoria | |
|---|---|
| Sicurezza dei workload |
|
| Networking |
|
| Protezione dei dati sensibili | Utilizza CMEK per criptare i dati con le tue chiavi in ambienti regolamentati. |
| Osservabilità |
|
Governare i deployment su larga scala
Man mano che la tua organizzazione cresce, implementa i seguenti controlli per automatizzare la gestione della sicurezza:
- Configura i sistemi di protezione a livello di organizzazione utilizzando il servizio policy dell'organizzazione.
- Applica il criterio in fase di ammissione utilizzando i webhook di ammissione di Kubernetes.
- Automatizza la prima risposta per i rilevamenti con un alto livello di affidabilità.
- Stabilisci la correlazione SIEM cross-layer e le baseline comportamentali per tenant.
Riepilogo delle best practice
La seguente tabella riassume le best practice consigliate in questo documento:
| Argomento | |
|---|---|
| Migliorare la sicurezza a livello di infrastruttura | Proteggi i nodi GKE, implementa i controlli di rete, gestisci identità e accessi, gestisci chiavi e secret e migliora la sicurezza della catena di fornitura. |
| Migliorare la sicurezza a livello di modello | Migliorare l'integrità del modello, proteggere la riservatezza del modello e migliorare le proprietà di sicurezza del modello. |
| Migliorare la sicurezza a livello di applicazione | Difenditi dalle minacce a livello di contenuti, proteggi i prompt di sistema, gestisci sessioni e routing e migliora la sicurezza degli agenti AI. |
| Configurare l'osservabilità e la risposta agli incidenti | Raccogli log e metriche, rileva minacce specifiche dell'AI e stabilisci una procedura di risposta agli incidenti. |
| Implementare la sicurezza durante il ciclo di vita del deployment | Esegui il deployment dell'infrastruttura, gestisci i workload e l'infrastruttura e governa i deployment su larga scala. |
Passaggi successivi
- Best practice per la sicurezza dell'AI generativa
- Best practice per rafforzare la sicurezza del cluster