Atténuer les risques répertoriés dans le top 10:2025 de l'OWASP sur Google Cloud

Ce document identifie les services Google Cloud et les stratégies d'atténuation qui peuvent vous aider à vous protéger contre les attaques au niveau des applications décrites dans le Top 10:2025 de l'OWASP. Créée par l'Open Web Application Security (OWASP) Foundation, la liste OWASP Top 10:2025 répertorie les 10 principaux risques de sécurité dans un cycle de vie de développement logiciel (SDLC). Bien qu'aucun service ne puisse garantir une protection complète contre ces risques, l'application de ces services lorsqu'ils sont pertinents dans votre architecture peut contribuer à une solution de sécurité multicouche puissante.

L'infrastructure Google est conçue pour vous aider à créer, déployer et exploiter des services avec des contrôles de sécurité robustes. La sécurité physique et opérationnelle, le chiffrement des données au repos et en transit, ainsi que de nombreuses autres protections fondamentales de l'infrastructure sont gérés par Google. Vous bénéficiez de ces avantages en déployant vos applications sur Google Cloud, mais vous devrez peut-être prendre des mesures supplémentaires pour protéger votre application contre des attaques spécifiques.

Matrice de conformité

Les services Google Cloud répertoriés dans le tableau suivant peuvent vous aider à vous protéger contre les 10 premiers risques de sécurité identifiés par OWASP Top 10:2025 :

Catégorie OWASP Top 10:2025 Commandes Primary Google Cloud et Wiz

A01 : Contrôle d'accès défaillant

Access Context Manager, Agent Gateway, identité de l'agent, Apigee, Google Cloud Armor, Firebase App Check, Règles de sécurité Firebase, Cloud Next Generation Firewall (Cloud NGFW), Identity-Aware Proxy (IAP), Identity and Access Management (IAM), Service de règles d'administration, VPC Service Controls, Wiz Cloud

A02 : Configuration incorrecte de la sécurité

Access Context Manager, Cloud Asset Inventory, Google Security Operations, Règle d'administration de l'organisation, Security Command Center Premium, VPC Service Controls, Wiz Cloud

A03 : Défaillances de la chaîne d'approvisionnement logicielle

Artifact Registry, Assured Open Source Software (Assured OSS), autorisation binaire, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code

A04 : Défaillances cryptographiques

Apigee, Certificate Authority Service, Certificate Manager, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, informatique confidentielle, Organization Policy, Secret Manager, Sensitive Data Protection, Wiz Cloud

A05 : Injection

Apigee, Cloud Armor, CodeMender, Règles de sécurité Firebase, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code

A06 : Conception non sécurisée

Apigee, CodeMender, Mandiant, Wiz Cloud

A07 : Échecs d'authentification

Access Context Manager, identité de l'agent, Apigee, Cloud Armor, Cloud Identity, Firebase App Check, Firebase Authentication, Google Cloud Fraud Defense, IAM (Privileged Access Manager, fédération d'identité de charge de travail et Workforce Identity Federation), IAP, Identity Platform, Security Command Center Premium, Secret Manager, clés de sécurité Titan, Wiz Code

A08 : Manque d'intégrité des données ou du logiciel

Artifact Analysis, Assured OSS, autorisation binaire, Cloud Armor, Cloud Build, Cloud Deploy, Firebase App Check, Security Command Center Premium, VirusTotal, Wiz Defend

A09 : Carences des systèmes de journalisation et d'alerte de sécurité

Approbation de l'accès et Access Transparency, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Protection des données sensibles, Wiz Defend

A10 : Mauvaise gestion des conditions exceptionnelles

Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

ServicesGoogle Cloud

Les sections suivantes décrivent les bonnes pratiques OWASP Top 10 pour les servicesGoogle Cloud de base.

Access Approval et Access Transparency

Access Transparency et Access Approval permettent de vérifier l'accès du fournisseur de services cloud. Access Transparency vous permet d'enregistrer le motif de chaque accès effectué par le personnel Google. La fonctionnalité Access Approval vous permet d'accepter ou de refuser les demandes d'accès émanant d'employés de Google chargés de vous fournir une assistance.

S'applique à A09 : Carence des systèmes de journalisation et d'alerte de sécurité.

