Безопасность для MSSQL

← →
Megabyte © (2006-05-30 11:38) [0]

Вопрос примитивный конечно. Как сделать так ограничения на просмотр таблиц у пользователя в СУБД, у которого стоит Enterprise Manager?(вариант не ставить юзеру менеджер не всегда хорошь %) ) Ведь стоит ему зарегистрировать сервер и поставить аутентификацию через "Windows account information...", и у него есть доступ к таблицам любой базы любого сервака. А мне надо будет к существующей БД делать таблицу с логинами и паролями для удобства разграничения доступа в на клиенте. Шифрованием заниматься не охота.
Неужто надо будет реализовывать права при входе в ОС?

← →
Ega23 © (2006-05-30 11:44) [1]

> Неужто надо будет реализовывать права при входе в ОС?
>

Можно так, а можно идентификацию пользователя на сервере не смешанную установить.

← →
Megabyte © (2006-05-30 12:10) [2]

> а можно идентификацию пользователя на сервере не смешанную
> установить.

Это при установке Манагера указывается? Ну тогда понятно.

← →
evvcom © (2006-05-30 12:13) [3]

> ограничения на просмотр таблиц у пользователя в СУБД, у
> которого стоит Enterprise Manager?

А юзер у тебя что логинится под sa? И о какой тогда безопасности может идти речь?

← →
MOA © (2006-05-30 12:27) [4]

>таблицу с логинами и паролями для удобства разграничения доступа в на клиенте.
А зачем? Встроенные механизмы безопасности скуля лучше, удобнее и надёжнее любой самопальной, а уж таблицы с паролями и логинами...
И их, эти механизмы к тому же не нужно делать - они уже есть ;), ими нужно просто восполдьзоваться.
Удачи!

← →
MOA © (2006-05-30 12:31) [5]

Вдогонку:
>Ведь стоит ему зарегистрировать сервер и поставить аутентификацию через "Windows account information...", и у него есть доступ к таблицам любой баз любого сервака.
Странно. У моих пользователей нет ;), хучь они себе поставь хоть што ;) - если они зашли не под логином админа базы - ничего они не видят кроме того что положено и не могут поменять ничего кроме разрешённого. Причём под любым механизмом аутентификации, а уж gjl Windows accountn - наособицу;).
Кстати, МС не рекомендует использовать SQL Server - аутентификацию, да она и неудобна.

Господа. Я не заведую установкой манагеров для юзеров и пока что понятия не имею, как там все используется. У меня задание, сделать прогу для построения отчета. БД делал не я.

> Странно. У моих пользователей нет ;), хучь они себе поставь
> хоть што ;) - если они зашли не под логином админа базы
> - ничего они не видят кроме того что положено и не могут
> поменять ничего кроме разрешённого. Причём под любым механизмом
> аутентификации, а уж gjl Windows accountn - наособицу;).

Эти пользователи только недавно стали моими. %) Т.е. у тебя логин к БД в манагере реализован через виндовую аутентификацию?

> А зачем? Встроенные механизмы безопасности скуля лучше,
> удобнее и надёжнее любой самопальной, а уж таблицы с паролями
> и логинами...

Ну да, про пароль я загнул, торможу. Просто мне, в зависимости от логина, надо ограничивать построение отчета. Будет нужна доп. таблица с полями(по логину), по которым я буду анализировать ограничения.

>логин к БД в манагере реализован через виндовую аутентификацию?
Не. Не в манагере. А любой логин. Просто - любой. И из манагера в том числе. И дело не в механизме аутентификации - а в установке резрешений - механизм м.б. любой - разрешения-то установлены на уровне базы.
Механизмы скуля поддерживают установку разрешений (грантов) на объёкты базы для отдельных юзеров, групп и ролей (ролями удобнее всего). Не поддерживается установка грантов на диапазон строк таблицы - но это решается зпрещением доступа к таблице и выдачей грантов на вью, возвращающий нужный диапазон - в частности, м. зависить и от юзера (группы, роли...).
От механизма аутентификации не зависит - просто виндовс-аутент. удобна - не нужно заставлять юзеров помнить ещё сто паролей - и безопаснее.
Если именно вид отчёта меняется в зависимости от юзера - скуль предоставляет кучу средств для выяснения "кто это", например USER_ID(), USER_NAME() и прочая и прочая - см BOL Security Functions и ссылки оттуда.
Нет никакой необходимости реализовывать что-то своё - всё уже есть, оттестировано и работает ;).
Удачи!

> Механизмы скуля поддерживают установку разрешений (грантов)
> на объёкты базы для отдельных юзеров, групп и ролей (ролями
> удобнее всего).

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

Лан, разберусь.

Безопасность для MSSQL Найти похожие ветки