Ce que l’audit Cloud doit permettre de décider
L’audit permet de vérifier si la sécurité réellement configurée dans AWS ou Azure correspond au niveau de protection attendu par l’entreprise. Nous cherchons notamment les comptes trop puissants, les ressources publiques, les secrets partagés, les données trop accessibles, les sauvegardes dépendantes de la production et les pipelines capables de modifier le Cloud.
La restitution distingue ce qui doit être corrigé immédiatement, ce qui nécessite une évolution d’architecture, les accès ou ressources réellement exposés, les corrections qui peuvent être automatisées et les investissements susceptibles de réduire le plus le risque.
Que regardons-nous dans AWS et Azure ?
Comptes, abonnements et organisation Cloud
Nous vérifions si l’organisation Cloud reflète réellement les frontières de l’entreprise : comptes AWS, Organizations, comptes racine, tenants Azure, subscriptions, management groups, resource groups, environnements et responsabilités d’administration.
Production, développement, administration et projets sensibles doivent être suffisamment séparés pour éviter qu’un incident dans un périmètre donne automatiquement accès aux autres.
Identités, IAM et privilèges
Nous identifions les comptes administrateurs, rôles, groupes, MFA, SSO, comptes root ou Global Admin, droits temporaires, comptes dormants, prestataires, identités applicatives, clés persistantes et permissions héritées.
Nous cherchons les identités capables de modifier la production, lire les données ou augmenter leurs propres privilèges. L’objectif est de réduire les droits permanents et de rendre les accès sensibles explicites, attribuables et révocables, sans recopier la page de remédiation IAM.
Réseau Cloud et exposition Internet
Nous relisons VPC, VNet, subnets, Security Groups, NSG, NACL, gateways, load balancers, private endpoints, interfaces d’administration, IP publiques, accès inter-environnements, VPN et connectivité on-premise.
Nous cartographions les chemins permettant d’atteindre les ressources critiques depuis Internet, un autre workload ou le réseau interne. Une ressource n’est pas sécurisée uniquement parce qu’elle n’apparaît pas directement sur une page publique.
Données, stockage et chiffrement
Nous examinons buckets, object storage, bases, snapshots, volumes, fichiers, données publiques, politiques d’accès, chiffrement au repos et en transit, clés, partages inter-comptes et réplication.
Nous identifions quelles données sont sensibles, qui peut réellement les lire et par quels chemins elles peuvent être copiées ou exposées. Nous regardons aussi si des données de production se retrouvent dans des environnements de test.
Secrets, clés et identités techniques
Nous vérifions secrets applicatifs, clés API, credentials Cloud, variables CI/CD, secrets Kubernetes, clés SSH, certificats, tokens, rotation, coffres et secrets présents dans les dépôts.
Un secret ne doit pas devenir un mot de passe permanent partagé entre plusieurs équipes ou environnements. Nous vérifions où il est stocké, qui peut le lire, comment il est utilisé et s’il peut être renouvelé sans interrompre la production.
Workloads et services Cloud
Selon le périmètre, nous regardons machines virtuelles, conteneurs, Kubernetes, serverless, bases managées, API gateways, services applicatifs, images, registries, fonctions et services exposés.
Nous ne cherchons pas à auditer le code de toutes les applications. Nous vérifions principalement si un workload compromis pourrait atteindre davantage de ressources Cloud que nécessaire. Pour le code ou l’application elle-même, voir l’audit de sécurité applicative.
Logs, surveillance et détection
Pour AWS, nous regardons notamment CloudTrail, les logs IAM, les événements, les logs réseau et les alertes disponibles. Pour Azure, nous regardons Activity Logs, Entra, diagnostics, logs réseau et outils de détection.
L’entreprise doit savoir qui a créé, supprimé ou modifié une ressource critique. Nous vérifions que les événements importants sont enregistrés, centralisés et réellement exploitables lors d’une investigation.
Sauvegardes, reprise et résistance à une compromission
Nous vérifions snapshots, backups, rétention, comptes utilisés, séparation production / sauvegarde, immutabilité lorsque pertinente, accès à la suppression, restauration, réplication et tests de restauration.
Un compte ayant compromis la production ne devrait pas pouvoir supprimer les sauvegardes dans la même opération. L’existence d’une sauvegarde ne suffit pas si personne n’a validé sa restauration ou son niveau d’isolation.
Qui peut modifier la production ?
Le pipeline de déploiement fait partie du périmètre de sécurité lorsqu’il peut créer, modifier ou supprimer des ressources de production. Nous relisons GitHub Actions, GitLab CI, Azure DevOps, Terraform, Bicep, CloudFormation, runners, rôles de déploiement, approbations et branches protégées.
Nous vérifions si un dépôt compromis, un token exposé ou un runner mal isolé pourrait devenir un accès administrateur indirect au Cloud. Les changements manuels hors code sont également identifiés car ils rendent les corrections difficiles à relire et à reproduire.
Les scénarios que nous cherchons à éviter
Un compte développeur devient administrateur de production
Un compte est compromis. Des permissions trop larges lui permettent ensuite d’accéder aux environnements de production, aux secrets ou aux données critiques. L’audit vérifie si les rôles et frontières entre environnements empêchent ce scénario.
Une ressource Cloud est exposée sans que l’équipe le sache
Une IP publique, une règle réseau, un stockage ou une interface d’administration a été ajouté pour un besoin ponctuel puis laissé en place. L’audit confronte l’exposition réelle à l’architecture attendue.
Un prestataire conserve un accès critique
Un prestataire a participé à une migration ou à un projet. Son compte, son rôle ou sa clé permet encore de modifier des ressources plusieurs mois plus tard. Nous identifions les droits à supprimer, limiter ou rendre temporaires.
Un secret compromis ouvre plusieurs environnements
La même clé ou le même secret est réutilisé entre plusieurs services ou environnements. Une fuite locale devient alors une compromission beaucoup plus large.
La production et ses sauvegardes tombent ensemble
Les mêmes comptes disposent des droits nécessaires pour supprimer les données de production et leurs sauvegardes. L’audit vérifie si la stratégie de reprise reste viable lorsqu’un accès privilégié est compromis.
Audit Cloud ou audit global du système d’information ?
L’audit Cloud se concentre sur les environnements AWS et Azure : comptes, identités, réseau, ressources, données, workloads, secrets, journalisation, sauvegardes et déploiements. L’audit cybersécurité du SI est plus large et peut également couvrir postes, réseau interne, Active Directory, applications internes, prestataires et organisation technique.
Lorsque le Cloud constitue seulement une partie d’un SI hybride important, les deux périmètres peuvent être combinés. L’audit cybersécurité global du système d’information reste alors la porte d’entrée transverse.
Comment se déroule un audit sécurité Cloud ?
01 — Cadrage de l’environnement
Un échange de 45 à 60 minutes avec CTO, DSI, RSSI, responsable Cloud, DevOps et, si nécessaire, un prestataire identifie providers, comptes AWS, subscriptions Azure, environnements, applications critiques, données, équipes et contraintes de production.
02 — Inventaire et accès en lecture
Nous réunissons architecture, comptes, ressources, politiques IAM, réseau, configurations, logs, dépôts d’infrastructure, pipelines et sauvegardes. Les accès en lecture ou rôles dédiés à l’audit sont privilégiés.
03 — Analyse de la configuration réelle
Nous comparons l’architecture attendue avec la configuration réellement déployée et vérifions droits, exposition, segmentation, secrets, données, logs, workloads, sauvegardes et pipelines. Les conclusions ne reposent pas uniquement sur un scanner automatique.
04 — Analyse des chemins de compromission
Nous relions les constats : un compte prestataire ancien, un rôle permissif, un accès aux secrets et un déploiement de production peuvent former un scénario critique. Une configuration individuelle peu risquée peut devenir critique lorsqu’elle est combinée à d’autres permissions.
05 — Restitution et roadmap
Une réunion de 60 à 90 minutes présente les risques prioritaires, ressources concernées, scénarios, quick wins, chantiers structurants, dépendances et ordre de réalisation.
Combien de temps dure un audit AWS ou Azure ?
Un audit de sécurité Cloud sur un environnement de taille intermédiaire représente généralement environ 8 à 12 jours ouvrés d’intervention, répartis sur deux à trois semaines calendaires.
La charge dépend du nombre de comptes AWS, subscriptions Azure, environnements, workloads, régions, interconnexions, pipelines, clusters Kubernetes, prestataires et de la qualité de la documentation. Un périmètre très large peut être découpé par compte, domaine ou criticité.
Que recevez-vous après l’audit ?
Synthèse pour la direction
Les principales expositions, scénarios critiques, impacts potentiels, décisions nécessaires et priorités, sans réduire la synthèse à une liste de termes AWS ou Azure.
Cartographie des ressources critiques
Environnements, comptes ou subscriptions, données, workloads critiques, accès privilégiés et principales connexions, avec un niveau de détail utile à la décision.
Matrice des risques
Pour chaque constat : environnement, ressource, risque, scénario, exposition, impact, priorité et correction proposée.
Revue IAM et accès sensibles
Nous identifions les comptes privilégiés et rôles trop larges, les clés persistantes, les accès prestataires ou croisés et les permissions capables de modifier la production ou les données.
Roadmap de remédiation
Immédiat : fermer les expositions critiques, supprimer les accès obsolètes et protéger les comptes administrateurs. À 30 jours : traiter permissions, segmentation, stockage, pipelines et logs. À 60 jours : structurer IAM, séparation des environnements, Infrastructure as Code et journalisation centralisée. À 90 jours et plus : mettre en œuvre l’architecture cible et automatiser les contrôles structurants.
Backlog exploitable
Chaque action peut devenir une tâche avec priorité, responsable, effort indicatif, dépendances et validation attendue.
Sur quoi s’appuie l’analyse ?
L’analyse s’appuie notamment sur les bonnes pratiques AWS et Microsoft applicables à l’environnement audité. Pour AWS, nous pouvons utiliser les axes du Security Pillar du AWS Well-Architected Framework : gestion des identités, détection, protection de l’infrastructure, protection des données, réponse aux incidents et sécurité applicative.
Pour Azure, nous pouvons nous appuyer sur les recommandations Security du Azure Well-Architected Framework : segmentation, identité, contrôles réseau, protection des données, monitoring, détection et sécurité des workloads. CIS Benchmarks ou CIS Controls peuvent compléter l’analyse lorsque pertinent.
Il s’agit de références de travail, pas d’un audit certifié AWS, Microsoft, CIS ou ANSSI.
Ce que vous devez savoir après l’audit
Après l’audit, l’entreprise doit savoir quels comptes peuvent administrer le Cloud, quelles ressources sont accessibles depuis Internet et quels prestataires possèdent encore des accès. Elle doit également pouvoir vérifier si la production et le développement sont suffisamment séparés.
La restitution doit enfin répondre à trois questions : une compromission peut-elle atteindre les données sensibles, les sauvegardes survivraient-elles à une compromission administrative et le pipeline constitue-t-il lui-même un accès privilégié ? Les corrections immédiates sont alors clairement rattachées à ces risques.
Quand faire auditer AWS ou Azure ?
La mission s’adresse aux PME structurées, ETI, scale-ups B2B, groupes, SaaS critiques et plateformes métier qui disposent déjà de plusieurs comptes, subscriptions, équipes, prestataires ou environnements. Elle ne vise pas un site WordPress isolé sur une seule VM.
L’audit est particulièrement pertinent lorsque l’infrastructure a grandi rapidement ou par plusieurs prestataires, lorsque plusieurs comptes AWS, subscriptions Azure ou équipes Cloud coexistent, ou lorsqu’un nouveau CTO, DSI ou RSSI arrive.
Il est également utile avant une due diligence, une levée, l’arrivée d’un nouveau client ou l’ouverture d’un service critique, ainsi que lors d’une migration Cloud, d’une fusion d’environnements, d’une reprise d’infrastructure, de secrets mal attribués ou d’un mélange de changements automatisés et manuels.
Comment sécuriser l’environnement après l’audit ?
Koragence peut ensuite prendre en charge la remédiation sur un périmètre séparé : IAM, MFA, SSO, rôles, comptes de service, clés persistantes, séparation des environnements, réseau privé, Security Groups / NSG, secrets, stockage, chiffrement, pipelines, Terraform, sauvegardes, logs, alertes et durcissement des workloads.
La sécurisation des accès et de l’infrastructure Cloud correspond à la remédiation. L’exploitation et le maintien de l’infrastructure Cloud relèvent ensuite du périmètre DevOps et infrastructure.