L'audit de sécurité Microsoft pour la conformité SOC 2
SOC 2 est le rapport que vos clients grands comptes réclament avant de signer. L'essentiel de l'effort porte sur les politiques et les processus, mais ce qui bloque les équipes au moment de la preuve est technique : démontrer comment l'accès à vos systèmes est réellement contrôlé. Si votre entreprise tourne sous Microsoft, cette preuve vit sur deux périmètres à la fois.
Ce qu'est réellement SOC 2
SOC 2 n'est pas une certification. C'est un rapport d'attestation émis par un cabinet d'expertise comptable 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, les critères Disponibilité, Confidentialité, Intégrité de traitement et Vie privée sont optionnels.
Il en existe deux formes. Un rapport de type I décrit vos contrôles à un instant donné. Un rapport de type II teste si ces contrôles ont fonctionné efficacement sur une période, couramment de trois à douze mois. Le type II est celui que veulent réellement les acheteurs grands comptes, et c'est le plus exigeant, 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 preuve. Un audit qu'on peut rejouer selon un calendrier, avec des rapports datés qui montrent la constance, vaut infiniment plus qu'une revue manuelle ponctuelle.
Les critères où l'identité fait le gros du travail
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 traitez :
- La robustesse de l'authentification — la MFA est-elle réellement imposée, et pour qui ? Une politique qui annonce « MFA obligatoire » alors que l'accès conditionnel comporte des exclusions est un constat qui n'attend que d'être levé.
- L'attribution et l'autorisation — comment les utilisateurs obtiennent leurs accès, et sur quelle base.
- Le retrait des accès — le contrôle le plus souvent en échec. Comptes dormants, comptes désactivés mais jamais supprimés, principaux de service résiduels : c'est exactement ce qu'un échantillonnage de type II fait remonter.
- L'accès à privilèges — combien de personnes détiennent des rôles d'administration, si cet accès est permanent ou activable à la demande, et s'il est revu.
- La restriction des chemins d'accès — les protocoles d'authentification hérités qui contournent les contrôles modernes contredisent directement une politique d'accès affichée.
CC7 — exploitation des systèmes
Supervision et détection. Pour un environnement Microsoft, les questions concrètes sont de savoir si les journaux de connexion et d'audit sont conservés assez longtemps pour enquêter sur un incident, s'ils sont exportés vers un support durable, et si quelqu'un les regarde.
Là où les équipes perdent réellement 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 à faire des captures d'écran de portails d'administration. Chaque portail a son propre format d'export. Personne ne parvient à produire une vue cohérente de « qui était administrateur général en mars », et les exclusions enfouies dans une stratégie d'accès conditionnel ressortent trois semaines avant l'échéance.
Le problème de fond est que la configuration Microsoft vit sur une douzaine de plans séparés, chacun avec sa console — et deux d'entre eux sont des produits entièrement différents : le tenant et l'annuaire.
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, dans une forme qu'un auditeur peut lire :
| Ce que demande l'auditeur | Ce que fournit l'audit |
|---|---|
| La MFA est-elle imposée, et où sont les trous ? | Résultat contrôle par contrôle sur l'accès conditionnel et les politiques d'authentification |
| Qui détient des rôles à privilèges ? | Constats sur les attributions de rôles privilégiés, accès permanents compris |
| Les comptes dormants sont-ils supprimés ? | Constats sur les comptes inactifs et orphelins, dans le tenant et dans Active Directory |
| L'accès d'administration est-il restreint ? | Attributions Propriétaire et Domain Admin, privilèges permanents, ports d'administration exposés sur Internet |
| Les protocoles hérités sont-ils bloqués ? | Résultat de contrôle explicite avec sa 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 normative et une étape de remédiation, ce qui compte parce que la question suivante d'un auditeur est toujours « et qu'avez-vous fait ensuite ? ».
Deux périmètres, un seul corpus de preuves
Une organisation qui tourne sous Microsoft n'en exploite rarement qu'un seul des deux. Le tenant cloud et l'annuaire on-premises portent chacun leur part de l'exigence, et un évaluateur qui ne regarde que le premier passe à côté de l'endroit où se trouve l'essentiel du risque.
| Périmètre | Ce qu'il apporte à l'exigence |
|---|---|
| Entra ID & Microsoft 365 | Robustesse de l'authentification, accès conditionnel, rôles à privilèges, consentement applicatif, accès invité, politiques de messagerie et de partage, rétention des journaux d'audit. |
| Active Directory | Appartenance aux groupes privilégiés, comptes de service, délégations ACL, configuration Kerberos, modèles de certificat, approbations, couverture LAPS — et les chemins d'escalade qui les relient. |
La correspondance normative est la même dans les deux, et c'est ce qui fait que les preuves s'additionnent au lieu de rester dans deux piles séparées.
Une séquence concrète
- Lancez un audit de référence sur les deux périmètres avant d'ouvrir la fenêtre d'observation. Il vaut mieux trouver les écarts avant que l'auditeur ne les échantillonne.
- Corrigez d'abord les fondamentaux — couverture MFA, authentification héritée, nombre de rôles privilégiés, comptes dormants. Ils se rattachent directement à CC6 et ce sont eux qui échouent visiblement.
- Instaurez une cadence. Des audits mensuels ou trimestriels sur la période d'observation donnent une preuve datée et constante de l'efficacité opérationnelle — ce qui est tout l'objet du type II.
- Conservez les rapports. Un dossier de rapports 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, tôt, pour que tout le monde s'accorde sur ce que la preuve démontre.
Une remarque sur le périmètre
SOC 2 couvre quantité de choses qu'aucun audit technique ne touche : gestion des fournisseurs, gestion du changement, procédures d'intégration RH, réponse à incident, sécurité physique. Un audit de configuration adresse la preuve sur le contrôle d'accès et la supervision, ce qui est une part significative du critère Sécurité — pas la totalité du rapport.
Ceci n'est ni un avis juridique ni un avis d'audit. Le périmètre, le choix des critères et ce qui constitue une preuve acceptable relèvent de vous et de votre cabinet. Prenez ceci comme un guide du travail technique préparatoire, pas comme un substitut au jugement de votre auditeur.