Привет всем!
Служба информационной безопасности поставила нам задачу обеспечить неизменность данных при хранении в СУБД.
Модель угрозы: "лицо с привилегированном доступом злонамеренно изменяет данные".
Я тщетно пытался объяснить, что подобная задача невыполнима, т.к. единственным способом проверки неизменности данных является сверка входящего набора данных с выходящим (хоть побитовым сравнением, хоть кэшем, хоть ЭЦП). При этом в СУБД приходит набор одного состава, а выходит практический всегда - другого. Т.е. атомарные данные перемешиваются в произвольной комбинации, образовывая новый, неизвестный на входе набор данных. Очевидным, простым и неправильным решением было бы сверять атомы данных. Неправильным потому, что важны не только сами данные, а их комбинации, логика образования которых неизвестна на входе и не может быть проверена на выходе.
Однако наши оппоненты стоят на своем и уверяют, что подобные решения для СУБД существуют.
Искренне прошу всех, кто знаком с существующими технологиями решения описанных мной проблем, сообщить мне.
Заранее невдолбенно благодарен!

landy,

Вы что, никогда не встречались с хомо безопасикус? :(
У нас они закрепились на позициях "мы никогда ничего никому не объясняем, а только тыкаем пальчиком в то, что считаем небезопасным".

Большое спасибо!
Я когда-то изучал vault, и не припомню в нем решения для угрозы такого типа:
Данные могут быть изменены администратором в регламентном процессе (устранение инцидента, например), но в рамках этого регламентного процесса он может внести неправильные данные как ненамеренно, так и злонамеренно. Разве vault это предотвращает?

Да, единственный выход - вообще запретить менять что-то в данных.
Но я предвосхищаю следующий заход безопасников: А если сенситивные данные изменятся в результате технического сбоя?
Они у нас молодые дарования, воспитанные уже на Hadoop. Они мыслят категориями "файл зашел" - "файл вышел".
При этом я не умаляю их компетентности во многих технических вопросах.
Однако когда говоришь, что это СУБД, они вспоминают, что в СУБД данные попадают из AS, при помощи JSON. И у них в голове вроде как складывается паззл "JSON пришел - JSON вышел" :)

Спасибо! Интересная фича.
Но это, наверное, не очень подойдет, т.к. судя по описанию "The participants are different database users who trust Oracle Database to maintain a tamper-proof blockchain of transactions". А в нашем случае доверие к СУБД недостаточное.

Я говорил, что они верят хэшам, ЭЦП и подобным способам приклеить к данным на входе какой-то проверочный ярлык, а на выходе его сверить.
Однако я думаю, что нам удастся их убедить в неприменимости такого подхода к данным в БД.