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 Zugangsdaten jedes Backends auf das Minimum, das zum Signieren nötig ist. Für AWS KMS sind das kms:Sign, kms:DescribeKey und kms:GetPublicKey für den jeweiligen Schlüssel (die Verfügbarkeitsprüfung nutzt die letzten beiden); bevorzugen Sie IAM-Rollen gegenüber statischen Zugangsdaten. Wenden Sie dasselbe Prinzip auf Vault-Richtlinien und API-Schlüssel verwalteter Wallets an.

Verfügbarkeit einplanen

Remote-Backends hängen von einem Netzwerkdienst ab. 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 fehlgeschlagene reine Signiervorgänge mit Backoff und definieren Sie einen Fallback-Pfad für Ausfälle. Wiederholen Sie bei einem Backend, das auch sendet (Crossmint, Fordefi Native-Auto-Modus), nicht blind: siehe Unbestätigte Broadcasts behandeln. Keychain erzwingt HTTPS für konfigurierte Basis-URLs, lehnt Weiterleitungen ab und wendet ein standardmäßiges Anfrage-Timeout an.

Unbestätigte Broadcasts behandeln

Crossmint und der Fordefi Native-Auto-Modus signieren und senden serverseitig, ein fehlgeschlagener Aufruf bedeutet also 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, wenn das Erstellen akzeptiert wurde, und immer den Idempotenzschlüssel, unter dem das Erstellen gesendet wurde, abgeleitet aus der Nachricht.

• Gleichen Sie den Status zuerst anhand der Transaktions-ID mit dem Anbieter ab, bevor Sie irgendetwas anderes tun.
• Das erneute Senden der byte-identischen Transaktion ist sicher: Der Idempotenzschlüssel dedupliziert sie.
• Wenn Sie die Transaktion neu aufbauen (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 Prüfungen in Ihrer Anwendung oder in den Richtlinienkontrollen des Anbieters durch.
• Der Fordefi Native-Manuell-Modus schreibt die Transaktion um (Blockhash, Anweisungen für Compute-Budget-Gebühren), bevor er sie signiert. Machen Sie mit der zurückgegebenen Transaktion weiter, niemals mit der von Ihnen eingereichten, und führen Sie ihn vor jedem anderen Signer aus.
• Rust überschreibt Zwischenpuffer für Schlüssel mit Nullen (Zeroize); Python und Go können das nicht. Behandeln Sie bei der Memory- Backend-Variante 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.

Weitere Informationen finden Sie im Sicherheitsmodell für das Gesamtbild.