>>> 3. TrueCrypt
>>>…
>>> Кроме того, файлы можно синхронизировать только после того, как Вы размонтировали его. >>> Это означает, что Вы не сможете синхронизировать свои файлы в режиме реального времени.
Возможно, получится использовать механизм Shadow Copy для получения «снапшота» криптоконтейнера, который в свою очередь и синхронизировать с DropBox'ом.
Только не забывайте чистить хистори bash'a на той машине, где производите эти манипуляции, а то все телодвижения с точностью до байта останутся записанными для потомков.
$ echo "любой отрывок текста из любой книги" > file.txt
$ md5sum file.txt | fold -10 | head -1
95584f1920
$ rm file.txt
«3.8.1 Оператор магазина приложений должен предоставлять уполномоченным правоохранительным органам доступ к административному интерфейсу удалённой инсталляции приложений на устройства пользователей.»
Рутину надо автоматизировать. Программисты всегда же так делают?
Значит, нужно приложение, которое будет от имени пользователя следить за тем, какие разрешения запрашивает инсталлируемое приложение. И если есть что-то подозрительное, что пользователь явно указал «Не пущать!» — сигнализирует.
Дальше можно группировать запреты логическими операторами, скобками, помещать в поименованные профили — управлять, в общем.
Правильно понимаете.
Вариант есть. Нужен установленный nnCron. У него есть семейство очень полезных ключевых слов Watch*. А конкретнее, в данном случае:
WatchDrive: "B"
При появлении диска с совпадающей буквой (т.е. «флешки» с криптоконтейнером на ней) срабатывает описанное ниже в скрипте правило:
\ Проверить, "флешка" ли это - есть ли файл "H:\KeePass Password Safe\KeePass.exe"
FILE-EXIST: "B:\KeePass Password Safe\KeePass.exe" \ Если есть - запустить "B:\KeePass Password Safe\KeePass.exe"
IF \ Если KeePass.exe ещё не запущен...
PROC-EXIST: "KeePass.exe" NOT
IF \ ... запустить его.
StartIn: "B:\KeePass Password Safe"
ShowNormal NormalPriority
START-APP: "B:\KeePass Password Safe\KeePass.cmd"
THEN
При появлении в системе диска B: (интервал сканирования настраивается. По умолчанию — 1000 мс) проверяется его содержимое. На диске должен быть KeePass. Если он есть — он запускается. Но не непосредственно, а батником. Файл KeePass.cmd делает бэкап базы паролей, добавляя в имя файла штамп времени и сохраняя его в выделенные каталоги (рядом на флешке и в «Моих документах» текущего пользователя. База зашифрована, за содержимое можно не волноваться).
\ Запустить монтирование тома на "флешке"
FILE-EXIST: "B:\TrueCrypt\TrueCrypt.exe"
IF \ Если файл криптоконтейнера существует на "флешке" ...
FILE-EXIST: "B:\MyDocs.tc"
IF
StartIn: "B:\TrueCrypt\"
ShowNormal NormalPriority
START-APPW: "B:\TrueCrypt\TrueCrypt.exe" /b /letter I /volume "B:\MyDocs.tc"
...
Теперь с использованием интерфейса командной строки TrueCrypt монтируется контейнер на выделенную букву диска. Ну, и дальше — всё что нужно.
В принципе, можно запрограммировать любые действия в пределах компетенций языка Форт, встроенного в nnCron.
Может быть. Не знаю насчёт Dropbox'a, а git и svn будут воспринимать криптоконтейнер как бинарный файл. Причём так как он «крипто-», то различий между двумя его версиями будет очень много. Поэтому «версионировать» по сети малыми diff'ами для синхронизации 500 Мб криптоконтейнер, по моему мнению, не получится.
Архивировать для хранения — тоже не вариант, опять же из-за того, что файл шифрованный и энтропия его велика.
А гонять по сети туда-сюда каждый раз по 500Мб — удовольствие на любителя.
Приоритеты для себя я давно расставил и особо важные «активы» — выделил. Всё, что нужно, — бэкапится. В контейнере хранится только оперативная информация, которая хранится также и в других местах и потеря которой в данном месте не критична. Затраты на бэкап, как показал «инцидент», не окупились бы всё равно.
Резервирование настроено. Вся критическая информация, которая, будучи потеряна, не сможет быть восстановлена или приведёт к неприемлемым задержкам в делах, копируется при любом удобном случае. Например, бакап базы паролей делается тем же скриптом, который запускает менеджер паролей, минимум дважды в сутки.
В контейнере же хранится оперативная информация (типа кэша). То есть такая, которая где-то ещё разбросана по накопителям, там же, при необходимости, резервируется и т.п. Всю её можно, потратив какое-то время, собрать заново. Например, сканы паспортов, свидетельств о рождении, сохранённые веб-страницы. Ценность эта информация представляет только из-за того, что здесь и сейчас она — со мной и не надо совершать лишних телодвижений, чтобы её получить.
В конце концов время, потраченное на восстановление, действительно оказалось гораздо меньше ориентировочного времени, которое я потратил бы на сбор всего этого заново.
С точки зрения решения проблемы — в принципе да. Тут, я считаю, чем проще — тем лучше.
С точки зрения причины — проблема в «трансляции» сбойных кластеров с нижнего уровня — базовой файловой системы — на верхний — в файловую систему контейнера. Точнее, в её отсутствии.
Если бы TrueCrypt «умел» бы определять сбойные кластеры на «родительской» файловой системе и переносить данные с них на другие, исправные… (Что в конце концов пришлось сделать вручную)
Хоть TrueCrypt и open source, но слишком далеко от моей специализации, чтобы взяться и сделать самому.
>>>…
>>> Кроме того, файлы можно синхронизировать только после того, как Вы размонтировали его. >>> Это означает, что Вы не сможете синхронизировать свои файлы в режиме реального времени.
Возможно, получится использовать механизм Shadow Copy для получения «снапшота» криптоконтейнера, который в свою очередь и синхронизировать с DropBox'ом.
«3.8.1 Оператор магазина приложений должен предоставлять уполномоченным правоохранительным органам доступ к административному интерфейсу удалённой инсталляции приложений на устройства пользователей.»
Значит, нужно приложение, которое будет от имени пользователя следить за тем, какие разрешения запрашивает инсталлируемое приложение. И если есть что-то подозрительное, что пользователь явно указал «Не пущать!» — сигнализирует.
Дальше можно группировать запреты логическими операторами, скобками, помещать в поименованные профили — управлять, в общем.
Вариант есть. Нужен установленный nnCron. У него есть семейство очень полезных ключевых слов Watch*. А конкретнее, в данном случае:
WatchDrive: "B"При появлении диска с совпадающей буквой (т.е. «флешки» с криптоконтейнером на ней) срабатывает описанное ниже в скрипте правило:
\ Проверить, "флешка" ли это - есть ли файл "H:\KeePass Password Safe\KeePass.exe"
FILE-EXIST: "B:\KeePass Password Safe\KeePass.exe"
\ Если есть - запустить "B:\KeePass Password Safe\KeePass.exe"
IF
\ Если KeePass.exe ещё не запущен...
PROC-EXIST: "KeePass.exe" NOT
IF
\ ... запустить его.
StartIn: "B:\KeePass Password Safe"
ShowNormal NormalPriority
START-APP: "B:\KeePass Password Safe\KeePass.cmd"
THEN
При появлении в системе диска B: (интервал сканирования настраивается. По умолчанию — 1000 мс) проверяется его содержимое. На диске должен быть KeePass. Если он есть — он запускается. Но не непосредственно, а батником. Файл KeePass.cmd делает бэкап базы паролей, добавляя в имя файла штамп времени и сохраняя его в выделенные каталоги (рядом на флешке и в «Моих документах» текущего пользователя. База зашифрована, за содержимое можно не волноваться).
\ Запустить монтирование тома на "флешке"
FILE-EXIST: "B:\TrueCrypt\TrueCrypt.exe"
IF
\ Если файл криптоконтейнера существует на "флешке" ...
FILE-EXIST: "B:\MyDocs.tc"
IF
StartIn: "B:\TrueCrypt\"
ShowNormal NormalPriority
START-APPW: "B:\TrueCrypt\TrueCrypt.exe" /b /letter I /volume "B:\MyDocs.tc"
...
Теперь с использованием интерфейса командной строки TrueCrypt монтируется контейнер на выделенную букву диска. Ну, и дальше — всё что нужно.
В принципе, можно запрограммировать любые действия в пределах компетенций языка Форт, встроенного в nnCron.
Архивировать для хранения — тоже не вариант, опять же из-за того, что файл шифрованный и энтропия его велика.
А гонять по сети туда-сюда каждый раз по 500Мб — удовольствие на любителя.
В контейнере же хранится оперативная информация (типа кэша). То есть такая, которая где-то ещё разбросана по накопителям, там же, при необходимости, резервируется и т.п. Всю её можно, потратив какое-то время, собрать заново. Например, сканы паспортов, свидетельств о рождении, сохранённые веб-страницы. Ценность эта информация представляет только из-за того, что здесь и сейчас она — со мной и не надо совершать лишних телодвижений, чтобы её получить.
В конце концов время, потраченное на восстановление, действительно оказалось гораздо меньше ориентировочного времени, которое я потратил бы на сбор всего этого заново.
С точки зрения причины — проблема в «трансляции» сбойных кластеров с нижнего уровня — базовой файловой системы — на верхний — в файловую систему контейнера. Точнее, в её отсутствии.
Если бы TrueCrypt «умел» бы определять сбойные кластеры на «родительской» файловой системе и переносить данные с них на другие, исправные… (Что в конце концов пришлось сделать вручную)
Хоть TrueCrypt и open source, но слишком далеко от моей специализации, чтобы взяться и сделать самому.