Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Kimel
Member

Откуда: Украина
Сообщений: 334
Уже год на предприятии используем программу, чем-то очень похожую на 1С. Похожую скорее тем, что можно расширять функционал как надо.

При заходе в программу идёт авторизация через таблицу dbo.Users, в зависимости от логина и пароля тебе выдаются права и какая-то часть данных будет заблокированная для чтения, какая-та для записи. Но самое удобное это то, что например если у меня логин Kimel, то я вижу только заказы которые я создал, то есть
SELECT * FROM ORDERS WHERE User = 'Kimel'

И так для каждого пользователя.(то есть логин пользователя идёт в WHERE)

Но кажется всему настал конец, я только сейчас понял, что все эти права это сраная иллюзия. На самом деле строка подключения примерно такая
Provider=SQLOLEDB.1;Persist Security Info=False;Data Source=213.0.13.50;User ID=sa;password=132465798;Initial Catalog=Database20;

То есть программа логинится, как sa, а потом считывает все таблицы и настройки уже внутренними программными методами (не методами sql) и блокирует какие-то права.
Теперь достаточно зайти в реестр компьютера и найти запись MsSqlConnectionString и там будет строка подключения с логином и паролем.
А дальше уже не через программу заходишь, а через MSSMS и получаешь все привилегии.

Но я не дурак и подумал, что можно каждому пользователю не только методами программы ограничивать права, но и методами сервера. То есть прописать какие таблицы будет видно ну и так далее.
И вроде бы это должно было решить мою проблему. НО НЕТ ЖЕ!!!!!

