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в продакшене, так как оба режима записывают в лог данные об устройстве и транзакции.
Полную картину см. в модели безопасности.
Is this page helpful?