Вирусы шифровальщики не первый год сотрясают ИТ общественность последствиями своей подпольной работы. Скрываясь за ссылкой в email или в JavaScript коде на странице веб сайта, они молчаливо инсталлируются на рабочие компьютеры или сервера и начинают тихо зашифровывать всю информацию. После окончания шифрования, некоторые просто удаляют ключ шифрования, а не которые требуют выкуп, но далеко не все заплатившие выкуп получают ключ шифрования. Как же с ними можно бороться? Самое главное средство борьбы – быть подготовленным к борьбе.
Резервное копирование
Как в самых больших, так и в маленьких организациях рабочие файлы располагают на общедоступном файловом хранилище, чтобы все могли ими пользоваться. Централизация хранения даёт удобство для совместной работы нескольким людям над одними и теми же файлами, но это налаживает и ответственность по защите такой информации. Естественно для борьбы с вирусами-шифровальщиками необходимо регулярно выполнять резервное копирование по схеме 3-2-1. Резервные копии важно хранить отдельно от основной системы. Но полное восстановление, во-первых, может быть достаточно длительным, а во-вторых резервное копирование как не крути выполняется не каждый час, и теряется вся новая информация (большой RPO).
Снепшоты для спасения
И вот здесь становится понятно на сколько важной частью резервного копирования являются снепшоты, которые можно выполнять на много чаще нежели резервные копии на NAS хранилище и соответственно восстанавливать такие данные на много быстрее из снепшотов, таким образом существенно уменьшив значение RPO. И вот здесь становится понятно на сколько важно, чтобы такие снепшоты функционировали как часы, не тормозили работу всего хранилища, не имели архитектурных проблем по удалению и консолидации снепшотов. При этом снепшоты это не замена резервному кодированию, а отличное дополнение для полноценной стратегии резервного копирования. Так снепшоты можно выполнять достаточно часто, чтобы захватывать самые последние изменения вашей информации. Снепшоты это не полная копия данных, только разница новых данных на блочном уровне, своего рода обратный инкрементальный бэкап, который более рационально использует пространство хранилища, нежели полный бэкап. Но всё равно это пространство используется, чем больше изменений, тем больше попадает информации в снепшот. Настроенное расписания авто-удаления старых снепшотов позволит более рационально использовать ресурсы хранилища и не съесть всё доступное пространство на дорогостоящем NAS хранилище. А резервное, будет хранить на много дольше по времени копии более старых версий информации.
Как снепшоты не должны работать
Многие уже сталкивались с различными реализациями снепшотов и уже на практике знают, как снепшоты не должны работать:
- они не должны увеличивать нагрузку на дисковую подсистему просто от наличия снепшота
- они не должны увеличивать нагрузку просто от большего числа снепшотов
- они должны быстро создаваться и удалиться и этот процесс не должен влиять на производительность дисковой подсистемы
- они должны удаляться так чтобы не повредить основные данные
- им не должно быть разницы сколько данных, всё должно работать быстро, моментально и без малейшей возможности повредить информацию из-за удаления или консолидации снепшота.
Снепшоты в операционной системе ONTAP для хранилищ NetApp так не работают. Они были впервые реализованы в операционной системе ONTAP, как часть файловой системы WAFL в 1993 году, эти технологии апробированы временим и сотнями тысяч компаний по всему миру. Кстати само слово «снепшот» (Snapshot ™) является зарегистрированной торговой маркой компании NetApp, а эта технология снепшотирования запатентована. Чтобы удостовериться в том, как работают снепшоты WAFL можно бесплатно скачать на тестовый период виртуальную машину с образом хранилища ONTAP.
mysupport.netapp.com/NOW/cgi-bin/software/?product=ONTAP+Select&platform=Deploy+Install
Автоматизация восстановления
Интеграция снепшотов хранилища с операционными системами позволит снять рутину с администратора хранилища по восстановлению отдельных файлов. Чтобы пользователи сами могли восстанавливать свои файлы из снепшотов прямо из своего компьютера стандартными срадствами ОС.
Репликация снепшотов
Просто удаление старых снепшотов, которые уже есть на хранилище и настроены в хорошо налаженной стратегии резервного копирования — это ужасная трата ресурсов. Ведь снепшоты можно использовать для их репликации на вторую систему хранения. Во-первых снепшоты уже есть, почему-бы их не использовать, во-вторых намного выгоднее передавать дельту нежели весь набор данных каждый раз, в третьих снепшоты работают на подобии обратных инкрементальных бэкапов, то есть не требуют времени на «склеивание в полный бэкап», в третьих снепшоты ONTAP подобны обратным инкрементальным бэкапам, но они не требуют склеивания или консолидации ни во время репликации ни во время восстановления, как это происходит с традиционными инкрементальным бэкапом или обратным инкрементальным бэкапом. Но магии не бывает, снепшоты при репликации данных всё равно вычитываются из целевой системы, чтобы быть отправленными на удалённую систему, это порождает дополнительные операции чтения во время реплики, но это на много лучше в сравнении с фулл-бэкапом, который каждый раз вычитывает заново все данные целиком.
Снепшоты как индикатор заражения Randsome
Как было сказано ранее снепшоты хранить в себе блочную дельту, разницу между предыдущим своим состоянием и между текущим, актуальным. И чем больше изменений внесено в актуальные данные, тем больше занимает снепшот. Кроме снепшотов стоит ещё упомянуть про технологии компрессии и дедупликации данных, которые позволяют сжимать оригинальные данные, экономя пространство на хранилище. Так вот некоторые данные не компрессируются и не жмутся. К примеру фото, видео или аудио данные, а какие данные ещё не жмутся? Правильно зашифрованные данные. И вот представьте вы настроили расписание снепшотов, у вас работает дедупликация и компрессия. Снепшоты снимаются, а более старые удаляются, данные жмутся, потребление пространства достаточно размеренное и стабильное. И вдруг снепшоты начинают занимать на много, на много больше нежели раньше, а дедуп и компрессия перестали показывать свою эффективность. Это и есть индикаторы молчаливой и вредоносной работы вируса-шифровальщика: ваши данные, во-первых, сильно изменяются (растут снепшоты в объёме, по сравнении юс тем как это было раньше), во-вторых дедуп и компрессия перестали давать результат (значит несжимаемая информация). Эти два косвенных показателя приводят к более не рациональному потреблению пространства на хранилище, и вы можете заметить это на графике потребления пространства, который внезапно начал геометрически расти вверх.
WORM
Технология Wright Once Read Many или WORM, таже известна и под другими названиями, к примеру SnapLock построенная на базе снепшотирования, позволяет залочить данные на длительный срок от изменений. К примеру можно хранить конфиги от разнообразных устройств, к примеру свичей, роутеров и прочее. Подобного рода файлы редко если вообще меняются в течении жизни устройства, а харнилища с поддержкой WORM надежное место для хранения фажных файлов-настроек для инфраструктуры.
Антивирусная защита NAS
Ну и конечно же возможность проверки файлов на строне хранилища тоже будет не лишней.
Вывод
Снепшоты это не замена, а важная часть стратегии резервного копирования, которая позволяют более быстро, более часто резервировать данные и быстрее их восстанавливать. Снепшоты WAFL являются базисом для репликации данных на резервную СХД, не тормозят систему, не требуют консолидации и склеивания, являются эффективным средством резервного копирования данных.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
ссылка на оригинал статьи https://habrahabr.ru/post/329746/
Добавить комментарий