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

[=^.^=]

Допустим у нас есть сервер MySQL и приложение на Dephi7 которое соединяется с ним через компонент ZEOSDBO. База состоит из 2-х таблиц, data (произвольные данные) и users (пользователи приложения). Таблицы связаны по полю user_id (один ко многим). Данные в таблице data, могут принадлежать разным пользователям, а контроль за доступом осуществляется только клиентским приложением, немного модифицировав его, злоумышленник может получить доступ к данным других пользователей. Как ограничить доступ пользователей к данным, на уровне записей таблиц? Как можно реализовать механизм контроля доступа пользователей к записям таблиц со стороны сервера?

[grf]

насколько помню в MySQL есть права для пользователей на уровне базы данных, таблиц, столбцов. Так что запретить доступ на уровне записей силами сервера нереально.

Если не так, пусть меня поправят


_________________
Errare humanum est

[=^.^=]

А можно ли ограничив доступ к базе данных (только чтение), создать что-то вроде хранимой процедуры для внесения изменений (добавление, удаление, редактирование записей)? (если такое нельзя реализовать на MySQL, думаю я смогу перенести базу на Interbase или Oracle). Если я не ересь несу, то клиент сможет выполнять запросы на изменение данных только через вызов процедуры, на сервере. Я с хранимыми процедурами знаком только на примере PLSQL и то чуть чуть, прошу сильно не ругать. Мне просто очень не хочется писать серверное приложение, которое будет своего рода прослойкой между базой данных и клиентом .

[C37]

А есть ли необходимость хранить данные всех пользователей в общей таблице? Может быть, стоит дать каждому по персональной таблице (название совпадает с user_id)?

[=^.^=]

К сожалению нет. Таблица с данными, должна быть открыта на чтение всем пользователям и запросы по этим данным буду охватывать все таблицы. Короче говоря запрос примет вид "select * from table_0, table_1, .... table_n" где это n может быть более 500. Запрос слишком длинный.

[C37]

Вместо длинного запроса надо использовать представление (view), тогда пользовательское приложение будет видеть только две таблицы: свою, куда можно писать, и общую (т.е. представление), из которой можно только читать.
Основной «минус» здесь в том, что при добавлении нового пользователя придется обновлять определение представления. Чтобы этого избежать, можно использовать механизм наследования, но, если правильно помню, MySQL его не поддерживает.

[=^.^=]

Бросил затею с MySQL начал изучать FireBird и заткнулся на первом же примере создания полей с autoincrement, так и не понял почему оно не работает.

[Dimasm]

[iv250973]

[and3008]

Поставьте MySQL 5.02 или выше и пользуйте хранимые процедуры и триггеры.


http://www.zoonman.com/library/mysql_sr_and_t.htm

[pa_han87]

Ограничение доступа на уровне записей точно есть в Oracle (Database Vault кажется называется)

[v_max]

Если интересует защита информации на уровне СУБД, можно посмотреть в сторону ЛИНТЕР. Там этому вопросу уделено большое внимание - есть и защита на уровне записей и много чего ещё.
Общее описание системы защиты ЛИНТЕР: http://www.linter.ru/ru/documentation/html/mod_szi.htm

[критикан]

странно, что эта мёртвая ветка никак в могилу не уйдёт. видимо, не хватает моего контрольного выстрела.

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

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

поэтому, если база данных спроектирована правильно -- что означает в том числе полную равнозначность записей в любой заданной таблице, -- то вопроса об ограничении доступа на уровне записей просто не возникает.

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

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

некоторые участники форума думают, что для решения вопроса доступа на уровне записей можно использовать триггеры и хранимые процедуры. это верно, но это стрельба из пушки по воробьям и по трудозатратам, и по результатам.
-------------------------------------------------------------------
из книги "Киллерство для чайников": всегда делайте контрольный выстрел в лоб, потому что предыдущий выстрел в грудь попал клиенту в подаренную ему любимой девушкой Библию в металлическом переплёте, которую клиент носил у сердца