HTTPS partout
Toute communication entre votre appareil Twoody, l'application mobile/web et nos serveurs passe exclusivement par TLS 1.2 ou supérieur. HTTP simple est refusé au niveau serveur, pas simplement redirigé.
Sécurité & confidentialité
Transport et chiffrement
Comment vos données voyagent entre vos appareils et nos serveurs, et comment elles sont stockées au repos.
Chaque octet qui quitte votre téléphone, votre navigateur ou votre enceinte Twoody voyage en TLS authentifié avec confidentialité persistante. Une fois en base, tout ce qui est sensible (clés API, credentials tiers, digests de session, empreintes vocales) est chiffré à nouveau avec des clés stockées hors de la base. Un backup volé est du bruit cryptographique ; un paquet capturé est du bruit cryptographique ; compromettre l'un des deux ne donne rien.
HSTS + preload
Les navigateurs sont instruits de toujours utiliser HTTPS pour twoody.com et ses sous-domaines pendant un an, avec includeSubDomains et preload. Notre domaine est soumis à la liste HSTS preload, rendant impossible toute rétrogradation même à la première visite.
TLS 1.3 + confidentialité persistante
Les connexions négocient TLS 1.3 quand c'est supporté et basculent sur TLS 1.2. La confidentialité persistante (ECDHE) est obligatoire sur chaque suite acceptée, donc une fuite future de notre clé privée ne peut pas déchiffrer du trafic enregistré.
CDN durci
Notre frontal Cloudflare bloque les bots malveillants (Bot Fight Mode), surveille l'émission de certificats (Certificate Transparency), applique nos règles WAF et absorbe le trafic DDoS en amont de notre origine.
DNSSEC activé
Notre zone DNS est signée, empêchant l'empoisonnement de cache chez les résolveurs qui honorent DNSSEC. Le mail et les sous-domaines pointés sur twoody.com ne peuvent pas être silencieusement détournés au niveau DNS.
Chiffrement au repos
Les colonnes sensibles (clés API utilisateur, credentials tiers, digests de session) sont chiffrées avec des clés distinctes du reste de la base, via ActiveRecord Encryption. Un dump de base de données ne donne pas accès aux secrets.
Backups chiffrés
Les backups de la base de production sont chiffrés au repos et en transit, conservés sur une fenêtre bornée, et l'accès est limité à l'opérateur principal avec des logs d'audit par action.
Principe du moindre stockage
La meilleure protection d'un secret, c'est de ne pas le stocker. Nous ne stockons pas les numéros de carte (Stripe le fait), nous ne persistons pas l'audio brut des mots d'activation au-delà du strict nécessaire, et nous ne conservons pas de logs verbeux pour les requêtes réussies.
Plongée technique
Comment le handshake TLS est verrouillé
Notre load balancer présente une liste moderne de suites cryptographiques : les suites AEAD TLS 1.3 d'abord (AES-GCM, ChaCha20-Poly1305), puis un repli court TLS 1.2 qui est ECDHE-only. Les primitives faibles (RC4, 3DES, export-grade, échange de clé RSA statique) sont refusées au handshake — un client qui ne peut pas négocier la confidentialité persistante reçoit un échec de connexion propre plutôt qu'une session dégradée. OCSP stapling est activé pour que les navigateurs puissent vérifier la révocation du certificat sans aller-retour supplémentaire vers notre CA.
La chaîne de certificats utilise les intermédiaires ECDSA de Let's Encrypt ; nous surveillons les logs Certificate Transparency et alertons sur tout certificat émis pour notre domaine que nous n'aurions pas demandé.
Distinction des clés au repos
Nous maintenons trois clés de chiffrement distinctes, stockées en variables d'environnement et jamais en base : une clé primaire pour les colonnes non-déterministes (ciphertext différent à chaque écriture), une clé déterministe pour les colonnes devant être requêtables par égalité, et un sel de dérivation de clé. Notre process de boot refuse de démarrer en production si l'une des trois manque ou porte encore le placeholder de dev — vous ne pouvez pas accidentellement déployer un build avec un chiffrement faible.
La rotation de clé est une opération de premier plan. La clé primaire est versionnée, donc une clé tournée chiffre les nouvelles lignes tandis que les lignes existantes restent lisibles sous la génération précédente ; un job en arrière-plan peut re-chiffrer à la demande.
Ce que nous ne chiffrons pas, volontairement
Les métadonnées non sensibles — identifiants utilisateur, timestamps, compteurs de lignes, SKU produits — sont stockées en clair. Tout chiffrer sans discernement casserait l'indexation, casserait l'analytique, et n'apporterait aucun bénéfice réel ; le modèle de menace pour ces données est « ils ont déjà votre base de données », auquel cas des identifiants chiffrés ne sont pas plus sûrs que du plaintext.
Nous chiffrons ce qui compte (jetons, secrets, biométrie, credentials tiers), nous documentons ce que nous chiffrons, et nous nous appuyons sur les contrôles d'accès Postgres ordinaires pour le reste.
Chaque saut réseau — votre téléphone vers nous, votre enceinte vers nous, notre serveur vers OpenAI — est couvert par l'une de ces couches. Nous ne faisons tourner aucun service interne non chiffré sur un réseau qu'une requête utilisateur peut toucher.