Проблема в том, что (по моему) средствами SQL нельзя ограничить для пользователей ЧАСТИЧНУЮ выборку из таблицы. Я имею ввиду не ограничение столбцов которые видно в таблице, а ограничение на значение столбцов. То есть например, в программе для торговле я могу сделать, что бы я мог изменять, только те записи, которые создал сам. Но методами SQL нельзя сделать так(((
То есть нужно запретить выборку
SELECT * FROM TABLE
, а разрешить только
 SELECT * FROM TABLE WHERE USER = 'Login' 
(где вместо Login имя пользователя)

Не знаю, что теперь делать, скорее всего когда об этом узнает начальник, я лишусь работы.
16 июл 13, 01:41    [14570721]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3422
Kimel,

Методами SQL это решить можно, но от одного логина для всех пользователей придется уйти - без этого никак. После этого можно будет сделать все что угодно.
16 июл 13, 05:08    [14570803]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
какое-то трололо похожее на 1с
Guest
Kimel,

от sa в любом случае надо избавиться
как вариант, можно всех загнать под application role/обычную db-role

WHERE User = 'Kimel'
передается же скорее всего параметрами? т.е. опять клиент сам решает кому как чего фильтровать.

автор
от одного логина для всех пользователей придется уйти - без этого никак

например, инициализация после логина сессионных временных (а может и постоянных) табличек.

и, для начала, способ авторизации не подтвержден, используется ли этот sa в коннекшн стринг вообще - не факт.

автор
все таблицы и настройки уже внутренними программными методами (не методами sql) и блокирует какие-то права

как же оно данные фильтрует? читает все, а на клиенте отсекает?
16 июл 13, 07:32    [14570893]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2415
Kimel
я лишусь работы

найдете новую.
вы то здесь причем? вы ее писали? или принимали? много пользователей знают слово "реестр"? опытные злоумышленники найдут еще десяток уязвимостей (у вас база шифруется? доступ в инет есть? от sql-инекций что-то предусмотрено?)

да и до конца вы не разобрались, как же программа рулит правами
16 июл 13, 09:39    [14571145]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Средствами эскуэль вы можете не то, что ограничить "выборку из таблиц", но даже наборы полей для разных пользователей и доступность элементов управления в ГУИ. Все упирается исключительно во время и стоимость разработки.
16 июл 13, 11:36    [14572040]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Kimel


[/src], а разрешить только
 SELECT * FROM TABLE WHERE USER = 'Login' 

Функция с параметрами
Процедура с параметрами
Представление с правами, для выделенного логина\роли
16 июл 13, 11:42    [14572094]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Kimel
Member

Откуда: Украина
Сообщений: 334
Ennor Tiegael
Kimel,

Методами SQL это решить можно, но от одного логина для всех пользователей придется уйти - без этого никак. После этого можно будет сделать все что угодно.


Я согласен уйти от одного имени входа, я даже готов каждому пользователю дать свой логин для базы данных sql. Но я так и не понял как ограничить выборку средствами sql, не изменяя и не дорабатывая исходный код программы (так как это программа стороннего разработчика), что бы пользователь видел только те строки таблицы, в которых в столбце user был бы его логин.
SELECT * FROM TABLE WHERE USER = 'Login' 
(где вместо Login имя пользователя)

Программа конечно же не моя, но я её всем устанавливал и как бы отвечаю за всё.
16 июл 13, 11:51    [14572175]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3422
Kimel
как ограничить выборку средствами sql, не изменяя и не дорабатывая исходный код программы (так как это программа стороннего разработчика)
Никак. Можно было бы сделать вьюхи, внутри которых жестко зашить проверку на текущий suser_sname(), то же самое в функциях и т.д.

Но если нельзя ничего менять, то все, что вы реально можете - это указать вашему начальнику на данную проблему, и дальше он уже сам будет решать, проблема это или нет, и возможно будет общаться с разработчиками (хотя не думаю, что они смогут настолько радикально все перелопатить).

Вашей вины тут нет, если конечно не вы эту систему рекомендовали :)
16 июл 13, 12:08    [14572298]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Kimel
Я согласен уйти от одного имени входа, я даже готов каждому пользователю дать свой логин для базы данных sql. Но я так и не понял как ограничить выборку средствами sql, не изменяя и не дорабатывая исходный код программы (так как это программа стороннего разработчика), что бы пользователь видел только те строки таблицы, в которых в столбце user был бы его логин.

Переименовать таблицу, закрыть права на ее чтение логинам, добавить вьюху с прежним именем таблицы, в которой делать фильтрацию по user=suser_name().
Но если программа обновляется (в т.ч. обновляет базу данных), то первое же обновление у вас не установится, и придется возвращать все назад.
16 июл 13, 12:59    [14572688]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Kimel
как ограничить выборку средствами sql, не изменяя и не дорабатывая исходный код программы (так как это программа стороннего разработчика), что бы пользователь видел только те строки таблицы, в которых в столбце user был бы его логин.
SELECT * FROM TABLE WHERE USER = 'Login' 
(где вместо Login имя пользователя)

Переименовать таблицу TABLE в TABLE_tab.
Создать view с именем TABLE:
CREATE VIEW [TABLE] AS
SELECT * FROM TABLE_tab WHERE [USER] = SUSER_SNAME()

Конечно, возможны нюансы.
16 июл 13, 13:04    [14572722]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2415
Гость333
Конечно, возможны нюансы.


главное от "Теперь достаточно зайти в реестр компьютера и найти запись MsSqlConnectionString и там будет строка подключения с логином и паролем. " без модификации программы не избавиться
16 июл 13, 13:39    [14572944]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
StarikNavy, поставьте там Server=myServerAddress;Database=myDataBase;Trusted_Connection=True; и выдайте права на подключение доменной группе пользователей, в чем проблема то?
16 июл 13, 13:44    [14572983]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2415
Minamoto
StarikNavy, поставьте там Server=myServerAddress;Database=myDataBase;Trusted_Connection=True; и выдайте права на подключение доменной группе пользователей, в чем проблема то?


проблема не у меня, проблема у автора топика, строка подключения, я подозреваю в программе прописана, которую он не может модифицировать
16 июл 13, 13:51    [14573028]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Kimel
Теперь достаточно зайти в реестр компьютера и найти запись MsSqlConnectionString и там будет строка подключения с логином и паролем.
А дальше уже не через программу заходишь, а через MSSMS и получаешь все привилегии.

В идеале, у пользователя не должно быть прав на запуск всяких там regedit и SSMS.
16 июл 13, 13:56    [14573065]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
StarikNavy, а, извиняюсь, не обратил внимания. Строка подключения прописана в реестре, что прямо написал автор топика. Так что поменять ее не составит проблем.
16 июл 13, 13:57    [14573073]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
StarikNavy
строка подключения, я подозреваю в программе прописана, которую он не может модифицировать

Судя по этой цитате, может:
автор
Я согласен уйти от одного имени входа, я даже готов каждому пользователю дать свой логин для базы данных sql.
16 июл 13, 13:57    [14573074]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3422
Minamoto
StarikNavy, поставьте там Server=myServerAddress;Database=myDataBase;Trusted_Connection=True; и выдайте права на подключение доменной группе пользователей, в чем проблема то?
... и не сможете отличить в базе одного пользователя от другого, если я не ошибаюсь.

Я имею в виду, что на каком-то этапе все равно придется каждому юзеру задавать его права, а делать это в AD или в SQL - вопрос десятый. Одна доменная группа на всех здесь ничего не даст.
16 июл 13, 14:14    [14573194]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Ennor Tiegael
Minamoto
StarikNavy, поставьте там Server=myServerAddress;Database=myDataBase;Trusted_Connection=True; и выдайте права на подключение доменной группе пользователей, в чем проблема то?
... и не сможете отличить в базе одного пользователя от другого, если я не ошибаюсь.

Почему? Думаете, вместо доменного имени пользователя будет видна доменная группа?

Вот я подключился к одному из серверов разработки. Права на нём ограничены, вижу только два логина:

select name from sys.syslogins

sa
Домен\ГруппаРазработки

Дальше делаю такую выборку:
select suser_name(), suser_sname(), original_login()

Результат:
Домен\Гость333Домен\Гость333Домен\Гость333
16 июл 13, 15:09    [14573634]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Секретный анонимус
Guest
Уважаемый Kimel, ситуация которую вы описали - вполне нормальна. Ваши переживания напрасны и необоснованы))

