Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Архив форумов ЦИТФорума
Море(!) вопросов - Море(!) ответов
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 
Как правильно задавать вопросы

Ограничение доступа к данным таблиц БД на уровне записей

 
Перейти:  
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Базы данных
Предыдущая тема :: Следующая тема  
Автор Сообщение
=^.^=



Зарегистрирован: 14.07.2008
Сообщения: 4

СообщениеДобавлено: Пн Июл 14 2008 22:18    Заголовок сообщения: Ограничение доступа к данным таблиц БД на уровне записей Ответить с цитатой

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



Зарегистрирован: 05.04.2005
Сообщения: 1242
Откуда: Москва

СообщениеДобавлено: Вт Июл 15 2008 07:45    Заголовок сообщения: Ответить с цитатой

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

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

Wink
_________________
Errare humanum est
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
=^.^=



Зарегистрирован: 14.07.2008
Сообщения: 4

СообщениеДобавлено: Вт Июл 15 2008 10:48    Заголовок сообщения: Ответить с цитатой

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



Зарегистрирован: 09.03.2005
Сообщения: 311

СообщениеДобавлено: Вт Июл 15 2008 21:42    Заголовок сообщения: Ответить с цитатой

А есть ли необходимость хранить данные всех пользователей в общей таблице? Может быть, стоит дать каждому по персональной таблице (название совпадает с user_id)?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
=^.^=



Зарегистрирован: 14.07.2008
Сообщения: 4

СообщениеДобавлено: Ср Июл 16 2008 10:30    Заголовок сообщения: Ответить с цитатой

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



Зарегистрирован: 09.03.2005
Сообщения: 311

СообщениеДобавлено: Ср Июл 16 2008 10:37    Заголовок сообщения: Ответить с цитатой

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



Зарегистрирован: 14.07.2008
Сообщения: 4

СообщениеДобавлено: Пт Июл 18 2008 17:54    Заголовок сообщения: Ответить с цитатой

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

CREATE DATABASE 'localhost:C:\mybase.fdb'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 4096
DEFAULT CHARACTER SET NONE;

CREATE TABLE "test" (
  "id"  BIGINT NOT NULL,
  PRIMARY KEY ("id")
);

CREATE SEQUENCE "id_counter";

ALTER SEQUENCE "id_counter" RESTART WITH 0;

SET TERM ^ ;

CREATE TRIGGER "on_insert" FOR "test"
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (NEW."id" IS NULL) THEN
  NEW."id" = GEN_ID("id_counter",1);
END^

SET TERM ; ^

При добавлении он вопит что поле id не заполнено, почему не отрабатывает триггер? Приношу извинения за свои тупые вопросы новичка.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dimasm



Зарегистрирован: 25.04.2005
Сообщения: 454

СообщениеДобавлено: Ср Июл 23 2008 13:13    Заголовок сообщения: Ответить с цитатой

=^.^= писал(а):
А можно ли ограничив доступ к базе данных (только чтение), создать что-то вроде хранимой процедуры для внесения изменений (добавление, удаление, редактирование записей)?

можно...
для этого, к табличке, где доступ нужно по строкам разделять, добавляешь поле user, в которое будешь указывать пользователя котому можно коннектиться... пользователь "видит" только хранимки
а в хранимке, когда делаешь выборку, пишешь так..
...
WHERE user_name = USER()
ну и если дальше развить, то понятно, что не имя, а ID, что не одно поле, а отдельную таблицу доступа
...WHERE access_id IN (SELECT access_id FROM access_table WHERE row_id=... AND user_id=421)
я немного не точно написал, но всё примерно в этом духе...
пробовал аналогично делать, отлично работает... как минус - надо отдельную табличку с пользователями держать, что, как говорят, плохо для безопасности
_________________
С уважением Dimasm
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
iv250973



Зарегистрирован: 30.11.2007
Сообщения: 12

СообщениеДобавлено: Ср Июл 30 2008 09:39    Заголовок сообщения: Ответить с цитатой

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

Совершенно концептуально-неправильный подход. Ни один из существующих способов проектирования БД (сущность-связь, к примеру) не допускает такого использования таблиц. Реляционная таблица по сути есть проекция некоторого класса сущностей.
Если пойти по такому пути, то появится куча проблем, главная из которых - возможное огромное число таблиц. Запрос (а вьюшка по сути есть результат запроса), использующий такое кол-во таблиц будет выполняться гораздо медленнее, чем запрос к одной таблице. А в случае добавления или удаления юзера, ссылочную целостность придётся поддерживать нереляционными средствами, что тоже очень плохо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
and3008



Зарегистрирован: 12.10.2001
Сообщения: 14893
Откуда: Н.Новгород

СообщениеДобавлено: Вс Окт 19 2008 23:46    Заголовок сообщения: Ответить с цитатой

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


http://www.zoonman.com/library/mysql_sr_and_t.htm
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
pa_han87



Зарегистрирован: 14.04.2006
Сообщения: 19

СообщениеДобавлено: Сб Ноя 15 2008 23:41    Заголовок сообщения: Ответить с цитатой

Ограничение доступа на уровне записей точно есть в Oracle (Database Vault кажется называется)
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
v_max



Зарегистрирован: 28.11.2008
Сообщения: 1

СообщениеДобавлено: Пт Ноя 28 2008 15:10    Заголовок сообщения: Ответить с цитатой

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



Зарегистрирован: 18.02.2005
Сообщения: 247

СообщениеДобавлено: Ср Дек 03 2008 10:56    Заголовок сообщения: совет новичкам: стреляйте в лоб -- не попадёте в Библию Ответить с цитатой

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

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

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

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

некоторые участники форума думают, что для решения вопроса доступа на уровне записей можно использовать триггеры и хранимые процедуры. это верно, но это стрельба из пушки по воробьям и по трудозатратам, и по результатам.
-------------------------------------------------------------------
из книги "Киллерство для чайников": всегда делайте контрольный выстрел в лоб, потому что предыдущий выстрел в грудь попал клиенту в подаренную ему любимой девушкой Библию в металлическом переплёте, которую клиент носил у сердца
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Базы данных Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2002 phpBB Group
Русская поддержка phpBB

 

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 6608306, ICQ 232284597
Пресс-релизы — pr@citforum.ru
Послать комментарий
Информация для авторов
This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2006 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...