|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Доброй ночи. Необходимо реализовать многопользовательское приложение с использованием MSSQL. Набор пользователей в приложении не известен. То есть каждый желающий в ней может зарегистрироваться для дальнейшей авторизации под своим логином и паролем. Чтобы не плодить вновь зарегистрированных пользователей на сервере в именах сервера и логинах БД, решил сделать так: Будет создана таблица USER, в которой и будут сохранятся логины и пароли пользователей, а далее создаваемые ими записи в таблицах будут связаны по ID. И вот в чем вижу опасность. Узнав логин и пароль от общего, под которым будет происходить коннект к БД злоумышленник сможет удалить все данные из таблиц. Как бы мне так обезопаситься, чтобы подобного не могло произойти? Убрать права на удаление нельзя, так как данная функция будет возможна, но каждый сможет видеть только те объекты, которые ему принадлежат по его ID. То есть тут я уже уверен, что пользователь 1 не удалит данные пользователя 2. Вот мне получается нужно сделать так, чтобы под ним только можно подключаться к БД, но через студию или другой клиент не войти. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 00:57 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Если это клиент-серверная архитектура, то только виндовая аутентификация. Если это какая-то другая архитектура, то вопроса о прямом доступе к БД по идее не должно быть в принципе. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 01:26 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич, авторЕсли это клиент-серверная архитектура, то только виндовая аутентификация. Я на клиенте авторизуюсь под виндовой аутенфикацией, а далее пользователь отправляет запрос (свой логин и пароль), чтобы получить уже свой ID и работать под ним в приложении. Но вопрос в том, что если пользователь узнает логин и пароль той самой виндовой учетки, то ему ничего не помешает поставить студию и подключиться под ней. Так ведь? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 01:58 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, Суть виндовой аутентификаци в том, что пользователю в AD заводится виндовая учетная запись, логин и пароль от которой он знает. Под ней он и аутентифицируется на сервере, под ней работает. Если он узнает логин-пароль какой-то другой записи... Ну, он, может, и от вашей узнает, если применит определенные методы. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 02:10 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, у вас изначально подход груго говоря "не верен". вы не должны в явном виде хранить в бд пароли пользователей. во первых это небезопасно во вторых это символизирует степень ваших знаний предметной области в хорошем варианте вы должны сохранять результат хэш-функции по отношению к реальному паролю, при том необратимой. почитайте несколько статей касательно обеспечения сетевой безопасности ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 02:18 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
felix_ff, Пароли пользователей в таблице USER я буду хранить в MD5, понятное дело. И при авторизации сравнивать хэш. Но чтобы сравнить их введенные данные, мне для начала нужно подключиться к БД. Вот о той учетки, с помощью которой я буду подключаться перед авторизацией пользователя и идет речь. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 02:25 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, если вы боитесь компометации сервисной учетки можете дополнительно настроить logon trigger на сервере который будет сравнивать к примеру App_Name(), host_name(). При этом конечно Вам стоит использовать windows аутентификацию. еще неплохой вариант использовать app_role ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 03:36 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, Если вы хотите ограничить возможность подключения к SQL Server, то вы можете это сделать. Если он на той же машине, что и ваш вебсайт (я подразумеваю, что это вебсайт или web api или что-то еще, не предполагающее прямого доступа пользователей к БД; если это не так, то у вас проблемы), то в сиквеле можно оставить только локальные подключения (ну или white list на файерволле определить, чтобы только вы, со статического ip либо через VPN, могли коннектиться на 1433). В то же время, если ваш клиентский (да и серверный тоже, в общем-то) код пишется с той же степенью компетенции, с какой вы владеете русским языком, то есть шанс, что Мэллори сможет хакнуть ваше приложение и получить доступ к контексту той учетки, под которым оное приложение соединяется с БД. Тут... сложно что-то посоветовать. Например, можно запретить delete, оставив только логические удаления, типа: Код: sql 1. 2. 3.
Варианты действий во многом зависят от архитектуры приложения (клиент-сервер либо трехзвенка), а также от того, внутрикорпоративное это приложение, или же выставлено в публичный доступ в интернете. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 04:21 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Ennor Tiegael, Спасибо за ответ. У меня была мысль сделать флаг записей на удаление, а потом джоб бы их сносил. Но тут можно с таким же успехом пометить все записи, имея доступ к БД под логином. Это приложение на C#, которое работает к MSSQL. Мне нужно решить сейчас одну проблему - это передать максимально зашифрованный пароль при подключении к серверу и всё. Во всем остальном нет возможности ограничиться. Буду читать в сторону шифрования. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 13:09 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг Я на клиенте авторизуюсь под виндовой аутенфикацией, а далее пользователь отправляет запрос (свой логин и пароль), чтобы получить уже свой ID и работать под ним в приложении. Но вопрос в том, что если пользователь узнает логин и пароль той самой виндовой учетки, то ему ничего не помешает поставить студию и подключиться под ней. Так ведь? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 13:33 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг Мне нужно решить сейчас одну проблему - это передать максимально зашифрованный пароль при подключении к серверу и всё. Можете даже не дергаться, бесполезно. Код на .NET дизассемблируется без проблем, следовательно атакующая сторона будет иметь доступ и к вашим алгоритмам шифрования, и к их ключам. Обфускаторы могут несколько усложнить эту задачу, но не могут предотвратить ее. Можно попытаться вынести всю криптографию в отдельную DLL и написать ее на С++, но целеустремленный человек с дебаггером и сетевым сниффером победит и это. По собственному опыту, вариантов у вас два: переписать все нахрен на веб, либо заводить пользователям реальные логины в SQL (очевидно, что сами они не должны быть в состоянии это делать, данную работу придется делать вам либо доверенному сотруднику). Именно поэтому я и написал, что многое зависит от того, как приложение используется - интранет, или же интернет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 14:26 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг Это приложение на C#, которое работает к MSSQL. Google: c# connection string encryption ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 16:16 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
invm Евгений Стронг Я на клиенте авторизуюсь под виндовой аутенфикацией, а далее пользователь отправляет запрос (свой логин и пароль), чтобы получить уже свой ID и работать под ним в приложении. Но вопрос в том, что если пользователь узнает логин и пароль той самой виндовой учетки, то ему ничего не помешает поставить студию и подключиться под ней. Так ведь? Спасибо большое! Хорошие метод. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 16:51 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Ennor Tiegael Евгений Стронг Мне нужно решить сейчас одну проблему - это передать максимально зашифрованный пароль при подключении к серверу и всё. Можете даже не дергаться, бесполезно. Код на .NET дизассемблируется без проблем, следовательно атакующая сторона будет иметь доступ и к вашим алгоритмам шифрования, и к их ключам. Обфускаторы могут несколько усложнить эту задачу, но не могут предотвратить ее. Можно попытаться вынести всю криптографию в отдельную DLL и написать ее на С++, но целеустремленный человек с дебаггером и сетевым сниффером победит и это. По собственному опыту, вариантов у вас два: переписать все нахрен на веб, либо заводить пользователям реальные логины в SQL (очевидно, что сами они не должны быть в состоянии это делать, данную работу придется делать вам либо доверенному сотруднику). Именно поэтому я и написал, что многое зависит от того, как приложение используется - интранет, или же интернет. Спасибо большое за помощь! Приму к сведению. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 16:54 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, На самом деле, есть еще один способ. Если ваши юзеры имеют техническую возможность аутентифицироваться в БД через свои учетки Windows (у всех доменные учетки, например), то проблема решаема. Заводите в AD отдельную группу, в нее включаете всех пользователей, кто должен иметь доступ к системе. В сиквеле для этой группы создаете логин, в БД - пользователя, даете нужные права - в этом случае все члены группы автоматом получают соотв. доступ. Прямой доступ к таблицам не даете, только через вьюхи либо функции, в теле которых добавлена фильтрация записей по CURRENT_USER(). Можно создать табличку с пользователями и обновлять ее автоматически - если пришел новый сотрудник и он смог законнектиться (читай: является членом соотв. группы AD), то добавлять. Кого-то можно пометить как админа, они смогут видеть все записи. В этом случае все работает отлично, без училки, без пятерки без логинов и паролей. Осталось загнать всех юзеров в AD (кстати, необязательно в один домен) и... скорее всего, переписать большую часть приложения и базы. Не сильно проще переписывания на веб. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 17:10 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
>Евгений Стронг, сегодня, 00:57 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1320988&msg=22054307][22054307] >Необходимо реализовать многопользовательское приложение с использованием MSSQL... <Аналогичная задача встала и передо мной - реализовать инфосистему из множества многопользовательских приложений с использованием MSSQL (PostgreSQL). Поступил так: 1. Параметры настройки стартового приложения поместил в файл криптоконтейнера (у меня пока .rar). Имя файла - производное от имени пользователя в домене. Пользователь может иметь несколько криптоконтейнеров. //-- Настройка стартового приложения //--====================================== //-- Максимальное число функциональных приложений в кеше 10 //-- Имя пользователя для аутентификации в инфосистеме СисАдмин //-- Пароль для аутентификации в инфосистеме ************* //-- Строка соединения к базе данных SQL сервера Хранилища Data Source=W10X64-POSTGRES\SQLEXPRESS;Initial Catalog=db_Хранилище;User ID=auten;Password=************** //-- Край 2. Ключ шифрования криптоконтейнера состоит из двух полей - пин код пользователя + некий постфикс, который знает приложение, но не знает пользователь 3. Параметры строки соединения для аутентификации дают возможность вызвать только хранимую процедуру аутентификации, передав ей хеши имени и пароля. 4. Если всё ок, стартовое приложение получает параметры работы функциональных приложений, включая и новую строку соединения для доступа к данным ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 17:39 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг Узнав логин и пароль от общего, под которым будет происходить коннект к БД злоумышленник сможет удалить все данные из таблиц. Тогда зная логин и пароль от виндовой учётки никто чужим данным навредить не сможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 20:07 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, для изоляции пользователей от базы используется слой приложений, например, веб-сервисы. В менее строгом варианте это могут быть хранимые процедуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2020, 20:48 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг Гавриленко Сергей Алексеевич, авторЕсли это клиент-серверная архитектура, то только виндовая аутентификация. Я на клиенте авторизуюсь под виндовой аутенфикацией, а далее пользователь отправляет запрос (свой логин и пароль), чтобы получить уже свой ID и работать под ним в приложении. Но вопрос в том, что если пользователь узнает логин и пароль той самой виндовой учетки, то ему ничего не помешает поставить студию и подключиться под ней. Так ведь?Каждый заходит под своей виндовой учеткой. В чем проблема то?? Евгений Стронг Чтобы не плодить вновь зарегистрированных пользователей на сервере в именах сервера и логинах БД ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2020, 01:06 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг felix_ff, Пароли пользователей в таблице USER я буду хранить в MD5, понятное дело. И при авторизации сравнивать хэш. Но чтобы сравнить их введенные данные, мне для начала нужно подключиться к БД. Вот о той учетки, с помощью которой я буду подключаться перед авторизацией пользователя и идет речь. Не, что-то в этом всем неправильно. Дублирование работы Active Directory ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2020, 10:02 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
>PsyMisha, сегодня, 10:02 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1320988&msg=22055350][22055350] >Не, что-то в этом всем неправильно… <Отчего же. Авторизацию пользователь осуществляет с доступным всем соединением и параметрами login и password (хеши). НО! - это соединение дает доступ всего лишь только к одной хранимой процедуре - процедуре реализующей авторизацию. Если ок, то процедура возвращает новое соединение и права пользователя для этого приложения (+ ещё чего ни будь) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2020, 10:55 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг, Так к MSSQL серверу или прямо "Ограничить возможность пользователю подключаться к MSSQL Studio " ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2020, 12:57 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
ВМоисеев >PsyMisha, сегодня, 10:02 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1320988&msg=22055350][22055350] >Не, что-то в этом всем неправильно… <Отчего же. Авторизацию пользователь осуществляет с доступным всем соединением и параметрами login и password (хеши). НО! - это соединение дает доступ всего лишь только к одной хранимой процедуре - процедуре реализующей авторизацию. Если ок, то процедура возвращает новое соединение и права пользователя для этого приложения (+ ещё чего ни будь) Последний раз я проверял процедуры не умели возвращать соединения. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2020, 00:16 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Mind, Полагаю, имелось ввиду, что MSSQL-процедура после проверки хэша возвращает наверх true/false, а уже в DAL-уровне приложения и генерится объект соединения, который возвращается уже дальше следующему уровню ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2020, 09:15 |
|
Ограничить возможность пользователю подключаться к MSSQL Studio
|
|||
---|---|---|---|
#18+
Евгений Стронг Пароли пользователей в таблице USER я буду хранить в MD5, понятное дело. Жуть какая. Их вообще-то в чистом виде даже в SHA-512 хранить нельзя, не говоря уж про MD5. Можно использовать, например, PBKDF2. Ennor Tiegael По собственному опыту, вариантов у вас два: переписать все нахрен на веб, либо заводить пользователям реальные логины в SQL (очевидно, что сами они не должны быть в состоянии это делать, данную работу придется делать вам либо доверенному сотруднику). Именно поэтому я и написал, что многое зависит от того, как приложение используется - интранет, или же интернет. Ну, в интранете вполне можно использовать WCF - это вполне можно использовать в обычных десктопных приложениях. А по сути будет то же, что и с вебом. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2020, 09:18 |
|
|
start [/forum/topic.php?fid=46&msg=39911798&tid=1686648]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
others: | 322ms |
total: | 472ms |
0 / 0 |