Najlepsze praktyki produkcyjne

Keychain abstrakcyjnie ujmuje backend podpisujący, jednak obsługa podpisującego w środowisku produkcyjnym nadal należy do Twoich obowiązków. Poniższe praktyki mają zastosowanie do wszystkich backendów; zapoznaj się z Wybieraniem backendu, aby wybrać odpowiedni.

Oddziel sygnatariuszy hot i cold

Używaj operacyjnego sygnatariusza z niskim saldem ("hot") do częstych, zautomatyzowanych transakcji oraz oddzielnego sygnatariusza wysokiej wartości ("cold") do operacji skarbcowych. Zabezpiecz sygnatariusza cold za pomocą MPC custody lub sprzętowego modułu HSM w chmurze i wymagaj polityk zatwierdzania przed podpisaniem. Ponieważ interfejs jest identyczny, każda rola może korzystać z innego backendu bez zmiany miejsc wywołań.

Rotuj klucze w sposób przemyślany

W Solanie klucz podpisujący jest adresem konta, więc rotacja klucza tworzy nowy adres. Planuj rotację jako migrację: zaopatrz się w nowy klucz, przypisz ponownie odpowiednie uprawnienia (lub przenieś środki) na nowy adres, a następnie wycofaj stary. Używaj odrębnych kluczy dla każdego środowiska, aby klucze devnet nigdy nie były ponownie używane w sieci mainnet.

Przyznawaj dostęp z minimalnymi uprawnienieniami

Ogranicz poświadczenia każdego backendu do minimum niezbędnego do podpisywania. W przypadku AWS KMS są to kms:Sign, kms:DescribeKey i kms:GetPublicKey dla konkretnego klucza (sprawdzanie dostępności korzysta z ostatnich dwóch); preferuj role IAM zamiast statycznych poświadczeń. Stosuj tę samą zasadę do polityk Vault i zarządzanych kluczy API portfela.

Planuj dostępność

Zdalne backendy zależą od usługi sieciowej. Sprawdź dostępność przed poleganiem na sygnatariuszu (isAvailable() w TypeScript, is_available() w Rust i Pythonie, IsAvailable(ctx) w Go), ponawiaj z opóźnieniem próby zakończone błędem w backendach wyłącznie podpisujących i zdefiniuj ścieżkę awaryjną na wypadek awarii. Nie ponawiaj bezrefleksyjnie prób w backendzie rozgłaszającym transakcje (Crossmint, natywny tryb auto Fordefi): zobacz Obsługa niepotwierdzonych rozgłoszeń. Keychain wymusza HTTPS dla skonfigurowanych bazowych adresów URL, odrzuca przekierowania i stosuje domyślny limit czasu żądania.

Obsługa niepotwierdzonych rozgłoszeń

Crossmint i natywny tryb auto Fordefi podpisują i rozgłaszają transakcje po stronie serwera, więc nieudane wywołanie nie oznacza, że nic nie zostało zapisane. Gdy dostawca mógł zaakceptować transakcję, Keychain zgłasza BROADCAST_UNCONFIRMED (SignerError::BroadcastUnconfirmed w Rust). Błąd zawiera identyfikator transakcji dostawcy, jeśli utworzenie transakcji zostało zaakceptowane, oraz zawsze klucz idempotentności, pod którym wysłano żądanie utworzenia, wyprowadzony z wiadomości.

  • Zanim zrobisz cokolwiek innego, uzgodnij stan z dostawcą, używając identyfikatora transakcji.
  • Ponowne wysłanie identycznej bajt po bajcie transakcji jest bezpieczne: klucz idempotentności ją deduplikuje.
  • Przebudowanie transakcji (na przykład z nowym blockhashem) tworzy nowy klucz i w efekcie nowy transfer.

Chroń sekrety i transport

  • Zdalne backendy wymuszają HTTPS dla skonfigurowanych bazowych adresów URL i odrzucają przekierowania. Jedynym wyjątkiem jest Vault, który akceptuje zwykły HTTP na interfejsie loopback, dzięki czemu lokalny vault server -dev działa.
  • Dostarczaj klucze API, tokeny i poświadczenia z menedżera sekretów lub zmiennych środowiskowych — nigdy nie koduj ich na stałe ani nie umieszczaj w kontroli wersji.
  • Keychain oczyszcza odpowiedzi błędów, aby uniknąć wycieków sekretów do logów; dbaj o to, aby Twoje własne logi były wolne od surowych poświadczeń i materiału klucza.

Monitoruj i audytuj podpisywanie

Śledź wskaźnik sukcesu podpisywania, opóźnienia i liczbę błędów oraz alertuj o skokach — zapoznaj się z metrykami w Production Readiness. Włącz logi audytu po stronie dostawcy (KMS, Vault lub powiernik) i uzgadniaj je z transakcjami przesyłanymi przez Twoją aplikację.

Wiedz, co sprawdza Keychain

  • Keychain waliduje etap podpisywania, a nie Twoją transakcję: nie ma symulacji, sprawdzania zawartości transakcji ani silnika polityk. Egzekwuj to w swojej aplikacji lub w mechanizmach polityk dostawcy.
  • Natywny tryb manualny Fordefi przepisuje transakcję (blockhash, instrukcje opłat Compute Budget) przed jej podpisaniem. Kontynuuj od transakcji, którą zwraca, a nie od tej, którą przesłano, i uruchom ją przed jakimkolwiek innym sygnatariuszem.
  • Rust zeruje pośrednie bufory kluczy; Python i Go nie potrafią tego zrobić. Przy backendzie Memory w tych językach traktuj całą pamięć procesu jako wrażliwą.
  • W przypadku Ledgera ekran urządzenia jest jedynym wiarygodnym opisem tego, co jest podpisywane. Nie włączaj funkcji unsafe-debug ani logowania TRACE dla solana_remote_wallet w środowisku produkcyjnym, ponieważ oba zapisują w logach szczegóły urządzenia i transakcji.

Pełny obraz znajdziesz w modelu bezpieczeństwa.

Is this page helpful?

Spis treści

Edytuj stronę