Sécurité multi-cloud et hybrid cloud

Sécurité multi-cloud et hybrid cloud

Le multi-cloud ne réduit pas mécaniquement le risque : il remplace une dépendance concentrée par plusieurs dépendances techniques, contractuelles et opérationnelles. Le compromis central est brutal : gagner une capacité théorique de repli exige de maîtriser simultanément plusieurs plans de contrôle, plusieurs modèles d’identité et plusieurs chaînes de détection.

Explication de la marmotte

Gérer plusieurs fournisseurs ressemble à louer plusieurs maisons pour éviter qu’une panne de chauffage bloque tout l’hiver. Cela peut sauver la situation si l’une devient inhabitable, mais il faut aussi garder des clés, des alarmes, des contrats et des règles différentes pour chaque maison.

→ Lire l’explication complète de la marmotte

Le compromis réel : résilience contre complexité de sécurité

Une stratégie multi-cloud justifiée vise un objectif mesurable : continuité d’un service critique, contrainte de souveraineté, acquisition d’une capacité indisponible chez le fournisseur principal, ou séparation forte entre deux périmètres de risque. « Éviter le verrouillage fournisseur » n’est pas un objectif d’architecture suffisant. C’est souvent un argument de négociation commerciale maquillé en stratégie de résilience, avec une facture de sécurité livrée sans emballage cadeau.

La résilience exige qu’une charge puisse fonctionner ailleurs dans les délais du plan de reprise. Répliquer des données ne suffit pas. Il faut reconstruire les identités de service, les règles réseau, les secrets, les journaux, les politiques de chiffrement, les images de conteneurs et les dépendances externes. Une application portable qui dépend d’un service de base de données managé propriétaire, d’une file native et de fonctions événementielles spécifiques n’est pas portable parce qu’elle tourne dans des conteneurs. Kubernetes ne transforme pas les dépendances en nuages inoffensifs.

Le cloud hybride ajoute une frontière supplémentaire entre les environnements hébergés et le système d’information interne. Cette frontière concentre les risques de transit, de résolution de noms, de fédération d’identité et d’administration distante. Les fondations réseau doivent être définies avant les interconnexions : segmentation, plan d’adressage non chevauchant, filtrage sortant, inspection et journalisation. La gouvernance du réseau cloud ne se délègue pas à une collection de tunnels privés.

La recommandation est de limiter le multi-cloud actif aux services dont le coût d’interruption justifie explicitement le coût de double exploitation. Pour le reste, choisir un fournisseur principal, formaliser une stratégie de sortie réaliste et tester la restauration des données est plus défendable qu’un deuxième cloud à moitié configuré. Un environnement de secours non testé est une décoration de comité de direction, pas une capacité de reprise.

IAM multi-cloud : plusieurs racines de confiance, plusieurs échecs

Chaque fournisseur implémente un modèle d’Identity and Access Management (IAM) propre : hiérarchies d’organisation, abonnements ou comptes, rôles, politiques de ressources, identités de charge, conditions contextuelles et mécanismes de délégation. Les noms paraissent comparables. La sémantique ne l’est pas. Un rôle à privilèges élevés dans un fournisseur ne se transpose pas mécaniquement dans un autre, et la transcription ligne à ligne d’une politique produit souvent une autorisation plus large que prévu.

La fédération doit reposer sur une source d’identité centrale, avec Security Assertion Markup Language (SAML) ou OpenID Connect (OIDC) selon les capacités du fournisseur. Cette fédération réduit le nombre de comptes humains permanents, mais elle ne supprime pas les comptes locaux de secours, les identités de machines ni les jetons d’accès générés hors de la fédération. Chaque exception crée une seconde racine de confiance à inventorier et à superviser.

Les identités de charge sont le point de rupture habituel. Une application exécutée chez un fournisseur A qui appelle une ressource chez un fournisseur B doit obtenir un jeton éphémère, avec une audience, un émetteur et des revendications vérifiables. Injecter une clé d’accès longue durée dans une variable de déploiement contourne ce mécanisme. Cela fonctionne très bien jusqu’au jour où la clé apparaît dans une image, une sauvegarde ou un journal. Vingt ans de sécurité d’infrastructure apprennent que le secret « temporaire » survit volontiers à trois réorganisations et à deux changements d’outil.

La règle est de préférer la fédération de charge à charge fondée sur OIDC, avec des jetons courts et des conditions strictes sur l’émetteur, l’audience et l’identité du dépôt ou du service appelant. Les rôles doivent être séparés par environnement et par fonction : lecture d’inventaire, déploiement, chiffrement, administration d’urgence. Le principe de moindre privilège ne consiste pas à écrire ReadOnly quelque part et à espérer que le mot fasse le travail.

Les mécanismes d’IAM natifs restent indispensables. Une couche centrale peut détecter les écarts, mais elle ne remplace pas l’évaluation locale des politiques, les permissions implicites ni les garde-fous de l’organisation fournisseur. La page sur l’IAM cloud complète ce point : l’identité reste le plan de contrôle réel, même lorsque l’interface affiche surtout des machines et des réseaux.

