У меня есть несколько подключенных систем, и я рассматриваю возможность настройки отдельного сервера для инкрементного и полного резервного копирования.
Чтобы также предотвратить потерю всех систем/резервных копий в случае компрометации одной из них, я рассматриваю возможность создания своего рода Dropbox-хранилища с общим ресурсом только для записи, смонтированным на каждой системе, куда переносятся резервные копии.
Я имею в виду, что в случае атаки резервная копия может быть открыта или передана в пострадавшую систему через недавно созданный общий ресурс, доступный только для чтения, а затем восстановлена оттуда, но доступ к самой системе будет невозможен.
Один из наших конкурентов недавно потерял весь свой бизнес, потому что даже его резервные копии были подключены, и ему не из чего было восстанавливать данные.
Я также буду загружать полные резервные копии через соответствующие промежутки времени.
Пожалуйста, найдите дыры в моем плане.
Спасибо.
решение1
Пожалуйста, найдите дыры в моем плане.
Конечно. Только удаление чтения не избавит вас от проблем. Любая попытка изменения требует разрешения на запись. Злоумышленник затем все равно может записать файл пустым (ему нужно только знать, где находится файл).
Почему бы не заблокировать на этом диске все, что касается резервного копирования, за исключением добавления новых данных?
Возможная установка:
/backups/20160911/backup.tar.gz
/backups/20160912/backup.tar.gz
/backups/20160913/backup.tar.gz
Создайте сценарий, который делает
chattr -R +a /backups/
chattr -R +i /backups/*.tar.gz
+iозначает "неизменяемый"; ничего нельзя сделать с этими файлами или каталогами. Даже root не может изменить его (включая удаление, редактирование, запись, добавление новых файлов. Все, что угодно). Даже root должен удалить это (с помощью -i), прежде чем root сможет что-то сделать с этими файлами.
+aозначает "добавить"; Те же правила, что и -iс одним исключением. Никому не разрешено вносить какие-либо изменения в файл или каталогкроме добавления к нему. И еще: даже root должен удалить это (с помощью -a) перед тем, как файл или каталог можно будет изменить, если изменение не добавляет к нему ничего.
(выше может потребоваться некоторая настройка. 1 большой файл резервной копии может быть, эм, не лучшим подходом. Что-то с подкаталогами и файлом может быть лучше. Так что потребуется корректировка этих 2 строк: например, делать это ТОЛЬКО для старых каталогов и делать «сегодня» вручную, когда резервная копия будет сделана. Тогда это станет
chattr -R +i /backups/{not_today}
chattr -R +a /backups/{today}
Запускайте этот скрипт через определенные интервалы, чтобы в случае, если кто-то что-то изменит внутри, /backups/разрешения для всех резервных копий были сброшены.
Каталоги и файлы можно добавлять в "сегодня", а после того, как резервная копия будет сделана, можно вручную добавить +i. Создайте хороший пароль администратора, и никто, кроме администратора, не сможет тронуть эти файлы. Никогда.
Кстати: также рассмотрите возможность хранения резервных копий в сети. У нас есть резервные копии в нескольких экземплярах Google (у нас есть 3 живые системы на 3 континентах, которые делятся данными, каждая из которых создает резервный экземпляр на другом континенте, и каждая из них делит систему резервного копирования).
решение2
Снимите readразрешение с файлов или каталогов, которые вы хотите сделать нечитаемыми.
Разрешения следующие:
u - Owner
g - group
o - others
Отключите чтение для всех и разрешите запись всем, кому вы хотите предоставить доступ.
$ chmod -R ugo-r [path]
Каталог [path] и все его файлы и подкаталоги будут иметь этот атрибут. В данном случае -r(нет доступа для чтения).
решение3
Нет ничего более безопасного, чем отключенные резервные копии. Загрузите свои резервные копии на внешний диск и отключите его от сети после копирования на него резервной копии. Возьмите несколько дисков и чередуйте их.
Например, купите 5 дисков по 1 ТБ (общая стоимость < $300). Назначьте 3 из них для ежедневного резервного копирования; каждый день подключайте один и копируйте на него резервную копию, затем отключайте. Назначьте один для еженедельного резервного копирования и один для ежемесячного и сделайте то же самое.
Храните часть дисков в другом месте на случай пожара или кражи.
Такой подход защищает вас от множества различных угроз потери данных.
Если ваша система полностью серверная, используйте облачный эквивалент. Настройте несколько серверов у разных провайдеров (amazon, google, azure). Ежедневно подключайтесь к другому серверу и загружайте резервную копию на этот сервер по sftp, а затем отключайтесь. Сохраняйте несколько копий, чтобы не создавать резервную копию поверх хорошей копии.
Но нет ничего более неуязвимого для взлома, чем физическая копия, отключенная от сети и хранящаяся в удаленном месте.