La faille ClarityCheck : 9 millions de visages exposés et la leçon sur la sécurité des bases de données non structurées
L’outil de vérification d’identité ClarityCheck a laissé à découvert une base de données S3 contenant plus de 9 millions de fichiers d’images de visages, soulignant une faille critique dans la gestion des identités numériques et la configuration des services cloud. Cet incident n’est pas seulement une violation de données personnelles, c’est un rappel brutal des risques liés aux objets non structurés hébergés dans des buckets publics.
En bref
- Exposition massive : Plus de 9 millions de photos de visages étaient accessibles sans authentification via un bucket S3 mal configuré.
- Cible spécifique : Les données concernaient des utilisateurs d’une plateforme de vérification d’identité (KYC), rendant le risque de vol d’identité particulièrement élevé.
- Cause racine probable : Une configuration d’ACL (Access Control List) incorrecte ou un bucket public sur AWS S3, une erreur récurrente dans le secteur du cloud.
- Vulnérabilité des biometries : Contrairement aux mots de passe, un visage ne peut pas être « reset » en cas de fuite, ce qui aggrave l’impact à long terme.
- Alerte sectorielle : L’incident met en lumière la fragilité des startups tech qui traitent des données sensibles sans les garde-fous de sécurité des grands groupes.
L’anatomie de la faille : Quand le stockage objet devient un risque majeur
Dans l’infrastructure cloud moderne, les buckets de stockage objet (comme Amazon S3, Azure Blob Storage ou Google Cloud Storage) sont souvent utilisés pour héberger des médias lourds : images, vidéos, documents PDF. Pour les services de vérification d’identité (KYC - Know Your Customer), ces images ne sont pas de simples fichiers ; ce sont des empreintes biométriques.
L’incident ClarityCheck illustre un schéma classique mais dévastateur. Le flux de travail typique est le suivant :
- L’utilisateur soumet une photo de son visage via une application mobile ou web.
- L’application envoie l’image à un backend qui la stocke dans un bucket S3 pour traitement ultérieur (analyse biométrique, archivage).
- Le backend génère un lien temporaire (presigned URL) ou accède directement via les API IAM.
La faille survient lorsque l’accès au bucket n’est pas restreint par des politiques IAM strictes, mais par une simple configuration d’ACL qui autorise public-read. Dans ce cas, n’importe qui connaissant ou découvrant le nom du bucket (souvent devinable ou indexable via des outils comme cloud_enum) peut lister les objets et télécharger les fichiers directement via HTTP/HTTPS, sans aucune authentification.
Pour un consultant IT ou un administrateur système, la distinction est cruciale : les buckets S3 ne sont pas des serveurs web par défaut. Ils ne sont sécurisés que si vous activez explicitement les restrictions. Par défaut, la plupart des nouveaux buckets sont privés, mais les configurations héritées, les scripts d’automatisation mal écrits ou les erreurs de fusion de code (merge conflicts) dans les templates Terraform ou CloudFormation peuvent inverser cette logique.
# Exemple de vérification rapide de l'exposition d'un bucket S3
# Si cette commande renvoie des objets, le bucket est PUBLIC.
aws s3api list-objects-v2 --bucket mon-bucket-kyc
# Pour vérifier les ACLs spécifiques :
aws s3api get-bucket-acl --bucket mon-bucket-kyc
Dans le cas de ClarityCheck, l’exposition de 9 millions de fichiers suggère non seulement une ACL publique, mais potentiellement l’absence de chiffrement au repos ou de journalisation des accès (CloudTrail) pour détecter l’anomalie avant qu’elle ne devienne une fuite de masse.
Le risque biométrique : Une donnée unique et immuable
Les consultants en cybersécurité le savent mieux que quiconque : le traitement des données personnelles (RGPD, CCPA) est complexe. Le traitement des données biométriques est exponentiellement plus dangereux.
Un mot de passe compromis peut être réinitialisé. Une adresse e-mail peut être changée. Un numéro de carte bancaire peut être annulé. Un visage, lui, ne change pas.
Lorsque des images de visages sont exposées, elles peuvent être utilisées pour :
- Contourner les systèmes de reconnaissance faciale : Créer des profils 3D ou des deepfakes pour débloquer des applications bancaires ou accéder à des zones sécurisées physiques.
- Vol d’identité à grande échelle : Combiner les visages avec d’autres données fuitées (noms, dates de naissance) pour créer des identités synthétiques crédibles.
- Chantage et harcèlement : Utiliser les images de manière non consentie.
Pour les équipes IT, cela signifie que la classification des données doit être affinée. Une image de profil est une donnée personnelle ; une image de visage destinée à la vérification biométrique est une catégorie spéciale de données personnelles selon le RGPD (Article 9). Elle exige des mesures de sécurité techniques et organisationnelles spécifiques, bien au-delà d’une simple sauvegarde standard.
Audit et durcissement : Ce que vos équipes doivent vérifier aujourd’hui
Face à un tel incident, la réponse ne doit pas être réactive mais préventive. Voici les actions concrètes que tout administrateur système ou ingénieur cloud doit implémenter dans ses environnements, qu’ils gèrent des buckets S3, Azure ou GCP.
1. Interdiction des ACLs publiques
La règle d’or est simple : Aucun bucket ne doit être public. Utilisez les politiques de bucket (Bucket Policies) et les rôles IAM pour accorder l’accès. Les ACLs (Access Control Lists) sont obsolètes pour la plupart des cas d’usage modernes et sont source d’erreurs.
// Exemple de politique de bucket S3 sécurisée (deny all public)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::mon-bucket-kyc/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyPublicAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::mon-bucket-kyc/*"
}
]
}
2. Chiffrement et rotation des clés
Assurez-vous que le chiffrement côté serveur (SSE-KMS ou SSE-S3) est activé par défaut. Mieux encore, forcez le chiffrement côté client si les données sont sensibles, et gérez les clés via AWS KMS avec une rotation automatique.
3. Détection et alerting
Configurez les alertes sur les événements de liste (ListBucket) et de téléchargement (GetObject) anormaux. Utilisez Amazon Macie ou des outils tiers pour scanner automatiquement les buckets à la recherche de données sensibles (PII, biométrie) exposées publiquement.
# Activer les journaux de service S3 vers un bucket dédié (Bucket Logging)
aws s3api put-bucket-logging \
--bucket mon-bucket-kyc \
--bucket-logging-status "{\"LoggingEnabled\":{\"TargetBucket\":\"mon-bucket-audit\",\"TargetPrefix\":\"logs/kyc/\"}}"
4. Gestion des données de cycle de vie
Les images de vérification d’identité ne doivent pas être conservées indéfiniment si elles ne sont plus nécessaires. Implémentez des règles de vie (Lifecycle Policies) pour supprimer automatiquement les objets après un délai défini (ex : 30 jours après la vérification réussie), sauf si la loi exige un archivage plus long.
Bonnes pratiques pour consultants IT
En tant que consultant, votre valeur réside dans votre capacité à identifier ces risques avant qu’ils ne deviennent des incidents de presse. Intégrez ces points dans vos audits et vos recommandations :
- Revue des configurations "Shift-Left" : Intégrez la vérification de l’exposition publique des buckets dans votre pipeline CI/CD. Un simple check
aws s3api get-bucket-acldans vos tests de déploiement peut sauver votre client. - Sensibilisation des développeurs : Les développeurs pensent souvent que "public" signifie "accessible par le frontend". Expliquez-leur la différence entre servir un fichier via une application backend (sécurisé) et le placer dans un bucket public (risqué).
- Incident Response Plan (IRP) : Assurez-vous que votre client a une procédure claire en cas de découverte d’exposition. Qui notifie ? Comment on purge ? Comment on préviennent les régulateurs (CNIL, etc.) ? Le temps est un ennemi en cybersécurité.
- Audit des dépendances : Si vous utilisez des frameworks ou des librairies tierces pour gérer le stockage, vérifiez leurs configurations par défaut. Beaucoup de scaffolds créent des buckets publics pour simplifier le développement initial, et ces configurations survivent jusqu’en production.
- Chiffrement de bout en bout : Pour les données biométriques, envisagez le chiffrement avant l’envoi vers le cloud (Zero Trust Storage). Même si le bucket est compromis, les données restent illisibles sans la clé de déchiffrement, qui est gérée séparément.
Points clés
L’affaire ClarityCheck n’est pas une anomalie, c’est la manifestation d’une tendance structurelle : la migration massive vers le cloud a emporté avec elle des millions de buckets mal configurés. Pour les consultants IT, c’est une opportunité de positionner la sécurité des données non structurées comme un pilier central de la conformité et de la protection des actifs clients.
Les points essentiels à retenir pour votre pratique quotidienne sont :
- Zéro bucket public : C’est une règle absolue, non négociable, sauf cas d’usage très spécifique (comme un site statique public, mais même là, un CDN est préférable).
- La biométrie est une donnée critique : Elle exige le même niveau de protection que les clés privées.
- L’automatisation est la clé : Vous ne pouvez pas compter sur la vigilance humaine pour configurer correctement des milliers de buckets. Utilisez Terraform, Pulumi ou les outils natifs du cloud pour imposer les bonnes pratiques par défaut.
- La surveillance doit être proactive : Détecter une fuite après 6 mois est trop tard. Les outils de détection de données exposées doivent tourner en continu.
En fin de compte, la sécurité n’est pas un produit que l’on achète, c’est une discipline que l’on pratique. Chaque bucket configuré, chaque politique IAM rédigée, est une décision de sécurité. Ne laissez jamais cette responsabilité aux paramètres par défaut.
Source : Ars Technica
