Normes de sécurité pour Gemini

Ce document décrit les normes de sécurité et les garde-fous pour le déploiement de Gemini pour Google Cloud et Gemini pour Government. Ces normes vous aident à vous conformer aux frameworks du secteur public tels que FedRAMP High et DoD IL5.

Bien que Stellar Engine automatise les déploiements de zones d'atterrissage de base, vous devez appliquer des garde-fous spécifiques pour les charges de travail d'IA sensibles afin de maintenir la souveraineté, d'empêcher la dérive de configuration et d'atténuer les failles spécifiques à l'IA.

Prérequis

Pour garantir un cycle de vie de déploiement sécurisé, respectez les prérequis suivants avant de lancer le provisionnement de l'infrastructure :

• Application de l'infrastructure as code (IaC) : éliminez les configurations manuelles dans la Google Cloud console. Implémentez toutes les modifications d'environnement, les actions de correction et les ajustements à l'aide de pipelines CI/CD automatisés pour éviter la dérive de configuration.
• Utilisation du dépôt officiel : utilisez les dépôts Stellar Engine officiels. Les forks non vérifiés ou les variations personnalisées peuvent introduire des régressions de sécurité.
• Security Command Center Premium: Activez Security Command Center Premium dans tous les dossiers pour activer la détection continue des menaces et la surveillance de la conformité.

Verrouillage de l'environnement racine

Pour répondre aux frameworks FedRAMP High et DoD IL5, appliquez les contrôles stricts suivants au niveau du dossier et de l'organisation :

• Architecture à deux dossiers : séparez les ressources à l'aide d'au moins deux dossiers dédiés régis par Assured Workloads : un pour FedRAMP High et un pour FedRAMP Moderate ou IL5.
• Résidence des ressources : verrouillez la résidence des ressources dans les régions américaines convenues au préalable (par exemple, us-east4).
• Contrainte liée aux règles d'administration : activez les contraintes suivantes pour limiter l'accès :
  • iam.allowedPolicyMemberDomains: limitez l'accès aux domaines d'agence autorisés.
  • compute.vmExternalIpAccess: empêchez l'attribution d'adresses IP publiques aux instances de VM.
  • compute.restrictVpcPeering: réduisez les risques de traversée latérale et acheminez le trafic des spokes via des hubs centralisés.
  • vertexai.allowedModels: limitez l'accès aux modèles autorisés (par exemple, pour empêcher l'ingestion de modèles externes ou partenaires non approuvés).
• Accès basé sur le contexte : exigez Identity-Aware Proxy (IAP) pour vérifier l'identité de l'utilisateur et la posture de sécurité de son appareil (à l'aide d'Access Context Manager) avant d'acheminer le trafic vers la couche d'application Gemini.

Configuration sécurisée

Les déploiements doivent appliquer une topologie en étoile régie par Network Connectivity Center plutôt que par un peering plat. La topologie en étoile présente les avantages suivants :

• Séparation du trafic : isolez le trafic dans des VPC spécialisés (par exemple, vpc-trust pour le routage interne, vpc-mgmt pour la gestion des appliances et vpc-untrust).
• Protection des limites : dirigez le trafic via des VPC d'inspection spécialisés équipés de pare-feu de nouvelle génération (NGFW) en cluster pour assainir le trafic entrant et sortant.
• Isolation latérale : configurez les hubs NCC pour vous assurer que les réseaux spokes qui diffusent les données d'application ne peuvent pas communiquer directement entre eux, ce qui élimine les vecteurs de mouvement latéral.

Garde-fous pour les applications

Pour protéger la couche d'application et les modèles de sauvegarde contre les risques d'injection ou d'exfiltration classiques, implémentez les éléments suivants :

• Équilibrage de charge privé : exposez les applications frontend à l'aide d'un équilibreur de charge d'application externe régional uniquement, en vous assurant qu'elles ne sont jamais directement accessibles depuis Internet.
• **IAP**: appliquez une validation stricte de l'identité et de la posture de l'appareil avant d'acheminer le trafic vers la couche d'application Gemini.
• Model Armor: activez Model Armor pour tous les modèles de sauvegarde qui s'exécutent sur Gemini Enterprise Agent Platform. Model Armor est requis pour appliquer la sécurité de la charge utile au moment de l'exécution, respecter la conformité du contenu et atténuer les failles d'injection de prompt.

Protection et audit des données

Pour protéger les charges de travail souveraines, vous pouvez implémenter les fonctionnalités d'audit et d'immuabilité centralisées suivantes :

• Schéma de classification des données : intégrez-le à votre schéma de classification des données pour optimiser le placement des contrôles.
• Périmètres VPC Service Controls : implémentez des périmètres VPC Service Controls autour des environnements de traitement et de stockage des données sensibles pour éviter l'exfiltration de données. Les périmètres sont obligatoires pour le DoD IL5.
• Séparation des tâches KMS : appliquez une séparation stricte des tâches pour les clés cryptographiques. Assurez-vous que les administrateurs de la sécurité qui gèrent les trousseaux de clés Cloud Key Management Service dans le projet de sécurité de phase 3 ne disposent pas des autorisations Identity and Access Management nécessaires pour déchiffrer les données.

• Récepteurs de journaux hiérarchiques : transférez la télémétrie au niveau de l'organisation vers des récepteurs structurés dédiés aux éléments suivants :

  • Journaux d'audit des activités d'administration et des accès aux données
  • Événements VPC Service Controls
  • Événements de connexion et Google Workspace
  • Télémétrie de conformité CIS

  Assurez-vous que les utilisateurs ne peuvent pas contourner le transfert de télémétrie.

• Ingestion SIEM : acheminez les journaux à l'aide de sujets Pub/Sub vers des projets d'administration spécialisés où les journaux sont stockés dans des dépôts de stockage immuables.

• Détection des anomalies : analysez les événements à l'aide d'outils SecOps tels que Google Security Operations pour détecter les violations telles que les pics d'API anormaux vers Agent Platform.

• Harmonisation des outils : intégrez la télémétrie à Google Threat Intelligence, Wiz Security Graph ou des outils tiers pour identifier les points de terminaison d'IA fantômes ou les configurations toxiques.

• Correction automatisée à l'aide de SOAR : utilisez des playbooks SOAR pour activer des défenses en temps réel, par exemple en isolant les points de terminaison de modèles non autorisés ou en désactivant les jetons compromis.

Surveillance et sécurité de l'IA

Maintenez l'observabilité et les pipelines de défense automatisés à l'aide des fonctionnalités suivantes :

• Surveillance de l'utilisation des API : créez des alertes pour la détection des pics sur les fonctions LLM de base (par exemple, serviceruntime.googleapis.com/api/request_count).
• Récepteurs de journaux hiérarchiques pour l'IA : configurez des récepteurs de journaux hiérarchiques pour capturer les événements spécifiques à l'IA, tels que les pics de volume d'appels d'API anormaux vers aiplatform.googleapis.com ou les violations de voyage impossible par les comptes de service d'IA. Assurez-vous que ces journaux sont stockés dans un dépôt de stockage immuable (par exemple, BigQuery) accessible par le SIEM de l'agence.
• Alignement sur le framework d'IA sécurisé (SAIF) : connectez la télémétrie aux quatre piliers SAIF suivants :
  • Bases solides : validez les autorisations IAM et l'état de Cloud KMS.
  • Extensions de détection : suivez les injections de prompt et les points de terminaison non autorisés à l'aide du filtrage des journaux.
  • Défenses automatisées : utilisez l'automatisation pour mettre en quarantaine ou rejeter les charges utiles anormales.
  • Harmonisation de la plate-forme : agissez sur le renseignement sur les menaces (à partir de Google Threat Intelligence ou des résultats de sécurité Wiz).