Какие есть методы создания децентрализованных хранилищ файлов?
Hi All!
Последнее время заинтересовался вопросом создания резервной копии своих личных файлов, которых накопилось достаточно много за это время... Сразу извиняюсь если пытаюсь "изобрести велосипед" и буду очень рад, если кто-то подскажет уже существующие решения или методики. К сожалению, беглый обзор Инет не дал мне желаемого результата, т.ч. решил обратиться с вопросом к сообществу.
Основные требования:
* Чтобы само удаленное файловое хранилище (провайдер) было представлено несколькими (минимум 2!) поставщиками услуг. Даже если это какое-то распределенное решение типа Amazon S3, то сам провайдер может по той или иной причине перестать существовать или перестать оказывать мне услуги, тогда хана всем моим "децентрализованным копиям". Поэтому, пусть лучше провайдеров будет несколько, даже если у них будут "самые базовые услуги" по хранению файлов...
* Все данные должны быть зашифрованы ключом на моей стороне и у провайдеров не должно быть физической возможности расшифровать данные или узнать их структуру (данные хранятся в виде обезличенных файлов, например).
* Сами ключи должны храниться достаточно надежно и в тоже время, я должен иметь возможность в любой момент получить к ним доступ (тут конечно есть противоречия). Желательно наличие многофакторной аутентификации.
* Оплата стоимости хранения (желательно!) была бы в криптовалюте (без участия фиатных денег!) и сама идентификация меня, как потребителя услуг, была бы минимальной, а лучше вообще анонимной.
* Получить доступ к данным (хотя бы на базовом уровне) можно было бы без установки спец.софта или спец.оборудования, например, запустив "специальное" js-приложение в любом браузере. Расширенный же доступ, можно получить после установки какого-то ПО для популярных ОС (меня интересует сейчас только Linux и может быть Android), как к обычным каталогам и файлам ФС без необходимости выкачивать весь архив предварительно из Инет.
* Желательно дополнительная защита от случайного или умышленного удаления/изменения содержимого (версионность).
* Желательно наличие "аварийного входа" (немного паранойи!), чтобы можно было предоставить "ключ/пароль под давлением" и злоумышленник получил бы доступ к "безопасной копии" хранилища.
Последний пункт, стал сейчас довольно актуален, т.к. за не предоставление пароля, запросто можно получить срок... да и "терморектальный криптоанализ" никто не отменял...
Как мне видется (фантазия!) решение, которое меня бы устроило:
* Несколько поставщиков услуг облачного хранения файлов. Желательно, чтобы у них был похожий API для доступа или возможность использовать "более абстрактный API" для доступа ко всем поставщикам.
* Все данные хранятся у поставщиков в виде набора файлов (блоков) с унифицированными именами (например, UID) и одинакового размера (какого?). Сами исходные файлы представлены "цепочками блоков". Каталоги тоже хранятся в блоках.
* Каждый файл/каталог (или блок?) зашифрован своим симметричным "сеансовым ключом". Сам "сеансовый ключ" хранится "где-то там же" (внутри блока) и зашифрован моим закрытым асинхронным ключом (похожий метод используется в pgp). Может это и лишняя заморочка, но так можно будет "делится" данными с другими....
* Создание/изменение/удаление данных реализовано так, чтобы свести к минимуму возможность повреждения данных в процессе обновления, например, взять что-то из "подходов" ZFS...
* Базовый доступ (посмотреть структуру каталогов и имена файлов, скачать какой-то отдельный файл или каталог) через web-приложение (по возможности доступно прямо из хранилища). Расширенный доступ, как к удаленной FS, например, через WebDAV, без выкачивания всех файлов.
Кое-какие решения я уже нашел, но всем, перечисленным выше требованиям, не отвечает ни одно из них... Хотелось бы узнать мнение сообщества по этому вопросу.
чтобы можно было предоставить "ключ/пароль под давлением" и злоумышленник получил бы доступ к "безопасной копии" хранилища.
Вы всерьез полагаете, что идея "безопасной копии" незнакома тем, кто будет у Вас "вежливо просить" пароль? Они тоже в курсе, что бывают двойные, тройные, N-мерные хранилища и "работать" с вами будут до тех пор, пока не получат настоящий пароль и Вы будете рады его отдать, только бы остаться живым и здоровым...
Если это будет "формальное требование", например, со стороны следствия, то факта добровольного предоставления пароля уже вполне достаточно. Даже если они будут "предполагать", что хранилище с "двойным дном", то доказательство этого, лежит уже в другой плоскости... Так можно "договориться" до того, что сам факт "надежного шифрования" чего-либо уже является, как минимум, "подозрительным".
Если же это будут "пацаны с огоньком", то шансы уже "пониже", где-то 50 на 50. С одной стороны, они про "многомерное хранилище", скорее всего, ничего не слышали. С другой, будут "стимулировать вашу память" до тех пор, пока не найдут то, что им нужно... и не важно какой пароль вы им сказали. ;(
Тут все будет зависеть от того, какого рода инфу будет нужно - ну то есть, по какой статье пойдете :) и насколко на Вас обидятся. Есть это будет например, ЦП - могут и формальным признаком "дал пароль, нашли фото котиков" обойтись.
Если будет что-то острополитическое типа дискредитации ВС РФ - то Вами займутся люди, которые и про "много мерное хранилище" в курсе и имеют под руками других людей, которые про него не в курсе, но в курсе, что есть чел, который должен расколоться...
Спасибо за рекомендацию! Про NextCloud что-то слышал, но пристально не смотрел... Если он решит хотя бы две основные проблемы (несколько мест хранения от разных провайдеров и сквозное шифрование файлов), то вполне стоит изучить...
Меня только немного смущает, что, кроме самого места для хранения, придется еще и арендовать сервер для обработки. Это конечно не show stoper, но обычно место на диске для просто сервера и место для хранения архива тарифицируются совсем по разному... Хотелось бы "быть в бюджете". ;)
Дмитрий Иванов, nextcloud это полностью автономная система. она устанавливается на сервер.
Как вариант можете разместить его где хотите, а далее прикрутить к нему уже удаленные места хранения. он это умеет
В теории, для некстклауда можно создать отдельного юзера и дать ему ограниченные права на просмотр только безопасных файлов, но прокатит ли такое на практике - информация засекречена.
Если совсем паранойную паранойю включать, то хранить всё в файле/файлах веракрипт, и бэкапить любым доступным способом. У веракрипт при создании можно включить скрытую часть, где по одному паролю открывается безопасная зона для просмотра (но её можно записать один раз, при создании, потом менять нельзя), а по другому паролю открывается полноценное харнилище.
Василий, Ну, "пароль под давлением" это все же "частичная паранойя"... Недавно, кстати, смотрел фильм "про бредбери" (точное название не помню), где как раз "потенциального подозреваемого" не привлекли к ответственности, т.к. основные доказательства у него были в телефона, а он "забыл" от него пароль... Если это не художественный вымысел, то весьма занимательный кейс. К сожалению, в "наше время" уже несколько раз читал о других случаях, когда отказ от предоставления пароля к файлам или телефону трактовался, как "признание вины" со всеми вытекающими обстоятельствами... Поэтому, если это возможно, то лучше перебдеть.
Вариант же с veracrypt тоже не подходит, т.к. шифрование он может и обеспечит, но как потом, например, с телефона "найти" нужный файл с фоткой или pdf-документом среди пару сотен файлов вида XXX-YYY-ZZZ? Возможность удобного и оперативного доступа тоже важно!
Желательно наличие "аварийного входа" (немного паранойи!), чтобы можно было предоставить "ключ/пароль под давлением" и злоумышленник получил бы доступ к "безопасной копии" хранилища.
mayton2019, Это когда "обычным образом" авторизовавшить "под принуждением" ты получаешь доступ к файловому хранилищу, то там вместо "реальных данных" доступна какая-то "реалистичная бутафория" типа фоток котиков или безобидного домашнего фотоархива, плюс несколько документов с рецептами приготовления пирогов... Ты как-бы попадаешь в "альтернативную реальность" похожую на действительность. ;)
Дмитрий Иванов, идея интересная. Я тоже об этом думал но в части стеганографии. У меня была
идея - создать стегано-хостинг где будет лежать прон и котики но на самом деле это
будет как-бы контейнер для скрытой информации.
Схема рабочая. Надежная но КПД невысокий. И идея такая что ты с котами и с сиськами
никаким спецслужбам не нужен. Типа - мелкая сошка чтоб с тобой возиться.
О боже, как всё сложно...
1) Используйте Resilio File Sync для размазывания файлов по нескольким вашим устройствам.
2) Дополнительно сделайте сервер бэкапа, КОТОРЫЙ САМ будет залезать к вашим данным и выгребать их. А залезть на него удаленно, допустим, нельзя вообще никак. Любые входящие соединения в бан.
Возможно и так, я писал выше, что возможно фантазирую, но считаю, что требования описаны достаточно четко... Только давайте не как в том анекдоте "про вопрос на американском, еврейском и русском форуме". ;)
1) Используйте Resilio File Sync для размазывания файлов по нескольким вашим устройствам.
Никогда не слышал о таком решении. Спасибо. Обязательно посмотрю.
Первое, что бросилось в глаза, это что решение закрытое и платное, а значит в любой момент к нему можно просто потерять доступ и нет никакой гарантии в том, что именно оно делает "под капотом"...
Второе, это что само решение не соответствует поставленной задаче! Основная его функция, это полная или частичная синхронизация данны[ между своими устройствами. Про шифрование, не совсем понял... ;( У меня же задача, это скорее создание "децентрализованной удаленной файловой системы". Следовательно, ни на одном из моих устройств может и не быть полной копии, хотя бы исходя из того, что она слишком большая для "локального хранения", либо просто нет в этом желания. Отсюда же вытекает, что при "больших объемах" сервисы, которые предоставляют только функцию хранения, например, Облако Mail.ru могут и не иметь возможности запускать у себя какие-то сторонние приложения (просто хранилище с api-интерфейсом для доступа и все).
2) Дополнительно сделайте сервер бэкапа, КОТОРЫЙ САМ будет залезать к вашим данным и выгребать их...
С учетом того, что нужна удаленная ФС, которую можно при необходимости подключать к клиенту, то вполне возможна такая ситуация, что метод pull (сервер затягивает изменения с клиента) просто технически невозможен... Тогда остается только метод push, когда изменения по "хранилищам" раскладывает сам клиент и только он является единственным "активным приложением"...
Дмитрий Иванов, думаю, что решение в таком виде, как вы описываете - писать и реализовывать придется самостоятельно, и это превратиться в "кровавую баню". Соответственно оптимальнее будет ужаться по требованиям и найти компромисс между требованиями и возможностями, с учетом доступных технологий и простой реализации вручную самостоятельно.
Если вы планируете все же в облака, и при чем разных провайдеров - то в любом случае внизу будет лежать общая (ваша) среда, а не их готовое решение. И уже в вашей среде будет реализовано хранилище. Как вариант - виртуализация операционки и распределенное файловое хранилище. Ну например Windows Server + DFS.
Как минимум под виндой все перечисленное сделать можно, хотя функцию шифрования ключом на вашей стороне - всё же придется доделывать вручную на клиентском ПО. Остальное же, так или иначе имеет готовые варианты решения.
думаю, что решение в таком виде, как вы описываете - писать и реализовывать придется самостоятельно, и это превратиться в "кровавую баню".
Отчасти согласен с Вами, на самом деле, смысл текущего поста был еще и в том, чтобы понять, насколько актуальна проблема для "сообщества". Потому, что "придумывать такой велосипед" в одиночку, заранее обреченная на провал задача, хотя бы по той причине, что у меня нет необходимых компетенций по всем аспектам поставленной задачи. Другое дело, если бы тема была актуальна для сообщества... Тогда был бы шанс. ;(
Однако, все не так утопично, как может показаться на первый взгляд. Я лично проводил (правда достаточно давно) следующий эксперимент:
* Взял два облачных хранилища на бесплатных тарифах (точно сейчас не помню, но вроде тогда это был Google Диск и Яндекс Диск, а объем был то ли 20 Gb, то ли 50 Gb).
* Установил на свой Linux, клиентов для этих хранилищ и получил два каталога, в которых можно было создавать/изменять/удалять файлы и они в фоновом режиме синхронизировались со своими хранилищами.
* Создал в этих каталогах набор произвольных файлов заполненных случайными данными на весь доступный объем.
* Каждый такой файл разметил и смонтировал, как LUKS том.
* Потом, с помощью LVM, эти тома сделал PV в режиме зеркала (одно отражение на данные первого хранилища, а второе на данные второго).
* В полученном дисковом пространстве нарезал себе разделов, отформатировал в ext4 и смонтировал, как обычный диск.
Потом, на такой диск/раздел можно писать и читать данные обычным образом, все преобразования и синхронизация с облаками происходит в обычном режиме....
Но это был просто эксперимент!
У него есть несколько явных недостатков относительно выдвинутых изначально требований:
* Во-первых, все данные из всех хранилищ должны в полном объемы быть размещены на локальных дисках всех моих устройств, которым нужно иметь доступ к "хранилищу".
Если это достаточно большой объем, например, 500 Gb, то для двух разных облаков, что является минимальным требованием, нужно уже 1Tb на локальном диске, а если реплик больше, то и объем пространства значительно вырастает... Хотя сейчас локальное дисковое пространство стало доступнее.
* Во-вторых, быстро взять и скачать/посмотреть один/два файла не получится, нужно развертывать целую конфигурацию и ожидать пока из хранилищ будет сделана полная копия на "локальный диск"... Частично эту проблему можно решить, например, с помощью "загрузочной флешки", но проблема с закачкой из хранилища все еще остается.
* В-третьих, подобное решение работает на полноценном Linux, но не взлетит, например, на телефоне или на чем-то подобном.
* В-четвертых, требование к реализации "отрицаемого шифрования" (ввод пароля под принуждением) остается нереализованным.
Правда есть и плюсы:
* Во-первых, используются только стандартные средства практически любого Linux-дистрибутива. Из нестандартного, только скрипты для создания/монтирования всего этого хозяйства.
* Во-вторых, мы получаем на выходе "стандартную ФС", которую можно использовать любым удобным образом, например, файлы БД на нее положить. В варианте же удаленного хранилища, перечень доступных действий значительно ограничен.
* В-третьих, возможно, если использовать для создания LUKS дисков, например, VeraCrypt, то удастся реализовать и "отрицаемое шифрование", либо просто создать многомерное хранилище...
* В-четвертых, при создании LUKS можно не формировать на дисках "служебную информацию", когда это будет просто случайный набор данных и доказать, что это зашифрованный диск будет очень сложно. Правда при этом может пострадать надежность (защита от случайных сбоев), но это компенсируется наличием копии или копий в других облаках, с которых всегда можно восстановить данные...