Привет всем!

Просьба помочь в нелегком вопросе. Есть клиент-серверное приложение, созданное с помощью таких средств:
- PowerBuilder 9.0.3
- Oracle 10.2.0.4
Безопасность доступа к данным обеспечивается следующим образом. Есть табличка с пользователями без паролей. Есть набор ролей, которым выдается доступ к различным ресурсам. При создании пользователя создается одноименный пользователь Оракла, записывается в табличку с пользователями, ему выдаются все роли. Каждая задача описывается через набор таблиц в БД. Каждой задаче ставится в соответствие перечень ролей, необходимых для ее запуска и функционирования. При запуске задачи создается отдельная сессия, в которой включаются необходимые роли (set role blablabla). Перечень ролей берется из табличек БД.
Пронырливыми заказчиками было установлено, что конечно бесправный пользователь по умолчанию ничего не видит при подключении SQL navigator'ом, но - видит перечень доступных ролей. Делает сам себе set role blablabla, и видит то, что ему вроде как было и недоступно. Что не есть гуд.
Приняли такое решение для обхода проблемы - задать всем ролям пароли и при вызове задачи включать роль с паролем. Типа - да, бесправный пользователь видит все возможные роли, но не может их включить. Соотв. картина "Лисица и виноград" :) Однако, предвидя следующий вопрос - "дык в SQL Monitor-е мы ж видим все передаваемые пароли!!" решили попытаться решить эту проблему заранее.
Отсюда вопрос. Как можно зашифровать обмен между клиентом и сервером при работе через PowerBuilder? Или может копаем не в ту сторону - просьба подсказать...

VanoRкакая-то ерунда написана


Vadim Romanenkoбесправный пользователь по умолчанию ничего не видит при подключении SQL navigator'ом, но - видит перечень доступных ролей.
убрать у пользователя привелегию "select any dictionary" и он ничего не увидит

Дурацкий вопрос :) Не подскажете, как убрать привилегию? Попробуем - спасибо в любом случае :)

VanoRVadim RomanenkoДелает сам себе set role blablabla
чтобы добавить самому себе роль, нужно самому иметь роль DBA в базе
а если пользователь не DBA, и имеет эту роль, то все равно чтобы передать эту роль другому, то эта роль blablabla должна у него быть с "with admin option"

Сам себе пользователь НЕ добавляет роль. Она ему добавляется при создании. А при запуске задачи - просто АКТИВИРУЕТСЯ уже имеющаяся роль.

VanoRчтобы добавить самому себе роль, нужно самому иметь роль DBA в базе
а если пользователь не DBA, и имеет эту роль, то все равно чтобы передать эту роль другому, то эта роль blablabla должна у него быть с "with admin option"
Потому-то и не выдается пользователю роль при старте задачи, а только активируется... Т.е. GRANT выполняется при СОЗДАНИИ пользователя.

VanoRавторА при запуске задачи - просто АКТИВИРУЕТСЯ уже имеющаяся роль.
эт как так?!! роль или есть или ее нет... как она может активироваться?!!!

Ну вроде как есть
а есть

Вроде так :) Но могу и ошибаться.

Так вот. Первое делается при создании пользователя, второе - при запуске задачи для текущей сессии.

... извиняюсь - очепятка.

читать как

Anatoly Moskovsky,

Дело в том, что роли у нас к сожалению не являются достаточно подробными, чтоб включив одну роль, дать права на выполнение только одного действия. Роль сразу дает права на целый спектр действий. Потому и включаем-выключаем по желанию. Одна из основных целей - защита от рук пользователя, полезшего со своими скриптами в БД. Ошибкой конечно было то, что роли не имеют пароля. И для включения нужно всего лишь в том же SQL Navigator-e активировать роль. Но думаю что впедалим туда пароли - и эта возможность исчезнет. Однако SQL Monitor позволит спиратить пароль на роли. Тут возникла конечно мысль роли давать через функцию на сервере и пароль передавать в функцию передавать шифрованным...

VanoRсамый простой способ - запретить пользователям (которые не DBA) коннектиться базе софтом, который админам не угоден... тем же SQL Monitor