Дело в том что есть существенная разница между пользователями ms sql server и пользователями отдельно взятого приложения. На вашем инстансе ms sql может существовать всего лишь одна учетная запись пользователя - sa, через которую приложения получают доступ к базам данных. В каждой базе может быть (или не быть) как угодно обозванная таблица Users, либо UserInfo и т.д. в которой приложение хранит данные о своих пользователях. В процессе работы приложение может ограничивать выборки из конкретных таблиц данными, специфичными для конкретного пользователя ПРИЛОЖЕНИЯ, но не учетной записи ms sql. Такой сценарий используется в большинстве адекватных систем. Перед этим приложение естественно аутентифицирует пользователя именно по его логину паролю которые лежат в своей собственной таблице и к учетной записи sql server'a "sa" не имеют никакого отношения.

В описанной вами ситуации единственная проблема - это то что пользователь может получить доступ непосредственно к учетной записи ms sql и, обладая навыками работы с базами может напрямую получить доступ к базе в обход приложения. Эта проблема решается стандартными способами типа энкрипта коннекшен стринга (гуглится за 1 минуту), вместо хранения его в явном виде. Вот и всё. Естественно что прямой доступ к базе нужно закрыть. Всё остальное - закроет приложение, которое специально этому обучалось))
16 июл 13, 18:33    [14574929]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Секретный анонимус
В описанной вами ситуации единственная проблема - это то что пользователь может получить доступ непосредственно к учетной записи ms sql и, обладая навыками работы с базами может напрямую получить доступ к базе в обход приложения. Эта проблема решается стандартными способами типа энкрипта коннекшен стринга (гуглится за 1 минуту), вместо хранения его в явном виде. Вот и всё.

А как при такой схеме решается проблема защиты от пользователя, обладающего навыками работы со снифферами, и таким образом могущего извлечь расшифрованный connection string из сетевого трафика?
16 июл 13, 18:46    [14574976]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Гость333
Секретный анонимус
В описанной вами ситуации единственная проблема - это то что пользователь может получить доступ непосредственно к учетной записи ms sql и, обладая навыками работы с базами может напрямую получить доступ к базе в обход приложения. Эта проблема решается стандартными способами типа энкрипта коннекшен стринга (гуглится за 1 минуту), вместо хранения его в явном виде. Вот и всё.

А как при такой схеме решается проблема защиты от пользователя, обладающего навыками работы со снифферами, и таким образом могущего извлечь расшифрованный connection string из сетевого трафика?
Я бы не стал обращать внимание на это сообщение, секретный анонимус, видимо, работает в сфере взлома различных систем, и хочет облегчить себе жизнь, убедив администраторов не пользоваться дополнительными мерами защиты.
16 июл 13, 18:51    [14574989]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Minamoto
Я бы не стал обращать внимание на это сообщение, секретный анонимус, видимо, работает в сфере взлома различных систем, и хочет облегчить себе жизнь, убедив администраторов не пользоваться дополнительными мерами защиты.

