Безопасность клиента/сервера в C#/SQL Server

У меня есть SQL Server, работающий на компьютере под управлением Windows 2008 R2, на котором должны выполняться основные запросы (SELECT/INSERT/UPDATE). Эти операции выполняются непосредственно клиентом, приложение, написанное на C#, которое установлено на одном компьютере в другом месте, поэтому соединение происходит через Интернет.Безопасность клиента/сервера в C#/SQL Server

Поскольку природа операций, выполняемых в БД, настолько проста, я бы предпочел не писать back-end поверх SQL Server. Поэтому настройка для обеспечения безопасности:

1) Имя пользователя и пароль, написанные на клиенте и отправленные.

2) Запрос запроса (параметризованный) запускается на сервере, а хэш и соль пароля возвращаются клиенту.

3) Пароль и соль добавляются, хешируются с использованием SHA_512 и сравниваются с хэшем пароля.

4) Если вам соответствуют два, вам предоставляется доступ к набору инструментов, который создает и отправляет запросы.

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

источник

2016-08-22 Kafros

Для одного у вас есть сервер в Интернете с портом 1433 открытым . – Paparazzi

Трафик между вашим клиентом и SQL-сервером [зашифрован] (https://technet.microsoft.com/en-us/library/ms189067 (v = sql.105) .aspx), право? –

Да SSL. На данный момент Im тестирует, так что все его локальные используют «Integrated Security». – Kafros

Если я правильно понимаю это, то вся проверка пароля выполняется на стороне клиента. Это верно? Если это так, это кажется потенциально небезопасным.

Вы доверяете клиенту полностью? Если неавторизованное лицо может получить доступ к клиенту или создать другого клиента, который имитирует ваш клиент, то это значительно увеличивает вероятность того, что они получат доступ к вашей стороне сервера.

Это определенно звучит так, будто вы были бы более безопасным, создавая заднюю систему, даже если это просто простой прокси-сервис, который просто проверяет имя пользователя и пароли, а затем пересылает сам запрос как есть.

Таким образом, пароль-хэш и соль никогда не покинут сервер.

источник

2016-08-22 09:09:10 Kjartan

1) Да, если я не прояснил, проверка пароля выполняется на стороне cleint 2) Получение доступа к клиенту является потенциальной угрозой. 3) Будет ли прокси-система не включать пароль, оставляющий клиента открытым текстом? (будь то по SSL) – Kafros

Возможно, но так или иначе они не отправлены так? – Kjartan

Нет, имя пользователя отправляется в виде открытого текста, пароль временно сохраняется на клиенте, ожидая хэш и соль для процесса проверки пароля. Имейте в виду, что это настольное приложение. – Kafros

Основываясь на вашем сценарии, я хотел бы рассмотреть возможность создания учетных записей SQL для каждого пользователя вашего приложения. Когда пользователь входит в ваше приложение, используйте эти учетные данные при построении строки подключения SQL Server и разрешите серверу выполнять проверку учетных данных. Это часто называют аутентификацией pass-thru.

Еще лучше, если ваше приложение будет выполнено пользователями в том же домене Active Directory, что и SQL Server, вы можете использовать более безопасную интегрированную систему безопасности Windows (то, что вы сейчас используете для локального тестирования), и пользователям не понадобятся для входа в систему. Соединение будет просто использовать их текущие учетные данные AD. См. Эту ссылку для получения дополнительной информации о настройке учетных записей пользователей в SQL Server с использованием учетных данных домена Windows: https://msdn.microsoft.com/en-us/library/dd787978.aspx

Кроме того, с помощью любой опции вы все равно захотите использовать защищенное TLS соединение (Encrypt = true), чтобы предотвратить отслеживание учетных данных над проводом.

источник

2016-08-22 14:00:45

Итак, теперь пользователь может просто загрузить SSMS-журнал и иметь прямой доступ к базе данных? Это не похоже на хороший план для меня. – Paparazzi

@Paparazzi: вы хотели бы удостовериться, что каждой учетной записи пользователя были предоставлены определенные разрешения базы данных, чтобы ограничить их действия в базе данных. С аудитом уровня базы данных вы также можете отслеживать изменения, сделанные каждым пользователем. При этом пользователь всегда будет иметь возможность напрямую подключаться к базе данных при использовании упрощенной модели, например, когда SQL Server является единственным компонентом на стороне сервера. Для чего-либо более продвинутого с точки зрения безопасности потребуется дополнительная служба/прокси на стороне сервера, которая реализует уровень аутентификации. –

Спасибо, что это то, что я искал. это немного разочаровывает то, что я создал систему регистрации с SHA_512 и солями и т. д., но это похоже на лучший способ сделать это для 2-3 пользователей, которых эта система будет иметь. – Kafros

Клиент, подключающийся непосредственно к SQL Server, не является безопасным. Если клиент находится на локальном жестком диске, его можно взломать.

Вы не можете найти то, что вы пытаетесь сделать, потому что это не очень хороший дизайн.

Не получите свою логику «Поскольку природа операций, выполняемых в БД, настолько проста, я бы предпочел не писать back-end поверх SQL Server."Если это легко, то, что является причиной, чтобы установить задний конец.

.NET имеет всю инфраструктуру для Windows Communication Foundation это..

источник

2016-08-22 14:11:40 Paparazzi

БД и клиент не будут находиться на одном локальном жестком диске. Это смягчает риски, о которых вы говорите? – Kafros

НЕТ, это смягчает риск. То, что так сложно в концепции клиента, можно взломать. Учетные данные в клиенте могут быть взломаны. Просто давать учетные данные для входа в свой домен еще хуже. Теперь им не нужно ничего взломать. – Paparazzi

Безопасность клиента/сервера в C#/SQL Server

ответ

Смежные вопросы