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, cela correspond à kms:Sign, kms:DescribeKey et kms:GetPublicKey sur la clé spécifique (la vérification de disponibilité utilise les deux derniers) ; préférez les rôles IAM aux identifiants statiques. Appliquez le même principe aux politiques Vault et aux clés API de portefeuille géré.

Planifier la disponibilité

Les backends distants dépendent d'un service réseau. Vérifiez la disponibilité avant de vous fier à un signataire (isAvailable() en TypeScript, is_available() en Rust et Python, IsAvailable(ctx) en Go), réessayez les échecs de signature seule avec délai exponentiel, et définissez un chemin de repli en cas de panne. Ne réessayez pas aveuglément un backend qui diffuse la transaction (Crossmint, mode auto natif de Fordefi) : voir Gérer les diffusions non confirmées. Keychain impose HTTPS sur les URL de base configurées, rejette les redirections et applique un délai d'expiration de requête par défaut.

Gérer les diffusions non confirmées

Crossmint et le mode auto natif de Fordefi signent et diffusent côté serveur, donc un appel en échec ne signifie pas que rien n'a abouti. 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 avec le fournisseur à l'aide de l'identifiant de transaction avant toute autre action.
• Renvoyer la transaction strictement identique, octet pour octet, est sans risque : la clé d'idempotence la déduplique.
• 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 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 dans 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 qu'il renvoie, jamais de celle que vous avez soumise, et exécutez-le avant tout autre signataire.
• Rust met à zéro les tampons de clés intermédiaires ; Python et Go ne le peuvent pas. 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 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.