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), повторюйте з відкладенням спроби після збоїв, що стосуються лише підписання, і визначте
резервний шлях на випадок відмов. Не повторюйте наосліп запити до бекенду, який виконує трансляцію
(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у production, оскільки обидва записують дані про пристрій і транзакцію.
Повну картину див. у моделі безпеки.
Is this page helpful?