Забезпечте резервне копіювання за межами сайтів, навіть у випадку доступу до коріння хакера

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

Я вже спробував два способи резервного копіювання за межами сайтів:

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

• Резервне копіювання Borg через SSH з аутентифікацією ключа. Проблема : підключення до цього зовнішнього сервера можна здійснити за допомогою ключа, який зберігається на хості, якщо шкідливий користувач має кореневий доступ до хоста.

Як рішення я думаю про ці потенційні способи, але не знаю, як і з чим:

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

Рішення, які не дуже цікаві в моїй ситуації:

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

Хто-небудь може дати пораду, як реалізувати правильну резервну копію для мого випадку?

Наразі всі ваші пропозиції мають одне спільне: джерело резервного копіювання робить резервне копіювання та має доступ до місця резервного копіювання. Незалежно від того, чи встановлюєте ви розташування або використовуєте такі інструменти, як SSH чи rsync, вихідна система якось має доступ до резервної копії. Тому компроміс на сервері може також скомпрометувати ваші резервні копії.

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

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

Незмінне зберігання

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

Є кілька служб, які можуть зробити це за вас. AWS S3, BackBlaze B2, і я підозрюю, що Azure та Google пропонують подібну послугу. Можливо, ви могли б налаштувати сервер для цього, але я не знаю як.

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

* AWS S3 **

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

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

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

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

Пропоноване програмне забезпечення

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

Борг - ще один варіант. Раніше я використовував Borg, але я виявив, що завдяки моїм резервним копіям середнього розміру в сотні МБ він ефективно завантажував усі мої дані щодня з EC2 до S3. Для мене це не поступово, тому я перестав його використовувати. Я знайшов документацію на це, але не маю посилання.

Є десятки програм, які можна завантажувати у хмарний сховище.

Захищене зберігання

За допомогою програмного забезпечення для резервного копіювання ви можете спробувати дати дозволу користувачу IAM писати нові файли, але не оновлювати існуючі файли. Зробити це обмеження легко AWS IAM, але відповідно до коментаря нижче Restic не буде працювати з цими дозволами. Ви також можете мати багатофакторну автентифікацію, необхідну для видалення файлів із S3.

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

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

Рішення, які не дуже цікаві в моїй ситуації:

Додаткова робота із резервного копіювання на хості за межами сайту, яка передає їх у місце, яке не є доступним першим хостом.

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

(Через технічне обмеження)

Технічні обмеження зроблені для подолання.

Хто-небудь може дати пораду, як реалізувати правильну резервну копію для мого випадку?

Стрічкові накопичувачі майже 70 років забезпечують захищений захист від різного роду катастроф - включаючи хакери.

Ви можете користуватися послугами зберігання даних, такими як AWS S3 (або, можливо, еквівалент Google або Azure), де ви можете надати вашому кошику дозволи PUT для кореневого облікового запису, але не видалити дозволи. Таким чином, ви можете використовувати модель push і зловмисник не зможе видалити резервну копію.

Є інші заходи безпеки, які ви можете вжити з AWS, наприклад, вимагати, щоб MFA виконував DELETE на відро, але дозволяти PUTs і GETs без MFA. Таким чином, ви можете як створити резервну копію даних, так і отримати їх для відновлення своїх послуг, не використовуючи пристрій MFA, що може бути корисним у надзвичайному (і, мабуть, занадто незрозумілому, щоб навіть згадати), коли доступ до пристрою MFA може поставити під загрозу.

Крім того, за межами коментаря, який може бути цікавим / корисним, існує декілька способів налаштування S3 та подібних служб для автоматичного відмови в разі відсутності основного джерела даних.

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

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

як додати команди в ssh санкціонованих_кейдів

Навіть якщо зловмисник відновить корінь входу, він не зможе виконати нічого, крім визначеної команди.

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