Прежде всего, незашифрованное содержимое web.config означает, что любой, кто имеет доступ к сервисному пакету, может получить доступ к содержимому web.config, а это может быть больше людей, чем вам нужно. Например, если у вас есть автоматическая сборка, любой сотрудник вашей компании, увидевший результаты сборки, увидит эти данные. Вы решаете, приемлемо ли это.
Далее, не забывайте, что в программном обеспечении есть уязвимости. Может случиться так, что в какой-то момент в IIS будет обнаружена уязвимость, позволяющая легко загрузить файл web.config.
Затем, если у вас когда-нибудь будет отключен customErrors и у вас есть что-то неправильно настроенное в web.config, может случиться так, что любой, кто делает HTTP-запрос к вашей веб-роли, увидит сообщение об ошибке от IIS, в котором говорится, что это и это неправильно настроено в web. config и показывает часть web.config, где произошла неправильная конфигурация. Это может привести к раскрытию вашего секрета - вот пример подобного раскрытия. Не очень вероятно, но технически возможно.
Наконец, при всем уважении ко всем облачным провайдерам вы на самом деле не контролируете, как данные обрабатываются в центрах обработки данных. Они могут выбросить неповрежденный диск, или какой-то сотрудник может быть поврежден, и ваш сервисный пакет может просочиться. Не очень вероятно, но технически возможно. Если вы задаете подобные вопросы (и это очень хороший вопрос), вы также должны учитывать этот риск.
Так что, как обычно, абсолютной безопасности нет. Все, что вы можете, это просто поднять планку. Хранение строки подключения в зашифрованном виде, безусловно, поднимает планку.
Вас также могут заинтересовать ответы на этот связанный вопрос.
person
sharptooth
schedule
26.06.2012
