Audit de sécurité Microsoft 365 pour la conformité SOC 2
SOC 2 est le rapport que vos clients grands comptes demandent avant de signer. L'essentiel de l'effort porte sur les politiques et les processus, mais la partie qui piège les équipes au moment des preuves est technique : prouver comment l'accès à vos systèmes est réellement contrôlé. Si votre entreprise tourne sur Microsoft 365, cette preuve vit dans Entra ID, Active Directory et Azure.
Ce qu'est réellement SOC 2
SOC 2 n'est pas une certification. C'est un rapport d'attestation émis par un cabinet de CPA agréé, fondé sur les Trust Services Criteria de l'AICPA. Vous choisissez les critères dans le périmètre ; le critère Sécurité — souvent appelé Common Criteria — est obligatoire, et Disponibilité, Confidentialité, Intégrité des traitements et Vie privée sont des ajouts optionnels.
Il en existe deux saveurs. Un rapport Type I décrit vos contrôles à un instant donné. Un rapport Type II teste si ces contrôles ont fonctionné efficacement sur une période, couramment de trois à douze mois. Le Type II est ce que la plupart des acheteurs entreprise veulent réellement, et c'est le plus difficile, parce qu'il faut montrer que le contrôle a tenu dans la durée — pas seulement le jour de la capture d'écran.
Pourquoi cela compte pour l'outillage. Le Type II est un problème de preuves. Un audit que vous pouvez relancer à intervalle régulier, avec des rapports datés qui montrent la constance, vaut bien plus qu'une revue manuelle ponctuelle.
Les critères où l'identité porte l'essentiel
CC6 — Contrôles d'accès logiques et physiques
C'est la famille où une organisation très Microsoft dépense l'essentiel de son effort de preuve. En pratique, les auditeurs veulent voir comment vous gérez :
- La force de l'authentification — le MFA est-il réellement imposé, et pour qui ? Une politique qui dit « MFA obligatoire » alors que l'accès conditionnel comporte des exclusions est un constat en puissance.
- Le provisionnement et l'autorisation — comment les utilisateurs obtiennent l'accès, et sur quelle base.
- Le déprovisionnement — le contrôle le plus souvent en échec. Comptes dormants, désactivés mais non supprimés, et principaux de service qui traînent : c'est exactement ce qu'un échantillon Type II fera remonter.
- L'accès privilégié — combien de personnes détiennent des rôles d'administration, si cet accès est permanent ou just-in-time, et s'il est revu.
- La restriction des chemins d'accès — des protocoles d'authentification hérités qui contournent les contrôles modernes contredisent directement une politique d'accès déclarée.
CC7 — Exploitation des systèmes
Surveillance et détection. Pour un environnement Microsoft, les questions pratiques sont de savoir si les journaux de connexion et d'audit sont conservés assez longtemps pour investiguer un incident, s'ils sont exportés vers un stockage durable, et si quelque chose les surveille.
Là où les équipes perdent vraiment du temps
Le schéma d'échec est constant : les politiques existent, les intentions sont bonnes, puis l'auditeur demande des preuves couvrant une fenêtre de neuf mois. Quelqu'un se met à capturer des écrans des portails d'administration. Chaque portail a un format d'export différent. Personne ne peut produire une vue cohérente de « qui avait Global Administrator en mars », et les exclusions enfouies dans une stratégie d'accès conditionnel ressortent trois semaines avant l'échéance du rapport.
Le problème de fond est que la configuration Microsoft vit dans une douzaine de plans séparés, chacun avec sa console. La collecte de preuves devient un chantier d'archéologie manuelle plutôt qu'une mesure.
Ce qu'apporte un audit automatisé
Un outil d'audit ne vous rend pas conforme SOC 2 — aucun outil ne le fait. Ce qu'il produit, c'est la preuve technique derrière un sous-ensemble précis de critères, sous une forme qu'un auditeur peut lire :
| Ce que l'auditeur demande | Ce que l'audit fournit |
|---|---|
| Le MFA est-il imposé, et où sont les trous ? | Résultat par contrôle sur l'accès conditionnel et les stratégies d'authentification |
| Qui détient des rôles privilégiés ? | Constats d'affectation de rôles privilégiés, accès permanent compris |
| Les comptes dormants sont-ils supprimés ? | Constats de comptes inactifs et orphelins, dans Entra ID et l'AD on-premises |
| Les protocoles hérités sont-ils bloqués ? | Résultat de contrôle explicite avec remédiation |
| Les journaux sont-ils conservés ? | Résultat du contrôle de rétention des journaux d'audit |
Chaque constat porte sa référence de référentiel et une étape de remédiation, ce qui compte parce que la question suivante de l'auditeur est toujours « et qu'en avez-vous fait ? »
N'oubliez pas Active Directory on-premises
Si vos systèmes de production s'authentifient contre un domaine on-premises, ou si des comptes privilégiés sont synchronisés de l'AD vers le cloud, alors l'AD est dans le périmètre de vos contrôles d'accès, que votre tableau de bord cloud le mentionne ou non. C'est une vraie lacune de la plupart des outils : les évaluations cloud-only dressent un tableau confortable pendant que le domaine qui détient réellement les clés reste inexaminé.
Auditer les deux ensemble referme aussi la couture où les environnements hybrides échouent le plus — comptes admin synchronisés qui héritent des privilèges des deux côtés, ou MFA imposé dans le cloud mais pas sur le chemin hérité.
Une séquence pratique
- Lancez un audit de référence sur Entra ID, Active Directory et Azure avant le début de la fenêtre d'observation. Il faut trouver les trous avant que l'auditeur les échantillonne.
- Remédiez d'abord aux fondamentaux — couverture MFA, authentification héritée, nombre de rôles privilégiés, comptes dormants. Ils correspondent directement à CC6 et ce sont ceux qui échouent visiblement.
- Fixez une cadence. Des audits mensuels ou trimestriels sur la période d'observation vous donnent des preuves datées et cohérentes d'efficacité opérationnelle — tout l'enjeu du Type II.
- Gardez les rapports. Un dossier de rapports de conformité datés montrant un score qui monte est un bien meilleur artefact qu'une pile de captures d'écran.
- Rattachez les constats aux critères avec votre auditeur dès le début, pour que tout le monde s'accorde sur ce que la preuve démontre.
Une note sur le périmètre
SOC 2 couvre beaucoup de choses qu'aucun audit technique ne touche : gestion des fournisseurs, gestion des changements, onboarding RH, procédures de réponse à incident, sécurité physique. Un audit de configuration traite les preuves de contrôle d'accès et de surveillance, une tranche significative du critère Sécurité — pas le rapport entier.
Ni avis juridique ni avis d'audit. Le périmètre, le choix des critères et ce qui constitue une preuve acceptable sont des décisions qui vous appartiennent, à vous et à votre cabinet de CPA. Utilisez ceci comme guide du travail technique préparatoire, pas comme substitut au jugement de votre auditeur.