Comment réussir un audit SOC 2 CC6 — mécanismes de contrôle des accès à privilèges. Guide pratique
La préparation à SOC 2 Type II est un marathon. La plupart des organisations traversent la documentation des politiques, les questionnaires de risque fournisseur et les diagrammes de segmentation réseau sans trop de difficultés. Puis elles arrivent à CC6 — Contrôles d'accès logiques et physiques — et l'audit devient difficile.
CC6 est l'endroit où les auditeurs passent le plus de temps et où les entreprises reçoivent le plus souvent des exceptions. Il couvre qui a accès à vos systèmes, comment cet accès est contrôlé, comment il est surveillé et comment il est révisé. Si votre réponse en matière de gestion des accès à privilèges est « nous utilisons un VPN plus RDP avec des identifiants administrateur partagés », vous ne passerez pas l'audit.
Voici exactement ce que CC6 exige, ce que les auditeurs demandent et comment fournir les preuves.
CC6.1, CC6.2, CC6.3, CC6.6 — ce que chaque point exige en langage simple
CC6.1 — Sécurité des accès logiques
Exigence : l'accès logique à vos systèmes, infrastructures et données est limité aux utilisateurs autorisés.
En pratique, cela signifie :
- Chaque utilisateur ayant accès à un système de production dispose d'une raison documentée pour cet accès
- L'accès est attribué par un processus défini (pas ad hoc)
- L'accès est supprimé rapidement lorsqu'un utilisateur part ou change de rôle
- L'accès à privilèges (admin, root, DBA) est suivi séparément et soumis à des standards plus élevés
Preuves souhaitées par les auditeurs : inventaire complet de qui a accès à privilèges à quoi, comment il a été attribué et quand il a été révisé pour la dernière fois.
CC6.2 — Identification et authentification
Exigence : les utilisateurs sont authentifiés avant d'accéder aux systèmes, et l'authentification est suffisamment robuste pour la sensibilité de la ressource.
En pratique, cela signifie :
- Le MFA est requis sur tous les comptes à accès à privilèges
- Les mots de passe respectent les exigences de complexité et de rotation
- Les comptes partagés (administrateur partagé, root partagé) sont éliminés ou strictement contrôlés
- Les comptes de service sont inventoriés et l'accès est révisé
Preuves souhaitées par les auditeurs : captures d'écran de l'inscription MFA, exports de l'inventaire des comptes, preuves de l'élimination des comptes administrateur partagés ou de l'existence de mécanismes de contrôle compensatoires.
CC6.3 — Suppression des accès
Exigence : l'accès est supprimé lorsqu'il n'est plus nécessaire (fin de contrat, changement de rôle, fin de projet).
En pratique, cela signifie :
- Vous disposez d'un processus d'offboarding documenté incluant la révocation des accès à privilèges
- La révocation des accès intervient dans des délais définis (24 à 48 heures pour l'accès en production)
- Vous pouvez démontrer que les utilisateurs dont le contrat est terminé n'ont plus de sessions actives ni d'identifiants
Preuves souhaitées par les auditeurs : tickets d'offboarding montrant les étapes de révocation des accès, captures d'écran des droits d'accès avant et après.
CC6.6 — Restrictions des accès logiques
Exigence : la transmission des données est chiffrée, et des restrictions d'accès logiques sont implémentées pour empêcher les accès non autorisés.
En pratique, cela signifie :
- Toutes les connexions administratives sont chiffrées en transit
- L'accès aux systèmes sensibles est limité aux points d'accès ou réseaux autorisés
- L'activité de session est surveillée et journalisée
Preuves souhaitées par les auditeurs : diagrammes réseau montrant les canaux chiffrés, journaux de session montrant l'activité administrative.
Ce que les auditeurs demandent réellement
Lorsqu'un auditeur SOC 2 examine CC6, il demande généralement les preuves suivantes :
Pour CC6.1 (inventaire des accès) :
- Tableur ou export système montrant tous les utilisateurs avec accès à privilèges, les systèmes auxquels ils ont accès et la justification métier
- Preuve de l'approbation de l'accès (e-mail, ticket, capture d'écran du workflow d'approbation)
- Dossiers de révision des accès montrant la recertification trimestrielle ou annuelle
Pour CC6.2 (authentification) :
- Capture d'écran de l'inscription MFA pour les comptes administrateur
- Documentation de la politique de mots de passe et preuve de son application
- Liste des comptes de service et preuve d'inventarisation
Pour CC6.3 (suppression des accès) :
- Tickets d'offboarding exemples (généralement 3 à 5 exemples sur la période d'audit)
- Preuve de révocation des accès à privilèges dans les délais SLA
- Intégration au système RH ou dossiers de vérification manuelle
Pour CC6.6 (surveillance des sessions) :
- Journaux de session montrant l'activité administrative (qui s'est connecté, quand, sur quel système, ce qui a été fait)
- Preuve de l'enregistrement des sessions
- Diagramme réseau montrant le chiffrement en transit
Les preuves doivent couvrir l'intégralité de la période d'audit (généralement 12 mois pour un audit Type II). Les auditeurs effectueront des sondages sur des événements de toute cette période — vous ne pouvez pas vous appuyer sur des preuves des deux dernières semaines avant les travaux de terrain de l'audit.
Échecs CC6 courants et comment les éviter
Identifiants administrateur partagés
Découverte CC6 la plus courante. « Nous utilisons un compte Administrator partagé car certains systèmes ne supportent pas les comptes individuels » n'est pas un mécanisme de contrôle acceptable. VaultPAM résout ce problème : les utilisateurs se connectent via des sessions proxy sans recevoir l'identifiant. Le coffre-fort stocke le mot de passe ; les journaux d'audit montrent exactement quel utilisateur a initié chaque session.
MFA non appliqué sur tous les comptes à privilèges Les organisations ont souvent le MFA sur la messagerie d'entreprise mais pas sur l'accès direct aux serveurs (RDP, SSH). Les auditeurs vérifient cela spécifiquement. Chaque session à privilèges doit exiger le MFA.
Absence de preuves de révision des accès Beaucoup d'organisations effectuent des révisions des accès de manière informelle. Les auditeurs veulent des preuves documentées : qui a révisé, ce qui a été révisé, quand et quelles actions ont été entreprises. « Nous avons effectué une révision au T3 » sans ticket, tableur ou rapport n'est pas une preuve.
Accès non révoqué rapidement Le délai entre le départ d'un employé et la révocation de son accès est une découverte récurrente. Si votre processus d'offboarding prend une semaine et que l'accès à privilèges est traité dans la même file d'attente, vous avez un problème CC6.3.
Journaux de session incomplets ou non disponibles La conservation des journaux de session n'est que la moitié de la réponse. Les auditeurs veulent voir que vous pouvez récupérer des événements spécifiques et que les journaux sont complets et inviolables. Les journaux dans des silos dispersés (Journal des événements Windows sur chaque serveur, journaux auth SSH sur chaque machine Linux) sans agrégation centrale sont difficiles à présenter comme preuves.
Comment VaultPAM produit automatiquement des preuves CC6 prêtes pour l'audit
VaultPAM est conçu en partant du principe que votre auditeur regarde par-dessus votre épaule. Les preuves qu'il produit s'appliquent directement à ce que CC6 exige :
| Mécanisme de contrôle CC6 | Ce que VaultPAM produit |
|---|---|
| CC6.1 — inventaire des accès | Rapport complet de tous les utilisateurs, systèmes cibles, politiques d'accès et approbations — exportable en CSV ou accessible via API |
| CC6.2 — application du MFA | TOTP et WebAuthn appliqués au niveau de la session — chaque session à privilèges nécessite une authentification ; statut d'inscription MFA visible dans le tableau de bord administrateur |
| CC6.2 — sans identifiants partagés | Proxying de session — les utilisateurs accèdent aux cibles sans recevoir les mots de passe ; le coffre-fort stocke l'identifiant, pas l'utilisateur |
| CC6.3 — suppression des accès | La révocation d'un utilisateur dans VaultPAM met immédiatement fin à sa capacité à initier de nouvelles sessions ; les sessions actives peuvent être forcément terminées |
| CC6.6 — surveillance des sessions | Enregistrement complet des sessions (vidéo + journal d'activité) pour chaque session RDP, SSH, VNC et HTTP ; inviolable grâce à la chaîne de hachage BLAKE3 ; consultable par utilisateur, cible et plage de temps |
| CC6.6 — chiffrement en transit | Toutes les sessions proxifiées via mTLS ; aucun port entrant direct sur les systèmes cibles |
Le processus de révision des accès est soutenu par les exports du journal d'audit de VaultPAM : vous pouvez générer un rapport complet de chaque session à privilèges du dernier trimestre, triées par utilisateur et cible, en quelques minutes. Présentez cela à l'auditeur avec la configuration de la politique d'accès et la capture d'écran de l'inscription MFA — c'est votre pack de preuves CC6.
En route vers la préparation SOC 2 Type II ? VaultPAM produit automatiquement des preuves prêtes pour l'audit pour les mécanismes de contrôle CC6 — enregistrements de session, journaux d'accès, application du MFA et configuration des politiques sont reportables depuis un seul tableau de bord.
Téléchargez notre résumé de conformité SOC 2 pour le mapping complet des mécanismes de contrôle VaultPAM aux critères de confiance SOC 2.