Keychain абстрагує бекенд підписання, але експлуатація підписанта у production — все одно ваша відповідальність. Ці практики застосовуються до всіх бекендів; щодо вибору конкретного — див. Вибір бекенду.
Розділяйте гарячі та холодні підписанти
Використовуйте операційний підписант із низьким балансом («гарячий») для частих автоматизованих транзакцій, і окремий підписант із високою вартістю («холодний») для переміщення коштів із treasury. Забезпечте холодний підписант MPC-кастодією або хмарним HSM і вимагайте політик затвердження перед підписанням. Оскільки інтерфейс однаковий, кожна роль може використовувати різний бекенд, не змінюючи точок виклику.
Виконуйте ротацію ключів цілеспрямовано
У Solana ключ підписання є адресою облікового запису, тому ротація ключа створює нову адресу. Плануйте ротацію як міграцію: створіть новий ключ, переназначте відповідні повноваження (або перемістіть кошти) на нову адресу, а потім виведіть старий із використання. Використовуйте окремі ключі для кожного середовища, щоб ключі devnet ніколи не перевикористовувалися у mainnet.
Надавайте доступ за принципом найменших привілеїв
Обмежуйте облікові дані кожного бекенда мінімумом, потрібним для підпису. Для AWS KMS
це kms:Sign, kms:DescribeKey та kms:GetPublicKey для конкретного ключа
(перевірка доступності використовує два останні); віддавайте перевагу ролям IAM перед статичними
облітковими даними. Застосовуйте той самий принцип до політик Vault і API-ключів
керованих гаманців.
Плануйте забезпечення доступності
Віддалені бекенди залежать від мережевого сервісу. Перевіряйте доступність, перш ніж
покладатися на підписувач (isAvailable() у TypeScript, is_available() у Rust і Python,
IsAvailable(ctx) у Go), повторюйте невдалі запити лише для підпису з експоненційною затримкою (backoff) і визначте
резервний шлях на випадок збоїв. Не повторюйте сліпо запити до бекенда, що розсилає транзакції
(Crossmint, нативний авторежим Fordefi): див.
Обробка непідтверджених розсилань. Keychain
вимагає HTTPS для налаштованих базових URL, відхиляє перенаправлення та застосовує типовий
таймаут запиту.
Обробка непідтверджених розсилань
Crossmint і нативний авторежим Fordefi підписують і розсилають транзакції на стороні сервера, тому
невдалий виклик не означає, що нічого не було відправлено. Якщо провайдер міг прийняти
транзакцію, Keychain повідомляє BROADCAST_UNCONFIRMED
(SignerError::BroadcastUnconfirmed у Rust). Помилка містить ідентифікатор транзакції
провайдера, якщо створення було прийнято, і завжди містить ключ ідемпотентності,
з яким було надіслано запит на створення; він виводиться з повідомлення.
- Спершу звірте стан із провайдером за ідентифікатором транзакції, перш ніж робити що-небудь інше.
- Повторне надсилання байт-у-байт ідентичної транзакції безпечне: ключ ідемпотентності усуває дублювання.
- Перебудова транзакції (наприклад, з новим blockhash) створює новий ключ і, отже, новий переказ.
Захищайте секрети та транспорт
- Віддалені бекенди вимагають HTTPS для налаштованих базових URL і відхиляють перенаправлення.
Єдиний виняток — Vault, який приймає звичайний HTTP на loopback, щоб локальний
vault server -devпрацював. - Надавайте ключі API, токени та облікові дані через менеджер секретів або змінні середовища — ніколи не зашивайте їх у код і не зберігайте у системі контролю версій.
- Keychain очищує відповіді з помилками, щоб уникнути витоку секретів у журнали; стежте, щоб ваші власні журнали не містили необроблених облікових даних і ключового матеріалу.
Моніторинг та аудит підписання
Відстежуйте показник успішності підписання, затримку та кількість збоїв, і налаштуйте сповіщення про аномальні сплески — дивіться метрики у Production Readiness. Увімкніть журнали аудиту на стороні провайдера (KMS, Vault або кастодіан) і звіряйте їх із транзакціями, що надсилає ваш застосунок.
Що перевіряє Keychain
- Keychain перевіряє лише етап підписання, а не вашу транзакцію: немає ні симуляції, ні перевірки вмісту транзакції, ні рушія політик. Забезпечуйте це у своєму застосунку або засобами керування політиками провайдера.
- Нативний ручний режим Fordefi переписує транзакцію (blockhash, інструкції комісії Compute Budget) перед підписанням. Продовжуйте роботу з транзакцією, яку він повертає, а не з тією, яку ви надіслали, і виконуйте її перед будь-яким іншим підписувачем.
- Rust обнуляє проміжні буфери ключів; Python і Go — ні. З бекендом Memory цими мовами вважайте чутливою всю пам’ять процесу.
- У випадку Ledger екран пристрою — єдиний надійний опис того, що
підписується. Не вмикайте функцію
unsafe-debugабо логуванняTRACEдляsolana_remote_walletу продакшені, оскільки обидва записують у лог дані про пристрій і транзакцію.
Повну картину дивіться в моделі безпеки.
Is this page helpful?