Безопасность ASP.NET Core appSettings.json

У меня есть приложение ASP.NET Core 2.0 WebAPI с Db ConnectionString в appSettings.json. В процессе разработки он имеет такую ​​ценность:

«DefaultConnection»: «Server = localhost; Database = Tyroll; Trusted_Connection = True; MultipleActiveResultSets = true»

и только когда мы публикуем его в производственной среде, мы меняем его с соответствующими паролями, используя профиль публикации VS 2017.

Таким образом, пароли для SQL-сервера не хранятся в репозитории, и там нет проблем.

Файл appsettings.json защищен IIS
Интересный вопрос Должен ли этот пароль быть каким-то образом «спрятан» даже в IIS?
Одной из причин является дополнительная безопасность, так что учетные данные SQL не отображаются в виде обычного текста в случае нарушения здесь. Другой вариант для сценария авторизации, когда администратор IIS не должен иметь прямого доступа к SQL-серверу.

Я полагаю, что он может быть зашифрован, и у самого приложения будет ключ для его расшифровки. Это не будет на 100% безопасным, так как в случае взлома IIS даже этот ключ может быть реконструирован из приложения, но это усложнит задачу, когда он находится в виде обычного текста.

Итак, первый вопрос: должен ли я вообще этим заниматься?

И, во-вторых, если 1.Q - «Да», что будет лучшим / рекомендованным способом сделать это?

Есть ли встроенный инструмент для этого в .NetCore2, VS2017, IIS или какой-либо другой инструмент?

Вот несколько ссылок по теме:


security asp.net connection-string appsettings password-encryption
person borisdj    schedule 09.10.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я бы посоветовал вам использовать Active Directory Integrated security для доступа к базе данных, пул приложений может работать под учетной записью пользователя, и эта конкретная учетная запись пользователя будет иметь только необходимый доступ к базе данных. Это защищает учетные данные пользователя в случае атаки, поскольку пароль никогда не раскрывается.

person Atmanirbhar Bharat    schedule 10.10.2017
comment
В моем случае это не вариант, потому что SQL Server не находится в том же домене, он находится в DMZ - person borisdj; 11.10.2017
comment
Вы хотите сказать, что SQL-сервер находится в демилитаризованной зоне .. Это должен быть общедоступный сервер, на котором размещена база данных ... Или же он не должен находиться в демилитаризованной зоне. - person Atmanirbhar Bharat; 11.10.2017
comment
Да, SQL-сервер находится в DMZ, поэтому IIS находится в другом домене. Это не публичный хостинг, это частный, и только приложения с нашей ISS с учетными данными пользователя (имя пользователя и пароль) могут получить к нему доступ. - person borisdj; 11.10.2017

arrow_upward
1
arrow_downward

Я реализовал собственное шифрование пароля в ConnectionString.
Но поскольку приложение должно его расшифровать, это скорее обфускация.
Для шифрования Я использовал AES (с использованием System.Security.Cryptography), и ключ хранится: половина в самой connectionString, а другая половина жестко закодирована в приложении.
Кроме того, < Strong> regex использовался для извлечения пароля из ConnectionString, а затем был заменен его дешифрованной строкой.

person borisdj    schedule 11.10.2017