Keychain абстрагирует бэкенд подписи, однако эксплуатация сигнера в production остаётся вашей ответственностью. Эти практики применимы ко всем бэкендам; см. Выбор бэкенда для подбора подходящего.
Разделяйте горячие и холодные сигнеры
Используйте операционный («горячий») сигнер с низким балансом для частых автоматизированных транзакций и отдельный высоконагруженный («холодный») сигнер для управления казначейством. Обеспечьте холодный сигнер 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?