Представлен значительный выпуск СУБД immudb 1.0, гарантирующей неизменность и сохранение всех когда-либо добавленных данных, а также предоставляющей защиту от внесения изменений задним числом и дающей возможность криптографического доказательства владения данными. Изначально проект развивался как специализированное NoSQL-хранилище, манипулирующее данными в формате ключ/значение, но начиная с выпуска 1.0 immudb позиционируется как полноценная СУБД с поддержкой SQL. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55219
СУБД и искажение данных - оксюморон, имхо.
...и защита от*
сглаза?
Так прикольно же, повреждаем первую запись и вуаля - цепочка доверия прервана. Никакого злого умысла, что вы!
Очередное мы написали, патамучта учили Go, B-tree и нам было нужно показать преподу/идиоту-заказчику/начальнику-самодуру какие мы офигенные.
И что? Вы же будете знать, что данные повреждены и доверять им уже нельзя. В отличие от изменения обычных БД, где вы изменения записи не заметите.
Замечу при сравнении снап шотов.Решение подобных проблем лежит обычно в административной плоскости.
А с имму дб этой можно и хеш намайнить при желании.
Или просто всю базу пересобрать.Проэкт интересный в общем но сложно представить реальное применение.
> Замечу при сравнении снап шотов.Это как - при каждой операции чтения или записи нужно сравнивать сотни гигабайтов снапшотов?
> Это как - при каждой операции чтения или записи нужно сравнивать сотни
> гигабайтов снапшотов?Зачем при каждой? И зачем гигабайты?
Как именно зависит от конкретной задачи.
Обычно критичных к изменению данных не так и много, а злоумышленник получивший доступ к вашей базе и так что угодно может сотворить.
Как вот по вашему бухгалтера работают три тысячи лет без имутабельных баз на блокчейне?
А стандартным средством например является запись всех операций в лог который хранится отдельно от базы что как бы критично для безопасности.
Они тут фактически черезпопно совместили этот лог с бд что вот совсем не хорошо.
> критичных к изменению данных не так и многоВ Росреестре данные критичные к изменению?
Смотря кому их нужно изменять.
Думается мне как только вы внедрите эту базу в росреестр вас тут же уволят и объявят врагов народа и иностранным агентом.
А что, россреестр полезных сайтов не должен гарантировать сохранности перечней? Ещё бы неплохо записывать все доступы кто изменял и когда, в СГА например даже незаконные изменения протоколируются.
> В Росреестре данные критичные к изменению?В Росреестре многие проблемы не связаны с не_изменяемостью БД
Доходит до смешного - всевозможных прав собственности на землю суммарно по площади вдвое больше, чем той земли в РФ вообще имеется и происходит подобное ввиду разрозненности баз разных уровней и наложения разных участков друг на друга( что уже пахнет раздолбайством отдельных сотрудников )
> Проэкт интересный в общем но сложно представить реальное применение.Real world examples
We already learned about the following use cases from users:use immudb to immutably store every update to sensitive database fields (credit card or bank account data) of an existing application database
store CI/CD recipes in immudb to protect build and deployment pipelines
store public certificates in immudb
use immudb as an additional hash storage for digital objects checksums
store log streams (i. e. audit logs) tamperproofСами мы сомневаемся, зачем вам это, но снежинки сами за нас все придумали.
Впрочем, похоже, это расширение к постгресу. БД мы запилили, угу.
> Впрочем, похоже, это расширение к постгресу. БД мы запилили, угу.Был не прав. Запилили.
Ну то есть они изобрели аудит лог чтобы можно было хранить аудит лог в аудит логе.
> Ну то есть они изобрели аудит лог чтобы можно было хранить аудит
> лог в аудит логе.Скорее, это БД-версионник. До конца не прочухал, да и на го я не песатель. Криптозашита рута, дальше верификация записи через предыдущую, что ли, версию.
Ну т.е. для купли-продажи недвижки/машины/земли, наверное, применить можно. Осталось убедиться, что их tbtree не развалится от ближайшего лунного затмения. Ну и что нигде не накосячили с криптографией.
Дело в том, что, в задачах купли продажи, и вообще финансовых отношений, решается проблема доверия.
Блокчейн её решает путём распределения базы данных между всеми участниками сети.
В недвижимости решается через государственный реестр.
В каком-то другом бизнесе может решаться через хранение копий у совладельцев.Их бд защищает от частичного изменения данных но не защищает от полной замены базы. При этом делает невозможным восстановление повреждённой БД.
Это может быть полезным где-то, как я писал, но очень очень в каких то ну очень нишевых применениях.
Если я допустим хочу вести аудит своей БД я настрою трансляцию логов операций на пару независимых серверов.
И эта их чудо база, насколько я понимаю, чудесным образом при каждом чтении не считает полного кеша по всей истории изменений для записи. А значит на лету изменение данных не может детектировать.
Так а я о чем? Ну, в конце концов, можно всегда поглядеть, как люди делали, что бы в свлю очередь на те же грабли не наступить.
Тут уже есть комментаторы, мол, 3 миллиона скачек не может быть говном. Рейтинг, блин, а потом это, не дай бог, употреблять придется где-нибудь, да без вариантов соскочить.
ля ты крутой. даже не почитав о проекте уже прям диагнозы всем выписал ). выходит зря чуваки 3+ млн раз качали докер образ.
3 миллиона тараканов не могут ошибаться? Дихлофос лучшая еда для инсектойдов! Если не понравится, мы вернем вам деньги!
чукча не читатель...
это прикольно, да, взять два слова из разных контекстов и замесить это в псевдоумное заключение )
> Информация в immudb хранится с использование блокчейн-подобной структуры, гарантирующей целостность всей цепочки имеющихся записей и не позволяющей изменить уже сохранённые данные или подменить/вставить запись в историю транзакций.Интересно, а в новостях про Git так пишут? Там ведь тоже "блокчейн-подобная" структура, где каждый коммит содержит хэш родительских коммитов.
>> Информация в immudb хранится с использование блокчейн-подобной структуры, гарантирующей целостность всей цепочки имеющихся записей и не позволяющей изменить уже сохранённые данные или подменить/вставить запись в историю транзакций.
> Интересно, а в новостях про Git так пишут? Там ведь тоже "блокчейн-подобная"
> структура, где каждый коммит содержит хэш родительских коммитов.Git - это про работать, там и так все всё знают, кому надо. А тут считают количество скачиваний докер образов.
но ведь докер не предназначен для БД, которые "хранить вечно" (или около того).
или я чего-то не понимаю ?
> но ведь докер не предназначен для БД, которые "хранить вечно" (или около
> того).
> или я чего-то не понимаю ?Ну, вроде как маунты/волюмы есть персистентные. Зато образ можно с новой версией скачать, забубенить, убедиться, что не работает, откатиться на старый и увидеть, что с ним тоже больше не работает. БД в докере, ну, не знаю, надо девляпсов спросить.
В Гите-то легко можно отредактировать эти ссылки
Прикольная тема. В больших конторах может прижиться. В маленьких просто не поймут зачем все это.
В больших конторах и так петабайты бэкапов, зачем им весь любой мусор хранить?
Восстановление бэкапа занимает время -> простой -> убытки.
Конфликт с GDPR и возможность быть забытым.
Шериф и проблемы европейцев.
А российский майор будет доволен. Никто не забыт, ничто не забыто.
Вообще-то Россия це европа больше чем цеевропа (404) и в РФ данные удаляют по решению суда как минимум.
они где надо удаляются, а где надо - в папочку и на полочку, чтоб если начальник спросит - ты ему бумажку на стол, и ему приятно - и тебе премия
Нет, если ты хранишь например логи пользователя и его id-шник. Удаляешь из сервиса авторизации привязку фио и т.д. к id-шнику и это просто обезличенный лог.
Далеко не каждый data является personal data.
Чем это лучше биткоина?
> Чем это лучше биткоина?SQL? Postgres wire protocol?
Готовятся к эре дешевых но ненадёжных серверных комплектующих
Не вижу реальных примеров кому и зачем это может понадобится. Насыщение текста баззвордами - это не объяснение
Система обмена документами между разными организациями, с эл.подписями и прочим. Чтобы никто потом не отмазался, что документ не отправлял или чтобы никто потом задним числом записи в базе данных за взятку не исправил.
Каким образом это спасает? если у тебя есть электронная подпись, зачем вот это вот все?
>базе данных за взятку не исправилесли у тебя бд в единственном числе где ее можно исправить, у тебя уже проблемы.
> Каким образом это спасает?Вы новость читали? Как работает асимметричное шифрование, электронные подписи - представление имеете?
В статье ведь написано:
"предоставляющей защиту от внесения изменений задним числом и дающей возможность криптографического доказательства владения данными. "
...
"Клиентам и аудиторам предоставляется криптографическое доказательство владения и целостности данных. Применение криптографии по открытым ключам не требует от клиента доверия к серверу, а подключение каждого нового клиента к СУБД увеличивает общей уровень доверия ко всему хранилищу"До вас не дошло, что всё, что вносится клиентом, подписывается его приватным ключом? Что все цепочки блоков, как в блокчейне в криптовалютах, тоже уже не перемешаешь и не изменишь - они все подписаны и упорядочены? Единственное отличие от нынешнего среднего криптовалютного блокчейна - БД централизована.
> если у тебя есть электронная подпись, зачем вот это вот все?
Глупый вопрос. И что делать с этой электронной подписью? Просто по почте обмениваться подписанным? Потом днями в почтовике искать "тот самый нужный документ про окорочка, который совхоз "Красная заря" три года назад отправлял"? Может ты еще и SQL-запросы своему почтовому клиенту будешь посылать? Опять же - где (с простой почтой) доказательство того что почта доставлена или прочтена получателем, какая-нибудь заявка взята в работу? И ACID-транзакционно будешь с почтовым ящиком получателя работать? А тут ты можешь поверх этого организовать систему документооборота, с подтвержденями отправки, получения/прочтения, исполнения, всё это с электронными подписями клиентов, причем даже админы не смогут что-то там изменить - приватные ключи хранятся у клиентов, которые вносят данные. Можешь организовать центр обмена документами между разными организациями, в каждой из которых будет своя система документооборота и, к примеру, в контейнерах PKCS#7, CAdES через этот центр(шлюз) слать доки.
>>базе данных за взятку не исправил
> если у тебя бд в единственном числе где ее можно исправить, у тебя уже проблемы.Ага, как же. Пойдешь и возьмешь приватный ключ у клиента, исправишь и переподпишешь? Причем БД не позволяет исправлять, функционала такого нет, только добавляет. Но ты же кулхацкер - остановил БД, и напрямую на диске, даже минуя файловую систему, поменял байтик. Как ты думаешь, что там будет с достоверностью подписанных клиентскими приватными ключами блоков данных?
Не видишь потому, что твой кругозор сильно ограничен. И, может, ты ещё читать не умеешь. В новости есть некоторые примеры. Бухгалтерия (например, документы строгой отчётности, налоговой отчётности), финансы, государственные реестры, аптечные склады и так далее, и тому подобное.
И чем это лучше иных решений ?А то ведь можно сделать даже так, что в базу можно будет лишь добавлять новые записи( вместо удаления/изменения предыдущих ).. и это без особого напряга и без смены субд
Та бд, кстати, защищает лишь от замены отдельных элементов( и то, условно ). Что помешает при сильном желании по новой накатить всю базу с уже содержащимися в ней «поправками» ?
> Что помешает при сильном желании по новой накатить всю базу с уже содержащимися в ней «поправками» ?Вот что помешает (из статьи):
"предоставляющей защиту от внесения изменений задним числом и дающей возможность криптографического доказательства владения данными. "
...
"Клиентам и аудиторам предоставляется криптографическое доказательство владения и целостности данных. Применение криптографии по открытым ключам не требует от клиента доверия к серверу, а подключение каждого нового клиента к СУБД увеличивает общей уровень доверия ко всему хранилищу"т.е. тебе придется оббежать всех клиентов этой БД, попросить у них ("- На время, очень надо!") их приватные ключи, переподписать старые данные/транзакции в новом блок-чейне вместе со своей правочкой.
Можно сделать так, что и оббежать не получится, наверное. Добавить ещё данных от какого-нибудь биткоина?
Кому нужна база данных, где данные трудно заменить задним числом? Она же это делает, я правильно понимаю?
Ну много кому, даже некоторым людям домой, но вообще в государственный реестр продажи домов, например.
Сначала какая-то студота (ну а кто ещё падкий на NoSQL хайп??) пилит ОЧЕРЕДНУЮ "древобазу". Ну да, нам же мало десятка недопроектов, которые все страдают синдромом NIH!
Затем понимают, что "обычные запросы" никуда не делись и что "древовидность" базы вообще нахрен никому не упёрлась - люди по-прежнему используют тонны ОДНОТИПНЫХ данных. Ладно, прикручивают SQL (чему и остальные NoSQL-шники тоже вынужденно следуют). Тоже "нефичасто" - проект всё ещё нафиг не нужен.
"А давайте придумаем фишку!" - ну да, ну да, вы же Дональд Кнут, мозг ИТ! И не "придумывают" фишку, а тупо вкорячивают то, что и так доступно БЕЗ их недобазы - ПОДПИСЬ! Ну вот прям шокировали ветеранов ИТ!! :)))
А что, тупо в SQL добавить поле с подписью - религия не позволяет? Это и будет "защита от изменений"! Ни бог весть какая фича, да ещё и ПРИКЛАДНОГО характера (т.е. ей вообще нечего делать на системном уровне СУБД).Нда... обмельчала молодёжь - ничего путного, ничего нового.
Как всегда, интерфейс либо черное на белом, либо наоборот. Мамкины хацкеры более ни на что не способны
вот бы ещё при любом чтении базы состояние как-то менялось, чтобы понятно, что кто-то лазил