Любопытный случай пропущенной строки подключения Azure
Вы новичок в Azure и работаете над развертыванием своего блестящего нового веб-приложения в службе веб-сайтов Azure. Но вы храните свое веб-приложение в общедоступном хранилище , таком как GitHub , BitBucket или CodePlex . В настоящее время с помощью любого количества возможных методов вам удалось сохранить строки подключения вне общего доступа, не регистрируя их. Теперь вы пытаетесь выяснить, как продолжить фиксацию в своем хранилище и выполнить развертывание в Azure без необходимости фиксации. Строка подключения, чтобы веб-сайты Azure могли знать о них. Звучит знакомо?
Ну, слава тебе. По крайней мере, вы обнаружите легко пропущенную дыру в безопасности, связанную с случайным раскрытием конфиденциальных данных приложения через то, что называется неправильной настройкой безопасности. Строки подключения к веб-сайту Azure упрощают соблюдение этого потенциального правила безопасности. Но сначала, почему это конфиденциальные данные?
Неправильная настройка безопасности
Неверная конфигурация безопасности является серьезным недостатком безопасности, поэтому OWASP поднял ее с 6 на 5 место в десятке лучших уязвимостей веб-приложений 2013 года . Точно названные строки подключения в нашем веб-приложении — это один из шлюзов в ценную позицию — данные нашего приложения. Я уже говорил о утечках данных приложений , но это уязвимость, которая действительно облегчает жизнь злоумышленникам.
При самостоятельном размещении веб-приложения мы не только должны защищать информацию, такую как строки подключения, но на более глубоком уровне мы должны гарантировать, что доступ к таким файлам также недоступен. Но это не статья о защите файловых ресурсов приложения, поэтому давайте вернемся к тому, что могут сделать веб-сайты Azure, чтобы упростить нашу жизнь, когда речь идет о защите строк подключения нашего приложения.
Строки подключения к веб-сайту Azure
Предполагая, что ваше веб-приложение работает с такой же строкой подключения, как показано ниже:
<add name=”shpt” connectionString=”…..”/>
Служба веб-сайтов Azure позволяет очень просто хранить такую информацию, как строки подключения к web.config, из нашего репозитория. На портале управления Azure в разделе Служба веб-сайта вы можете выбрать вкладку « Настройка» .
Отсюда мы можем прокрутить вниз до области Строки подключения, чтобы найти, где можно указать строки подключения на веб-сайте Azure. Здесь вы можете добавить новую строку подключения, имя которой совпадает с полем name = ””, которое вы указали в файле web.config.
Теперь, когда ваше приложение зафиксировано в вашем хранилище и происходят процессы сборки и развертывания, Azure выгрузит и заменит указанную вами строку подключения, где имена совпадают с именами, которыми обладает Azure.
ПРИМЕЧАНИЕ. При работе с Visual Studio можно позаботиться о некоторых из описанных настроек строки подключения Azure в зависимости от того, настроили ли вы Azure изначально в начале своего веб-приложения.
Эта статья рассказывает о том, что Azure сделает для вас, когда нужно сделать строку подключений доступной для вашего веб-приложения. Но проблема, которая могла возникнуть, — « как сделать строку подключения доступной для локальной разработки ?»
Съесть свой торт и съесть его
Когда дело доходит до подключения к локальной базе данных, гарантируя, что информация о подключении к локальной базе данных не является общедоступной, в то же время обеспечение правильных доступных строк подключения в Azure может быть непростым делом. Существует ряд различных сценариев, в которых вы можете оказаться. Поэтому я опущу несколько подходов, которые люди могут использовать для манипулирования этим типичным сценарием. Это ни в коем случае не исчерпывающий список.
Преобразование Web.config
Используйте преобразование web.config, как описано в этой статье MSDN . Это позволяет вам иметь отдельный файл, который содержит конкретную информацию о соединении с базой данных для вашей строки соединения. Затем заполнитель для строки подключения в вашем файле web.config заменяется соответствующим образом на правильную строку подключения к базе данных, которая сохраняется в отдельном файле.
Атрибут ConfigSource
Другой подход заключается в использовании атрибута « configSource» элемента « connectionStrings» в вашем файле web.config, чтобы указать отдельный файл, похожий на файл в варианте № 1, но немного менее подробный. У этой опции есть немного больше, но вы можете прочитать подробный обзор и подход к этому здесь, а также преимущества, которые он предлагает.
В любом случае преимущество безопасности достигается, когда мы применяем разделение проблем к нашему web.config И гарантируем, что это разделение защищено. Любая выгода для безопасности будет уменьшена, если мы не гарантируем, что этот дополнительный файл не будет пропущен через общедоступный репозиторий или иным способом.
Вывод
Это было коротким, но цель этой статьи состояла в том, чтобы просто показать, что служба веб-сайта Azure способна сделать с помощью соглашения, чтобы помочь защитить важную информацию веб-приложения без необходимости нарушать основное правило безопасности. Кроме того, это выявляет важность обеспечения безопасности важной информации о приложениях и не допускает неправильной конфигурации безопасности. Такая информация, как строки подключения к вашей базе данных, может привести к появлению невероятных пробелов в безопасности в нашем приложении, и вы должны убедиться, что вы выполнили соответствующие шаги по усилению безопасности, а строки подключения к веб-сайту Azure упростят эту задачу. В самое ближайшее время я опубликую статью, в которой подробно описывается, как можно гарантировать, что ваше веб-приложение не станет жертвой неправильной настройки безопасности. Так что следите за обновлениями.