CNAPP et posture multi-cloud : centraliser sans croire à la magie

Une Cloud Native Application Protection Platform (CNAPP) agrège généralement la gestion de posture cloud, l’analyse d’infrastructure déclarative, l’inventaire des charges, la détection de vulnérabilités, parfois la protection d’exécution et la corrélation des chemins d’attaque. Son intérêt est réel : produire une vue transverse des comptes, des ressources exposées, des configurations interdites et des identités sur-privilégiées.

Cette vue n’est jamais équivalente aux services natifs. Un connecteur API lit les données qu’il est autorisé à lire, à la fréquence prévue par l’outil, selon un modèle de ressource que l’éditeur a implémenté. Une nouvelle fonctionnalité fournisseur, une région récente, une politique conditionnelle ou un journal spécialisé peuvent rester invisibles pendant des mois. La plateforme « unifiée » devient alors un angle mort centralisé. Le marché adore appeler cela une console unique. Une console unique qui ignore une partie du terrain reste une console, pas un périmètre de sécurité.

Un CNAPP doit donc être traité comme un système de détection et de pilotage, non comme une autorité de sécurité. Les contrôles préventifs doivent rester proches de l’action : politiques d’organisation du fournisseur, règles de déploiement, validation des configurations déclaratives et limitations IAM. Les règles centrales servent à normaliser le référentiel de risques, à identifier les écarts et à suivre les corrections.

La couverture doit être évaluée contrôle par contrôle. Pour chaque exigence, documenter : ressource concernée, fournisseur, signal natif de référence, délai maximal de remontée, capacité de remédiation, limite connue du connecteur et propriétaire de l’exception. Sans cette matrice, le taux de couverture affiché par l’outil est une valeur décorative. Les pourcentages ont cette propriété fascinante de sembler précis même lorsqu’ils mesurent seulement ce qui a été branché.

Exemple reproductible : vérifier les privilèges d’un connecteur de posture

Le compte de lecture d’un outil de posture ne doit pas recevoir des privilèges d’administration. L’exemple suivant vérifie une politique AWS Identity and Access Management (AWS IAM) locale avant son attachement à un rôle de collecte. Il requiert l’interface en ligne de commande AWS CLI version 2, jq version 1.6 ou supérieure, et des identifiants capables d’appeler l’API IAM.

# Refuser les permissions d'écriture et les jokers de ressources
# dans une politique destinée à un connecteur de lecture.
POLICY_ARN="arn:aws:iam::123456789012:policy/CNAPPReadOnly"

aws iam get-policy-version \
  --policy-arn "$POLICY_ARN" \
  --version-id "$(aws iam get-policy \
    --policy-arn "$POLICY_ARN" \
    --query 'Policy.DefaultVersionId' \
    --output text)" \
  --query 'PolicyVersion.Document' \
  --output json |
jq -e '
  [.Statement[] |
   select(.Effect == "Allow") |
   .Action |
   if type == "array" then .[] else . end |
   select(test("^(?!.*(Put|Create|Delete|Update|Attach|Detach|PassRole)).*$"))] |
  length > 0
' >/dev/null

# Le code de retour non nul impose une revue de la politique.

Ce contrôle ne prouve pas l’absence de privilège excessif. Il ne couvre ni les actions indirectes, ni les autorisations héritées, ni les politiques de ressources. Il bloque seulement une classe d’erreurs courante : confondre collecte de posture et administration du tenant. Le même contrôle doit exister pour chaque fournisseur, avec une grammaire de permissions différente. C’est précisément le problème.

Surface d’attaque et contrôles non négociables

Les interconnexions entre fournisseurs créent des chemins d’attaque supplémentaires : compromission d’une identité fédérée, abus d’un rôle inter-cloud, empoisonnement de résolution de noms privée, exfiltration par flux sortant autorisé et pivot depuis un agent de supervision. Un lien privé réduit l’exposition Internet, pas le besoin d’authentifier, d’autoriser et de journaliser les flux. Le câble logique n’a jamais signé de contrat de confiance.

Le chiffrement en transit doit s’appuyer sur Transport Layer Security (TLS) avec authentification mutuelle lorsque deux services contrôlent leurs certificats. Une Public Key Infrastructure (PKI) doit alors gérer l’émission, la rotation et la révocation des certificats. La révocation ne coupe pas les sessions déjà établies : les durées de session et les délais de renouvellement bornent le temps d’exposition. Les fondations décrites dans PKI et TLS restent valables, mais les autorités de certification et les points de distribution doivent être atteignables depuis tous les environnements concernés.

Les clés de chiffrement posent une autre limite. Chaque fournisseur propose un service de gestion de clés avec ses propres politiques, journaux et modes de sauvegarde. Exporter une clé maître pour la réimporter ailleurs détruit fréquemment les garanties recherchées. Préférer le chiffrement d’enveloppe : une Data Encryption Key (DEK) chiffre les données, puis une Key Encryption Key (KEK) protège la DEK dans le service de clés local. La portabilité porte alors sur les données et les DEK chiffrées, pas sur une clé racine qui voyage dans un fichier. Pour les clés non exportables, un module cryptographique matériel peut imposer une frontière matérielle, mais il ne résout pas la cohérence des politiques entre clouds.

Le multi-cloud ne garantit ni l’indépendance face aux éditeurs de logiciels, ni la disponibilité d’Internet, ni l’absence d’erreur humaine, ni la récupération après compromission d’une identité centrale. Le reste doit venir d’une architecture de reprise, de sauvegardes hors domaine d’administration, de procédures d’urgence et d’exercices réguliers. Une sauvegarde accessible avec les mêmes privilèges que la production est une copie pratique pour l’attaquant.

Exploitation : rotation, supervision et reprise inter-fournisseurs

L’exploitation doit définir un inventaire consolidé des comptes, abonnements, projets, identités de service, domaines DNS, clés, certificats, réseaux et journaux. Cet inventaire doit être alimenté par les interfaces de programmation des fournisseurs et comparé aux déclarations d’infrastructure. Les ressources créées hors automatisation sont des exceptions à durée limitée, jamais une seconde méthode d’exploitation.

La supervision nécessite des journaux d’audit natifs immuables, exportés vers une plateforme de corrélation distincte. La conservation, l’horodatage et les champs d’identité varient entre fournisseurs : normaliser les événements sans conserver l’événement brut rend les enquêtes fragiles. Conserver l’original, ajouter une représentation normalisée, corréler sur des identifiants stables et tester les alertes sur les actions à privilèges.

La rotation doit couvrir les secrets humains, les jetons de charges, les certificats et les clés de chiffrement. Les rotations automatiques doivent être testées avec les applications clientes : un secret tourné que personne ne consomme correctement devient une panne planifiée par un robot très ponctuel. Les sauvegardes doivent être chiffrées, versionnées, isolées des identités de production et restaurées périodiquement dans un environnement distinct.

🐝 Ce qui arrive si on s’en passe

Sans cette discipline, la porte reste ouverte sur des détails que personne ne regarde : un tenant ouvert pour un essai reste facturé et actif, avec ses comptes de secours hors fédération, longtemps après le départ de son demandeur. Le départ d’un administrateur se traite alors dans un annuaire et pas dans les trois autres. En cas d’incident, la reconstitution de la chronologie échoue sur des horodatages, des formats d’identifiants et des durées de conservation divergents, ce qui allonge la qualification et empêche de prouver l’étendue réelle d’un accès. Les réponses aux auditeurs et aux demandes légales (localisation d’une donnée, liste des accès privilégiés, preuve de suppression) deviennent des enquêtes manuelles par fournisseur. Enfin, faute de stratégie de sortie testée, la migration vers un autre fournisseur se négocie sous contrainte, au moment le plus défavorable.

🦫 Explication de la marmotte 🍫

Utiliser plusieurs fournisseurs d’informatique à distance signifie créer et protéger plusieurs environnements séparés. Chacun possède ses propres comptes, règles d’accès, réseaux, journaux et moyens de chiffrer les données. Une même personne ou une même application doit parfois obtenir une autorisation dans plusieurs environnements. Si cette autorisation est trop large, volée ou mal supprimée, elle peut permettre d’atteindre des données dans plusieurs endroits.

Une organisation peut installer un outil central pour repérer les erreurs de configuration. Cet outil récupère des informations auprès de chaque fournisseur, puis signale par exemple un stockage public ou un compte trop puissant. Il ne voit pourtant que les informations que les fournisseurs acceptent de lui donner et que ses concepteurs savent interpréter. Une règle récente ou un service particulier peut donc manquer à l’écran alors qu’il existe réellement.

Pour éviter ce problème, les protections locales de chaque fournisseur restent actives. Les accès doivent être limités, les autorisations temporaires et les actions enregistrées. Les données doivent être sauvegardées dans un endroit séparé des systèmes utilisés chaque jour. En cas de panne ou d’attaque, la reprise dépend aussi des identités, des réseaux, des certificats et des programmes, pas seulement de la copie des données. Le second fournisseur n’aide que si tout cela fonctionne déjà chez lui.

À lire aussi

• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoiDéfinition du cloud computing selon le NIST, modèles de service IaaS, PaaS, SaaS et modèles de déploiement, avec ce que chacun délègue réellement en sécurité et ce qu'il laisse au client.
• Comment gouverner les coûts cloud contre un compte compromisLa gouvernance des coûts cloud limite l'impact financier d'un compte compromis en complétant la détection, les identités et la réponse à incident.
• 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 l'accès des flottes de véhicules connectésSécuriser les systèmes de contrôle d'accès des véhicules connectés et des flottes face aux attaques par diagnostic et connectivité cellulaire.

Pages voisines

La citent

• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi
• Cloud networking, VPC/VNet, CDN et équilibrage
• Ce que « hébergé en France » garantit

Sécurité multi-cloud et hybrid cloud

Elle cite

• Détecter la persistance IAM dans AWS
• Mettre en place la fédération d’identité de charge
• Réconcilier inventaire IaC et cloud réel
• Normaliser les logs avec OCSF, ECS ou CIM