Сохранение криптографических ключей

Закрытый ключ позволяет санкционировать любое действие, разрешённое соответствующему субъекту полномочий. Никогда не передавайте закрытый ключ другим лицам. С той же тщательностью защищайте исходный материал, секреты восстановления, токены на предъявителя и экспортированные файлы ключей.

Выберите модель хранения ключей до запуска промышленной системы. Она должна соответствовать величине риска, политике контроллера учётной записи и процессу восстановления развёртывания.

Определите границы ответственного хранения

• Ведите реестр каждого субъекта полномочий, открытого ключа, алгоритма, окружения, назначения, хранителя, места хранения, резервной копии и процедуры замены.
• Используйте отдельные ключи для разработки, тестирования, производства, рутинных операций, управления, развертывания и восстановления.
• Предоставляйте людям и процессам доступ только к тем ключам, которые требуются для их роли.
• Требуйте независимого одобрения подписей для высокоценных операций или управления, если этого требует модель риска.
• Зафиксируйте, какую сеть и какие полномочия может использовать подписант. Служба подписания должна отклонять запросы, выходящие за эти рамки.

Выберите подходящий способ хранения

Для локальной разработки, контролируемых тестов или безопасной передачи в систему ответственного хранения ключ можно экспортировать в файл с ограниченными правами доступа. На поддерживаемой платформе Unix создайте новый каталог ключей с помощью kagami:

cargo run --bin kagami -- keys --algorithm ed25519 --out-dir ./client-key

Родительский каталог должен существовать. Целевой каталог должен быть новым либо уже принадлежать текущему пользователю, иметь режим 0700, не содержать символических ссылок и быть пустым. Kagami записывает public.key и private.key с режимом 0600; параметр --pop также создаёт pop.hex. Команда завершается ошибкой на платформах, где Kagami не может обеспечить правила файловой системы с доступом только для владельца.

Файл закрытого ключа представляет собой незашифрованную экспортированную копию. Не помещайте его в систему контроля версий, общие папки, журналы, тикеты, чаты и артефакты сборки. Импортируйте промышленный ключ в утверждённую систему ответственного хранения, а затем удалите экспортированную копию в соответствии с процедурой развёртывания. Не используйте ключ разработки в промышленной среде.

Для промышленной среды отдавайте предпочтение аудируемой системе ответственного хранения, например:

• аппаратный модуль безопасности или аппаратно защищённое хранилище ключей
• хранилище ключей операционной системы или мобильного устройства
• отдельный сервис подписи
• менеджер секретов, выдающий ключ только авторизованной рабочей нагрузке

Если выбранная интеграция поддерживает это свойство, храните ключевой материал в неэкспортируемом виде. Убедитесь, что система хранения поддерживает алгоритм и операцию подписи, необходимые субъекту полномочий Iroha.

Шифрование данных в состоянии покоя защищает сохранённую копию. Оно не защищает ключ после того, как неавторизованный процесс или оператор получит расшифрованные байты. Усильте защиту узла, ограничьте доступ во время выполнения и контролируйте операции подписания.

Защитите процессы подписания

• Используйте именные учётные записи операторов, надёжную аутентификацию и аудируемый доступ к системам подписания.
• Не допускайте попадания необработанных ключей в аргументы командной строки, историю оболочки, дампы окружения, списки процессов, отчёты о сбоях и журналы приложений.
• Разблокируйте подписанта только на время необходимой операции. После использования закройте сеанс или дождитесь истечения его срока.
• Покажите полномочия, сеть, инструкции, активы и сборы до одобрения.
• Требуйте явного подтверждения для привилегированных или высокоценных транзакций.
• Сохраняйте сырые частные ключи за пределами страниц браузера и процессов применения общего назначения, когда индивидуальная интеграция клиента может делегировать подписание.

Конфигурация клиента с закрытым ключом в открытом виде подходит только для локальной разработки и контролируемых тестов. Промышленная интеграция должна получать подписи через утверждённую систему ответственного хранения. Стандартный Iroha CLI читает закрытый ключ из конфигурации клиента и не предоставляет универсального адаптера внешнего подписанта. Пользовательские клиенты могут вычислить хеш полезной нагрузки транзакции и прикрепить подпись, созданную внешним подписантом.

Резервное копирование и восстановление ключей

• Создавайте резервные копии только тех ключей, для которых этого требует политика восстановления.
• Шифруйте резервные копии и храните их отдельно от активного подписанта.
• Применяйте к резервной копии те же средства контроля доступа и одобрения, что и к активному ключу.
• При необходимости разделения обязанностей храните учётные данные для восстановления у независимого хранителя.
• Проверяйте восстановление, не раскрывая ключевой материал промышленной среды.
• Регистрируйте и проверяйте каждое создание, чтение, восстановление и уничтожение резервной копии.

Не предполагайте, что мнемонический формат стороннего кошелька может представлять закрытый ключ Iroha. Используйте только формат восстановления, который поддержан и проверен выбранной системой хранения.

Заменяйте раскрытые или выведенные из эксплуатации ключи

Подготовьте замену до возникновения инцидента. Процедура должна определять:

1. кто может объявить ключ раскрытым или выведенным из эксплуатации
2. как изолируется затронутый подписант
3. как создаётся новый ключ и помещается в утверждённое хранилище
4. для учётной записи — как авторизованная замена контроллера или социальное восстановление создаёт новый канонический AccountId и переносит связанное состояние
5. для узла или пира — как авторизованная ротация или отключение консенсусного ключа в блокчейне согласуется с BLS PoP, политикой активации и периода перекрытия, локальной конфигурацией ключа, trusted_peers_pop и топологией развёртывания
6. как зависимые конфигурации, приложения и операторы переходят на новый AccountId, открытый ключ или идентификатор пира
7. как удаляются полномочия старого ключа и как архивируются или уничтожаются его копии
8. как после этого проверяются сеть и зависимые приложения

WARNING

Шифрование или новый пароль не могут снова сделать скопированный закрытый ключ безопасным. При подозрении на раскрытие прекратите использовать ключ и выполните утверждённую процедуру замены или отзыва.

См. Генерация криптографических ключей, Операционная безопасность и Принципы безопасности.