|
|
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
Добрый день. Начал разбираться в проектировании БД и систем, и возник следующий вопрос: Предположим есть задача создать довольно крупную систему и БД к ней, тема в принципе значения не имеет. Основные требования такие: 1) В данной системе может быть любое кол-во пользователей 10....n в разумных приделах конечно.:) 2) Приложение создается полностью на модульной основе с периодическим добавлением новых модулей и новым функционалом, т.е изначально не известен полный функционал системы. 3) Большое кол-во различных вариаций доступа к тем или иным данным в БД. Так вот, как лучше всего организовать доступ пользователей из ПО в БД: 1) ПО подключается к БД под одной какой-то определенной учетной записью с длинным стойким паролем и доступом на запись во все таблицы, доступы непосредственного пользователя разграничиваются программно непосредственно в ПО по выбранным в нем доступам. 2) Писать очень большой доп. модуль к ПО который будет создавать конкретных пользователей в БД и раздавать им гранты на структуру таблиц, на основе необходимых доступов в ПО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2010, 16:24 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoserПредположим есть задача создать довольно крупную систему и БД к ней, тема в принципе значения не имеет . Обычно создаётся БД и системы к ней А вот с темой я бы не торопилась с голословным утверждением. Есть законы обеспечения конфидециальности тех или иных данных и доступа к ним различными уровнями пользователей. Коллега - я бы обратилась с ЭТИМИ вопросами к хранителям безопасности Вашего Бизнеса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2010, 16:48 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoser1) ПО подключается к БД под одной какой-то определенной учетной записью с длинным стойким паролем и доступом на запись во все таблицы, доступы непосредственного пользователя разграничиваются программно непосредственно в ПО по выбранным в нем доступам. Только надо обеспечить недоступность этого пароля ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2010, 17:49 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoser 1) ПО подключается к БД под одной какой-то определенной учетной записью с длинным стойким паролем и доступом на запись во все таблицы, доступы непосредственного пользователя разграничиваются программно непосредственно в ПО по выбранным в нем доступам. 2) Писать очень большой доп. модуль к ПО который будет создавать конкретных пользователей в БД и раздавать им гранты на структуру таблиц, на основе необходимых доступов в ПО. Дык, а что в первом случае вам не надо писать модуль для управления доступами? На счёт размера модуля я сомневаюсь. Можно под каждый новый модуль сразу создавать роли БД и из админского РМ выдавать их пользователям. Можно сразу ограничиться ролью "<модуль> только чтение" и ролью "<модуль> полный доступ" и т.д. Впринципе этот модуль должен уметь манипулировать учётными записями пользователей. Создавать иерархию ролей, отвечающую функциональной структуре предпрития, назначать роли учётным записям. Если в системе предусмотрен кадровый учёт, то возможно потребуется функция синхронизации системных учётных данных с системой кадрового учёта и наоборот. Как бы вариантов использования не много. Как раз тот случай, когда бизнес логику (разграничение доступа) следует сосредоточить в СУБД а не в клиентских модулях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2010, 14:47 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
Vika VinnerОбычно создаётся БД и системы к ней +1 pilesoser1) ПО подключается к БД под одной какой-то определенной учетной записью с длинным стойким паролем и доступом на запись во все таблицы, доступы непосредственного пользователя разграничиваются программно непосредственно в ПО по выбранным в нем доступам. Имеется ввиду, что длинный стойкий пароль "зашит" в самом ПО? Очень плохое решение. И что означает фраза "доступы непосредственного пользователя разграничиваются программно непосредственно в ПО по выбранным в нем доступам"? Каждый модуль сам решает, что можно, а что нельзя? pilesoser2) Писать очень большой доп. модуль к ПО который будет создавать конкретных пользователей в БД и раздавать им гранты на структуру таблиц, на основе необходимых доступов в ПО. Во-первых, более-менее развитые СУБД поставляются с готовыми инструментами для управления доступом пользователей. Почему вы так уверены, что функциональности этой "тулзы" не хватит? Во-вторых, с чего вы взяли, что это "очень большой" модуль? В-третьих, нафига пользователям "гранты на структуру таблиц"? О чем речь-то? Вобщем? поддерживаю мнение mcureenab: разбирайтесь с ролями. Есть еще вполне рабочий вариант: огранизация работы клиентского ПО через хранимые процедуры и раздача прав на их запуск, опять же через роли БД. В этом случае "клиент" вообще ничего не знает о структуре таблиц. И это хорошо! (c) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2010, 15:21 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
Добрый день, извиняюсь за долгое отсутствие. Возможно, да написал не совсем понятно, попробую подойти с другого бока. Итак: Задача: 1) Предположим есть самая проста задача хранить в БД какие-то действия пользователей. Для простоты пусть это будет 2 поля в одной таблице БД ( имя пользователя, действие). 2) Кол-во таких пользователей заранее не известно. 3) Каждый такой пользователь должен иметь имя и пароль чтобы смотреть свои действия, а так же действия того пользователя к которому ему может быть предоставлен доступ. 4) Есть какой-то графический интерфейс для работы с системой. 5) Создание пользователей, раздача доступов должно происходить в данном GUI, без использования встроенных менеджеров SQL серверов. Вопрос: Каким образом предоставлять доступ пользователей и приложения к БД? Варианты: 1) Каждому пользователю программным путем через GUI создавать пользователя на SQL сервере давать соответствующие гранты. Но тогда возникает проблема что например продвинутый пользователь может напрямую подключиться к БД и сделать select всей таблицы по всем пользователям. Выход из данной проблемы я вижу один: использовать схемы для каждого пользователя, но тогда встает например вопрос что делать если нужно произвести какую-то большую выборку по всем пользователями? 2) Использовать один вшитый в приложение стойкий пароль, а права пользователей реализовывать в логике GUI. Но помимо того что данный способ я сам считаю очень нехорошим, то еще возникает проблема с обслуживанием данной БД , например невозможность просмотра какой пользователь сделал блокировку в БД. 3) Возможно где я ошибаюсь изначально. :) P.S: Пример полностью выдуманный, а сам проект как таковой не делается внутри конкретной компании, по-этому ответы типа "решение о рисках ухода той или иной информации должны принимать руководители" не предлагать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 14:37 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoserВопрос: Каким образом предоставлять доступ пользователей и приложения к БД? Если это вопрос чисто теоритический, то применяем на практике такой подход. - что-то указываем в некой группе доступа - в конкретном пароле перечисляем в какие он группы входит + добавляем некие индивидуальные установки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 16:18 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoser 3) Возможно где я ошибаюсь изначально. :) Точно, вот здесь pilesoser 1) <skipped>продвинутый пользователь может напрямую подключиться к БД и сделать select всей таблицы по всем пользователям<skipped> Права нужно (и ведь можно!) хранить так, чтобы никакой пользователь, кроме админа (возможно даже не системного, и даже не администратора БД, а администратора по безопасности) не имел доступа к всей таблице. Способы решения - зависят от выбранной СУБД... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 16:24 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
А вот здесь можно по подробнее. Решение на базе MS Sql 2008. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 16:27 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoserРешение на базе MS Sql 2008. Так это точно не в раздел "Проектирование БД"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 16:28 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
АнатоЛой, есть средства, построенные на шифровании данных, которые позволяют не пускать к открытым данным даже админа. Аудит, резервное копирование - пожалуйста. Расшифровать - фигу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 16:30 |
|
||
|
Организация доступов из приложения к БД
|
|||
|---|---|---|---|
|
#18+
pilesoser 1) Каждому пользователю программным путем через GUI создавать пользователя на SQL сервере давать соответствующие гранты. Но тогда возникает проблема что например продвинутый пользователь может напрямую подключиться к БД и сделать select всей таблицы по всем пользователям. Выход из данной проблемы я вижу один: использовать схемы для каждого пользователя, но тогда встает например вопрос что делать если нужно произвести какую-то большую выборку по всем пользователями?Схемы в топку - не для этого они. Вместо грантов на таблицы - гранты на вьюхи или хранимки которые фильтруют по имени пользователя. pilesoser 5) Создание пользователей, раздача доступов должно происходить в данном GUI, без использования встроенных менеджеров SQL серверов. Даже встроенные менеджеры SQL серверов выдают create user ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 16:57 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=74&tid=1542708]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
83ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
81ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 464ms |

| 0 / 0 |
