All streams
Search
Write a publication
Pull to refresh

Comments 15

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

А по сути. У меня похожее решения для резевного копирования. На Google Drive, средставим rclone, копируются файлы из одной директории первой необходимости.

Всего у меня существует 4 каталога информации которые реплицируются средствами "synсthing" между 3 устройствами. Сейчас 4-ое устройство на походе.

Ну и вишенка на торте - резервное копирование всех 4 каталогов каждый день + резервное копирование системы раз в неделю по сети на сервер "rest-server" для "restic". Диск с данными, где хранятся резервные копии, дублируется еще на двух дисках, потому как помимо резервных копий там содержится еще много ценных данных.

По поводу шифрования. Я не понял зачем писать свои bash скрипты для шифрования одиночных файлов, когда можно использовать готовые крипто контейнеры "LUKS/dm-crypt" для чувствительных данных. Примонтировал, поработал с файлами, отмонтировал. У меня прекрасно работает данная схема.

Контейнер - большой файл. Делать мелкие неудобно, возни много.

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

Контейнер может быть любого удобного размера.

А писать скрипт, шифровать единичные файлы и потом помнить где что лежит, не лень))

Ну вот смотрите, ситуация: вам надо сохранить файл "Секретный рецепт сырников.doc", 123 кбайта.

У вас три варианта:
1 - encrypt "Секретный рецепт сырников.doc" - пароль для рецептов - upload 123 кб
2 - открыть криптоконтейнер Bigfile, внести рецепт туда, закрыть - upload 2Гб
3 - открыть криптоконтейнер для рецептов на 200 Мб, увидеть что в нем не осталось места, создать второй для рецептов еще на 200 Мб, - upload 200 Мб. И еще отдельно придумать каталог, что в каком контейнере лежит, чтобы не искать по разным.

Как-то так.

Ваши сценарии очень синтетические. И смахивают на придумывание очередного велосипеда.

Для того что бы не искать файлы, должен быть подход к хранению файлов и структура хранения файлов.

У меня в каталоге "первой" необходимости хранится криптоконтейнер "KeePassX". Там хранятся все пароли, и при необходимости, можно туда поместить "секретный рецепт сырников" весом 123Кб. Там есть хорошая структура каталогов, которая позволяет не путаться. Файл весит сейчас 1 мегабайт с учетом зашифрованных вложений. Ну даже если он вырастет до 10Мб в моменте, или даже до 100, я не вижу в этом ничего страшного. Сейчас не та скорость интернета, что бы экономить на спичках. Даже если потенциально оперировать размерами в гигабайты, это спокойно можно пережить. Rclone спокойно загрузит все в фоновом режиме. Это "горячее" хранение информации.

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

Подчеркну, ничего крупного шифрованного в облаке не хранится. Но даже если вы хотите идти по пути одиночных шифрованных файлов, то можно сделать зашифрованный архив, который и разместить в облаке. В Линукс этом можо делать хоть в CLI, хоть в GUI. И не надо изобретать велосипеды.

Linux/Unix - это и есть куча велосипедов, где одни и те же задачи можно решить разными инструментами и разными способами )

В Linux также есть шифрованные ФС - encfs и cryfs. У второй даже в описании прямым текстом заявлена работа с облаками.

CryFS encrypts your files, so you can safely store them anywhere. It works well together with cloud services like Dropbox, iCloud, OneDrive and others. Simple.

Вместо того, чтобы считать и прикапывать хэш от дешифрованного контента, лучше считать и прикапывать hmac

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

Никак. Это персональный архив, который не предполагает периодической смены паролей и перешифрования. Более того, никто не обещает что пароли на все файлы одинаковые )

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

А как еще вы предлагаете менять ключ? Мне правда интересно. Можно перешифровать симметричный ключ, спрятанный в файле - но это всё равно обновление файлов в облаке.

И в случае криптоконтейнера с возможностью замены ключа - тоже.

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

И зачем? rclone умеет сам шифровать файлы. Просто создаём еще одну запись типа crypt, а в remote ссылаемся на облако.

Затем, чтобы они и локально были шифрованные, независимо от rclone.
Он - транспорт, с дополнительными возможностями, он передает некие данные - вот и пусть передает. Завтра вместо Google Drive будет что-то другое, и другой транспорт окажется лучше - это не должно влиять на данные.

А готовить данные - локальная задача. Их лучше не объединять.

Уже был опыт с какой-то вот такой программой (не помню, давно было), позволяла делать шифрованные бекапы в собственное облако Убунты.
Сначала попал на какой-то баг в программе (иногда не расшифровывались обратно), а потом и облако это отключили.

Поддержу, crypt позволяет прозрачно для пользователя шифровать файлы при выгрузке в облако и дешифровать в исходный вид при скачивании. Удобная вещь!

File content encryption is performed using NaCl SecretBox, based on XSalsa20 cipher and Poly1305 for integrity. Names (file- and directory names) are also encrypted by default, but this has some implications and is therefore possible to be turned off.

Итак, установим rclone:

apt install rclone

Как вариант, раз утилита rclone написана на Go, а значит не требует установки, кроссплатформенная, достаточно скачать свежую сборку и положить один бинарь в .local/bin

всё, что хранится не в вашем собственном облачном хранилище - в принципе доступно кому-нибудь не вам

Именно поэтому не храню там ничего чувствительного\критического.

К тому же бывает (в последнее время), что может и не быть доступа к GoogleDrive (сервера "деградируют", к примеру).

Sign up to leave a comment.

Articles