Центр безопасности

Защитите кошельки, ключи, доступ к серверу и идентичность Service Node.

Эксплуатация Service Node — это не только стейкинг и запуск сервера. Операторам также нужно защищать данные восстановления кошелька, приватные ключи, файлы доступа, записи о узлах и резервные материалы, чтобы средства, инфраструктура и идентичность узла оставались восстанавливаемыми и безопасными.

Сид-фразаофлайн-резервная копия
Приватные ключиникогда не передавать
Доступ к серверузащищать файлы .pem
Резервные копииотдельные безопасные места

Критически важные материалы безопасности

Защищайте материалы, которые могут восстановить кошельки, идентифицировать Service Nodes или дать доступ к серверам.

01

Резервная копия сид-фразы кошелька

Сид-фраза кошелька — один из самых важных инструментов восстановления.

  • Не передавайте сид-фразу никому
  • Не отправляйте сид-фразу через мессенджеры или email
  • Не храните сид-фразу в открытом виде на компьютере, подключённом к интернету
  • Не делайте скриншоты сид-фразы
  • Не загружайте сид-фразу в облачное хранилище
  • Не вставляйте сид-фразу на неизвестные сайты или в неизвестные инструменты
  • Храните как минимум одну офлайн-резервную копию в безопасном месте

Если сид-фраза кошелька потеряна, кошелёк может быть невосстановим. Если сид-фраза утекла, средства кошелька могут оказаться под угрозой.

02

Резервная копия пароля кошелька

Пароль кошелька также важен.

  • Используйте надёжный пароль
  • Не используйте простые пароли
  • Не храните пароль кошелька вместе с сид-фразой
  • Не отправляйте пароль кошелька никому
  • При необходимости храните безопасную офлайн-резервную копию

Хорошая практика — хранить сид-фразу кошелька и пароль кошелька отдельно.

03

Резервная копия приватного ключа Service Node

Приватный ключ Service Node используется для идентификации Service Node. Файл ключа обычно находится по пути /home/ubuntu/.bitjudecoin/key_ed25519.

  • Не передавайте приватный ключ Service Node
  • Не отправляйте его через мессенджеры или email
  • Не публикуйте его в публичных группах
  • Не загружайте его в публичное облачное хранилище
  • Храните как минимум две офлайн-резервные копии
  • Храните резервные копии в разных безопасных местах

Если сервер потерян, повреждён, переустановлен или перенесён, приватный ключ Service Node может понадобиться для восстановления исходной идентичности Service Node.

04

Резервная копия файла доступа .pem к серверу

Файл .pem используется для доступа к серверу. Если файл .pem потерян, обычный SSH-доступ к серверу может быть утрачен.

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

Файл .pem следует рассматривать как чувствительный файл доступа.

Структура резервного копирования и восстановления

Используйте раздельные резервные копии и приватные записи, чтобы восстановление кошелька и Service Node не зависело от одного устройства.

05

Резервная копия информации о сервере

Оператор Service Node должен хранить базовую приватную запись с информацией о сервере.

  • Регион сервера
  • Провайдер сервера
  • Имя инстанса
  • Публичный IP-адрес
  • Версия CLI
  • Публичный ключ Service Node
  • Кошелёк, использованный для регистрации
  • Дата регистрации
  • Текущий статус узла
  • Заметки об обновлениях или перезапусках

Не публикуйте эту полную запись публично. Она полезна для приватного управления и восстановления.

07

Аппаратно зашифрованный USB-накопитель

Аппаратно зашифрованный USB-накопитель может быть полезен для хранения чувствительных файлов.

  • Резервная копия приватного ключа Service Node
  • Резервная копия файла .pem
  • Файл записи узла
  • Заметки по восстановлению кошелька
  • Важные операционные документы
  • Используйте как минимум два зашифрованных USB-накопителя
  • Храните их в разных безопасных местах
  • Не храните обе резервные копии в одной сумке или на одном компьютере
  • Проверьте USB-накопитель, прежде чем полагаться на него
  • Храните пароль безопасно и отдельно от USB-накопителя

Зашифрованные резервные копии полезны только тогда, когда защищены и устройство с копией, и пароль.

Никогда не передавайте эти материалы

Материалы восстановления, приватные ключи, файлы доступа и чувствительные скриншоты нельзя отправлять через публичные или приватные каналы.

08

Что нельзя передавать никогда

Никогда не передавайте чувствительную информацию доступа к кошельку, серверу или Service Node.

  • Сид-фраза кошелька
  • Приватный ключ кошелька
  • Пароль кошелька
  • Ключ просмотра
  • Ключ расходования
  • Файлы кошелька
  • Приватный ключ Service Node
  • Файл .pem
  • Учётные данные входа на сервер
  • Коды подтверждения
  • Скриншоты backend с чувствительной информацией

Если кто-то просит эти данные, воспринимайте это как серьёзный риск безопасности.

Безопасность коммуникации и сообщества

Снижайте ненужное раскрытие данных в публичных каналах, email, скриншотах и процессах участия.

09

Безопасность email и защита от фишинга

Осторожно относитесь к письмам и сообщениям, которые якобы представляют проект, сообщество или техническую команду.

  • Проверьте, использует ли отправитель доверенный домен
  • Проверьте, запрашивает ли сообщение приватные ключи или сид-фразы
  • Проверьте, есть ли подозрительная ссылка
  • Проверьте, пытается ли сообщение создать ощущение срочности
  • Перед ответом подтвердите личность через доверенные каналы проекта

Никогда не передавайте приватные ключи, сид-фразы, файлы кошелька или файлы доступа к серверу через email.

10

Безопасность GitHub и сообщества

При участии в GitHub Discussions или документации избегайте раскрытия приватной операционной информации.

  • Не публикуйте сид-фразы кошельков
  • Не публикуйте приватные ключи Service Node
  • Не публикуйте файлы .pem
  • Не публикуйте данные входа на сервер
  • Не публикуйте полные скриншоты backend
  • Удаляйте личную информацию со скриншотов перед публикацией
  • Избегайте публичного раскрытия крупных балансов или деталей владения узлами

Вклад в сообщество должен быть полезным, но он не должен раскрывать приватную операционную информацию.

Готовность к миграции и восстановлению

Проверьте материалы восстановления перед сменой серверов, перемещением средств или восстановлением идентичности Service Node.

11

Перед миграцией или восстановлением сервера

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

  • Резервная копия приватного ключа Service Node
  • Файл .pem или доступ к новому серверу
  • Информация о версии CLI
  • Публичный ключ Service Node
  • Записи узла
  • доступ к кошельку
  • Безопасная рабочая среда

Не начинайте восстановление, если не уверены, что приватный ключ Service Node правильный.

Базовый контрольный список резервного копирования

Используйте этот итоговый контрольный список перед запуском или обслуживанием Service Node.

12

Базовый контрольный список резервного копирования

Перед запуском или обслуживанием Service Node убедитесь, что ключевые материалы восстановления имеют резервные копии.

  • Сид-фраза кошелька
  • Пароль кошелька
  • Файлы кошелька при необходимости
  • Приватный ключ Service Node
  • Файл .pem
  • Заметки о регионе сервера и инстансе
  • Публичный ключ Service Node
  • Информация о версии CLI
  • Заметки по эксплуатации узла
  • Одна основная зашифрованная резервная копия
  • Одна офлайн-зашифрованная резервная копия
  • Одна отдельная бумажная копия критически важной информации восстановления

Безопасность Service Node так же важна, как и его эксплуатация.

Заключение

Оператор узла должен знать не только, как запускать, перезапускать или восстанавливать узел, но и как защищать ключи и файлы, стоящие за ним. Более безопасные привычки резервного копирования снижают предотвратимые риски и помогают защищать долгосрочную работу Service Node.