Quotas cloud contre le déni de service par coût

Le déni de service par coût (cost-based denial of service, CDoS) transforme une permission cloud légitime en facture toxique. Les quotas, budgets et limites de débit ne remplacent ni l’identité ni la détection, mais ils bornent le rayon d’explosion quand un compte, une clé ou une fonction automatisée dérape.

→ Lire l’explication complète de la marmotte

Modèle de menace du déni de service par coût

Un CDoS survient lorsqu’un attaquant provoque une consommation facturable sans nécessairement interrompre le service. Une clé d’accès exposée peut lancer des instances de calcul, créer des volumes, provisionner des adresses réseau payantes ou extraire massivement des données. Une application publique peut aussi être forcée à déclencher des traitements coûteux : conversion vidéo, génération d’image, requêtes analytiques, appels à un modèle d’intelligence artificielle ou lectures répétées d’objets distants.

L’attaquant cherche le multiplicateur. Une requête HTTP (Hypertext Transfer Protocol) de quelques octets peut provoquer plusieurs secondes de calcul, une extraction de données et une sortie réseau. Le mécanisme le plus rentable n’est pas toujours spectaculaire. Une boucle de réessais sur une file de messages, un déclencheur qui se réinvoque, ou une règle d’autoscaling mal bornée suffit. Le cloud facture avec une régularité presque poétique, y compris les bugs.

Il faut distinguer trois surfaces :

Le plan de contrôle : création, modification ou suppression de ressources via une interface de programmation ou une console. Une identité compromise y crée directement de la consommation.
Le plan de données : lectures, écritures, requêtes, transferts réseau et appels applicatifs. Une identité peut rester parfaitement légitime et devenir néanmoins coûteuse.
Le plan d’exécution : machines virtuelles, conteneurs, fonctions et tâches asynchrones. L’automatisation amplifie les demandes avant que l’alarme ne sonne.

Les protections d’identité restent la première barrière. Une clé longue durée ne doit pas disposer de droits d’administration, et une charge de travail doit recevoir une identité éphémère avec un périmètre minimal. La page IAM cloud couvre cette séparation. Mais l’IAM (Identity and Access Management) répond à « qui peut créer ? », pas à « combien peut être créé avant que le compte ne brûle ». Les deux questions doivent avoir une réponse distincte.

Quotas de service et limites d’architecture

Un quota de service fixe un maximum sur une catégorie de ressources : nombre d’instances, nombre de processeurs virtuels, volumes, adresses publiques, travaux simultanés ou capacité réservée. Une limite d’architecture fixe un maximum choisi par l’équipe : taille maximale d’un cluster, concurrence maximale d’une fonction, nombre de partitions consommées, débit sortant ou durée d’un traitement.

Le compromis central est brutal : un plafond bas réduit la perte financière maximale, mais augmente le risque de saturation lors d’un pic légitime ou d’une reprise. La recommandation est de préférer un refus contrôlé à une croissance illimitée, sauf pour les composants dont l’indisponibilité immédiate crée un dommage supérieur au budget d’incident. Dans ce dernier cas, conserver un plafond élevé, mais isoler le périmètre dans un compte ou un projet dédié avec son propre budget et ses propres alertes.

Les quotas globaux sont insuffisants. Un quota régional laisse souvent créer les mêmes ressources dans une autre région, et un quota par abonnement ne limite pas un portefeuille multi-comptes. La structure de comptes doit donc suivre les frontières de risque : production, développement, expérimentation, données sensibles et traitements élastiques ne partagent pas le même plafond. Le découpage proposé dans l’architecture cloud doit servir aussi à contenir la dépense, pas seulement à organiser les diapositives.

Fixer un quota exige de partir de la capacité nominale, puis d’ajouter une marge de reprise connue. Pour un service qui requiert 40 unités de calcul en pointe et 20 unités supplémentaires pendant un basculement, un quota de 60 est cohérent. Un quota de 500 « au cas où » annule la mesure. Une réserve sans scénario de consommation est juste une permission permanente avec une moustache.

Les mécanismes à borner en priorité sont ceux qui combinent création rapide et facturation variable :