Вообще что-то подобное, я считаю, имеет право на жизнь, но только в трёхзвенной системе. Приложение-клиент не умеет обращаться к БД, но обращается к application server'у, который обеспечивает секьюрность, и уже этот application server обращается к database server'у с какими угодно правами, например sa (хотя sa — это всё равно плохо ).
16 июл 13, 18:57    [14575005]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Гость333
Minamoto
Я бы не стал обращать внимание на это сообщение, секретный анонимус, видимо, работает в сфере взлома различных систем, и хочет облегчить себе жизнь, убедив администраторов не пользоваться дополнительными мерами защиты.

Вообще что-то подобное, я считаю, имеет право на жизнь, но только в трёхзвенной системе. Приложение-клиент не умеет обращаться к БД, но обращается к application server'у, который обеспечивает секьюрность, и уже этот application server обращается к database server'у с какими угодно правами, например sa (хотя sa — это всё равно плохо ).
В требованиях к банковскому софту, например, прописано, что и при трехзвенной системе разграничение прав должно быть как на уровне сервера приложений, так и на уровне базы данных, с ограничением доступа к объектам базы.
Правда, это больше Oracle-way, в MS SQL часто пренебрегают передачей прав через сервер приложений в базу.
16 июл 13, 19:00    [14575014]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Секретный анонимус
Guest
Гость333
Секретный анонимус
В описанной вами ситуации единственная проблема - это то что пользователь может получить доступ непосредственно к учетной записи ms sql и, обладая навыками работы с базами может напрямую получить доступ к базе в обход приложения. Эта проблема решается стандартными способами типа энкрипта коннекшен стринга (гуглится за 1 минуту), вместо хранения его в явном виде. Вот и всё.

А как при такой схеме решается проблема защиты от пользователя, обладающего навыками работы со снифферами, и таким образом могущего извлечь расшифрованный connection string из сетевого трафика?


Через сетевой трафик подобные данные идут в зашифрованном виде, так что достать их одно, расшифровать - совсем другое.
http://www.asp.net/web-forms/tutorials/data-access/advanced-data-access-scenarios/protecting-connection-strings-and-other-configuration-information-cs
RSAProtectedConfigurationProvider - uses the asymmetric RSA algorithm for encryption and decryption.
DPAPIProtectedConfigurationProvider - uses the Windows Data Protection API (DPAPI) for encryption and decryption
Вы конечно же и тут скажите что "А если у него есть навыки расшифровки RSA и DPAPI" на что у меня будет встречный вопрос: "А что если упасть и чем-то острым прямо в глаз?" ))) Если серьезно - такая степень защиты является приемлемой, но хакерские атаки конечно ещё никто не отменял.

Вообще по-хорошему секьюрные данные не должны быть на клиентских машинах ни в каком виде. Например веб сервер который знает об учетной записи ms sql и доступ на который закрыт для смертных.
16 июл 13, 19:00    [14575016]     Ответить | Цитировать Сообщить модератору
 Re: Гибкая система безопасности или фатальная ошибка в проектировании? (Внутри много текста)  [new]
Секретный анонимус
Guest
Minamoto
Гость333
пропущено...

Вообще что-то подобное, я считаю, имеет право на жизнь, но только в трёхзвенной системе. Приложение-клиент не умеет обращаться к БД, но обращается к application server'у, который обеспечивает секьюрность, и уже этот application server обращается к database server'у с какими угодно правами, например sa (хотя sa — это всё равно плохо ).
В требованиях к банковскому софту, например, прописано, что и при трехзвенной системе разграничение прав должно быть как на уровне сервера приложений, так и на уровне базы данных, с ограничением доступа к объектам базы.
Правда, это больше Oracle-way, в MS SQL часто пренебрегают передачей прав через сервер приложений в базу.


Интересно что за "Требования к банковскому софту", это типа как 10 заповедей в которых всё четко прописано?))) Я думаю что каких-то ЕДИНЫХ требований к какому либо софту не существует.

Да, описанное вами это Oracle-way. В ms sql based системах, как правило, применяется подход который я описал.
16 июл 13, 19:07    [14575043]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить