Зашифровані резервні копії на місці - де зберігати ключ шифрування?

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

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

Питання: Яка найкраща політика для зберігання ключа шифрування за межами сайту?

Який би метод ми не обрали, потрібно пройти аудит безпеки, тому "зберігати копію вдома" не є адекватною, а "зберігати її за межами стрічок" очевидно перемагає мета шифрування їх в першу чергу! Кілька варіантів, які ми розглядаємо, включають:

• Сейф у банку
• Зберігається в хмарі або в географічно окремій мережі в захищеній паролем формі (наприклад, використовуючи програмне забезпечення, наприклад Keepass або Password Safe)

Звичайно, другий варіант ставить ще одне питання: як ми збережемо цей пароль у безпеці.

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

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

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

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

Редагувати:

Швидкий пошук знайшов sharesecret , реалізацію порогової схеми GPL.

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

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

Практичне рішення:

Створіть приватний ключ ssh на 4096 біт на USB-накопичувачі. потім створіть сильно зашифрований контейнер файлів за допомогою truecrypt і використовуйте ключ ssh як "keyfile", тобто зашифрований диск розблокується з файлом ключа ssh. Встановіть контейнер для файлів як розділ та створіть на ньому файлову систему (тобто mkfs.ext4.) Змонтуйте розділ та напишіть файл пароля, який ви хочете заархівувати. Демонтуйте все та надішліть свій ключ USB разом із архівними стрічками. Створений вами контейнер файлів ви можете (досить безпечно) помістити в обліковий запис операційної системи, на дискету (хто серйозно на нього подивиться?) І т. Д. По суті, без файлу ключів неможливо отримати доступ до резервної копії , а збережений за межами веб-сайту ключовий файл марний без шифрованого розділу, який ви зберігаєте ... куди завгодно.

Це може здатися складним рішенням, але, можливо, це направить вас у правильному напрямку. Як альтернатива, може бути достатньо зашифрованої флешки.

https://www.ironkey.com/

http://www.pcworld.com/article/254816/the_best_encrypted_flash_drives.html

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

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

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

Ніхто більше не може отримати парольну фразу тощо, поки ми це перевірили, і є додаткова проблема / відповідь, коли ми перевіряємо. Система розміщена в зовсім іншому місці.

Будучи великою організацією, це було вартістю витрат, але там можуть бути продукти, які можуть зробити подібну діяльність.

Нічого собі сейфи, адвокати та інші складні методи у цій темі. Все абсолютно непотрібно.

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

SpiderOak хороший тим, що для доступу до даних вам потрібно лише ім’я користувача та пароль. Він також сильно зашифрований. Це також більш безпечно, ніж DropBox, оскільки вони не зберігають ключі шифрування / дешифрування і не знають, що ваші дані, і не мають можливості доступу до ваших даних у вашому обліковому записі. DropBox, однак, відкритий для своїх співробітників або уряду США для доступу до даних з ордером. Якщо ви збираєтеся з DropBox, вам потрібно буде вкласти ключ у файл KeyPass і запам'ятати пароль, щоб також отримати доступ до цього.

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