Comment gouverner les coûts cloud contre un compte compromis

Un compte cloud compromis peut créer des ressources facturées avant que la détection de sécurité ne produise un signal exploitable. La gouvernance des coûts ne bloque pas l’attaque, mais elle réduit la durée pendant laquelle un attaquant peut transformer des identifiants volés en dette financière. Ce n’est pas un sujet FinOps décoratif : c’est une limite de blast radius, au même titre que la segmentation d’identité.

→ Lire l’explication complète de la marmotte

Coût cloud et compromission d’identité

La chaîne d’attaque est banale : vol d’un jeton d’accès, compromission d’un compte de service, clé exposée dans un dépôt ou session fédérée détournée. L’attaquant crée ensuite des instances de calcul, des volumes de stockage, des adresses réseau, des services d’analyse ou des transferts sortants. Les ressources sont légitimes au regard du plan de contrôle : elles ont été créées avec une identité autorisée. Le fournisseur cloud facture donc avec une ponctualité remarquable, contrairement à certaines alertes de sécurité qui préfèrent méditer sur leur niveau de confiance.

La gestion des coûts doit donc être placée dans le modèle de détection d’incident. Une variation de dépense est un indicateur faible : elle ne prouve pas une compromission. En revanche, combinée à une création de ressource inhabituelle, un usage depuis une localisation inattendue ou une élévation de privilège, elle permet de prioriser une enquête avant que la facture ne devienne un incident de trésorerie.

La distinction avec les quotas et limites de ressources est essentielle. Un quota est un garde-fou préventif qui refuse une création au-delà d’une capacité définie. Une alerte de coût est un contrôle détectif, souvent retardé par les cycles de consolidation de consommation. Les deux se complètent, mais aucun budget ne doit être présenté comme une barrière anti-abus. Une alerte reçue après plusieurs heures ne rembobine pas les ressources déjà consommées. La comptabilité n’a pas de bouton « undo », malgré ce que promettent certaines slides FinOps.

Le compromis central est net : augmenter la finesse d’attribution et la fréquence d’analyse réduit le délai de détection, mais impose des tags, des comptes de facturation structurés, des exports de données et une astreinte capable d’interpréter les alertes. La recommandation est de payer ce coût d’exploitation pour les environnements exposés, les comptes de production et les identités capables de créer du calcul ou du réseau. Pour un bac à sable sans accès aux données ni à la connectivité externe, un contrôle quotidien suffit généralement.

Attribution des dépenses et frontières IAM

L’attribution commence par le découpage des comptes, abonnements ou projets de facturation. Un compte de production ne doit pas partager sa frontière de facturation avec des laboratoires, des tests de charge ou de l’expérimentation. Cette séparation facilite l’analyse, limite les permissions transverses et permet un arrêt d’urgence sans interrompre l’ensemble du système d’information.

Les étiquettes de coût ne constituent pas une frontière de sécurité. Un acteur disposant du droit de créer une ressource peut parfois choisir, modifier ou omettre ses étiquettes. Une politique qui dépend d’un tag modifiable par le créateur est une convention, pas un contrôle. Les tags servent à attribuer et investiguer. Les règles d’autorisation servent à empêcher.

L’IAM (Identity and Access Management) doit interdire la création de ressources coûteuses aux identités qui n’en ont pas besoin. Cela inclut les familles de calcul accéléré, les capacités réservées, les passerelles réseau à débit élevé, les services de traitement de données et les régions non exploitées. Les permissions doivent être accordées par type de ressource, région, taille et réseau cible, pas seulement par action générique de création.

Une politique d’accès efficace impose aussi des attributs à la création : propriétaire technique, centre de coût, environnement et date d’expiration. Ces attributs doivent être contrôlés côté politique, puis verrouillés contre la modification par les rôles d’exécution. Sans cela, l’inventaire perd sa valeur dès la première automatisation pressée, souvent baptisée « plateforme autonome » après trois fichiers YAML.

