#c# #sql-server #security
#c# #sql-сервер #Безопасность
Вопрос:
Простой и надуманный пример:
Настольное приложение C # взаимодействует с базой данных SQL Server. Все заказы существуют в таблице Orders.
Приложение просматривает, создает и исправляет заказы. В этом примере пользователь может изменять только свои собственные заказы.
Проблемы:
Хранение строки подключения при использовании выделенных учетных данных sql. Даже если используются учетные данные пользователя, безопасность приложения можно обойти, подключившись напрямую через Excel или Access.
Решения:
Предоставляйте доступ к SQL только через веб-службу / промежуточное программное обеспечение. Хорошо, но не обязательно жизнеспособно в этом случае.
Зашифруйте строку подключения где-нибудь в приложении. Не очень безопасно, безопасность через неизвестность.
Защитите базу данных, предоставив доступ к определенным хранимым процедурам, представлениям и т.д. без доступа к реальным таблицам. SP и представления учитывают права / учетные данные пользователя. Довольно ужасно. Хорошо для простых примеров (выберите, где пользователь, становится сложным, когда вы вводите пользователей в разные группы, отношения менеджера и т. Д.
Альтернативы:
Как бы вы подошли к этому?
Спасибо
Комментарии:
1. Не забудьте очистить свои входные данные: xkcd.com/327
Ответ №1:
Даже если используются учетные данные пользователя, безопасность приложения можно обойти, подключившись напрямую через Excel или Access
что вы имеете в виду? вы не должны разрешать пользователям подключаться к SQL Server напрямую или с помощью Excel или Access. Они не должны знать sa или другой пароль.
После этого, конечно, вы могли бы зашифровать некоторые разделы своего приложения, настроить так, чтобы никто не мог видеть его содержимое.
У меня действительно была бы логика, согласно которой пользователь может изменять свои собственные заказы только на уровне приложения. Я думаю, это можно сделать и в хранимых процедурах, но это зависит, и об этом следует знать больше, чтобы предложить наилучший или наиболее подходящий подход.
Комментарии:
1. Я согласен, но если они получили учетные данные или если они были настроены на доступ, предоставленный их учетными данными NT, они могут получить доступ.
2. Я думаю, что это тот путь, который имеет для меня наибольший смысл. Приложение использует SQL auth (строка подключения в web.config), и доступ доступен только через некоторый DAL, который фильтрует результаты на основе идентификатора пользователя. Есть ли там какая-то ненужная уязвимость?
3. Привет, nycdan, да, если пользователь получает доступ к незашифрованной строке подключения, он может подключиться к базе данных и делать все, на что у этой учетной записи есть права. Если соединение осуществляется через интегрированную систему безопасности, им просто нужно имя сервера. Это не будет web.config, так как это не веб-приложение, поэтому файл конфигурации существует на локальном компьютере. Я думаю, шифрование поможет в этом, если мы не будем использовать интегрированное.
Ответ №2:
Используйте проверку подлинности Windows вместо проверки подлинности sql.
Чтобы разрешить пользователям видеть только свои данные, вы можете создавать просмотр и фильтровать данные на основе текущего вошедшего в систему пользователя, используя SYSTEM_USER для получения данных только для текущего пользователя и отказа в разрешении выбора в самой таблице.
Комментарии:
1. Да, это я тоже хотел предложить, но я думаю, что проблема для него заключается в том, что в этом случае пользователь может подключиться к Access или другому инструменту и изменять заказы, не связанные с ним. Если я правильно понял вопрос, конечно…
2. Это Давиде. Если мы предоставим им права NT, они теоретически могут просто открыть соединение в Excel или Access и прочитать (и, возможно, записать) любые старые данные, которые они пожелают.
3. Спасибо, Георгий. Одна из проблем, с которой я сталкиваюсь, заключается в том, что иногда право на редактирование может также зависеть от группового доступа пользователя. Теперь я могу определить эти групповые отношения и в sql, на самом деле мы можем в конечном итоге сделать это в любом случае, но если мы в конечном итоге используем, скажем, ActiveDirectory для этого, все становится более согласованным.
Ответ №3:
Вы не можете обеспечить безопасность на уровне строк в SQL Server (ну, вы можете, но это не так просто). Итак, ваш единственный выбор для обеспечения полной безопасности — пройти через уровень данных, который контролирует доступ. Вы можете хранить свои учетные данные в зашифрованном виде, но, как вы говорите, это не совсем безопасно. Это зависит от того, что вам нужно.
Комментарии:
1. Просто смотрю, как другие подошли к этому. Обычно я бы выбрал уровень обслуживания, но в данном случае это монолитное приложение, получающее доступ к базе данных непосредственно с рабочего стола.
Ответ №4:
Ну, в нашем приложении, которое мы обрабатываем, мы храним строку подключения, зашифрованную в файле. Таким образом, у пользователя нет прямого доступа к этому файлу. Мы также используем sql-соединение только с нашей базой данных и предоставляем пользователю только для этого.
Если вы используете учетные данные Windows для доступа к нему и хотите предотвратить любые манипуляции, вы можете запретить доступ на запись в таблицу. Для чтения данных вы можете создавать запросы или обращаться к таблицам.
Для записи / добавления / обработки данных вы можете создавать хранимые процедуры. Одним из параметров является имя пользователя. Внутри процедуры вы создаете свою бизнес-логику, олицетворяете пользователя, имеющего доступ на запись, чтобы окончательно записать / обновить данные. Там у вас есть свой «слой» внутри SQL server. Но я бы не советовал идти этим путем 🙂 Это возможно, но для многих бизнес-логик внутри базы данных imho. Поэтому самый безопасный способ — найти хороший класс шифрования на вашем языке, использовать только sql auth и хранить эти данные внутри вашего кода.
Комментарии:
1. Спасибо, это действительно ценно. Я полностью согласен, я ненавижу иметь этот «слой» в самом sql server, это так похоже на конец 90-х 🙂