instances de calcul à accélérateur graphique ou à forte mémoire ;
fonctions sans limite de concurrence ni durée maximale ;
clusters de conteneurs avec autoscaling horizontal ;
bases analytiques facturées au volume scanné ;
transfert sortant vers Internet ou vers une autre région ;
stockage d’objets sans règle de cycle de vie ;
journaux très verbeux exportés sans rétention ;
passerelles de traduction réseau, équilibreurs et adresses publiques laissés orphelins.

Un quota ne garantit pas que la facture restera sous un montant donné. Les ressources déjà créées peuvent continuer à consommer, certains produits sont facturés hors quota, et les frais de transfert ou de support peuvent échapper au modèle attendu. Le plafond de ressource limite une quantité technique, pas la comptabilité complète.

Budgets, alertes et coupure contrôlée

Un budget compare les coûts observés ou prévus à un seuil monétaire. Il détecte une dérive, mais ne bloque généralement rien par lui-même. Le traiter comme un disjoncteur est une erreur classique : l’alerte arrive après collecte, agrégation et parfois retard de facturation. Entre-temps, une charge élastique peut avoir fait des choses très créatives avec une carte de crédit.

Utiliser trois seuils par périmètre de facturation :

50 % : signal à l’équipe propriétaire, sans automatisation destructrice ;
80 % : création d’un incident et gel des déploiements non critiques ;
95 % : exécution d’une action préparée, par exemple réduction de la concurrence, suspension d’un environnement non productif ou blocage d’une route d’API.

L’action automatique doit être réversible, testée et limitée. Désactiver tout le compte à 95 % peut empêcher la collecte des journaux, la réponse à incident ou les sauvegardes. Couper un environnement de développement isolé est souvent acceptable. Couper le système de paiement parce qu’un tableau de bord a paniqué l’est beaucoup moins.

Les alertes doivent surveiller aussi les unités techniques qui précèdent le coût : créations d’instances, erreurs d’autorisation, appels d’API (Application Programming Interface) inhabituels, concurrence des fonctions, volume de sortie, profondeur de file et taux de réessais. Le coût est un indicateur retardé. Le débit et la création de ressources sont les signaux précoces.

Conserver les journaux du plan de contrôle dans un compte ou projet de sécurité distinct, avec une rétention définie. Sans ces traces, il devient impossible de distinguer une erreur d’automatisation, une fuite de secret et une attaque externe. La supervision ne remplace pas la prévention, mais l’absence de supervision transforme chaque facture en roman policier sans dernier chapitre.

Exemple Terraform de garde-fous AWS

L’exemple suivant associe une limite de concurrence à une fonction AWS Lambda et une alarme sur le nombre d’invocations. Terraform doit être exécuté avec un rôle autorisé à gérer Lambda, CloudWatch et les budgets. Le budget AWS reste une alerte, la limite Lambda est le frein effectif sur l’exécution simultanée.

# Empêche une fonction Lambda de démarrer plus de 25 exécutions simultanées.
# Prévoir cette valeur dans le dimensionnement du service, pas au lancer de dés.
resource "aws_lambda_function" "conversion" {
  function_name = "conversion-bornée"
  role          = aws_iam_role.lambda.arn
  runtime       = "python3.12"
  handler       = "handler.main"
  filename      = "lambda.zip"

  reserved_concurrent_executions = 25
}

# Déclenche une alarme avant que le coût ne soit visible sur la facture.
resource "aws_cloudwatch_metric_alarm" "invocations_anormales" {
  alarm_name          = "conversion-invocations-anormales"
  namespace           = "AWS/Lambda"
  metric_name         = "Invocations"
  statistic           = "Sum"
  period              = 300
  evaluation_periods  = 1
  threshold           = 5000
  comparison_operator = "GreaterThanThreshold"

  dimensions = {
    FunctionName = aws_lambda_function.conversion.function_name
  }
}

La limite réservée réduit la capacité disponible pour les autres fonctions du compte AWS (Amazon Web Services) si elle est mal répartie. L’isolation par compte reste préférable pour les traitements à risque élevé. Tester également le comportement applicatif au refus : file d’attente, réponse HTTP 429, reprise avec délai et limite de tentatives. Sans cela, le mécanisme de protection peut devenir une usine à réessais, ce qui est une manière très moderne de payer pour refuser du trafic.

