Dernière mise à jour : 22 mai 2026
Ce document identifie les vecteurs d'attaque potentiels et les stratégies d'atténuation pour la confidentialité, l'intégrité et la disponibilité des données pour Cloud Storage. Le champ d'application de ce rapport est limité à votre perspective. Il se concentre sur les risques que vous pouvez gérer dans votre environnement Cloud Storage.
Ces modèles de menace sont une évaluation probabiliste basée sur les vecteurs d'attaque actuellement connus, les hypothèses architecturales et le champ d'application spécifié du système au moment de la publication. Ces modèles ne sont pas exhaustifs et sont destinés à servir de référence pour les évaluations de sécurité et des risques des clients Google Cloud, ainsi qu'à guider les décisions de réduction des risques.
Les menaces suivantes ont été identifiées pour ce service :
Détails de la menace
Les sections suivantes fournissent des informations sur chaque menace, leurs manifestations et les mesures d'atténuation recommandées.
Divulgation d'informations à l'aide d'une configuration d'accès non sécurisée
Les données sensibles stockées dans des objets Cloud Storage peuvent être exposées à des tiers non autorisés lorsque les contrôles d'accès sont mal configurés. La mauvaise configuration des contrôles d'accès est l'un des problèmes de sécurité cloud les plus courants et les plus graves.
| Catégorie STRIDE |
Divulgation d'informations |
| Tactique MITRE ATT&CK |
Collection |
| Manifestations |
Exposition publique des buckets : un bucket Cloud Storage est rendu public en accordant des rôles tels que Storage Object Viewer aux comptes allUsers ou allAuthenticatedUsers dans sa stratégie d'autorisation IAM. Si la protection contre l'accès public n'est pas appliquée, ces rôles exposent tous les objets à Internet. Fuite d'URL signée : une URL signée, qui sert de jeton de support temporaire, est divulguée par inadvertance via du code côté client, des journaux ou une transmission non sécurisée. Tout utilisateur ou application externe qui obtient l'URL peut accéder à l'objet Cloud Storage spécifié avec les autorisations (par exemple, lecture ou écriture) jusqu'à l'expiration de la signature de l'URL. Autorisations IAM trop larges : des identités, telles qu'un compte utilisateur ou un compte de service, se voient accorder des autorisations étendues (par exemple, storage.objects.get ou storage.objects.list) sur de nombreux buckets alors qu'elles n'ont besoin d'accéder qu'à un petit sous-ensemble de données. Identifiants d'identité compromis : un pirate informatique obtient les identifiants d'un compte utilisateur ou une clé de compte de service, ce qui lui permet de s'authentifier auprès de l'API JSON Cloud Storage et d'accéder à toutes les données que l'identité compromise est autorisée à consulter. Configuration incorrecte de l'équilibreur de charge : une instance Cloud Load Balancing configurée avec un bucket Cloud Storage comme backend peut être mal configurée et exposer publiquement des objets, même si le bucket lui-même n'est pas public. Cette configuration incorrecte crée un chemin d'accès alternatif, potentiellement moins sécurisé, aux données, en contournant les contrôles IAM directs de Cloud Storage. Mise en cache CDN incorrecte : lorsqu'un bucket Cloud Storage est utilisé comme backend pour Cloud Load Balancing et Cloud CDN, une erreur de configuration peut entraîner la mise en cache de données sensibles dans les emplacements périphériques publics de Google. Si le service de backend n'émet pas les en-têtes Cache-Control appropriés (par exemple, "private" ou "no-store"), le CDN peut diffuser le contenu mis en cache à des utilisateurs non autorisés, en contournant les vérifications IAM du bucket.
|
| Mesures d'atténuation |
Appliquez la protection contre l'accès public à des buckets de stockage individuels ou au niveau d'un projet, d'un dossier ou d'une organisation avec la contrainte de règle d'administration storage.publicAccessPrevention. Utilisez l'accès uniforme au niveau du bucket pour simplifier les autorisations et éviter les anciennes LCA. Configurez des clés de chiffrement gérées par le client (CMEK) pour protéger les données avec le chiffrement au repos. Définissez des délais d'expiration aussi courts que possible pour les URL signées. Auditez régulièrement les clés de compte de service compromises ou inutilisées, et supprimez-les. Implémentez VPC Service Controls pour créer un périmètre de service et empêcher l'exfiltration de données, même en cas de vol d'identifiants. Assurez-vous que les règles Cloud Armor sont appliquées aux équilibreurs de charge qui diffusent du contenu Cloud Storage pour restreindre l'accès.
|
Élévation des privilèges à l'aide de configurations IAM incorrectes
Un pirate informatique disposant d'autorisations IAM spécifiques et apparemment inoffensives peut élever ses privilèges pour obtenir un accès plus étendu, y compris un contrôle administratif sur les buckets Cloud Storage et les données qu'ils contiennent. Cette menace contourne la stratégie de sécurité prévue et enfreint le principe du moindre privilège.
| Catégorie STRIDE |
Élévation des privilèges |
| Tactique MITRE ATT&CK |
Élévation des privilèges |
| Manifestations |
Modification directe des stratégies : une identité, telle qu'un utilisateur ou un compte de service, qui dispose de l'autorisation storage.buckets.setIamPolicy sur un bucket Cloud Storage peut modifier directement sa stratégie d'autorisation. Cette configuration permet au pirate informatique de s'attribuer des rôles très privilégiés, tels que Storage Admin, ce qui lui donne un contrôle total sur la configuration et les données du bucket. Emprunt d'identité d'un compte de service : une identité avec un rôle tel que roles/iam.serviceAccountUser contenant l'autorisation iam.serviceAccounts.actAs sur un compte de service peut associer le compte de service à d'autres ressources, telles qu'une instance Compute Engine, pour exécuter du code avec l'identité du compte de service associé. Vous pouvez également utiliser une identité disposant d'un rôle tel que roles/iam.serviceAccountTokenCreator, qui inclut des autorisations telles que iam.serviceAccounts.getAccessToken, pour générer des jetons d'accès pour ce compte de service. Si le compte de service cible dispose d'autorisations élevées sur les ressources Cloud Storage, le pirate informatique hérite de ces privilèges. Génération d'URL signées : une identité disposant de l'autorisation iam.serviceAccounts.signBlob sur un compte de service peut générer des URL signées V4. Ces URL permettent au pirate informatique de créer un accès temporaire avec jeton du porteur aux objets que le compte de service peut lire ou écrire, ce qui peut contourner des contrôles réseau plus restrictifs ou le manque d'autorisations Cloud Storage directes du pirate informatique.
|
| Mesures d'atténuation |
Suivez le principe du moindre privilège. Évitez d'ajouter des autorisations telles que storage.buckets.setIamPolicy, iam.serviceAccounts.actAs ou iam.serviceAccounts.signBlob aux rôles, sauf en cas d'absolue nécessité. Utilisez les conditions IAM pour limiter les autorisations à des ressources ou des périodes spécifiques. Auditez régulièrement les stratégies d'autorisation à l'aide d'outils tels que inventaire des éléments cloud pour détecter et supprimer les autorisations excessives. Assurez-vous que les applications qui gèrent les URL signées ne les enregistrent pas et ne les exposent pas de manière à ce qu'elles puissent être récupérées par des tiers. Par exemple, si vous utilisez Cloud CDN pour mettre en cache des URL signées, définissez des en-têtes Cache-Control appropriés pour éviter la mise en cache publique d'objets sensibles qui doivent être privés et authentifiés via une URL signée.
|
Falsification ou destruction de données à l'aide d'autorisations excessives
Un pirate informatique disposant des autorisations suffisantes peut altérer, corrompre ou supprimer définitivement des données et des configurations dans le système Cloud Storage, ce qui entraîne une perte d'intégrité et de disponibilité des données.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Manipulation directe des objets : une identité disposant des autorisations storage.objects.create ou storage.objects.delete peut écraser ou détruire des objets Cloud Storage individuels. Utilisation abusive des règles de cycle de vie : un pirate informatique disposant de l'autorisation storage.buckets.update peut modifier la configuration de la gestion du cycle de vie des objets d'un bucket pour créer une règle qui supprime tous les objets immédiatement ou après une courte période, ce qui entraîne la destruction massive de données. Suppression de buckets : un pirate informatique disposant de privilèges élevés et de l'autorisation storage.buckets.delete peut supprimer un bucket Cloud Storage entier, détruisant instantanément tous les objets, configurations et règles qui y sont associés. Détournement de notifications : un pirate informatique disposant de l'autorisation storage.buckets.update peut modifier ou supprimer de manière malveillante une configuration de notification Pub/Sub. Cette attaque peut aveugler les systèmes en aval qui s'appuient sur ces événements ou rediriger les notifications vers un sujet contrôlé par un pirate informatique.
|
| Mesures d'atténuation |
Si vous avez besoin d'un stockage immuable ou d'une période de conservation minimale, configurez le verrouillage du bucket pour l'ensemble du bucket ou le verrouillage d'objet pour les objets individuels. Configurez la gestion des versions des objets et une règle de suppression réversible pour planifier la récupération en cas de réécriture accidentelle ou malveillante dans les buckets contenant des données critiques. Implémentez une période de suppression réversible spécifiée qui vous donne suffisamment de temps pour détecter et récupérer les objets avant leur suppression définitive. Activez les journaux d'audit des accès aux données sur les buckets contenant des données critiques pour surveiller les schémas d'accès irréguliers.
|
Exfiltration de données à l'aide de jobs du service de transfert de stockage mal configurés
Un pirate informatique disposant des autorisations storagetransfer.transferjobs.create ou storagetransfer.transferjobs.update peut créer ou modifier un job de service de transfert de stockage pour copier des données d'un bucket Cloud Storage sensible vers un bucket contrôlé par le pirate dans un autre projet. Ce vecteur d'attaque peut être utilisé pour exfiltrer de grands volumes de données de manière silencieuse et continue, en contournant la surveillance typique de l'accès aux données qui peut être axée sur les appels d'API directs comme storage.objects.get.
| Catégorie STRIDE |
Divulgation d'informations |
| Tactique MITRE ATT&CK |
Exfiltration |
| Manifestations |
Création de jobs de transfert malveillants : un pirate informatique disposant des autorisations storagetransfer.transferjobs.create ou storagetransfer.transferjobs.update crée ou modifie un job service de transfert de stockage pour copier des données d'un bucket Cloud Storage sensible vers un bucket contrôlé par le pirate informatique dans un autre projet.
|
| Mesures d'atténuation |
Limitez strictement les autorisations IAM pour storagetransfer.transferjobs.create et storagetransfer.transferjobs.update. N'attribuez ces autorisations qu'aux rôles utilisés par des comptes d'administrateur de confiance. Implémentez un périmètre VPC Service Controls pour limiter la communication entre les services à l'intérieur et à l'extérieur du périmètre. Utilisez des conditions IAM sur les rôles qui accordent des autorisations pour les jobs de transfert afin de limiter les buckets source et de destination à des emplacements connus et autorisés. Surveillez régulièrement Cloud Audit Logs pour détecter la création et la modification de jobs service de transfert de stockage. Configurez des alertes pour tous les jobs qui spécifient une destination non fiable ou externe.
|
Perte d'accès aux données en raison d'une mauvaise gestion des dépendances
Les attaques ou la mauvaise gestion des dépendances de service critiques peuvent refuser l'accès légitime aux données dans Cloud Storage, ce qui les rend inaccessibles même sans compromettre directement le système de stockage lui-même.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Indisponibilité des CMEK : si un bucket Cloud Storage est configuré pour utiliser une CMEK, la désactivation ou la suppression de la clé Cloud KMS sous-jacente rend tous les objets chiffrés avec cette clé cryptographiquement inaccessibles. L'agent de service Cloud Storage ne peut pas effectuer de déchiffrement, ce qui entraîne un déni de service total pour ces données. Verrouillage malveillant du bucket : un pirate informatique disposant des autorisations storage.buckets.update peut appliquer un verrouillage du bucket avec une période de conservation excessivement longue. Ce verrouillage empêche la suppression légitime des données, ce qui peut entraîner une accumulation de coûts importants et inutiles, une forme de déni de service financier.
|
| Mesures d'atténuation |
Mettez en œuvre des stratégies d'autorisation IAM strictes et la séparation des tâches pour l'administration de Cloud KMS. Assurez-vous que les identités autorisées à gérer les buckets Cloud Storage ne sont pas également autorisées à gérer les clés Cloud KMS utilisées par les buckets. Utilisez les mécanismes de prévention de la suppression des clés Cloud KMS. Pour le verrouillage de bucket, contrôlez étroitement l'autorisation storage.buckets.update et utilisez la surveillance pour générer des alertes en cas de modifications de configuration inattendues.
|
Obscurcissement de l'activité en raison d'une observabilité insuffisante
Un pirate informatique peut effectuer des actions malveillantes sur les ressources Cloud Storage sans être détecté si l'audit et la surveillance ne sont pas correctement configurés. Une observabilité insuffisante permet à un pirate informatique de masquer ses traces et empêche une réponse aux incidents et une investigation efficaces.
| Catégorie STRIDE |
Répudiation |
| Tactique MITRE ATT&CK |
Éviction de défense |
| Manifestations |
Journaux d'accès aux données désactivés : les journaux d'activité d'administration sont toujours activés, mais les journaux d'accès aux données, qui enregistrent les lectures et les écritures d'objets, sont désactivés par défaut. Si elle n'est pas explicitement activée, un pirate informatique peut exfiltrer ou falsifier toutes les données d'un bucket sans générer de Cloud Audit Logs pour ces actions, ce qui rend la violation difficile à détecter ou à examiner. Manipulation des récepteurs de journaux : un pirate informatique qui obtient des autorisations suffisantes peut désactiver ou reconfigurer les récepteurs de journaux qui acheminent Cloud Audit Logs, ce qui arrête le flux de données liées à la sécurité vers les systèmes de surveillance. Négligence de la surveillance des métriques : un pirate informatique effectue des activités lentes et discrètes, comme l'exfiltration progressive de petites quantités de données sur une longue période. Ces actions ne déclenchent peut-être pas d'alertes de gravité élevée dans Cloud Audit Logs, mais elles créent des schémas anormaux dans les métriques Cloud Monitoring (par exemple, un trafic sortant soutenu). Si vous ne surveillez pas ces métriques, un pirate informatique pourra plus facilement passer inaperçu.
|
| Mesures d'atténuation |
Activez les journaux d'audit des accès aux données pour tous les buckets contenant des données sensibles ou critiques. Assurez-vous que les journaux sont acheminés vers un projet de journalisation sécurisé et centralisé, avec des autorisations étroitement contrôlées pour empêcher toute falsification des récepteurs de journaux. Configurez des alertes basées sur les journaux dans Cloud Monitoring ou un SIEM pour détecter activement les activités suspectes, telles que les schémas d'accès anormaux ou les modifications apportées aux règles d'autorisation IAM. Créez des alertes basées sur les métriques clés de Cloud Monitoring pour détecter les écarts par rapport au comportement de référence. Utilisez les tableaux de bord Storage Intelligence intégrés et les données d'insights de Data Security Posture Management pour surveiller en continu l'exposition aux risques au niveau des objets et évaluer la stratégie de sécurité.
|
Empoisonnement de la chaîne d'approvisionnement à l'aide d'artefacts piratés stockés dans Cloud Storage
Si un pirate informatique obtient un accès en écriture, tel que storage.objects.create ou storage.objects.delete, à un bucket Cloud Storage utilisé pour stocker des artefacts logiciels (par exemple, des binaires, des images de conteneurs ou des scripts de compilation), il peut remplacer les artefacts légitimes par des versions malveillantes. Les pipelines CI/CD en aval, les développeurs ou les utilisateurs finaux qui font confiance aux artefacts de ce bucket exécuteront involontairement le code piraté, ce qui entraînera une attaque généralisée de la chaîne d'approvisionnement.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Accès initial |
| Manifestations |
Remplacement de fichier binaire : un pirate informatique écrase un fichier binaire ou une bibliothèque de version avec une version trojanisée. Lorsque cet artefact est extrait dans une compilation ou déployé, le code du pirate informatique s'exécute dans l'environnement cible. Empoisonnement d'images de conteneurs : un pirate informatique ayant accès à un bucket utilisé comme backend pour un registre de conteneurs (par exemple, Artifact Registry) peut potentiellement falsifier des calques d'image, en y injectant des failles ou des portes dérobées. Modification du script de compilation : un pirate informatique modifie les scripts de compilation (par exemple, cloudbuild.yaml ou Makefile) stockés dans Cloud Storage pour altérer le processus de compilation lui-même. Un pirate informatique peut modifier les scripts de compilation pour exfiltrer des secrets ou intégrer une porte dérobée lors de la compilation. Empoisonnement de modèle d'IA : un pirate informatique peut remplacer un point de contrôle de modèle valide dans Cloud Storage par un point de contrôle malveillant qui exécute du code lorsqu'il est chargé par un système de production. Un pirate informatique peut également modifier les données d'un bucket Cloud Storage utilisé pour l'entraînement de modèle afin d'insérer des portes dérobées ou des comportements malveillants dans le modèle entraîné.
|
| Mesures d'atténuation |
Utilisez un service de gestion des artefacts dédié, tel qu'Artifact Registry, qui fournit une analyse des failles et un meilleur contrôle des accès. Évitez d'utiliser des buckets Cloud Storage standards pour stocker des artefacts logiciels critiques. Implémentez la signature numérique pour tous les artefacts de compilation. Configurez des pipelines CI/CD pour vérifier la signature d'un artefact avant de le déployer, afin de garantir son intégrité et sa provenance. Configurez la gestion des versions d'objets sur un bucket pour conserver les objets qui ont été écrasés par des données malveillantes.
|
Déni de service basé sur les coûts à l'aide de l'inondation d'objets Cloud Storage ou de l'utilisation abusive de la sortie
Un pirate informatique disposant d'autorisations de création d'objets dans un bucket accessible en écriture publiquement ou mal sécurisé peut importer un grand nombre de petits objets, ce qui entraîne des coûts financiers importants liés aux opérations de classe A et aux frais de stockage. De même, un pirate informatique disposant d'un accès en lecture à un bucket dont l'option "Requester Pays" est désactivée peut télécharger de grands objets à plusieurs reprises, ce qui génère des frais de sortie réseau excessifs et peut avoir un impact sur la disponibilité du service pour les utilisateurs légitimes en raison des limites de facturation.
| Catégorie STRIDE |
Déni de service |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Inondation d'objets : un pirate informatique utilise un script pour créer rapidement des millions de petits objets dans un bucket, ce qui augmente les coûts opérationnels et peut avoir un impact sur les applications qui listent ou traitent le contenu du bucket. Utilisation abusive de la sortie : pour un bucket hébergeant de grands ensembles de données publics, un pirate informatique télécharge des fichiers à plusieurs reprises, ce qui entraîne une perte financière en raison des coûts de bande passante de sortie. Cet usage abusif peut entraîner le dépassement des quotas de facturation du projet, ce qui provoque un déni de service.
|
| Mesures d'atténuation |
Configurez des alertes Cloud Billing pour avertir les administrateurs lorsque les coûts dépassent un seuil budgétaire prédéfini. Vous pourrez ainsi détecter rapidement les dépenses anormales. Pour les buckets accessibles au public, activez les paiements du demandeur. Cette fonctionnalité transfère le coût de l'accès aux données et de la sortie des données à l'utilisateur qui les télécharge, ce qui atténue les attaques basées sur les coûts de sortie contre le propriétaire du bucket. Utilisez Storage Insights pour surveiller l'activité au niveau des objets. Storage Insights offre la visibilité nécessaire pour prévoir les coûts et identifier les objets à fort trafic qui pourraient être la cible d'une utilisation abusive des sorties.
|
Manipulation de l'intégrité des données par utilisation abusive de la gestion des versions des objets Cloud Storage
Bien que la gestion des versions des objets soit une défense essentielle, un pirate informatique disposant des autorisations suffisantes, telles que storage.objects.delete ou storage.objects.create, peut manipuler l'historique des objets pour compromettre l'intégrité des données. Ils peuvent supprimer la version actuelle d'un objet, ce qui fait qu'une version plus ancienne, potentiellement incorrecte ou vulnérable, devient la version "active". Cela peut être utilisé pour rétablir des correctifs de sécurité, réintroduire des bugs ou restaurer des informations obsolètes sans que cela soit immédiatement évident, car l'objet existe toujours.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Rétablissement d'un correctif de sécurité : un pirate informatique supprime la dernière version d'un fichier binaire ou d'un fichier de configuration d'application contenant un correctif de sécurité, ce qui entraîne le rétablissement de la version précédente, vulnérable. Corruption des données par rétablissement : dans un système qui s'appuie sur Cloud Storage pour stocker l'état ou la configuration, un pirate informatique rétablit un objet de configuration critique à un état antérieur, ce qui entraîne des erreurs de configuration du service ou de traitement des données. Manipulation de l'intégrité du modèle d'IA : un pirate informatique peut écraser ou rétablir un point de contrôle de modèle d'IA stocké dans un bucket Cloud Storage.
|
| Mesures d'atténuation |
Développez des applications qui s'appuient sur des versions spécifiques d'objets pour récupérer l'objet par son numéro de génération unique, et pas seulement par son nom. Cela permet de s'assurer que la bonne version est toujours récupérée. Utilisez un verrou de bucket avec une règle de conservation définie pour les données qui nécessitent un stockage immuable. Configurez une règle de suppression réversible pour ajouter une couche de protection supplémentaire contre les suppressions malveillantes. La gestion des versions d'objets ne fournit pas de protection contre les suppressions de buckets.
|
Exfiltration de données à l'aide de pipelines Dataflow déclenchés par Cloud Storage
Si un pipeline Dataflow est configuré pour se déclencher automatiquement lors de la création d'un objet dans un bucket Cloud Storage, un pirate informatique qui peut écrire dans ce bucket peut potentiellement exfiltrer des données. Si le compte de service du job Dataflow est autorisé à accéder à d'autres données sensibles et à écrire dans des emplacements externes (par exemple, un autre bucket Cloud Storage ou BigQuery), le pirate informatique peut créer un fichier d'entrée qui amène le pipeline à lire des données sensibles et à les écrire dans un emplacement contrôlé par le pirate informatique.
| Catégorie STRIDE |
Divulgation d'informations |
| Tactique MITRE ATT&CK |
Exfiltration |
| Manifestations |
Exfiltration inter-projets : un pirate informatique importe un fichier dans un bucket de déclencheur. Le pipeline Dataflow, exécuté avec un compte de service privilégié, lit les données sensibles d'un autre projet et écrit la sortie dans un bucket Cloud Storage public spécifié par le fichier d'entrée de l'auteur de l'attaque.
|
| Mesures d'atténuation |
Encapsulez le pipeline Dataflow et ses dépendances Cloud Storage dans un périmètre VPC Service Controls pour empêcher le pipeline d'envoyer des données vers des destinations externes non autorisées. Appliquez le principe du moindre privilège au compte de service du nœud de calcul Dataflow. Il ne doit disposer que des autorisations spécifiques nécessaires pour lire la source et écrire dans la destination prévue. Activez les journaux d'audit des accès aux données pour les événements DATA_WRITE afin d'auditer les activités suspectes du pipeline Dataflow. Activez l'accès uniforme au niveau du bucket sur votre bucket Cloud Storage pour assurer un contrôle des accès cohérent basé sur IAM.
|
Compromission de l'intégrité par manipulation de l'état IaC dans Cloud Storage
Lorsque vous utilisez des buckets Cloud Storage pour stocker des fichiers d'état IaC (Infrastructure as Code), par exemple le fichier terraform.tfstate dans Terraform, un pirate informatique disposant d'un accès en écriture au bucket d'état peut falsifier le fichier d'état. En modifiant l'état, un pirate informatique peut injecter des ressources malveillantes, modifier des configurations de sécurité critiques ou provoquer la destruction de ressources lors de la prochaine exécution de l'IaC. Cette falsification contourne les processus de revue de code, car l'attaque cible l'état, et non le code lui-même.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Désactivation des contrôles de sécurité : un pirate informatique modifie le fichier d'état pour afficher un état inexact pour une règle de pare-feu ou une stratégie d'autorisation IAM. La prochaine application Terraform risque de ne pas appliquer correctement la configuration sécurisée prévue.
|
| Mesures d'atténuation |
Activez la gestion des versions d'objets dans le bucket Cloud Storage qui stocke le fichier d'état. La gestion des versions des objets vous permet de récupérer le fichier d'état en cas de modification accidentelle ou malveillante. Implémentez des contrôles IAM stricts sur le bucket de fichiers d'état. Assurez-vous que seul le compte de service CI/CD dispose d'un accès en écriture et que les développeurs disposent au maximum d'un accès en lecture seule.
|
Élévation des privilèges pour les scripts de démarrage ou d'amorçage stockés dans Cloud Storage
Si une instance Compute Engine ou un nœud GKE extrait ses scripts de démarrage ou d'amorçage à partir d'un bucket Cloud Storage, un pirate informatique disposant d'un accès en écriture à ce bucket peut modifier ces scripts. Étant donné que ces scripts s'exécutent souvent avec des privilèges élevés (par exemple, en tant que root sur la VM ou avec le compte de service du nœud), le pirate informatique peut injecter des commandes pour créer des utilisateurs de porte dérobée, exfiltrer des métadonnées et des jetons d'accès, ou installer des logiciels malveillants. Ces actions permettent à un pirate informatique d'étendre les privilèges d'autorisation d'écriture d'objets Cloud Storage au contrôle total des ressources de calcul.
| Catégorie STRIDE |
Élévation des privilèges |
| Tactique MITRE ATT&CK |
Élévation des privilèges |
| Manifestations |
Exfiltration de métadonnées : l'attaquant ajoute des commandes telles que curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... au script de démarrage pour voler des jetons de compte de service ou d'autres secrets. Interface système inversée : le pirate informatique injecte une commande pour lancer une interface système inversée à partir de l'instance de calcul vers un serveur contrôlé par le pirate informatique, ce qui lui permet d'y accéder de manière interactive.
|
| Mesures d'atténuation |
Stockez les scripts de démarrage dans un bucket Cloud Storage dédié et étroitement contrôlé. Appliquez des stratégies d'autorisation IAM basées sur le principe du moindre privilège afin que seuls les administrateurs autorisés ou les pipelines CI/CD puissent modifier les scripts. Envisagez une stratégie de classification des données dans laquelle vous configurez des tags de ressources sur les buckets utilisés pour les scripts de démarrage et utilisez l'accès conditionnel basé sur les tags IAM pour restreindre davantage l'accès. Au lieu d'extraire les scripts de Cloud Storage, incluez-les dans des images de machine personnalisées. Cette stratégie crée un artefact immuable moins susceptible d'être modifié au moment de l'exécution.
|
Porte dérobée dans la chaîne d'approvisionnement utilisant des données d'entraînement ML hébergées dans Cloud Storage
Un pirate informatique disposant d'un accès en écriture à un bucket Cloud Storage contenant des données d'entraînement pour un modèle de machine learning peut empoisonner l'ensemble de données. En injectant des données malveillantes soigneusement conçues, le pirate informatique peut créer une porte dérobée dans le modèle entraîné. Cette porte dérobée peut amener le modèle à mal classer des entrées spécifiques d'une manière qui profite à l'auteur de l'attaque, tout en se comportant normalement sur les données générales pour éviter d'être détecté. Par exemple, le modèle peut approuver des transactions frauduleuses ou contourner les contrôles de sécurité.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Classification incorrecte ciblée : un pirate informatique insère des données empoisonnées qui amènent un modèle de détection des fraudes entraîné à toujours classer les transactions d'un compte contrôlé par le pirate comme légitimes. Évasion de modèle : un pirate informatique empoisonne les données d'entraînement d'un modèle de détection de logiciels malveillants avec des exemples de ses logiciels malveillants étiquetés comme bénins, ce qui amène le modèle final à ignorer ses outils spécifiques.
|
| Mesures d'atténuation |
Implémentez des contrôles d'accès stricts sur les buckets Cloud Storage contenant des données d'entraînement. Appliquez le principe du moindre privilège pour accorder l'accès en écriture à ces buckets et effectuez régulièrement des audits à l'aide d'outils tels que Policy Analyzer. Envisagez une stratégie de classification des données dans laquelle vous configurez des tags de ressources sur les buckets utilisés pour les données d'entraînement du ML, et ajoutez des conditions basées sur les tags IAM pour restreindre davantage l'accès. Vérifiez si des modifications non autorisées ont été apportées aux objets utilisés pour les données d'entraînement. Configurez la gestion des versions des objets, conservez les sommes de contrôle et configurez les journaux d'audit d'accès aux données pour l'événement DATA_WRITE afin d'aider à auditer les anomalies pour les événements de création d'objets liés aux données d'entraînement. Auditez et validez régulièrement les modèles de ML pour détecter tout comportement inattendu. Utilisez des techniques de test contradictoires pour détecter les portes dérobées ou les failles cachées introduites lors de l'entraînement. Configurez un périmètre VPC Service Controls pour restreindre l'accès aux ressources sensibles, telles que les données d'entraînement et les autres services impliqués dans la création de modèles, depuis l'extérieur du périmètre approuvé.
|
Déni de service à l'aide de workflows de distribution ramifiée déclenchés par la création d'objets dans Cloud Storage
Si un workflow (par exemple, Cloud Run Functions ou Workflows) est configuré pour déclencher la création d'objets dans un bucket Cloud Storage et effectuer une tâche gourmande en ressources, un pirate informatique disposant de l'autorisation storage.objects.create peut lancer une attaque par déni de service. En important un grand nombre de fichiers en peu de temps (ce que l'on appelle un déclencheur de distribution ramifiée), le pirate informatique peut entraîner une mise à l'échelle rapide du service en aval, ce qui consomme des ressources excessives, atteint les limites de simultanéité ou de scaling, et engendre des coûts importants. En fin de compte, cela entraîne l'indisponibilité du service pour les utilisateurs légitimes.
| Catégorie STRIDE |
Déni de service |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Épuisement des ressources : un pirate informatique importe 10 000 petits fichiers, ce qui déclenche 10 000 invocations de fonctions Cloud Run parallèles qui épuisent le quota de CPU, la mémoire ou les limites de débit des API en aval du projet. Déni de DoS basé sur les coûts : la distribution ramifiée déclenche un nombre massif d'exécutions dans un service payant, ce qui entraîne une facture énorme et une éventuelle suspension du compte, ce qui constitue un déni de service.
|
| Mesures d'atténuation |
Mettez en place des contrôles d'accès stricts sur les buckets Cloud Storage qui déclenchent des workflows. Appliquez le principe du moindre privilège pour accorder l'accès en écriture à ces buckets et effectuez régulièrement des audits à l'aide d'outils tels que Policy Analyzer. Définissez des limites de simultanéité sur les fonctions Cloud Run événementielles pour contrôler le nombre maximal d'exécutions parallèles et éviter l'épuisement des ressources. Implémentez un mécanisme de suppression des rebonds, qui appelle ensuite la logique de traitement principale. Un mécanisme de suppression des rebonds consiste par exemple à ajouter une tâche à une file d'attente Cloud Tasks avec des limites de fréquence. Ce mécanisme permet de gérer les pics soudains de volume de requêtes en les répartissant dans le temps. Configurez un périmètre VPC Service Controls pour restreindre l'accès aux ressources sensibles (par exemple, l'écriture dans un bucket qui déclenche un workflow) depuis l'extérieur du périmètre de confiance.
|
Déplacement non autorisé de données à l'aide de pipelines de sauvegarde basés sur Cloud Storage
Les outils de sauvegarde et de reprise après sinistre utilisent souvent Cloud Storage comme zone de transit ou destination finale pour les sauvegardes. Si un pirate informatique compromet la configuration de cet outil, il peut rediriger les sauvegardes vers un bucket Cloud Storage contrôlé par un pirate informatique. Le compte de service de sauvegarde dispose souvent de droits de lecture étendus sur de nombreuses sources de données (par exemple, des bases de données ou des VM). Cela permet au pirate informatique d'exfiltrer de grands volumes de données sensibles en manipulant le paramètre de destination du job de sauvegarde.
| Catégorie STRIDE |
Divulgation d'informations |
| Tactique MITRE ATT&CK |
Exfiltration |
| Manifestations |
Redirection des jobs de sauvegarde : un pirate informatique disposant des autorisations nécessaires pour modifier la configuration d'un job de sauvegarde remplace le chemin d'accès au bucket Cloud Storage cible par gs://attacker-public-bucket/. Sauvegarde inter-projets : le pirate informatique configure un nouveau job de sauvegarde dans un projet compromis pour lire les données d'une source sensible et les sauvegarder dans un bucket d'un autre projet Google Cloud contrôlé par le pirate.
|
| Mesures d'atténuation |
Assurez-vous que les comptes de service de l'outil de sauvegarde disposent d'autorisations à portée limitée. Configurez les outils de sauvegarde de sorte qu'ils ne puissent écrire que dans des buckets de sauvegarde spécifiques et désignés, et non lire à partir d'emplacements arbitraires. Utilisez VPC Service Controls pour empêcher les services de sauvegarde d'accéder à des sources de données sensibles et d'écrire dans des buckets Cloud Storage en dehors d'un périmètre sécurisé.
|
Contournement des règles à l'aide de l'ancienne utilisation des LCA Cloud Storage dans les environnements hybrides
Cloud Storage est compatible avec deux systèmes de contrôle des accès mutuellement exclusifs : IAM et les anciennes LCA. Lorsque l'accès uniforme au niveau du bucket est désactivé, les deux systèmes sont évalués. Un pirate informatique peut exploiter cette configuration en ajoutant une ancienne LCA (par exemple, en accordant l'accès à un compte Google personnel ou à un groupe public) à un objet, même si la règle d'autorisation au niveau du bucket semble restrictive. Cette attaque crée un chemin d'accès fantôme qui échappe souvent aux scanners de sécurité axés sur IAM, ce qui permet à l'attaquant de contourner les règles de sécurité prévues.
| Catégorie STRIDE |
Élévation des privilèges |
| Tactique MITRE ATT&CK |
Éviction de défense |
| Manifestations |
Accès public au niveau de l'objet : un pirate informatique disposant de l'autorisation storage.objects.update ajoute une LCA "public-read" à un objet sensible, le rendant accessible à tous les internautes et contournant une règle d'autorisation de bucket restrictive. Accès inter-comptes : un pirate informatique attribue à son compte externe l'autorisation OWNER sur un objet de configuration critique à l'aide d'une LCA, ce qui lui permet de modifier l'objet sans être détecté par les audits IAM.
|
| Mesures d'atténuation |
Activez l'accès uniforme au niveau du bucket sur tous les buckets Cloud Storage. L'accès uniforme au niveau du bucket désactive toutes les LCA et garantit qu'IAM est la seule méthode cohérente pour gérer les accès, ce qui simplifie les audits et empêche ce contournement. Utilisez la contrainte de règle d'administration constraints/storage.uniformBucketLevelAccess pour appliquer un accès uniforme au niveau du bucket à tous les nouveaux buckets d'un projet, d'un dossier ou d'une organisation.
|
Destruction de données à l'aide de pipelines CI/CD compromis ciblant Cloud Storage
Les pipelines CI/CD se voient souvent accorder des comptes de service très privilégiés pour gérer l'infrastructure et déployer des artefacts. Si un pirate informatique compromet le système CI/CD, il peut utiliser le compte de service du pipeline pour effectuer des actions destructrices sur Cloud Storage. Par exemple, un pirate informatique peut injecter du code malveillant dans un script de compilation ou accéder à l'orchestrateur. Cette compromission peut impliquer la suppression de buckets ou l'écrasement d'objets critiques.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Étape de compilation malveillante : un pirate informatique ajoute une étape à un pipeline CI/CD qui efface toutes les données. Par exemple, le pirate informatique ajoute une étape dans cloudbuild.yaml qui exécute une commande telle que gcloud storage rm -r gs://critical-bucket/. Héritage des privilèges : le pirate informatique utilise le compte de service compromis du pipeline, qui dispose de nombreuses autorisations, pour accorder à son propre compte un accès administrateur aux buckets Cloud Storage pour une utilisation ultérieure.
|
| Mesures d'atténuation |
Appliquez le principe du moindre privilège aux comptes de service CI/CD. Par exemple, n'accordez pas à un pipeline de compilation les autorisations nécessaires pour supprimer des buckets de production. Utilisez des identités distinctes pour les différentes étapes du pipeline, telles que la compilation, le test ou le déploiement. Protégez les buckets Cloud Storage critiques contre la suppression en activant le verrouillage de bucket ou d'objet, ou en vous assurant que le compte de service CI/CD ne dispose pas de l'autorisation storage.buckets.delete.
|
Suppression non autorisée de buckets à l'aide de comptes "bris de glace" disposant de trop de droits
Les comptes d'accès d'urgence ou "bris de glace" sont des identités à privilèges élevés qui ne sont utilisées qu'en cas d'urgence. Si ces comptes ne sont pas correctement sécurisés et gérés (par exemple, si les identifiants sont divulgués ou si l'accès n'est pas limité dans le temps), un pirate informatique qui parvient à compromettre un compte break-glass peut effectuer des actions très destructrices. Le principal risque est la suppression de buckets Cloud Storage entiers, qui peut entraîner une perte de données catastrophique et irréversible, car la suppression de buckets est une action permanente.
| Catégorie STRIDE |
Élévation des privilèges |
| Tactique MITRE ATT&CK |
Élévation des privilèges |
| Manifestations |
Perte catastrophique de données : un pirate informatique compromet un compte break-glass mal géré et exécute un script pour supprimer tous les buckets Cloud Storage d'un projet. Extorsion : un pirate informatique accède à des buckets critiques et menace de les supprimer à moins qu'une rançon ne lui soit versée.
|
| Mesures d'atténuation |
Mettez en œuvre un accès "juste-à-temps" (JAT) pour les procédures de "bris de glace" au lieu d'utiliser des comptes avec des privilèges permanents. Accorder des autorisations à la demande pour une durée limitée et un objectif spécifique. Appliquez un verrouillage de bucket aux buckets contenant des objets critiques ou un verrouillage d'objet aux objets individuels. Les verrouillages empêchent la suppression du bucket et de ses objets, même par les utilisateurs disposant des autorisations de propriétaire, pendant une période de conservation spécifiée.
|
Exfiltration silencieuse de données à l'aide de récepteurs de journaux piratés écrivant dans Cloud Storage
Vous pouvez configurer Cloud Logging pour exporter les journaux vers un bucket Cloud Storage. Si un pirate informatique obtient l'autorisation de modifier un récepteur de journaux, il peut le reconfigurer pour exporter des journaux sensibles vers un bucket Cloud Storage contrôlé par le pirate dans un autre projet. L'exportation de journaux sensibles permet à un pirate informatique d'exfiltrer silencieusement et en continu les données sensibles capturées dans les journaux.
| Catégorie STRIDE |
Divulgation d'informations |
| Tactique MITRE ATT&CK |
Exfiltration |
| Manifestations |
Redirection du récepteur de journaux : un pirate informatique modifie la propriété de destination d'un récepteur de journaux existant pour qu'elle pointe vers son propre bucket Cloud Storage. Création de filtres malveillants : un pirate informatique crée un récepteur avec un filtre qui cible spécifiquement les journaux contenant des informations sensibles (par exemple, des informations permettant d'identifier personnellement l'utilisateur ou des jetons) et les exporte.
|
| Mesures d'atténuation |
Surveillez les journaux d'audit Cloud pour les appels d'API CreateSink et UpdateSink. Configurez des alertes pour avertir les équipes de sécurité de tout récepteur de journaux nouveau ou modifié afin de vous assurer qu'il est autorisé. Configurez un périmètre VPC Service Controls pour limiter l'exfiltration de données.
|
Activation du ransomware à l'aide de la révocation centralisée des CMEK
Lorsque les buckets Cloud Storage sont chiffrés avec une CMEK, la disponibilité des données est liée à la disponibilité de la clé. Un pirate informatique qui obtient des autorisations suffisantes sur Cloud KMS peut détruire ou désactiver la clé utilisée pour un bucket Cloud Storage critique. Cette action rend toutes les données du bucket cryptographiquement inaccessibles. Il s'agit en fait d'une forme de destruction des données ou de ransomware, car les données restent présentes, mais ne peuvent pas être déchiffrées.
| Catégorie STRIDE |
Falsification |
| Tactique MITRE ATT&CK |
Impact |
| Manifestations |
Destruction de clé : un pirate informatique disposant de l'autorisation cloudkms.cryptoKeyVersions.destroy détruit définitivement une version de clé, ce qui rend la récupération des données impossible. Désactivation de clé : un pirate informatique disposant de l'autorisation cloudkms.cryptoKeyVersions.disable désactive une clé, ce qui rend les données Cloud Storage illisibles jusqu'à ce que la clé soit réactivée. Cette action peut entraîner une interruption prolongée.
|
| Mesures d'atténuation |
Appliquez une durée minimale pour l'état "Destruction programmée" avant que les clés Cloud KMS puissent être détruites. Par défaut, cette période est de 30 jours, mais vous pouvez la configurer sur une durée comprise entre 1 et 120 jours lors de la création d'une clé. Vous ne pouvez pas modifier cette période après la suppression d'une clé. Envisagez d'appliquer la contrainte de règle d'administration constraints/cloudkms.minimumDestroyScheduledDuration pour empêcher la création de clés avec une période de destruction programmée inférieure à votre minimum attendu. Limitez strictement l'accès aux rôles d'administrateur Cloud KMS. Séparez les tâches d'utilisation des clés de celles d'administration des clés pour éviter qu'un seul compte piraté puisse à la fois utiliser et détruire des clés. Effectuez régulièrement la rotation des clés Cloud KMS en choisissant une période de rotation en fonction de la sensibilité ou des exigences de conformité de votre charge de travail.
|
Exfiltration de données à l'aide d'exportations d'instantanés ou de sauvegardes vers Cloud Storage
De nombreux services Google Cloud (par exemple, Compute Engine ou Cloud SQL) permettent de créer des instantanés ou d'exporter des sauvegardes vers Cloud Storage. Un pirate informatique disposant des autorisations nécessaires pour effectuer ces opérations d'exportation peut créer un instantané d'une ressource contenant des données sensibles et l'enregistrer dans un bucket Cloud Storage avec des autorisations laxistes, comme un bucket public ou un bucket partagé avec un compte externe. Cette action contourne les contrôles d'accès plus stricts de la ressource principale (par exemple, les identifiants de base de données), car les données sont désormais accessibles à l'aide de Cloud Storage IAM.
| Catégorie STRIDE |
Divulgation d'informations |
| Tactique MITRE ATT&CK |
Exfiltration |
| Manifestations |
Instantané de disque vers un bucket public : un développeur interne disposant des autorisations compute.snapshots.create et storage.objectAdmin crée un instantané d'un disque de VM contenant des secrets et l'exporte vers un bucket Cloud Storage public. Exportation de la base de données : un pirate informatique disposant de l'autorisation cloudsql.instances.export exporte une base de données de production vers un bucket Cloud Storage dans un projet contrôlé par le pirate.
|
| Mesures d'atténuation |
Assurez-vous que les projets désignés pour les sauvegardes et les instantanés disposent de règles IAM et VPC Service Controls au moins aussi strictes que celles des projets sources afin de maintenir une posture de sécurité cohérente. Envisagez une stratégie de classification des données dans laquelle vous configurez des tags de ressources sur les buckets utilisés pour les sauvegardes et ajoutez des conditions d'accès basées sur les tags IAM pour restreindre davantage l'accès.
|
