Pourquoi avons-nous encore besoin du CIS Benchmark dans le cloud ?

8 juillet 2026 | 8 min de lecture

1. Le paradoxe du cloud : sécurisé par conception, mais pas sécurisé par défaut

Au cours d’un travail d’automatisation des contrôles du CIS Microsoft Azure Foundations Benchmark v3.0, nous avons développé un script PowerShell dont l’objectif était de vérifier, point par point, la conformité d’un tenant Azure.

L’exercice consistait à traduire chaque contrôle du référentiel en une fonction capable de décrire l’état réel de la plateforme : configuration des comptes administrateurs, activation des journaux, restrictions réseau, gestion des identités, protection des données, etc.

Pour représenter le projet, voici un schéma simple montrant le fonctionnement et le but de la démarche :

Représentation du passage du CIS Benchmark vers un rapport de conformité

À mesure que le projet avançait, une question s’est naturellement imposée : pourquoi avons-nous encore besoin d’un benchmark comme le CIS alors que Microsoft investit massivement dans la sécurité d’Azure ?

Après tout, les services cloud modernes sont conçus selon des standards de sécurité élevés. Ils bénéficient de mécanismes avancés de protection, d’une supervision continue et d’une expertise difficilement atteignable pour la plupart des organisations.

Pourtant, lors des audits, il est fréquent de constater qu’un tenant Azure parfaitement fonctionnel présente de nombreux écarts vis-à-vis des recommandations du CIS.

D’où vient ce décalage ? C’est la question à laquelle nous avons tenté de répondre au fil de cette réflexion.

Une première réponse réside dans la distinction entre la sécurité de la plateforme et la sécurité de sa configuration.

Le Cloud Service Provider met à disposition des services sécurisés, mais il laisse volontairement une grande liberté de configuration à ses clients.

Par exemple :

Azure permet la mise en place de comptes administrateurs hautement protégés.
Azure permet également, pour des raisons de flexibilité, de conserver des privilèges permanents sur certains comptes.
Azure permet de conserver des journaux d’activité pendant plusieurs années, mais également de les désactiver ou de réduire leur durée de conservation selon les besoins.

Dans chacun de ces cas, le service fonctionne correctement. La différence réside dans le niveau de risque que l’organisation choisit d’accepter, indépendamment de la qualité du service fourni.

2. Ce que garantit réellement un Cloud Service Provider

Pour comprendre l’intérêt d’un benchmark de sécurité, il est nécessaire de revenir au principe fondamental du cloud : le modèle de responsabilité partagée.

Lorsqu’une organisation migre vers Azure, AWS ou Google Cloud, elle transfère une partie de la responsabilité de la sécurité au fournisseur.

Exemple des responsabilités respectives d’un Cloud Service Provider et de l’entreprise vis à vis du service fourni/utilisé

En d’autres termes, le fournisseur cloud garantit que les outils fonctionnent conformément à leur conception. En revanche, il ne peut pas déterminer comment chaque organisation doit les utiliser.

Deux entreprises utilisant exactement les mêmes services Azure peuvent ainsi présenter des niveaux de sécurité très différents uniquement en raison de leurs choix de configuration.

Un autre aspect important est que de nombreux services cloud sont délibérément conçus pour être permissifs par défaut plutôt que restrictifs.

Cette philosophie de conception permet aux organisations de déployer et d’utiliser rapidement des services, sans être freinées par des paramètres de sécurité trop contraignants. Si cela améliore considérablement la facilité d’utilisation et accélère l’adoption, cela implique également que de nombreuses fonctionnalités de sécurité sont facultatives et doivent être configurées explicitement par le client.

En pratique, un service peut être déployé dans un état parfaitement fonctionnel tout en présentant une surface d’attaque plus étendue que nécessaire. Les configurations par défaut ne sont donc pas nécessairement non sécurisées, mais elles sont rarement optimisées pour répondre aux exigences de sécurité propres à une organisation donnée.

3. L’importance du CIS Benchmark

C’est précisément là que les référentiels de sécurité, tels que le CIS Benchmark, s’avèrent précieux : ils fournissent des orientations pour transformer un déploiement cloud fonctionnel en une solution conforme aux meilleures pratiques de sécurité reconnues.

Sa principale force réside dans son indépendance. Contrairement aux recommandations publiées par les fournisseurs cloud, le benchmark est élaboré par une communauté d’experts composée d’architectes, d’auditeurs, de consultants et de spécialistes de la sécurité.

Cette approche permet de définir un socle de sécurité commun, reconnu par l’ensemble de l’écosystème cyber, sans être lié à la stratégie commerciale d’un fournisseur particulier.

Le CIS constitue ainsi un langage commun entre les équipes techniques, les auditeurs et les responsables de la sécurité. Lorsqu’un contrôle est déclaré conforme ou non conforme, chacun comprend précisément ce que cela signifie.

Mais son intérêt ne s’arrête pas là.

Ses recommandations sont suffisamment précises pour être traduites en contrôles techniques automatisables.

C’est précisément ce que nous avons cherché à réaliser avec notre script PowerShell.

Chaque recommandation devient alors un contrôle objectif : vérifier que l’authentification multi-facteurs est activée, que les comptes propriétaires sont limités, que les journaux sont correctement collectés ou encore que les clés de chiffrement sont protégées.

Le benchmark cesse alors d’être un simple document de recommandations pour devenir un véritable référentiel technique, mesurable et reproductible.

Plus qu’une liste de bonnes pratiques, il fournit un cadre cohérent permettant d’évaluer la posture de sécurité d’un environnement cloud.

4. Une réflexion issue de l’automatisation des contrôles

Le développement de cet outil d’audit nous a progressivement amenés à modifier notre perception de ce type de référentiel.

Au départ, le CIS Benchmark pouvait être perçu comme une simple checklist de conformité destinée à produire un score.

Pourtant, à mesure que les contrôles étaient traduits en fonctions PowerShell renvoyant un résultat booléen (True/False), nous nous sommes aperçus que la véritable valeur du benchmark réside dans sa capacité à mettre en évidence les écarts de sécurité.

Nous avons également constaté que certains contrôles, bien que pertinents d’un point de vue sécurité, pouvaient être difficilement applicables dans certains contextes opérationnels. Une organisation exploitant des applications historiques n’aura pas toujours la possibilité d’appliquer immédiatement l’ensemble des recommandations sans impacter son fonctionnement.

Chaque contrôle non conforme devient alors une question à laquelle l’organisation doit répondre.

S’agit-il d’un oubli ? D’une dette technique ? D’une contrainte métier ? Ou alors est-ce un choix assumé après une analyse de risque ?

Le benchmark ne remplace donc pas l’analyse de risque. Il l’alimente.

Dans cette perspective, le CIS Benchmark apparaît moins comme un objectif à atteindre que comme un outil d’aide à la décision. Il évolue continuellement afin d’accompagner les organisations dans la réduction de leur surface d’exposition, tandis que le Cloud Service Provider poursuit l’amélioration de la sécurité des services qu’il fournit.

En définitive, nous avons compris que la question n’était pas de savoir si Azure est suffisamment sécurisé. La véritable question est de disposer d’un référentiel indépendant permettant d’évaluer objectivement les choix de configuration réalisés par une organisation.

C’est précisément ce rôle que continue de jouer le CIS Benchmark aujourd’hui.

En somme, ce qu’il faut retenir tient en une image :