Réaliser un audit Microsoft 365 sans PowerShell paraît impossible quand on ouvre le référentiel. Le CIS Microsoft 365 Foundations Benchmark v7.0.0 compte en effet 160 recommandations, et pour à peu près toutes celles qui portent une procédure automatisée, le Center for Internet Security propose la même chose : un extrait PowerShell, à exécuter avec un compte disposant de droits d’administration sur le tenant.
C’est ce qui circule partout, et c’est ce que reprennent les dépôts publics. Cela pose pourtant un problème dès qu’on sort de son propre tenant.
Le vrai coût du script
Faire tourner un script d’audit chez un client suppose trois choses qu’aucun responsable sérieux n’accorde de bon cœur.
Un accès privilégié confié à un tiers. Les modules d’administration Microsoft 365 se connectent en effet avec des comptes qui peuvent lire, mais aussi écrire. Le client doit donc faire confiance au fait que le script ne fait que lire. Or il ne peut le vérifier autrement qu’en le relisant ligne à ligne, ce qu’il ne fera pas.
Un poste de travail dans la boucle. Le résultat dépend ensuite de la version des modules installés, du système et de la politique d’exécution locale. Ainsi, deux consultants obtiennent deux sorties légèrement différentes sur le même tenant, et personne ne sait laquelle fait foi.
Aucune garantie de rejouabilité. Six mois plus tard, les modules ont changé de version et certaines commandes ont disparu. Par conséquent, la comparaison avant-après devient un exercice d’interprétation plutôt qu’une mesure.
Sur un audit interne, on vit avec. En revanche, sur une prestation vendue, sur une exigence NIS2 de sécurité de la chaîne d’approvisionnement, ou sur une preuve à produire devant un auditeur ISO 27001, ces trois points deviennent des objections que la bonne volonté ne lève pas.
Comment mener un audit Microsoft 365 sans PowerShell
Ce que ces scripts lisent, Microsoft l’expose également par interfaces applicatives, en lecture seule. L’identité, la messagerie, la protection contre les menaces, la conformité, la collaboration et le partage documentaire sont ainsi tous adressables de cette manière.
Le travail ne consiste pas à trouver ces interfaces. Il consiste à établir, recommandation par recommandation, laquelle rend le réglage exact que le benchmark demande de constater, et sous quelle forme. Ce travail de rattachement est long, et c’est lui qui sépare un outil qui coche quarante contrôles d’un outil qui en couvre 160.
Sur les 160 recommandations de la v7.0.0, 140 deviennent donc des contrôles automatiques. Les 20 restantes passent en vérification guidée, saisies avec la réponse motivée de l’exploitant, puisqu’elles portent sur des décisions d’organisation et non sur un réglage lisible dans une console.
Ce que la lecture seule change concrètement
Le client n’exécute rien. Il accorde un consentement applicatif, nominatif, en lecture, sur une application identifiée. De plus, il le retire quand il veut, en une action. Aucun installateur, aucun agent, aucun connecteur résident.
Le périmètre reste visible et vérifiable. Les autorisations accordées apparaissent en effet dans son propre portail d’administration. Il sait donc exactement ce que l’auditeur peut lire, et chaque accès laisse une trace dans son journal d’audit à lui, pas dans celui du prestataire.
Aucun compte administrateur global ne change de mains. C’est ainsi la différence de nature entre un audit qui repose sur la confiance accordée à un consultant, et un audit qui repose sur une frontière technique que le client contrôle et peut fermer à tout moment.
Le constat est daté et rejouable. Deux collectes séparées de trois mois se comparent mécaniquement. Ainsi, la question de savoir si la mesure corrective a tenu reçoit une réponse factuelle, avec un horodatage, et non une impression.
Pour une entité soumise à NIS2 ou à DORA, ces propriétés séparent précisément une déclaration de conformité d’une preuve de conformité.
La v7.0.0 arrive dans un web qui parle encore des versions précédentes
Le benchmark v7.0.0 est récent. La plupart des ressources publiques, dépôts de scripts compris, portent encore sur les versions antérieures. On y trouve donc des numéros de recommandation qui ne correspondent plus, des sections déplacées et des procédures d’audit modifiées.
Auditer contre une version périmée produit alors un rapport qui a l’air complet et qui ne l’est pas. C’est le genre d’écart qui ne se voit qu’au moment où un auditeur externe ouvre le document, c’est-à-dire au pire moment.
Enfin, la première question à poser à un prestataire ne porte pas sur le nombre de contrôles qu’il exécute. Elle porte sur la version du benchmark, et sur ce qu’il exige comme accès pour le faire.
Tenovia couvre les 160 recommandations du CIS Microsoft 365 v7.0.0, en lecture seule, sans aucun script exécuté sur le tenant audité. Le détail domaine par domaine figure sur la page couverture CIS Microsoft 365.