Про существование не в курсе. Но теоретически, мне кажется, что это осуществимо. Если прикрутить какой-то таймер, который будет отсчитывать каждый раз вручную сутки и сравнивать с системным временем. Если по какой-то причине системное время не меняется на протяжении суток (т.е. дата, допустим, остаётся 21 июня, хотя уже должно быть 22), то блокируется запись в БД.

Аналогично, после того, как 21 июня заканчивается, делается где-то особая пометка, и после этого в БД нельзя внести информацию к дате 21 июня.

Как-то так, ИМХО. Поправьте, если неправ - я пока много чего не понимаю.

Посмотри как работает цепь блоков bitcoin и реализуй тоже самое у себя. :)
Но есть один момент: работать будет только при условии если данные записываются единожды и никогда не меняются.

В принципе git работает так же, там все комиты идут последовательно, а потому каждый новый завязан на старые, и если один подменить то это сразу же вскроется.

Ну ты предлогаешь бредовый вариант, когда есть способ с контрольными суммами который уже работает.
Но его все равно реализовывать придется поверх БД, т.к вряд ли такие есть.

Ну я тоже чуток бред написал:
Грубо говоря изменения могут быть, но они должны быть эдаким «коммитом».
Т.е должны не заменять старую запись в БД, а либо создавать новую ревизию записи, либо же быть как патч коммит в гите.

Ну ты предлогаешь бредовый вариант, когда есть способ с контрольными суммами который уже работает.

Вполне возможно. Мне показался более логичным мой вариант.

А так да, реализовывать скорее всего придётся поверх.

Мм. Тогда можно сверять коммиты с датой, и по прошествии 24 часов запрещать коммиты, или оставлять их висеть отдельно.

Только мне почему-то кажется, что такой подход очень сильно просадит производительность.

Такое можно сделать на базах, которые целиком поднимаются из transcaction log'а (вроде redis в режиме append only file), либо у которые хранят readonly снапшоты старых сегментов (leveldb, cassandra, + то что построено на lucene, плюс еще возможно hbase).

В любом случае чтобы оно быстро работало придется иногда опитимизировать структуры, отказываясь на время оптимизации от гарантии неизменяемости. Иначе оно будет или медленно подниматься после рестарта (в первом случае), или медленно читать (во втором).

Да ладно, лукавит Линус!

В этом мире нет ничего, кроме смерти, чего нельзя было бы сделать «задним числом».

Можно-то оно можно...

Но где гарантия, что злоумышленник не делает форк базы (вместе с логами, подписями и прочей обвязкой) каждые 10 минут. А потом внесет изменения оттолкнувшись от последней копии сделанной до момента в который его надо внести. Ну и естественно накатит все остальные изменения пользуюсь последним логом.

Есть ли что-то подобное для баз данных: такая технология, чтобы любое изменение протоколировалось-подписывалось, да так, чтобы нельзя было подделать записи ЗАДНИМ ЧИСЛОМ?

Алгоритмы существуют, рассматриваются в дисциплине «криптографическая защита данных». Если каждый блок данных подписывается с использованием своих данных и данных всех предыдущих блоков. Ничего сложного, в принципе.

H0 - вектор инициализации.

T1 - первый блок данных, в базу пишем (T1,H1), Н1=Hash(T1+H0).

T2 - второй блок данных, в базу пишем (T2+H2), H2=Hash(T2+H1)=Hash(T2+Hash(T1+H0))

Каждый блок данных включает в себя дату и время, задача только заблокировать возможность корректировки хэша (не важно каким способом).

Так что задача давно решена, те кому надо давно эти алгоритмы освоили.

Ну так подписывать каждую транзакцию. Или подразумевается, что вместе с базой можно и закрытый ключ утянуть?

вместе с логами, подписями и прочей обвязкой

Не надо таких костылей. БД стоит на специализированном сервере, у неё время синхронизируется. Просто подписывайте сообщение вместе с временем и автором правки.

Зачастую важна даже не правка задним числом, а правка посторонними людьми. Достаточно той же аутентификации на открытых ключах.

Любое изменение в базе должно быть только результатом транзакции. Откуда злоумышленник узнает закрытые ключи юзеров, чтобы накатить изменения?

