Sécurisation d’infrastructure cloud

Sécuriser une infrastructure cloud, ce n'est pas empiler des outils : c'est reprendre la maîtrise de qui accède à quoi, de ce qui est chiffré, de ce qui est sauvegardé et de ce que vous voyez réellement de votre environnement. La plupart des incidents cloud ne viennent pas d'un attaquant génial, mais d'une configuration laissée ouverte « provisoirement ». Ce guide opérationnel détaille la démarche complète sur Microsoft Azure et AWS, modèle de responsabilité partagée, identités, chiffrement, Zero Trust, conformité française, outils natifs, budget, KPI, pour que vous sachiez précisément où vous êtes exposé et dans quel ordre corriger.

Qu'est-ce que la sécurisation d'une infrastructure cloud ?

La sécurisation d'une infrastructure cloud est l'ensemble structuré des mesures techniques, organisationnelles et de gouvernance qui protègent un environnement hébergé sur une plateforme de cloud public (Microsoft Azure, AWS) ou en mode hybride : identités et accès, réseau, données, configurations, supervision, et conformité aux référentiels qui vous engagent. Le but n'est pas de produire de la peur, mais de la maîtrise, savoir ce qui est exposé, ce que cela coûterait, et comment réduire ce risque dans un ordre rationnel.

Concrètement, sécuriser un cloud revient à agir sur six leviers : la gestion des identités et des accès (IAM), la sécurité réseau et sa segmentation, le chiffrement des données et la gestion des clés, la résilience (sauvegarde, redondance, PRA/PCA), la détection (journalisation, supervision continue, réponse à incident), et la conformité au cadre réglementaire applicable. Chacun de ces leviers se décline différemment selon que vous consommez de l'IaaS, du PaaS ou du SaaS.

À retenir : sécuriser son cloud répond à trois questions de direction, « Qui peut faire quoi ? », « Que voit-on si quelque chose tourne mal ? », « Combien de temps pour s'en remettre ? ». Tout le reste est méthode pour y répondre avec des preuves, pas avec des impressions.

Sécurité cloud et sécurité on-premise : ce qui change vraiment

La sécurité d'un datacenter traditionnel reposait sur un périmètre tangible : un pare-feu en bordure, un réseau interne « de confiance », des serveurs physiques que l'on maîtrisait de bout en bout. Le cloud fait sauter ce périmètre. Vos ressources sont accessibles par API, depuis n'importe où, et la frontière de sécurité n'est plus le réseau mais l'identité.

Trois différences structurantes :

• Le périmètre devient l'identité. Dans le cloud, une clé d'accès volée ou un compte sans MFA donne potentiellement les mêmes droits qu'une intrusion physique dans une salle serveurs. L'identité est le nouveau pare-feu.
• La vitesse change l'échelle des erreurs. On crée une ressource en quelques secondes, par script. Une mauvaise configuration se réplique aussi vite : un rôle trop permissif appliqué à un modèle d'infrastructure se propage sur des dizaines de comptes.
• La responsabilité est partagée. Sur site, vous étiez responsable de tout. Dans le cloud, le fournisseur sécurise une partie de la pile, vous sécurisez le reste. Ne pas savoir où passe la frontière est la première cause de mauvaise surprise.

Ce dernier point mérite un chapitre à part entière, car il conditionne tout le reste.

Le modèle de responsabilité partagée, rendu concret

Tous les fournisseurs publient un schéma du modèle de responsabilité partagée. Le principe est simple : le fournisseur (CSP) sécurise le cloud (datacenters, matériel, hyperviseur, réseau physique), le client sécurise ce qu'il met dans le cloud (données, identités, configurations). La difficulté est que la frontière exacte se déplace selon le modèle de service consommé. C'est cette frontière mouvante que la plupart des pages laissent dans le flou.

Tableau de répartition par couche et par modèle

| Couche | On-premise | IaaS (VM, réseau) | PaaS (App Service, bases managées) | SaaS (Microsoft 365, Salesforce) | |---|---|---|---|---| | Datacenter physique | Client | CSP | CSP | CSP | | Réseau & hyperviseur | Client | CSP | CSP | CSP | | Système d'exploitation | Client | Client | CSP | CSP | | Runtime / middleware | Client | Client | CSP | CSP | | Application | Client | Client | Client | CSP | | Configuration du service | Client | Client | Client | Client | | Données | Client | Client | Client | Client | | Identités & accès (IAM) | Client | Client | Client | Client |

La lecture clé : les données, les identités et la configuration restent toujours de votre responsabilité, quel que soit le modèle. Même en SaaS, c'est vous qui décidez qui a accès, comment les comptes sont protégés et quelles données sont partagées. Personne d'autre ne le fera à votre place.

Le piège le plus fréquent : croire que « passer en managé » (PaaS) transfère la sécurité au fournisseur. Le fournisseur sécurise l'OS et le runtime de la base managée, mais une base PaaS ouverte sur Internet avec un mot de passe faible reste votre erreur, pas la sienne.

Azure et AWS décrivent ce modèle de façon quasi identique. Azure résume la frontière selon IaaS/PaaS/SaaS ; AWS parle de sécurité of the cloud (fournisseur) versus in the cloud (client). Dans les deux cas, la conclusion opérationnelle est la même : vos efforts doivent porter sur IAM, données et configuration. Pour une vue d'ensemble de l'état de santé de votre plateforme, le pilier sécurisation d'infrastructure cloud s'articule avec l'audit infrastructure cloud.

Les principaux risques et menaces du cloud

Contrairement à l'imaginaire de l'attaquant sophistiqué, la majorité des incidents cloud proviennent d'une erreur de configuration côté client. Les études sectorielles convergent depuis des années : la mauvaise configuration et le vol d'identifiants dominent largement les exploits de failles logicielles. Voici les schémas qui reviennent le plus souvent, par ordre de fréquence observé.

• Erreurs de configuration (misconfiguration). Stockage exposé en lecture publique (bucket S3, compte de stockage Azure), groupe de sécurité ouvert sur 0.0.0.0/0, journalisation désactivée. C'est de loin la première cause d'exposition.
• Vol d'identifiants. Clés d'accès versionnées dans un dépôt Git, mot de passe d'administration réutilisé, compte sans MFA. Une seule clé fuitée suffit souvent à compromettre un environnement entier.
• Attaques d'API. Les API cloud sont la surface d'administration. Une API exposée sans authentification forte, sans limitation de débit ni filtrage, devient une porte d'entrée directe.
• Ransomware. Le chiffrement malveillant vise aussi le cloud : suppression de sauvegardes, chiffrement de volumes, compromission via une surface d'administration ouverte (RDP/SSH).
• DDoS. Saturation de la disponibilité d'un service exposé, à neutraliser par les protections natives (Azure DDoS Protection, AWS Shield) et un WAF.
• Shadow IT. Des services cloud souscrits hors de la DSI, sans gouvernance ni supervision, créent des zones aveugles que personne ne surveille.

Le constat qui change la priorisation : un attaquant n'a pas besoin de « pirater » Azure ou AWS. Il lui suffit de trouver la ressource que vous avez oublié de fermer. La sécurisation efficace commence donc par la réduction de la surface d'exposition, pas par l'achat d'un produit de détection avancé.

Pour mesurer précisément votre exposition actuelle, un audit infrastructure cloud hiérarchise ces risques avant toute remédiation.

Pilier 1 : Gestion des identités et des accès (IAM)

L'identité est le périmètre du cloud. C'est donc le premier chantier, et celui qui réduit le plus de risque pour le moins d'effort. Trois principes structurent un IAM solide.

MFA partout, sans exception

L'authentification multifacteur (MFA) neutralise la grande majorité des attaques par vol de mot de passe. Elle doit couvrir tous les comptes humains, en priorité absolue les comptes d'administration et d'accès aux portails (Entra ID côté Azure, IAM Identity Center côté AWS). Les comptes de service, eux, ne s'authentifient pas par MFA mais par identités managées et rotation de secrets, jamais par clé statique partagée.

Le moindre privilège, appliqué et révisé

Le principe du moindre privilège consiste à n'accorder que les droits strictement nécessaires, pour la durée strictement nécessaire. En pratique :

• Rôles ciblés plutôt que droits d'administration globale. Côté Azure, RBAC avec des rôles personnalisés et Privileged Identity Management (PIM) pour des droits d'administration à la demande, limités dans le temps (just-in-time). Côté AWS, des politiques IAM restreintes, des permission sets dans IAM Identity Center et l'usage de rôles temporaires plutôt que de clés longue durée.
• Revue d'accès périodique : suppression des comptes orphelins, des prestataires partis, des clés inutilisées. C'est l'hygiène qui se dégrade le plus vite avec le temps.
• CIEM (Cloud Infrastructure Entitlement Management) pour analyser l'écart entre droits accordés et droits réellement utilisés, la nouvelle génération d'outils qui rationalise les permissions à grande échelle.

Séparer les environnements et les comptes

Production, recette et développement ne doivent jamais partager les mêmes identités à privilèges. Une structure d'abonnements Azure (par management groups) ou une organisation AWS multi-comptes (via AWS Organizations) isole les rayons d'explosion : compromettre un compte de développement ne doit pas donner accès à la production.

Pilier 2 : Chiffrement des données et gestion des clés

Le chiffrement est exigé à la fois par le bon sens et par la réglementation (l'article 32 du RGPD cite explicitement le chiffrement parmi les mesures techniques appropriées). Deux états à couvrir, plus la question décisive des clés.

• Chiffrement au repos. Les données stockées (disques, bases, objets) sont chiffrées par défaut sur Azure et AWS. Le vrai sujet n'est pas « est-ce chiffré » mais « qui détient la clé ».
• Chiffrement en transit. TLS pour tous les flux, y compris internes. Aucun trafic d'administration ou de données sensibles ne doit circuler en clair, même à l'intérieur d'un VPC/VNet.
• Gestion des clés (KMS). C'est le cœur du sujet. Azure Key Vault (et Managed HSM pour les exigences fortes) et AWS KMS permettent de gérer le cycle de vie des clés, leur rotation, et la traçabilité de leur usage.

Le bon réflexe souveraineté : pour les données sensibles, privilégiez les clés gérées par le client (CMK, customer-managed keys) plutôt que les clés gérées par le fournisseur. Vous gardez le contrôle de la révocation : couper la clé rend les données illisibles, ce qui est un mécanisme de défense réel face à une compromission. La gestion des secrets applicatifs (chaînes de connexion, jetons d'API) passe par le même coffre, jamais par des variables d'environnement en clair ni par le dépôt Git.

Pilier 3 : Sauvegarde, redondance et continuité d'activité

Une infrastructure sécurisée mais non résiliente reste vulnérable au ransomware, à l'erreur humaine et à la panne régionale. La résilience se conçoit, elle ne s'improvise pas le jour de l'incident.

La règle 3-2-1, transposée au cloud

La règle 3-2-1 reste la référence : 3 copies des données, sur 2 supports différents, dont 1 hors site. Dans le cloud, on la durcit avec deux notions essentielles :

• L'immuabilité : des sauvegardes que personne, pas même un administrateur compromis, ne peut modifier ni supprimer pendant une durée définie (verrous d'immuabilité sur Azure Backup et AWS Backup Vault Lock). C'est la parade structurelle au ransomware.
• L'isolement du compte de sauvegarde : les sauvegardes critiques résident dans un compte ou un abonnement séparé, avec des identités distinctes, pour qu'une compromission de la production n'emporte pas les sauvegardes.

PRA, PCA, RTO et RPO

Le PRA (plan de reprise d'activité) décrit comment redémarrer après sinistre ; le PCA (plan de continuité) vise à maintenir le service pendant l'incident. Deux indicateurs les pilotent :

• RTO (Recovery Time Objective) : le temps maximal acceptable pour redémarrer.
• RPO (Recovery Point Objective) : la perte de données maximale acceptable, exprimée en temps.

Ces objectifs déterminent l'architecture (multi-zones, multi-régions, réplication synchrone ou asynchrone) et donc le coût. Un PRA non testé n'est pas un PRA : seul un exercice de bascule réel valide les délais annoncés. Voir nos approches dédiées PRA cloud et PCA cloud.

Pilier 4 : Sécurité réseau et segmentation

Même si l'identité est le nouveau périmètre, le réseau reste une ligne de défense majeure. L'objectif : qu'une ressource compromise ne puisse pas se déplacer librement.

• Isolation par VPC/VNet et sous-réseaux : séparer les niveaux applicatifs (front, métier, données) dans des segments distincts.
• Micro-segmentation : restreindre les flux entre charges de travail, pas seulement en bordure. On n'autorise que les communications explicitement nécessaires (Network Security Groups Azure, Security Groups AWS, network policies Kubernetes).
• Pare-feu managé (Azure Firewall, AWS Network Firewall) pour le filtrage centralisé et la journalisation des flux.
• WAF (Web Application Firewall) devant les applications exposées, pour bloquer les attaques applicatives (injection, exfiltration) en amont.
• Suppression des surfaces d'administration ouvertes : pas de RDP/SSH sur Internet. On passe par un bastion (Azure Bastion) ou un accès via Session Manager côté AWS, sans port d'administration exposé.

Cette discipline réseau est le socle concret de l'approche Zero Trust, que nous détaillons maintenant.

Pilier 5 : Démarche Zero Trust appliquée au cloud

Le Zero Trust part d'un principe : ne jamais faire confiance par défaut, vérifier systématiquement. Fini le réseau interne « de confiance ». Chaque accès est authentifié, autorisé et chiffré, quel que soit son point d'origine. Trois principes opérationnels :

1. Vérifier explicitement. Authentifier et autoriser chaque requête en fonction de l'identité, de l'appareil, de la localisation et du contexte de risque (accès conditionnel Entra ID).
2. Appliquer le moindre privilège. Accès juste-à-temps, juste-assez, et adaptatif au risque.
3. Présumer la compromission. Segmenter, chiffrer de bout en bout, journaliser tout, et limiter le rayon d'explosion d'un incident.

Le Zero Trust n'est pas un produit que l'on achète mais une architecture que l'on construit, brique par brique : MFA et accès conditionnel d'abord, segmentation ensuite, supervision enfin. C'est un parcours, et il se chiffre par étapes mesurables.

Pilier 6 : Supervision, journalisation et réponse à incident

Une intrusion non détectée peut durer des semaines. La détection transforme un incident silencieux en alerte actionnable. Sans journalisation centralisée ni détection, vous êtes aveugle.

Journalisation et supervision continue

Centraliser les journaux (activité du plan de contrôle, accès aux données, flux réseau) dans un espace dédié et protégé : Azure Monitor / Log Analytics côté Microsoft, AWS CloudTrail + CloudWatch côté AWS. Les journaux doivent être inaltérables et conservés selon vos obligations légales et contractuelles.

Détection et SIEM

Un SIEM (Microsoft Sentinel, ou un SIEM tiers alimenté par AWS Security Hub et GuardDuty) corrèle les signaux pour détecter les comportements anormaux. Couplé à un SOAR, il automatise une partie de la réponse (isolement d'une ressource, désactivation d'une clé compromise).

Plan de réponse à incident cloud, étape par étape

Improviser un jour d'incident coûte cher. Un runbook prêt à l'emploi, daté, fait gagner les heures décisives :

1. Détecter & qualifier (T0) : confirmer l'incident, en estimer la portée.
2. Contenir (T0 + minutes) : isoler la ressource (modification du groupe de sécurité, désactivation des clés d'accès compromises, révocation des sessions).
3. Éradiquer (T0 + heures) : supprimer la cause, corriger la configuration fautive.
4. Restaurer (selon RTO) : redémarrer depuis une sauvegarde saine et vérifiée.
5. Notifier : en cas de violation de données personnelles, notification à la CNIL dans les 72 heures au titre du RGPD, information des personnes concernées si le risque est élevé.
6. Analyser (post-mortem) : forensics cloud à partir des journaux, retour d'expérience et durcissement.

Cas d'usage : clé d'accès fuitée dans un dépôt Git. Remédiation pas-à-pas : (1) révoquer immédiatement la clé dans IAM/Entra ; (2) auditer CloudTrail / journaux d'activité pour tracer son usage récent ; (3) rechercher toute ressource créée par cette identité ; (4) faire tourner tous les secrets associés ; (5) purger l'historique Git et déployer un scan de secrets en CI/CD pour éviter la récidive. Sans journalisation préalable, l'étape 2 est impossible, d'où l'importance de tout journaliser avant l'incident.

Pour une exploitation continue, ces runbooks s'opèrent dans le cadre d'une infogérance cloud entreprise ou d'un SOC managé (MDR) qui assure la détection-réponse 24/7.

Dans quel ordre corriger : la séquence de priorisation

Le rôle d'un pilier de sécurisation n'est pas de tout traiter en même temps, mais de séquencer les chantiers selon le rapport coût/risque. C'est la valeur d'une vue d'ensemble : elle évite l'erreur classique qui consiste à acheter un outil de détection avancé avant d'avoir fermé les expositions les plus basiques. La logique que nous appliquons en mission classe les actions en quatre vagues.

1. Vague 1 : fermer les portes ouvertes (jours 1-2). Couper les surfaces d'administration exposées (RDP/SSH sur Internet), fermer les stockages publics, activer la MFA sur les comptes d'administration, révoquer les clés longue durée inutilisées. Effort faible, réduction de risque maximale.
2. Vague 2 : reprendre le contrôle des identités et des clés (jours 2-5). Moindre privilège, PIM et accès juste-à-temps, chiffrement avec clés gérées par le client, isolement du compte de sauvegarde. C'est le socle durable.
3. Vague 3 : voir et réagir (jours 4-8). Journalisation centralisée et inaltérable, détection (Defender for Cloud / GuardDuty + SIEM), runbook de réponse à incident daté. Sans cette vague, on subit les incidents au lieu de les piloter.
4. Vague 4 : empêcher la dérive (récurrent). Policy as code, scan IaC en CI/CD, revues d'accès périodiques, mesure continue de la couverture CIS. La sécurité cesse d'être un projet pour devenir un état stable.

On traite d'abord ce qui réduit le plus de risque pour le moins d'effort, puis on industrialise. Chaque vague des sections suivantes (conformité, Kubernetes, security by design) vient compléter ce socle, jamais s'y substituer.

Conformité et souveraineté : le lien avec la sécurisation

Sécurité et conformité ne se confondent pas, mais une infrastructure bien sécurisée produit l'essentiel des preuves qu'exige la conformité. Les piliers décrits plus haut alimentent directement les cadres : le chiffrement avec clés clientes et les sauvegardes immuables servent l'article 32 du RGPD ; la journalisation inaltérable et le moindre privilège nourrissent la démarche ISO/IEC 27001 ; le taux de couverture des CIS Benchmarks Azure et AWS devient un KPI de posture auditable. La sécurisation fournit la matière technique ; la mise en conformité la traduit en preuves opposables.

Pour les données sensibles, l'arbitrage est d'abord réglementaire : orientation vers une offre qualifiée pour limiter l'exposition aux lois extraterritoriales (CLOUD Act / FISA), et, en santé, hébergement chez un partenaire certifié HDS, la certification visant l'hébergeur, jamais vous. Les définitions complètes des cadres (RGPD art. 28/32, ISO 27001/27017/27018, SecNumCloud, HDS, DORA, NIS2, EUCS) et la roadmap de mise en conformité par phases sont détaillées sur la page sœur conformité cloud (RGPD, ISO, HDS). Les secteurs les plus exposés disposent d'approches dédiées : secteur santé et secteur finance.

Les outils natifs Azure et AWS, au niveau réel

C'est le levier que personne ne descend : nommer les outils, leur rôle et leur équivalent d'un cloud à l'autre. Voici la cartographie que nous utilisons en mission.

| Fonction | Microsoft Azure | AWS | |---|---|---| | Posture de sécurité (CSPM) | Microsoft Defender for Cloud | AWS Security Hub + AWS Config | | Détection de menaces | Microsoft Defender for Cloud (plans) | Amazon GuardDuty | | Identités & accès | Microsoft Entra ID (+ PIM) | AWS IAM Identity Center | | Politiques / garde-fous | Azure Policy | AWS Config Rules / SCP | | Gestion des clés & secrets | Azure Key Vault / Managed HSM | AWS KMS / Secrets Manager | | SIEM / SOAR | Microsoft Sentinel | Security Hub + SIEM tiers | | Conformité des configurations | Azure Policy + Defender for Cloud | AWS Config + Security Hub (CIS) | | Protection anti-DDoS | Azure DDoS Protection | AWS Shield | | Pare-feu applicatif | Azure WAF | AWS WAF |

CSPM, CWPP, CASB, CNAPP, CIEM : démêler les acronymes

Ces familles d'outils se chevauchent et la confusion fait acheter en double. Distinction nette :

• CSPM (Cloud Security Posture Management) : surveille les configurations et détecte les écarts (stockage public, MFA manquant). C'est la base.
• CWPP (Cloud Workload Protection Platform) : protège les charges de travail (VM, conteneurs), antimalware, détection runtime, gestion des vulnérabilités.
• CASB (Cloud Access Security Broker) : contrôle l'usage des applications SaaS, lutte contre le shadow IT, applique la DLP.
• CNAPP (Cloud-Native Application Protection Platform) : la génération récente qui unifie CSPM + CWPP (et plus) dans une plateforme unique, du code au runtime. Defender for Cloud évolue vers ce modèle.
• CIEM : gère et rationalise les droits (entitlements) à grande échelle, l'écart entre permissions accordées et utilisées.

L'erreur classique consiste à empiler des produits qui se recouvrent. La bonne démarche : partir des outils natifs (souvent suffisants pour 80 % du besoin), mesurer les angles morts, puis ajouter une CNAPP seulement si la complexité multicloud le justifie.

Gestion des vulnérabilités, patch management et pentests

Sécuriser la configuration ne suffit pas : le code et les composants vieillissent.

• Gestion des vulnérabilités : scan continu des images, des VM et des dépendances (intégré à Defender for Cloud / GuardDuty et aux outils de la chaîne CI/CD).
• Patch management : application disciplinée des correctifs, automatisée autant que possible (Azure Update Manager, AWS Systems Manager Patch Manager). Un correctif appliqué tard est une fenêtre d'exposition.
• Pentest cloud : test d'intrusion ciblé pour valider l'exploitabilité d'une faille, complémentaire de l'audit de configuration, pas substituable. À cadrer selon les règles d'engagement du fournisseur.
• Chaîne d'approvisionnement logicielle : l'inventaire des composants et le scan des dépendances tierces relèvent de l'hygiène de base ; l'industrialisation au build de la supply chain logicielle (SBOM, SLSA, signature) relève de la démarche DevSecOps.

Sécurité Kubernetes et conteneurs : le volet à traiter à part

Les clusters conteneurisés (AKS, EKS, GKE) ajoutent une couche de risque que les six piliers génériques ne couvrent pas entièrement : RBAC propre au cluster, Network Policies entre pods, Pod Security à l'admission, chiffrement des secrets et de l'etcd. Dans la priorisation d'ensemble, ce chantier se traite comme un sous-domaine spécialisé, une fois les fondamentaux IAM, réseau et chiffrement déjà en place.

Le durcissement complet d'un cluster (modèle 4C, manifestes YAML déployables, admission control Kyverno/OPA, comparatif EKS/AKS/GKE et réponse à incident au niveau du pod) fait l'objet de la page sœur dédiée sécurité Kubernetes.

Security by design : empêcher la dérive dans le pipeline

Sécuriser durablement, c'est inscrire les garde-fous dans le pipeline plutôt que de corriger après coup : infrastructure décrite en code (Terraform, Bicep) et versionnée, scan IaC avant déploiement, policy as code qui bloque un déploiement non conforme, détection de drift entre l'état déclaré et l'état réel. Dans la trajectoire de sécurisation, ce volet prend le relais une fois la posture initiale assainie, c'est lui qui empêche les écarts de revenir.

L'industrialisation complète de cette « part client » de la responsabilité (security gates bloquants/alertants, SAST/DAST/SCA, gestion des secrets de pipeline et supply chain logicielle) est détaillée sur la page sœur DevSecOps cloud, en appui de nos pratiques infrastructure & DevOps.

Multicloud et hybride : une posture cohérente

Beaucoup d'organisations opèrent à la fois Azure, AWS et de l'on-premise. Le risque : des politiques de sécurité divergentes, des angles morts entre plateformes. La bonne pratique consiste à définir une politique de sécurité de référence unique (identités, chiffrement, journalisation, niveaux de durcissement CIS) puis à la décliner sur chaque plateforme avec ses outils natifs, en centralisant la détection dans un SIEM commun. La cohérence prime sur l'uniformité : on vise le même niveau de sécurité partout, pas le même outil partout. C'est l'objet de la gouvernance cloud.

Le facteur humain : formation et sensibilisation

La technique ne suffit pas. La majorité des compromissions débutent par une action humaine : un clic sur un lien de phishing, un secret partagé par messagerie, une clé laissée dans un dépôt public. La sensibilisation des équipes, développeurs comme métiers, fait partie intégrante de la sécurisation : reconnaître le phishing, manier les secrets correctement, comprendre le moindre privilège. Une politique de sécurité que personne ne comprend n'est pas appliquée.

Combien ça coûte, combien de temps, quels livrables ?

Architecte Cloud assume la transparence : voici les fourchettes indicatives. Le périmètre réel se chiffre sur devis après un échange de cadrage, car le coût dépend du nombre de comptes/abonnements, de la criticité des données et du niveau de conformité visé.

• Budget indicatif : de 7 000 à 18 000 € pour une prestation de sécurisation, selon le périmètre et la profondeur attendue. À présenter comme une fourchette de départ, ajustée au contexte.
• Durée indicative : de 3 à 10 jours pour la phase d'audit et de remédiation initiale, hors run.

Le déroulé d'un projet de sécurisation

1. Cadrage & diagnostic (jours 1 à 3) : inventaire, évaluation de la posture face aux CIS Benchmarks et aux référentiels applicables, matrice de risques hiérarchisée.
2. Remédiation priorisée (jours 3 à 8) : correction des risques critiques d'abord (IAM, exposition réseau, chiffrement, journalisation), industrialisée en IaC quand c'est pertinent.
3. Run & supervision (récurrent, optionnel) : supervision continue, détection-réponse, revue de posture périodique, dans le cadre d'une infogérance ou d'un SOC managé.

Les livrables

• Une matrice de risques hiérarchisée (criticité, exploitabilité, effort).
• Un plan de remédiation priorisé et chiffré.
• Le code IaC des correctifs, versionné dans vos dépôts.
• Un rapport de posture avec taux de couverture CIS et indicateurs.
• La documentation d'exploitation et les runbooks de réponse à incident.

Notre engagement d'autonomie : tout ce que construisent les prestataires de notre réseau vous appartient. Code IaC dans vos dépôts, comptes cloud à votre nom, documentation remise. Aucun enfermement : vous restez libre de reprendre la main ou de changer de prestataire. La réversibilité fait partie du livrable, pas des petits caractères.

Piloter par des KPI mesurables

On ne sécurise bien que ce que l'on mesure. Les indicateurs que nous suivons :

• Taux de couverture CIS : pourcentage de contrôles conformes, suivi dans le temps.
• Nombre de findings critiques ouverts et leur âge.
• MTTD (Mean Time To Detect) et MTTR (Mean Time To Respond) : délais moyens de détection et de réponse, observés et améliorés à mesure que la supervision mûrit.
• Dérive de conformité : nombre d'écarts apparus depuis la dernière revue.

Ces métriques transforment la sécurité d'un sujet anxiogène en un tableau de bord pilotable, et prouvent le ROI à la direction.

Checklist de sécurisation cloud

Un récapitulatif actionnable des fondamentaux :

• [ ] MFA activée sur tous les comptes humains, sans exception
• [ ] Moindre privilège appliqué ; aucune clé d'accès longue durée inutilisée
• [ ] Aucun stockage exposé en lecture publique
• [ ] Pas de port d'administration (RDP/SSH) ouvert sur Internet
• [ ] Chiffrement au repos et en transit ; clés gérées via Key Vault / KMS
• [ ] Sauvegardes immuables et isolées (règle 3-2-1 durcie)
• [ ] PRA testé, avec RTO/RPO validés par exercice réel
• [ ] Journalisation centralisée, inaltérable et conservée
• [ ] Détection active (Defender for Cloud / GuardDuty + SIEM)
• [ ] Politiques en policy as code, scan IaC en CI/CD
• [ ] Mapping de conformité (RGPD, ISO 27001, HDS/DORA/NIS2 si applicable)
• [ ] Runbook de réponse à incident, dont notification CNIL sous 72 h

Pourquoi Architecte Cloud

Sécuriser un cloud demande de descendre au niveau de la configuration tout en restant lisible pour la direction. C'est précisément là que nous intervenons : cadrer votre besoin de sécurité, puis vous mettre en relation avec des prestataires qualifiés qui conduisent les projets de bout en bout.

• Intermédiaire indépendant : nous nous appuyons sur des prestataires Microsoft Azure Partner (Solutions Partner, Infrastructure) et AWS Partner (Advanced Tier Services), pour un conseil dual-cloud sans parti pris.
• Experts qualifiés : prestataires disposant des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer). Démarche ISO 27001.
• Conformité française maîtrisée : RGPD (art. 28/32), hébergement chez un partenaire certifié HDS, exigences DORA et NIS2, orientation SecNumCloud pour les données les plus sensibles.
• Autonomie & transparence : votre code, vos comptes, votre documentation. Coûts clairs, réversibilité réelle.

Pour aller plus loin : nos services, le conseil en architecture, la cybersécurité cloud, et le guide du cloud. Pour évaluer votre exposition, démarrez par un diagnostic en ligne ou contactez-nous, réponse sous 48 h ouvrées.

FAQ : Sécurisation d'infrastructure cloud

Comment sécuriser son infrastructure cloud ?

En agissant sur six leviers dans le bon ordre : d'abord les identités (MFA partout, moindre privilège), puis la réduction de la surface d'exposition (aucun stockage public, aucun port d'administration ouvert), le chiffrement avec clés gérées, la résilience (sauvegardes immuables, PRA testé), la détection (journalisation centralisée, SIEM), enfin la conformité. La démarche commence toujours par un diagnostic de la posture face aux CIS Benchmarks pour prioriser ce qui réduit le plus de risque pour le moins d'effort.

Quels sont les principaux risques de sécurité du cloud ?

Par ordre de fréquence observé : les erreurs de configuration (stockage exposé, règles réseau ouvertes), le vol d'identifiants (clés dans Git, comptes sans MFA), les attaques d'API, le ransomware, le DDoS et le shadow IT. La majorité des incidents viennent d'une erreur côté client, pas d'une faille du fournisseur, d'où l'importance de réduire d'abord la surface d'exposition.

Qui est responsable de la sécurité dans le cloud : le fournisseur ou l'entreprise ?

Les deux, selon le modèle de responsabilité partagée. Le fournisseur sécurise le cloud (datacenters, matériel, hyperviseur) ; le client sécurise ce qu'il met dans le cloud. Les données, les identités et la configuration restent toujours de votre responsabilité, quel que soit le modèle IaaS, PaaS ou SaaS.

Qu'est-ce que le modèle de responsabilité partagée ?

C'est le cadre qui répartit les obligations de sécurité entre le fournisseur cloud (CSP) et le client. La frontière se déplace selon le service : en IaaS, le client gère l'OS et au-dessus ; en PaaS, le fournisseur prend l'OS et le runtime ; en SaaS, presque tout sauf les données, les identités et la configuration, qui restent côté client dans tous les cas.

Qu'est-ce que l'approche Zero Trust dans le cloud ?

Le Zero Trust ne fait jamais confiance par défaut et vérifie chaque accès. Trois principes : vérifier explicitement chaque requête selon le contexte de risque, appliquer le moindre privilège (accès juste-à-temps), et présumer la compromission (segmentation, chiffrement, journalisation). C'est une architecture qui se construit par étapes, pas un produit que l'on achète.

Quelle est la différence entre CSPM, CWPP et CNAPP ?

Le CSPM surveille les configurations et détecte les écarts de posture. Le CWPP protège les charges de travail (VM, conteneurs) au niveau runtime. Le CNAPP est la génération récente qui unifie CSPM et CWPP dans une plateforme unique, du code au runtime. À ces familles s'ajoutent le CASB (usage SaaS, shadow IT) et le CIEM (rationalisation des droits d'accès).

Le cloud est-il plus sûr qu'une infrastructure sur site ?

Le cloud peut être plus sûr, à condition d'être bien configuré : les fournisseurs investissent massivement dans la sécurité physique et la résilience. Mais rien ne garantit qu'un cloud mal paramétré le soit : une mauvaise configuration s'y réplique plus vite qu'on-premise. La sécurité dépend moins de la plateforme que de la rigueur avec laquelle on l'exploite.

Comment chiffrer ses données dans le cloud ?

Au repos, les données sont chiffrées par défaut sur Azure et AWS ; le vrai sujet est la gestion des clés. Pour les données sensibles, privilégiez les clés gérées par le client (CMK) via Azure Key Vault ou AWS KMS, plutôt que les clés du fournisseur, afin de garder le contrôle de la révocation. En transit, imposez TLS sur tous les flux, y compris internes.

Quels outils utiliser pour sécuriser Azure et AWS ?

Côté Azure : Microsoft Defender for Cloud (posture et détection), Entra ID avec PIM (identités), Azure Policy (garde-fous), Key Vault (clés et secrets), Microsoft Sentinel (SIEM). Côté AWS : Security Hub et AWS Config (posture), GuardDuty (détection), IAM Identity Center (identités), KMS et Secrets Manager (clés). Les outils natifs couvrent l'essentiel du besoin ; une CNAPP ne se justifie qu'en contexte multicloud complexe.

Combien coûte la sécurisation d'une infrastructure cloud ?

À titre indicatif, une prestation de sécurisation se situe dans une fourchette de 7 000 à 18 000 €, et de 3 à 10 jours pour l'audit et la remédiation initiale, hors supervision continue. Le coût réel dépend du nombre de comptes, de la criticité des données et du niveau de conformité visé ; il est établi sur devis après un échange de cadrage.

Comment sécuriser un environnement multicloud ou hybride ?

En définissant une politique de sécurité de référence unique (identités, chiffrement, journalisation, durcissement CIS) puis en la déclinant sur chaque plateforme avec ses outils natifs, tout en centralisant la détection dans un SIEM commun. L'objectif est d'atteindre le même niveau de sécurité partout, pas d'imposer le même outil partout. C'est un travail de gouvernance autant que de technique.