Вопрос по секьюрити

Господа здравствуйте.

Есть потребность в реализации секьюрити такого характера:

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

Необходимо предоставить пользователям механизм , который бы позволял, например, выбирать(возможно добавлять, удалять, модифицировать) информацию из этой таблицы. НО сделать это надо так, чтобы пользователь, работающий с таблицей видел только свои данные и не видел чужих. И при этом не просто не видел, но и не имел физической возможности доступа к ним отказавшись, скажем от приложения, которое работает с данной базой, а получив доступ туда просто ручками через СКЛ консольку. Соотв. для этого в таблице будут естественно поля типа ИД_ЮЗЕР.
Я вот что думаю. Если бы это было возможно, то организовать сей механизм так:

Админ создает таблицу. Когда требуется дать юзеру права на выборку данных из неё, то Админ создает ХранимуюПроцедуру (ХП), которая по ИД Юзера осуществляет в выражении WHERE контроль выбираемых значений, чтобы в конечную выборку попадали только те значения, которые принадлежат пользователю.
Далее.. Пользователь работает с этой таблицей только с помощью ХП, права на выполнение которой дает ему Админ, потому что прямых грантов на выборку данных ему не дано. И эта ХП единственный способ получить доступ к данным. Таким образом он никак не сможет при всем желании увидеть данные др. юзера.

В данном примере ХП я представил в виде объекта посредника, который может запускаться юзером, которому даны права на его выполнение, однако этот объект (в данном случае ХП) запустившись работает в контексте своего создателя, т.е. админа, а потому имеет доступ к таблице. Т.е. в этом случае ХП выступает в роли некоторого секьюрити-моста.

Описанный выше пример сделать нельзя, как я понимаю. Потому что ХП будет запускаться в контексте юзера, а значит она не сможет выбрать данные из таблицы, потому что доступа к ней(таблице) у неё не будет.

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

Спасибо.

см. в BOL SUSER_SNAME()

дать юзеру доступ не к таблице а к ее представлению с фильтром WHERE ПолеЮзер=SYSTEM_USER

ХП работать будет если у пользователя есть права на ее исполнение.
Если таблицы, к которым обращаются хп принадлежат одному и тому же пользователю (напр. dba), то при обращения к таблицам из хп проблем не будет. Это называется Ownership Chains (см BOL).
То есть даете пользователю права на исполнения SP и не даете права на таблицу.

блин, сам не понял что написал :-)
короче:
1. создаете все таблицы как dbo.tablename
2. создаете хп dbo.procname с параметром userid, в ней обращаетесь к таблицам.
3. создаете application role или просто пользователя базы "app"
4. даете app execute permission на dbo.procname
5. коннектитесь во время работы как app.

приложение сможет выполнить процедуру, но не сможет напрямую обращатся к таблицам.

ps. RTFM Ownership Chains, Application Role

To Latuk: дать юзеру доступ не к таблице а к ее представлению с фильтром WHERE ПолеЮзер=SYSTEM_USER

И что это даст? Юзер ведь все равно спокойно сможет зайти через СКЛ-консоль и сделать выборку из главной таблицы какую-только захочет.

To Genady: см. в BOL SUSER_SNAME()

Не знаю, что это такое, щас смотреть буду, спасибо.

To Shura_M: блин, сам не понял что написал :-)
короче:
1. создаете все таблицы как dbo.tablename
2. создаете хп dbo.procname с параметром userid, в ней обращаетесь к таблицам.
3. создаете application role или просто пользователя базы "app"
4. даете app execute permission на dbo.procname
5. коннектитесь во время работы как app.

приложение сможет выполнить процедуру, но не сможет напрямую обращатся к таблицам.

ps. RTFM Ownership Chains, Application Role

Т.е. Вы фактически описали ту же схему, что и я в своем вопросе. Что-то я сомневаюсь что это работать будет. Ведь хранимая процедура будет выполняться в контексте юзера, её вызвавшего, а у этого app прав доступа к таблице нету.. Значит и выполнение ХП провалится. Так ведь? Каждый юзер работает ведь в своей области видимости...

To Latuk: дать юзеру доступ не к таблице а к ее представлению с фильтром WHERE ПолеЮзер=SYSTEM_USER

И что это даст? Юзер ведь все равно спокойно сможет зайти через СКЛ-консоль и сделать выборку из главной таблицы какую-только захочет.

To Genady: см. в BOL SUSER_SNAME()

Не знаю, что это такое, щас смотреть буду, спасибо.

To Shura_M: блин, сам не понял что написал :-)
короче:
1. создаете все таблицы как dbo.tablename
2. создаете хп dbo.procname с параметром userid, в ней обращаетесь к таблицам.
3. создаете application role или просто пользователя базы "app"
4. даете app execute permission на dbo.procname
5. коннектитесь во время работы как app.

приложение сможет выполнить процедуру, но не сможет напрямую обращатся к таблицам.

ps. RTFM Ownership Chains, Application Role

Т.е. Вы фактически описали ту же схему, что и я в своем вопросе. Что-то я сомневаюсь что это работать будет. Ведь хранимая процедура будет выполняться в контексте юзера, её вызвавшего, а у этого app прав доступа к таблице нету.. Значит и выполнение ХП провалится. Так ведь? Каждый юзер работает ведь в своей области видимости...

Хотя возможно я и не прав.. Я с МС СКЛ не пробовал ещё, вечером дома буду пытать его. Но в Оракле такое не прокатит, вот я оттуда и отталкиваюсь..

Ведь хранимая процедура будет выполняться в контексте юзера, её вызвавшего, а у этого app прав доступа к таблице нету.. Значит и выполнение ХП провалится. Так ведь? Каждый юзер работает ведь в своей области видимости...

В случае если процедура и все объекты к которым она обращается принадлежат обному и томуже юзеру (dbo), то права доступа проверяются только на самом верхнем уровне, а права на нижележащие объекты не проверяются. Это называется Ownership Chains и это описано в BOL.
Если вы хотите разобраться с секьюрити SQL сервера обязательно прочитайте про это.
А работать будет точно.

дай свому юзеру грант тильки на инcерт,значит испортить,удалить он не смогет.Поле ID заполняй через триггер,сфальшифить ID станет не просто,исполнительную силу давай самой юной записи,остальных вроде как и нет,по утрам ,с опохмелки,удалишь ЛИШНЕЕ САМ и все.

Не знаю, что это такое, щас смотреть буду, спасибо.
Это функция, которая возвращает имя юзера, добавшь в таблицу столбец с именем, а потом когда юзер подключится будешь выдавать ему отфильтрованые данные через ХП или вью.