Gérer une crise cloud multi-tenant
Gérer une crise cloud multi-tenant
Section intitulée « Gérer une crise cloud multi-tenant »Un incident chez un autre client d’un fournisseur cloud peut dégrader ou interrompre un service sans qu’aucune erreur de configuration ne soit présente côté application. La difficulté n’est pas de prouver son innocence technique, mais de détecter la dépendance commune, limiter le rayon d’impact et piloter une reprise dont le calendrier dépend partiellement d’un tiers.
→ Lire l’explication complète de la marmotte
Incident multi-tenant : dépendance partagée et compromis assumé
Section intitulée « Incident multi-tenant : dépendance partagée et compromis assumé »Un environnement multi-tenant héberge plusieurs clients sur une infrastructure, un plan de contrôle ou des services mutualisés. Cette mutualisation concerne parfois le calcul, mais surtout les briques les plus difficiles à isoler : résolution de noms, stockage objet, gestion des identités, limitation de débit, réseau virtuel, bases managées et interfaces de programmation applicative.
Le compromis est net : on gagne une vitesse de déploiement, une capacité élastique et une exploitation industrialisée ; on paie une dépendance à des ressources communes dont l’état réel reste partiellement opaque. Ce compromis est acceptable pour la majorité des charges, à une condition : l’architecture doit prévoir qu’une panne provoquée par un autre locataire peut affecter le service local.
La recommandation est de traiter le fournisseur comme une dépendance externe à défaillance corrélée, même si le contrat annonce des zones indépendantes. Deux zones de disponibilité du même fournisseur réduisent les pannes matérielles locales. Elles ne séparent pas nécessairement un service de gestion d’identités, une limite de débit globale, un certificat de plateforme, une erreur de plan de contrôle ou une saturation du réseau dorsal. La haute disponibilité à coups de logo de régions sur une slide reste une religion assez répandue. Elle ne remplace pas l’analyse des dépendances.
Un objectif de niveau de service, ou SLO (Service Level Objective), doit donc distinguer les indisponibilités applicatives des indisponibilités de fournisseur. Cette séparation évite de conclure à tort qu’un service respecte son objectif parce que le fournisseur calcule sa disponibilité selon une autre frontière, souvent plus flatteuse pour ses brochures.
La cartographie doit identifier, pour chaque chemin métier critique :
- le fournisseur, la région et la zone de disponibilité ;
- les interfaces de programmation applicative, ou API (Application Programming Interface), appelées au démarrage et en fonctionnement ;
- les limites de débit par compte, projet, adresse réseau ou identité ;
- les services mutualisés nécessaires à l’authentification, au chiffrement et à la résolution de noms ;
- les dépendances hors région, notamment les annuaires, les journaux, les registres d’images et les services de support ;
- le mécanisme de bascule et son prérequis d’autorisation.
La page architecture cloud aide à poser cette frontière de responsabilité. La séparation des privilèges et des comptes d’urgence relève aussi de la gestion des identités cloud.
Détection de la dégradation et qualification de la cause externe
Section intitulée « Détection de la dégradation et qualification de la cause externe »Un incident multi-tenant commence rarement avec un message explicite du fournisseur. Les premiers symptômes sont plus mesquins : hausse de latence, erreurs 429 de limitation de débit, erreurs 503 de saturation, délais d’allocation, échecs intermittents de résolution de noms ou opérations d’administration bloquées alors que les flux applicatifs existants fonctionnent encore.
La supervision doit tester le service depuis plusieurs emplacements et à plusieurs niveaux. Un contrôle synthétique externe détecte l’accessibilité publique. Une sonde interne détecte les ruptures de réseau privé. Une transaction métier vérifie le chemin complet, identité comprise. Les trois résultats ne sont pas interchangeables : un équilibreur de charge peut répondre correctement alors que l’émission d’un jeton d’accès est indisponible.
Conserver les preuves brutes est une obligation opérationnelle, pas une lubie d’auditeur : horodatage synchronisé, identifiant de requête fournisseur, code d’erreur, région ciblée, adresse résolue et latence. Sans ces éléments, la qualification dérive vite vers la chasse au fantôme dans les règles pare-feu. Vingt ans de production apprennent que le journal décisif expire toujours avant la réunion où quelqu’un demande pourquoi il n’a pas été conservé.
L’horloge doit être synchronisée par Network Time Protocol, ou NTP, avec au moins deux sources indépendantes. Une dérive de quelques minutes suffit à confondre un jeton expiré, une signature refusée et une indisponibilité du fournisseur. Les journaux doivent partir vers un stockage distinct du compte ou du projet affecté. Sinon, l’incident efface précisément le thermomètre qui permettait de le mesurer.
La qualification suit un ordre strict :
- vérifier l’état des dépendances internes et les changements récents ;
- comparer plusieurs régions ou fournisseurs si l’architecture le permet ;
- vérifier les annonces publiques du fournisseur, sans les prendre pour un oracle immédiat ;
- chercher une corrélation entre clients, comptes ou services différents ;
- ouvrir un dossier d’incident avec les identifiants de requête et une plage temporelle précise.
Une annonce de statut verte ne prouve rien. Elle indique seulement qu’aucun texte n’a encore été publié, ce qui est un état administratif parfaitement compatible avec une panne technique.
Confinement et continuité face à une panne de voisinage
Section intitulée « Confinement et continuité face à une panne de voisinage »Le premier objectif n’est pas de restaurer toutes les fonctions. Il faut préserver les parcours métier dont l’arrêt coûte plus que la dégradation : lecture avant écriture, validation différée avant rejet, cache avant appel distant, file de messages avant traitement synchrone.
Un disjoncteur logiciel, ou circuit breaker, doit interrompre temporairement les appels vers une dépendance qui échoue. Sans cette coupure, les tentatives automatiques amplifient la saturation et consomment les limites de débit restantes. Le délai entre tentatives doit suivre une attente exponentielle avec aléa, ou jitter : chaque client attend une durée croissante et légèrement différente. Des tentatives strictement synchronisées recréent une foule devant une porte fermée. Le cloud adore appeler cela une tempête de reprise, comme si lui donner un nom météorologique empêchait les dégâts.
Les files d’attente doivent imposer une durée maximale, une limite de taille et une stratégie de rejet. Une file sans borne transforme une indisponibilité courte en crise de stockage, puis en reprise interminable. Les messages doivent être idempotents : rejouer deux fois une opération ne doit pas débiter deux fois, créer deux objets ou envoyer deux notifications. L’identifiant de déduplication appartient au contrat métier, pas au hasard heureux d’une base de données.
La bascule vers une autre région ou un autre fournisseur n’est recommandée que si elle est exercée et si les données nécessaires y sont disponibles. Une bascule non testée pendant une crise devient une migration forcée, avec le stress en supplément et les droits manquants en dessert. Le délai de reprise, ou RTO (Recovery Time Objective), et la perte de données admissible, ou RPO (Recovery Point Objective), doivent être définis par processus métier. Une réplication asynchrone ne garantit jamais une écriture faite juste avant la panne.
Les accès d’urgence doivent résister à l’incident. Un compte administrateur dépendant de l’authentification unique du fournisseur est inutile si ce service est dégradé. Prévoir des identités de secours, protégées par authentification forte, documentées hors du fournisseur et limitées aux actions de crise. Leur utilisation doit générer une alerte immédiate et une revue après incident.
Exemple concret : alerte sur erreur de dépendance cloud
Section intitulée « Exemple concret : alerte sur erreur de dépendance cloud »Cet exemple configure une alerte Prometheus sur une sonde Blackbox Exporter. Prometheus est un système de collecte de métriques ; Blackbox Exporter exécute des vérifications réseau externes. Le fichier suppose que la métrique probe_success est déjà collectée pour deux chemins indépendants vers le même service.
groups: - name: cloud-multitenant rules: - alert: DependenceCloudDegradee # Les deux sondes échouent pendant 5 minutes. # Le seuil évite l'alerte sur une perte de paquet isolée. expr: | min_over_time(probe_success{job=~"public-api|private-api"}[5m]) == 0 for: 5m labels: severity: critical annotations: summary: "Dégradation simultanée des chemins cloud" description: > Vérifier les identifiants de requête, la région, les limites de débit et l'état des services mutualisés avant toute bascule.Charger cette règle dans le répertoire surveillé par Prometheus, puis vérifier sa syntaxe avec promtool check rules cloud-multitenant-alerts.yml. L’alerte ne démontre pas qu’un autre client est responsable. Elle démontre qu’un chemin partagé mérite une qualification immédiate. C’est volontairement moins spectaculaire qu’une certitude prématurée, et beaucoup plus exploitable.
Exploitation : secrets, sauvegardes et reprise contrôlée
Section intitulée « Exploitation : secrets, sauvegardes et reprise contrôlée »Les mécanismes de continuité échouent souvent sur les secrets. Une réplication applicative vers une seconde région ne sert à rien si la clé de chiffrement, le certificat Transport Layer Security, ou TLS, ou le secret d’accès à la base restent indisponibles dans la région primaire.
Chaque dépendance de sécurité doit être classée selon trois questions : où est stocké le secret, quelle identité peut l’utiliser, et quelle dépendance permet de le récupérer. Une clé de chiffrement gérée exclusivement par un service régional crée une frontière de panne régionale. Une copie exportable réduit cette dépendance mais augmente le risque d’exfiltration. Il n’existe pas de magie, seulement des coûts déplacés.
La rotation doit être testée pendant un état dégradé. Une rotation réussie en régime normal ne prouve pas que les applications peuvent récupérer la nouvelle version durant une indisponibilité partielle. Les versions précédentes doivent rester utilisables pendant une fenêtre bornée, afin de ne pas casser les sessions et les données chiffrées encore actives. La révocation d’un certificat ne ferme pas les connexions déjà établies : les délais de session, de cache et de renouvellement définissent le délai réel.
Les sauvegardes doivent être indépendantes du plan de contrôle utilisé pour les restaurer. Une sauvegarde stockée dans le même compte, chiffrée par la même clé inaccessible et restaurable seulement par une API indisponible est une archive décorative. Tester la restauration avec des identités de secours, des images immuables et des journaux de contrôle est le minimum. Les principes de reprise sont détaillés dans la page sauvegardes et continuité.
Le retour à la normale demande une levée graduelle des limitations : réactiver un pourcentage de trafic, surveiller les erreurs, vider les files à débit contrôlé, puis seulement rétablir les traitements différés. Rejouer toute la charge retenue d’un seul coup est une manière très efficace de prolonger une panne que le fournisseur vient tout juste de résoudre.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans ce dispositif, l’incident du voisin ouvre des brèches locales durables. Faute d’accès d’urgence préparés, les équipes contournent l’obstacle sous pression : droits élargis attribués à la hâte, authentification forte suspendue, règles de filtrage ouvertes pour tester une hypothèse, secrets copiés en clair vers une autre région. Ces modifications survivent souvent à la panne, car aucune revue ne les recense. Une application non préparée peut aussi valider un jeton expiré ou non vérifié lorsque le service d’identité ne répond plus, ce qui accorde l’accès sans contrôle réel. Enfin, sans identifiants de requête ni plage temporelle horodatée, la réclamation contractuelle auprès du fournisseur perd son fondement : l’indisponibilité subie ne peut ni être imputée ni compensée, et l’analyse après incident ne distingue plus les actions de crise légitimes d’éventuels abus.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un service en ligne peut utiliser des ressources partagées avec d’autres clients du même fournisseur. Même si son propre programme est correct, une panne, une surcharge ou une limite atteinte sur une ressource commune peut empêcher les utilisateurs d’accéder au service.
La gestion de crise commence par vérifier ce qui échoue réellement. Il faut comparer les résultats obtenus depuis plusieurs réseaux et regarder si la connexion, l’identification, le stockage ou une fonction précise est touchée. Les journaux gardent la date, l’heure, le lieu et le message d’erreur. Ces informations permettent de distinguer un défaut local d’un problème chez le fournisseur.
Pendant la panne, le service doit réduire les demandes envoyées vers la partie défaillante. Il peut conserver temporairement certaines données, remettre des tâches à plus tard ou refuser des opérations non urgentes. Répéter sans arrêt la même demande aggrave souvent la panne, car cela augmente la charge.
Une seconde zone ou un second fournisseur peut prendre le relais, mais seulement si les données, les autorisations et les secrets nécessaires y sont déjà disponibles. Les clés de chiffrement, les certificats et les comptes d’urgence doivent donc être préparés avant l’incident. Quand le fournisseur revient à la normale, le trafic et les tâches en attente doivent reprendre progressivement, sinon la reprise peut provoquer une nouvelle saturation.
À lire aussi
- Quotas cloud contre le déni de service par coûtGérer les quotas et limites de ressources cloud pour réduire le risque de déni de service par abus de facturation.
- Sécuriser le rollback blue-green et canary cloudSécuriser le versionnement, le rollback blue-green et le déploiement canary d'une infrastructure cloud face à une mise à jour défaillante.
- Saturation d'une équipe de sécurité : une panne d'architectureUne équipe de sécurité saturée est le symptôme d'une organisation mal conçue : files sans limite, alertes non actionnables, décisions sans propriétaire.
- Test de restauration des sauvegardesLes tests de restauration révèlent les défaillances opérationnelles, cryptographiques et applicatives qu'un audit de sauvegarde ne peut pas prouver.
Pages voisines
La citent
- Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi
- Isolation multi-locataire face à un locataire hostile
Gérer une crise cloud multi-tenant
Elle cite