Consultez les bonnes pratiques suivantes :

  • Automatisez le processus d'approbation des accès. Pour ce faire, configurez Access Approval afin d'envoyer les métadonnées des demandes d'approbation d'accès entrantes à un sujet Pub/Sub. Créez un abonnement Pub/Sub qui envoie la charge utile JSON à votre point de terminaison de webhook personnalisé (tel qu'un service Cloud Run authentifié, des fonctions Cloud Run ou une passerelle d'API d'entreprise) pour traitement.
  • Considérez les journaux Access Transparency comme des données de télémétrie de sécurité critiques. Créez des métriques basées sur les journaux et des règles d'alerte dans Monitoring pour signaler à votre centre des opérations de sécurité (SecOps) si du personnel Google accède à des ressources sensibles sans ticket d'assistance actif correspondant.
  • Exporter directement les journaux Access Transparency vers Google SecOps ou votre SIEM d'entreprise centralisé.
  • Créez une règle de conformité pour auditer régulièrement vos flux de journaux et vérifier que les événements d'accès d'urgence auto_approved correspondent à un incident documenté de gravité élevée.
  • Pour le contrôle cryptographique, utilisez Key Access Justifications afin de forcer le système à demander une approbation de déchiffrement de clé de manière programmatique.

Access Context Manager

Access Context Manager est le moteur d'accès contextuel deGoogle Cloud. Access Context Manager vous permet de définir des niveaux d'accès basés sur des attributs (tels que les plages d'adresses IP des clients, la stratégie de sécurité des appareils et l'emplacement géographique) pour IAP, VPC Service Controls et IAM.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A02 : Erreur de configuration de sécurité
  • A07 : Échecs d'authentification

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Créez des niveaux de sécurité réutilisables et hiérarchisés pour la règle d'accès de votre organisation. Créez des niveaux d'accès de base pour tester les attributs standards. Pour les conditions complexes à plusieurs facteurs, déployez des niveaux d'accès personnalisés afin d'évaluer les états avancés des appareils et les signaux des points de terminaison tiers.
  • Utilisez Endpoint Verification ou Chrome Enterprise Core pour appliquer des contraintes au niveau de l'appareil, comme le chiffrement complet du disque, un verrouillage d'écran actif et une version approuvée du système d'exploitation.
  • Pour protéger les dépôts de données à forte valeur ajoutée avec VPC Service Controls, ajoutez des niveaux d'accès à vos règles d'entrée VPC Service Controls. Si une clé de compte de service est divulguée, un pirate informatique ne peut pas l'utiliser seule pour interroger BigQuery ou Cloud Storage à partir d'une adresse IP publique non autorisée ou d'une machine non fiable.
  • Pour étendre la protection "zéro confiance" aux applications Web et aux tunnels administratifs de VM, associez des niveaux d'accès directement à vos ressources sécurisées par IAP.

Consultez les bonnes pratiques suivantes pour A02 : mauvaise configuration de la sécurité :

  • Implémentez des règles d'accès limitées associées à des dossiers spécifiques pour déléguer la gestion des règles locales à des équipes de projet individuelles et isoler leurs modifications du reste de l'organisation.
  • Pour éviter que les règles d'entrée orphelines ne deviennent des portes dérobées silencieuses, vérifiez et supprimez régulièrement les plages d'adresses IP mises hors service, les sous-réseaux partenaires expirés et les attributs d'appareil obsolètes.

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Utilisez des liaisons d'accès utilisateur pour définir des durées de session maximales strictes. Configurez la règle de réauthentification pour exiger SECURITY_KEY (FIDO2 ou WebAuthn). Pour appliquer des contraintes plus strictes aux environnements à haut risque, configurez scopedAccessSettings afin de remplacer les durées de session par défaut pour les applications sensibles.

Agent Gateway et Agent Identity

Agent Gateway et Agent Identity fournissent une application dédiée des règles réseau, une gestion du cycle de vie des identités et une authentification cryptographique pour les agents IA et les workflows agentiques.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A07 : Échecs d'authentification

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Dans les environnements avec des systèmes multi-agents, des outils MCP externes ou des pipelines autonomes, utilisez Agent Gateway comme point d'application des règles et réseau dédié pour limiter les échecs de contrôle d'accès agentique.
  • Configurez des règles d'autorisation précises pour les identités d'agent afin de limiter l'accès aux outils et la récupération de données aux seules ressources requises pour le workflow spécifique de l'agent.

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Pour authentifier les agents autonomes et les intégrations d'outils sans intégrer de clés API ni de mots de passe statiques, générez et attribuez une identité d'agent à chaque agent.
  • Configurez l'identité de l'agent pour émettre un certificat X.509 en tant qu'identifiants de l'agent. Ces certificats permettent d'éviter le vol de jetons. Ainsi, si un jeton d'accès est intercepté, il ne peut pas être utilisé dans d'autres environnements.

Apigee

Apigee fournit des mécanismes centralisés au niveau de la passerelle à l'aide de proxies d'API pour appliquer des normes cryptographiques, valider les charges utiles signées et chiffrer les données d'application en transit et au repos. En agissant comme une passerelle de proxy inverse pour le trafic d'API, Apigee effectue des vérifications de limites et de structure pour valider les charges utiles. Apigee fournit des règles d'authentification des API, OAuth et de validation des jetons Web JSON (JWT) intégrées pour établir des limites d'identité fortes. Apigee propose plusieurs méthodes pour effectuer la journalisation, la surveillance, la gestion des exceptions et la journalisation d'audit.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A04 : Défaillances cryptographiques
  • A05 : Injection
  • A06 : Conception non sécurisée
  • A07 : Échecs d'authentification
  • A09 : Carences des systèmes de journalisation et d'alerte de sécurité

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Utilisez des proxys d'API pour effectuer les opérations suivantes :

    • Interceptez les requêtes dans lesquelles un pirate informatique tente d'accéder aux enregistrements d'un autre utilisateur en manipulant les variables d'ID dans le chemin d'accès de la requête API.

    • Empêchez les clients standards d'exécuter des méthodes administratives restreintes ou des opérations à privilèges élevés.

  • Pour le plan de gestion des API, appliquez des contrôles d'accès, une authentification et un stockage secret à l'aide de cartes de valeurs clés chiffrées, de Secret Manager ou de secrets Kubernetes (déploiements hybrides uniquement).

  • Utilisez des règles OAuth et des jetons JWT pour vérifier les signatures. Mappez les points de terminaison et les actions sensibles à des niveaux d'autorisation OAuth précis et élevés (par exemple, delete:account ou write:billing). Utilisez la règle OAuthV2 pour valider ces niveaux d'autorisation au point d'entrée de l'API et renvoyer un code d'état HTTP 403 Forbidden à tout client ne disposant pas des autorisations appropriées.

  • Activez Advanced API Security pour analyser le trafic et détecter les modèles de comportement anormaux, puis lancez des actions de sécurité.

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

  • Chiffrez les données sensibles dans votre application et appliquez une validation cryptographique stricte avant que le trafic n'atteigne votre application de backend. Configurez votre environnement Apigee avec des clés de chiffrement gérées par le client (CMEK) à l'aide de Cloud KMS.
  • Utilisez le protocole TLS unidirectionnel et bidirectionnel pour chiffrer les informations sensibles au niveau du protocole. Pour les intégrations d'entreprise serveur à serveur ou à haut risque, configurez mTLS (TLS mutuel) au niveau de la passerelle d'entrée Apigee.
  • Utilisez les stratégies VerifyJWT et VerifyJWS pour exiger que les jetons entrants disposent d'une signature cryptographique valide avant que la requête ne soit traitée. Utilisez les techniques OAuth standards et envisagez d'implémenter le hachage HMAC et de charge utile, la validation de l'état ou du nonce, et la clé de vérification pour l'échange de code (PKCE) afin de renforcer la sécurité cryptographique de chaque requête.
  • Masquez les données sensibles pour qu'elles soient chiffrées et masquées lorsque vous utilisez l'outil de débogage Apigee.

Consultez les bonnes pratiques suivantes pour A05 : Injection :

Consultez les bonnes pratiques suivantes pour A06 : Conception non sécurisée :

  • Validez les requêtes entrantes avec la règle OASValidation pour les messages de requête ou de réponse entrants par rapport à la spécification OpenAPI.
  • Atténuez les pics de trafic et la surcharge du backend en implémentant les règles SpikeArrest et Quota.
  • Utilisez des règles de gestion des erreurs pour intercepter les erreurs de backend (comme un plantage de base de données) et les réécrire en réponses HTTP génériques.

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Implémentez la validation des clés API pour vos API destinées aux développeurs afin qu'Apigee puisse vérifier si la clé API d'une application cliente est présente, valide et autorisée à accéder à la ressource d'API demandée.
  • Pour éviter le vol de jetons de session et les attaques par relecture, implémentez la démonstration de la preuve de possession (DPoP). DPoP associe les jetons à la clé publique de l'expéditeur pour atténuer la réutilisation des jetons.
  • Protégez les points de terminaison de génération de jetons et de connexion contre les attaques par force brute automatisées en combinant les limites de fréquence SpikeArrest avec l'intégration de reCAPTCHA Enterprise.

Consultez les bonnes pratiques suivantes pour A09 : Carences des systèmes de journalisation et d'alerte de sécurité :

  • Transmettez de manière asynchrone les métadonnées structurées des transactions d'API aux journaux ou aux systèmes SIEM tiers. Associez votre règle MessageLogging à PostClientFlow, qui s'exécute une fois la réponse envoyée au client.
  • Centralisez les journaux d'audit de la plate-forme pour suivre les modifications apportées aux proxys d'API, aux identifiants et aux environnements de déploiement. Pour éviter que des modifications non autorisées apportées aux proxys passent inaperçues, intégrez Apigee à Cloud Audit Logs. Pour en savoir plus, consultez Journaux d'audit Apigee et Journaux d'audit Apigee API Management.
  • Configurez des alertes Advanced API Security dans Monitoring pour informer les équipes SecOps des campagnes de scraping automatisées, des utilisations abusives d'identifiants et des régressions du score de sécurité.
  • Nettoyez les variables fournies par l'utilisateur dans vos modèles de messages de journaux en les encapsulant dans la fonction escapeJSON().
  • Si vous diffusez des métadonnées de journaux vers un SIEM externe, configurez la règle MessageLogging pour qu'elle utilise Syslog sur TLS (port TCP 6514) afin de chiffrer vos données en transit.

Artifact Registry et Artifact Analysis

Artifact Registry est un dépôt unique permettant à votre organisation de gérer les images de conteneurs et les packages de langages. Artifact Analysis fournit une analyse intégrée des failles, la génération de nomenclatures logicielles (SBOM) et le stockage des métadonnées pour les artefacts stockés dans Artifact Registry.

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A08 : Manque d'intégrité des données ou du logiciel

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

  • Réduisez la surface d'attaque et contribuez à empêcher le déploiement d'anciennes images vulnérables en configurant des règles de nettoyage pour supprimer les images candidates à la publication non versionnées, non taguées ou obsolètes après une période de conservation prédéfinie.
  • Protégez-vous contre les attaques par confusion de dépendances en configurant des dépôts virtuels avec des priorités de dépôt en amont qui privilégient les dépôts d'artefacts internes par rapport aux registres publics.
  • Appliquez des tags d'image immuables ou déployez des images strictement par condensé cryptographique (sha256:...) pour éviter les attaques par mutation de tag.

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

Assured OSS

Assured OSS vous permet d'intégrer les packages OSS que Google valide et utilise dans vos propres workflows de développement.

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A08 : Manque d'intégrité des données ou du logiciel

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

  • Configurez les dépôts distants pour qu'ils pointent en amont vers Assured OSS.
  • Vérifiez que les bibliothèques Open Source de vos compilations contiennent une signature Google valide et un enregistrement de provenance du build SLSA vérifiable. Configurez des portes de qualité dans Cloud Build pour valider ces attestations avant de compiler les binaires de l'application.
  • Configurez les gestionnaires de packages (tels que pip.conf, settings.xml ou build.gradle) dans vos images de base Cloud Workstations pour qu'ils ne pointent que vers vos dépôts Assured OSS internes.
  • Utilisez les métadonnées générées par Assured OSS pour déterminer si une CVE récemment divulguée dans un package Open Source est exploitable dans votre contexte de déploiement spécifique.

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

Autorisation binaire

L'autorisation binaire vérifie l'intégrité des conteneurs afin que seules les images de conteneurs fiables soient déployées. Vous pouvez créer des règles pour autoriser ou refuser les déploiements en fonction de la présence ou de l'absence d'attestations. L'autorisation binaire applique des règles au niveau d'un cluster afin que vous puissiez configurer différentes règles pour différents environnements.

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A08 : Manque d'intégrité des données ou du logiciel

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

  • Configurez des pipelines de déploiement pour référencer et appliquer des images de conteneurs en fonction de leur condensé cryptographique SHA-256 unique et immuable (tel que @sha256).
  • Déployez la validation continue de l'autorisation binaire sur vos clusters GKE pour surveiller les pods actifs par rapport à votre règlement de la plate-forme et générer des alertes dans Logging si les conteneurs en cours d'exécution ne sont plus conformes.

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

  • Appliquez la génération automatique d'attestations dans vos pipelines Cloud Build ou GitHub Actions. Créez des exigences d'attestation progressive afin que les images passent par des étapes de validation séquentielles à mesure qu'elles se rapprochent de la production.
  • Pour les incidents de production de haute gravité, activez les déploiements d'urgence Breakglass. Configurez des règles d'alerte Monitoring sur les événements de journal d'audit Breakglass pour avertir votre équipe SecOps lorsqu'un contournement d'admission se produit.

Service CA et Gestionnaire de certificats

Certificate Authority Service (CA Service) simplifie le déploiement et la gestion des autorités de certification (CA) privées. Le gestionnaire de certificats permet de provisionner, de renouveler et de gérer de manière centralisée les certificats TLS pour Cloud Load Balancing et Cloud CDN.

S'applique à A04 : Défaillances cryptographiques.

Consultez les bonnes pratiques suivantes :

  • Utilisez CA Service pour automatiser l'émission et la gestion du cycle de vie des certificats privés. Déployez des autorités de certification racine et intermédiaires soutenues par Cloud HSM pour protéger les clés privées, et utilisez des modèles de certificats pour appliquer des règles cryptographiques (telles que les longueurs de clé minimales et les utilisations de clé étendues autorisées).
  • Activez Cloud Audit Logs pour surveiller les événements administratifs à haut risque (tels que la révocation d'une autorité de certification, les mises à jour des règles ou un pic soudain de demandes de certificats). Acheminez les alertes vers Google SecOps pour détecter les menaces internes potentielles ou les pipelines CI/CD compromis.
  • Configurez Certificate Manager pour qu'il utilise des certificats gérés par Google associés à des autorisations DNS. Certificate Manager valide la propriété du domaine, émet le certificat X.509 et gère les renouvellements 30 jours avant l'expiration.
  • Associez des cartes de certificats à des proxys HTTPS cibles pour activer la sélection dynamique et la rotation des certificats sans avoir à redémarrer les proxys ni à reconfigurer les équilibreurs de charge.
  • Pour l'équilibrage de charge hybride ou des microservices internes, configurez des maps de certificats pour émettre des certificats privés directement à partir d'un pool d'autorités de certification CA Service privées.
  • Configurez des mappages de certificats pour faire correspondre les requêtes d'indication du nom de serveur (SNI) entrantes à des certificats spécifiques.

Inventaire des éléments cloud

L'inventaire des éléments cloud vous permet de surveiller votre infrastructure sur Google Cloud pour détecter les infrastructures informatiques orphelines ou non autorisées.

S'applique à A02 : erreur de configuration de sécurité.

Consultez les bonnes pratiques suivantes :

  • Configurez des notifications pour vous avertir en cas de ressources en cours d'exécution inattendues, qui peuvent être mal sécurisées ou utiliser des logiciels obsolètes.
  • Utilisez l'analyseur de stratégies IAM pour découvrir les contrôles d'accès mal configurés, tels que les buckets de stockage publics avec l'autorisation allUsers, les rôles de compte de service disposant de trop de privilèges ou les identités orphelines.
  • Exportez des instantanés d'éléments vers BigQuery pour auditer les configurations d'infrastructure au fil du temps et maintenir un enregistrement de conformité de référence dans les environnements multiprojets.

Cloud Armor

Cloud Armor est un pare-feu d'application Web (WAF) adaptatif que vous déployez à la périphérie de votre réseau Google Cloud pour vous aider à vous protéger contre les attaques DDoS et à bloquer les charges utiles d'injection SQLi ou XSS. Cloud Armor inclut des règles WAF préconfigurées pour vous protéger contre les dix principales failles de sécurité selon l'OWASP, limiter la surface d'attaque de vos points de terminaison d'authentification et bloquer les identifiants compromis.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A05 : Injection
  • A07 : Échecs d'authentification
  • A08 : Manque d'intégrité des données ou du logiciel
  • A10 : Mauvaise gestion des conditions exceptionnelles

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

Consultez les bonnes pratiques suivantes pour A05 : Injection :

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Restreignez l'accès aux points de terminaison d'authentification et d'administration aux adresses IP ou aux pays autorisés.
  • Activez evaluatePreconfiguredWaf pour intercepter et bloquer les requêtes conçues pour exploiter les failles de l'état de session et le détournement de session.
  • Utilisez l'API securityPolicies.patchRule pour bloquer toutes les requêtes entrantes qui contiennent un paramètre compromis dans la chaîne de requête ou les en-têtes au niveau du réseau.

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

  • Limitez les points de terminaison qui acceptent les objets sérialisés à haut risque provenant de sources non fiables à un ensemble d'adresses IP de confiance à l'aide d'une règle de refus semblable à la suivante :

    request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')

  • Déployez des règles personnalisées pour inspecter les mots clés du corps de la requête afin d'identifier les schémas d'exécution spécifiques à la langue et les signatures de désérialisation dangereuses.

Consultez les bonnes pratiques suivantes pour A10 : mauvaise gestion des conditions exceptionnelles :

  • Activez Google Cloud Armor Adaptive Protection dans vos stratégies de sécurité pour établir des modèles de trafic normaux, configurer des alertes sur les anomalies de couche 7 et générer des règles WAF ciblées avec des signatures d'attaque.
  • Configurez des règles de limitation du débit Cloud Armor sur les points de terminaison critiques (par exemple, les API /login, /checkout ou de recherche). Les règles de limitation du débit limitent les requêtes en fonction de l'adresse IP ou de l'en-tête HTTP de chaque client (par exemple, en limitant les clients à 100 requêtes par minute) et renvoient un code d'état HTTP 429 Too Many Requests.
  • Définissez la règle par défaut de priorité la plus basse dans votre règle de sécurité Cloud Armor sur Deny (code d'état : 403 ou 404).

Cloud Build et Cloud Deploy

Cloud Build et Cloud Deploy fournissent un pipeline d'intégration et de livraison continues (CI/CD) intégré et sécurisé surGoogle Cloud. Cloud Build crée des artefacts avec une provenance SLSA vérifiable et des attestations cryptographiques, tandis que Cloud Deploy gère les déploiements progressifs, les approbations cibles et la vérification automatisée sur GKE et Cloud Run.

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A08 : Manque d'intégrité des données ou du logiciel

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

  • Définissez requestedVerifyOption: VERIFIED dans votre fichier cloudbuild.yaml pour exiger une provenance vérifiable.
  • Déployez des pools privés Cloud Build appairés à votre réseau VPC privé pour les compilations d'entreprise sensibles.
  • Configurez des déclencheurs de compilation pour qu'ils s'exécutent sous des comptes de service dédiés et gérés par l'utilisateur. N'accordez à ces comptes de service que les autorisations IAM minimales requises (par exemple, Rédacteur Artifact Registry (roles/artifactregistry.writer) et Rédacteur de journaux (roles/logging.logWriter)).
  • Exigez des approbations manuelles sur les déclencheurs Cloud Build qui ciblent les environnements de préproduction ou de production.
  • Limitez les outils de compilation CI (tels que Cloud Build, GitHub Actions ou GitLab) au rôle Cloud Deploy Releaser (roles/clouddeploy.releaser) afin que les pipelines de compilation ne puissent créer que des versions.
  • Pour exiger des approbations manuelles, configurez le manifeste de votre pipeline de déploiement (delivery-pipeline.yaml) avec requireApproval: true sur vos cibles de préproduction et de production.
  • Configurez des environnements d'exécution avec des comptes de service spécifiques à la cible (par exemple, un compte de service avec des autorisations limitées à l'espace de noms intermédiaire et un compte de service distinct et audité pour la production).
  • Déployez des hooks personnalisés pour exécuter des assertions de sécurité hors bande pendant le cycle de vie du déploiement. Utilisez des hooks de pré-déploiement pour vérifier si les clusters cibles respectent les bases de référence de conformité et des hooks de post-déploiement pour lancer des analyses automatisées des failles sur les points de terminaison de conteneurs actifs.

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

  • Intégrez Cloud Build à Cloud KMS et à Artifact Analysis pour créer et signer des attestations cryptographiques lorsque les tests unitaires et d'analyse statique sont effectués avec succès.
  • Utilisez des condensés SHA-256 cryptographiques immuables (par exemple, golang@sha256:...) dans les étapes du compilateur dans cloudbuild.yaml.
  • Stockez les configurations de compilation dans des dépôts avec contrôle des versions protégés par des règles de protection des branches (par exemple, en exigeant des examens par deux personnes pour les demandes d'extraction). Limitez les autorisations de modification des déclencheurs aux administrateurs de plate-forme autorisés à l'aide de comptes de service gérés par l'utilisateur.
  • Promouvez des fichiers manifestes de déploiement prérendus et identiques, ainsi que des condensés d'images de conteneurs immuables dans les étapes cibles, sans laisser les pipelines d'intégration continue modifier les fichiers manifestes entre la préproduction et la production.
  • Définissez des tâches de validation du déploiement automatisées dans votre fichier manifeste skaffold.yaml. Cloud Deploy exécute ces conteneurs de validation après le déploiement des pods pour effectuer des vérifications d'état dynamiques, des tests d'intégration et des assertions de contrat d'API.
  • Utilisez des stratégies de déploiement Canary. Si un test de validation Skaffold échoue ou si la surveillance détecte des seuils d'anomalie pendant une phase canary, Cloud Deploy interrompt le déploiement et rétablit le trafic vers la dernière version de publication correcte connue.
  • Configurez les clusters GKE et Cloud Run pour appliquer les règles d'autorisation binaire. Lorsque Cloud Deploy applique les fichiers manifestes, le contrôleur d'admission cible vérifie de manière cryptographique les résumés des images de conteneurs et rejette les artefacts non fiables.

Cloud Identity et clés de sécurité Titan

Cloud Identity fournit une gestion centralisée des identités, du cycle de vie des identifiants et des accès dans Google Cloudet Google Workspace. Les clés de sécurité Titan sont des dispositifs de sécurité matériels résistants à l'hameçonnage qui utilisent la cryptographie à clé publique basée sur les normes FIDO2 ou WebAuthn.

S'applique à A07 : Échecs d'authentification.

Consultez les bonnes pratiques suivantes :

  • Pour vous protéger contre les attaques d'hameçonnage de type "man-in-the-middle" (MITM), configurez la validation en deux étapes et définissez la méthode autorisée sur Clés de sécurité uniquement (FIDO2, WebAuthn ou clés de sécurité Titan).
  • Configurez l'authentification unique (SSO) basée sur SAML 2.0 ou OIDC avec votre fournisseur d'identité d'entreprise et le provisionnement automatique.
  • Définissez la règle de durée de session sur un seuil maximal bas pour forcer les utilisateurs à se réauthentifier régulièrement.Google Cloud
  • Enregistrez les clés de sécurité Titan en tant que clés d'accès pour activer l'authentification sans mot de passe, ce qui réduit considérablement les risques de piratage par force brute et de compromission des identifiants.
  • Rendez obligatoire l'authentification à deux facteurs avec les clés de sécurité Titan pour vos identités privilégiées (telles que les propriétaires de projet, les administrateurs de la facturation et les équipes SecOps) en appliquant des règles relatives aux clés de sécurité dans Cloud Identity. Inscrivez les utilisateurs à haut risque au Programme Protection Avancée.

Cloud KMS

Cloud KMS gère les clés cryptographiques symétriques et asymétriques pour les services Google Cloud compatibles et dans vos propres applications. Vous pouvez générer, utiliser, alterner et détruire des clés de chiffrement pour le chiffrement symétrique, la signature asymétrique, le chiffrement asymétrique et la signature MAC.

S'applique à A04 : Défaillances cryptographiques.

Consultez les bonnes pratiques suivantes :

  • Utilisez Cloud KMS Autokey pour automatiser le provisionnement et l'attribution. Avec la fonction de clé automatique, vous n'avez pas besoin de provisionner des trousseaux de clés, des clés et des comptes de service à l'avance. Au lieu de cela, les clés et les trousseaux de clés sont générés à la demande lors de la création de ressources.
  • Utilisez des clés Cloud KMS pour chiffrer les charges utiles sensibles avant de les envoyer dans des buckets de stockage ou des bases de données. Vous pouvez utiliser l'API ou les bibliothèques clientes Cloud KMS pour utiliser vos clés Cloud KMS pour le chiffrement côté client.
  • Vérifiez l'intégrité des données de bout en bout en validant les sommes de contrôle pendant le transfert.
  • Pour les charges de travail strictes en termes de conformité et de réglementation, stockez et exécutez vos opérations cryptographiques à l'aide de Cloud HSM. Cloud HSM stocke vos clés dans des modules de sécurité matériels validés FIPS 140-3 de niveau 3.
  • Configurez des calendriers de rotation automatique des clés sur une période définie (par exemple, tous les 90 jours).

Cloud Load Balancing

Cloud Load Balancing est un service géré, défini par logiciel et entièrement distribué qui répartit le trafic utilisateur entre plusieurs instances et régions de backend.

S'applique aux éléments suivants :

  • A04 : Défaillances cryptographiques
  • A10 : Mauvaise gestion des conditions exceptionnelles

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

Consultez les bonnes pratiques suivantes pour A10 : mauvaise gestion des conditions exceptionnelles :

Google Cloud Observability (journalisation, surveillance et Error Reporting)

Google Cloud Observability fournit une gestion complète des journaux avec Logging, des métriques et des alertes avec Monitoring, et un suivi en temps réel des plantages d'applications avec Error Reporting.

S'applique aux éléments suivants :

  • A09 : Carences des systèmes de journalisation et d'alerte de sécurité
  • A10 : Mauvaise gestion des conditions exceptionnelles

Consultez les bonnes pratiques suivantes pour A09 : Carences des systèmes de journalisation et d'alerte de sécurité :

  • Activez les journaux des accès aux données pour les dépôts de données à forte valeur ajoutée (tels que Cloud Storage, BigQuery et Spanner) qui stockent des données sensibles. Les journaux d'accès aux données vous permettent d'auditer chaque événement de lecture, d'écriture et de requête pour les données sensibles.
  • Appliquez le verrouillage de bucket et les règles de conservation pour le bucket de journaux personnalisé afin d'empêcher les pirates informatiques ou les administrateurs non autorisés de supprimer les journaux pour effacer leurs traces.
  • Utilisez des récepteurs agrégés pour compiler et acheminer les entrées de journal dans un seul dépôt centralisé pour vos équipes SecOps. Configurez des récepteurs agrégés d'interception pour éviter de stocker les journaux à fort volume, comme les journaux d'accès aux données, à plusieurs endroits.
  • Configurez des règles d'alerte basées sur les journaux pour les indicateurs de compromission critiques, tels que les erreurs IAM "Autorisation refusée", les créations inattendues de clés API ou les modifications soudaines de la configuration du pare-feu.
  • Déployez des règles d'alerte basées sur les journaux dans l'explorateur de journaux ou Monitoring. Spécifiez des filtres exacts ciblant les événements de gravité élevée, tels que les modifications non autorisées des stratégies IAM ou les révocations de clés KMS, afin qu'une notification d'incident soit générée lorsqu'une entrée de journal correspondante est ingérée.
  • Créez des métriques de compteur basées sur les journaux dans Logging pour convertir les entrées de journal correspondantes en données de séries temporelles. Créez ensuite une règle d'alerte basée sur des métriques dans Monitoring qui déclenche un incident lorsque le taux dépasse un seuil spécifique (par exemple, plus de 50 tentatives de connexion infructueuses en cinq minutes).
  • Configurez des règles d'alerte basées sur les journaux qui surveillent les appels administratifs à l'API Cloud Logging et qui vous alertent en cas de modifications inattendues des récepteurs d'exportation de journaux ou de suppression de buckets.
  • Configurez des canaux de notification avec des modèles de documentation clairs. Incluez des liens profonds directs vers la requête de l'explorateur de journaux, des procédures opérationnelles standards (POS) pour l'ingénieur d'astreinte et des étapes de correction explicites pour faciliter la résolution rapide des incidents.

Consultez les bonnes pratiques suivantes pour A10 : mauvaise gestion des conditions exceptionnelles :

  • Intégrez les SDK Error Reporting directement dans le code de votre application ou configurez Logging pour qu'il analyse les formats d'exception JSON structurés.
  • Configurez des canaux de notification Error Reporting ou des règles d'alerte Monitoring pour avertir vos équipes SecOps lorsqu'une nouvelle classe d'exception apparaît.

Cloud NGFW

Cloud NGFW est un service de pare-feu géré qui permet l'inspection avec état et le contrôle des applications de couche 7 pour le trafic nord-sud et est-ouest.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A05 : Injection

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

Consultez les bonnes pratiques suivantes pour A05 : Injection :

  • Configurez le service de détection et de prévention des intrusions avec un groupe de profils de sécurité qui refuse les menaces correspondant aux signatures d'exploitation d'injection SQL, d'injection de commandes OS et d'exécution de code à distance.
  • Configurez l'inspection TLS Cloud NGFW pour déchiffrer le trafic HTTPS entrant et sortant, appliquer des vérifications de signature d'injection IPS à la charge utile en texte brut et rechiffrer la session avant de la transmettre au backend.
  • Appliquez des règles de pare-feu de sortie basées sur le nom de domaine complet aux bases de données de backend et aux sous-réseaux Compute. Limitez les connexions sortantes aux domaines externes approuvés et prédéfinis pour empêcher les applications vulnérables de créer des shells inversés non autorisés.
  • Activez la journalisation des règles de pare-feu sur les profils de prévention des menaces et acheminez ces journaux vers Google SecOps pour corréler les signatures d'injection réseau bloquées avec la télémétrie au niveau de l'hôte. Vous pourrez ainsi identifier les charges de travail ciblées pour l'application de correctifs en priorité.

Cloud Workstations

Cloud Workstations fournit des environnements de développement gérés sur Google Cloud avec sécurité intégrée et personnalisations.

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A04 : Défaillances cryptographiques

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

  • Créez des images de conteneurs de base personnalisées stockées dans Artifact Registry qui préinstallent des outils de sécurité, des extensions de développeur fiables et des environnements d'exécution de langage approuvés.
  • Déployez vos clusters de stations de travail avec une entrée et une sortie d'adresses IP privées, et à l'intérieur d'un périmètre VPC Service Controls.
  • Configurez Cloud Workstations pour acheminer le trafic de session via IAP. Exigez des développeurs qu'ils s'authentifient à l'aide d'identifiants professionnels avec l'authentification multifacteur (MFA) activée et appliquez des rôles à privilèges minimum (par exemple, Utilisateur Cloud Workstations (roles/workstations.user)).
  • Configurez des configurations de stations de travail avec des limites de délai d'inactivité faibles (par exemple, l'arrêt automatique après deux heures d'inactivité). Lorsqu'une station de travail redémarre, Cloud Workstations extrait la dernière image de conteneur corrigée pour la sécurité, afin que les développeurs puissent travailler dans un environnement propre.

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

CodeMender

CodeMender est un agent d'ingénierie IA spécialisé et autonome. CodeMender peut corriger les failles nouvellement découvertes et réécrire le code existant pour résoudre les failles existantes. Vous pouvez installer et configurer CodeMender dans Gemini Enterprise Agent Platform.

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A05 : Injection
  • A06 : Conception non sécurisée

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

Consultez les bonnes pratiques suivantes pour A05 : Injection :

  • Exécutez la génération de correctifs automatisée dans des bacs à sable locaux isolés pour réécrire la logique vulnérable (par exemple, en assainissant les entrées). Avant de créer des demandes d'extraction, vérifiez que les tests unitaires sont réussis et que les preuves de concept ne sont plus exploitables.

Consultez les bonnes pratiques suivantes pour A06 : Conception non sécurisée :

  • Refactorisez la logique de code d'architecture ancienne ou non sécurisée à l'aide du moteur de correctifs itératifs de CodeMender, en fournissant des contraintes de codage explicites pour appliquer des modèles de conception sécurisés dans les modules d'application.
  • Maintenez un examen humain en boucle pour les demandes d'extraction et les diffs générés par CodeMender afin de vérifier que les modifications proposées sont conformes à vos consignes de codage sécurisé.

Informatique confidentielle

L'informatique confidentielle permet de protéger les données utilisées en les gardant chiffrées en mémoire pendant leur traitement. L'informatique confidentielle utilise des environnements d'exécution sécurisés (TEE, Trusted Execution Environments) basés sur le matériel pour s'assurer que vos données sensibles et vos clés de chiffrement ne sont pas accessibles par l'hyperviseur, le système d'exploitation hôte ni les administrateurs de l'infrastructure.

S'applique à A04 : Défaillances cryptographiques.

Consultez les bonnes pratiques suivantes :

  • Utilisez des Confidential VMs ou des nœuds Confidential Google Kubernetes Engine pour les charges de travail très sensibles (comme les informations permettant d'identifier personnellement l'utilisateur, les documents financiers ou les pondérations de modèles d'IA propriétaires).
  • Lorsque plusieurs organisations doivent mettre en commun des données sensibles pour l'analyse ou l'entraînement de l'IA (sans exposer les données brutes les unes aux autres), utilisez Confidential Space pour appliquer l'attestation cryptographique et l'isolation des données.

Firebase (Firebase Authentication, Firebase App Check et règles de sécurité Firebase)

Firebase fournit des contrôles de sécurité axés sur les développeurs pour l'identité, l'attestation du client et l'accès à la base de données. Firebase Authentication gère l'identité des utilisateurs et la gestion des sessions, App Check valide l'intégrité des applications clientes et les règles de sécurité Firebase appliquent le contrôle des accès basé sur les attributs et la validation du schéma pour Firestore et Cloud Storage.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A05 : Injection
  • A07 : Échecs d'authentification
  • A08 : Manque d'intégrité des données ou du logiciel

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Limitez les lectures et les écritures à l'ID de l'utilisateur authentifié dans les règles de sécurité Firebase. N'utilisez jamais de règles par défaut permissives comme allow read, write: if true;.
  • Pour les rôles administratifs, utilisez les SDK Firebase Admin pour définir des revendications personnalisées sur les jetons d'ID des utilisateurs et validez ces revendications dans vos règles de sécurité au lieu d'autoriser les écritures de profil côté client.
  • Appliquez App Check dans les règles de sécurité Firebase pour bloquer l'accès client non authentifié ou usurpé au niveau de la base de données.

Consultez les bonnes pratiques suivantes pour A05 : Injection :

  • Appliquez la validation de la structure de charge utile dans les règles de sécurité en vérifiant les types de champs de document entrants, la longueur des chaînes et la taille des objets pour rejeter les charges utiles d'écriture mal formées ou malveillantes avant l'ingestion dans la base de données.

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

Fraud Defense

Fraud Defense est une plate-forme unifiée de protection contre la fraude et les utilisations abusives, y compris la protection des bots, des comptes et des transactions sur le Web. reCAPTCHA, une offre qui fait partie de Fraud Defense, filtre les bots et autres formes d'automatisation et de trafic groupé en évaluant le niveau de risque des tentatives d'accès.

S'applique à A07 : Échecs d'authentification.

Consultez les bonnes pratiques suivantes :

  • Intégrez reCAPTCHA à votre WAF existant, tel que Google Cloud Armor, pour émettre des défis automatisés ou bloquer le trafic de robots à haut risque avant que les requêtes n'atteignent les points de terminaison d'authentification.
  • Protégez les comptes sur les points de terminaison de connexion, de réinitialisation du mot de passe et de renouvellement de la session. Obtenez des scores de risque de prise de contrôle de compte (ATO) en fonction de la vitesse de connexion des utilisateurs et des empreintes digitales des appareils.
  • Protégez-vous contre la fraude à la facturation par l'opérateur via SMS dans les formulaires d'inscription et d'A2F en évaluant les profils de risque des numéros de téléphone avant d'envoyer des SMS sortants.
  • Pour réduire les faux positifs et entraîner des modèles d'évaluation des risques spécifiques à votre site, annotez et envoyez régulièrement des commentaires sur les transactions.
  • Vérifiez les mots de passe lors des parcours de connexion et de création de compte des utilisateurs pour détecter si les identifiants fournis figurent dans des bases de données tierces sur les violations de données sur le Web.

Google SecOps

Google Security Operations est une plate-forme d'opérations de sécurité qui combine l'analyse de la télémétrie de sécurité (SIEM), l'orchestration, l'automatisation et la réponse de sécurité (SOAR), ainsi que les renseignements sur les menaces Mandiant de première ligne dans une plate-forme unique.

S'applique aux éléments suivants :

  • A02 : Erreur de configuration de sécurité
  • A09 : Carences des systèmes de journalisation et d'alerte de sécurité

Consultez les bonnes pratiques suivantes pour A02 : mauvaise configuration de la sécurité :

  • Ingérez les résultats de Security Command Center dans Google SecOps pour combiner les résultats de configuration incorrecte statique (par exemple, PUBLIC_BUCKET_ACL ou CMEK_DISABLED) avec la télémétrie en direct du réseau et du pare-feu.
  • Créez des playbooks de réponse SOAR automatisés pour exécuter des actions de confinement.
  • Utilisez Gemini pour accélérer le tri des configurations incorrectes et recevoir des résumés synthétisés des ressources mal configurées, des rôles IAM associés et des conseils de correction détaillés.

Consultez les bonnes pratiques suivantes pour A09 : Carences des systèmes de journalisation et d'alerte de sécurité :

  • Normalisez la télémétrie des journaux au modèle de données unifié (UDM) pour permettre une recherche et une corrélation multicloud rapides et standardisées sans les frais généraux liés à l'analyse des journaux bruts.
  • Écrivez des règles de détection YARA-L 2.0 pour surveiller les modifications de configuration à haut risque, telles que la désactivation d'OS Login, la suppression des récepteurs de journaux ou les modifications apportées aux périmètres VPC Service Controls.
  • Utilisez les détections organisées d'Applied Threat Intelligence pour évaluer vos données d'événements par rapport aux données de Mandiant Threat Intelligence.
  • Utilisez Gemini dans Google SecOps pour générer des règles de détection YARA-L à partir de descriptions en langage naturel et résumer des chronologies d'incidents complexes et en plusieurs étapes en résumés d'incidents exécutifs.

Identity-Aware Proxy

IAP crée une couche d'autorisation centrale pour les applications accessibles via HTTPS et les connexions TCP administratives. IAP vérifie l'identité et le contexte de l'utilisateur avant d'accorder l'accès aux ressources Cloud Run, App Engine, Compute Engine, GKE et sur site.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A07 : Échecs d'authentification

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Appliquez des contrôles d'accès précis aux applications Web, aux VM, aux API  Google Cloud et aux applications Google Workspace en fonction de l'identité d'un utilisateur, de son appartenance à un groupe et du contexte de la requête.
  • Intégrez Agent Gateway pour appliquer des contrôles d'accès à vos identités d'agent.
  • Utilisez le transfert TCP IAP pour établir des tunnels HTTPS chiffrés vers vos instances de backend et supprimer les points de terminaison SSH (port 22) et RDP (port 3389) accessibles sur Internet.

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Authentifiez les utilisateurs qui accèdent aux interfaces administratives et aux applications Web via IAP à l'aide des identités provisionnées dans IAM ou Cloud Identity.
  • Validez l'assertion JWT signée dans l'en-tête x-goog-iap-jwt-assertion au niveau de l'application. Validez la signature par rapport aux clés publiques de Google et vérifiez que la revendication d'audience (aud) correspond à l'ID de votre service de backend.
  • Pour empêcher les pirates informatiques de contourner l'authentification IAP, configurez les paramètres d'entrée Cloud Run pour n'autoriser que le trafic interne et Cloud Load Balancing, en bloquant l'accès public direct aux URL de vos conteneurs de backend. Pour les VM ou les nœuds GKE, configurez les règles de pare-feu VPC pour n'accepter que le trafic entrant provenant des plages d'adresses IP de l'équilibreur de charge.

Identity and Access Management

Identity and Access Management (IAM) vous permet de gérer un accès précis aux services et ressources dans Google Cloud. IAM inclut des fonctionnalités telles que les suivantes :

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A07 : Échecs d'authentification

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Utilisez des rôles prédéfinis ou personnalisés (et non des rôles de base) pour limiter les autorisations à des ressources ou des besoins utilisateur spécifiques.
  • Limitez les autorisations pour accorder les rôles Utilisateur du compte de service (roles/iam.serviceAccountUser) et Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator).
  • Utilisez IAM Recommender pour analyser les journaux d'utilisation active de votre organisation et supprimer les comptes disposant de trop d'autorisations.
  • Écrivez des conditions IAM dans vos liaisons de rôle pour ajouter une autorisation contextuelle et limiter l'accès par date, heure de la journée ou adresse IP d'origine.
  • Déployez des stratégies de limite d'accès des principaux (PAB) pour définir les organisations, les dossiers ou les projets auxquels un ensemble de comptes principaux peut accéder. Si un pirate informatique vole une session active ou si un compte de service reçoit accidentellement des rôles IAM étendus, PAB bloque l'accès si la ressource spécifiée se trouve en dehors de la limite désignée de l'identité.
  • Associez des règles de refus IAM au niveau de l'organisation ou du dossier pour bloquer les autorisations à haut risque (telles que iam.serviceAccountKeys.create ou resourcemanager.projects.delete).
  • Lorsque vous configurez des règles de refus IAM, déclarez un groupe de sécurité breakglass dédié dans la liste exceptionPrincipals. Utilisez des tags de ressources dans vos conditions de refus (tels que resource.matchTag('env', 'prod')) pour bloquer les actions destructrices sur les ressources de production tout en offrant aux développeurs une flexibilité opérationnelle dans les projets de bac à sable de développement.

Consultez les bonnes pratiques suivantes concernant A07 : Échecs d'authentification qui s'appliquent à Privileged Access Manager :

  • Convertissez les rôles administratifs critiques (comme Propriétaire (roles/owner), Administrateur de l'organisation (roles/resourcemanager.organizationAdmin) et Administrateur de sécurité (roles/iam.securityAdmin)) des liaisons IAM statiques en droits Privileged Access Manager. Configurez ces droits d'accès pour exiger une justification opérationnelle avant que l'élévation soit accordée.
  • Pour les environnements de production, configurez des règles de droits d'accès Privileged Access Manager avec des approbateurs obligatoires tels qu'un groupe SecOps central ou des responsables d'équipe.
  • Configurez la durée maximale des droits d'accès Privileged Access Manager sur la fenêtre opérationnelle réaliste la plus courte (par exemple, deux heures pour la maintenance standard, 30 minutes pour les actions breakglass). Une fois le délai écoulé,Google Cloud supprime la liaison de rôle IAM temporaire.
  • Gérez l'infrastructure Terraform à l'aide de ressources IAM non faisant autorité (par exemple, google_project_iam_member ou google_folder_iam_member plutôt que google_project_iam_policy ou google_project_iam_binding). Cette pratique permet d'éviter d'écraser vos pipelines Terraform ou de désynchroniser les liaisons de rôles temporaires Privileged Access Manager pendant qu'un administrateur corrige activement un incident.
  • Activez Cloud Audit Logs sur Privileged Access Manager pour enregistrer les actions liées aux droits d'accès et les événements d'expiration. Ingérez ces journaux dans Google SecOps pour recevoir des alertes sur les schémas d'élévation suspects, tels que les demandes d'élévation multiples en dehors des heures de bureau ou les demandes répétées provenant de géolocalisations inattendues.

Consultez les bonnes pratiques suivantes concernant les échecs d'authentification (A07) qui s'appliquent à la fédération d'identité de personnel :

  • Déployez des pools d'identités de personnel à l'aide de SAML 2.0 ou d'OpenID Connect (OIDC) pour fédérer des fournisseurs d'identité externes avecGoogle Cloud.
  • Configurez la durée de la session dans votre pool d'identité de personnel pour limiter la durée de vie des jetons des utilisateurs fédérés.
  • Appliquez des conditions d'attributs aux fournisseurs d'identité des employés pour atténuer la falsification de jetons IdP multitenants ou l'usurpation d'identité entre organisations.
  • Mappez les appartenances à des groupes externes pour attribuer des rôles IAM à des ensembles d'entités principales de groupes fédérés (par exemple, principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

Consultez les bonnes pratiques suivantes concernant A07 : Échecs d'authentification qui s'appliquent à la fédération d'identité de charge de travail :

  • Créez des pools et des fournisseurs d'identités de charge de travail pour les charges de travail externes. Utilisez des jetons OIDC éphémères et échangez-les de manière dynamique à l'aide du service de jetons de sécurité pour obtenir des jetons d'accès temporaires qui expirent en quelques minutes.
  • Appliquez des conditions d'attributs aux fournisseurs d'identité de charge de travail afin que les plates-formes multitenants externes ne puissent pas s'authentifier auprès de votre pool à partir de dépôts ou de comptes non autorisés.
  • Associez des rôles IAM directement à des ensembles de comptes principaux spécifiques filtrés par des attributs mappés personnalisés.
  • Lorsque vous configurez l'accès aux charges de travail, accordez des rôles IAM directement à l'identifiant principalSet:// fédéré sur la ressource cible.
  • Pour appliquer la fédération d'identité de charge de travail, définissez la contrainte constraints/iam.disableServiceAccountKeyCreation dans votre organisation.

Identity Platform

Identity Platform est la plate-forme de gestion de l'authentification et des accès client (CIAM) pour les clients Google Cloud . Identity Platform fournit une authentification avec compatibilité multiprotocole à l'aide de SDK et d'API. Identity Platform prend en charge l'authentification MFA, l'intégration à des services d'authentification tiers et le suivi d'activité contrôlable.

S'applique à A07 : Échecs d'authentification.

Consultez les bonnes pratiques suivantes :

  • Activez l'MFA pour l'ensemble de votre base d'utilisateurs. Privilégiez les méthodes résistantes à l'hameçonnage, comme TOTP (applications d'authentification) ou WebAuthn (biométrie et clés de sécurité).
  • Déployez des fonctions Cloud Run de blocage à l'aide des déclencheurs beforeCreate et beforeSignIn pour exécuter un code de sécurité personnalisé avant qu'un utilisateur ne soit enregistré ou qu'un jeton ne lui soit attribué. Cette pratique vous permet de bloquer les domaines d'adresses e-mail jetables, de restreindre les adresses IP ou d'exiger la validation des adresses e-mail.
  • Intégrez reCAPTCHA Enterprise pour évaluer les requêtes de connexion, d'inscription et de réinitialisation du mot de passe afin de détecter le trafic de robots, les tentatives de bourrage d'identifiants et les utilisations abusives automatisées.
  • Configurez des règles relatives aux mots de passe pour imposer une longueur minimale, exiger des caractères complexes spécifiques (comme des chiffres et des symboles), et bloquer les séquences prévisibles.
  • Si vous utilisez MFA par téléphone, configurez les régions SMS et activez la SMS defense reCAPTCHA pour limiter les messages de validation aux codes de pays où résident vos utilisateurs cibles.

Solutions Mandiant de conseil en sécurité de l'IA

Les solutions de conseil en sécurité de l'IA proposées par Mandiant peuvent évaluer vos architectures logicielles, processus métier et déploiements cloud proposés dès le début du cycle de développement. En appliquant des renseignements sur les menaces de première ligne à la conception de votre système, les consultants Mandiant vous aident à identifier les failles logiques cachées, les limites de confiance manquantes et les risques architecturaux avant même qu'une seule ligne de code ne soit écrite.

S'applique à A06 : Conception non sécurisée.

Consultez les bonnes pratiques suivantes :

  • Faites appel aux consultants Mandiant avant le début du développement pour effectuer des ateliers d'architecture et implémenter des contrôles de sécurité dès le début.
  • Collaborez avec des experts en modélisation des menaces pour cartographier les diagrammes de flux de données de votre application. Définissez les points où les données sensibles franchissent les limites de confiance pour identifier les points où des contrôles stricts d'authentification, de chiffrement et de validation doivent être appliqués.
  • Utilisez des frameworks de modélisation des menaces structurés (tels que STRIDE) lors de vos ateliers d'architecture. Les consultants Mandiant peuvent vous aider à hiérarchiser les failles de conception découvertes en fonction de leur exploitabilité dans le monde réel et de leur impact sur votre activité.
  • Établissez des bases de référence sécurisées pour la gouvernance de l'IA pour les workflows agentiques et les déploiements de LLM, en définissant des limites de confiance claires entre les agents d'IA, les serveurs MCP et les sources de données de backend d'entreprise.

Model Armor

Model Armor est conçu pour filtrer les prompts et les réponses des LLM, ainsi que les appels d'outils MCP. Model Armor inspecte les charges utiles de l'IA générative pour aider à détecter et à bloquer l'injection de prompt, les tentatives de jailbreaking, les URL malveillantes, les contenus toxiques et les fuites de données sensibles.

S'applique aux éléments suivants :

  • A05 : Injection
  • A10 : Mauvaise gestion des conditions exceptionnelles

Consultez les bonnes pratiques suivantes pour A05 : Injection :

  • Déployez des règles Model Armor en ligne au niveau de la passerelle d'API à l'aide de l'intégration Apigee ou d'Agent Gateway pour filtrer les requêtes entrantes et les réponses sortantes du modèle avant que le trafic n'atteigne les moteurs d'inférence ou les environnements d'exécution des outils.
  • Configurez des paramètres de plancher au niveau de l'organisation ou du dossier pour créer des consignes de sécurité de base obligatoires que les équipes de projet individuelles ne peuvent pas contourner.
  • Créez des modèles Model Armor personnalisés avec des seuils de confiance ajustés (par exemple, LOW_AND_ABOVE ou MEDIUM_AND_ABOVE) pour la détection des injections de prompts et du jailbreaking sur les points de terminaison publics.
  • Activez la détection des URL malveillantes et l'analyse des PDF et des fichiers dans votre modèle Model Armor pour comparer les URL intégrées aux bases de données de renseignements sur les menaces de Google. Supprimez les requêtes contenant des vecteurs de logiciels malveillants ou d'hameçonnage avant leur exécution.
  • Activez Sensitive Data Protection dans votre modèle Model Armor pour inspecter le trafic de sortie du modèle. Configurez l'anonymisation ou le masquage automatiques pour remplacer les données sensibles détectées par des espaces réservés avant que la réponse ne quitte la limite.

Consultez les bonnes pratiques suivantes pour A10 : mauvaise gestion des conditions exceptionnelles :

  • Configurez le code de votre application pour intercepter les verdicts MATCH_FOUND et renvoyer une réponse générique, afin que le système n'exécute pas la requête par défaut ni n'expose les traces d'exception brutes.
  • Implémentez une architecture fail-closed (fail-secure) dans le code de votre application pour rejeter les requêtes d'IA générative entrantes si les appels de l'API Model Armor rencontrent des délais d'attente réseau, des limites de débit ou des erreurs HTTP 5xx non gérées.

Règles d'administration

Les règles d'administration vous offrent un contrôle centralisé et automatisé sur les ressources Google Cloud de votre organisation.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A02 : Erreur de configuration de sécurité
  • A04 : Défaillances cryptographiques

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Appliquez constraints/storage.publicAccessPrevention pour remplacer les stratégies IAM ou les LCA au niveau du bucket qui tentent d'accorder l'accès à allUsers ou allAuthenticatedUsers.
  • Appliquez constraints/iam.allowedPolicyMemberDomains pour limiter strictement les liaisons de stratégie IAM à vos numéros client Google Workspace ou Cloud Identity validés.
  • Appliquez constraints/iam.disableServiceAccountKeyCreation aux dossiers de production pour empêcher les utilisateurs de télécharger les clés de compte de service, ce qui oblige les équipes d'ingénierie à adopter des alternatives éphémères comme la fédération d'identité de charge de travail.
  • Appliquez constraints/iam.automaticIamGrantsForDefaultServiceAccounts pour que Google Cloud n'attribue pas automatiquement le rôle permissif d'éditeur (roles/editor) aux comptes de service par défaut.
  • Pour les exigences non couvertes par les contraintes prédéfinies, déployez des contraintes personnalisées afin d'appliquer des configurations de ressources précises. Envisagez de limiter la création de VM aux familles de machines approuvées, de limiter la taille du provisionnement des disques persistants ou d'imposer des configurations spécifiques de tags de pare-feu réseau.

Consultez les bonnes pratiques suivantes pour A02 : mauvaise configuration de la sécurité :

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

  • Pour rendre CMEK obligatoire, appliquez constraints/gcp.restrictNonCmekServices au niveau de l'organisation ou du dossier de premier niveau, définissez le type de règle sur Deny et listez les services Google Cloud compatibles. Avant d'appliquer la contrainte, vérifiez que l'agent de service de chaque service cible existe et qu'il dispose du rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) sur les trousseaux de clés concernés.
  • Appliquez constraints/gcp.restrictCmekCryptoKeyProjects pour limiter la sélection de clés aux projets Cloud KMS dédiés.

Secret Manager

Secret Manager permet aux applications et aux pipelines d'accéder aux valeurs des secrets nommés en fonction des autorisations accordées avec IAM. Lorsque cette option est activée, les interactions avec Secret Manager créent une piste d'audit que vous pouvez utiliser pour répondre aux exigences d'investigation numérique et de conformité.

S'applique aux éléments suivants :

  • A04 : Défaillances cryptographiques
  • A07 : Échecs d'authentification

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Supprimez les valeurs sensibles telles que les clés API du code source, des fichiers .env et des configurations de compilation de conteneurs, puis stockez les identifiants dans Secret Manager. Récupérez les valeurs déchiffrées au moment de l'exécution à l'aide des bibliothèques clientesGoogle Cloud , des pilotes CSI GKE Secret Store ou des liaisons de secrets Cloud Run.
  • Appliquez des liaisons de stratégie IAM directement à des secrets individuels spécifiques, en accordant aux microservices le rôle Accesseur de secret Secret Manager (roles/secretmanager.secretAccessor) uniquement sur les secrets spécifiques dont ils ont besoin.
  • Configurez des calendriers de rotation automatique dans Secret Manager. Lorsqu'un intervalle de rotation commence, Secret Manager publie une notification SECRET_ROTATE dans un sujet Pub/Sub désigné. Configurez une fonction Cloud Run ou un service Cloud Run pour lire la notification, générer une nouvelle valeur secrète, ajouter la nouvelle version à Secret Manager et détruire la version obsolète.
  • Activez Cloud Audit Logs sur Secret Manager pour suivre les événements de création et de destruction de versions de secrets, ainsi que les événements d'accès aux charges utiles. Routez ces journaux vers Google SecOps pour recevoir des alertes sur les événements d'accès suspects, comme un compte de service compromis accédant à des secrets en dehors des heures d'ouverture standard ou tentant de lire des ressources secrètes non approuvées.

Security Command Center Premium

Security Command Center Premium vous permet de trouver et de corriger les erreurs de configuration de sécurité et les menaces d'exécution actives, y compris les échecs d'identification et d'authentification, dans votre environnement Google Cloudet vos applications Web. Le service Web Security Scanner peut surveiller les failles d'application, y compris les failles XML External Entity (XXE), grâce à des analyses conçues pour couvrir les dix principales commandes OWASP.

S'applique aux éléments suivants :

  • A02 : Erreur de configuration de sécurité
  • A05 : Injection
  • A07 : Échecs d'authentification
  • A08 : Manque d'intégrité des données ou du logiciel

Consultez les bonnes pratiques suivantes pour A02 : mauvaise configuration de la sécurité :

  • Appliquez des frameworks intégrés (tels que les benchmarks CIS ou NIST) à l'aide de Compliance Manager pour évaluer vos configurations cloud par rapport aux frameworks de sécurité réglementaires et aux benchmarks du secteur.
  • Activez Cloud Infrastructure Entitlement Management pour gérer les identités qui ont accès aux ressources de vos déploiements cloud et réduire les failles potentielles liées à des erreurs de configuration.
  • Examinez et corrigez les résultats de Web Security Scanner pour résoudre les problèmes de configuration des en-têtes de sécurité des réponses HTTP, des en-têtes d'origine CORS non valides et de diffusion de contenu mixte.

Consultez les bonnes pratiques suivantes pour A05 : Injection :

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

  • Configurez Web Security Scanner pour qu'il analyse les points de terminaison Web à la recherche de bugs d'exécution basés sur des signatures et génère un résultat STRUTS_INSECURE_DESERIALIZATION de gravité élevée si une application exécute une version vulnérable d'Apache Struts.
  • Corrigez le résultat STRUTS_INSECURE_DESERIALIZATION en mettant à niveau la version de la bibliothèque du framework vulnérable ou en déployant Assured OSS pour récupérer un remplacement vérifié par Google.

Protection des données sensibles

La protection des données sensibles vous permet d'analyser les données potentiellement sensibles stockées dans des buckets, des bases de données, des requêtes d'IA générative ou des charges utiles d'applications de streaming afin d'éviter toute fuite d'informations accidentelle. Si des données non autorisées sont identifiées, Sensitive Data Protection peut les signaler ou les masquer.

S'applique aux éléments suivants :

  • A04 : Défaillances cryptographiques
  • A09 : Carences des systèmes de journalisation et d'alerte de sécurité

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

  • Activez la découverte des données sensibles pour analyser en continu vos ressources de stockage et de base de données, générer des profils de données et générer des métriques pour les rapports d'audit.
  • Utilisez le chiffrement préservant le format, le hachage cryptographique ou la tokenisation basée sur une clé pour anonymiser les données sensibles.
  • Déployez des modèles d'anonymisation réutilisables et gérés de manière centralisée pour appliquer des règles d'inspection et de masquage cryptographique cohérentes dans toutes les équipes de développement.
  • Analysez les charges utiles des requêtes pour éviter que des données d'entreprise sensibles ou des informations permettant d'identifier personnellement les utilisateurs ne soient divulguées dans les pipelines d'entraînement de l'IA générative.

Consultez les bonnes pratiques suivantes pour A09 : Carences des systèmes de journalisation et d'alerte de sécurité :

  • Configurez votre récepteur Logging pour envoyer les journaux d'application à un sujet Pub/Sub. Associez un abonné Cloud Run qui utilise l'API Sensitive Data Protection pour analyser et anonymiser la charge utile du journal avant d'écrire des journaux propres dans votre bucket Logging final.
  • Utilisez des filtres d'exclusion dans vos récepteurs Logging pour n'acheminer que les journaux non structurés à haut risque (tels que les erreurs d'application brutes, les charges utiles d'enregistrement des utilisateurs et les journaux de transactions) via le pipeline de désinfection.

VirusTotal

L'API VirusTotal est une plate-forme de renseignement sur les menaces et d'analyse de fichiers qui analyse les fichiers, URL, domaines et adresses IP suspects pour détecter les logiciels malveillants, les chevaux de Troie et les charges utiles malveillantes. L'intégration de l'API VirusTotal dans les pipelines d'ingestion de fichiers vous permet d'analyser les importations non fiables avant que les fichiers ne soient traités par les systèmes d'application.

S'applique aux éléments suivants :

  • A08 : Manque d'intégrité des données ou du logiciel
  • A05 : Injection

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

Consultez les bonnes pratiques suivantes pour A05 : Injection :

  • Utilisez le module d'analyse privée VirusTotal pour analyser les importations sensibles de manière isolée et ne pas partager les fichiers importés avec des tiers.
  • Implémentez la limitation du débit de l'API et la gestion des exceptions dans votre code d'ingestion pour intercepter les codes d'état HTTP 429 Too Many Requests.

VPC Service Controls

VPC Service Controls vous permet de créer des périmètres autour de vos ressources Google Cloud pour éviter l'exfiltration de données et limiter les attaques par falsification des requêtes côté serveur (SSRF). VPC Service Controls refuse les appels d'API qui franchissent les limites du périmètre, sauf s'ils sont explicitement autorisés par des règles d'entrée et de sortie.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A02 : Erreur de configuration de sécurité

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Incluez les services critiques (tels que Cloud Storage, BigQuery, Spanner et Agent Platform) dans un périmètre de service pour limiter l'accès aux API aux réseaux VPC autorisés et aux identités de confiance.
  • Configurez des règles de périmètre de sortie sur les ressources serverless pour bloquer l'exfiltration de données non autorisée causée par des appels d'API sortants vers des destinations externes hors périmètre.
  • Restreignez l'accès aux API entre les périmètres et les organisations à l'aide de règles d'entrée et de sortie explicites qui spécifient les sources de projet approuvées, les API cibles et les identités de l'appelant.

Consultez les bonnes pratiques suivantes pour A02 : mauvaise configuration de la sécurité :

  • Regroupez les projets dans des périmètres dédiés organisés par niveau de sécurité de l'environnement (par exemple, un périmètre de production). Utilisez les services accessibles par VPC pour limiter les API Google internes qui peuvent être appelées dans le périmètre.
  • Acheminez les requêtes API sortantes des charges de travail sans serveur via le réseau VPC. Configurez les services Cloud Run et les fonctions Cloud Run pour qu'ils utilisent la sortie VPC directe ou un connecteur d'accès au VPC sans serveur avec l'entrée définie strictement sur "interne uniquement".
  • Associez les niveaux d'accès Access Context Manager à vos règles d'entrée de périmètre qui évaluent une combinaison de sous-réseaux IP d'entreprise, de revendications d'identité authentifiées et de signaux d'état de santé des appareils de validation des points de terminaison.
  • Maintenez un processus administratif breakglass préapprouvé pour la réponse aux incidents d'urgence et configurez des alertes de surveillance pour tout événement inattendu de non-respect du périmètre.

Services Wiz

Les sections suivantes décrivent les bonnes pratiques OWASP Top 10 pour les services Wiz qui s'intègrent àGoogle Cloud.

Wiz Code

Wiz Code étend la sécurité du cloud aux workflows des développeurs et aux pipelines CI/CD. Wiz Code corrèle la télémétrie du code au cloud, analyse l'infrastructure en tant que code (IaC), analyse les dépendances (SCA), détecte les identifiants exposés et effectue des tests statiques de sécurité des applications (SAST).

S'applique aux éléments suivants :

  • A03 : Défaillances de la chaîne d'approvisionnement logicielle
  • A05 : Injection
  • A07 : Échecs d'authentification

Consultez les bonnes pratiques suivantes pour A03 : Défaillances de la chaîne d'approvisionnement logicielle :

  • Intégrez la CLI Wiz dans les pipelines CI/CD pour empêcher les requêtes d'extraction de fusionner si elles introduisent des CVE critiques, des secrets exposés ou des erreurs de configuration IaC graves dans les branches protégées.
  • Générez et exportez une SBOM pour chaque compilation afin de maintenir une visibilité continue sur la chaîne d'approvisionnement dans Wiz Cloud.
  • Déployez les extensions Wiz Code IDE pour fournir aux développeurs des commentaires en temps réel, en détectant les packages vulnérables, les clés API codées en dur et les erreurs de syntaxe avant le commit du code.
  • Intégrez Wiz Code à CodeMender dans les pipelines CI/CD pour générer, tester et envoyer des demandes d'extraction lorsque des dépendances tierces vulnérables sont détectées.

Consultez les bonnes pratiques suivantes pour A05 : Injection :

  • Empêchez les requêtes d'extraction de fusionner si l'analyseur SAST détecte des entrées utilisateur non fiables qui sont transmises à des requêtes de base de données ou à des commandes OS sans assainissement approprié.
  • Intégrez le plug-in Wiz Code aux IDE de développement pour fournir des alertes en temps réel si les développeurs saisissent des modèles d'exécution de requêtes SQL ou de commandes non sécurisés ou concaténés.
  • Lorsque Wiz Code signale une faille d'injection, acheminez les traces de flux de données vers CodeMender pour rédiger un correctif de remédiation vérifié.

Consultez les bonnes pratiques suivantes pour A07 : Échecs d'authentification :

  • Implémentez l'analyse automatisée des secrets dans les IDE des développeurs, les hooks de pré-commit locaux et les pipelines CI/CD pour détecter les identifiants exposés.
  • Pour limiter le vol d'identifiants, remplacez les identifiants statiques de longue durée par des jetons dynamiques de courte durée et un accès lié à l'identité (comme la fédération d'identité de charge de travail ou l'authentification basée sur OIDC).
  • Implémentez un playbook de réponse aux incidents automatisé pour supprimer les secrets détectés du code, des variables d'environnement et des journaux de compilation.

Wiz Cloud

Wiz Cloud analyse les environnements multicloud pour identifier les erreurs de configuration de sécurité, les expositions de données sensibles et les risques liés à l'identité. À l'aide du graphe de sécurité Wiz, Wiz Cloud met en corrélation les facteurs de risque dans les différentes couches d'infrastructure pour mettre en évidence les chemins d'attaque critiques.

S'applique aux éléments suivants :

  • A01 : Contrôle d'accès défaillant
  • A02 : Erreur de configuration de sécurité
  • A04 : Défaillances cryptographiques
  • A06 : Conception non sécurisée

Consultez les bonnes pratiques suivantes pour A01 : contrôle d'accès défaillant :

  • Suivez et signalez les chemins d'élévation des privilèges complexes et multihops dans les rôles et les règles IAM pour identifier les points d'accès potentiels des pirates informatiques pour se déplacer latéralement ou élever leurs privilèges.
  • Mappez les autorisations d'accès actives sur les comptes utilisateur, les comptes de service et les agents d'IA aux datastores critiques, et révoquez les droits trop privilégiés.
  • Intégrez les résultats des droits d'identité aux plates-formes d'orchestration pour remplacer les liaisons de rôles administratifs permanentes par un accès juste-à-temps (JAT).
  • Surveillez et visualisez le déplacement des données pour détecter quand des informations permettant d'identifier personnellement l'utilisateur en production sont copiées ou synchronisées dans des environnements de préproduction ou de développement non sécurisés.

Consultez les bonnes pratiques suivantes pour A02 : mauvaise configuration de la sécurité :

  • Évaluez et hiérarchisez les risques de configuration cloud en corrélant les erreurs de configuration avec plusieurs facteurs d'attaque à l'aide de Wiz Security Graph.
  • Appliquez des frameworks de conformité intégrés (tels que le top 10 de l'OWASP, les benchmarks CIS et NIST) pour mesurer les configurations cloud par rapport aux normes du secteur.
  • Intégrez le scanner Wiz CLI aux pipelines CI/CD pour examiner les builds ou corriger les erreurs de configuration IaC avant le déploiement.

Consultez les bonnes pratiques suivantes pour A04 : Défaillances cryptographiques :

  • Priorisez la correction des bases de données et des buckets de stockage contenant des identifiants en texte brut, des clés non hachées ou des données sensibles stockées sans chiffrement.
  • Exécutez la découverte des données Wiz Cloud dans les répertoires d'entraînement de l'IA, les bases de données vectorielles et les pipelines RAG pour vérifier que les données propriétaires et les informations permettant d'identifier personnellement l'utilisateur sont masquées avant l'ingestion par le LLM.
  • Analysez les environnements pour identifier les composants de données non gérés et supprimez les données redondantes afin de minimiser votre surface d'attaque.

Consultez les bonnes pratiques suivantes pour A06 : Conception non sécurisée :

  • Demandez à Wiz Red Agent d'analyser les interfaces architecturales logiques et de simuler des chemins d'attaque pour identifier les failles de conception non sécurisées avant le déploiement en production.
  • Transmettez le contexte validé de la chaîne d'attaque de l'agent Wiz Red à CodeMender pour identifier les causes racines et générer des demandes d'extraction architecturales testées.

Wiz Defend

Wiz Defend fournit des fonctionnalités de détection et de réponse dans le cloud (CDR, Cloud Detection and Response), de protection de l'exécution des charges de travail et de sécurité d'admission Kubernetes. Wiz Defend surveille l'activité du plan de contrôle, détecte les anomalies d'exécution, applique les règles d'admission des conteneurs et déclenche le confinement automatisé.

S'applique aux éléments suivants :

  • A08 : Manque d'intégrité des données ou du logiciel
  • A09 : Carences des systèmes de journalisation et d'alerte de sécurité

Consultez les bonnes pratiques suivantes pour A08 : Manque d'intégrité des données ou du logiciel :

  • Configurez les règles d'admission Wiz Defend pour inspecter et refuser les manifestes de déploiement Kubernetes qui tentent d'exécuter des conteneurs avec des droits racine, de demander des espaces de noms de réseau hôte ou d'activer privileged: true.
  • Configurez des webhooks d'admission de sécurité critiques avec failurePolicy: Fail (fail-closed) en production pour bloquer les conteneurs non fiables si le webhook est inaccessible.

Consultez les bonnes pratiques suivantes pour A09 : Carences des systèmes de journalisation et d'alerte de sécurité :

  • Exportez les journaux d'audit Google Cloud à l'aide d'un récepteur de journaux vers un sujet Pub/Sub afin que Wiz Defend puisse ingérer et analyser les activités du plan de contrôle et les événements de charge de travail.
  • Déployez le capteur Wiz Runtime sur les clusters GKE et les VM Compute Engine à forte valeur ajoutée pour détecter les menaces d'exécution, les exploits en mémoire et les compromissions actives.
  • Automatisez les playbooks de confinement pour désactiver immédiatement les comptes de service IAM piratés ou isoler les charges de travail compromises.
  • Utilisez l'agent Wiz Blue pour examiner les détections d'exécution, en corrélant la télémétrie des processus en direct et le contexte d'identité afin de déterminer les causes premières et les ressources concernées.

Respecter la conformité avec le top 10:2025 de l'OWASP

Wiz inclut un cadre de conformité OWASP Top 10 2025 qui vous permet d'évaluer et de surveiller votre posture. Le framework de conformité OWASP Top 10 2025 mappe les règles Wiz intégrées aux catégories de risques OWASP pertinentes et crée des résultats si un contrôle n'est pas conforme. Vous pouvez suivre votre score de conformité au fil du temps. Si nécessaire, vous pouvez personnaliser le framework de conformité OWASP Top 10 2025 pour répondre aux besoins de votre entreprise.

Étapes suivantes

Consultez le catalogue des bonnes pratiques de sécurité pour en savoir plus.