На bitcoincashresearch.org мы стремимся обеспечить определённый уровень децентрализации форума, включая возможность того, что любой, кто считает это необходимым, сможет развернуть экземпляр форума на другом домене.
Для этого мы должны периодически публиковать резервные копии базы данных. Однако мы сталкиваемся с проблемой раскрытия конфиденциальной информации пользователей, такой как электронные адреса, IP-адреса и т. д.
Мы могли бы вручную удалять эту конфиденциальную информацию из резервных копий базы данных, но это не кажется самым умным или аккуратным решением, особенно при периодическом создании резервных копий.
Вам известно о каких-либо решениях, которые могли бы помочь в этом вопросе? Или о примерах аналогичных проектов, которые уже были реализованы?
Вы хотите удалить IP-адреса и адреса электронной почты? Без адресов электронной почты у пользователей не будет способа восстановить доступ к своим аккаунтам (если они использовали пароль, они смогут войти, но не смогут вернуть свой адрес электронной почты, так как не будет возможности проверить это изменение).
Я не вижу способа создать полезную резервную копию, в которой не было бы хотя бы адресов электронной почты.
Я согласен, что это может показаться странной пограничной ситуацией. Но сама идея не кажется такой уж нелепой, поскольку она направлена на предотвращение централизации форумов.
Понимаю, что для некоторых форумов это может быть не очень важно, но для других — критично.
Также согласен, что удаление пользователей и паролей (наряду с другой информацией) из резервной копии помешает этим же пользователям войти в новый экземпляр.
Вот почему я сказал, что это не кажется самым разумным решением.
Мне, вероятно, стоит переформулировать свой вопрос.
Существует ли известный способ или рекомендуемая процедура публикации резервных копий базы данных, чтобы любой мог восстановить экземпляр форума, не раскрывая при этом конфиденциальную информацию пользователей?
Я хотел бы добавить немного контекста. Существует очень специфическая потребность / вариант использования.
Существует операционный дискурс, содержащий важную информацию, которая со временем станет ещё более значимой. Из-за природы экосистемы, использующей его, мы поняли, что крайне важно избегать единых точек отказа.
При экспорте сегодня, если исключить данные аутентификации, теоретически возможно опубликовать весь контент сайта публично. Однако, как указал @pfaffman, это приводит к необратимому разрыву: пользователи больше не могут аутентифицироваться, и экспортированный сайт становится доступным только для чтения.
Поэтому, на мой взгляд, то, что нужно Леандро — это функция в Discourse, позволяющая пользователям входить в систему с помощью криптографических вызовов вместо традиционных схем «учётная запись/пароль». Тогда при экспорте включать только эту часть учётной записи — без остальной информации, такой как электронная почта, хеши паролей и т. д. В альтернативной копии сайта пользователи, воспользовавшиеся этой функцией, смогут войти и пройти процедуру восстановления учётной записи через электронную почту или стандартные методы.
При такой полной публикации крайне важно не включать никакую традиционную информацию для аутентификации учётных записей, такую как адреса электронной почты и хеши паролей и т. д. Это настолько важно, что для любой версии Discourse с этой функцией конфиденциальная информация должна храниться отдельно от остальных данных сайта, чтобы исключить случайный экспорт.
Надеюсь, это добавит немного контекста для размышлений.
Кроме того, эти изменения, очевидно, очень нетривиальны. Было бы полезно получить обратную связь, замечания и альтернативные предложения. Возможно, в нашей экосистеме удастся объединить ресурсы для создания форка, реализующего эту идею.
Кстати, обычным пользователям не нужно подтверждать изменения адреса электронной почты, если они вошли в систему. Поэтому дамп без адресов электронной почты подойдёт для всех пользователей, которые должны входить с использованием любых учётных данных из базы данных (пароль — самый простой вариант).
Плагин, который либо удаляет адреса электронной почты, либо шифрует их (я думаю, что знаю, как это сделать относительно легко), мог бы решить проблему.
В одном из плагинов я зашифровал некоторые поля следующим образом:
Думаю, что возможно аналогичным образом переопределить модель UserEmail и зашифровать адреса электронной почты. В модели UserEmail не так много кода, и, похоже, она меняется очень редко, поэтому такое изменение может быть не слишком рискованным. Хотя, возможно, оно вообще не сработает.
Фильтрация IP-адресов может быть немного сложнее, так как, как мне кажется, будет трудно переопределить модель пользователя. Для этого вы можете создать плагин, который тем или иным способом удаляет эти IP-адреса.
@Falco и @pfaffman, большое спасибо за вашу обратную связь и советы.
Мы изучим WebAuthn, чтобы понять, можем ли мы пойти по этому пути, то же самое касается вашего плагина @pfaffman.
Я вернусь к вам через пару дней с комментариями, вопросами или выводами.
Ещё одна перспективная возможность — использование усиленного PAKE (протокола обмена ключами с аутентификацией по паролю), благодаря которому пароль становится практически невосстановимым из базы данных и никогда не передаётся по сети.
К сожалению, все такие решения пока находятся в области экспериментальной криптографии и ещё не готовы к простому внедрению. Синхронизация в iOS iCloud использует PAKE.
Если вы хотите сохранить вход по электронной почте и паролю, но так, чтобы любой мог войти в учётную запись любого пользователя в резервной копии базы данных, вы можете сгенерировать для каждого пользователя адрес электронной почты на основе его имени пользователя, например <username>@email.invalid.
Что касается паролей и входов: предположим, что Discourse использует зашифрованные пароли с солью (я не проверял, но предполагаю, что так), вы можете установить пароль, например 123456 (в вашей рабочей базе данных), затем посмотреть в базе данных полученный зашифрованный пароль и соль (после этого смените пароль обратно или выполните это на тестовой учётной записи). Затем выполните команду в новой (клонированной) базе данных, чтобы установить для каждого пользователя зашифрованный пароль и соль на те значения, которые вы увидели ранее (у каждого пользователя будет одинаковый зашифрованный пароль и соль, и, следовательно, одинаковый пароль — тот, который вы использовали ранее). Таким образом, для пользователя foo вы сможете войти с адресом электронной почты foo@email.invalid и паролем 123456.
Помимо этого, возможно, стоит удалить личные сообщения (если они не нужны), так как в них может содержаться конфиденциальная информация.
И наконец, рекомендуется проверить поля, которые могут содержать конфиденциальные данные, например настройки (администраторов).