Meilleures pratiques en production

Keychain abstrait le backend de signature, mais l'exploitation d'un signataire en production reste votre responsabilité. Ces pratiques s'appliquent à tous les backends ; consultez Choisir un backend pour en sélectionner un.

Séparer les signataires chauds et froids

Utilisez un signataire opérationnel à faible solde (« chaud ») pour les transactions fréquentes et automatisées, et un signataire distinct à haute valeur (« froid ») pour les mouvements de trésorerie. Appuyez le signataire froid sur une garde MPC ou un HSM cloud, et exigez des politiques d'approbation avant qu'il signe. L'interface étant identique, chaque rôle peut utiliser un backend différent sans modifier les points d'appel.

Effectuer une rotation délibérée des clés

Sur Solana, la clé de signature est l'adresse du compte, donc la rotation d'une clé produit une nouvelle adresse. Planifiez la rotation comme une migration : provisionnez une nouvelle clé, réassignez les autorités concernées (ou transférez les fonds) vers la nouvelle adresse, puis retirez l'ancienne. Utilisez des clés distinctes par environnement afin que les clés devnet ne soient jamais réutilisées sur le mainnet.

Accorder l'accès au moindre privilège

Limitez les identifiants de chaque backend au strict minimum nécessaire pour signer. Pour AWS KMS, il s'agit de kms:Sign, kms:DescribeKey et kms:GetPublicKey sur la clé concernée (la vérification de disponibilité utilise les deux dernières) ; privilégiez les rôles IAM plutôt que les identifiants statiques. Appliquez le même principe aux politiques Vault et aux clés d'API des portefeuilles gérés.

Planifier la disponibilité

Les backends distants dépendent d'un service réseau. Vérifiez la disponibilité avant de vous appuyer sur un signataire (isAvailable() en TypeScript, is_available() en Rust et Python, IsAvailable(ctx) en Go), relancez les échecs des backends de signature seule avec un backoff, et définissez une solution de repli en cas d'indisponibilité. Ne relancez pas aveuglément un backend qui diffuse les transactions (Crossmint, mode auto natif de Fordefi) : consultez Gérer les diffusions non confirmées. Keychain impose le HTTPS sur les URL de base configurées, rejette les redirections et applique un délai d'expiration des requêtes par défaut.

Gérer les diffusions non confirmées

Crossmint et le mode auto natif de Fordefi signent et diffusent côté serveur : un appel en échec ne signifie donc pas que rien n'a été envoyé. Lorsque le fournisseur a pu accepter la transaction, Keychain renvoie BROADCAST_UNCONFIRMED (SignerError::BroadcastUnconfirmed en Rust). L'erreur contient l'identifiant de transaction du fournisseur lorsque la création a été acceptée, et contient toujours la clé d'idempotence sous laquelle la création a été envoyée, dérivée du message.

• Réconciliez l'état avec le fournisseur à l'aide de l'identifiant de transaction avant toute autre action.
• Renvoyer la transaction à l'identique (octet pour octet) est sans risque : la clé d'idempotence la dédoublonne.
• Reconstruire la transaction (avec un nouveau blockhash, par exemple) produit une nouvelle clé et donc un nouveau transfert.

Protéger les secrets et le transport

• Les backends distants imposent le HTTPS sur les URL de base configurées et rejettent les redirections. La seule exception est Vault, qui accepte le HTTP simple sur l'interface loopback afin qu'un vault server -dev local fonctionne.
• Fournissez les clés API, tokens et identifiants depuis un gestionnaire de secrets ou des variables d'environnement — ne les codez jamais en dur ni ne les validez dans le contrôle de source.
• Keychain assainit les réponses d'erreur pour éviter que des secrets ne fuient dans les journaux ; maintenez vos propres journaux exempts d'identifiants bruts et de matériel de clé.

Surveiller et auditer les signatures

Suivez le taux de succès des signatures, la latence et le nombre d'échecs, et alertez en cas de pics — consultez les métriques dans Disponibilité en production. Activez les journaux d'audit côté fournisseur (KMS, Vault ou dépositaire) et réconciliez-les avec les transactions soumises par votre application.

Savoir ce que Keychain vérifie

• Keychain valide l'étape de signature, pas votre transaction : il n'y a ni simulation, ni vérification du contenu de la transaction, ni moteur de politiques. Appliquez ces contrôles dans votre application ou via les contrôles de politique du fournisseur.
• Le mode manuel natif de Fordefi réécrit la transaction (blockhash, instructions de frais Compute Budget) avant de la signer. Poursuivez à partir de la transaction renvoyée, jamais de celle que vous avez soumise, et exécutez-la avant tout autre signataire.
• Rust efface (zeroize) les tampons de clés intermédiaires ; Python et Go en sont incapables. Avec le backend Memory dans ces langages, considérez toute la mémoire du processus comme sensible.
• Avec Ledger, l'écran de l'appareil est la seule description fiable de ce qui est en train d'être signé. N'activez pas la fonctionnalité unsafe-debug ni la journalisation TRACE pour solana_remote_wallet en production, car toutes deux consignent des détails sur l'appareil et la transaction.

Consultez le modèle de sécurité pour une vue d'ensemble.