Еще раз про защиту данных в СУБД

← →
ANB © (2005-10-25 10:08) [0]

Ну в основном про оракл речь идет.
Защита от обычного пользователя делается довольно просто и есть куча механизмов. Для простых случаев хватает даже простых грантов.
Возникла задача защитить данные от шаловливых ручек админа.
Репу почесали - придумали фичу - каждая запись БД должна иметь поле для подписи. При изменении/добавлении в это поле можно записывать некий хэш, расчитаный с помощью RSA. Закрытый ключ можно хранить на смарткарте или брелоке, шифровать там же, а открытый - прямо в базе. Тогда, при необходимости, можно будет подтвердить, что запись внесена через приложение штатным порядком и подписана ключом оператора. Админ уже ручками поостережется лазить, так как в случае чего его же и выдерут.
Но я никак не могу придумать, как защитить базу от удаления записей. Подпись тогда писать некуда. Есть ли у кого логическое решение такой проблемы ?

← →
Sandman29 © (2005-10-25 10:16) [1]

>Есть ли у кого логическое решение такой проблемы ?

Триггер на удаление/изменение с перезаписью прошлых данных в другую таблицу с совпадающей структурой. Из этой новой таблицы либо никто не может удалять, либо где-то сохраняется подписанное общее количество записей в ней, при обранужении сломанной подписи админ увольняется/штрафуется.

← →
Anatoly Podgoretsky © (2005-10-25 10:21) [2]

ANB © (25.10.05 10:08)
Уволить (сменить) админа.
Если не устраивает, то Уволить (сменить) администрацию.

← →
Anatoly Podgoretsky © (2005-10-25 10:23) [3]

Sandman29 © (25.10.05 10:16) [1]
Брось, у вас что администратор с интеллектом червя?

← →
Sergey13 © (2005-10-25 10:24) [4]

>Возникла задача защитить данные от шаловливых ручек админа.
А это не того... не паранойя? 8-)
От чтения все равно не защитишь. А от изменения.... А надо менять? Да просто подойди к любому соединенному в данный момент компу и попроси девочку уступить место для "проверки компьютера на 5 минут - и закрывать ничего не надо". 8-)

← →
Sandman29 © (2005-10-25 10:31) [5]

Anatoly Podgoretsky © (25.10.05 10:23) [3]

Про нас я не говорю, я теоретически.
Один администратор знает пароль пользователя-владельца таблиц, другой знает пароль пользователя-владельца таблиц истории, третий знает системный пароль (и может удалить триггер), но не имеет доступа к компьютеру. Если что-то нужно делать, все трое участвуют и контролируют друг друга. Можно еще звеньев добавить. "Разделяй и властвуй" :)

← →
Anatoly Podgoretsky © (2005-10-25 10:42) [6]

Про паранойю уже сказали, но видимо она летальная.

← →
ANB © (2005-10-25 10:48) [7]

Это не паранойя. Это у реального заказчика вылезла. Наши аналитики уже второй месяц репу чешут. Короче - ситуация :
к нашему заказчику приходит клиент и заявляет, что он не обслуживался по своей карте тогда то и тогда то. А по базе стоит - что обслуживался. Заказчик заявляет - раз в базе есть, то обслужился, клиент - вы сами в эту базу все добавили. Заказчик чешет к нам - дайте справку, что ничего руками добавит в базу нельзя. Мы справку не даем, так как на самом деле при желании - можно. Заказчик в растройстве и просит чего нибудь придумать, чтобы история не повторялась. То есть хочет таки иметь такую справку для новых версий.

← →
ANB © (2005-10-25 10:49) [8]

Кстати, идея Sandman29 © - весьма весьма. Я тоже начал о таком думать.

← →
Anatoly Podgoretsky © (2005-10-25 10:59) [9]

О так у вас бардак, надо просто навести порядок.

← →
Desdechado © (2005-10-25 11:09) [10]

имхо, если речь идет об обслуживании по карте, то:
1. та самая карта и может быть ключом
2. тогда в БД ничего никуда не должно деваться, просто перекладываться из одного места в другое, т.е. приход-расход-баланс остается

← →
Sandman29 © (2005-10-25 11:12) [11]

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

← →
ANB © (2005-10-25 11:34) [12]

> Sandman29 © (25.10.05 11:12) [11]
- как ты думаешь, сколько в ЮКОСе или Лукойле в день продаж на запрваках ? Причем все терминалы в оффлайне, инкассируются примерно раз в сутки.

> Anatoly Podgoretsky © (25.10.05 10:59) [9]
- система не у нас стоит, а у заказчика, а у него свой админ. Ну и наш бардак, ессно. Вот и хотят попытаться порядок навести. Правда наши карты RSA не поддерживают, но поддерживают DES (так и не узнал, что это за алгоритм). На EMV клиенты не хотят переходить - дорого.

> Desdechado © (25.10.05 11:09) [10]
- админ с правами DBA может почистить и логирующую таблицу.