La page sur les identités cloud et IAM complète ce dispositif : les droits de création, de délégation et d’accès aux données de facturation doivent être revus comme des privilèges sensibles. Lire les coûts peut révéler l’activité, les produits utilisés et parfois la structure d’un service. Écrire les budgets ou les alertes permet de masquer une attaque. Ces droits n’appartiennent pas au même rôle.

Alertes de coût et corrélation de sécurité

Trois niveaux d’alerte sont nécessaires :

Budget planifié : alerte quand une enveloppe mensuelle ou journalière est dépassée. Elle détecte une dérive connue, mais réagit mal à une attaque rapide en début de période.
Anomalie de consommation : comparaison avec un historique, par service, compte, région ou tag. Elle est plus adaptée à la fraude, mais nécessite un historique propre et génère des faux positifs après un changement légitime.
Événement de création : journalisation en temps proche du réel des créations, suppressions de protections, modifications de facturation et changements de rôle. C’est le signal de réponse le plus rapide.

L’alerte de coût doit contenir le périmètre facturé, la période observée, le service concerné, l’identité de création et un lien vers les événements de contrôle associés. Envoyer seulement « budget dépassé » dans une messagerie d’astreinte revient à déposer un morceau de puzzle sous la porte et à appeler cela de la détection.

La corrélation s’appuie sur les journaux d’API (Application Programming Interface), les journaux d’authentification et les données de facturation exportées. Un SIEM (Security Information and Event Management) peut rapprocher ces sources, mais le retard de disponibilité des coûts doit être documenté. Si la donnée de coût arrive toutes les douze heures, le scénario de réponse doit utiliser les événements de création pour agir immédiatement et les coûts pour confirmer la gravité.

Une règle de détection raisonnable cherche par exemple : création de calcul hors région approuvée, par une identité rarement active, suivie d’une hausse anormale du coût prévisionnel. Chaque condition seule produit du bruit. Leur combinaison produit un incident à traiter. Les seuils statiques globaux sont fragiles : une dépense normale pour une plateforme de données peut être catastrophique pour un service applicatif.

Exemple AWS : budget quotidien et alerte de seuil

L’exemple suivant crée un budget quotidien Amazon Web Services (AWS) avec deux seuils. Il exige AWS CLI version 2, un compte où les alertes de facturation sont activées, l’autorisation budgets:CreateBudget et une adresse de notification vérifiée ou un canal de notification déjà gouverné. La valeur est exprimée en dollars américains, car l’API Budgets attend cette devise dans cet exemple.

# Récupérer le compte AWS ciblé par les identifiants courants.
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

# Créer un budget de coût quotidien et avertir à 80 % puis à 100 %.
aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget '{
    "BudgetName": "security-daily-spend-guardrail",
    "BudgetLimit": {"Amount": "250", "Unit": "USD"},
    "TimeUnit": "DAILY",
    "BudgetType": "COST",
    "CostFilters": {"TagKeyValue": ["user:environment$production"]}
  }' \
  --notifications-with-subscribers '[
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "security-operations@example.net"}
      ]
    },
    {
      "Notification": {
        "NotificationType": "FORECASTED",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 100,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "security-operations@example.net"}
      ]
    }
  ]'

Ce budget ne déclenche aucune action de confinement. Une action automatique mal conçue peut supprimer des ressources critiques lors d’un pic légitime, puis transformer un incident financier en indisponibilité. L’automatisation de blocage est justifiée uniquement si le périmètre est jetable, l’impact métier accepté, le mécanisme testé et une liste d’exceptions revue. Pour la production, la première action automatisée doit plutôt être la révocation ou la suspension de l’identité suspecte, après corrélation avec les événements de sécurité.

Réponse à incident, rotation et reprise

Une alerte de coût doit ouvrir un processus de réponse avec un propriétaire désigné. La séquence est : identifier l’identité, lister les ressources créées, préserver les journaux, bloquer les permissions de création, révoquer les sessions et secrets concernés, puis supprimer les ressources après qualification. Supprimer avant de collecter les éléments nécessaires peut effacer la chronologie et empêcher de déterminer si des données ont été exfiltrées.

