Комментарии 20
Я что хочу сказать. Уязвимости не появляются на пустом месте. Они следствия попыток сэкономить на IT.
Но самые большие проблемы фирмам принесли именно вышедшие из строя сервера.
Поверьте я знаю о чем говорю, всю неделю без выходных и отдыха езжу по заказчикам ;)
Все привыкли ставить пиратское ПО из-за этого все привыкли что ИТ это дешево. Соответственно бюджетов на ИТ нормальных не выделяется и мы имеем то что имеем сейчас. Кстати из-за этого же недооценённые и сами ИТшники. Нужно объяснять бизнесу что ИТ — «это не дешево» и «это не то место, где можно экономить».
Я как-то писал статью, в которой разбирал основные проблемы современного резервного копирования. Главная из них, что время восстановления — это некая функция от объема данных и главная задача — разорвать это отношение. И сделать это можно только 2-мя способами:
- Использовать быстро-производимые и -разворачиваемые копии (например, снепшоты)
- Использовать уже работающие копии с возможностью отката (Oracle Standby с FlashBack, различные CDP)
Но с шифровальщиками все несколько сложнее. Если защищаться от него снепшотом — то нужно заложить как минимум 2х кратный объем на СХД (при полной перезаписи снепшот будет занимать объем, равный исходному тому)
Но с технологией FabricPool снэпшоты смещаются с SSD накопителей на дешевое хранилище S3. Так что даже с вирусами-шифровальщиками снэпшоты не проблема. Так что с FabricPool снэпшоты сам доктор прописал.
Как показывает практика, нужно защищаться:
- И программными средствами (типа Standby/ZDLRA/Continuous Data Protection/FlashBack)
- И снэпшотами (а по хорошему ещё нужно делать реплики этих снепшотов на резервную СХД, на которой из тонких клонов тестировать эти отреплицированные снэпшоты на восстанавливаемость).
Одно другого не отменяет, а дополняет, это видно даже по приведённым примерам в статье:
- Потому что, если просто иметь Standby то повреждённые данные могут отреплицироваться на запасную площадку.
- Полное восстановление из логов или фулл/инкрементов слишком долгое
- А сами по себе снэпшоты они теоретически могут быть подвержены скрытым повреждениям на СХД (хотя на практике с NetApp FAS такого не встречал, но теоретически может быть).
Так что мало того, что по-хорошему, нужно иметь
- Standby/ZDLRA/Continuous Data Protection/FlashBack
- так нужны ещё на этих же системах и снэпы
Чтобы быть готовым к тому, что если первый метод вовсе не сработает или восстановление по нему будет слишком долгое, тогда откатиться быстрее по второму методу и потом накатить изменения из логов по тому же первому методу (если получиться).
http://bit.ly/NetApp-against-ransomware-slides
А если речь не о системе для организации (где ценность и объём данных оправдывают достаточно дорогую систему защиты), а о домашнем применении — можете что-то посоветовать?
Мои мысли бродят в направлении линуксовой машинки + rsnapshot + (возможно) zfs. С запуском бэкапа со стороны этой машинки — чтобы рабочая машина вообще не имела к диску с бэкапами доступа на запись. Ну или ещё какими хитростями — лишь бы не давать доступа на запись к старым снепшотам.
Хотя предпочёл бы готовый NAS, умеющий всё нужное...
Там можно хранить файловую шару и даже запускать ОС с iSCSI.
При большем желании можно написать простую интеграцию для снятия снэпшота по каким-то событиям, к примеру выключение ОС.
Спасибо.
Чтоб не искать (если помните) — на каком уровне nas4free "из коробки" обеспечивает функционал вида "снэпшоты неприкосновенны"? Запуск rsync server под chroot?
Не понял на счёт rsync. У ZFS/NAS4Free есть свой собственный механизм репликации на вторую NAS4free/ZFS.
Ну, если из коробки нет — понятно, что можно настроить, по крайней мере, в достаточной степени (r/w доступ к папке, куда бэкапимся, r/o к снэпшотам.
Насчёт rsync — я про бэкап рабочей машины на nas в стиле http://www.mikerubel.org/computers/rsync_snapshots/ (на zfs получится лучше, конечно)
Не гонять же по сети все данные?
А можно просто подключить iSCSI лун с NAS4Free и снимать снэп с этого луна прямо на хранилище, тогда по сети вообще ничего гонять rsync»ом не нужно, но тогда нужно как-до добиваться консистентности, если на этом луне будут жить не просто файлы.
Самый простой способ достичь консистентности это выкючить комп и снять снэпшот луна на ZFS.
Дома девайсы (ноут, пк и несколько HD-плееров) используют встроенный накопитель только для ос. Все данные на NAS через SMB. В ZFS создано 2 датасета:
— зеркало на WD Red, для документов, фото, хоумвидео (все что жалко потерять), включены снапшоты.
— страйп (2 диска последовательно) — для торрентов и что не жалко потерять.
На NAS также работает и Transmission.
В оффисе:
Кластерок из 3 нод. Одна нода полноценный сервер (12 ядер, 48 Гб ОЗУ), две обычных пк Core i5 16 Гб ОЗУ. В принципе все виртуальные машины помещаются с запасом на основном сервере, но если с ним нужно провести какие либо работы, вм распределяются (онлайн-миграция) по другим нодам.
Диски вм и домашние папки пользователен на хранятся на двух NAS. В каждом 2 SSD для дисков вм и 2 hdd для данных пользователей, бэкапов и реплик с других NAS.
Каждый NAS реплицирует свои данные хотя-бы на один другой. Что куда реплицировать можно настроить индивидуально. Например датасеты с образами вм реплицируются каждые пять минут между NASами в офисе, и раз в сутки еще и на нас дома (можно и чаще но особого смысла нет, это удаленный бэкап на случай украли\изъяли сервера).
Практически все настраивается из веб-интерфейса Freenas, только очистку от старых снапшотов делал через скрипт в croon. Freenas не удаляет автоматически снапшоты, получившиеся в процессе репликации.
Бюджетная и вполне удовлетворяющая мои потребности конфигурация. Дома Freenas уже года как 3 использую. На работе около года. Пока никаких проблем. Но Freenas надо обновлять осторожно, часто любят поломать, что раньше работало.
Например, .doc файлы должен изменять winword.exe и никто другой.
Как защитить корпоративное хранилище от вирусов-шифровальщиков снэпшотами