Шифрование данных таблицы

← →
Dinik © (2003-07-01 11:16) [0]

Нужно обеспечить конфиденциальность данных Interbase, защиту от кражи. Средства ОС не подходят, так как потенциальный злоумышленник - сотрудник фирмы и имеет администраторские права на сервере. Остается шифрование самих данных. Если кто-нибудь сталкивался с шифрованием полей таблицы и последующей работы с ними (ввод, отображение) - поделитесь, пожалуйста, своим опытом. Проблема достаточно срочная - на эксперименты времени нет.

← →
Johnmen © (2003-07-01 11:29) [1]

"Быстро только кошки родятся" (c) О.Бендер

Серьезные вопросы не решаются скондачка...:)

← →
Жук © (2003-07-01 11:34) [2]

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

← →
Zacho © (2003-07-01 11:43) [3]

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

← →
Dinik © (2003-07-01 11:48) [4]

В принципе для отображения можно использовать вычисляемые поля. Проблема - как вводить данные??? Хотя можно также использовать несколько DBEdits - одни использовать для отображения, другие для записи в базу и их поочередно скрывать на форме. Но это решение в лоб.

← →
Digitman © (2003-07-01 11:49) [5]

> Dinik

Триггеры BEFORE INSERT/UPDATE у тебя есть ?
Вот в их телах и шифруй значения полей

new.MyField = Crypt(new.MyField);

а при выборке

select Decrypt(MyField) from MyTable...

где Crypt/Decrypt() - либо SP либо UDF (на твой вкус и выбор), шифрующие/дешифрующие значения полей вставляемой/модифицируемой/отбираемой записи

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

← →
Жук © (2003-07-01 11:52) [6]

> Digitman © (01.07.03 11:49)

Если есть доступ к БД, то есть доступ и триггерам.
Правда если UDF написать, и спрятать её подальше. :-)

← →
Digitman © (2003-07-01 12:14) [7]

> Жук

> если UDF написать, и спрятать её подальше

... то найти ее "злоумышленнику", хоть сколь-либо соображающему во механизмах IB так же не составит великого труда)

вариант с шифрованием на AppServer"е, видимо, также не подходит - скорей всего, "злоумышленник" и туда вхож.

отается последний вариант - крипт/декрипт непосредственно в клиентских приложениях)

← →
Jeer © (2003-07-01 12:18) [8]

Или перейти на DB-сервера с шифруемым ядром.
LINTER, DBISAM,..

← →
Zacho © (2003-07-01 12:20) [9]

> Digitman © (01.07.03 12:14)

Но если "злоумышленник" имеет доступ и к клиентским приложениям - вообще вариантов не остается :) Кроме чисто административных.

← →
DINIK © (2003-07-01 12:24) [10]

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

← →
DINIK © (2003-07-01 12:38) [11]

Действительно, я пришел к выводу, что остается только крипт/декрипт непосредственно в клиентских приложениях. В принципе шифроваться будут не все поля, а только самые важные - сократиться время на обработку

← →
Digitman © (2003-07-01 12:43) [12]

> DINIK

> Программа защищена временным интервалом использования и
> привязана к компьютеру

какая программа-то ?) IB-сервер ? AppServer ? Клиентская ?

← →
Dinik © (2003-07-01 13:49) [13]

Клиентская.

← →
Vladymir (2003-07-07 00:50) [14]

Давайте разберемся - какой сотрудник и с каким правом админа. Есть сисадмин. Он по определению будет владеть всеми ресурсами сети.... т.е. в базу влезать ему можно запретить (не говорить пароль) но он сможет ее скопировать целиком, а потом дома ночами "хакать".
Есть администратор БД. Он не владеет такими ресурсами и возможностями как сисадмин, но в БД имеет полный доступ (ко вскм объектам) и знает все пароли так как сам их назначает.
Так вот, для обеспечения конфиденциальности администратор БД должен быть 100%-ой надежности. Потому что он все защиты обойдет если мало-мальски грамотный. Ну а сисадмин - пусть хакает если смщжет.

2 koks © (07.07.03 12:54)
>Ну а сисадмин - пусть хакает если смщжет.
Ему достаточно подменить файл isc4.gdb на такой же по умолчанию и поюзать SYSDBA-masterkey. Даже базу копировать не надо.
От плохих людей нужны иные средства защиты: увольнение и найм порядочных. Слава богу, порядочных большинство.

← →
Vladymir (2003-07-08 02:02) [17]

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

> Vladymir (08.07.03 02:02)

Написать-то можно, но что помешает этому сисадмину использовать эту же UDF для дешифровки ?

← →
Vladymir (2003-07-09 03:38) [19]

>Zacho © (08.07.03 06:31)
В общем и целом, конечно, ничего, но большую базу прогнать полностью на дешифровку, потом отбэкапить результат, потом переписать все на др. носитель, утащить вместе с UDF, на др.машине сделать все в обратном порядке... Достаточно геморройно получается, даже при условии, что все знаешь. Особенно, если тексты процедур, занимающихся криптом, удалены.
Вроде так?...

Шифрование данных таблицы Найти похожие ветки