Разграничение прав доступа
ты хоть субд скажи
Информативно... Хоть бы описал что и с помощью чего делаешь...
Почитай книжки.
ЗЫ: какой вопрос, такой ответ.
Почитай книжки.
ЗЫ: какой вопрос, такой ответ.
субд - MS SQL.
Интерфейс к БД на builder C++.
В базе ведется учет клиентов и продаж.
Конкретная проблема заключается в том, что надо запретить некоторым пользователям просматривать определенную информацию о клиенте (в частности паспортные данные и контактную информацию).
В базе ведется учет клиентов и продаж.
Конкретная проблема заключается в том, что надо запретить некоторым пользователям просматривать определенную информацию о клиенте (в частности паспортные данные и контактную информацию).
Ну в чем проблема запретить это на стороне БД?
вот с этого момента поподробнее.
создаем отдельную таблицу в секретной инфыормацием, отдельную -- со всей остальной. Ключ -- общий.
далее кому-то даем в секретной читать, а кому-то -- нет.
Ни в коем случае нельзя делать проверку на стороне клиента. это примерно как проверять правильный ли пароль на стороне клиента и отвечать серверу правильный ввели или нет
далее кому-то даем в секретной читать, а кому-то -- нет.
Ни в коем случае нельзя делать проверку на стороне клиента. это примерно как проверять правильный ли пароль на стороне клиента и отвечать серверу правильный ввели или нет
хмм.
а это же не расширяемое решение.
рассмотрим
такой пример
Таблица
ИНН
НОМЕРПАСПОРТА
ТЕКУЩИЙ СЧЕТ
АДРЕС
ФИО
ТЕКУЩИЙ НОМЕР ЗАКАЗА
...итд
допустим для бухгалтерской отчетности надо предоставлять ИНН. НОМЕРПАСПОРТА. ТЕКУЩИЙ СЧЕТ. АДРЕС. ФИО.
для курьера номер заказа и адрес,
а для охранника на вахте номер паспорта и фио.
как тогда быть?
а это же не расширяемое решение.
рассмотрим
такой пример
Таблица
ИНН
НОМЕРПАСПОРТА
ТЕКУЩИЙ СЧЕТ
АДРЕС
ФИО
ТЕКУЩИЙ НОМЕР ЗАКАЗА
...итд
допустим для бухгалтерской отчетности надо предоставлять ИНН. НОМЕРПАСПОРТА. ТЕКУЩИЙ СЧЕТ. АДРЕС. ФИО.
для курьера номер заказа и адрес,
а для охранника на вахте номер паспорта и фио.
как тогда быть?
клиент делает запрос не к базе напрямую, а к надстройке над базой
В догонку. Предположим у нас система, стоит в сотовой компании и позволяет определять по номеру телефона его владельца. Среди пользователей системы есть операторы поддержки, которые имеют право обращаться за информацией только в рабочее время. А во все остальное не могут. Тогда такое решение становится совсем неприемлемым.
сделать представления этой таблицы для бухгалтера, охранника, еще каких-нибудь юзеров и назначить на серваке нужный доступ
Ну это целая наука информационной безопасности, читай любые книжки в какие есть в доступности.
В электронном виде легко достать например Грушо А.А. Тимонина Е.Е. "Теоретические основы защиты информации"
1996 г. Издательство Агентства “Яхтсмен”
А вообще это решается с помощью прослойки, обеспечивающей безопасность доступа. В общем виде задача не решена.
Чаще всего ее пытаются решить с помощью создания этой прослойкой некоторых проекций базы данных доступных только одному пользователю
(одной группе пользователей). Например, удобно использовать оракловские view. Самая сложность - доказать, что эти самые view выдают информации не больше чем разрешается пользователю. Для этого существует множество методов, но их использование
сильно поднимет стоимость такого проекта, так что может и заморачиваться не надо. Чаще всего хватает списков ACL для полей и юзеров, либо вынесения секретной информации в отдельную таблицу и использования внутренних механизмов безопасности БД.
В электронном виде легко достать например Грушо А.А. Тимонина Е.Е. "Теоретические основы защиты информации"
1996 г. Издательство Агентства “Яхтсмен”
А вообще это решается с помощью прослойки, обеспечивающей безопасность доступа. В общем виде задача не решена.
Чаще всего ее пытаются решить с помощью создания этой прослойкой некоторых проекций базы данных доступных только одному пользователю
(одной группе пользователей). Например, удобно использовать оракловские view. Самая сложность - доказать, что эти самые view выдают информации не больше чем разрешается пользователю. Для этого существует множество методов, но их использование
сильно поднимет стоимость такого проекта, так что может и заморачиваться не надо. Чаще всего хватает списков ACL для полей и юзеров, либо вынесения секретной информации в отдельную таблицу и использования внутренних механизмов безопасности БД.
1. В MS SQL 2000 можно управлять правами доступа прямо на столбцы.
2. Лучше в таких случаях делать разные представления, предназначенные для различных групп пользователей.
2. Лучше в таких случаях делать разные представления, предназначенные для различных групп пользователей.
Очень даже расширяемое -- разбивкой на две таблицы.
Не надо хотеть сделать мегапупер универсально, это невозможно в принципе. Нужно решать задачи по мере их поступления.
На худой конец можно по отдельной таблице на каждый параметр. Если возникнут проблемы с большим числом запросов -- кэширование на стороне клиента должно решить проблему.
Вообще, специфику задачи надо знать, универсальное решение обычно самое говняное...
Не надо хотеть сделать мегапупер универсально, это невозможно в принципе. Нужно решать задачи по мере их поступления.
На худой конец можно по отдельной таблице на каждый параметр. Если возникнут проблемы с большим числом запросов -- кэширование на стороне клиента должно решить проблему.
Вообще, специфику задачи надо знать, универсальное решение обычно самое говняное...
вот это я и хотел узнать. спасибо.
Содай вместо нее несколько: одну с физ.лицами - ключевую, а все остальное, паспотрные данные в отдельную, адреса в другую, тем более адресов может быть несколько, а не один единственный, на физ лицо
согласен
Не надо хотеть сделать мегапупер универсально, это невозможно в принципе. Нужно решать задачи по мере их поступления.
На худой конец можно по отдельной таблице на каждый параметр. Если возникнут проблемы с большим числом запросов -- кэширование на стороне клиента должно решить проблему.добавление нового поля => новая таблица => не лучшее решение
согласен
Вообще, специфику задачи надо знать, универсальное решение обычно самое говняное...
забей это первое что мне в голову пришло, просто я посчитал решение пианиста не идеальным.
новая таблица => не лучшее решениепереход объясни
таблица в тридцать полей => 30 таблиц => многовато
30 таблиц => многоватотоже не очень ясно
к тому же не понятно, как это связано с предыдущей проблемой
ну ты прикинь таблиц с данными около 30 ти в каждой в среднем по 10 полей, твое решение предлагает, дополнительно 300 таблиц. имхо решение неудачное
в каждой по ДВА поля -- ключ и значение
я думаю можно меньше сделать, не надо такого дробления
я думаю можно меньше сделать, не надо такого дробления
Плохо с отдельными таблицами. Таблицы делаются так, чтобы данные правильно лежали. Зачем всем пользователям делать джойны, только потому, что какой-то группе нельзя иметь доступ к определенным полям. ИМХО самое правильное решение, как Номакс сказал, с помощью представлений (view). Представления полезно использовать и без проблем с правами доступа, хотя бы по тому, что в будущем, посмотрев на характер запросов к базе, захочется поменять таблицы (например, выделить редко используемые и объемные столбцы в отдельную таблицу). А то, потом несчастным админам базы придется извращаться с материальными представлениями и делать покрывающие индексы, что в свою очередь негативно скажется на других операциях с базой, не говоря уже о ее объеме.
Да надо знать специфику задачи, прежде чем решать. Из того, что тут написано, -- мое самое простое и понятное, а нужны ли будут джойны -- не факт
Твое решение не работает в случае возможности таких
Чем оно еще не работает? Как раз все работает.
как ты обойдешься без джойнов?
где? запрос придумай
создаем отдельную таблицу в секретной инфыормацием, отдельную -- со всей остальной. Ключ -- общий.Я верно понял, что решение давать кому-то из секретной таблицы читать или нет принимается, проверяя права пользователя, выполняющего запрос, на эту таблицу средствами СУБД? Тогда не понимаю, как ты собираешься давать/отнимать права в зависимости от времени суток. Объясни, пожалуйста.
далее кому-то даем в секретной читать, а кому-то -- нет.
Ни в коем случае нельзя делать проверку на стороне клиента. это примерно как проверять правильный ли пароль на стороне клиента и отвечать серверу правильный ввели или нет
Если БД не позволяет это сделать, то мануально в крон прописал бы блокировку аккаунтов.
> Среди пользователей системы есть операторы поддержки, которые имеют право обращаться за информацией
только в рабочее время. А во все остальное не могут
Это уже не ограничение по безопасности.
Это уже чисто административное ограничение, которое можно и на стороне клиента делать.
только в рабочее время. А во все остальное не могут
Это уже не ограничение по безопасности.
Это уже чисто административное ограничение, которое можно и на стороне клиента делать.
ограничение, которое можно и на стороне клиента делать."Вам идиница, молодой человек!"
Никакие ограничения нельзя вводить на стороне клиента. Только подсказки, мол, вы обломаетесь, но можете попробовать.
Безопасность и обеспечение целостности - необходимо делать на сервере.
Административные ограничения, красивую защиту от дурака, удобства - лучше делать на клиенте.
Административные ограничения, красивую защиту от дурака, удобства - лучше делать на клиенте.
Защиту от дурака на сервере делать необходимо. Дураки разные бывают.
На клиенте я в принципе не понимаю как можно проверить время. Ибо часы всегда можно перевести
На клиенте я в принципе не понимаю как можно проверить время. Ибо часы всегда можно перевести
Зачем делать защиту от дурака на сервере, если там уже есть обеспечение целостности?
Ай, невнимательно читал, да, ты прав...
1. В MS SQL 2000 можно управлять правами доступа прямо на столбцы.Мне надо на строки =(
Информация обо всех клиентах хранится в одной таблице. Клиенты делятся на несколько категорий. В зависимости от категории клиента и соответствующих прав оператора, последний либо может просматривать инфу, либо нет.
2 :
Спасибо, гляну.
конечно, через views c горизонтальным разбиением
самый простой способ в этом случае разбить все данные в таблице по иерархии каталогов (как в explorer-e) и давать права юзерам на сам каталог. Можно конечно и на Row давать но ихмо героройнее намного.
это как ?
суть в том, что разграничение доступа делается на уровне приложения (ч/з Application Server к примеру)
это как ?что как ?
т.е. не на уровне бд, а через прослойку?
Оставить комментарий
Slavaga
В некоторой программке (интерфейс к БД) надо сделать разделенный доступ к данным. Пару велосипедов я уже изобрел