Exploitation des limites, secrets et reprise

Les quotas doivent être décrits comme du code ou inventoriés dans une configuration contrôlée. Les changements manuels en urgence sont parfois nécessaires, mais ils doivent être réconciliés ensuite. Sinon, le prochain déploiement rétablit une valeur ancienne ou masque un dépassement de privilège.

Une augmentation de quota doit passer par une demande liée à une capacité attendue, une durée et un propriétaire. Pour les événements ponctuels, programmer le retour au plafond normal. Les hausses temporaires deviennent permanentes avec une constance qui ferait rougir les mauvaises résolutions de janvier.

Les identités d’automatisation qui modifient les quotas, budgets ou règles de mise à l’échelle sont sensibles. Séparer le rôle de déploiement du rôle de gouvernance financière. Exiger une authentification multifacteur pour les accès humains et des informations d’identification courtes pour les automatisations. La gestion des secrets, leur rotation et leur journalisation relèvent des mêmes exigences que le reste de l’infrastructure, détaillées dans les ressources de sécurité.

Prévoir une procédure de reprise : qui autorise une hausse, quel seuil déclenche l’escalade, quels services peuvent être dégradés, et comment vérifier que l’augmentation n’a pas ouvert une dérive supplémentaire. Mesurer le délai entre alerte, décision et effet réel. Un budget sans canal d’astreinte ni actionneur n’est qu’une décoration comptable.

🐝 Ce qui arrive si on s’en passe

Sans plafond propre au service, une fonction emballée consomme le réservoir de concurrence commun au compte : les autres fonctions, y compris celles de production, reçoivent alors des refus d’exécution alors qu’elles ne sont pas en cause, et le déni de service devient réel en plus d’être financier. Une identité compromise dispose de toute la marge des limites par défaut du fournisseur, que l’attaquant peut remplir d’instances de calcul pour du minage dans des régions jamais utilisées ; ces ressources continuent de facturer après la révocation de la clé tant qu’un inventaire région par région ne les a pas retrouvées. Enfin, une facture hors de proportion ou une activité détectée comme abusive peut conduire le fournisseur à restreindre ou suspendre le compte, ce qui coupe aussi les services légitimes pendant la contestation.

🦫 Explication de la marmotte 🍫

Un service cloud facture selon ce qui est utilisé : puissance de calcul, espace de stockage, données envoyées vers Internet, nombre de demandes ou durée d’exécution. Une personne malveillante, un programme mal configuré ou une clé d’accès volée peut donc provoquer une grande dépense sans forcément voler de données ni arrêter le service.

La protection commence par limiter les droits : chaque programme reçoit seulement les autorisations nécessaires. Ensuite, on fixe des plafonds techniques. Ils empêchent de créer trop de machines, de lancer trop de tâches en même temps ou de garder un traitement actif trop longtemps. Ces plafonds doivent être choisis à partir du besoin normal et de la capacité nécessaire en cas de panne.

On ajoute des seuils de dépense et des alertes. Ils avertissent quand le coût monte, mais ils ne bloquent pas forcément la consommation. Il faut donc surveiller aussi les signes précoces : trop de créations de machines, trop de demandes, trop de données envoyées ou trop de nouvelles tentatives après un échec.

Quand un seuil est dépassé, une action préparée peut réduire la capacité, suspendre un environnement secondaire ou bloquer une fonction coûteuse. Cette action doit être testée, car arrêter sans réflexion peut aussi empêcher les sauvegardes ou la réparation. Enfin, les plafonds, alertes et droits doivent être revus régulièrement : une limite oubliée après une hausse temporaire cesse de protéger, même si elle apparaît encore dans un document.

Pages voisines

La citent

Quotas cloud contre le déni de service par coût

Elle cite

: les deux pages se citent l’une l’autre.

Quotas cloud contre le déni de service par coût

Quotas cloud contre le déni de service par coût

Modèle de menace du déni de service par coût

Quotas de service et limites d’architecture

Budgets, alertes et coupure contrôlée

Exemple Terraform de garde-fous AWS

Exploitation des limites, secrets et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines