Audit de sécurité cloud

Un audit de sécurité cloud, c'est l'examen méthodique de tout ce qui protège (ou expose) votre environnement Azure ou AWS : identités, réseau, chiffrement, configurations, journalisation, et conformité aux référentiels qui vous engagent. Le but n'est pas de produire de la peur, mais de la clarté : savoir précisément où vous êtes exposé, ce que cela coûterait, et dans quel ordre corriger. Cette page détaille la méthode, le périmètre réel, les prix indicatifs, le comparatif Azure contre AWS et le mapping de conformité française que la plupart des prestataires laissent de côté.

Qu'est-ce qu'un audit de sécurité cloud ?

Un audit de sécurité cloud est l'examen structuré et indépendant des configurations, des accès et des mécanismes de protection d'un environnement hébergé sur une plateforme de cloud public (Microsoft Azure, AWS, parfois Google Cloud) ou en mode hybride, confronté à un ou plusieurs référentiels de sécurité reconnus (CIS Benchmarks, ISO/IEC 27001, Azure / AWS Well-Architected, recommandations de l'ANSSI). Il aboutit à une matrice de risques hiérarchisée et à un plan de remédiation priorisé.

Concrètement, l'audit couvre cinq grandes familles de contrôle : la gestion des identités et des accès (IAM), la sécurité du réseau, la protection des données, le durcissement des configurations, et la supervision/détection. Il ne se contente pas de lancer un scanner : il replace chaque constat dans son contexte d'exploitation (qui gère quoi, comment les changements sont déployés, quelle gouvernance encadre les ressources) pour distinguer une alerte cosmétique d'un risque réellement exploitable.

À retenir : un audit de sécurité cloud répond à trois questions de direction : « Suis-je attaquable ? », « Par où ? », « Dans quel ordre corriger ? ». Tout le reste n'est que méthode pour y répondre avec des preuves, pas avec des impressions.

Audit de sécurité, pentest, audit de configuration, audit de conformité

Ces quatre termes circulent souvent comme des synonymes. Ils désignent des exercices distincts, complémentaires, avec des finalités et des destinataires différents. La confusion coûte cher : on commande un pentest là où il fallait un audit de configuration, ou l'inverse.

| Démarche | Question centrale | Référentiel / méthode | Ce qu'elle ne fait pas | |---|---|---|---| | Audit de sécurité cloud | L'environnement cloud est-il attaquable, et où ? | CIS, Well-Architected, ISO 27001, modèle de menace, MITRE ATT&CK for Cloud | Exploiter activement les failles jusqu'à l'intrusion | | Pentest cloud (test d'intrusion) | Une faille précise est-elle réellement exploitable ? | Approche offensive, scénarios d'attaque réels | Couvrir la totalité du périmètre à grande échelle | | Audit de configuration | Les paramètres techniques suivent-ils les bonnes pratiques ? | CIS Benchmarks, baselines du fournisseur | Croiser les constats avec vos obligations légales | | Audit de conformité | Respecte-t-on les obligations légales et normatives ? | RGPD, ISO 27001, NIS2, DORA, HDS, SecNumCloud | Évaluer l'exploitabilité technique d'une faille |

L'audit de sécurité et le pentest sont complémentaires : l'audit révèle des mauvaises configurations à grande échelle (un bucket public, un rôle trop permissif, un compte sans MFA), le pentest valide qu'une faille précise est exploitable jusqu'au bout. La plupart des organisations ont d'abord besoin de l'audit : il traite l'essentiel du risque en s'attaquant aux configurations, avant même de tester l'exploitabilité. Pour le volet purement normatif, voyez l'audit de conformité cloud ; pour la vue d'ensemble de l'état de santé d'une plateforme, le pilier audit d'infrastructure cloud.

Pourquoi auditer la sécurité de son cloud : enjeux, risques et déclencheurs

Le cloud a souvent été adopté vite, dans l'urgence d'un projet ou d'une migration. Les ressources se sont empilées, les comptes se sont multipliés, les accès ont été ouverts « provisoirement ». Un audit remet de la lisibilité là où s'accumulent les angles morts.

Les risques concrets, par ordre de fréquence

Contrairement à l'imaginaire de l'attaquant sophistiqué, la majorité des incidents cloud proviennent d'une erreur de configuration côté client, pas d'une faille du fournisseur. Les schémas qui reviennent le plus souvent :

• Stockage exposé en public : un bucket S3 ou un compte de stockage Azure ouvert en lecture anonyme, exposant des sauvegardes, des exports clients ou des journaux contenant des secrets.
• Identités trop permissives : des rôles d'administration distribués trop largement, des clés d'accès jamais expirées, des comptes orphelins d'anciens collaborateurs ou prestataires.
• Secrets en clair : clés d'API, chaînes de connexion ou mots de passe versionnés dans un dépôt Git, présents dans des variables d'environnement non chiffrées ou des fichiers d'IaC.
• Surfaces d'administration ouvertes : ports SSH/RDP ou consoles d'administration exposés sur Internet sans bastion ni filtrage, cibles directes de bots et de ransomware.
• Détection aveugle : journalisation désactivée ou non centralisée, absence d'alerte sur les actions sensibles : une intrusion peut alors durer des semaines sans être vue.

Ces écarts conduisent aux trois familles de conséquences que tout dirigeant redoute : fuite de données (exposition publique, exfiltration via une identité compromise), ransomware (chiffrement des données et des sauvegardes mal isolées), et sanction réglementaire (RGPD, NIS2) le jour d'un contrôle ou d'une notification d'incident.

Les déclencheurs typiques d'un audit

Dans notre expérience d'intermédiaire, un audit de sécurité cloud est presque toujours déclenché par l'un de ces six événements :

1. Un incident ou une alerte (tentative d'intrusion, alerte du fournisseur, phishing réussi) qui révèle qu'on ne sait pas vraiment où l'on est exposé.
2. Une exigence client ou contractuelle : un grand compte impose une preuve de sécurité avant de signer, ou un questionnaire sécurité long de 200 lignes.
3. Une obligation réglementaire qui entre en vigueur : NIS2, DORA, HDS selon le secteur.
4. Une démarche de certification ISO 27001 ou SecNumCloud, pour laquelle l'audit cloud est un prérequis.
5. Une migration ou une croissance rapide : l'environnement a grossi plus vite que la gouvernance, et personne n'a une vue d'ensemble.
6. Un changement d'équipe : départ de la personne qui « savait », ou reprise d'un cloud non documenté, un cas si fréquent qu'il mérite sa propre page : cloud non documenté, que faire ?.

Un audit n'est pas une dépense de confort. C'est l'instrument qui transforme une infrastructure subie en infrastructure pilotée : on cesse de réagir aux incidents pour décider sur preuves.

Le modèle de responsabilité partagée : le fondement de tout audit

Impossible d'auditer sérieusement un cloud sans poser d'abord la frontière des responsabilités. Le modèle de responsabilité partagée définit ce qui relève du fournisseur (Azure, AWS) et ce qui relève de vous, le client. C'est la ligne de démarcation qui détermine ce que l'audit peut et doit examiner.

La règle est constante : le fournisseur est responsable de la sécurité du cloud (datacenters, matériel, hyperviseur, réseau physique, services managés sous-jacents), et vous êtes responsable de la sécurité dans le cloud (vos données, vos identités, vos configurations, votre réseau virtuel, le chiffrement que vous activez ou non). Le niveau de responsabilité varie selon le modèle de service.

| Couche | IaaS (VM) | PaaS (service managé) | SaaS | |---|---|---|---| | Données et classification | Client | Client | Client | | Identités et accès (IAM) | Client | Client | Client (partagé) | | Configuration applicative | Client | Client | Fournisseur (partagé) | | Système d'exploitation | Client | Fournisseur | Fournisseur | | Réseau virtuel / firewall | Client | Partagé | Fournisseur | | Hyperviseur / infrastructure physique | Fournisseur | Fournisseur | Fournisseur |

Le malentendu le plus coûteux : croire que « le cloud est sécurisé par défaut ». Le fournisseur sécurise son infrastructure ; vos données, vos accès et vos configurations restent votre responsabilité, quel que soit le modèle. Les identités et la donnée ne quittent jamais votre périmètre. C'est précisément là que l'audit concentre son énergie : sur la part que vous maîtrisez, et que vous êtes le seul à pouvoir corriger.

Périmètre et cadrage de l'audit

Un audit utile commence par un cadrage net. Auditer « le cloud » sans périmètre, c'est garantir un rapport flou. Le cadrage répond à quatre questions.

Quels environnements et quels comptes ?

• Multi-cloud : un seul fournisseur, deux, ou trois (Azure + AWS + GCP) ? Chaque plateforme a sa propre matrice de contrôles.
• Hybride : des passerelles, des interconnexions VPN/ExpressRoute/Direct Connect vers un datacenter on-premise élargissent la surface.
• Environnements : production, préproduction, développement, sandbox. Un audit sérieux ne s'arrête pas à la prod : les environnements de dev et les sandbox « temporaires » sont des points d'entrée fréquents, souvent sans MFA ni journalisation.

Quel inventaire des actifs ?

On n'audite pas ce qu'on ne connaît pas. La première phase technique reconstitue l'inventaire réel : abonnements et comptes, ressources actives, identités humaines et machines, expositions publiques, dépôts d'IaC. Sur un cloud non documenté, cet inventaire est souvent la première révélation : des ressources « oubliées » que plus personne ne pilote. Si c'est votre cas, lisez remettre de l'ordre dans son cloud.

Un bon cadrage fixe aussi ce qui est hors périmètre (les postes de travail, le SI on-premise, le code applicatif détaillé) pour éviter le malentendu et concentrer l'effort là où il compte.

Les domaines d'un audit de sécurité cloud

Un audit complet examine six domaines techniques. Chacun peut faire l'objet d'un approfondissement dédié, mais un diagnostic sérieux les couvre tous pour donner une vue cohérente.

1. Audit IAM : identités et gestion des accès

L'identité est le nouveau périmètre. Dans un cloud, une identité compromise ou trop permissive vaut une porte d'entrée directe. L'audit IAM vérifie notamment :

• MFA activé sur tous les comptes, en priorité absolue sur les comptes à privilèges et les comptes d'urgence (« break-glass »).
• RBAC et moindre privilège : les rôles attribués correspondent-ils au besoin réel, ou trouve-t-on des permissions excessives (*:*, rôles Owner/AdministratorAccess distribués sans justification) ?
• Comptes orphelins : identités d'anciens collaborateurs ou prestataires toujours actives, clés d'accès jamais expirées.
• Escalade de privilèges : chemins d'attaque où une identité peu privilégiée peut, via un rôle assumable ou une politique mal écrite, obtenir des droits d'administration.
• Identités machines : principals de service, rôles d'instance, identités managées, souvent les plus négligées et les plus puissantes.

Constat récurrent sur les environnements que nous auditons : le risque numéro un n'est presque jamais une faille « zero-day », mais une accumulation d'accès jamais nettoyés. Le moindre privilège n'est pas un état, c'est une discipline.

2. Audit réseau

L'audit réseau mesure la surface d'exposition et la qualité de la segmentation :

• Segmentation : les VPC (AWS) / VNet (Azure) sont-ils découpés par environnement et par sensibilité, ou tout cohabite-t-il à plat ?
• Security Groups / NSG : trouve-t-on des règles 0.0.0.0/0 ouvrant des ports d'administration (22, 3389) ou des bases de données sur Internet ?
• Exposition publique : quelles ressources ont une adresse IP publique, et est-ce justifié ?
• Bastions et accès d'administration : l'administration passe-t-elle par un bastion (Azure Bastion, AWS Systems Manager Session Manager) plutôt que par des ports ouverts ?
• WAF et protection périmétrique : les applications exposées sont-elles protégées par un pare-feu applicatif et une protection anti-DDoS ?

3. Audit de la protection des données

• Chiffrement au repos : activé sur les disques, le stockage objet, les bases managées et les sauvegardes ? Avec des clés gérées par le fournisseur ou par le client ?
• Chiffrement en transit : TLS imposé partout, sans rétrocompatibilité avec des protocoles obsolètes ?
• Gestion des clés et des secrets : usage d'un coffre dédié (Azure Key Vault, AWS KMS, HashiCorp Vault) plutôt que des secrets en dur ? Rotation des clés ? Séparation des droits ?
• Sauvegardes et rétention : existent-elles, sont-elles isolées (à l'abri d'un ransomware qui chiffrerait aussi les backups), testées en restauration, et conformes à votre politique de rétention ?

4. Audit des configurations et durcissement (CIS Benchmarks)

C'est le cœur technique. On confronte chaque service aux CIS Benchmarks et aux baselines du fournisseur pour traquer les misconfigurations :

• Services managés (bases de données, files de messages, fonctions) ouverts ou mal paramétrés.
• Conteneurs et Kubernetes (AKS, EKS) : RBAC du cluster, network policies, admission control, Pod Security, secrets, images non scannées, comptes de service trop permissifs. Pour aller au fond : audit Kubernetes.
• Serverless (Azure Functions, AWS Lambda) : permissions des fonctions, variables d'environnement contenant des secrets, exposition des endpoints.

5. Audit du logging, de la supervision et de la détection

Une intrusion non détectée est une intrusion réussie. L'audit vérifie la couverture de détection :

• Traçabilité : AWS CloudTrail / Azure Monitor activés sur tous les comptes, journaux centralisés, immuables et conservés assez longtemps.
• Détection managée : Microsoft Defender for Cloud, AWS GuardDuty, AWS Security Hub activés et exploités, pas seulement allumés.
• SIEM et alerting : les événements sensibles (création de rôle admin, désactivation de journal, accès anormal) déclenchent-ils une alerte vers une équipe qui la traite ?

6. Audit de l'IaC et du pipeline CI/CD (DevSecOps)

Domaine que presque aucun concurrent ne traite, et pourtant décisif : la sécurité se joue avant le déploiement. Auditer le code d'infrastructure (Terraform, Bicep, CloudFormation) et le pipeline permet de corriger une misconfiguration à la source, une fois, plutôt que sur des centaines de ressources déployées :

• Analyse statique de l'IaC (recherche de buckets publics, de chiffrement absent, de règles réseau trop larges dans le code lui-même).
• Gestion du state Terraform (chiffré, à accès restreint), gestion du drift entre le code et la réalité.
• Sécurité du pipeline : secrets du CI/CD, droits des runners, scan des images et des dépendances avant apply.

Cette approche DevSecOps relie l'audit à la cybersécurité cloud et à l'infrastructure DevOps.

Comparatif Azure vs AWS : auditer côte à côte

Auditer Azure et AWS demande de connaître les équivalences de services. Voici la correspondance que nous utilisons, posée côte à côte, un repère qu'aucune page concurrente ne fournit clairement.

| Domaine | Microsoft Azure | AWS | |---|---|---| | Identités / IAM | Microsoft Entra ID | AWS IAM / IAM Identity Center | | Détection des menaces | Microsoft Defender for Cloud | AWS GuardDuty + Security Hub | | Posture & conformité | Defender for Cloud (Secure Score) | AWS Config + Security Hub | | Politiques / garde-fous | Azure Policy | Service Control Policies (SCP) | | Gestion des clés/secrets | Azure Key Vault | AWS KMS + Secrets Manager | | Journalisation des actions | Azure Monitor / Activity Log | AWS CloudTrail | | Réseau virtuel | VNet + NSG | VPC + Security Groups | | Accès d'administration | Azure Bastion | Systems Manager Session Manager | | Kubernetes managé | AKS | EKS | | Serverless | Azure Functions | AWS Lambda | | Infrastructure as Code natif | Bicep / ARM | CloudFormation | | Landing zone / structure | Cloud Adoption Framework | Control Tower / Landing Zone Accelerator | | Cadre d'architecture | Azure Well-Architected | AWS Well-Architected (6 piliers) |

Sur Azure, l'audit s'appuie largement sur le Secure Score de Defender for Cloud et la couverture Azure Policy ; sur AWS, sur l'AWS Well-Architected Review (pilier sécurité) croisée avec Config et Security Hub. En tant qu'intermédiaire indépendant, nous vous orientons vers des prestataires qui mènent les deux selon la même grille de risque, sans privilégier une plateforme par intérêt commercial. Pour un approfondissement par plateforme : audit Azure, audit AWS et l'AWS Well-Architected Review.

Méthodologie d'audit en cinq étapes

Notre méthode suit cinq étapes, du cadrage au plan d'action. C'est cette structure qui transforme un scan en décision.

1. Cadrage : On définit le périmètre (comptes, environnements, domaines), les référentiels applicables, les interlocuteurs et les accès en lecture seule. On fixe ce qui est dans et hors périmètre. Durée : une demi-journée à une journée.
2. Collecte : On reconstitue l'inventaire et on collecte les configurations via des accès en lecture seule et des outils dédiés (CSPM, Prowler, ScoutSuite). Aucune action intrusive sur la production.
3. Analyse : On confronte les constats aux CIS Benchmarks, au Well-Architected et aux référentiels de conformité. On qualifie chaque écart par sévérité (critique / élevé / moyen / faible) et par effort de correction, et on écarte les faux positifs.
4. Restitution : On présente les résultats en deux temps : une synthèse pour la direction (risques majeurs, score, trajectoire), un détail pour les équipes techniques (chaque constat, sa preuve, sa remédiation).
5. Plan de remédiation priorisé : On livre une feuille de route séquencée par risque et par effort, structurée en horizons d'action (voir plus bas la trajectoire 48h / 30j / 90j).

La valeur d'un audit ne tient pas au nombre de findings, mais à la qualité de la priorisation. Cent alertes non hiérarchisées paralysent ; dix risques classés par impact font agir.

Livrables d'un audit de sécurité cloud

Un audit sérieux produit des livrables exploitables à plusieurs niveaux, pas un PDF que personne ne rouvre :

• Rapport exécutif (5 à 10 pages) : posture globale, top des risques, score de maturité, trajectoire et budget de remédiation, en langage clair pour la direction.
• Rapport technique détaillé : chaque constat avec sa preuve (capture, identifiant de ressource), sa sévérité, son référentiel de rattachement (CIS, ISO, RGPD) et sa procédure de correction.
• Score et matrice de maturité : note par domaine (IAM, réseau, données, configuration, détection) pour situer les écarts et mesurer la progression d'un audit à l'autre.
• Matrice de risques : croisement probabilité × impact, pour décider en connaissance de cause.
• Plan d'action priorisé : la feuille de route séquencée, chiffrée et assignable.

Côté Architecte Cloud, deux principes différencient nos livrables : ils vous appartiennent (remis dans vos dépôts, réutilisables), et toute correction d'infrastructure que nous proposons est livrée en IaC versionné : pas une intervention manuelle invisible, mais du code que vous gardez et rejouez. C'est notre exigence d'autonomie et de réversibilité : à la fin, vous n'êtes prisonnier de personne.

Référentiels, outils et conformité

Référentiels de sécurité

Un audit s'appuie sur des cadres reconnus plutôt que sur l'opinion de l'auditeur : CIS Benchmarks (durcissement par service), ISO/IEC 27001 (système de management de la sécurité), NIST (cadre de gestion des risques), CSA (Cloud Security Alliance, contrôles cloud), Azure / AWS Well-Architected (pilier sécurité), et MITRE ATT&CK for Cloud pour cartographier les techniques d'attaque réelles.

Outils d'audit cloud

Nous combinons des outils open source et des plateformes de posture :

• Prowler et ScoutSuite : audit de configuration multi-cloud, open source, contrôles alignés CIS.
• CSPM / CNAPP (Cloud Security Posture Management / Cloud-Native Application Protection Platform) : surveillance continue de la posture.
• AWS Config et Azure Policy : évaluation continue de la conformité des ressources aux règles définies.

L'outil ne fait pas l'audit. Il produit des données brutes que l'expertise transforme en risques priorisés. Un scan sans interprétation, c'est du bruit.

Mapping de conformité française et européenne

C'est ici que l'essentiel des pages concurrentes décroche : elles citent HIPAA et PCI-DSS américains et ignorent le cadre français. Voici le croisement réel entre un audit cloud et vos obligations.

| Cadre | Qui est concerné | Ce que l'audit cloud vérifie | |---|---|---| | RGPD (art. 28 & 32) | Toute organisation traitant des données personnelles | Mesures techniques (art. 32 : chiffrement, journalisation, contrôle d'accès), encadrement du sous-traitant (art. 28), localisation et transferts | | NIS2 | Entités « essentielles » et « importantes » (élargies depuis la transposition de 2024) | Mesures de gestion du risque cyber, traçabilité, gestion des incidents, responsabilité des dirigeants | | DORA | Finance, assurance, prestataires critiques | Résilience opérationnelle, tests, gestion du risque tiers (votre fournisseur cloud), réversibilité et plans de sortie | | HDS | Hébergement de données de santé | Hébergement chez un partenaire certifié HDS, traçabilité, chiffrement, contractualisation conforme | | SecNumCloud | Cloud de confiance, secteurs sensibles, État | Exigences renforcées de sécurité et de localisation, immunité aux lois extraterritoriales | | PASSI | Prestataires d'audit qualifiés par l'ANSSI | Qualification de l'auditeur pour les audits réglementés | | ISO/IEC 27001 | Démarche de certification volontaire | Contrôles de l'Annexe A appliqués au cloud (accès, chiffrement, journalisation, continuité) |

Deux précisions importantes pour rester exact. La certification HDS vise l'hébergeur, jamais votre configuration ni le prestataire d'audit : l'audit vérifie que vous hébergez bien chez un partenaire certifié HDS et que votre usage est conforme. ISO 27001 est une démarche. Architecte Cloud travaille selon une démarche ISO 27001 sans revendiquer une certification que seul un organisme accrédité délivre. Pour le détail réglementaire complet, voyez l'audit de conformité cloud, et selon votre secteur les pages santé, finance ou SaaS.

Combien coûte un audit de sécurité cloud ? Durée, prix et livrables

Question que tout le top 10 évite. Nous y répondons, en restant honnête : un prix dépend toujours du périmètre réel. Les fourchettes ci-dessous sont indicatives, établies sur le marché français, et confirmées sur devis après cadrage.

| Format | Pour qui | Durée typique | Budget indicatif | |---|---|---|---| | Audit flash | PME, périmètre cloud unique et restreint | 2 jours | À partir de ~4 000 € | | Audit standard | ETI, environnement structuré, un à deux fournisseurs | 3 à 4 jours | ~5 000 à 7 000 € | | Audit approfondi | Grand compte, multi-cloud, conformité réglementée | 5 jours et plus | 8 000 € et au-delà, sur devis |

Pour l'audit de sécurité cloud présenté ici, comptez un budget indicatif de 4 000 à 8 000 € pour une durée de 2 à 5 jours, selon le nombre de comptes, d'environnements et de référentiels à couvrir. Les audits qualifiés PASSI (ANSSI), requis pour certains contextes réglementaires, se facturent généralement à un TJM supérieur et sortent de cette grille standard.

Ce qui est inclus : le cadrage, la collecte, l'analyse, la restitution en deux niveaux et le plan de remédiation priorisé décrits plus haut. Ce qui fait varier le prix : le nombre de plateformes (Azure seul, ou Azure + AWS), le nombre d'environnements, la profondeur sur Kubernetes et l'IaC, et l'exigence de conformité (un mapping RGPD/NIS2/DORA complet ajoute du temps d'analyse).

Transparence sur les coûts : pas de prix ferme avant de connaître votre périmètre, mais pas non plus de « sur devis » fumeux. La fourchette est posée, le devis l'affine. C'est notre principe d'indépendance : nous vendons une expertise, pas des licences.

Scénarios concrets de vulnérabilités et leur remédiation

Le concret parle mieux que la théorie. Voici quatre vulnérabilités que nous rencontrons régulièrement, leur scénario d'exploitation et la correction.

Bucket de stockage public

Constat : un bucket S3 (ou un conteneur Azure Blob) configuré en accès anonyme en lecture. Exploitation : un attaquant énumère les buckets et télécharge sauvegardes, exports et journaux : fuite de données sans même « entrer ». Remédiation : blocage de l'accès public au niveau du compte, politique restrictive, chiffrement, et alerte sur toute ressource redevenant publique.

Métadonnées d'instance non protégées (IMDSv1)

Constat : une instance utilise encore IMDSv1, le service de métadonnées sans protection contre le SSRF. Exploitation : via une faille applicative (SSRF), un attaquant interroge les métadonnées et récupère les identifiants temporaires du rôle de l'instance, donc ses droits cloud. Remédiation : imposer IMDSv2 (requête signée), limiter les permissions du rôle d'instance au strict nécessaire.

Secret en clair dans le code

Constat : une clé d'API ou une chaîne de connexion versionnée dans un dépôt Git ou une variable d'environnement. Exploitation : compromission du dépôt ou d'un poste, et l'attaquant dispose d'un accès valide et durable. Remédiation : rotation immédiate du secret, migration vers Key Vault / KMS / Vault, scan automatique des dépôts dans le pipeline pour bloquer toute fuite future.

Rôle assumable trop permissif

Constat : un rôle dont la politique de confiance autorise un principal trop large à l'assumer, avec des permissions d'administration. Exploitation : une identité peu privilégiée assume le rôle et obtient les droits d'admin : une escalade de privilèges. Remédiation : resserrer la politique de confiance, appliquer le moindre privilège, alerter sur les actions d'AssumeRole sensibles.

Que faire après l'audit : trajectoire de remédiation 48h / 30j / 90j

Un audit sans suite ne sert à rien. Notre plan de remédiation s'organise en trois horizons, pour que chaque équipe sache quoi faire et quand.

• Sous 48 heures : les risques critiques. Fermer les expositions publiques béantes, révoquer les accès compromis ou orphelins évidents, activer la MFA sur les comptes d'administration, faire tourner les secrets exposés. Ce sont les gestes qui réduisent immédiatement la surface d'attaque.
• Sous 30 jours : les risques élevés et la structure. Resserrer le RBAC et appliquer le moindre privilège, activer et centraliser la journalisation, déployer la détection managée (Defender for Cloud, GuardDuty), durcir les configurations selon les CIS Benchmarks.
• Sous 90 jours : la posture durable. Industrialiser via l'IaC et les garde-fous (Azure Policy, SCP), mettre en place une posture continue (CSPM), formaliser la gouvernance et planifier les audits suivants. C'est le passage de l'audit ponctuel à la maîtrise pérenne : la base d'une vraie sécurisation de l'infrastructure cloud.

Audit ponctuel ou posture continue (CSPM) : quand basculer ?

Un audit ponctuel est un instantané : il photographie votre posture à un moment donné. C'est indispensable pour faire l'état des lieux, prioriser et démarrer. Mais un cloud vit : on déploie tous les jours, et une configuration corrigée peut redevenir vulnérable la semaine suivante.

La posture continue (CSPM) surveille en permanence et alerte dès qu'une ressource s'écarte de la cible. La règle de bascule est simple :

• Audit ponctuel quand vous démarrez, que vous devez prouver un niveau à un instant T (certification, contrat, contrôle), ou que vos déploiements sont peu fréquents.
• Posture continue dès que votre rythme de déploiement est soutenu, que votre environnement est multi-comptes, ou que vous êtes soumis à des obligations permanentes (NIS2, DORA). On commence presque toujours par un audit ponctuel, qui sert de référence ; le CSPM prend ensuite le relais pour maintenir le niveau.

Audit de sécurité, FinOps et autonomie : l'angle Architecte Cloud

Sécurité et coûts ne sont pas des sujets opposés. Un environnement bien gouverné est à la fois plus sûr et moins cher : les ressources oubliées qu'on éteint sont autant de surface d'attaque en moins et de facture en moins. Notre audit de sécurité dialogue naturellement avec l'optimisation des coûts cloud et l'audit FinOps : un environnement maîtrisé sur le plan financier est presque toujours mieux tenu sur le plan sécurité.

Le différenciateur qui structure toute notre démarche : l'autonomie. Tout ce qui est construit vous appartient : code IaC versionné dans vos dépôts, comptes cloud à votre nom, documentation remise, réversibilité assurée. Nous ne vous enfermons pas dans une dépendance. En tant qu'intermédiaire indépendant Azure et AWS, nos recommandations ne sont pas orientées par la revente de licences ou de matériel : nous vous disons ce que nous voyons, pas ce qui nous arrange. C'est le sens de notre conseil en architecture.

Fréquence recommandée d'un audit de sécurité cloud

À quel rythme auditer ? La réponse dépend de votre exposition :

• Annuel : minimum pour toute organisation exploitant du cloud, et souvent attendu dans une démarche ISO 27001.
• Semestriel : recommandé pour les environnements en croissance rapide, multi-comptes, ou avec des déploiements fréquents.
• Continu (CSPM) : pour les secteurs régulés (finance/DORA, santé/HDS) et les organisations matures, en complément des audits ponctuels qui restent utiles comme point de contrôle externe et indépendant.

Un audit ponctuel reste pertinent même avec un CSPM en place : le regard externe, indépendant, attrape ce que l'œil interne, habitué, ne voit plus.

Cas sectoriels : des exigences d'audit spécifiques

L'audit n'est pas le même selon votre métier :

• Santé (HDS) : hébergement chez un partenaire certifié HDS, traçabilité renforcée des accès aux données de santé, chiffrement, contractualisation conforme. Voir secteur santé.
• Finance et assurance (DORA) : l'audit intègre la résilience opérationnelle, les tests, et surtout le risque tiers : votre fournisseur cloud devient un point d'attention réglementaire, avec exigence de réversibilité. Voir secteur finance.
• SaaS et scale-ups : l'enjeu est l'isolation multi-tenant, la rapidité des déploiements (donc l'IaC et le pipeline), et la capacité à répondre aux questionnaires sécurité des clients grands comptes. Voir secteur SaaS.
• Industrie et distribution : environnements hybrides, interconnexions avec l'OT ou les sites, et continuité d'activité. Voir industrie et distribution.
• Secteur public : exigences de souveraineté, SecNumCloud, localisation des données. Voir secteur public.

Pourquoi Architecte Cloud pour votre audit de sécurité

Choisir un prestataire d'audit, c'est choisir un regard. Les critères qui comptent vraiment, en langage clair :

• Indépendance : nous ne revendons ni licences ni matériel. Nos constats ne servent aucun intérêt commercial caché : c'est la condition d'un audit honnête.
• Double expertise Azure et AWS : nous vous mettons en relation avec des prestataires et experts qualifiés, partenaires Microsoft Azure et AWS, disposant des certifications requises (Azure Solutions Architect Expert, Azure Security Engineer, AWS DevOps Engineer Pro, CISSP) et engagés dans une démarche ISO 27001.
• Expérience : une expertise cloud éprouvée sur de nombreux projets Azure et AWS, portée par un réseau de prestataires reconnus. Nous avons vu les schémas d'erreur se répéter : c'est ce qui permet de prioriser vite.
• Réversibilité et autonomie : livrables dans vos dépôts, comptes à votre nom, aucune dépendance créée.
• Langage clair : un rapport que la direction comprend autant que les équipes techniques. La sécurité est une décision de gestion, pas seulement un sujet d'ingénieurs.

Pour comprendre notre approche au-delà de cette page, voyez nos services, notre page à propos et le guide du cloud.

Notre promesse n'est pas le « zéro risque » : rien ne garantit qu'un environnement ne sera jamais visé. Notre promesse, c'est la lucidité : savoir où vous en êtes, sur preuves, et avancer dans le bon ordre.

Passez à l'action

Si vous lisez ces lignes, c'est probablement que vous n'avez pas une vue claire de votre exposition. La première étape est simple et sans engagement : un diagnostic en ligne pour cadrer votre périmètre et identifier les priorités. Lancez-le sur notre page audit, ou décrivez votre contexte via le contact : réponse sous 48 h ouvrées.

Un audit de sécurité cloud bien mené ne vous laisse pas avec une liste d'angoisses. Il vous laisse avec un plan, une trajectoire et la sérénité de décider sur des faits.

FAQ : Audit de sécurité cloud

Qu'est-ce qu'un audit de sécurité cloud ?

C'est l'examen structuré et indépendant des configurations, des accès et des protections d'un environnement Azure ou AWS, confronté à des référentiels reconnus (CIS Benchmarks, ISO 27001, Well-Architected, recommandations ANSSI). Il produit une matrice de risques hiérarchisée et un plan de remédiation priorisé, pour savoir précisément où vous êtes exposé et dans quel ordre corriger.

Comment réaliser un audit de sécurité cloud ?

En cinq étapes : cadrage du périmètre et des référentiels, collecte des configurations via des accès en lecture seule et des outils dédiés (CSPM, Prowler, ScoutSuite), analyse des écarts par rapport aux CIS Benchmarks et au Well-Architected, restitution en deux niveaux (direction et technique), puis livraison d'un plan de remédiation priorisé par risque et par effort.

Quel est le prix d'un audit de sécurité cloud ?

Le budget indicatif se situe entre 4 000 et 8 000 € selon le périmètre. Comptez environ 4 000 € pour un audit flash de PME sur un cloud restreint, 5 000 à 7 000 € pour un audit standard d'ETI, et 8 000 € et plus pour un grand compte multi-cloud ou réglementé. Les audits qualifiés PASSI se facturent à un TJM supérieur. Le prix exact est confirmé sur devis après cadrage.

Combien de temps dure un audit de sécurité cloud ?

En général de 2 à 5 jours selon le périmètre : 2 jours pour un audit flash, 3 à 4 jours pour un audit standard, 5 jours et plus pour un environnement multi-cloud ou soumis à des exigences réglementaires fortes.

Quelle est la différence entre un audit de sécurité cloud et un pentest cloud ?

L'audit examine l'ensemble de l'environnement (configurations, IAM, réseau, données, détection) pour révéler les écarts à grande échelle. Le pentest, lui, est offensif : il cherche à exploiter réellement une faille précise jusqu'à l'intrusion. Les deux sont complémentaires, mais l'audit traite l'essentiel du risque en premier en corrigeant les mauvaises configurations.

Quels sont les domaines couverts par un audit de sécurité cloud ?

Six domaines : l'IAM (MFA, RBAC, moindre privilège, comptes orphelins), la sécurité réseau (segmentation, exposition publique, bastions), la protection des données (chiffrement, gestion des clés et secrets, sauvegardes), le durcissement des configurations (CIS Benchmarks, conteneurs, serverless), le logging et la détection (CloudTrail, Defender for Cloud, GuardDuty, SIEM), et l'IaC/CI-CD (DevSecOps).

À quelle fréquence faut-il auditer la sécurité de son cloud ?

Au minimum une fois par an. Un rythme semestriel est recommandé pour les environnements en croissance rapide ou multi-comptes. Les secteurs régulés (finance/DORA, santé/HDS) gagnent à compléter par une posture continue (CSPM), tout en conservant un audit ponctuel indépendant comme point de contrôle externe.

Qu'est-ce que la qualification PASSI de l'ANSSI ?

PASSI (Prestataire d'Audit de la Sécurité des Systèmes d'Information) est une qualification délivrée par l'ANSSI qui atteste de la compétence et de la déontologie d'un prestataire d'audit. Elle est requise dans certains contextes réglementaires ou pour des audits portant sur des systèmes sensibles. Un audit PASSI se facture généralement à un TJM supérieur à un audit standard.

Quels outils utiliser pour auditer la sécurité d'un cloud AWS ou Azure ?

Côté open source, Prowler et ScoutSuite réalisent un audit de configuration multi-cloud aligné sur les CIS Benchmarks. Côté natif, AWS Config et Azure Policy évaluent en continu la conformité des ressources, tandis que GuardDuty/Security Hub (AWS) et Defender for Cloud (Azure) assurent la détection. Les plateformes CSPM/CNAPP industrialisent la surveillance continue. L'outil produit des données ; l'expertise les transforme en risques priorisés.

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

C'est la répartition des responsabilités entre le fournisseur et le client. Le fournisseur sécurise « le cloud » (datacenters, matériel, hyperviseur, services managés) ; le client sécurise « dans le cloud » (ses données, identités, configurations, réseau virtuel, chiffrement). Le niveau de responsabilité du client diminue de l'IaaS au SaaS, mais les données et les identités restent toujours de sa responsabilité.

Un audit cloud est-il obligatoire avec NIS2 ou DORA ?

Ni NIS2 ni DORA n'imposent littéralement « un audit cloud » nommé, mais tous deux exigent une gestion documentée du risque cyber, de la traçabilité et de la résilience que seul un audit permet de démontrer. DORA ajoute la maîtrise du risque tiers, donc l'examen de votre fournisseur cloud et de la réversibilité. En pratique, l'audit est l'instrument naturel pour prouver la conformité.

Quels sont les livrables d'un audit de sécurité cloud ?

Un rapport exécutif pour la direction, un rapport technique détaillé avec preuves et procédures de correction, un score et une matrice de maturité par domaine, une matrice de risques (probabilité × impact) et un plan d'action priorisé. Chez Architecte Cloud, les correctifs d'infrastructure proposés sont livrés en IaC versionné dans vos dépôts, pour rester autonome et réversible.

Comment auditer la sécurité d'une infrastructure Azure ou AWS ?

Sur Azure, l'audit s'appuie sur le Secure Score de Defender for Cloud, la couverture Azure Policy et l'examen d'Entra ID, des VNet/NSG et de Key Vault. Sur AWS, il s'appuie sur l'AWS Well-Architected Review (pilier sécurité), Config, Security Hub, GuardDuty, et l'examen d'IAM, des VPC/Security Groups et de KMS. Un intermédiaire indépendant oriente vers des prestataires qui appliquent la même grille de risque aux deux plateformes.

Quelles sont les principales vulnérabilités trouvées lors d'un audit cloud ?

Les plus fréquentes : stockage exposé en public (bucket S3 ou conteneur Blob ouvert), comptes à privilèges sans MFA, permissions excessives et rôles assumables menant à l'escalade de privilèges, secrets en clair dans le code, ports d'administration ouverts sur Internet, métadonnées d'instance non protégées (IMDSv1), et journalisation absente ou non centralisée empêchant toute détection.