SQL Monitor - не коннектится к базе ;) Он перехватывает сетевой трафик "на лету".
Но идея такая, правда касательно sql navigator, sql plus, etc - тоже бродила. И даже будем применять. Вопрос только - как определить, что запущенный ЕХЕ-шник это наш ЕХЕ-шник, а не переименованный sql plus например :( Т.е. пока что подход не дает 100%-ной гарантии.

VanoRвторой способ - переделать весь софт на работу не с таблицами, а с процедурами. и пользователям дать права только на коннект и вызов нужных процедур, а в процедурах также отслеживать с какого софта ее запустили
Ну-у-у... Всегда можно перехватить вызовы, и подделать их. Это с одной стороны. С другой - такая переработка... М-м-м... Много-много месяцев работы, сводящихся к полному переписыванию клиентского приложения, которое разрабатывалось на протяжении 11 лет. Правда, мега-активной фазы там конечно года на полтора... Но это непростительные затраты для нас :(
В кардинально новой версии конечно учтем этот момент, и таки наверное именно по этому пути и пойдем.

VanoRVadim RomanenkoВопрос только - как определить, что запущенный ЕХЕ-шник это наш ЕХЕ-шник, а не переименованный sql plus например :( Т.е. пока что подход не дает 100%-ной гарантии.

ну как минимум можно еще отслеживать поля MODULE и ACTION из v$session
MODULE - всегда можно переименовать. Т.е. sqlplusw.exe в какое-нибудь разрешенное имя.

А что такое ACTION?

Anatoly MoskovskyVadim Romanenko Одна из основных целей - защита от рук пользователя, полезшего со своими скриптами в БД. Ошибкой конечно было то, что роли не имеют пароля. И для включения нужно всего лишь в том же SQL Navigator-e активировать роль. Но думаю что впедалим туда пароли - и эта возможность исчезнет. Однако SQL Monitor позволит спиратить пароль на роли. Тут возникла конечно мысль роли давать через функцию на сервере и пароль передавать в функцию передавать шифрованным...
Вы пытаетесь использовать для обеспечения безопасности фичу, предназначенную только для удобства юзера.

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

Согласен. Дыра. Но пока не могу понять как эту дыру убрать. Единственное что видится - создание достаточно большого кол-ва ролей (сотни) по доступу на таблицу (связанные таблицы), причем на каждую таблицу (или их набор) нужно как минимум две роли - только чтение, или полный доступ... То же самое по пакетам. Хотя... Для пакетов наверное можно было бы сделать одну большую роль :)

И каждой задаче выдавать столько ролей, сколько таблиц/пакетов она затрагивает. Но это же... В общем, ужасно - управлять таким массивом данных довольно сложно... Или может только так кажется?

Anatoly MoskovskyVadim RomanenkoЕдинственное что видится - создание достаточно большого кол-ва ролей (сотни) по доступу на таблицу (связанные таблицы), причем на каждую таблицу (или их набор) нужно как минимум две роли - только чтение, или полный доступ... То же самое по пакетам.
Нет, конечно.
Так не надо делать.
Роли должны создаваться на задачи, а не на таблицы.
Просто вы должны принять тот факт, что если у юзера есть права на задачу, то у него должно быть право на доступ через SQL+ к таблицам и ХП которые в этой задаче используются из клиентского приложения.
А чтобы юзер не мог кривыми sql командами попортить данные, контроль целостности должен проводиться не только на клиенте, но и на триггерах.
Конечно использование ХП намного облегчает контроль на стороне сервера.

Хм. Т.е. вы предлагаете идеологию "одна задача - одна роль"? Может и так. Но все равно - многовато ролей :( Хотя меньше, чем таблиц :) Что ж, подумаем, взвесим! Спасибо за идею!

ПС: т.е. предполагается, что пакеты будут иметь максимальные права, а вот доступ к пакетам уже будет определяться ролями...

VanoRVadim RomanenkoMODULE - всегда можно переименовать. Т.е. sqlplusw.exe в какое-нибудь разрешенное имя.

А что такое ACTION?

ACTION - колонка в v$session
ею можно манипулировать с помощью DBMS_APPLICATION_INFO.set_action

ну и раз все так серьезно с доступом к данным, можно всегда вести аудит

хотя и из sqlplus можно тот же action установить, но об этом обычные пользователи не должны знать... допустим при первой попытке пользователь не установил action или module и попытался приконнектиться и выполнить запрос
триггер перехватил запрос, action например не тот, дал отлуп юзеру и записал в журнал попытку злого умысла.
админ увидел это в логе, доложил начальству, начальство отдало приказ "расстрелять" :)

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

tru55Если таковые есть, то большинство проблем решается грантами. Работа только через хранимки - тоже хорошее дело. Опять же, есть такая фича, как FGAC.

Предполагается, что таковые есть. С самого начала (более 11 лет назад) вся безопасность была положена на роли (казалось бы, группированные гранты). С одной стороны - можно просто всем ролям дать пароли, но взлом все же возможен SQL Monitor-ом например (слушает сетевой трафик по обмену с Ораклом на клиенте). Но уже придумали мысль - роли выдавать через функцию, пароли передавать в шифрованном виде.
А что есть FGAC?

tru55Правда, все это к PB отношения не имеет :)
Согласен :) но стартовый вопрос (как и стартовая идея) был в том, чтоб зашифровать обмен клиент-сервер, чтоб нельзя было по сети выцепить пароли ролей. Пока никто не подсказал, как это возможно на ПБ :) Думал есть настройки драйвера - но пока не нашел :(

Anatoly Moskovsky,

Большое спасибо за ссылку!! Действительно, дело совсем не в ПБ...