Les clés d’accès longues durées sont le cas le plus dangereux. Leur rotation doit être automatisée, contrôlée et suivie par une alerte sur toute clé inactive ou non utilisée. Les rôles temporaires réduisent la fenêtre d’exploitation, mais ne remplacent pas la surveillance : un jeton valide pendant une heure peut suffire à lancer une infrastructure coûteuse. La MFA (Multi-Factor Authentication) doit protéger les comptes humains disposant de privilèges de facturation ou d’administration.

Les sauvegardes de configuration comptent aussi. Les budgets, exportations, alertes, politiques IAM et règles de corrélation doivent être gérés en IaC (Infrastructure as Code), versionnés et restaurables. Une suppression malveillante d’alerte est un événement de sécurité. Sans export de configuration ni journal d’administration immuable, il reste seulement une facture et de très mauvaises hypothèses.

Ce mécanisme ne garantit pas la prévention de l’exfiltration, du chiffrement malveillant de données, de l’usurpation d’identité ou de la fraude effectuée sous le seuil d’alerte. Il ne remplace ni la segmentation réseau, ni les permissions minimales, ni la supervision des accès aux données. Les principes d’architecture cyber restent la source des contrôles qui réduisent la probabilité de compromission ; la gouvernance des coûts réduit surtout le temps et l’argent disponibles pour l’attaquant.

🐝 Ce qui arrive si on s’en passe

Sans gouvernance des coûts reliée à la détection, un compte compromis transforme des identifiants volés en dette financière avant qu’une alerte de sécurité ne produise un signal exploitable. L’attaquant crée des instances de calcul, des volumes, des passerelles à débit élevé ou des transferts sortants, toutes légitimes au regard du plan de contrôle puisque créées avec une identité autorisée : le fournisseur facture avec ponctualité pendant que l’enquête médite sur son niveau de confiance. Sans séparation des frontières de facturation, impossible de couper un périmètre en urgence sans interrompre le reste. Sans restriction IAM sur la création de ressources coûteuses, n’importe quelle identité peut engager du calcul accéléré ou des capacités réservées. Une alerte reçue après plusieurs heures ne rembobine aucune ressource déjà consommée, et un droit d’écriture sur les budgets permet même de masquer l’attaque en cours.

🦫 Explication de la marmotte 🍫

Un compte cloud permet de demander des ressources informatiques à un fournisseur : puissance de calcul, espace de stockage, réseau ou services spécialisés. Chaque demande est enregistrée et facturée. Si une personne malveillante obtient les accès d’un compte, elle peut commander ces ressources au nom de l’organisation. Le fournisseur ne sait pas automatiquement que la demande est frauduleuse, car elle utilise un accès valide.

La protection commence avant l’incident : séparer les environnements, limiter les droits de chaque compte et interdire certaines ressources coûteuses aux identités qui n’en ont pas besoin. Des informations sont ajoutées à chaque ressource pour savoir quel service, quelle équipe et quel environnement ont causé la dépense. Ces informations aident à retrouver rapidement l’origine d’une hausse.

Ensuite, les dépenses sont mesurées régulièrement. Des alertes signalent un dépassement prévu, une dépense inhabituelle ou la création d’une ressource dans un endroit inattendu. Ces alertes doivent être comparées aux journaux qui indiquent quel compte a créé quoi et à quel moment.

Quand une alerte paraît suspecte, il faut suspendre l’accès concerné, conserver les traces, examiner les ressources créées puis les supprimer si elles sont frauduleuses. Les mots de passe, clés et accès temporaires doivent aussi être remplacés. Si les alertes sont supprimées, mal configurées ou trop lentes, la dépense continue jusqu’à une détection humaine ou jusqu’à la limite imposée par le fournisseur.

Pages voisines

La citent

Comment gouverner les coûts cloud contre un compte compromis

Elle cite

Comment gouverner les coûts cloud contre un compte compromis

Comment gouverner les coûts cloud contre un compte compromis

Coût cloud et compromission d’identité

Attribution des dépenses et frontières IAM

Alertes de coût et corrélation de sécurité

Exemple AWS : budget quotidien et alerte de seuil

Réponse à incident, rotation et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines