Разрешить oracle db войти только в конкретное приложение?

Мы хотим разрешить доступ к БД (Oracle) нашим пользователям только через наше собственное приложение - назовем его «ourTool.exe», установленное локально на компьютерах пользователей. В настоящее время пользователи должны указывать имя пользователя / пароль всякий раз, когда они запускают «ourTool». Предоставленный пароль пароля расшифровывается, и мы используем имя пользователя / расшифрованный пароль, чтобы наконец войти в базу данных Oracle. Такой подход предотвращает прямой доступ пользователей к нашей БД с помощью сторонних инструментов (SQLplus, Excel, Access, ...), и все в БД гарантированно будет введено / отредактировано с использованием & quot; ourTool & quot ;.

Теперь один из наших клиентов хочет разрешить своим пользователям «единый вход». (со смарт-картами / Oracle PKI). Благодаря этому пользователь сможет подключаться к нашей БД без указания пароля каждый раз, когда он запускает «ourTool». Но то же самое будет верно для потенциально опасных инструментов, таких как SQLplus, Excel, Access и т. Д.

Есть ли способ предотвратить это? Как мы можем быть уверены, что каждая запись в нашей БД создается / редактируется / удаляется только с помощью & quot; ourTool & quot; по этому сценарию?

Ответы на вопрос(3)

инения с myTool.exe

SELECT  program
FROM    V$SESSION
where username = 'SYSTEM';

Возвращает: myTool.exe

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

По умолчанию,OCI передает вызывающее приложениеEXE имя, и вы можете получить к нему доступ, запросивv$session:

SELECT  program
FROM    V$SESSION

, что вы можете сделать вAFTER LOGON спусковой крючок.

Но это можно легко переопределить, и на него нельзя полагаться.

 17 июн. 2009 г., 16:26
+1 - это предотвратит случайный вход через sql tools.
Решение Вопроса

и вы имеете контроль над источником, вы можете использовать либо роли базы данных, защищенные паролем, либо защищенные роли приложений, которые включены в ourTool.exe. (увидетьhttp://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).

Например, с ролью базы данных, защищенной паролем, начальное соединение будет иметь только привилегию CREATE SESSION, а затем ourTool.exe выдаст SET ROLE с паролем, известным только вам. Любое другое приложение не имеет информации для установки роли. Очевидно, что привилегии предоставляются только роли, а не непосредственно пользователю в этой конфигурации.

 17 июн. 2009 г., 16:47
хороший момент - да, вам нужно придумать какой-то способ запутать строку в .exe
 17 июн. 2009 г., 16:42
Будьте внимательны при встраивании PW в исходный код - существует множество инструментов, позволяющих вам видеть встроенные строки ASCII в исполняемом файле.
 ToastedSoul26 июн. 2009 г., 14:06
Мы собираемся использовать идеи, представленные здесь, и мы могли бы также включить запрос в v $ session (см. Ответ Quassnoi). Спасибо всем!
 18 июн. 2009 г., 00:23
Если вы не защищаете сетевой трафик, они все равно могут получить текст, передаваемый с ПК в базу данных. Я думаю, что сетевое шифрование SQL * является частью одной из дополнительных возможностей для редакции Enterprise.
 18 июн. 2009 г., 13:46
Да SQLNet encryption is still part of the extra cost Advanced Security Option. Both you and DCookie have valid points for the fringe case of someone determined to connect to the database and gain privileges, but I believe the spirit of the original question was how to deal with the average desktop user who has SQLПлюс или ODBC подключение. Я надеюсь, что Oracle в конечном итоге выкатывает Adv. Sec. вариант для Enterprise Edition - кажется неправильным доплачивать за защиту продукта компании.

Ваш ответ на вопрос