Sécurité cloud : de la configuration à la gouvernance multi-cloud

Qu’est-ce que la sécurité cloud ?

La sécurité cloud protège identités, données, workloads, configurations, interfaces, journaux et usages IaaS, PaaS et SaaS. Les responsabilités sont réparties entre fournisseur et client et varient selon le service utilisé.

Expertise cloud, audit ou conseil : quelle différence ?

Sécurité cloud : l’essentiel

• Clarifier la responsabilité partagée.
• Réduire les privilèges et protéger les identités.
• Éviter exposition publique et mauvaises configurations.
• Protéger données, secrets et sauvegardes.
• Maîtriser interconnexions et exposition Internet.
• Conserver une journalisation exploitable.
• Gouverner utilisateurs, partages et intégrations SaaS.

Pourquoi la responsabilité partagée est-elle le point de départ ?

AWS distingue la sécurité of the cloud de la sécurité in the cloud. Microsoft indique que les responsabilités varient entre IaaS, PaaS et SaaS et que le client conserve notamment la responsabilité de ses données et identités. Google Cloud décrit également un modèle de responsabilité partagée, complété par son approche de shared fate.

AWS — Shared responsibility · Microsoft — Responsabilité partagée · Google Cloud — Shared fate

AWS, Azure et Google Cloud : faut-il les sécuriser de la même manière ?

Les principes sont proches, les implémentations ne sont pas identiques. Identités, privilèges, exposition réseau, données, secrets, journalisation et configuration restent des enjeux communs, mais services et modèles d’autorisation diffèrent.

Une stratégie multi-cloud doit définir des objectifs de contrôle communs, puis les traduire correctement dans chaque plateforme.

Quels services natifs peuvent aider à piloter la posture de sécurité cloud ?

Les grands fournisseurs disposent de services natifs capables de centraliser une partie de la posture, des vulnérabilités, des alertes ou des recommandations. Ils peuvent être utiles, mais leur présence ne dispense pas de définir une architecture, des responsabilités et un processus de remédiation.

AWS Security Hub · Microsoft Defender for Cloud · Google Security Command Center

Ces services sont cités comme exemples documentés par les fournisseurs, pas comme outils obligatoires ni comme preuve de certification ou de maîtrise personnelle.

Pourquoi les identités sont-elles centrales dans le cloud ?

De nombreuses opérations d’administration passent par des API et mécanismes d’identité. Un droit excessif accordé à un utilisateur, rôle ou workload peut donner accès à des ressources très différentes.

• séparer usages courants et privilégiés ;
• limiter les privilèges permanents ;
• protéger les comptes sensibles ;
• maîtriser les identités techniques ;
• révoquer les accès inutiles ;
• surveiller les changements de rôles.

Voir aussi Sécurité des systèmes et identités.

Quelles erreurs de configuration cloud faut-il traiter en priorité ?

Cloud hybride, multi-cloud et cloud de confiance : quelles différences ?

Ces notions ne sont pas interchangeables. Une architecture multi-cloud n’est pas nécessairement hybride ; un cloud hybride n’est pas automatiquement « souverain » ; et le recours à une offre qualifiée ne transfère pas toute la responsabilité de sécurité au fournisseur.

Cloud hybride et multi-cloud : où apparaissent les zones grises ?

Les architectures hybrides relient datacenter, cloud public, SaaS, utilisateurs distants et parfois plusieurs fournisseurs. Les risques apparaissent souvent aux frontières : identités fédérées, DNS, routage, VPN, interconnexions privées, synchronisation d’annuaires, secrets et administration.

Voir Sécurité réseau.

SaaS security : le fournisseur sécurise-t-il tout ?

Non. Même lorsqu’un fournisseur SaaS exploite application et infrastructure, l’organisation doit encore gouverner utilisateurs, données, droits, partages et intégrations.

• cycle de vie des comptes ;
• rôles d’administration ;
• partages externes ;
• applications OAuth et intégrations tierces ;
• paramètres de sécurité ;
• logs et investigation ;
• export, sauvegarde et réversibilité selon le service.

CASB, CSPM, CNAPP : faut-il ajouter un nouvel outil ?

Pas nécessairement. Ces familles répondent à des besoins différents et leurs périmètres évoluent selon les éditeurs.

L’acronyme ne doit jamais devenir le besoin. Il faut d’abord identifier le risque, la couverture existante et l’équipe capable d’exploiter les alertes.

Zero Trust s’applique-t-il différemment dans le cloud ?

Le cloud renforce l’intérêt d’une approche centrée sur identités, ressources et décisions d’accès plutôt que sur la seule localisation réseau. Le NIST a publié un modèle spécifique pour les applications cloud-native et multi-cloud.

Zero Trust ne signifie ni supprimer les contrôles réseau ni acheter un produit unique. Voir Sécurité réseau et Sécurité des systèmes.

Source primaire : NIST SP 800-207A

Quel référentiel utiliser pour structurer une gouvernance cloud multi-fournisseurs ?

Lorsque l’organisation utilise plusieurs fournisseurs ou veut éviter de raisonner uniquement avec les recommandations d’un éditeur, un cadre neutre peut être utile. La Cloud Security Alliance Cloud Controls Matrix (CCM) v4.1, publiée en janvier 2026, regroupe 207 contrôles de sécurité et de confidentialité répartis sur 17 domaines.

La CCM peut aider à structurer l’évaluation des responsabilités, de l’IAM, de la journalisation, de la gestion des fournisseurs, des vulnérabilités, de la résilience et d’autres dimensions cloud, tout en fournissant des correspondances avec plusieurs standards et bonnes pratiques.

Source : Cloud Security Alliance — Cloud Controls Matrix v4.1

SecNumCloud : que signifie réellement la qualification ?

SecNumCloud est une qualification de sécurité de l’ANSSI applicable à des offres cloud répondant à un référentiel d’exigences techniques, opérationnelles et juridiques. L’ANSSI la présente comme un moyen d’identifier des offres cloud de confiance, notamment pour la protection de données et traitements sensibles.

Une offre qualifiée SecNumCloud ne rend pas automatiquement l’application du client sécurisée. L’ANSSI précise que la qualification du fournisseur ne préjuge pas du niveau de sécurité des services numériques du client.

Les recommandations ANSSI pour l’hébergement des SI sensibles constituent un outil d’aide à la décision selon le type de SI, la sensibilité des données et le niveau de menace.

ANSSI — Cloud et SecNumCloud · ANSSI — Hébergement des SI sensibles

Comment protéger les données dans le cloud ?

Le chiffrement est important, mais ne résume pas la protection des données. Il faut savoir quelles données existent, où elles résident, qui y accède, comment elles sont partagées, sauvegardées, restaurées et supprimées.

• classification et propriétaires ;
• droits et partages ;
• chiffrement lorsque pertinent et gestion des clés ;
• sauvegardes et restauration ;
• journalisation des accès sensibles ;
• cycle de vie et suppression ;
• réversibilité.

Voir Sécurité des données.

Quels événements cloud faut-il journaliser ?

Collecter tous les logs sans cas d’usage peut coûter cher sans améliorer la sécurité. La journalisation doit partir des scénarios de détection et d’investigation.

• authentifications ;
• changements de rôles et politiques ;
• actions d’administration sensibles ;
• création ou exposition de ressources ;
• changements réseau et sécurité ;
• accès sensibles lorsque pertinent ;
• modifications de la journalisation.

Quelles idées reçues faussent le plus souvent la sécurité cloud ?

Comment évaluer et améliorer la sécurité cloud ?

1. Inventorier comptes, projets, services SaaS et interconnexions.
2. Clarifier les responsabilités fournisseur/client.
3. Cartographier identités, privilèges, données et exposition.
4. Analyser configurations, logs, secrets, réseau et sauvegardes.
5. Prioriser les chemins de risque à fort impact.
6. Industrialiser les garde-fous maintenables.
7. Réévaluer régulièrement.

Cette expertise peut être mobilisée dans un audit cloud, une mission de conseil, un test de sécurité ou un pilotage RSSI.

Où s’arrête la sécurité cloud et où commence la sécurité applicative ?

Les deux domaines se recouvrent, mais ne se confondent pas. La sécurité cloud traite surtout l’environnement d’exécution, les identités, les configurations, les services managés, les secrets, le réseau et la gouvernance. La sécurité applicative traite davantage la conception du logiciel, les autorisations métier, les API, les dépendances, le code et le CI/CD.

Dans une application cloud-native, les deux doivent être traités ensemble : une application bien codée peut rester exposée par une mauvaise configuration cloud, et une infrastructure correctement configurée n’efface pas une faille logique dans l’application.

Quelles erreurs fragilisent le plus souvent la sécurité cloud ?

• penser que le fournisseur prend en charge toute la sécurité ;
• multiplier comptes ou projets sans gouvernance ;
• accorder des privilèges larges ;
• laisser des ressources publiques par oubli ;
• conserver des secrets statiques ;
• activer des logs sans les exploiter ;
• acheter un outil de posture sans processus de remédiation ;
• traiter séparément cloud, SaaS, réseau et identités.

Ce que cette expertise ne signifie pas

Connaître les principes de sécurité AWS, Azure, Google Cloud, SaaS, CASB ou CSPM ne signifie pas recommander tous les outils ni prétendre qu’une configuration identique convient à chaque fournisseur.

Cette page décrit un domaine d’expertise, pas une certification AWS, Microsoft ou Google, ni une qualification SecNumCloud de Mobhitech.

Une expertise cloud reliée au risque et au business

Gérard Levicki intervient directement dans les missions Mobhitech avec une approche reliant cloud, identités, réseau, données, architecture, risque, gouvernance et conséquences métier. Son parcours dans les métiers de la cybersécurité s’étend sur plus de 25 ans.

Learn about his career · LinkedIn Profile

Autres domaines d’expertise

Systèmes · Réseau · Applicatif · Données · Industrie & IoT

Questions fréquentes sur la sécurité cloud

Le fournisseur cloud est-il responsable de toute la sécurité ?

Non. Les responsabilités sont partagées et varient selon IaaS, PaaS, SaaS et les services utilisés.

Une offre SecNumCloud rend-elle mon application sécurisée ?

Non. L’ANSSI précise que la qualification du fournisseur ne préjuge pas du niveau de sécurité du service numérique du client.

CASB et CSPM sont-ils obligatoires ?

Non. Leur pertinence dépend du risque, des usages et des capacités déjà disponibles.

Le chiffrement suffit-il à protéger les données cloud ?

Non. Accès, identités, clés, sauvegardes, partages, logs et cycle de vie restent déterminants.

Un audit cloud est-il la même chose que cette expertise ?

Non. Cette page décrit le domaine technique ; l’audit est une prestation d’évaluation avec un périmètre et des livrables.

Zero Trust remplace-t-il la sécurité réseau dans le cloud ?

Non. Identités, politiques d’accès, réseau, terminaux et télémétrie restent complémentaires.

Quelle différence entre cloud hybride et multi-cloud ?

Le cloud hybride combine généralement SI interne ou cloud privé avec des services cloud publics ; le multi-cloud désigne l’usage de plusieurs fournisseurs cloud. Une organisation peut être hybride sans être multi-cloud, et inversement.

Un service natif comme Security Hub, Defender for Cloud ou Security Command Center suffit-il ?

Non. Ces services peuvent améliorer visibilité, posture et priorisation, mais ne remplacent ni architecture, gouvernance, remédiation ni analyse des risques.