Модель безопасности для приложения .NET Windows Forms с Amazon RDS SQL Server

Мне бы хотелось получить отзывы о лучших практиках модели безопасности, которую я придумал для своего приложения. Сначала я погружаюсь с головой в обновление внешнего интерфейса/серверной части Microsoft Access до .NET WinForms/SQL Server с использованием Amazon RDS. Приложение будет многопользовательским, многосайтовым (разные домены) и будет содержать конфиденциальную информацию о состоянии здоровья.

Вот итог двухнедельного исследования:

  1. Зашифрованная строка подключения, хранящаяся в приложении с использованием смешанной аутентификации и SSL. Не идеально, но я думаю, что нашел способ, чтобы все было в порядке, если строка подключения украдена (см. № 5 ниже).

  2. SQL Server принимает соединения только с выбранных IP-адресов (все будут статическими).

  3. Строка подключения к приложению, назначенная одному пользователю SQL Server с правами только на выполнение. Все взаимодействие с БД будет осуществляться с помощью процедур. Разрешения схемы, используемые для ограничения пользователя приложения определенными процедурами.

  4. Таблица пользователей с SHA 256 солеными и хешированными паролями. Это обеспечивает первый уровень безопасности приложений.

  5. ЭТО ЧАСТЬ, В КОТОРОЙ Я НЕ УВЕРЕН: каждая процедура будет полностью выполняться только в том случае, если оператор IF, ищущий имя пользователя и пароль, отправленный как одна из переменных exec = True. UN/PW будет временно храниться для каждого сеанса приложения. Мое объяснение заключается в том, что это не позволяет пользователю со строкой подключения, который каким-то образом входит в систему с разрешенного IP-адреса, получать/изменять какие-либо данные без действительного пароля.

  6. Конфиденциальные столбцы зашифрованы с помощью симметричного ключа AES_256, зашифрованного сертификатом с использованием главного ключа базы данных. Пользователь приложения имеет права на использование симметричного ключа и сертификата.

  7. Пароли пользователей должны соответствовать правилам (длина, сочетание верхнего и нижнего регистра, специальные символы).

Может ли кто-нибудь увидеть какие-либо дыры в этом или есть хорошие альтернативы? Решает ли # 5 дыры в безопасности, присущие строкам подключения, которые есть в приложениях Windows, которые не могут использовать проверку подлинности Windows?


person JBL    schedule 04.12.2012    source источник


Ответы (1)


В целом ваш дизайн кажется мне попыткой дублировать встроенную функциональность (аутентификация, авторизация, контроль разрешений) с самодельной попыткой копирования, только потому, что вы не доверяете встроенным функциям.

Используйте пользователя/пароль SQL для аутентификации/авторизации. НЕ создавайте таблицу пользователей и хэшей. НЕ отправляйте пользователя и пароль с каждым запросом exec (!).

Используйте разрешения SQL Server для управления доступом. Используйте подпись кода для детального контроля выполнения (подписанные процедуры). НЕ пытайтесь создать параллельную, дублирующую инфраструктуру контроля доступа, НЕ храните временного пользователя/пароль для каждого сеанса.

Используйте инфраструктуру брандмауэра AWS для управления IP-адресами доступа. НЕ изобретайте свои собственные.

Если вы используете шифрование на уровне столбцов, поймите, от чего вы защищаете и какова ваша цель. Случайная потеря носителя? Затем зашифруйте с помощью главного ключа базы данных (т.е. TDE для бедняков). Конфиденциальность данных? Затем попросите пользователя ввести пароль для расшифровки сертификата в каждом сеансе.

устранить внутренние дыры в безопасности строки подключения

Попросите пользователя ввести пароль при запуске приложения, чтобы вы не раскрывали пароль в неактивных файлах (.config). Вот и все. SQL Server давно перестал обменивать пароль на проводную аутентификацию SQL.

person Remus Rusanu    schedule 04.12.2012
comment
Спасибо @Remus. У меня возникли проблемы с динамической и безопасной настройкой строки подключения для всего приложения (а не только каждый раз, когда я вызываю коннектор таблицы для каждой формы). Хотя у меня будет еще один шанс. Определенно использует встроенный брандмауэр AWS и не может позволить себе TDE, но хочет защитить информацию о пациентах при хранении. - person JBL; 04.12.2012
comment
Вы можете зашифровать файл app.config. разделы с использованием DPAPI. С .Net 4.5 и выше у вас есть безопасный SqlCredential функция для пользователя/пароля внутри процесса. - person Remus Rusanu; 04.12.2012
comment
Вау, жаль, что я не обнаружил SQLCredential раньше - ценю это. - person JBL; 05.12.2012