Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Ограничение пользователя только на чтение данных  [new]
-ALS78-
Member

Откуда:
Сообщений: 53
Доброго времени суток!

Имею задачу. Система должна предоставить функционал по выполнению произвольных скриптов, написанных пользователем, для сбора аналитики и отчетности...

При этом система должна выполнять эти скрипты, не давая выполнить никаких действий, производящих любую модификацию БД. Т.е. исключительно Read-Only доступ. При этом пользователю можно использовать предоставленные системой табличные и скалярные функции для вычисления каких-то шаблонных вещей.

Я создал в БД юзера ReportUser, под которым выполняю скрипты...

У юзера следующие полномочия и роли:
1. server role: Public
2. db role: db_datareader, db_denydatawriter
3. db permission: Execute

Думал, задачу решил. Однако не тут то было... Юзер может выполнить мои хранимки, которые удаляют или модифицируют записи в таблицах.

Вопросы:
1. Как его ограничить исключительно на чтение данных и выполнение хранимок и функций без возможности изменения данных?
2. Нет вариантов, кроме как давать возможность выполнения для исключительно безопасных функций?
3. Может что еще?

Спасибо.
6 окт 09, 18:14    [7749900]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36814
Ну не надо было давать права на выполнение хранимок.
6 окт 09, 18:37    [7750051]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
^^
Guest
-ALS78-
Имею задачу. Система должна предоставить функционал по выполнению произвольных скриптов, написанных пользователем, для сбора аналитики и отчетности...


То есть Вы изначально легально создаете пользователю все условия для SQL injection, а потом удивляетесь, что он запускает Ваши процедуры, которые модифицируют данные.

Тут, наверное, можно только обрабатывать пользовательский скрипт с точки зрения наличия в нем всяких "запретных" слов, типа "INSERT", "UPDATE" ну и всяких "sp_МояПроцедураКотораяСильноМодифицируетДанные".

В общем, если я вас правильно понял, то тут необходимо применять все классические способы борьбы с SQL injection...

Да и вообще Вы как то не показали как запускаете скрипты именно под тем пользователем которому Вы по Вашему мнению выдали ограниченные права
6 окт 09, 21:41    [7750483]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
-ALS78-
Member

Откуда:
Сообщений: 53
Выполнение скриптов происходит через SqlDataAdapter (.NET Framework 3.5 SP1), полученная DataTable подсовывается MS Excel 2007 в качестве источника данных.

Отвечаю оптом:

1. Про отсечение всяких INSERT, DELETE думали, но хотим решить задачу через ограничение в правах, что более действенно. Пользовать специальный настроенный логин/юзера.

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

Спасибо.
Просьба: Пожалуйста, отвечайте по существу, без общих отступлений типа "сам дурак".. :)
7 окт 09, 07:59    [7751147]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Влом регистрироваться
Guest
-ALS78-,

- выделите процедуры для отчетов (надеюсь, они у вас не производят модификацию данных?) в отдельную схему Report и дайте права EXECUTE юзеру ReportUser только на этой схеме.
- создайте отдельную роль для пользователей, которым разрешено править данные.
- заберите права EXECUTE/INSERT/UPDATE/DELETE у роли public
7 окт 09, 08:45    [7751223]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Александр65
Member

Откуда: Москва
Сообщений: 30
-ALS78-

исключительно Read-Only доступ.


А если решить иначе:
1. Создать новую базу для отчетов
2. Скопировать туда данные
2. Перевести в Read-Only
3. Присвоить права пользователю только на новую базу
4. По желанию - настроить автоматическое копирование рабочей базы, подъем в новую.

Итог - предоставлен функционал по выполнению произвольных скриптов, написанных пользователем, для сбора аналитики и отчетности.
На рабочей базе изменения данных не происходит.
За корректность отчетов отвечает пользователь.
7 окт 09, 10:01    [7751543]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
ТАРАКАН
Member

Откуда:
Сообщений: 439
db_denydatawriter разве не запрещает модификацию данных в БД ?
7 окт 09, 10:13    [7751621]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Glory
Member

Откуда:
Сообщений: 104760
ТАРАКАН
db_denydatawriter разве не запрещает модификацию данных в БД ?

Она запрещает модификацию явной командой. А в процедурах действуют цепочки владения

Сообщение было отредактировано: 7 окт 09, 10:40
7 окт 09, 10:40    [7751805]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
ТАРАКАН
Member

Откуда:
Сообщений: 439
а проверку в процедурах нельзя установить на то , что если у пользователя нет доступа на запись то сказать ему досвидание?
7 окт 09, 10:59    [7751951]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Glory
Member

Откуда:
Сообщений: 104760
ТАРАКАН
а проверку в процедурах нельзя установить на то , что если у пользователя нет доступа на запись то сказать ему досвидание?

Зачем давать права тогда на эту процедуру ??
7 окт 09, 11:00    [7751958]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
ТАРАКАН
Member