← →
Sandman29 © (2005-10-25 11:38) [13]

ANB © (25.10.05 11:34) [12]

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

← →
ANB © (2005-10-25 11:44) [14]

> Sandman29 © (25.10.05 11:38) [13]
- а пока лучше вашего совета во втором посте ничего и нет. Я и не наезжаю. И оправдываться не надо, ибо не в чем. Я ж и правда объем не писал. Только сравнение с бумажками - не проканает. Кто их потом с заправок забирать будет и анализировать ?

← →
Seg (2005-10-25 11:45) [15]

защитить данные от шаловливых ручек админа.

Настучать по рукам. И не только по рукам.

← →
ANB © (2005-10-25 11:47) [16]

> Seg (25.10.05 11:45) [15]
> защитить данные от шаловливых ручек админа.
>
> Настучать по рукам. И не только по рукам.

Чтобы настучать, нужно хотя бы узнать, что он это сделал.

← →
Sandman29 © (2005-10-25 11:48) [17]

ANB © (25.10.05 11:44) [14]

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

← →
ANB © (2005-10-25 12:08) [18]

> Sandman29 © (25.10.05 11:48) [17]

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

← →
wal © (2005-10-25 12:13) [19]

> как ты думаешь, сколько в ЮКОСе или Лукойле в день продаж
> на запрваках ?
--
> к нашему заказчику приходит клиент и заявляет, что он не
> обслуживался по своей карте тогда то и тогда то. А по базе
> стоит - что обслуживался.

В среднем 600-700 заправок по картам в сутки на крупных АЗК.
При инкассации терминала в базу складывать номер терминала, по которому транзакция прошла. На АЗС хранить копии чеков терминала (в отсортированном по времени виду). Тогда подобная заморочка разрешится в 10 минут и пару телефонных звонков.

← →
Sandman29 © (2005-10-25 12:16) [20]

ANB © (25.10.05 12:08) [18]

Логично. Но такую гарантию дать невозможно, если человек знает системный пароль и поэтому может изменять все. При желании он сможет разобраться в защите и обойти ее каким-нибудь способом. Напоминает взлом лицензионной версии программы ИМХО.

← →
ANB © (2005-10-25 12:18) [21]

> При инкассации терминала в базу складывать номер терминала,
> по которому транзакция прошла. На АЗС хранить копии чеков
> терминала (в отсортированном по времени виду).

Номер терминала и время обслуживания в базе есть. Похоже, заказчик не сильно жаждет хранить копии чеков. Там же еще и карты лояльности обслуживаются. Хотя идея. Надо будет аналитикам подкинуть.

← →
ANB © (2005-10-25 12:19) [22]

> Sandman29 © (25.10.05 12:16) [20]

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

← →
wal © (2005-10-25 12:20) [23]

> Похоже, заказчик не сильно жаждет хранить копии чеков. Там
> же еще и карты лояльности обслуживаются.
Это проблема заказчика, как он такие заморочки без копии чека решать будет. По картам лояльности тоже чек печатается (или два, или три - по желанию). Статистика с учетом подобных карт.

С уважением.

← →
MOA © (2005-10-25 12:22) [24]

ПМСМ:
1. От толкового админа не защититься иначе, чем шифрованием.
2. Следовательно, необходимо завести поле с зашифрованными данными - время-дата-объём, например - причём шифрование с ключом клиента - можно однонаправленное - хеш какой-нибудь. И в договоре записать, что за секретность ключа отвечает клиент.

← →
hCat (2005-10-25 12:23) [25]

А на Оракловый аудит смотреть не пробовали ? Вроде бы действия сиса над таблицами самого аудита тоже журналируются в аудите.

Однако. Пара команд

insert into dual values ("Y");
commit;

дает просто офигительный эффект в Оракл, и ничего удалять не надо - все системы раком, понять только трассировкой, в данных хрен знает что. Не вздумайте проверять на пром БД.

← →
MOA © (2005-10-25 12:27) [26]

Да, если есть возможность - дополнительно можно завести где-нибудь километров за 500 (и/или в забетонированном и опечатанном помещении) сервер, к которому не будет доступа по чтению - только запись логов с поднятием тревоги при непоступлении логов в течении , например, 5-ти минут. Пароль на сервер и ключ к помещению (сейфу) - в сейфе начальника ;).

← →
ANB © (2005-10-25 12:29) [27]

> По картам лояльности тоже чек печатается (или два, или три
> - по желанию)

Дык по этим чекам разборок не бывает. Я к тому, что эти чеки надо либо отдельно класть, либо в общую кучу, что увеличит объем бумажек.

> MOA © (25.10.05 12:22) [24]
- для вставок/обновлений примерно такую идею и задумали. Вопрос с удалением.

> А на Оракловый аудит смотреть не пробовали ?
- логирование выключено. Млин. Для экономии места.

