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

← →
ANB © (2005-10-25 14:56) [40]

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

← →
Seg (2005-10-25 15:04) [41]

Есть идея, содранная у Sandman29 :

А может все-таки положить сисадмину конкурентную зарплату, чтобы воровать было невыгодно?

← →
ANB © (2005-10-25 15:06) [42]

> Seg (25.10.05 15:04) [41]
- не я же зарплату админу определяю. А заказчик.

← →
MOA © (2005-10-25 15:26) [43]

А тут, ПМСМ, дело не только в админе.
Ситация "я ничего не делала а оно всё пропало" ;), вариант "яничегонеделала а адмнивсёстёр" возникает постоянно, а встроенные в систему логи слегка отрезвляют "ничегонеделалщиков" - обычно, конфликтная ситуация на этом и исчерпывается - человек таки вспоминает, что делал ;).

← →
Гаврила © (2005-10-25 15:30) [44]

> ANB ©

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

У меня возникло страшное подозрение, что вы взяли на работу того самого админа, которого мы не так давно уволили
:-)))))

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

- не я же зарплату админу определяю. А заказчик.

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

← →
Opilki_Inside © (2005-10-25 16:27) [46]

Когда-то я сам интересовался подобным вопросом, и меня отправили на sql.ru

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

Т.е. имя пользователя в БД храниться должно, но пользователь получает его зашифрованное значение.
Программа должна иметь методы авторизации пользователя, тогда получается пользователь вводит VASYA, программа конверитрует это имя например в AYSAV и кидает его в БД...

Таким образом, пользователь в обход программ влезть в БД не сможет.

Идея понятна?

← →
Seg (2005-10-25 16:31) [47]

Идея понятна?

Вопрос сначала прочитай:

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

← →
Opilki_Inside © (2005-10-25 18:46) [48]

Seg

ты полагаешь, что я его не читал?

если этот админ, не будет знать пароль на доступ к БД, то как он сможет что либо изменить в базе?

Используй механизм RLS.
Им можно защитить табличные данные от тех, кто знает пароль владельца схемы.

> если этот админ, не будет знать пароль на доступ к БД,

...то какой он нафик админ?

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