Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Шифрование данных таблицы [D3, D4, D5, D6, D7, IB5.x, IB6.x]

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

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

Zacho (2003-07-08 06:31:00) [2]

> Vladymir (08.07.03 02:02)

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

Vladymir (2003-07-08 02:02:00) [3]
Кстати, можно написать UDF, которая будет шифровать что-нибудь в базе скажем серийным номером сетевой карты, каковой уникален по определению...

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

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

Vladymir (2003-07-07 00:50:00) [6]
>DINIK © (01.07.03 12:38) Но проблема с уворовыванием или умышленной порчей данных останется.

Dinik (2003-07-01 13:49:00) [7]
Клиентская.

Digitman (2003-07-01 12:43:00) [8]

> DINIK

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

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

DINIK (2003-07-01 12:38:00) [9]
Действительно, я пришел к выводу, что остается только крипт/декрипт непосредственно в клиентских приложениях. В принципе шифроваться будут не все поля, а только самые важные - сократиться время на обработку

DINIK (2003-07-01 12:24:00) [10]
Программа защищена временным интервалом использования и привязана к компьютеру. А если украсть базу данных и законнектиться на другом компьютере - то структуру базы можно понять и написать простенькое клиентское приложение.

Zacho (2003-07-01 12:20:00) [11]

> Digitman © (01.07.03 12:14)

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

Jeer (2003-07-01 12:18:00) [12]
Или перейти на DB-сервера с шифруемым ядром.
LINTER, DBISAM,..

Digitman (2003-07-01 12:14:00) [13]

> Жук

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

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

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

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

Жук (2003-07-01 11:52:00) [14]

> Digitman © (01.07.03 11:49)

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

Digitman (2003-07-01 11:49:00) [15]

> Dinik

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

new.MyField = Crypt(new.MyField);

а при выборке

select Decrypt(MyField) from MyTable...

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

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

Dinik (2003-07-01 11:48:00) [16]
В принципе для отображения можно использовать вычисляемые поля. Проблема - как вводить данные??? Хотя можно также использовать несколько DBEdits - одни использовать для отображения, другие для записи в базу и их поочередно скрывать на форме. Но это решение в лоб.

Zacho (2003-07-01 11:43:00) [17]
К тому же, если у потенциального злоумышленника права админа на сервере, то весьма вероятно, что и приложение он сможет похитить, и толку от шифрования не будет.
Проще уволить этого потенциального злоумышленника.

Жук (2003-07-01 11:34:00) [18]
Я сталкивался только с шифрованием хранимых паролей в 3-хзвенке. Но там было необратимое шифрование. Когда юзер вводил свой пароль, тот зашифровывался и сравнивался с хранящимся в базе.
А отображение... Это ж такие тормоза будут, если их на клиенте расшифровывать.

Johnmen (2003-07-01 11:29:00) [19]
"Быстро только кошки родятся" (c) О.Бендер

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »