Какую "модель" выбрать для шифрования резервных ко
Хочу спросить, как лучше поступить в след. ситуации.
Примерно раз в неделю делаю резервную копию новых/измененных данных на dvd-r (на промежуточный носить резервное копирования делается каждый день). Данные записываю на болванку в зашифрованном виде (создаю контейнер, скидываю в него резервную копию, закрываю контейнер, и записываю его на болванку).
Как правильнее организовать "процесс"?
Раньше рассматривал два варианта:
1. Выбрать и запомнить один длинный пароль и применять его ко всем контейнерам.
2. Для каждого контейнера использовать свой пароль, и эти пароли хранить в текстовом файле, положив его в другой контейнер (или в запоминатель паролей), пароль от которого запоминать.
Или использовать третий вариант:
3. Создать открытый и приватный PGP ключ, с длинным паролем, запомнить пароль. Все файлы с резервными копиями шифровать открытым PGP ключем. Приватный PGP ключ хранить в контейнере с другим длинным паролем в "недоступном месте". Оба пароля помнить! :)
Записанные диски могут потребоваться только в "случае пожара", в остальное время их не трогают.
Но оценить какой их этих вариантов более правильный с точки зрания криптографии и реализации в конечных программах (PGP и TrueCrypt) я не могу.
Третий вариант мне нравится больше, из-за отсутствия ввода каждый раз пароля (на случай кейлогера), и отсутствия необходимости хранить приватный ключ "близко от цели" (не знаю, насколько это улучшает стойкость).
А може есть еще варианты???
PS Не пинайте, если спрашиваю совсе уж тривиальных вещи. :)
Для ноутбука и для сервера они совершенно разные. Второй вариант не имеет примущиств по сравнению с первым. Первый вариант больше подходит для персонального компьютера (рабочей станции, ноутбука, и т. п.), а третий для сервера. Но это только так, не зная подробностей.
Вообще, вопросы безопасности и надежности бэкапов — интересная и весьма нетривиальная тема. Очень многое зависит от конкретных требований конкретной ситуации.
Я понимаю, что вопрос защиты информации должен решаться комплексно. Но я хочу выделить только задачу шифрования резервных копий, "модель сферического коня в вакууме". :)
Хочется выбрать вариант который имеет меньше потенциальных (и реальных) уязвимостей. Ну например при первом или втором варианте, имхо, самую большую угрозу представляет кейлогер, тк пароль вводится каждый раз, и достаточно один раз скомпрометировать пароль, чтобы все до этого сделанные копии могли быть открыты.
А хочется найти не "достаточный" вариант, а "минимально уязвимый" вариант, тот, который можно применить и для резервных копий нотера, и для сервера.
Например, какие уязвимости присутствующие в 3 варианте отсутствуют в первом?
Еше один вариан:
4. Заранее сделать большое количество пар PGP ключей, с одинаковым паролем. Каждую резервную копию шифровать своим ключем. Остальное все как в третьем варианте – контейнер со всеми приватными ключами хранится в недоступном месте.
Я так понял, что зная открытый ключ, при большом желании ;) можно (читай очень трудно, практически невозможно) узнать приватный ключ и прочитать данные зашифрованные им, но нельзя определить пароль, которым закрыт приватный ключ.
PS Действительно вопрос шифрования резервных копий "сильно нетривиальная" задача?!
комментариев: 11558 документов: 1036 редакций: 4118
Ещё, наверное, коня с равномерной плотностью. :)
комментариев: 510 документов: 110 редакций: 75
теоретически можно, но времени на это уйдет столько, что Ваша информация будет уже никому не нужна. В данном случае время исчисляется далеко не днями, и даже не годами, и даже не десятилетиями...а миллионами и даже миллиардами лет (если математики не сотворят чудо).
В остальном мне кажеться Вы предлагаете схему, в которой легко запутаться. Если Вы боитесь кейлоггера, можно бояться и трояна, который может украсть Ваш ключ и пароль, а это уже несколько другой аспект безопасности. В данном случае я бы обратил внимание на использование смарт-карт для хранения OpenPGP ключа или же выполнение операций шифрования на отдельной машине.
Неужели бывают и такие?! ;)
Этим я хотел сказать/спросить, что не имея доступ к приватному ключу, по открытому ключу нельзя сказать каким паролем закрыт приватный ключ.
То, что "взлом" открытого ключа занимает о-о-о-чень много времени я уже знаю! :)
В Этой Жизни я мало чего боюсь. :) Просто есть веши, которые считаю нежелательными. ;)
Собственно, я так и задумывал: на отдельном проверенном компе, за один раз создается нужное количество пар ключей, приватные записываются в контейнер и контейнер нарезается на болванку и убираются "с глаз долой", открытые ключи записываются на другую болваку и используются для шифрования рез. копий.
И минимальные "телодвижения" в процессе рез. копирования – только указать новый ключ.
PS Думаю, что если сразу не указали на уязвимости, значит явные дыры в таком варианте маловероятны. ;) Или нет? ;)
Так что если оперативность при восстановленни после "пожара" критична, то надо постоянно синхронизировать запасной копмьютер (по зашифрованному каналу, конечно), а чтобы обеспечить "надежную защиту от злобных вражеских посягательств", надо все файловые системы кромя /usr, /bin, /sbin и /boot шифровать (да, даже /tmp, /var и swap!). Для этого не плохо иметь сервер с двумя или более поцессорами (один шифрует, остальные работают).
Надо немножко пожанглировать маленькой стартовой системой, которая, при введении ключа для зашифрованных разделов монтирует и запускает настоящюю систему. Ключ для шифрования файловых систем должен храниться у всех доверенных лиц будучи зашифрованный их же открытыми ключами.
Недавно, наш сервер в Будапеште перезапускался после сбоя из интернет-кафэ Главпочтамта в Киеве (так получилось, что по закону подлости, все доверенные лица находились зарубежем в тот момент). :-)
Но все это относится только к серверам. С персоналками все проще.
Зачем Вам много ключей только я не пойму. Если Вы уберете приватный ключ в надежное место, есть ли смысл в большом количестве ключей, а так же в том, что бы зарывать его в отдельный контейнер. Сам по себе секретный ключ зашифрован симметричным алгоритмом, без знания пароля им воспользоваться невозможно. Открытые ключи можно держать открыто на том компьютере, где Вы производите шифрование.
Если Вы очень беспокоитесь о сохранности ключа, то кроме смарт-карт в PGP предусмотрена технология разделения ключей.
И если можно вопрос. Что Вы имеете в виду под резервными файлами? Выполнять шифрование архивных папок или файлов pgd – дисков? PGP дисками Вы воспользоваться не сможете, в том случае если приватного ключа на машине не будет, т.к. перед записью в такой диск его нужно будет открывать. По видимому Вам придется архивировать информацию в папки и шифровать такие архивные папки. Иначе говоря применить некую свою систему архивов.
Ну и последнее, о чем писал Д. Надь. Предлагаемая Вами схема защитит отдельно хранимые резервные данные (впрочем Вы не писали, шифрована ли информация на рабочей машине), если данные представляют высокую ценность, то информация на рабочей машине так же должна быть шифрована, а в данном случае вся идея с хранимыми отдельно приватными ключами на мой взгляд частично ставится под сомнение, т.к. информацию можно тем или иным способом похитить с самой рабочей машины. Здесь все зависит от конкретной ситуации конечно.
Это так конечно.
И даже имея приватный ключ, нельзя сказать каким паролем он зашифрован. Однако если Ваш приватный ключ все таки попал в чужие руки, то гипотетически принято считать, что Ваш ключ скомпрометирован, т.к. Ваш пароль могли так же украсть, ранее чем сам ключ, здесь конечно опять же все зависит от конкретных ситуаций.
Поправлюсь. Данное утверждение справедливо если украденный пароль соответствует той копии ключа, которая зашифрована с применением этого пароля.
В отдельный контейнер – это для "двухуровневой" защиты. Возможно это излишне, но я не знаю ответ на этот вопрос.
Насчет большого количество ключей, возможно это тоже лишнее, но и на этот вопрос я не знаю ответа.
Открытые ключи, конечно, будут лежать на машине, на которой выполняется резервное копирвоание.
Данные для рез. копирования предполагаются как "открытые" (полученные с уже открытого pgp-диска), так и "закрытые" (одразы винтов с pgp wde).
Вот именно потому, что pgp-диск для записи в него нужно каждый раз открывать, я и отказался от варианта 1.
В варианте 3 и 4 для зашифровывания рез. копии пароль вводить не нужно.
Те от программы Backup_а получаем один файл с рез. копией, его зашифровываем, нарезаем на двд, незашифрованный файл стираем.
Ни в коем случае не спорю с тем, что зашита информации должна быть комплексной, иначе это будет сейфовая дверь для карточного домика! :) Поэтому хотел заранее оговориться, что рассматриваем только шифрования резервных копий, как хранятся данные До копирования не принимать во внимание.
Так же не рассматриваются варианты "бандитской ректально-термической криптографии".
[quote:9656b68f38="Д. Надь"]Так что если оперативность при восстановленни после "пожара" критична, то надо постоянно синхронизировать запасной копмьютер (по зашифрованному каналу, конечно), а чтобы обеспечить "надежную защиту от злобных вражеских посягательств", надо все файловые системы кромя /usr, /bin, /sbin и /boot шифровать (да, даже /tmp, /var и swap!).
Нет, оперативность восстановления абсолбтно не нужна.
А swap лучше вообще не использовать, а добавить оперативки. ;)
[quote:9656b68f38="Д. Надь"]Надо немножко пожанглировать маленькой стартовой системой, которая, при введении ключа для зашифрованных разделов монтирует и запускает настоящюю систему. Ключ для шифрования файловых систем должен храниться у всех доверенных лиц будучи зашифрованный их же открытыми ключами.
Но все это относится только к серверам. С персоналками все проще.
Наверно в моем случае ближе всего подойдет определение "пероснальный сервер", к нему у меня есть локальный/физический доступ. Так что процесс запуска сервера не требует отдельной стартовой системы.