Откуда:
Сообщений: 439
Glory
ТАРАКАН
а проверку в процедурах нельзя установить на то , что если у пользователя нет доступа на запись то сказать ему досвидание?

Зачем давать права тогда на эту процедуру ??

выходит что надо создать набор доступных процедур для пользователя.
7 окт 09, 11:46    [7752315]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Влом регистрироваться
Guest
Александр65,

а кто будет делать синхронизацию данных?
7 окт 09, 12:03    [7752461]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Александр65
Member

Откуда: Москва
Сообщений: 30
Влом регистрироваться
Александр65,

а кто будет делать синхронизацию данных?


Job, конечно, каждую ночь. Так что если пользователь накосячил и все удалил - можно отвечать пословицей: "Утро вечера мудренее."
8 окт 09, 19:41    [7761185]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Влом регистрироваться
Guest
Александр65,

а Job кто будет настраивать? Блин, вот нет, чтобы просто - как по букварю - настроить права, надо изобретать велосипед и наживать себе нешуточный геморрой.
9 окт 09, 06:43    [7762153]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Александр65
Member

Откуда: Москва
Сообщений: 30
Влом регистрироваться
Александр65,

а Job кто будет настраивать? Блин, вот нет, чтобы просто - как по букварю - настроить права, надо изобретать велосипед и наживать себе нешуточный геморрой.


Не согласен.
1. Даже после прочтения букваря и настройки прав есть вероятность что -нибудь не учесть.
Цена ошибки в настройке - изменение данных в живой базе. Причем проблема может всплыть спустя некоторое время и восстановиться из backup не получится, т.к. он уже содержит искаженные данные.
2. Имея зеркальную базу, да еще на другом сервере - пользователей с отчетами можно отправить туда. Нагрузка на основной сервер снизится.
3. Съэкономленое на настройке прав время (пользователи добавляются, убывают и т.д) тратим на:
1 раз настраиваем Job, остальное по собственному усмотрению.
4. Гарантировано имеем копию живой базы по состоянию на - 1день.
5. То, что сделался backup может контролировать даже не специалист.

на счет нешуточного геморроя я не понял он в чем? 1 раз настроить Job? А backup у Вас как делается?
9 окт 09, 10:12    [7762640]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Влом регистрироваться
Guest
Александр65,

> 1. Даже после прочтения букваря и настройки прав есть вероятность что -нибудь не учесть.
Такая вероятность есть и при настройке Job'а (ну фича же не в настрочке джоба, а в действиях, что он делает?) А искусственную синхронизацию (если только не через backup-restore) делать куда более затратно и потенциально глючно.

> 2. Имея зеркальную базу, да еще на другом сервере - пользователей с отчетами можно отправить туда. Нагрузка на основной сервер снизится.
Не спорю, но если нужны оперативные отчеты (гы, назовем так)? Например, десятки трейдеров в режиме реального времени отслеживают ситуацию на бирже.

> 3. Съэкономленое на настройке прав время (пользователи добавляются, убывают и т.д) тратим на: 1 раз настраиваем Job, остальное по собственному усмотрению.
Во-первых, про настройку Job'а я уже говорил... А что мешает сделать роль ReportViewer и добавлять туда пользователей? Отсутствие букваря?

> 4. Гарантировано имеем копию живой базы по состоянию на - 1день.
Политика резервного копирования спасет отца русской.

> 5. То, что сделался backup может контролировать даже не специалист.
А нафиг?
9 окт 09, 11:43    [7763349]     Ответить | Цитировать Сообщить модератору
 Re: Ограничение пользователя только на чтение данных  [new]
Александр65
Member

Откуда: Москва
Сообщений: 30
quot Влом регистрироваться
> 1. Даже после прочтения букваря и настройки прав есть вероятность что -нибудь не учесть.
Такая вероятность есть и при настройке Job'а (ну фича же не в настрочке джоба, а в действиях, что он делает?) А искусственную синхронизацию (если только не через backup-restore) делать куда более затратно и потенциально глючно.

Имел виду backup-restore. ИМХО более безопасно.

> 2. Имея зеркальную базу, да еще на другом сервере - пользователей с отчетами можно отправить туда. Нагрузка на основной сервер снизится.
Не спорю, но если нужны оперативные отчеты (гы, назовем так)? Например, десятки трейдеров в режиме реального времени отслеживают ситуацию на бирже.

Согласен подходит не для всех.

> 5. То, что сделался backup может контролировать даже не специалист.
А нафиг?

Известна мне такая история:
W2003, SQL200, RAID. backup делался на тот же сервер.

RAID приказал долго жить.

Данные спасали с помощью SQL RECOVERY.

Часть данных в покореженном виде.

Восстанавливали долго и нудно.


На сейчас тамошний директор хочет ЛИЧНО проверять сохранность данных. При данном варианте сделать это легко. А еще варианты какие? При нем каждый раз делать restore?


Все ИМХО.
9 окт 09, 13:21    [7764402]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить