Comments 99
Я просто храню в дропбоксе зашифрованный трукриптом контейнер — вариант для ленивых =)
Получается, сделали у себя на машине контейнер n-ного размера, используете его через truecrypt, и сливаете его на dropbox через синхронизацию?
Вариант, конечно, возможный, но какой-то странный: маленький криптованный диск не особо полезен, а большой (пусть даже 1 Гб) — можно замучиться синхронизировать.
Как ни крути, любой изменение содержимое контейнера потребует передачи на удаленный хост изрядного куска этого контейнера, если не его всего. Да и для синхронизации контейнер надо бы размонтировать, тоже не всегда удобно…
Вариант, конечно, возможный, но какой-то странный: маленький криптованный диск не особо полезен, а большой (пусть даже 1 Гб) — можно замучиться синхронизировать.
Как ни крути, любой изменение содержимое контейнера потребует передачи на удаленный хост изрядного куска этого контейнера, если не его всего. Да и для синхронизации контейнер надо бы размонтировать, тоже не всегда удобно…
Непосредственная работа с контейнером вне папки дроп бокса, синхронизация ночью по расписанию. Да — так не прокатит следующий вариант: скопировал с компа, сразу получил на ноутбуке, но для меня это не критично.
Для меня этот подход (работа с точностью до файла) не то чтобы критичен, но как-то глупо кажется гонять туда-сюда контейнеры, когда вариант «rsync в туннеле» делает то же, только быстрее (поскольку синхронизируем не все, а только измененное) и (в случае, если на арендованном сервере сделано шифрование) вполне безопасно.
Но если контейнер невелик — ваш вариант вполне удобен, согласен.
Но если контейнер невелик — ваш вариант вполне удобен, согласен.
А нельзя гонять контейнер не целиком, синхронизировать только то, в нём что изменилось?
Существующие решения синхронизации с удаленным хранилищем, афаик, ориентированы либо на работу с файлами либо на текстовые диффы. С бинарниками всё плохо. А уж с криптоконтейнерами, где изменение одного бита должно приводить к неузнаваемым изменениям минимум одного блока и, как следствие, добавление одного байта к изменению всего файла ещё хуже. Решить проблему, наверное можно изменением форматов криптоконтейнеров, но с потерей криптостойкости.
Можно сделать так: сначала залить полностью контейнер,
а, потом, периодически заливать инкрементные копии.
Это позволит синхронизировать до нужного уровня (периода).
а, потом, периодически заливать инкрементные копии.
Это позволит синхронизировать до нужного уровня (периода).
О том разговор и идет: меняем в содержимом кроптоконтейнера совсем немного — надо перегонять по проводам минимум один блок контейнера. rsync в смысле инкрементных копий хорош, другой вопрос, что при обычной работе с дисковым томом изменений (даже если ничего с файлами не делать, только читать их) набегает немало (обновляются данные каталогов; может, «вдруг», поработать антивирус или дефрагментатор), и передавать нам придется довольно много.
А самое главное — смысл передавать критоконтейнер, когда можно в точке назначения создать криптованный том, и на него по rsync-у тому же передать изменения в самих файлах?
А самое главное — смысл передавать критоконтейнер, когда можно в точке назначения создать криптованный том, и на него по rsync-у тому же передать изменения в самих файлах?
Один блок контейнера — это как раз немного. С криптографической точки зрения — 8 или 16 байт. С файлосистемной точки зрения — минимум 512.
А вот передавать изменения (если только они не эквивалентны изменению криптоконтейнера) нельзя, поскольку мы не доверяем серверу.
А вот передавать изменения (если только они не эквивалентны изменению криптоконтейнера) нельзя, поскольку мы не доверяем серверу.
Тут появляется ещё одна неприятная вещь — злоумышленный сервер может «откатить» изменения в криптоконтейнере, поэтому нужно на клиенте хранить номер версии, а на криптоконтейнере придумать способ «связывания» изменений с номером версии.
Прошу прощения, с этого момента можно поподробнее?
Представьте, Вы — владелец криптоконтейнера и по совместительству банк, а некто Петя — владелец сервера. Вы к нему каждый вечер приходите с флешкой и с неё заливаете его сервер свой криптоконтейнер. В числе прочего в этом файле записано, сколько денег вам должен некто Ваня, по совместительству Петин приятель.
В одну из ночей Петя делает бекап вашего криптоконтейнера, на следующий день Ваня одалживает у Вас ещё денег, о чем вы делаете запись в файл, а вечером заливаете его на сервер, во вторую ночь Петя подменяет свежий криптоконтейнер на однодневной давности, а ко всему прочему по странному стечению обстоятельств Вы не можете обнаружить следующим утром флешку в кармане штанов, но это не беда, вы скачиваете бекап с Петиного сервера. В итоге Вы забыли про Ванин вчерашний долг.
В одну из ночей Петя делает бекап вашего криптоконтейнера, на следующий день Ваня одалживает у Вас ещё денег, о чем вы делаете запись в файл, а вечером заливаете его на сервер, во вторую ночь Петя подменяет свежий криптоконтейнер на однодневной давности, а ко всему прочему по странному стечению обстоятельств Вы не можете обнаружить следующим утром флешку в кармане штанов, но это не беда, вы скачиваете бекап с Петиного сервера. В итоге Вы забыли про Ванин вчерашний долг.
Идею понял, но не сильно сложно закручено даже для тов. Дж. Бонда?
Если же серьезно, я не планирую таскать туда-сюда контейнер, у меня криптотом на сервере, в него и сохраняется все. И да, там есть версии — версии файлов. Но уж коли у нас такой умный Ваня — может, ему и не придется что-то там подменять, а просто удалит он контейнер (а может — диск/сервер/ДЦ — зависит от размера долга) с лица Земли?
Сам себе же посоветую данные хранить в разных местах и сравнивать перед использованием. Особенно если там записи о деньгах.
Если же серьезно, я не планирую таскать туда-сюда контейнер, у меня криптотом на сервере, в него и сохраняется все. И да, там есть версии — версии файлов. Но уж коли у нас такой умный Ваня — может, ему и не придется что-то там подменять, а просто удалит он контейнер (а может — диск/сервер/ДЦ — зависит от размера долга) с лица Земли?
Сам себе же посоветую данные хранить в разных местах и сравнивать перед использованием. Особенно если там записи о деньгах.
он и так гоняется не целиком.
контейнер разбит на блоки, при изменении нескольких файлов в контейнере он не переписывается весь, а меняется только небольшая часть его.
дропбокс тоже бъет файлы на части, и синхронизирует лишь измененные
контейнер разбит на блоки, при изменении нескольких файлов в контейнере он не переписывается весь, а меняется только небольшая часть его.
дропбокс тоже бъет файлы на части, и синхронизирует лишь измененные
> синхронизация ночью по расписанию.
Тогда вам дропбокс вообще не нужен. Заведите личную файлопомойку (хоть из старого ноутбука) и синхронизируйте туда используя unison.
Тогда вам дропбокс вообще не нужен. Заведите личную файлопомойку (хоть из старого ноутбука) и синхронизируйте туда используя unison.
Для линуксоводов есть eCryptfs — тоже шифрованный контейнер, но бэкендом является дерево файлов и каталогов, соответствующее 1:1 оригинальному, но с зашифрованными именами и содержимым.
Прекратите нести чушь и примите православную веру. А сервак поставьте дома.
Хинт: хостеры тоже легко могут посмотреть ваши данные. При использовании виртуализации KVM спасает шифрование. При использовании OpenVZ/Xen — нет.
Хинт: хостеры тоже легко могут посмотреть ваши данные. При использовании виртуализации KVM спасает шифрование. При использовании OpenVZ/Xen — нет.
Если на удаленной машине, пусть даже виртуальной, данные зашифрованы, то хостер, в отличии от dropbox-а, доступа к ним не получит (я про вот это). Скажем так, просто так не получит: перехватить трафик — это уж от туннеля зависит, а перехватывать данные в памяти — тут, простите, нужно что-то сильно большее, чем простое любопытство провайдера, хотя это, конечно, возможно. Но никто не мешает арендовать физический сервер (в приличном западном ДЦ), другой вопрос — бюджет.
А ставить дома сервер, чтобы поддерживать даже и такие красивые инициативы — вот уж увольте. Причины: сервер требует места, гудит, тратит энергию. Он стоит денег, наконец, при этом всякие приятности, вроде зеркала, оплачиваются сразу — а мне проще платить пару сотен руб. помесячно, чем 15-20 тыс. руб. разово. Не говоря уже о том, что с домом или с сервером мало ли что может произойти в физическом плане; в случае с ДЦ и виртуалкой я как-то больше в сохранность верю, особенно если виртуалок несколько.
Потом — канал связи. Он у меня домашний, явно без гарантии со стороны провайдера, да и упасть может с больше вероятностью, чем линки того же scalaxy.
Про новую «серебрянную пулю», которую Вы называете «православной верой», я и не говорю. Честно скажу — просто не верю в долгую жизнь ее. Рад был бы ошибиться, но пока данные свои ей доверить — не готов.
А ставить дома сервер, чтобы поддерживать даже и такие красивые инициативы — вот уж увольте. Причины: сервер требует места, гудит, тратит энергию. Он стоит денег, наконец, при этом всякие приятности, вроде зеркала, оплачиваются сразу — а мне проще платить пару сотен руб. помесячно, чем 15-20 тыс. руб. разово. Не говоря уже о том, что с домом или с сервером мало ли что может произойти в физическом плане; в случае с ДЦ и виртуалкой я как-то больше в сохранность верю, особенно если виртуалок несколько.
Потом — канал связи. Он у меня домашний, явно без гарантии со стороны провайдера, да и упасть может с больше вероятностью, чем линки того же scalaxy.
Про новую «серебрянную пулю», которую Вы называете «православной верой», я и не говорю. Честно скажу — просто не верю в долгую жизнь ее. Рад был бы ошибиться, но пока данные свои ей доверить — не готов.
> Если на удаленной машине, пусть даже виртуальной,
Если вы шифруете файлы сами — то да. Но это неудобно по разным причинам.
> Причины: сервер требует места, гудит, тратит энергию.
Вы когда видели последний раз среднестатистический домашний сервер вообще?
> 15-20 тыс.
Бросьте, под файлопомойку хватит 2-4 тысяч без hdd.
> Потом — канал связи
Чтобы сервер заменил dropbox — 100% аптайма канала ему не нужно, поверьте. Если для вас критично актуальное состояние данных на определенный момент — делайте rsync руками, поверьте моему опыту работы со всеми этими облачными стораджами.
> данные свои ей доверить — не готов.
А в том то вся и фича, что данные вы никому не доверяете. Только своим машинкам. Хотите — арендуйте виртуалку и ставьте там клиент. Хотите — ставьте дома сервер и синкайте туда. Хотите — просто обеспечьте одинаковые данные на десктопе и лаптопе. Feel free to do everything. На виртуалку бэкапьте рабочие проекты, либу с паролями — только между вашими личными машинами, нужные файлы на одной работе — только на рабочий комп в той компании и на свой лаптоп.
Ну упадут у них сервера — ну обидно. Ну перестанет клиент работать — тоже обидно. Данные никуда не денутся в таких случаях.
Если вы шифруете файлы сами — то да. Но это неудобно по разным причинам.
> Причины: сервер требует места, гудит, тратит энергию.
Вы когда видели последний раз среднестатистический домашний сервер вообще?
> 15-20 тыс.
Бросьте, под файлопомойку хватит 2-4 тысяч без hdd.
> Потом — канал связи
Чтобы сервер заменил dropbox — 100% аптайма канала ему не нужно, поверьте. Если для вас критично актуальное состояние данных на определенный момент — делайте rsync руками, поверьте моему опыту работы со всеми этими облачными стораджами.
> данные свои ей доверить — не готов.
А в том то вся и фича, что данные вы никому не доверяете. Только своим машинкам. Хотите — арендуйте виртуалку и ставьте там клиент. Хотите — ставьте дома сервер и синкайте туда. Хотите — просто обеспечьте одинаковые данные на десктопе и лаптопе. Feel free to do everything. На виртуалку бэкапьте рабочие проекты, либу с паролями — только между вашими личными машинами, нужные файлы на одной работе — только на рабочий комп в той компании и на свой лаптоп.
Ну упадут у них сервера — ну обидно. Ну перестанет клиент работать — тоже обидно. Данные никуда не денутся в таких случаях.
Про шифрование я, в общем-то, и писал: что оно настраивается по вкусу (и рукам) владельца. Удобно или нет, не знаю, я, лично «за» него.
Среднестатические — вижу довольно часто, это машинки, которые жаль выкинуть, которые гудят и не особо шустро работают. Хорошие тоже вижу, но покупать этакое бесшумное решение, чтобы было, чем озаботить себя еще и дома — знаете, я бы предпочел, чтобы в мое отсутствие дома было поменьше работающей техники.
А вообще, наверное, идея у AeroFS и хороша, но альфа-статус и вот эта самая моя неуверенность в том, что если взяться за хранение всем миром, то файлы будут сохраннее — эти две причины (ну, пусть первая и уйдет, но пословицу про «у семи нянек дитя без глаза» все мы помним) и не дают мне поверить в нее. Тем более назвать «православной».
Среднестатические — вижу довольно часто, это машинки, которые жаль выкинуть, которые гудят и не особо шустро работают. Хорошие тоже вижу, но покупать этакое бесшумное решение, чтобы было, чем озаботить себя еще и дома — знаете, я бы предпочел, чтобы в мое отсутствие дома было поменьше работающей техники.
А вообще, наверное, идея у AeroFS и хороша, но альфа-статус и вот эта самая моя неуверенность в том, что если взяться за хранение всем миром, то файлы будут сохраннее — эти две причины (ну, пусть первая и уйдет, но пословицу про «у семи нянек дитя без глаза» все мы помним) и не дают мне поверить в нее. Тем более назвать «православной».
Почему при использовании OpenVZ/Xen шифрование не работает?
scalaxy.ru реклама детектед.
по статье: использую DropBox + несколько контейнеров трукрипта, в одном из них keypass лежит.
В контейнерах важные данные, которые я хочу сохранить и хочу скрыть.
Всего у меня 5 контейнеров, 100 mb максимум.
Фотки, музыка и образ диска храню на 2х дисках, подключаемых через sata-докстанцию.
по статье: использую DropBox + несколько контейнеров трукрипта, в одном из них keypass лежит.
В контейнерах важные данные, которые я хочу сохранить и хочу скрыть.
Всего у меня 5 контейнеров, 100 mb максимум.
Фотки, музыка и образ диска храню на 2х дисках, подключаемых через sata-докстанцию.
Как насчет необходимости отмонтировать контейнеры во время синхронизации?
А с рекламой — да просто пользуюсь, ребята работают хорошо, в отличии от постоянно упоминаемого Dropbox-а. А вот слово «детектед» — это, сударь, словарь бедный у Вас.
А с рекламой — да просто пользуюсь, ребята работают хорошо, в отличии от постоянно упоминаемого Dropbox-а. А вот слово «детектед» — это, сударь, словарь бедный у Вас.
Я открываю контейнеры, когда они необходимы и после использования сразу отмантирую… чаще 1-2 раза в день на 15 минут они мне не нужны. Раньше нужно было больше, но провел анализ и на остальное забил. Паранойи должно быть в меру.
А словарь — он у каждого свой, какое есть, но свой. В данном случае использован фразеологизм.
А словарь — он у каждого свой, какое есть, но свой. В данном случае использован фразеологизм.
Согласен, с таким профилем использования можно отлично жить. С другой стороны, зачем тогда дропбокс, если главная его прелесть — а именно, работа с отдельными файлами — не востребована? Хранить-то контейнеры где угодно можно, хоть на бесплатных хостингах.
А с «личным» (на самом деле — арендованным) сервером мне приятно еще и то, что я на него неплохо могу скинуть другие задачи, ту же почту, то же качание файлов с медленных хостов (несколько раз выручало) — в общем, почти все, ради чего можно бы и дома держать сервачок, но только здесь это будет «почти домашний сервачок», но на толстом канале и с большей надежностью. Ну и привычнее в администрировании, конечно же — спишем это на «личные причины».
А с «личным» (на самом деле — арендованным) сервером мне приятно еще и то, что я на него неплохо могу скинуть другие задачи, ту же почту, то же качание файлов с медленных хостов (несколько раз выручало) — в общем, почти все, ради чего можно бы и дома держать сервачок, но только здесь это будет «почти домашний сервачок», но на толстом канале и с большей надежностью. Ну и привычнее в администрировании, конечно же — спишем это на «личные причины».
А чем это плох DropBox? Пока только тем, что оказывается к данным есть доступ у некоторых сотрудников.
«Сегодня ты играешь джаз...»
Получается, что они с самого начала правду, как бы сказать, недоговаривали. А что еще они запамятовали сказать?
Получается, что они с самого начала правду, как бы сказать, недоговаривали. А что еще они запамятовали сказать?
«ребята работают хорошо, в отличии от постоянно упоминаемого Dropbox»- я лишь призываю не наговаривать на DropBox лишнего, который упоминался лишь в контексте одной проблемы. Считаю, что предложенный вами метод неадекватно сложен, да еще и платен. Преимущества перед Dropboxом сомнительны. У большинства пользователей количество конфиденциальной информации, которую они хранят в облаке крайне мало (в моем случае ее нет), можно сделать маленький контейнер в Dropbox и все.
Знаете, мне это напоминает известную фразу про то, что «по соотношению цена/качество халявному пиву альтернативы нет». Дропбокс не бесплатен, он просто оплачен деньгами тех, кто платит за сервис.
Я не агитирую ни за, ни против их сервиса. Собственно, свои мысли по поводу темы топика я изложил в первых же паре абзацев — что тут добавить? Мне лично проще использовать то, что сам знаю как устроено.
Я не агитирую ни за, ни против их сервиса. Собственно, свои мысли по поводу темы топика я изложил в первых же паре абзацев — что тут добавить? Мне лично проще использовать то, что сам знаю как устроено.
Может кому-нибудь для реализации сценариев пригодится inotify-tools
Вы имеете в виду, с клиенской стороны делать некие действия по изменению файлов? Как вариант, в принципе, интересно, но…
Синхронизация — штука обоюдоострая: если ее запускать редко, то можно потерять данные, а вот если часто — то рискуем «влететь» на большой трафик и «битые» файлы (если файл открыт и меняется часто, то в точке назначения получится он же, как есть, и почти наверняка «битый»). И баланс между этими вариантами, конечно, каждый находит для себя, но дергать синхронизацию по событиям ФС я бы побоялся. Тем более что rsync и так синхронизирует только то, что изменилось.
Синхронизация — штука обоюдоострая: если ее запускать редко, то можно потерять данные, а вот если часто — то рискуем «влететь» на большой трафик и «битые» файлы (если файл открыт и меняется часто, то в точке назначения получится он же, как есть, и почти наверняка «битый»). И баланс между этими вариантами, конечно, каждый находит для себя, но дергать синхронизацию по событиям ФС я бы побоялся. Тем более что rsync и так синхронизирует только то, что изменилось.
События есть разные и лучше, по-моему, дёргать по событиям ФС, чем rsync по хрону.
В близком мне варианте схемы, когда для синхронизации мы через API хостера запускаем виртуалку, потом через свой API настраиваем iptables пропускать трафик туннеля только с нашего текущего IP, делаем синхронизацию, и отключаем машину (сложно звучит, но в моем случае это самое простое, да и выглядит изящно; данные же у меня не сказать чтобы так часто меняются, а сервер я рассматриваю не как зеркальный диск, а именно как бекап) — в этом варианте события ФС использовать можно с известной опаской, поэтому отношусь настороженно. Мы же не антивирус тут создаем.
Впрочем, я привык жить с ноутом, а портативные устройства не всегда имеют связь, а также запас «лишней» энергии, чтобы делать синхронизацию постоянно. Так что, признаться, и тема такой постоянной синхронизации мне не очень близка — но, конечно же, это не мешает её использовать в других условиях и под более динамичные задачи.
Впрочем, я привык жить с ноутом, а портативные устройства не всегда имеют связь, а также запас «лишней» энергии, чтобы делать синхронизацию постоянно. Так что, признаться, и тема такой постоянной синхронизации мне не очень близка — но, конечно же, это не мешает её использовать в других условиях и под более динамичные задачи.
Ну да, от особенностей поста я отвлекся. Зациклился на замене Дропбоксу :)
С другой стороны, события (вернее файлы) можно собирать в очередь локально, а затем одним пакетом или по таймеру, или по появлению коннекта, или по числу файлов, или просто «вручную» заливать на сервер. rsync же сканит все файлы и лучше раз в час сбрасывать заранее известные 10 файлов (пускай тем же rsync'ом), чем сканить полсотни тысяч файлов в ~ и сбрасывать их же.
С другой стороны, события (вернее файлы) можно собирать в очередь локально, а затем одним пакетом или по таймеру, или по появлению коннекта, или по числу файлов, или просто «вручную» заливать на сервер. rsync же сканит все файлы и лучше раз в час сбрасывать заранее известные 10 файлов (пускай тем же rsync'ом), чем сканить полсотни тысяч файлов в ~ и сбрасывать их же.
rsync, надо сказать, сканирует быстро, если делает это достаточно часто. Сам наблюдал: файловое дерево тысяч на 30 файлов (весьма раскидистое) сканировалось раз в 5 минут буквально за пару секунд, не напрягая систему вообще — но тут, возможно, и ОС со своим кешированием помогла.
Но, в общем-то, с подходом «очередь строим по событиям ФС, а отправляем одним махом» соглашусь, это будет оптимальнее. В идеале бы еще делать копии файлов до того, как они открываются, чтобы быть уверенным в результате копирования — и в этом, кажется, как раз события ФС вполне помогут.
Но, в общем-то, с подходом «очередь строим по событиям ФС, а отправляем одним махом» соглашусь, это будет оптимальнее. В идеале бы еще делать копии файлов до того, как они открываются, чтобы быть уверенным в результате копирования — и в этом, кажется, как раз события ФС вполне помогут.
Есть событие «был открыт на запись и закрыт». Вполне подходит.
Часто лювлю (и чем дальше — тем чаще) себя на мысли, что многие полезные вещи давно уже изобретены и вылизаны, так что изобретение велосипеда не только не оправдано, но и просто вредно в смысле времени и концентрации на результате.
Вот и пример — обидно, что о таких прелестях, как обработка событий ФС, узнаешь порой уже после решения некой задачи. Правда, мне критично отработка синхронизаиции и с Windows, и хотя NTFS может многое, именно про удобный способ ловить такие события я не слышал…
Вот и пример — обидно, что о таких прелестях, как обработка событий ФС, узнаешь порой уже после решения некой задачи. Правда, мне критично отработка синхронизаиции и с Windows, и хотя NTFS может многое, именно про удобный способ ловить такие события я не слышал…
jnotify.sourceforge.net/ — но тут нет события такого.
Цепочка на шеи с флэшкой спасает.
Вы же не думаете, что Ваши личные файлы, расположенные на чужом хостинге, находятся в безопасности и неприкосновенности?
Я думаю, что при желании бекапиться куда-то удаленно, и выборе между Дропбоксом, который декларирует, что шифрует мои данные (но как-то хитро, так, что не только я могу их прочесть), и между собственноручно настроенным сервером (физическим или виртуальным — не суть, главное, чтобы можно было нужные вещи на нем настроить), притом сервером, который будет переданные ему на хранение данные сначала шифровать, а уже потом хранить — я склоняюсь ко второму варианту.
Потому что доберутся недруги дл этого сервера — а им еще надо будет из крипто извлечь то, что сервер для меня хранит. Ключ шифрования, конечно, на том же сервере хранить не надо.
В этом смысле я как раз не понимаю Дропбокс и т.д.: вот им, под их честное слово не вчитываться в мои файлы, отдавать данные на хранение как-то страшно.
Потому что доберутся недруги дл этого сервера — а им еще надо будет из крипто извлечь то, что сервер для меня хранит. Ключ шифрования, конечно, на том же сервере хранить не надо.
В этом смысле я как раз не понимаю Дропбокс и т.д.: вот им, под их честное слово не вчитываться в мои файлы, отдавать данные на хранение как-то страшно.
А NAS с RAID-1 не лучше будет? Гарантия сохранности данных есть (вероятность одновременной поломки обоих винтов не в счет). Если поискать, то и с шифрованием найти, думаю, можно.
А пожар? )
А пожар в ДЦ? =)
Ну… а в двух ДЦ сразу)?
Уговорили. NAS в несгораемом шкафу.
Сопрут, прожгут напалмом, взорвут… =)
А ещё мой NAS не влезет ни в один стандартный шкаф(
А ещё мой NAS не влезет ни в один стандартный шкаф(
Отключенный от всего и вся. На дне глубокой реки. Намазанный отравой от рыб. И заминированный от аквалангистов.
Кажется, мои данные не стоят жизней всех этих существ!
Кажется, мои данные не стоят жизней всех этих существ!
Ну а если серьезно, чем же вам NAS не подходит?
Темой топика. Разговор о том, что кому-то нравится хранить данные совсем в других местах, а не у себя дома.
К тому же NAS: потребляет энергию, гудит, требует сеть — я, например, дома мини ЦХД разворачивать не особо чтобы питаю желание. К данным NAS-а нужно еще достучаться извне, а у меня канал ADSL, исходящий у него не очень… Много «но», который решаются внешним хранилищем достаточно изящно, чтобы хотя бы подумать о нем — и попробовать.
К тому же NAS: потребляет энергию, гудит, требует сеть — я, например, дома мини ЦХД разворачивать не особо чтобы питаю желание. К данным NAS-а нужно еще достучаться извне, а у меня канал ADSL, исходящий у него не очень… Много «но», который решаются внешним хранилищем достаточно изящно, чтобы хотя бы подумать о нем — и попробовать.
У меня к примеру так и есть, NAS настроен на внешку, все что нужно беру оттуда. Конечно это не супер система с защитой, но и очень секретных документов нет.
Уверен, что есть и такие NAS которые стоят денег и защита у них есть. Стоит дома и никто о нем кроме тебя не знает.
Уверен, что есть и такие NAS которые стоят денег и защита у них есть. Стоит дома и никто о нем кроме тебя не знает.
Я бы понял, если бы статья позицианировалась как альтернатива dropbox`у, а не о безопасности своих данных.
Потому что как альтернатива, решение вполне интересное. Но как читаешь про безопасность на «совковом» хостере, по сравнению с dropboх. Как-то даже удивляешься, и дело не в том, что «совковый» хостер плохой, или хороший. Держать свои файлы не на dropbox, а на другом чужом сервере, странная безопасность. Здесь, данные могут сдать по первому требованию тем кому нада, а если не сдадут, то и сервера у них вынести могут. Такими методами, «наши» службы добраться до dropbox не смогут.
Так что, я думаю, рекламу обернули немного не в ту обёртку.
Потому что как альтернатива, решение вполне интересное. Но как читаешь про безопасность на «совковом» хостере, по сравнению с dropboх. Как-то даже удивляешься, и дело не в том, что «совковый» хостер плохой, или хороший. Держать свои файлы не на dropbox, а на другом чужом сервере, странная безопасность. Здесь, данные могут сдать по первому требованию тем кому нада, а если не сдадут, то и сервера у них вынести могут. Такими методами, «наши» службы добраться до dropbox не смогут.
Так что, я думаю, рекламу обернули немного не в ту обёртку.
Знаете, если бы у меня был бы ник, скажем, SCALAXY_RU, я бы еще взялся дискутировать о рекламе, но я к ним отношения особого не имею. С тем же успехом (не запишете в рекламодатели?) можно воспользоваться linode.com, напр. — только что путь до серверов от моего бука вырастет, а так все будет очень похоже. И «маски-шоу» с изъятием серверов в этом случае не грозят, если это критично — они не в России, и не на Украине.
Еще раз посмотрите по тексту — как раз как альтернатива функционалу Dropbox-а, я бы даже постеснялся свой вариант предлагать. Они молодцы, растут и развиваются, удачи им во всем. У меня все сильно скромнее, но мои задачи выполняет. Мои мысли «зачем» в начале статьи и изложены, мне просто хочется знать досконально, что я использую. А Вы, как, предпочитаете верить «дяде» на слово по поводу безопасности совсем даже не его данных?
Еще раз посмотрите по тексту — как раз как альтернатива функционалу Dropbox-а, я бы даже постеснялся свой вариант предлагать. Они молодцы, растут и развиваются, удачи им во всем. У меня все сильно скромнее, но мои задачи выполняет. Мои мысли «зачем» в начале статьи и изложены, мне просто хочется знать досконально, что я использую. А Вы, как, предпочитаете верить «дяде» на слово по поводу безопасности совсем даже не его данных?
Ну о какой безопасности на чужом VPS может идти речь?
Если бы у вас был ник SCALAXY_RU, это была бы просто реклама, то что у вас другой ник, это уже другая реклама.
То что вас НЛО пригласило два дня назад, и вы тут же выдали такую не разу «не рекламную» статью, естественно случайность.
Поймите меня правильно, сама статья мне нравится. Можно было просто указать о варианте использования VPS, без упоминания компаний, или упомянуть хотя бы двух. У вас же получилась весьма навязчивая реклама, ещё и с прилепленной за уши безопасностью.
Если бы у вас был ник SCALAXY_RU, это была бы просто реклама, то что у вас другой ник, это уже другая реклама.
То что вас НЛО пригласило два дня назад, и вы тут же выдали такую не разу «не рекламную» статью, естественно случайность.
Поймите меня правильно, сама статья мне нравится. Можно было просто указать о варианте использования VPS, без упоминания компаний, или упомянуть хотя бы двух. У вас же получилась весьма навязчивая реклама, ещё и с прилепленной за уши безопасностью.
Вы уж простите меня великодушно, что Вам почудилось во мне то, кем я не являюсь.
На чужом (типа своем, но арендованном) VPS только одна (вернее три) опасность существует априори — уничтожение данных ( ещё блокирование доступа, ещё модификация). Если вы заливаете на него данные практически не поддающиеся расшифровке, подписываете их подписью практически исключающей подделку (и не заливаете на него ключ шифрования и подписи), то неверные данные вы не получите (вернее получите, но сможете опознать, что они неверные).
Dropbox — сервис массовый, рассчитанный на пользователей Word-а и Excel-я. Процент тех, из них, кто может сам поднять VPS и настроить удаленный бекап, ничтожно мал. К тому же, если вдруг каждый захочет завести себе для хранения 10Гб свою собственную виртуалку, которая инфраструктурно значительно сложнее аккаунта на Dropboxe, цена на VPS-ы резко изменится ;)
Согласен. Но… Вспоминается Б. Полевой, помните:
— Но ты же советский человек! — настаивал Комиссар.
Это я к тому, что в Хабре народ, в общей массе, чуть более технически грамотный, чем обычные пользователи Word-а и Excel-я, и тема сделать что-то самому может показаться не проблемой для избегания, а задачкой для решения. Но это, конечно, не умяляет заслуг и пользы Дропбокса.
А цены на VPS и диски в них — тут представители многих хостинговых компаний есть, можно спросить, как они изменятся. Мне кажется почему-то, что не только не вырастут, но и упадут даже. Хотя бы потому, что если каждый побежит за виртуалкой, то рост клиентов создаст куда больший положительный эффект, чем расход кусочка места под диск, даже если за диск и брать просто по себестоимости.
— Но ты же советский человек! — настаивал Комиссар.
Это я к тому, что в Хабре народ, в общей массе, чуть более технически грамотный, чем обычные пользователи Word-а и Excel-я, и тема сделать что-то самому может показаться не проблемой для избегания, а задачкой для решения. Но это, конечно, не умяляет заслуг и пользы Дропбокса.
А цены на VPS и диски в них — тут представители многих хостинговых компаний есть, можно спросить, как они изменятся. Мне кажется почему-то, что не только не вырастут, но и упадут даже. Хотя бы потому, что если каждый побежит за виртуалкой, то рост клиентов создаст куда больший положительный эффект, чем расход кусочка места под диск, даже если за диск и брать просто по себестоимости.
Может идея для стартапа? Поднимаем сервер для бэкапа, который при утере вашего ключа даже мы прочитать не сможем!
Так ведь это вопрос веры нам со стороны юзера. Почему он должен именно нам верить?
Да, и самое непонятное: те, кто в теме не разбирается, и так уже на Дропбоксе (и полудесятке конкурентов его), поверив рекламе. Те, кто понимает — что мы им предложим, настроенный сервер? Так ведь они и без нас сами его настроят, либо найдут того, кто это сделает.
Эту услугу может продавать любой из хостеров VPS, это да, но я как-то не вижу того ключевого отличия, за которое хочется платить деньги.
«Личный» VPS — это, как ни крути, сервер, его надо администрировать, о нем думать, его обновлять в плане ПО. Мне это интересно, но таких как я, не наберется, думаю, в кол-ве, оправдывающем запуск спецхостинга под нас.
Да, и самое непонятное: те, кто в теме не разбирается, и так уже на Дропбоксе (и полудесятке конкурентов его), поверив рекламе. Те, кто понимает — что мы им предложим, настроенный сервер? Так ведь они и без нас сами его настроят, либо найдут того, кто это сделает.
Эту услугу может продавать любой из хостеров VPS, это да, но я как-то не вижу того ключевого отличия, за которое хочется платить деньги.
«Личный» VPS — это, как ни крути, сервер, его надо администрировать, о нем думать, его обновлять в плане ПО. Мне это интересно, но таких как я, не наберется, думаю, в кол-ве, оправдывающем запуск спецхостинга под нас.
Ключевой недостаток такого решения это то, что все это дело требует администрирования, нужно будет забивать голову надежностью, бекапами и т.п. То есть, фактически, нужно будет реализовать свой dropbox в каком-то обрезанном варианте.
В идеале, хотелось бы dropbox, который шифрует на стороне клиента :)
В идеале, хотелось бы dropbox, который шифрует на стороне клиента :)
Хранить данные только в чужом подъезде в большом железном ящике. Прикрутить функцию самоуничтожения при несанкционированном вскрытии.
В интернет ходить исключительно через тройной каскад ssh туннелей через 3 страны с vpn туннелем поверх ssh туннелей через четвертуюиз макдака с вайфаем.
Нигде не оставлять никакой личной информации, везде использовать разные неуникальные ники.
Никаких скайпоасек, только собственный jabber сервер с pgp шифрованием.
В интернет ходить исключительно через тройной каскад ssh туннелей через 3 страны с vpn туннелем поверх ssh туннелей через четвертую
Нигде не оставлять никакой личной информации, везде использовать разные неуникальные ники.
Никаких скайпоасек, только собственный jabber сервер с pgp шифрованием.
Детский лепет какой-то. Используй просто Amazon S3 — не надо занимать белый ip4 у человечества, да и возни сильно меньше. Людей которые способны установить dropbox сильно больше чем тех кто может поднять vps в каком-нибудь «скалакси». Те кто могут — давно решили свои проблемы миллионом наиболее подходящих способов. Надеюсь не настолько извращенным. ;)
А что, на Амазоне даже айпишник не дают? :( Я так понял по хаьру, что там полноценная машина с динамически изменяемым «железом»…
Для S3 он и не нужен, а если работать так же через виртуалку, то пока айпи привязан к поднятой виртуалке, то он в ее цене. А если зарезервирован и никуда не подцеплен — копеечка тикает…
Дают, дают. У них логика такая: если у меня есть машина, и я прошу IP, то адрес мне дадут бесплатно, а вот если я просто так попрошу адрес, не привязав его к машине, то с меня возьмут абонплату. Логично в смысле защиты от любителей набрать адресов «побольше», про запас.
Но и без запроса адреса можно работать, просто выход в мир — через NAT, можно попросить пробросить на свой сервер какие-то порты, и адрес выхода будет динамический. Для иных задач такого тоже хватает.
Но и без запроса адреса можно работать, просто выход в мир — через NAT, можно попросить пробросить на свой сервер какие-то порты, и адрес выхода будет динамический. Для иных задач такого тоже хватает.
«Почему страдаю? Я ими наслаждаюсь!»
Главное, чтобы использующему тот или иной способ нравилось, я так полагаю.
P.S. Если наберете миллион способов, да еще менее извращенных, буду Вам рукоплескать!
Главное, чтобы использующему тот или иной способ нравилось, я так полагаю.
P.S. Если наберете миллион способов, да еще менее извращенных, буду Вам рукоплескать!
Использую свою домашнюю пару как webdav сервер. Смотрю на пользователей проприетарного продукта с удивлением
Облачные хранилища, как и социальные сети, для простого юзера, может, и хорошо, а во с точки зрения ИБ уже далеко не все так однозначно.
Вывод один: конфиденциальную инфу всё-таки лучше хранить по-старинке. Благо, те же flash-накопители с каждым годом все дешевле.
Вывод один: конфиденциальную инфу всё-таки лучше хранить по-старинке. Благо, те же flash-накопители с каждым годом все дешевле.
Вполне заслуживающее уважениея мнение. Но я писал не об этом, а о том, что для любителей хранить свои данные по-модному, «снаружи», есть вариант не использовать совсем уже готовое решение, а сделать все своими руками.
Правда, есть вопрос — флешки со временем ведут себя не особо предсказуемо. Запишешь, а потом — оп! — и никакой шпион уже не прочитает, не то что хозяин…
Правда, есть вопрос — флешки со временем ведут себя не особо предсказуемо. Запишешь, а потом — оп! — и никакой шпион уже не прочитает, не то что хозяин…
Ну тут можно парировать: облака ведут себя не менее непредсказуемо — скинешь на облако, а тут — оп! — кошка локалку перегрызла, или DDoS, или в штатах законодательство поменялось, провайдер шалит, да там много вариантов на самом деле. Тут уже надо грамотно риски простраивать. Но это уже разговоры из другой плоскости.
Но статья все равно занятная, спасибо.
Но статья все равно занятная, спасибо.
Буквально вчера интересовался возможностью бэкапа в облако, и для объёмов порядка терабайта что-то особого «выбирай — нехочу» не заметил.
S3 — 3780руб/мес.
Вот и всё.
А все дропбоксы сразу идут лесом со своими 100Gb.
VDS на скалакси получится 8000руб/мес.
На других хостингах расценок на расширяемое дисковое пространство вообще не нашёл.
S3 — 3780руб/мес.
Вот и всё.
А все дропбоксы сразу идут лесом со своими 100Gb.
VDS на скалакси получится 8000руб/мес.
На других хостингах расценок на расширяемое дисковое пространство вообще не нашёл.
Ну, я-то не про такой калибр писал. S3 — вполне себе вариант, тем более что куда как более «заточенный» под объемы.
Но вот пишут про 100 Гб, чуть не за 20 долларов. Сам с ними не работал, но, знаю, что ребята серьезные.
Но вот пишут про 100 Гб, чуть не за 20 долларов. Сам с ними не работал, но, знаю, что ребята серьезные.
«Аренда в разных концах мира» так же не учитывает риск глобальной потери каналов данных…
Почти в тему: как рассказывал один знакомый спец ИБ, в их компании не только для бэкапа, но и для работы использовались доступные по WiFi сервера, установленные во всегда готовой отъехать от офиса машине.
«Как то раз очень помогло»)
ps
за идеи — спасибо.
Почти в тему: как рассказывал один знакомый спец ИБ, в их компании не только для бэкапа, но и для работы использовались доступные по WiFi сервера, установленные во всегда готовой отъехать от офиса машине.
«Как то раз очень помогло»)
ps
за идеи — спасибо.
статья правильная и мысль четкая, НО не стоит забывать, ЧТО по закону о телекомуникациях ваш провайдер хранит логи ваших коннектов до 2х лет (на практике не больше полугода), и если за вами придут, то всё узнают (куда вы заливали). А пароли вы сами расскажете, как только в камере недельку посидите.
Пусть хранит. Ну висел коннект… Так СОРМ и так этот коннект видит, как видит и наличие трафика в нем (ssh, который частенько что-то помногу передает — подозрительно). Но, согласитесь, мы тут все же от пожаров бережемся с нашими бекапами, да от нехороших дядей от мелкого до среднего калибра закрываемся, а не от правоохранительных органов. А мелкий калибр плохишей до данных СОРМ-а, будем надеяться, не доберется.
Если же очень хочется, покупаем VPN-туннель с приземлением на западе, его постоянно забиваем случайными данными (чтобы было видно, что канал нагружен все время, и нельзя было коррелировать время загрузки канала с временем работы сервера/офиса/нас самих), и только когда надо что-то передавать, подвинув «белый шум», передаем свои данные уже на свой сервер… Можно и цепочкой это все завязать… Что-то накручено как-то, какова ценность данных-то?
Если же очень хочется, покупаем VPN-туннель с приземлением на западе, его постоянно забиваем случайными данными (чтобы было видно, что канал нагружен все время, и нельзя было коррелировать время загрузки канала с временем работы сервера/офиса/нас самих), и только когда надо что-то передавать, подвинув «белый шум», передаем свои данные уже на свой сервер… Можно и цепочкой это все завязать… Что-то накручено как-то, какова ценность данных-то?
Получается что провайдер облака может в любое время подмаунтить диски виртуальной машины куда нужно и безо всякого дешифрования и подбора паролей слить чего нужно куда нужно ;) Особенно если об этом его попросят господа или какие-либо другие внутренние органы.
Я до сих пор периодически пытаюсь продумать систему синхронизации с удалённым сервером с шифрованием, с учётом того что рут-доступ к серверу может быть не только у меня.
Т.е. задача хранить файлы в зашифрованном виде на диске, но ключ шифрования должен быть только у меня, поэтому варианты с шифрованным диском на сервере, который сам открывается при загрузке или через autorun — не прокатывают. И синхронизировать хотелось бы только изменения, а не все файлы подряд.
При последнем обострении нарыл утилиту rsyncrypto — вроде как раз то что надо, синхронизирует только изменения, поэтому лишний трафик гонять не будет. Но развитие проекта идёт как-то вяло и у меня пока не получилось его настроить чтобы заработало. И подобных альтернатив не нашёл. Так что кому интересно — могут тоже попробовать его поиспользовать, по к
Я до сих пор периодически пытаюсь продумать систему синхронизации с удалённым сервером с шифрованием, с учётом того что рут-доступ к серверу может быть не только у меня.
Т.е. задача хранить файлы в зашифрованном виде на диске, но ключ шифрования должен быть только у меня, поэтому варианты с шифрованным диском на сервере, который сам открывается при загрузке или через autorun — не прокатывают. И синхронизировать хотелось бы только изменения, а не все файлы подряд.
При последнем обострении нарыл утилиту rsyncrypto — вроде как раз то что надо, синхронизирует только изменения, поэтому лишний трафик гонять не будет. Но развитие проекта идёт как-то вяло и у меня пока не получилось его настроить чтобы заработало. И подобных альтернатив не нашёл. Так что кому интересно — могут тоже попробовать его поиспользовать, по к
На самом деле обычный rsync прекрасно передает разницу в файлах, и замечательно работает поверх ssh-туннеля. Примерно этот же функционал, мне кажется, предлагает и rsyncrypto, так что можно понять, почему проект замер.
Слить провайдер может, но кто мне помешает шифровать целый диск? Ключ — разумеется, не следует его хранить рядом с зашифрованным, но уже можно зайти удаленно, ввести пароль, замонтировать диск. В конце концов, здесь как раз чем сложнее, тем больше греется сердце каждого параноика :)
Опять же, цель не прятать инфу о сверхдоходах, а просто ощущать, что в личные данные не залезет абы кто. Про способность туда проникнуть у кого надо даже дискутировать не хочу, не всегда, знаете ли, пароль решает, иногда найдутся и другие пути получить все, что нужно. Помните, была такая шутка:
Главный системный администратор компании ЮКОС заявил, что на современном уровне развития IT-технологий понадобится 10 лет для получения пароля доступа к их базам данных. Специалистам силовых структур потребовалось 6 минут, из них 3 — на привязывание скотчем к стулу...
Слить провайдер может, но кто мне помешает шифровать целый диск? Ключ — разумеется, не следует его хранить рядом с зашифрованным, но уже можно зайти удаленно, ввести пароль, замонтировать диск. В конце концов, здесь как раз чем сложнее, тем больше греется сердце каждого параноика :)
Опять же, цель не прятать инфу о сверхдоходах, а просто ощущать, что в личные данные не залезет абы кто. Про способность туда проникнуть у кого надо даже дискутировать не хочу, не всегда, знаете ли, пароль решает, иногда найдутся и другие пути получить все, что нужно. Помните, была такая шутка:
Главный системный администратор компании ЮКОС заявил, что на современном уровне развития IT-технологий понадобится 10 лет для получения пароля доступа к их базам данных. Специалистам силовых структур потребовалось 6 минут, из них 3 — на привязывание скотчем к стулу...
Проблема не в том что провайдер украдёт данные при передаче, а в том что на бекап-сервере они хранятся в открытом виде.
Поэтому любой, имеющий рутовый доступ к бекап-серваку, сможет их посмотреть.
И требуется защита именно от этого, чтобы просто так шаловливые руки админа не пялились на мои интимные фотки, а была бы хоть какая-то защита.
Паяльник применять для того чтобы на эти фотки посмотреть он навряд ли будет, а так если валяются просто в папке в открытом виде — то почему бы не полазить?
Если делать шифрованный диск, то он будет подмонтирован и свободно доступен для админа, поэтому этот вариант не катит.
У rsyncrypto технология такая: он разбивает каждый файл на кусочки и шифрует их отдельно. Поэтому при изменении части файла нужно будет перешифровать только кусок, а не весь файл в случае обычного шифрования.
В результате на бекап-сервере лежат в открытом доступе шифрованные файлы, которые без моего ключа не расшифруешь, но при синхронизации передаются только изменения, а не всё файло.
Поэтому любой, имеющий рутовый доступ к бекап-серваку, сможет их посмотреть.
И требуется защита именно от этого, чтобы просто так шаловливые руки админа не пялились на мои интимные фотки, а была бы хоть какая-то защита.
Паяльник применять для того чтобы на эти фотки посмотреть он навряд ли будет, а так если валяются просто в папке в открытом виде — то почему бы не полазить?
Если делать шифрованный диск, то он будет подмонтирован и свободно доступен для админа, поэтому этот вариант не катит.
У rsyncrypto технология такая: он разбивает каждый файл на кусочки и шифрует их отдельно. Поэтому при изменении части файла нужно будет перешифровать только кусок, а не весь файл в случае обычного шифрования.
В результате на бекап-сервере лежат в открытом доступе шифрованные файлы, которые без моего ключа не расшифруешь, но при синхронизации передаются только изменения, а не всё файло.
> Если делать шифрованный диск, то он будет подмонтирован
Да, подмонтирован, на то время, пока будет работать бекап.
В моем понимании, схема может быть такой: мой локальный скрипт удаленно через API включается ВМ, заходит на ВМ, настраивает firewall, закрывая доступ для всех, кроме моего IP, после монтирует в ВМ шифрованный диск (может в этот момент спросить пароль у меня, или еще откуда-то его взять), поднимает ssh-туннель, в нем, при помощи rsync, делает сравнение файлов локальных и удаленных, передает изменения, отмонтирует диск, через API выключает ВМ.
От большей части напастей это убережет, но не от всех, конечно. Злобный админ может вообще настроить делание снапшотов всего, что монтируется в ВМ, а потом настроить скрипт собирать из этих снапшотов все картинки, которые больше чем какие-то линейные размеры (чтобы не коллекционировать мелкие картинки. используемые в оформлении сайтов). Остается уповать, что на крупных хостингах таких виртуалок — тысячи, и искать интимное добро в каждой замучается даже скрипт, не то что админ устанет просматривать их.
Да, подмонтирован, на то время, пока будет работать бекап.
В моем понимании, схема может быть такой: мой локальный скрипт удаленно через API включается ВМ, заходит на ВМ, настраивает firewall, закрывая доступ для всех, кроме моего IP, после монтирует в ВМ шифрованный диск (может в этот момент спросить пароль у меня, или еще откуда-то его взять), поднимает ssh-туннель, в нем, при помощи rsync, делает сравнение файлов локальных и удаленных, передает изменения, отмонтирует диск, через API выключает ВМ.
От большей части напастей это убережет, но не от всех, конечно. Злобный админ может вообще настроить делание снапшотов всего, что монтируется в ВМ, а потом настроить скрипт собирать из этих снапшотов все картинки, которые больше чем какие-то линейные размеры (чтобы не коллекционировать мелкие картинки. используемые в оформлении сайтов). Остается уповать, что на крупных хостингах таких виртуалок — тысячи, и искать интимное добро в каждой замучается даже скрипт, не то что админ устанет просматривать их.
Предложенный процесс конечно надёжный, но уж больно долго это настраивать для радового юзера, пытающегося забекапить свои интимные фотки ;)
Но для бекапа серьёзных данных вполне хорошее решение.
Я всё же, если с rsyncrypto так и не разберусь, ограничусь для себя наверно следующими этапами:
1. Подключаемся под ssh, монитруем шифрованный диск (пароль хранится у меня на компе в скрипте).
2. Через rsync синхронизируем всё что нужно.
3. Отмонтируем диск, отключаемся.
Но для бекапа серьёзных данных вполне хорошее решение.
Я всё же, если с rsyncrypto так и не разберусь, ограничусь для себя наверно следующими этапами:
1. Подключаемся под ssh, монитруем шифрованный диск (пароль хранится у меня на компе в скрипте).
2. Через rsync синхронизируем всё что нужно.
3. Отмонтируем диск, отключаемся.
Sign up to leave a comment.
Онлайн хранение документов — как быть спокойным за свои данные?