Архив форумов ЦИТФорума

[s_tristan]

Сабж, собственно

[and3008]

-

[s_tristan]

У меня вот такая, казалось бы, тривиальная задача: есть абстрактная база с одной таблицей. В нее добавляют записи, скажем, Петров, Иванов и Сидоров. Как мне сделать так, чтобы на запрос Петрова сервер, во-первых, понимал, что это Петров, а во-вторых выдавал ему только его, Петрова, записи, причем, чтобы остальные записи Петров не мог даже читать. Да, я понимаю, что со стороны клиента это сделать довольно легко - строка SQL в предложении WHERE будет содержать что-то вроде UserID='Петров', НО если Петров имеет у себя текст этой строки, то что ему мешает заменить UserID='Петров' на UserID='Иванов' и прочитать записи Иванова? Это значит, что я не могу имя пользователя посылать в строке SQL. Сервер, и только он, должен решать какие записи кому выдавать, а имя пользователя он берет из параметров подключения, а не из строки SQL. Это значит, что даже если злоумышленник Сидоров в строке SQL пропишет UserID='Петров', то сервер должен вернуть ему записей!
Может у меня совершенно неправильное понимание концепции разграничения прав пользователей? Если так, что буду признателен за сссылку на соответствующую литературу.

[and3008]

Нужно в базу писать не фамилии, а идентификаторы пользователей.
Идентификаторы хранить в отдельной табличке.
Идентификаторы должны быть случайные, а не последовательные и иметь весьма не хилую длину. Тогда меньше шансов взломать базу тупым перебором.

При подключении к базе - обязательная авторизация.

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

[s_tristan]

Подождите, порассуждаю...
Итак есть сервер. Также есть клиент, написанный на произвольном языке и который рано или поздно будет взломан. В нем зашита строка подключения типа там SERVER="xxx.xxx.xxx.xxx;DATABASE=Test;UserID=UID;PASSWORD=PW D", где UID и PWD - переменные (то бишь в коде клиента их нигде нет и которые юсер обязан внести ручками) нехилой длины и случайно сгенерированные. Также там имеется строка SQL с предложением WHERE UserID=UID. Теперь предположем, что юсер захочет получить доступ к чужим записям. Он поломает клиента, возьмет строку подключения и подключится из консоли к серверу. Далее он берет строку SQL, убирает строку WHERE нафиг и посылает ее серверу. Ответит сервер? Конечно - он вернет ВСЕ записи из таблицы. Вот и вся петрушка. В связи с этим нужно как-то реализовать следующий механизм:
1. Строка подключения остается прежней - хай подключается на здоровье.
2. Строка SQL не содержит предложения WHERE
3. Сервер при приеме строки SQL делает следующее:
3.1 смотрит в своей таблице пользователей наличие записи с UID и PWD, которые он берет из параметров текущего подключения
3.2 в найденной строке считывает УНИКАЛЬНЫЙ и НИКОМУ неизвестный КОД этого юсера
3.3 Самостоятельно составляет предложение WHERE с этип кодом
3.4 Приплюсовывает созданное предложение WHERE к исходной строке SQL
3.5 и наконец выдает юсеру записи соответствующие окончательному варианту строки SQL

Вопрос 1 - какой из серверов, желательно OpenSource, такое умеет делать (понятно, что после программирования)?
Вопрос 2 - может есть другое решение?

[and3008]

Имеем таблицу UID, PWD
Имеем хранимую процедуру на сервере, которая принимает UID и PWD и возвращает клиенту номер сессии в случае правильного пароля и в случае неправильного.
Сервер записывает во временную таблицу пару UID и номер сессии.

После этого клиент общается с сервером посредством хранимых процедур, отправляя SQL запрос и номер сессии.

Сервер перед выполнением запроса проверяет соответствие сессии и UID, слегка меняет исходный запрос и выполняет.

Возникает вопрос с тем, что делать, когда клиент отключается... Наверняка при разрыве сессии сервер выполняет какие-то действия, которые несколько расширить.

Идея понятна?

Из Open Source рекомендую поглядеть в первую очередь на Postgress
Он вроде бы нормально работает с хранинмыми процедурами.

[MaDDog]

А можно еще проще..

Вар1: Та же хранимая процедура никакими сессиями не занимается, выбирает из параметров подключения UID, через таблицу согласования смотрит ID юзера и соответственно выполняет запрос и возвращает данные.

Вар2: Вариант уродский, но работает везде(!), даже с MySQL
Для каждого пользователя, кому нужен такой сервис, создается представление, возвращающее только его записи. Доступ имеет только этот самый юзер. В клиенте, исходя из имени юзера составляется запрос именно к тому view, к которому надо.
Понятно, что если пользователей сотни, то вариант не подходит. Но тогда - серьезная СУБД и Вар1.

[Борис]

Вариант 2 самый естественный, так как в конечном счёте доступ к таблицам определяется индивидуально по каждой таблице и по каждому пользователю (поэтому лего создавать представления для каждой таблицы), но, к сожалению, вариант не работает для добавления/обновления данных.

100%-ный вариант -- переписать сервер (по сути вар. 1), чтобы он ко всем запросам добавлял фильтр WHERE. Но трудно.

[pnchl]

Почитай в хелпе по Oracle "Establishing Security Policies" - там описано, как установить разделение доступа на уровне записей. Сервер как раз добавляет неявное условие в WHERE...

[pnchl]

В Oracle есть такая функция - userID - она возвращает имя текущего пользователя. Можно вообще не давать доступа на чтение из таблицы с данными, а создать представление:

create view1 as select * from table1 t where t.user_name = userID

Более того, в Oracle можно вообще не давать никакого доступа к таблице, а дать доступ на запись (!) в представление. При этом для представления должен быть опеределен триггер INSTEAD OF (INSERT или UPDATE). Пользователи будут считать, что работают с реальной таблицей с полными данными...