2009-06-17 5 views
4

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

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

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

ответ

2

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

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

+0

Будьте осторожны с вложением PW в источник - есть много инструментов, которые позволят вам увидеть встроенные строки ASCII в исполняемом файле. – DCookie

+0

Хорошая точка - да, вам нужно придумать какой-то способ обфускации строки в .exe. – dpbradley

+0

Если вы не обеспечиваете сетевой трафик, они все равно могут получить текст, передаваемый с ПК в базу данных. Я думаю, что шифрование SQL * net является частью одной из дополнительных опций затрат для Enterprise edition. –

2

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

SELECT program 
FROM V$SESSION 

, которые вы можете сделать в AFTER LOGON триггере.

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

+0

+1 - это предотвратит случайный вход через инструменты sql. –

1

я переименовал свою sqlplus.exe в myTool.exe и после установления соединения с myTool.exe

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

Returns: myTool.exe

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