> insert into dual values ("Y");
> commit;
- пробовал уже. Ничего особо не ломается и легко чинится.

← →
Игорь Шевченко © (2005-10-25 12:30) [28]

ANB © (25.10.05 12:29) [27]

> - логирование выключено. Млин. Для экономии места.

ССЗБ ?

> Ничего особо не ломается

Ломается :)

archived redo logs + logminer не поможет?

> логирование выключено. Млин. Для экономии места.

Ну... а что у вас еще выключено?

> ССЗБ ?
- не ругайтесь, плз, непонятными словами. Не я это придумал.

> Ломается :)

Чичас проверим.

> Игорь Шевченко © (25.10.05 12:43) [33]

Ну. И ничего не сломалось. Заинсертил. Посмотрел системные вьюхи - все работает. Ломаются только запросы из dual. Ну и приложения лучше не запускать. Гы гы. И нормально удалилось.

← →
hCat (2005-10-25 12:57) [35]

> пробовал уже. Ничего особо не ломается и легко чинится.

Это если знать, что именно сломано. Ежели не ломается значит так написано - те что я знаю ломаются и еще как.
Просто сказано это к тому, что бороться с админом занятие достаточно бесперспективное при практически любых раскладах. Права-то у него практически все есть в том числе и просмотреть, что именно вы там накрутили.

> логирование выключено. Млин. Для экономии места.

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

И почему вы так уверены, что это не програмная ошибка ? Я бы копал в сторону ошибок в софте и ловле усеров, которые имеют права на удаление удаленного. А с самого начала бы посмотрел внимательно запрос, который список выводит - м.б. сам счет на месте, а удалили запись справочника на которую он ссылается обычным джойном. Например:
select i.Invoice_ID from TInvoices i, TClients c where i.Client_ID = c.CLient_ID

>> Desdechado © (25.10.05 11:09) [10]
> админ с правами DBA может почистить и логирующую таблицу
Если баланс прихода-расхода-наличия нарушен, то только админ мог это сделать, ибо ведь как там у Ломоносова в законе сохранения вещества? Ничто никуда не девается и ниоткуда само не берется.

> hCat (25.10.05 12:57) [35]

Не, ошибок нету. Софт вообще то старый и совсем без защиты. Вот сейчас ее и проектируют. Писать дай бог через год начнут.

← →
hCat (2005-10-25 14:03) [38]

Бороться с админом не советую - все равно без толку все это.

Вот, может, так?:
1. Предполагаеи, что админ умный - значит, сможет отключить или подтасовать механизмы логов
2. Ведём лог транзакций по счётам, где есть зашифрованные ключом клиента данные, включающие код операции, сумму и сквозной номер операции по всем счетам. Дополнительно в таблице проводок пишем поле с зашифрованными ключом клиента реквизитами проводки.
Шифруем так, чтобы у нас был ключ для расшифровки этого поля, но не для шифровки.
Теперь админу, чтобы удалить запись необходимо править все последующие - а для этого нужно либо знать пароли всех клиентов, либо ломать алгоритм шифрования ;).
В такой схеме админ, конечно, сможет удалить запись "сразу же", до того как была записана следующая запись.
Варианты противодействия:
а) Вести аналогичный лог "транзакция проведена" (например, бензин налит) с полем, зашифрованным неким "директорским ключом", или "ключом офицера безопасности", или "ключом аппаратуры" - обман будет выявлен при сравнении логов. Тут возможен сговор
б) Вести независимые логи где-то ещё, в месте, доступ к которому затруднён физически (на заправках, на отдельном сервере) - и выявлять обман сревнением. Опять же, обмануть можно при сговоре.

Есть идея, содранная у Sandman29 :
Имеем живую таблицу и таблицу архива (и так есть). Заводим еще одну таблицу для контрольных сумм. При добавлении записи в таблицу (операцию можно подписать ключом клиента прямо на терминале, чтобы клиент не рыпался) считаем количество записей, подписываем его с помощью ключа на операторской карте (это уже организационно можно продумать, железяку какую подключить или еще что) и кладем в таблицу контрольных сумм. Штатное удаление будет просто перекладывать записи из живой таблицы в архивную, сумма записей меняться не будет, причем операцию можно подписать картой оператора еще раз. Теперь, если удалить ручками и не положить в архив - не сойдется количество записей, количество записей и вставку в архив не подделать, так как нужен ключ. При желании и это можно будет взломать (сговор и т.п.), но стоимость взлома будет такой высокой, что не найдется заказчиков (это ж сколько бензина надо будет вывезти, чтобы расчитаться). Самому админу за бесплатно это будет на фиг не нужно. А так как операции будут подписаны картой клиента, ему тяжело будет доказывать, что обслуживания не было. Тем более для частников - только электронные кошельки, а там уже карта заботиться о том, чтобы он не взял больше, чем ему положено.

Еще раз про защиту данных в СУБД Найти похожие ветки