Чи є зашифровані резервні копії гарною ідеєю?

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

Я це роблю, і це працює для мене (як і в, резервні копії працюють нормально, і я зробив кілька відновлень). Я використовую бакулу, яка її підтримує. На мої гроші вказівки на отримання цього права включають:

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

2) програмне забезпечення для резервного копіювання вже повинно підтримувати це; не починайте зламувати це у своєму улюбленому інструменті, тому що ви можете помилитися, і ви не будете знати, поки не важливо, що він працює (тобто відновити час).

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

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

5) Перш за все, багато тестуйте . У будь-якому випадку вам слід регулярно тестувати свої реставрації, але як тільки ви зробите щось таке розумне, стає абсолютно критично, що ви впевнені, що все працює так, як слід.

До плюсів, що випливають із цієї практики, належить не турбуватися, коли на зберіганні в інших місцях втрачається стрічка або дві, оскільки - вони лише люди - вони час від часу роблять це; надійно знищити старі стрічки легко (кинути у відро); і якщо всі мої файлові системи зашифровані на диску, це більше не підірвано, якщо у сусідньому пожежному сейфі стопку незашифрованих стрічок резервного копіювання.

але вони здаються впевненими, що шифрування - це погана ідея, оскільки один поганий біт може зруйнувати весь блок

Це не дуже вагома причина, щоб не використовувати шифрування. Те саме стосується більшості стислих резервних копій. Найкращим способом вирішити проблему було б використання файлової системи, що має толерантність до відмов (формати файлостійких файлів дуже тонкі на землі - здебільшого тому, що вони не мають справу з такою кількістю сценаріїв відмов, як файлосистеми, що мають стійкість до відмов).

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

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

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

Що стосується самих переваг шифрування, то це насправді зводиться до того, наскільки погано було б, якби резервні копії були вкрадені. У більшості компаній сьогодні є достатньо критично чутливих даних про те, що варто хоча б зробити пілотний проект (щоб дізнатися про практичні проблеми управління річчю) та зробити аналіз рентабельності інвестицій у цілому.

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

Я використовую rsync over ssh для резервного копіювання даних 100 Гб віддалених веб-серверів щовечора - для перенесення відмінностей та синхронізації локального дзеркала потрібно лише кілька хвилин. Однак це покладається на те, що пункт призначення не шифрується.

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

Якщо на рейдовому диску використовується зашифрована файлова система, додатково шифрувати резервні копії не повинно. Якщо накопичувачі викрадені, вони повинні залишатися нечитабельними, але якщо вони беруть всю систему і ключ доступний де завгодно, то це суперечка.

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

Ви можете обслуговувати ключ через https з віддаленого веб-сервера як функцію ip-адреси джерела, таким чином, якщо система та резервні копії були вкрадені, ви все одно можете мати деякий контроль над ключем і можете вчасно відключити його.

Завжди зберігайте кілька копій, локально та віддалено.