Управління шифруванням стрічок та найкращі практики

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

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

Мої запитання:

1. Як слід відстежувати, які стрічки мають шифрування? У мене вже є кілька сотень стрічок без шифрування. Навіть якщо я знайду час, щоб переписати їх усі для шифрування, будуть місяці перекриття, де деякі мають, а деякі ні. Як бакула дізнається, чи потрібно встановити ключ перед читанням заданої стрічки? Чи накопичувач достатньо розумний для читання незашифрованих стрічок, навіть коли ключ встановлений?
2. Якщо ключ коли-небудь порушений, нам доведеться його змінити, і ми матимемо ту ж проблему, що і №1.
3. Якщо ключ загублений, ми фактично втратили всі наші резервні копії. Як я можу це пом'якшити, не збільшуючи ризик його порушення?
4. Чи повинен ключ змінюватися регулярно? Раз на рік? Яка найкраща практика?
5. Як великі резервні системи ISV вирішують ці проблеми?

Дуже хороші запитання. Я теж хотів би бачити хороші відповіді від людей, які знають про це більше, ніж я. :-)

3 Якщо ключ загублений, ми фактично втратили всі наші резервні копії

Саме тому багато або більшість людей не використовують зашифровані резервні копії.

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

4 Чи слід регулярно змінювати ключ? Раз на рік? Яка найкраща практика?

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

Нарешті: я вважаю за краще все шифрування та обробку резервних копій в одній системі, тому є менший ризик відновлення не працювати. Під цим я маю на увазі використання вбудованого шифрування в програмному забезпеченні типу Retrospect або Backup Exec, а не шифруванні на рівні накопичувача.

Я використовую dm-crypt FS, шифруючи його довгою та сильною парольною фразою.

Щоб уникнути втрати парольної фрази, я написав її на запечатаному воском листі, відправив її у власність компанії, і він зберігав її у ящику безпеки.

Звичайно, ви можете віддати його нотаріусу, або що ви думаєте.

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

Вас, звичайно, можна катувати :)

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

Для запису я використовую Amanda Enterprise як резервне рішення, і я не використовую шифрування стрічки, яке воно надає, з тих самих причин, які ви згадуєте.

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

• Шифрування рідного режиму (іноді його називають встановленим і забутим). Цей метод контролює шифрування LTO4 з бібліотеки стрічкових накопичувачів. Є одна клавіша, яка встановлюється за допомогою інтерфейсу управління бібліотекою (Web GUO або панель управління оператора). Цей метод шифрує всі стрічки одним і тим самим ключем, і це негативно впливає на рівень безпеки.

• Програмне забезпечення на основі програмного шифрування зашифровує дані перед виходом із сервера, а ключі зберігаються у внутрішній базі даних або каталозі програми. Цей метод шифрування накладає велике навантаження на сервер, оскільки програмне забезпечення виконує багато математичних операцій, використовуючи потужність обробки хоста. Кілька програм, включаючи HP Open View Storage Data Protector 6.0, пропонують шифрування як особливість. Хоча безпека зашифрованих дат таким чином дуже висока (оскільки дані зашифровані під час транзиту), оскільки зашифровані дані є надзвичайно випадковими, тоді стає неможливим досягти стиснення даних нижче за потоком у стрічковому накопичувачі, а тому зберігання неефективне.

• Ключі, якими керує програма ISV, також відома як вбудоване управління ключами. Програмне забезпечення ISV постачає ключі та управляє ними, а Ultrium LTO4 Tape Drive виконує шифрування. Ключі будуть посилатися на дані, пов'язані з ключами, і зберігатимуться у внутрішній базі додатків. (Для підтримки цієї функції зверніться до вашого окремого постачальника програм резервного копіювання ISV).

• Вбудований пристрій шифрування перехоплює посилання Fiber Channel і шифрує дані під час польоту. Ці товари доступні у кількох постачальників, таких як Neoscale і Decru. Керування ключами здійснюється від жорсткого пристрою управління ключами. Цей метод не залежить від програмного забезпечення ISV та підтримує застарілі стрічкові накопичувачі та бібліотеки. Стиснення даних повинно виконуватись цими пристроями, оскільки стискання всередині магнітоли не можливе після шифрування.

• Перемикач тканини SAN з можливістю шифрування схожий на вбудований пристрій, але в комутатор вбудовано обладнання для шифрування.

• Пристрій керування ключами працює з бібліотеками корпоративних класів, такими як бібліотеки HP StorageWorks EML та ESL серії EL. Він відомий як позадіапазонне управління ключами, оскільки ключ подається на стрічковий привід пристроєм управління ключами. На малюнку 8 показані основні компоненти пристрою управління ключами. Програми резервного копіювання не знають про можливості шифрування стрічкового накопичувача. Клавіші надходять до контролера бібліотеки стрічок через мережеве з'єднання за допомогою шару захищених сокетів (SSL), нещодавно перейменованого на захист транспортного шару (TLS). Це зашифроване з'єднання, необхідне для захисту безпеки ключів, які перебувають у дорозі від пристрою. Для налаштування захисту в апаратне забезпечення бібліотеки встановлюється цифровий сертифікат. Це встановлює необхідне безпечне з'єднання. Налаштування SSL / TLS використовує шифрування відкритого ключа, але після закінчення рукостискання секретний ключ передається для шифрування посилання. Коли стрічки відновлюються, дані, пов'язані з ключем (отримані зі стрічки), використовуються для посилання на запит на правильний ключ для розшифрування стрічки незалежно від програми резервного копіювання.

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

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