Best Practices für den Produktionsbetrieb

Keychain abstrahiert das Signing-Backend, aber der Betrieb eines Signers im Produktionsbetrieb liegt weiterhin in Ihrer Verantwortung. Diese Praktiken gelten für alle Backends; siehe Choosing a backend zur Auswahl eines geeigneten.

Hot- und Cold-Signer trennen

Verwenden Sie einen Signer mit geringem Guthaben ("Hot"-Signer) für häufige, automatisierte Transaktionen und einen separaten Signer für hohe Werte ("Cold"-Signer) für Treasury-Bewegungen. Sichern Sie den Cold-Signer mit MPC-Custody oder einem Cloud-HSM ab und verlangen Sie Genehmigungsrichtlinien vor der Unterzeichnung. Da die Schnittstelle identisch ist, kann jede Rolle ein anderes Backend verwenden, ohne die Aufrufstellen zu ändern.

Schlüssel gezielt rotieren

Bei Solana ist der Signing-Schlüssel die Kontenadresse, daher erzeugt das Rotieren eines Schlüssels eine neue Adresse. Planen Sie die Rotation als Migration: Stellen Sie einen neuen Schlüssel bereit, weisen Sie die relevanten Berechtigungen (oder übertragen Sie Mittel) der neuen Adresse zu und deaktivieren Sie dann den alten. Verwenden Sie für jede Umgebung separate Schlüssel, damit Devnet-Schlüssel niemals im Mainnet wiederverwendet werden.

Zugriff nach dem Prinzip der minimalen Rechte vergeben

Beschränken Sie die Anmeldedaten jedes Backends auf das Minimum, das zum Signieren erforderlich ist. Für AWS KMS sind das kms:Sign, kms:DescribeKey und kms:GetPublicKey für den spezifischen Schlüssel (die Verfügbarkeitsprüfung nutzt die letzten beiden); bevorzugen Sie IAM-Rollen gegenüber statischen Anmeldedaten. Wenden Sie dasselbe Prinzip auf Vault-Richtlinien und verwaltete Wallet-API-Schlüssel an.

Verfügbarkeit einplanen

Remote-Backends sind auf einen Netzwerkdienst angewiesen. Prüfen Sie die Verfügbarkeit, bevor Sie sich auf einen Signer verlassen (isAvailable() in TypeScript, is_available() in Rust und Python, IsAvailable(ctx) in Go), wiederholen Sie reine Signierfehler mit Backoff und definieren Sie einen Fallback-Pfad für Ausfälle. Wiederholen Sie bei einem Backend, das Transaktionen per Broadcast sendet (Crossmint, Fordefi im nativen Auto-Modus), nicht blind: siehe Unbestätigte Broadcasts behandeln. Keychain erzwingt HTTPS für konfigurierte Basis-URLs, lehnt Weiterleitungen ab und wendet einen Standard-Anfrage-Timeout an.

Unbestätigte Broadcasts behandeln

Crossmint und Fordefi im nativen Auto-Modus signieren und senden serverseitig per Broadcast, daher bedeutet ein fehlgeschlagener Aufruf nicht, dass nichts angekommen ist. Wenn der Anbieter die Transaktion möglicherweise akzeptiert hat, meldet Keychain BROADCAST_UNCONFIRMED (SignerError::BroadcastUnconfirmed in Rust). Der Fehler enthält die Transaktions-ID des Anbieters, sofern die Erstellung akzeptiert wurde, und stets den Idempotenzschlüssel, unter dem die Erstellung abgeschickt wurde und der aus der Nachricht abgeleitet ist.

• Gleichen Sie den Status anhand der Transaktions-ID mit dem Anbieter ab, bevor Sie irgendetwas anderes tun.
• Die byte-identische Transaktion erneut zu senden ist sicher: Der Idempotenzschlüssel dedupliziert sie.
• Wird die Transaktion neu aufgebaut (zum Beispiel mit einem neuen Blockhash), entsteht ein neuer Schlüssel und damit eine neue Überweisung.

Geheimnisse und Transport schützen

• Remote-Backends erzwingen HTTPS für konfigurierte Basis-URLs und lehnen Weiterleitungen ab. Die einzige Ausnahme ist Vault, das einfaches HTTP auf Loopback akzeptiert, sodass ein lokales vault server -dev funktioniert.
• Stellen Sie API-Schlüssel, Tokens und Anmeldedaten über einen Secret-Manager oder Umgebungsvariablen bereit – codieren Sie diese niemals fest oder übertragen Sie sie in die Quellcodeverwaltung.
• Keychain bereinigt Fehlerantworten, um zu verhindern, dass Geheimnisse in Logs gelangen; halten Sie Ihre eigenen Logs frei von rohen Anmeldedaten und Schlüsselmaterial.

Signing überwachen und auditieren

Verfolgen Sie Signing-Erfolgsrate, Latenz und Fehleranzahl und richten Sie Alarme bei Spitzen ein – siehe die Metriken in Production Readiness. Aktivieren Sie anbieterseitige Audit-Logs (KMS, Vault oder Verwahrstelle) und gleichen Sie diese mit den Transaktionen ab, die Ihre Anwendung einreicht.

Wissen, was Keychain prüft

• Keychain validiert den Signierschritt, nicht Ihre Transaktion: Es gibt keine Simulation, keine Prüfung des Transaktionsinhalts und keine Policy-Engine. Setzen Sie diese Kontrollen in Ihrer Anwendung oder in den Richtlinienkontrollen des Anbieters durch.
• Der native manuelle Modus von Fordefi schreibt die Transaktion um (Blockhash, Anweisungen für die Compute-Budget-Gebühr), bevor er sie signiert. Setzen Sie mit der zurückgegebenen Transaktion fort, niemals mit der von Ihnen eingereichten, und führen Sie sie vor jedem anderen Signer aus.
• Rust überschreibt Zwischenspeicher für Schlüssel mit Nullen (Zeroizing); Python und Go können das nicht. Behandeln Sie mit dem Memory-Backend in diesen Sprachen den gesamten Prozessspeicher als sensibel.
• Bei Ledger ist der Gerätebildschirm die einzige vertrauenswürdige Beschreibung dessen, was signiert wird. Aktivieren Sie in der Produktion weder das Feature unsafe-debug noch das TRACE-Logging für solana_remote_wallet, da beide Geräte- und Transaktionsdetails protokollieren.

Das vollständige Bild finden Sie im Sicherheitsmodell.