Sécurité
Une adresse confiée à YesWeCheck est stockée chiffrée et retrouvée par une empreinte, jamais comparée en clair. Une clé API n'est pas conservée, seule son empreinte l'est. Une clé exposée dans une page web ne fonctionne que depuis les domaines déclarés, et les durées de conservation des données sont écrites, pas laissées à l'appréciation.
YesWeCheck ne détient aucune certification formelle de sécurité, et n'en revendique aucune. Ce qui est décrit ici est vérifiable dans le comportement du service, pas dans un audit tiers.
Les mesures, une par une
Elles se répartissent en trois familles : ce qui protège les données au repos, ce qui protège les identifiants d'accès, et ce qui limite les dégâts quand un identifiant échappe à son propriétaire. La troisième famille compte autant que les deux premières, parce qu'un secret finit toujours par circuler.
| Ce qui est protégé | Mécanisme |
|---|---|
| Adresses email stockées | Chiffrées au repos en AES-256-GCM, avec une clé de données gérée par le coffre de clés d'OVHcloud. La colonne en clair n'existe pas : une adresse est stockée sous sa forme chiffrée, et retrouvée par un index aveugle HMAC-SHA-256. |
| Recherche sans déchiffrement | L'index aveugle permet de retrouver une adresse, de vérifier son unicité et de la rapprocher d'une liste, sans jamais la déchiffrer ni la comparer en clair. |
| Mots de passe | Stockés en empreinte bcrypt. Aucun mot de passe n'est conservé sous une forme réversible, et aucun ne circule dans les journaux. |
| Clés API | Le secret n'est jamais stocké. La base conserve son empreinte SHA-256 et son préfixe de neuf caractères, qui sert uniquement à l'afficher dans l'interface. Une clé perdue se remplace, elle ne se relit pas. |
| Rotation des clés | Une clé se remplace sans interruption : l'ancienne empreinte reste acceptée pendant la période de grâce choisie, puis cesse de l'être. La rotation ne demande donc pas de déployer les deux valeurs en même temps. |
| Clés exposées dans une page | Une clé de portée « widget » est publique par nature. Le serveur refuse de la servir si elle ne porte aucun domaine autorisé, et refuse toute requête dont l'origine ne correspond à aucun de ces domaines. |
| Restriction par adresse IP | Une clé peut être restreinte à une liste d'adresses IP. Quand les deux restrictions coexistent, l'adresse IP et le domaine doivent correspondre tous les deux : une origine forgée ne suffit pas à contourner la restriction réseau. |
| Accès à l'interface | Double authentification par code temporaire, gestion des appareils connus, et liste d'adresses IP autorisées par utilisateur, avec une procédure de déblocage par courriel quand la connexion vient d'ailleurs. |
| Tentatives répétées | Les points d'entrée d'authentification sont limités en débit par adresse IP réelle, compteur partagé entre les processus. Le seuil exact n'est pas publié. |
| Journal d'appels | Chaque appel est tracé avec sa date, son statut, son organisation et sa clé. Le contenu analysé n'y figure pas en clair. |
| Transport | Toutes les surfaces publiques sont servies en HTTPS, certificat renouvelé automatiquement. Aucune n'est joignable en clair. |
Les adresses au repos
Le chiffrement d'une adresse email pose un problème pratique : une donnée chiffrée ne se cherche pas. Le service résout ce problème en stockant deux valeurs pour une même adresse, une forme chiffrée qui se déchiffre quand il faut la restituer, et une empreinte qui sert d'index et ne se déchiffre jamais.
La forme chiffrée
Chiffrement AES-256-GCM, clé de données gérée par le coffre de clés d'OVHcloud. Elle sert à restituer l'adresse quand le client la redemande, et à rien d'autre.
L'index aveugle
Une empreinte HMAC-SHA-256 de l'adresse normalisée. Elle permet de retrouver une ligne, de vérifier une unicité et de rapprocher une adresse d'une liste, sans jamais la déchiffrer.
Ce qui n'existe pas
Aucune colonne ne conserve l'adresse en clair. Les journaux d'activité en portent l'empreinte, pas le contenu.
Le vocabulaire mérite d'être précis, parce qu'il est souvent employé de travers : le chiffrement AES-256-GCM porte sur les adresses email stockées. Les mots de passe, eux, ne sont pas chiffrés mais réduits à une empreinte bcrypt, et les clés API à une empreinte SHA-256. Ces deux dernières valeurs sont irréversibles par construction, c'est ce qu'on attend d'elles.
Les clés API, et ce qui limite les dégâts
Une clé API est un secret qui voyage : elle finit dans un dépôt de code, dans une variable d'environnement partagée, parfois dans une page web. La sécurité ne consiste donc pas à croire qu'elle restera secrète, mais à réduire ce qu'elle permet à celui qui la trouve, et à permettre de la remplacer sans interruption.
Ce qui protège une clé de widget n'est pas un chiffrement, c'est sa portée. Une clé de portée « widget » ne peut appeler que la validation, et seulement depuis un domaine déclaré. Recopiée ailleurs, elle est refusée par le serveur avant d'atteindre le moteur de validation.
Deux restrictions se cumulent sur une même clé, une liste de domaines autorisés et une liste d'adresses IP autorisées. Quand les deux sont définies, la requête doit satisfaire les deux : forger une origine ne suffit pas à contourner la restriction réseau, et venir de la bonne adresse IP ne suffit pas à contourner la restriction de domaine.
Une clé se remplace sans interruption de service. L'ancienne empreinte reste acceptée pendant la période de grâce choisie, le temps de déployer la nouvelle valeur, puis elle cesse de l'être. Le détail de la procédure est dans la documentation : voir comment un widget résout sa clé côté serveur .
Combien de temps les données sont conservées
Les adresses soumises ne sont pas conservées pour être revendues, réutilisées ou enrichies. Elles servent à produire le résultat demandé, puis elles sont supprimées selon des durées écrites, dont la plus longue vaut 90 jours et ne porte plus que des compteurs.
| Donnée | Durée | Détail |
|---|---|---|
| Résultats détaillés d'un traitement par lots | 7 jours | Le compte à rebours part de la fin du traitement. Passé ce délai, les résultats ligne à ligne sont supprimés et le fichier n'est plus téléchargeable. |
| Rapport d'audit non débloqué | 30 jours | Un audit conserve plus longtemps de quoi être débloqué. Une fois débloqué, il repasse sous la règle des 7 jours. |
| Adresses sources importées | Durée du traitement | Les lignes importées sont effacées à la clôture de chaque lot de traitement. Elles ne survivent pas à la fin du traitement. |
| Métadonnées et statistiques d'un traitement | 90 jours | Nom du fichier, compteurs et répartition des statuts, sans les adresses. C'est ce qui alimente l'historique de la console. |
| Journaux d'appels API | Réglable | La durée de conservation est un réglage, entre 7 jours et 3650 jours selon la table. La purge est automatique. |
| Compte supprimé | 30 jours | La suppression est demandée depuis le compte, confirmée par un code envoyé par courriel, puis exécutée après un délai de rétractation de 30 jours pendant lequel elle reste annulable. |
La suppression d'un compte est un droit, et elle est outillée comme tel : elle se demande depuis le compte, se confirme par un code envoyé par courriel, et reste annulable pendant le délai de rétractation. Passé ce délai, elle est exécutée sans intervention humaine.
Ce que ces mesures ne font pas
Le chiffrement au repos protège la base, pas l'usage. Une clé API volée reste utilisable jusqu'à sa révocation, et un compte dont le mot de passe fuite reste accessible tant que la double authentification n'est pas activée. C'est pourquoi la restriction par domaine et par adresse IP compte autant que le chiffrement.
Deux conséquences pratiques. La première : activez la double authentification sur les comptes qui administrent une organisation, c'est la seule mesure qui survit à une fuite de mot de passe. La seconde : restreignez les clés de production à vos domaines et à vos adresses IP, c'est la seule mesure qui survit à une fuite de clé.
La question de savoir où les données résident, et qui d'autre les traite, est distincte de celle des mécanismes. Elle est traitée à part : consulter la politique de résidence des données .
Questions fréquentes
- Les adresses email sont-elles stockées en clair ?
- Non. Les adresses sont chiffrées au repos en AES-256-GCM, avec une clé de données gérée par le coffre de clés d'OVHcloud, et retrouvées par un index aveugle HMAC-SHA-256 qui permet la recherche sans déchiffrement.
- Qu'est-ce qui protège une clé API exposée dans une page web ?
- Ce qui protège une clé de widget n'est pas un chiffrement, c'est sa portée. Une clé de portée « widget » ne peut appeler que la validation, et seulement depuis un domaine déclaré. Recopiée ailleurs, elle est refusée par le serveur avant d'atteindre le moteur de validation.
- Combien de temps les données sont-elles conservées ?
- Les adresses soumises ne sont pas conservées pour être revendues, réutilisées ou enrichies. Elles servent à produire le résultat demandé, puis elles sont supprimées selon des durées écrites, dont la plus longue vaut 90 jours et ne porte plus que des compteurs.
- YesWeCheck détient-il une certification de sécurité ?
- YesWeCheck ne détient aucune certification formelle de sécurité, et n'en revendique aucune. Ce qui est décrit ici est vérifiable dans le comportement du service, pas dans un audit tiers.