регулярный бэкап на read-only носители, носители хранить в физически защищенном месте (сейф, хранилище с пулемётными турелями на входе и минами-ловушками)

БД стоит на специализированном сервере, у неё время синхронизируется.

А разве это не оставляет вероятности изменить дату на какое-то время (даже если ntp синхронизирует время каждый час, то у злоумышленника есть до 1 часа на то, чтобы внести изменения)? Т.е. как минимум должно быть ещё что-то (ключи улучшат ситуацию, но вероятность всё равно остаётся).

Выше уже предлагали скреплять последовательно транзакции. В любом случае, чтобы провести любую атаку, понадобится иметь ключи одного из пользователей, по которым при должном усердии можно будет отследить изменения.

Условия таковы

Условия предполагают, что серверу БД имеет доступ злоумышленник, который может делать с ним всё, что захочет, но чтобы пользователям казалось, что всё в так и было.

Похоже, здесь подходит что-то типа «всех не подкупишь»: копии БД хранятся у N-ого количества людей, СУБД работает только если все копии идентичны. (Периоды сверки, синхронизация реализуется сама собой.)

СУБД работает только если все копии идентичны

Атака проводится захватом и изменением любой из копий. Такая БД будет больше лежать, чем работать.

В общем, в сторону византийского соглашения смотрите насчёт синхронизации.

Это всё для борьбы с коррупцией...

Концепция:
1) все действия чиновника и общение с его пользователями отражаются в БД;
2) исходя из этого (того, как хорошо работает) общество назначает ему зарплату;
3) записи в БД должны быть неподделываемы.

Как-то бредовенько звучит.

1) Как синхронизировать базу с действиями чиновника? 2) Какое «общество»? Почему эта группа лиц не может быть коррумпирована? Почему её выбор не может быть подделан? 3) Как мы уже видели выше, если необходимо сохранить последовательность транзакций, это выполняется не на все 100%.

Ещё вариант: сервер доступен для аудита всем желающим.

1) разрабатывается формализованный перечень стандартных действий чиновника. Например:
название: выдача документа на открытие фирмы
клиент: ...
имя будещей фирмы: ...
срок: ...
В специальном АРМ он в процессе работы заполняет соотв. записи.

2) заинтересованные граждане всё это видят в реальном времени. Ставят отметки, по которым в конце месяца определяется, сколько заработал себе на зарплату этот чиновник;

3) серверы БД, где хранится вся эта инфа, доступны для аудита теми же гразжанами. Самая уязвимая часть.

Профит:
* открытость действий чиновника исключает коррупцию;
* назначение зарплаты оюществом поворачивает чиновника лицом к людям.

разрабатывается формализованный перечень стандартных действий чиновника

Флаг в руки и барабан на шею.

В специальном АРМ он в процессе работы заполняет соотв. записи.

В том-то и беда, что он сам заполняет или не заполняет что-то. Кто мешает ему именно в этом месте подделать данные? И вся остальная схема полетит в тартарары.

вот только при существующем законодательстве физически невозможно работать только в рамках «стандартных операций». иначе получится такая глобальная итальянская забастовка.

Кто мешает ему именно в этом месте подделать данные? И вся остальная схема полетит в тартарары.

Мешает гласность: данные проверяемы заинтерсованными лицами (например, контурентами фирмы, незаконно получившей поблажку).

Не, ну ежели ты собираешься подписывать каждую тразакцию ключом пользователя ее выполняющего (читай: все транзакции ключом пользователя от которого запущен апач) то да - это несколько сложнее может оказаться. Примерно в 1 раз.

Последнее исправление: maxcom 22.06.2012 8:56:29 (всего исправлений: 1)

Читер! Я тоже так хочу!

Тсс… проводятся тестовые испытания.

В этом мире нет ничего, кроме смерти, чего нельзя было бы сделать «задним числом».

И то не факт.

Что, людей уже научились оживлять?

Не, ну ежели ты собираешься подписывать каждую тразакцию ключом пользователя ее выполняющего (читай: все транзакции ключом пользователя от которого запущен апач) то да - это несколько сложнее может оказаться. Примерно в 1 раз.

Почитай про криптосистемы с открытым ключом уже. Юзеры БД не обязаны хранить свои закрытые ключи на сервере БД.

Что, людей уже научились оживлять?

Не ну а чо? Клиническая смерть тоже смерть. Да и кто его знает, что было до нас и что будет после нас.

Клиническая смерть тоже смерть

Еще нет.

Да и кто его знает, что было до нас и что будет после нас

Лучше не проверять

Я бы проверил, но как?

Если задним числом по времени, то невозможно. Если под «задним числом» понимать подмену данных, занесенных до выполнения последней транзакции, то возможно при условии открытости всех данных.

Нет - конечно не обязаны. Но прочитай сообщение которое цитируешь уже. Ключевое слово там апач. В подавляющем большинстве случаев разделение прав пользователей будет происходить на уровне приложения, а с базой будет работать один пользователь - тот от которого приложение запущено. Соответственно и ключ будет ровно один даже если пользователей будет over9000.

Я понимаю что ты можешь мне ответить:

будем подписывать сами данные ключами пользователей.

Но нафиг тогда база данных если никаких операций кроме выборки всех данных (а иначе как востановить последнюю запись) с ней производится не будет. Не проще фигачить в файл?

будем передавать ключ пользователя на сервер для подписывания транзакции

Что мне помешает (помним, что доступ к серверу у меня есть - а иначе как я бы смог производить такие операции с базой как замена прошедшей транзакции) задампить ключи?

Что мне помешает (помним, что доступ к серверу у меня есть - а иначе как я бы смог производить такие операции с базой как замена прошедшей транзакции) задампить ключи?

Может быть то, что закрытые ключи тебе никто пересылать не будет? А без них ты не добавишь корректную транзакцию, сможешь лишь прочитать чужие транзакции.

Сделать так, что все действия/бездействия и прочие исполнения происходят только на основе этих записей. Не? Нет записи - нет действия. Не корректная запись - не корректно действие.

Сделать так, что все действия/бездействия и прочие исполнения происходят только на основе этих записей.

А теперь вернёмся в реальный мир. Каким образом запретить чиновнику общаться с окружающим миром, чтобы он мог взаимодействовать с миром лишь посредством этих записей?

Ок. Вернемся к моменту подписания транзакции. Если закрытый ключ не передается как приложение сможет ее подписать?

Ок. Вернемся к моменту подписания транзакции. Если закрытый ключ не передается как приложение сможет ее подписать?

Клиент самостоятельно шифрует транзакцию своим закрытым ключом и отправляет серверу. Открытый ключ клиента лежит на сервере, любой желающий может расшифровать сообщение. Но зашифровать сможет только данный клиент.

А. Вот оно что - клиент получает незашифрованную/неподписаную транзакцию и данные необходимые для шифрования/подписывания (скажем подпись предыдущей транзакции), шифрует/подписывает и передает на сервер. Умно.

Но тут вылезут следующие траблы - 1 очень медленные операции записи, так как придется при каждом акте записи блокировать на запись сразу всю базу; 2 если клиент позже подменит свою транзакцию, то как будем разбираться кто виноват - он (подменивший свою транзакцию) или автор следующей транзакции сгенирировавший случайный вектор инициализации с целью компрометации предыдущего оратора?

Блокировать всю базу возможно и не понадобится. Зависит от архитектуры. По второму вопросу можно просто держать «подписи предыдущих транзакций» для каждого юзера свои. Так юзер не сможет незаметно вставить новую транзакцию посреди старых, но при этом никто другой на него повлиять не сможет.

В случае взлома конкретного юзера, доступ к БД ему блокируется, после чего начинается разбор последних его транзакций на предмет добавления взломщиком.

Всё это я сейчас из головы взял. Скорее всего уже существуют нормальные теоретически выверенные протоколы для этого.

О - да - это серьёзная заявка на победу... Тут уже думать надо, а я больше суток не спал. Может завтра чё сочиню ;)

А пока ты выиграл. Ага.

Это невозможно, если у вас нет копии в безопасном хранилище, с которой можно сверить изменения.

Без копии взломщик просто перепишет всю историю (с хешами, проститут-ми и виски), вставив свою запись.

http://en.wikipedia.org/wiki/Trusted_timestamping

В этом мире нет ничего, кроме смерти, чего нельзя было бы сделать «задним числом».

Ты в белорусском парламенте случайно не участвуешь?