Являются ли зашифрованные резервные копии хорошей идеей?

Я отвечаю за небольшой набор ноутбуков и хотел получить какое-то автоматическое удаленное (через WAN) резервное копирование; резервные копии будут идти на диск RAID. Поскольку у нас на самом деле нет безопасного хранилища для хранения всех наших дисков (если кто-то захочет, они могут разбить окна и забрать наши диски), я подумал об использовании шифрования, возможно, что-то вроде двуличия ( http: //duplicity.nongnu .org / ). Я обсуждал это с несколькими разработчиками, но они, похоже, убеждены, что шифрование - плохая идея, потому что один плохой бит может испортить весь блок. Однако на самом деле я не слышал ни о каких ужасных историях, где это произошло. Каково ваше мнение? Преимущества перевешивают риски с шифрованием?

Я делаю это, и это работает для меня (например, резервные копии работают нормально, и я сделал несколько восстановлений). Я использую bacula, который поддерживает это. За мои деньги, указатели для получения этого права включают в себя:

1) Ключ дешифрования хранится (в незашифрованном виде) на CD-R, а не в моей голове. Есть несколько копий CD-R, и ни одна из них не со мной. Мне нужно делать восстановление только раз в несколько месяцев, и, честно говоря, я бы, наверное, забыл пароль, который использовал редко. Это также означает, что моя безопасность не ограничена длиной запоминающейся парольной фразы.

2) ПО для резервного копирования уже должно это поддерживать; не начинайте взламывать это в своем любимом инструменте, потому что вы можете ошибиться, и вы не будете знать, пока не будет жизненно важно, чтобы он работал (то есть время восстановления).

3) У вас есть мнение о переворотах, но они могут испортить любую резервную копию. Я очищаю свои магнитные головки каждый раз, когда привод запрашивает их, поворачиваю ленты каждые несколько лет и, прежде всего, сохраняю много приращений. Если переворот действительно испортил вчерашний инкремент, я всегда могу вернуться к предыдущему, который спасет большую часть моей задницы.

4) Документируйте процедуру восстановления . Шифрование всегда усложняет ситуацию, особенно если все сделано хорошо, и вам не нужно заново открывать колесо, когда вы находитесь под давлением, чтобы вернуть базу данных учетных записей. Я написал короткий README с большим количеством деталей, которые очень специфичны для моей установки (настоящее пошаговое руководство, все явно указаны пути, и тому подобное), и он записан на те же компакт-диски, что и ключи дешифрования.

5) Прежде всего, проверьте это много . В любом случае, вы должны регулярно проверять свои восстановления, но как только вы сделали что-то умное, вы абсолютно уверены, что все работает так, как должно.

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

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

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

Как и при любом резервном копировании, вам необходимо обеспечить доступ к ресурсам, необходимым для восстановления данных, и периодически проверять / запускать тестовые восстановления.

Однако у вас гораздо больше шансов потерять ноутбук, чем сервер резервного копирования, поэтому, если ваши данные ценны, ваш первый порт захода должен решить, как защитить данные на ноутбуке. Это, вероятно, окажет большое влияние на ваш выбор способа защиты резервной копии.

У них есть свои преимущества и недостатки, как и у любого другого. Проблема с переворотами, разрушающими все ^1, может быть решена путем правильной проверки резервных копий и наличия нескольких копий (что всегда является хорошей идеей - одна на месте для быстрого восстановления и одна за пределами для целей аварийного восстановления) ).

Что касается преимуществ самого шифрования, то в действительности все сводится к тому, как плохо будет, если резервные копии будут украдены. Большинство компаний в наши дни имеют достаточно критически важных данных, поэтому стоит по крайней мере сделать пилотный проект (чтобы узнать о практических вопросах управления этим) и провести анализ ROI в целом.

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

Я использую rsync поверх ssh для резервного копирования 100 ГБ данных удаленного веб-сервера каждую ночь - для передачи различий и синхронизации локального зеркала требуется всего несколько минут. Тем не менее, это зависит от того, что адресат не зашифрован.

После получения данных они могут быть заархивированы с помощью tar, сжаты с помощью gzip (опционально протестированы с помощью gzip -t), а затем могут быть зашифрованы и переименованы с указанием даты и сохранены в рейд-системе. (Мне было проще хранить все это, чем возиться с инкрементами).

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

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

Вы можете обслуживать ключ через https с удаленного веб-сервера как функцию IP-адреса источника, поэтому, если система и резервные копии были украдены, вы все равно можете иметь некоторый контроль над ключом и своевременно отключить его.

Всегда храните несколько копий, локально и удаленно.