Les gardiens de la conformité : analyser l'authentification de l'identité selon SOC 2 et RGPD
Découvrez comment SOC 2 et le RGPD imposent légalement la vérification d'identité, l'AMF, les contrôles d'accès et les journaux d'audit, avec des références directes aux normes officielles.
Product & Design
Dans le paysage réglementaire moderne, la gestion des identités et des accès (IAM) n'est plus seulement une tâche opérationnelle informatique ; c'est une exigence légale et de conformité. Deux des cadres les plus importants régissant ce domaine sont SOC 2 (System and Organization Controls 2) et le RGPD (Règlement général sur la protection des données).
Alors que SOC 2 se concentre sur la confiance dans la prestation de services, et que le RGPD met l'accent sur les droits à la vie privée des individus, les deux convergent vers une seule vérité : Tu ne peux pas sécuriser les données si tu ne peux pas vérifier l'identité de la personne qui y accède.
Vous trouverez ci-dessous une analyse stricte des clauses et critères spécifiques dans les deux cadres qui imposent une authentification forte de l'identité, y compris des liens directs vers les normes officielles.
Partie 1 : Exigences SOC 2 (Les critères des services de confiance)
Les audits SOC 2 reposent sur les critères des services de confiance (TSC) 2017 de l'AICPA. Pour l'authentification de l'identité, la série des critères communs (CC) 6.0 (contrôles d'accès logiques et physiques) fait autorité.
- Source officielle : AICPA 2017 Trust Services Criteria (PDF)
1. La base de l'accès logique (CC6.1)
Le critère :
"L'entité met en place des logiciels, une infrastructure et des architectures de sécurité d'accès logique sur les actifs d'information protégés afin de les protéger contre les événements de sécurité pour atteindre les objectifs de l'entité."
L'analyse :
C'est le mandat général pour un système IAM. Pour satisfaire le CC6.1, une organisation doit prouver qu'elle dispose d'un mécanisme centralisé (comme un fournisseur d'identité - IdP) pour gérer les identités. Les comptes partagés ou ad hoc entraînent généralement un échec ici car ils rendent impossible l'audit de la "sécurité de l'accès logique".
2. Vérification de l'identité et cycle de vie (CC6.2)
Le critère :
"Avant d'attribuer des identifiants système et d'accorder l'accès au système, l'entité enregistre et autorise les nouveaux utilisateurs internes et externes dont l'accès est géré par l'entité."
L'analyse :
Cela exige un processus strict d'intégration/mobilité/départ (JML).
- Exigence d'authentification : Tu dois vérifier l'identité de l'utilisateur avant de lui donner un nom d'utilisateur/mot de passe.
- Révocation : Lorsqu'un employé quitte l'entreprise, l'accès doit être immédiatement révoqué (généralement sous 24 heures).
- Preuve requise : Les auditeurs demanderont une "liste de population" des employés licenciés et la croiseront avec les journaux systèmes pour vérifier que les jetons d'authentification ont bien été désactivés à temps.
3. L'obligation d'AMF (CC6.3)
Le critère :
"L'entité autorise, modifie ou supprime l'accès aux données, logiciels, fonctions et autres actifs d'information protégés en fonction des rôles, des responsabilités ou de la conception du système ..."
L'analyse :
Alors que le texte mentionne explicitement les "rôles" (RBAC), les "points d'attention" de l'AICPA pour CC6.3 insistent tout particulièrement sur la nécessité de l'authentification multifacteur (AMF).
- Interprétation stricte : Pour les rapports SOC 2 Type II modernes, se reposer uniquement sur l’authentification à facteur unique (mots de passe) pour l'accès administrateur, les dépôts de code source ou les données de production est presque universellement considéré comme une "déficience majeure" ou une exception.
- Exigence : L'accès à l'environnement de production ou aux données clients doit être protégé par l'AMF.
4. Revalidation (CC6.4)
Le critère :
"L'entité limite l’accès physique aux installations et aux actifs d'information protégés au personnel autorisé pour atteindre les objectifs de l'entité."
L'analyse :
Appliqué dans le contexte de l'accès logique, ceci impose la revue périodique des accès utilisateurs (UAR). Tu ne peux pas simplement authentifier un utilisateur une fois ; il faut, de façon périodique (généralement chaque trimestre), revérifier que l'identité est toujours valide et possède les privilèges appropriés.
Partie 2 : Exigences du RGPD (L'approche basée sur le risque)
Contrairement à SOC 2, le RGPD est une loi de l'UE. Il ne liste pas de technologies spécifiques (type "utilisez les applications OTP"), mais impose des résultats qui rendent une authentification forte légalement nécessaire.
1. Intégrité et confidentialité (Article 5)
La clause : Article 5(1)(f)
"Les données à caractère personnel doivent être traitées d'une manière garantissant une sécurité appropriée des données, notamment une protection contre le traitement non autorisé ou illicite..."
L'analyse :
"Traitement non autorisé" est le terme clé. Si un attaquant devine un mot de passe faible et accède à des données personnelles, l'organisation a échoué à l'article 5.
- Exigence d’authentification : La méthode d’authentification doit être suffisamment forte pour empêcher les attaques courantes (comme la force brute ou l’attaque par bourrage d’identifiants). Cela implique une politique de complexité de mot de passe rigoureuse et des mesures de limitation de débit.
2. Sécurité du traitement (Article 32)
- Lien officiel : RGPD Article 32 (Sécurité du traitement)
La clause : Article 32(1)
"Compte tenu de l’état des connaissances, des coûts de mise en œuvre et de la nature, de la portée, du contexte et des finalités du traitement... le responsable du traitement et le sous-traitant mettent en œuvre des mesures techniques et organisationnelles appropriées..."
L'analyse :
C'est la clause "état de l'art".
- Interprétation stricte : En 2024/2025, l’AMF est considérée comme "l’état de l’art" pour l’accès aux données sensibles. Si une violation survient et qu’on découvre que l’organisation n’utilisait que des mots de passe (une posture obsolète pour les données à haut risque), les régulateurs (comme l’ICO ou la CNIL) jugeront probablement les mesures "inappropriées" selon l’article 32.1
- Chiffrement : L’Article 32 mentionne aussi explicitement le chiffrement. Les systèmes d’identité doivent chiffrer les identifiants en transit et au repos (hachage/salage).
3. Protection des données dès la conception (Article 25)
La clause : Article 25(2)
"Le responsable du traitement met en œuvre des mesures techniques et organisationnelles appropriées pour faire en sorte que, par défaut, seuls les données à caractère personnel nécessaires à chaque finalité spécifique du traitement soient traitées."
L'analyse :
Ceci impose le principe du moindre privilège.
- Exigence d'authentification : Il ne suffit pas d’authentifier que « l’Utilisateur A est l’Utilisateur A ». Le système doit garantir que l’Utilisateur A ne voit que ce qui est nécessaire.
- Implication sur l'identité : Cela impose un contrôle d’accès basé sur les rôles (RBAC) finement paramétré et lié directement à l’identité vérifiée.
Partie 3 : Analyse comparative et résumé
Le tableau suivant résume comment satisfaire simultanément les deux normes :
| Fonctionnalité | Exigence SOC 2 (Critère) | Exigence RGPD (Article) | Norme de mise en œuvre stricte |
|---|---|---|---|
| Sécurité de connexion | CC6.3 (Contrôle d'accès) | Art. 32 (Sécurité du traitement) | AMF obligatoire pour tout le personnel ayant accès aux données clients ou aux environnements de production. |
| Périmètre d'accès | CC6.2 (Autorisation) | Art. 25 (Privacy by Design) | RBAC (Contrôle d'accès basé sur les rôles). Refus par défaut ; autorisation explicite selon les fonctions de poste. |
| Départ / Offboarding | CC6.2 (Suppression) | Art. 5 (Intégrité) | Déprovisionnement automatique. L'accès doit être révoqué immédiatement à la résiliation du contrat. |
| Audit | CC6.1 (Architecture de sécurité) | Art. 30 (Journal du traitement) | Journalisation centralisée. Qui s'est connecté, quand et d'où (adresse IP) ? |
Le verdict
Pour satisfaire à une analyse stricte des deux normes :
- SOC 2 considère l'identité comme un processus documenté. Tu dois prouver que tu as un processus pour créer, vérifier, et supprimer les identités.
- Le RGPD considère l'identité comme un bouclier protecteur. Tu dois prouver que tes mesures d'identité sont suffisamment solides pour prévenir une violation selon les normes technologiques actuelles.
La conformité SOC 2 et RGPD exige d’aller au-delà d’une simple gestion des mots de passe. Les organisations doivent mettre en place un fournisseur d'identité (IdP) centralisé imposant l’AMF, un RBAC strict et une journalisation automatisée des accès. Ne pas le faire aboutit à l’échec d’un audit SOC 2 (exception sur CC6.x) et à des sanctions RGPD potentielles pour manquement à la mise en place des "mesures techniques appropriées" selon l’article 32.