Статья во многом опирается на опыт проекта Lots of Copies Keep Stuff Safe - «Множество копий гарантирует сохранность», см. http://dx.doi.org/10.1145/1047915.1047917 - это проект Стенфордского университета по созданию системы с открытым кодом, позволяющей библиотекам собирать, сохранять и предоставлять читателям доступ к материалам, опубликованным в Интернете. Как Розенталь отмечал в другом своём посте:
«Наш опыт эксплуатации одноранговых (peer-to-peer) сетей обеспечения сохранности различного размера в рамках программы LOCKSS позволил нам уверенно доверять способности этих сетей, при реалистичном уровне внимания оператора, обнаруживать повреждения и своевременного восстанавливать контент, при условии наличия 7 или более участников. По мере снижения числа участников необходимо повышать уровень внимания оператора, поэтому существует определенный компромисс между расходами на оборудование и на оплату труда сотрудников.»Фундаментальная проблема при разработке системы LOCKSS (от Lots of Copies Keep Stuff Safe - «Множество копий гарантирует сохранность», см. https://dl.acm.org/doi/10.1145/1047915.1047917 и https://dl.acm.org/doi/10.1145/1165389.945451 ) заключалась в аудите целостности многочисленных реплик контента, хранящихся в ненадежных, взаимно не доверяющих друг другу системах без загрузки всего контента:
- Многочисленные реплики (в нашем случае – очень большое их количество) появились вследствие нашего подхода к решению проблемы, связанной с тем, что академические журналы, для долговременной сохранности которых предназначалась система LOCKSS, были защищены авторским правом, и эти права принадлежат богатым, охотно затевающим судебные споры членам олигополии академических изданий (см. https://blog.dshr.org/2019/11/academic-publishers-as-parasites.html ). Мы решили эту проблему, настаивая на том, чтобы каждая библиотека сохраняла свою собственную копию того контента, на который она подписалась.
- Ненадежные, не доверяющие друг другу системы стали следствием этого подхода. Система каждой библиотеки должна быть настолько дешёвой в плане владения, администрирования и эксплуатации, насколько это возможно, с тем, чтобы удерживать совокупные затраты на систему на приемлемом уровне и поддерживать индивидуальные расходы каждой из библиотек ниже порога, который привлек бы внимание руководства. Так что ни оборудование, ни системное администрирование не будут особенно надёжными.
- Ещё одним следствием стал отказ от скачивания всего контента при аудите, по двум причинам. Скачивание контента с большого количества узлов в ходе каждого аудита будет медленным и дорогим. Но что ещё хуже, она, вероятно, стала бы нарушением авторских прав, что привело бы к уголовной ответственности в соответствии с американским законом DMCA (Digital Millennium Copyright Act, Public Law 105-304 of October 28, 1998, https://www.gpo.gov/fdsys/pkg/PLAW-105publ304/pdf/PLAW-105publ304.pdf – «Закон нового тысячелетия о защите авторских прав на электронный контент» - Н.Х.).
Наличие очень большого числа реплик имеет ключевое значение для работоспособности протокола LOCKSS, - но в более «нормальных» системах их не столь много по очевидным экономическим причинам. Примерно в то же время были разработаны системы аудита целостности, которые не нуждались в избытке реплик, включая работу Мехула Шаха (Mehul Shah) и др. (см. https://www.usenix.org/legacy/events/hotos07/tech/full_papers/shah/shah_html/ ); а также статью Джаджа (Jaja) и Суна (Song) (см. https://www.ingentaconnect.com/content/ist/ac/2007/00002007/00000001/art00022 ). Однако, - прежде всего потому, что неявно подразумеваемые модели угроз для большинства поставляемых архивных систем предполагали наличие надёжной инфраструктуры, - эти системы не получили широкого распространения. За пределами архивной отрасли в них не было потребности.
Спустя полтора десятилетия распространение облачного хранения (вмести с соответствующими рисками), привело к возобновлению интереса к этой проблеме. В статье Линь Янфей (Yangfei Lin) и др. «Схемы аудита целостности на основе использования многочисленных реплик для облачного хранения данных» (Multiple-replica integrity auditing schemes for cloud data storage, см. https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.5356 ) содержит полезный обзор текущего положения дел.
В аннотации данной статьи сказано следующее:
«Облачные вычисления являются ключевой технологией для предоставления вычислительных ресурсов по требованию, в качестве услуги в Интернете. Не только организации, но и частные лица могут передавать свои данные на аутсорсинг в облако, не беспокоясь о затратах на закупку и обслуживание.Системная архитектура
Облачная система хранения, однако, не является в полной мере доверенной. Аудит целостности данных в облаке имеет решающее значение для защиты от угроз безопасности в отношении данных в недоверенной многопользовательской среде. Хранение нескольких реплик является широко используемой стратегией обеспечения доступности и надежности критически-важных данных.
В данной статье мы даём обзор и анализируем современные схемы аудита целостности на основе использования нескольких реплик при облачном хранении данных. Мы описываем модель системы и угрозы безопасности при аутсорсинге данных в облако, вместе с классификацией текущих разработок. Мы также резюмируем существующие схемы аудита целостности данных для многооблачного хранения данных (multicloud data storage). Рассматриваются важные открытые вопросы и потенциальные направления дальнейших исследований.»
Существует три возможных системных архитектуры для аудита целостности нескольких реплик:
- Насколько я знаю, решение LOCKSS уникально тем, что оно использует настоящую одноранговую архитектуру, в рамках которой хранящие контент узлы проводят взаимный аудит друг друга;
- В другой возможной архитектуре аудит реплик осуществляет владелец данных (data owner, DO в обозначениях, используемых Линь Янфей и др.);
- Линь Янфей и др. в общем случае рассматривают архитектуру, в которой доверенная третья сторона осуществляет аудит реплик от имени владельца данных.
Существует два вида аудита:
- Аудит на основе «доказательства извлекаемости» (Proof-of-Retrievability, PoR) позволяет аудитору с очень высокой вероятностью утверждать, что в момент аудита проверяемая реплика существовала и каждый её бит был неповрежденным;
- Аудит на основе «доказательство владения» (Proof-of-Possession, PoP) позволяет аудитору с очень высокой вероятностью утверждать, что в момент аудита проверяемая реплика существовала, но не даёт возможности утверждать, что каждый её бит был неповреждённым. В статье используется аббревиатура PDP для «доказуемого владения данными» (Provable Data Possession).
Проведение аудита целостности необходимо по той причине, что системы хранения не являются ни надежными, ни заслуживающими доверия, особенно при больших масштабах. Некоторые системы аудита опираются на хранение токенов целостности, таких как хеши, в хранилище, которое приходится считать надёжным. Если хранилище токенов повреждено, факт порчи, вероятно, может быть обнаружен, однако восстановление может оказаться невозможным. Обычно предполагается, что, поскольку токены по объёму намного меньше того контента, целостность которого они подтверждают, то они, соответственно, более надёжны. При этом легко забыть, что и токены, и контент состоят из однотипных битов, и что даже системы хранения защищенные с помощью криптографического оборудования, имеют уязвимости (см. https://thehackernews.com/2019/11/tpm-encryption-keys-hacking.html ).
Зашифрованные реплики
Во многих приложениях облачного хранения важно обеспечить конфиденциальность данных посредством их шифрования. В контексте обеспечения долговременной сохранности, шифрование данных добавляет существенную единую точку отказа - потерю или повреждение ключа, и поэтому обычно не используется. Если же шифрование всё же используется, обычно желательно наличие каких-либо средств для обеспечения того, чтобы в зашифрованном виде реплики были разными, равно как и использование неподверженного изменениям, заслуживающего доверия хранилища для ключей дешифрования. В статье обсуждается возможность сделать это с помощью вероятностного шифрования (probabilistic encryption, см. https://en.wikipedia.org/wiki/Probabilistic_encryption , а также http://cryptowiki.net/index.php?title=Вероятностное_шифрование – Н.Х.) с использованием пар открытых / закрытых ключей или же с помощью симметричного шифрования с использованием случайного шума, добавляемого к подлежащим шифрованию данным.
Если реплики зашифрованы подобным образом, они не будут побитно-идентичными и, следовательно, их хеши будут отличаться независимо от того, остались ли они неповреждёнными или нет. Поэтому необходимо использовать алгоритм гомоморфного шифрования (homomorphic encryption, см. https://en.wikipedia.org/wiki/Homomorphic_encryption , а также https://ru.wikipedia.org/wiki/Гомоморфное_шифрование - Н.Х.) :
«Гомоморфное шифрование – это форма шифрования, дополнительно позволяющая производить определённые математические действия с зашифрованными данными без доступа к секретному ключу. Результат такого вычисления остается зашифрованным.»В разделе 3.3 своей статьи Линь Янфей и др. обсуждают две схемы аудита, основанные на гомоморфном шифровании:
- Гомоморфизм на основе алгоритма RSA;
- Гомоморфизм, основанный на алгоритме электронной подписи Бона-Линн-Шахи (Boneh-Lynn-Shacham, BLS, см. https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham , а также https://ru.wikipedia.org/wiki/BLS_подпись - Н.Х.).
(Окончание следует, см. https://rusrim.blogspot.com/2020/04/2.html )
Дэвид Розенталь (David Rosenthal)
Источник: DSHR's Blog
https://blog.dshr.org/2019/11/auditing-integrity-of-multiple-replicas.html
Комментариев нет:
Отправить комментарий