(Окончание, начало см. http://rusrim.blogspot.ru/2017/08/1.html )
RAID-массив
Зеркалирование диска также известно как RAID 1. RAID N где N> 1 - это способ защиты данных от сбоев диска с использованием коэффициента репликации менее двух. Блоки дисков организованы в виде полос из S блоков. Каждая полоса содержит D блоков данных и P блоков четности, где D + P = S. Данные могут быть восстановлены из любых D блоков, поэтому RAID-массив может выдержать P ошибок без потери данных. Например, если D = 4 и P = 1, данные будут защищены на случай утраты одного из дисков при коэффициенте репликации 1,25.
Сам по себе RAID-массив не обеспечивает защиту от деградации битов (bit-rot). Некоторые RAID-системы поддерживают возможность «отчистки» данных (data scrubbing). Если эта опция включена, то в RAID-системе используется фоновая задача для выявления отдельных плохих блоков и их исправления - до того, как они будут обнаружены в результате операции чтения пользователем. Отчистка данных может предотвратить некоторые формы деградации битов, как правило, за счет некоторого снижения производительности. Насколько известно, эта возможность редко используется на практике.
Поскольку, однако, контент по-прежнему виден в одной файловой системе, любая компрометация системы, например, из-за заражения вирусом-вымогателем, создает риск полной утраты данных. Ввиду того, что емкость дисков увеличилась, однако скорость передачи данных с диска и количество операций записи до выхода из строя (unrecoverable bit error rate, UBER) не увеличились пропорционально, - время, необходимое оператору после того, как он заметил сбой диска, на заполнение заменяющего диска, и объёмы передаваемых данных означают, что RAID с одинарным контролем четности (S-D = P = 1) уже не является жизнеспособным.
Использование «кодов избыточности» (Erasure Coding)
RAID - это тоже форма «erasure coding», однако более продвинутые системы (такие, как IBM Cleversafe) используют коды избыточности для размещения контента на множестве систем в сети, а не на нескольких дисках в системе. Данный подход может значительно снизить корреляцию между сбоями носителей информации. Поскольку программные приложения видят хранилище такого рода как файловую систему, оно не защищает от вирусов-вымогателей и иных видов компрометации прикладной системы.
Два независимых экземпляра
Почему ни один из вышеперечисленных подходов не защищает от криптовымогательства? Причина в том, что ни один из них не обеспечивает независимых реплик данных. В каждой системе имеется единая точка, из которой вирус может зашифровать все копии.
Предположим, что в архиве поддерживаются две независимые копии - независимые в том смысле, что они географически-удалены друг от друга и являются отдельными в сетевом плане и в плане администрирования. Никто не имеет прав доступа к обеим копиям. Хотя оба экземпляра, возможно, первоначально были сформированы из одного источника, нет такого места, из которого впоследствии можно писать или выполнять удаление на обеих копиях. Теперь вирусу-вымогателю нужно заразить обе копии почти одновременно, до того, как операторы заметят неладное и отключат второй экземпляр от сети.
Три независимых экземпляра
Сами по себе две независимые копии не защищают от более «тонких» видов порчи, чем шифрование всего и вся. Часто предполагается, что хранение хешей вместе с данными позволит выявить и устранить повреждения, но это не так. Как я писал в посте «Алгоритм хеширования SHA-1 мёртв» (SHA-1 is Dead, http://blog.dshr.org/2017/03/sha1-is-dead.html ):
«Есть два возможных результата перевычисления хеша контента и его сравнения с сохраненным хешем:Если, например, злоумышленник изменит как данные, так и хеш на одной из двух реплик, то у архива будут две разные версии, каждая из которых удовлетворяет хеш-проверке. Какая из них правильная? С тремя независимыми копиями на этот вопрос можно дать ответ путем голосования, в котором реплики будут голосовать за правильный вариант.
Сохраненные хеши записаны битами такого же качества, что и контент, целостность которого они должны защищать. Биты хешей подвержены тем же угрозам, что и биты контента.»
- Два хеша совпадают, и в этом случае:
- Хеш и контент не изменились, или
- Злоумышленник изменил как контент, так и хеш, или
- Злоумышленник заменил контент на коллизию (другой электронный объект, имеющий тот же хеш – Н.Х.), оставив хеш без изменений.
- Два хеша различаются, и в этом случае:
- Контент изменилось, а хеш – нет, или
- Хеш изменился, а контент - нет, или
- Изменились и контент, и хеш.
В качестве альтернативы методы, основанные на группировке хешей в древовидные структуры (дерево Меркла - Merkle Trees), могут быть использованы для определения того, какой хеш был изменен. Они взаимосвязаны, но гораздо дешевле, чем технологии «блокчейн», применяемые для той же цели. Проблема в том, что дерево Меркла становится критически-важным ресурсом, который в свою очередь необходимо сохранять с помощью нескольких независимых копий (и в результате необходимые обновления становятся хитрым делом). Если вирус-вымогатель сможет зашифровать его, то система не сможет гарантировать целостность контента.
Четыре независимых экземпляра
Если одна из трех независимых копий недоступна, то процесс голосования не работает. Четыре независимых копии - это минимальное количество, позволяющее системе выдержать отказ одной из копии.
Множество независимых копий
Как и в случае с дисками, оказалось, что сбои вроде бы независимых копий коррелируют друг с другом. Также выяснилось, что архивы, которые не могут себе позволить многочисленный персонал, часто с большим запаздыванием замечают и медленно реагируют на проблемы, что удлиняет периоды неработоспособности копий. Оба фактора делают более вероятным недоступность более чем одной копии в момент, когда они будут нужны для выявления и восстановления повреждений.
Резервное копирование на магнитные ленты
Традиционным способом резервного копирования данных было циклическое копирование на магнитные ленты. Если всё чрезмерно упростить, допустим, что цикл был недельным. Каждый день записывались бы резервные копии данных, затирая ранее записанную информацию, на ленту того же дня с предыдущей недели. Коэффициент репликации 7 был возможен лишь потому, что лента была очень дешевой по сравнению с диском. При использовании этого традиционного подхода, вирусу-вымогателю нужно было бы вести себя намного умнее. Ему нужно было бы перехватывать резервные копии и шифровать их во время их изготовления, одновременно откладывая шифрование самого диска до завершения полного цикла резервного копирования.
На практике все может быть куда сложнее. Запись на ленту происходит медленно, а лента не так уж сильно дешевле диска, поэтому используются сложные циклы, в которых чередуется создание полных и инкрементных резервных копий. Базовое программное обеспечение для криптовымогательства вряд ли будет в курсе таких деталей, поэтому ему не удастся уничтожить все резервные копии. Восстановление, однако, очень медленный и подверженный ошибкам процесс, который вряд ли восстановит все данные.
Резервное копирование на носители однократной записи
Прекрасным способом защиты от криптовымогательства и многих других угроз (таких как «корональный выброс массы», coronal mass ejections, см. http://blog.dshr.org/2014/07/coronal-mass-ejections.html ) - это резервирование данных на оптических носителях однократной записи. Кестутис Патеюнас (Kestutis Patiejunas) сделал такую систему для Facebook, и она введена в промышленную эксплуатацию. Однако мало у каких архивов (если такие вообще есть) масштаб деятельности достаточен для того, чтобы такого рода системы были экономически эффективными.
Как всё это связано с LOCKSS?
Ничто из сказанного выше не является специфическим для технологии LOCKSS; все это относится к любой технологии, используемой архивом. Система LOCKSS была разработана для того, чтобы справляться с широким спектром угроз. Первоначально она была описана в публикации 2005 года ( http://dx.doi.org/10.1045/november2005-rosenthal ), и более детально проработана для аудита 2014 года на соответствие требованияTRAC архива CLOCKSS Archive ( https://documents.clockss.org/index.php?title=CLOCKSS:_Threats_and_Mitigations ).
Мой комментарий: Руководство «Аудит и сертификация доверенных хранилищ: Критерии и контрольный список» (Trustworthy Repositories Audit and Certification: Criteria and Checklist, TRAC) было разработано американским Центром научно-исследовательских библиотек (Center for Research Libraries, CRL) в 2007 году, см. http://www.crl.edu/sites/default/files/attachments/pages/trac_0.pdf , с участием и при финансовой поддержке Национальных Архивов США (NARA).
Хотя в этих моделях угроз отдельно не упоминается криптовымогательство, которое три года тому назад не считалось особенно большой угрозой, они включают внешнюю атаку, внутреннюю атаку и ошибку оператора. Все три угрозы имеют схожие характеристики с криптовымогательством.
Таким образом, протокол опроса и восстановления системы LOCKSS (LOCKSS Polling and Repair Protocol) - инструмент, с помощью которого равноправные участники сети LOCKSS обнаруживают и восстанавливают повреждения, такие, как шифрование вирусом-вымогателем, - было разработано для работы при наличии не менее 4 копий. Нереалистично ожидать, что все копии всегда будут доступны при необходимости; так что, как и при использовании любой другой технологии обеспечения сохранности, 4 - это минимум для безопасности.
Наш опыт эксплуатации одноранговых (peer-to-peer) сетей обеспечения сохранности различного размера в рамках программы LOCKSS позволил нам уверенно доверять способности этих сетей, при реалистичном уровне внимания оператора, обнаруживать повреждения и своевременного восстанавливать контент, при условии наличия 7 или более участников. По мере снижения числа участников необходимо повышать уровень внимания оператора, поэтому существует определенный компромисс между расходами на оборудование и на оплату труда сотрудников.
Дэвид Розенталь (David Rosenthal)
Источник: DSHR's Blog
http://blog.dshr.org/2017/07/archive-vs-ransomware.html
Полезно очень.
ОтветитьУдалить