Sécurité & résidence des données
RGPD by design. Self-custody d'abord. Sans petites lignes.
Paperkey est construit autour du principe que vos données de licence sont à vous. Vous pouvez les exporter à tout moment, et le RGPD est notre mode opératoire par défaut. Cette page liste ce qui est vrai aujourd'hui, rien de plus.
- Conçu à Paris
- RGPD-compliant
- Aucun tracker tiers
- Export self-custody
- SDK MIT
Résidence des données
Où vos données vivent.
Les enregistrements de licence, les activations et les données clients reposent sur une infrastructure chiffrée opérée intégralement en UE. Les backups utilisent des clés séparées. Rien ne franchit la frontière UE.
- Le stockage et le runtime restent à l'intérieur de l'UE. Aucune région de failover hors UE.
- Les backups sont chiffrés quotidiennement avec des clés conservées séparément des données actives, avec un point-in-time recovery sur 7 jours.
- Comme aucune donnée ne franchit la frontière UE, aucune Standard Contractual Clause n'est requise pour les transferts internationaux.
- Les logs d'audit partagent le même stockage UE. On garde 90 jours d'activité d'écriture, et les events de sécurité (auth, billing, rotation de clé) tant que le compte existe.
RGPD
Une vraie posture privacy.
Le RGPD est notre mode opératoire, pas une feature qu'on facture. Chaque droit des personnes concernées est câblé directement dans le dashboard et l'API.
- Droit d'accès : vous exportez l'intégralité des données liées à votre compte (licences, activations, audit log) depuis le dashboard à tout moment, en JSON ou CSV.
- Droit à l'effacement : la suppression de compte est self-service. Elle cascade sur tous les enregistrements que vous possédez (produits, licences, activations, webhooks, télémétrie agent, références billing). Rien n'est planqué derrière un soft-delete.
- Droit à la portabilité : le même endpoint d'export, structuré et lisible par machine.
- Base légale : exécution contractuelle pour les données de licence, intérêt légitime pour les logs de sécurité, opt-in explicite pour la télémétrie agent.
- Aucun pixel de tracking, aucun tag publicitaire tiers sur ce site. Les analytics sont auto-hébergées avec IPs anonymisées.
Sous-traitants
Chaque tiers qui voit vos données.
On garde cette liste courte volontairement. Aujourd'hui, le seul tiers qui touche aux données liées à votre compte est le fournisseur de billing, et uniquement quand vous avez un abonnement payant. Tout nouveau sous-traitant sera annoncé ici au moins 30 jours avant sa mise en production.
Chiffrement & secrets
Defaults de chiffrement vérifiables.
Defaults solides : TLS 1.3 en externe, AES-256 au repos, et secrets applicatifs hashés plutôt que stockés.
- En transit : TLS 1.3 partout en externe, éligible HSTS preload, aucun fallback HTTP en production.
- Au repos : chiffrement de stockage AES-256, et backups chiffrés sous des clés séparées.
- Les clés API et secrets de webhook sont affichés une seule fois à la création. Ensuite, seuls des hashs one-way restent en base. On ne peut pas les récupérer, vous les régénérez.
- Les mots de passe sont hashés avec un algorithme adaptatif standard. Un timing-decoy fait payer le même coût aux emails inconnus qu'aux vrais, donc le temps de réponse ne révèle aucun compte.
- Les tokens de session sont à durée de vie courte, signés côté serveur, et invalidés à chaque « sign out everywhere ».
Contrôle d'accès
Moindre privilège, audit par défaut.
L'accès opérationnel est étroit, et chaque action administrative qui touche aux données client est loggée, horodatée, et auditable.
- L'authentification à 2 facteurs (TOTP) est disponible pour chaque compte client, et obligatoire pour tout compte avec accès billing.
- Les changements en production passent par un pipeline CI/CD automatisé. Chaque changement est une pull request, gated par tests obligatoires, scan de secrets et audit de dépendances avant de pouvoir merger. Aucun code n'atteint la production à la main.
- Des vérifications d'ownership strictes tournent sur toute route authentifiée, contrôlées par tests d'intégration à chaque changement. Les bugs de classe IDOR échouent au build, pas en production.
- Des rate limiters par IP et par licence protègent l'auth et les endpoints publics validate/activate. L'auth a une limite plus stricte que le cap global, et les seuils exacts tournent.
- Chaque action administrative qui modifie un état (auth, billing, rotation de clé, émission de licence, révocation de licence) est enregistrée dans un audit log append-only.
Gestion d'incident
Si quelque chose arrive, vous le saurez par nous en premier.
On s'engage à notifier directement les clients affectés sous 72 heures à compter de la détection confirmée d'une violation, conformément au RGPD.
- Détection : monitoring continu d'erreurs sur chaque chemin d'API, probes externes d'uptime, et suivi de latence par route. Status page sur status.paperkey.dev.
- Notification : une fenêtre de 72 heures pour les violations confirmées affectant des données client, par email au contact du compte. La CNIL est notifiée en parallèle quand le seuil est atteint.
- Divulgation : un post-mortem public est publié sur paperkey.dev pour tout incident causant plus de 5 minutes d'impact client. Il inclut la timeline, la root cause, le fix, et les actions de suivi.
- Signaler une vulnérabilité : écrire à security@paperkey.dev. On répond sous 2 jours ouvrés. La fenêtre de divulgation coordonnée est de 90 jours, étendue pour les cas sévères.
Modèle de menace
Ce que ça protège, et ce que ça ne protège pas.
Vue clinique de ce que la validation côté serveur peut et ne peut pas défendre. On vous donne la frontière pour que vous puissiez empiler le bon complément par-dessus.
- Ce qu'on protège, côté serveur : le partage de licence au-delà du cap d'activation (la diversité de fingerprints machine est appliquée), la réutilisation d'une licence révoquée (la révocation se propage côté serveur et le SDK refuse les négatifs cachés), la réutilisation d'une licence expirée (la validation est autoritaire pour le statut), le churn d'activation abusif (rate limits par licence + alertes dashboard sur les patterns near-cap ou multi-régions).
- Ce qu'on remonte sans appliquer : le partage sur un seul fingerprint, une géographie IP anormale, des cycles de réactivation suspectement rapides. Le dashboard expose ces signaux ; vous décidez de révoquer, réémettre, ou contacter le client.
- Ce qui reste votre responsabilité côté client : signer votre binaire, vérifier l'intégrité du site d'appel SDK, ne pas hardcoder la clé publique d'une manière qui permettrait son extraction d'un dump mémoire. La validation côté serveur ne peut pas défendre contre un binaire modifié pour skipper l'appel à validate().
- Ce qu'on ne revendique pas faire : prévenir le reverse engineering, obfusquer votre code, contrer la modification mémoire, ou arrêter un attaquant déterminé qui contrôle le runtime. La validation de licence est un check d'intégrité sur la relation commerciale, pas un DRM. Si votre modèle de menace requiert de l'anti-tamper, accouplez Paperkey à une stratégie de code signing et un binary protector.
- Comment marche la détection de partage en pratique : chaque activation est liée à un fingerprint machine haché (machine ID + MAC + classe CPU), capé par licence. Réactiver le même fingerprint est idempotent ; activer un nouveau fingerprint consomme un slot ou retourne 403 si on est au cap. Le dashboard flag la réutilisation de fingerprint, les patterns multi-IP, et l'activité near-cap sur une fenêtre configurable.
Liste honnête
Ce qu'on ne revendique pas.
Un fournisseur de licensing qui exagère sa posture compliance est un risque.
- Pas de SOC 2 Type I ni Type II. On n'est pas à l'échelle où l'audit a du sens, et un faux badge n'aiderait personne. Type I sera poursuivi quand un client enterprise payant en fera une condition de signature.
- Pas d'ISO 27001. Même raisonnement. C'est sur la roadmap, pas sur la home.
- Pas de scope PCI. On ne traite pas de cartes bancaires. Stripe gère ça pour le billing, et vos clients achètent votre soft via votre propre checkout (Stripe, Lemon Squeezy, Paddle, Gumroad, etc.). Paperkey émet et valide uniquement la licence.
- Pas de SLA formel pour l'instant. On en publiera un avant la GA, avec un historique d'incidents public. La cible 99,9 % sur /reliability est un objectif interne, pas un engagement contractuel.
- Pas de badge « trusted by 50+ startups » tant que 50+ startups n'auront pas réellement shippé avec nous.
Une question sécurité ?
Écrivez à un humain. Réponse en heures ouvrées, souvent plus rapide.
Vous hésitez encore ?
Lisez le quickstart de 5 minutes. Ou sautez-le : le SDK a des valeurs par défaut sensées et le dashboard se comprend tout seul.