Chiffrement
Où le chiffrement est utilisé, et où il ne l'est pas encore.
Le chiffrement protège une vérification à plusieurs endroits distincts : la connexion, l'image, le secret, la sauvegarde, le mot de passe. Nous préférons énumérer chacun honnêtement plutôt que de dire « chiffré » une seule fois et de vous laisser supposer que cela couvre tout.
En transit
TLS en périphérie, et appliqué sur la base de données du registre.
Chaque requête vers ShieldID est chiffrée avant d'atteindre l'application.
- La périphérie publique met fin au TLS pour chaque connexion, avec HSTS et un ensemble d'en-têtes de sécurité verrouillé, de sorte qu'une requête est chiffrée avant d'atteindre tout ce qui se trouve derrière.
- La base de données principale du registre impose le TLS sur chaque connexion qu'elle accepte. Une connexion en clair est refusée d'emblée, et non simplement déconseillée par la configuration.
- L'application vérifie le certificat de la base de données auprès d'une autorité épinglée et contrôle son nom d'hôte, plutôt que de se fier au premier certificat qui se présente.
Au repos
Les images de pièces d'identité et les dates de naissance sont chiffrées. Nous précisons ce qui ne l'est pas encore.
« Chiffré au repos » est souvent dit d'une plateforme entière d'un seul souffle. Voici ce que cela couvre réellement aujourd'hui.
- Images de pièces d'identité et égoportrait
- Chiffrées avec AES-256-GCM pendant leur stockage, avant la purge automatique qui les supprime.
- Date de naissance
- Stockés chiffrés, jamais en texte clair, partout où un dossier de vérification les conserve.
- Secrets (clés API, identifiants de base de données, clés de signature)
- Conservés dans un coffre de secrets dédié, et non dans la configuration de l'application ou le code source.
- Le reste de la base de données et les volumes de stockage généraux
- Non chiffré au niveau du disque ou de la base de données à l'heure actuelle. Nous le disons clairement plutôt que de laisser entendre une couverture généralisée.
Secrets
Un seul coffre-fort, protégé par jeton, avec un historique des rotations consigné.
Les identifiants d'application ne sont pas dispersés dans des fichiers de configuration.
Centralisé
Les clés API, les identifiants de base de données et les secrets de webhook sont conservés dans un système dédié de gestion des secrets, lu et modifié uniquement par l'entremise d'une API authentifiée et protégée par jeton.
Rotation auditée
Un processus de rotation dédié consigne chaque modification d'identifiant et chaque tentative refusée dans un journal inviolable qui ne stocke que les empreintes des valeurs, jamais les valeurs elles-mêmes.
Jamais dans le code ni la configuration
Les secrets sont lus depuis le coffre-fort au démarrage, et non versés dans le code source ni laissés dans un fichier d'environnement livré avec un déploiement.
Sauvegardes
Chiffrées avant de quitter la mémoire, avec un exercice de restauration que vous pouvez exécuter sans toucher à la production.
Une sauvegarde couvre l'application, sa configuration et la base de données.
- Chiffrée avec AES-256, à l'aide d'une clé conservée dans le coffre-fort des secrets. Si cette clé n'est pas disponible, le script de sauvegarde refuse d'écrire un fichier non chiffré plutôt que de se rabattre silencieusement sur cette option.
- Une procédure de restauration documentée et scriptée existe et prend en charge un mode de répétition vers un emplacement temporaire, de sorte que le processus peut être testé sans toucher aux données en production.
- Les sauvegardes demeurent actuellement dans les mêmes locaux. Nous n'offrons pas de sauvegardes géoredondantes ni de site de reprise après sinistre distinct, et nous le précisons sur les pages de résidence des données et de conformité, et pas seulement ici.
Mots de passe, sessions et clés API
Rien de ce qui vous authentifie n'est stocké sous une forme que quelqu'un pourrait lire et réutiliser.
Trois types de secrets différents, trois traitements différents, tous à sens unique.
- Mots de passe
- Hachés, jamais stockés ni journalisés en clair.
- Jetons de session
- Le jeton dans le témoin de session de votre navigateur est une valeur aléatoire de 32 octets définie comme témoin HttpOnly.
- Clés API
- Stockées sous forme de hachages SHA-256. Seul un court préfixe est conservé en clair, ce qui vous permet de reconnaître une clé dans une liste sans que sa valeur complète puisse jamais être récupérée.
Ce que cette page ne prétend pas
Aucune protection contre les attaques DDoS, aucun WAF, aucune géoredondance.
Nous ne sommes actuellement pas derrière un réseau de diffusion de contenu ni un pare-feu applicatif Web, et nous ne prétendons pas chiffrer chaque octet stocké au niveau du disque ou de la base de données. Une limitation de débit de base protège la connexion et d'autres points de terminaison coûteux, mais il ne s'agit pas encore d'une couche de protection contre les abus robuste et permanente. Si un contrôle précis importe pour l'évaluation de votre organisation, posez-nous la question directement plutôt que de présumer qu'une formule générale le couvre.
Questions
Des réponses claires sur le chiffrement.
Autres renseignements au dossier
Découvrez comment la conservation et la résidence des données s'articulent.
Le chiffrement est un contrôle parmi d'autres. Consultez ce qui est purgé, quand, et où se trouvent les données tant qu'elles existent.