Защита от SYSDBA

← →
y-soft © (2004-01-16 12:25) [0]

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

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

Решил сделать так:

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

2. Создать бесправную роль SYSDBA

3. Возможно, очистить в таблице RDB$Procedures поля RDB_PROCEDURE_SOURCE

4. Весь доступ осуществляется через ХП, так что можно еще и всем таблицам и полям присвоить неудобочитаемые наименования...

Вроде должно защитить от подмены ISC4.gdb и backup/restore под левым логином

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

← →
Vlad © (2004-01-16 12:28) [1]

> y-soft © (16.01.04 12:25)

Так ты не спасешься от подмены ISC_4

← →
y-soft © (2004-01-16 12:30) [2]

>Vlad © (16.01.04 12:28) [1]

Обоснуй

← →
y-soft © (2004-01-16 12:30) [3]

>Vlad © (16.01.04 12:28) [1]

Обоснуй

← →
Vlad © (2004-01-16 12:31) [4]

> y-soft © (16.01.04 12:30) [3]

Ну поставлю я свой isc4.gdb в котором у sysdba будут все права, и что дальше ?

← →
kaif © (2004-01-16 12:31) [5]

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

← →
y-soft © (2004-01-16 12:32) [6]

Права пишутся не в ISC4, а в саму базу

← →
kaif © (2004-01-16 12:32) [7]

Я думаю шансов выиграть такой процесс предостаточно.

← →
y-soft © (2004-01-16 12:33) [8]

>kaif © (16.01.04 12:31) [5]

К сожалению за всеми заказчиками не уследишь (это 12 городов) :(

← →
kaif © (2004-01-16 12:34) [9]

Не туда копаешь. Если знаешь, откуда утечка и куда - подавай в суд. Заказчик сам прибежит тебе бабки предлагать, а сисадмина просто уволят к черту. Зачем тебе все это унижение?

← →
kaif © (2004-01-16 12:37) [10]

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

← →
Vemer © (2004-01-16 12:38) [11]

От SYSBDA можно защититься созданием одноименной роли... Только Yaffil Personal кажеться все равно нифига не проверяет...

← →
y-soft © (2004-01-16 12:39) [12]

>kaif © (16.01.04 12:34) [9]

Доказать сложно - вся информация только устная... :(

Думаю, что защищаться надо заранее - хорошо еще, что им в руки попала версия годовой давности...

>Vemer © (16.01.04 12:38) [11]

Это точно, как-то не подумал... Но без текстов ХП и Yaffil Personal не поможет. А с крякозябрами в названиях таблиц и полей придется порядком помучаться...

>kaif © (16.01.04 12:37) [10]

С них есть что взять, а с тебя - нет

Я ведь не кустарь, а работаю в фирме, которая в своей области в России и СНГ на ведущих ролях. А о безопасности мне по должности пристало заботиться - других пинаю, а сам лоханулся...

+ пункт №5
Писать только на SQL 3-его диалекта и использовать в качестве имен полей зарезервированные имена типа "Date","count"

Это вызовет проблемы с утилитами перекачки данных типа DataPump, с просмотром в SQL Explorer и будет неудобством в переносимости на Диалект 1 и для его приверженцев, которых большинство

+ п 6
шифровать содержимое важных данных

>DCoder © (16.01.04 15:05) [16]

п.5 - интересная идея
п.6 - IMHO не всегда приемлемо. Важна скорость, а с индексами возникнут проблемы. Хотя для Blob можно...

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

Ещё один (стрёмный) способ - REVOKE для SYSDBA.

Защита от SYSDBA Найти похожие ветки