Безопасное управление веб-приложениями

Служба приложений Azure
Шлюз приложений Azure
База данных SQL Azure
VPN-шлюз Azure
Брандмауэр веб-приложения Azure

В этой статье представлен обзор развертывания безопасных приложений с помощью среды службы приложение Azure. Чтобы ограничить доступ к приложениям из Интернета, используются служба Шлюз приложений Azure и Azure Брандмауэр веб-приложений. В этой статье также приводятся рекомендации по непрерывной интеграции и непрерывному развертыванию (CI/CD) для сред службы приложений с помощью Azure DevOps.

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

Потенциальные варианты использования

Рассмотрите этот сценарий для следующих вариантов использования:

  • Создание веб-приложения Azure, где требуется дополнительная безопасность.
  • Предоставление выделенной аренды, а не использование планов Службы приложений с общим арендатором.
  • Использование Azure DevOps с внутренней средой службы приложений с балансировкой нагрузки (ILB).

Архитектура

Схема с примером архитектуры сценария для безопасного развертывания Среда службы приложений балансировки нагрузки.

Скачайте файл Visio для этой архитектуры.

Поток данных

  1. HTTP/HTTPS-запросы сначала поступают в Шлюз приложений.
  2. При необходимости (не показанная на схеме) можно включить проверку подлинности Microsoft Entra для веб-приложения. После первого попадания трафика в Шлюз приложений пользователю будет предложено предоставить учетные данные для проверки подлинности в приложении.
  3. Запросы пользователей проходят через внутреннюю подсистему балансировки нагрузки (ILB) среды, которая, в свою очередь, направляет трафик в веб-приложение Expenses.
  4. Затем пользователь переходит к созданию отчета о расходах.
  5. При создании отчета о расходах вызывается развернутое приложение API для получения имени и электронной почты руководителя пользователя.
  6. Созданный отчет о расходах сохраняется в Базе данных SQL Azure.
  7. Чтобы упростить непрерывное развертывание, код возвращается в экземпляр Azure DevOps.
  8. На виртуальной машине сборки установлен агент Azure DevOps, что позволяет виртуальной машине сборки извлекать биты для веб-приложения для развертывания в Среда службы приложений (так как виртуальная машина сборки развернута в подсети в той же виртуальной сети).

Компоненты

  • Среда службы приложений предоставляет полностью изолированную, выделенную среду для безопасного запуска приложения в большом масштабе. Кроме того, поскольку Среда службы приложений и рабочие нагрузки, выполняемые в ней, находятся за виртуальной сетью, она также обеспечивает дополнительный уровень безопасности и изоляции. Требование высокой масштабируемости и изоляции привело к выбору Среда службы приложений ILB.
  • Эта рабочая нагрузка использует изолированную Служба приложений ценовую категорию, поэтому приложение работает в частной выделенной среде в центре обработки данных Azure с использованием более быстрых процессоров, хранилища SSD и удвоит соотношение памяти к ядрам по сравнению со стандартом.
  • Веб-приложение Службы приложений Azure и приложение API содержат веб-приложения и интерфейсы REST API. Эти приложения и API размещаются в плане изолированной службы, который также предлагает автомасштабирование, пользовательские домены и т. д., но на выделенном уровне.
  • Шлюз приложений Azure — это подсистема балансировки нагрузки веб-трафика, работающая на уровне 7 и предназначенная для управления трафиком веб-приложения. Он предлагает разгрузку SSL, которая удаляет дополнительные затраты с веб-серверов, на которых размещено веб-приложение, чтобы расшифровать трафик снова.
  • Брандмауэр веб-приложений (WAF) — это компонент Шлюза приложений. Включение WAF в Шлюзе приложений повышает безопасность. WAF использует правила OWASP для защиты веб-приложения от таких атак, как межсайтовые сценарии, перехват сеансов и внедрение кода SQL.
  • База данных SQL Azure была выбрана, так как большая часть данных в этом приложении является реляционными данными, и лишь часть данных — это документы и большие двоичные объекты.
  • Сеть Azure предоставляет различные сетевые возможности в Azure, а сети могут быть пиринговые с другими виртуальными сетями в Azure. Подключение также можно установить с локальными центрами обработки данных через ExpressRoute или site-to-site. В этом случае в виртуальной сети включается конечная точка службы, чтобы обеспечить передачу данных только между виртуальной сетью Azure и экземпляром Базы данных SQL.
  • Azure DevOps используется для совместной работы команд во время спринтов, использования функций, поддерживающих гибкую разработку, а также для создания конвейеров сборки и выпуска.
  • Была создана виртуальная машина сборки Azure, чтобы установленный агент смог извлечь соответствующую сборку и развернуть веб-приложение в среде.

Альтернативные варианты

Среда службы приложений может запускать обычные веб-приложения в Windows или, как в этом примере, веб-приложения, развернутые в среде, которая выполняется в качестве контейнеров Linux. Был выбран Среда службы приложений для размещения этих контейнерных приложений с одним экземпляром. Доступны альтернативные варианты. При проектировании своего решения ознакомьтесь с приведенными ниже сведениями.

Другие варианты для уровня данных:

  • Azure Cosmos DB. Если большая часть данных находится в нереляционном формате, Azure Cosmos DB является хорошей альтернативой. Эта служба предоставляет платформу для запуска других моделей данных, таких как MongoDB, Cassandra, данные Graph или простое хранилище таблиц.

Рекомендации

При работе с сертификатами на Среда службы приложений ILB существуют некоторые рекомендации. Необходимо создать сертификат, который связан с доверенным корнем, не требуя запроса на подпись сертификата, созданного сервером, где сертификат будет храниться в конечном итоге. Например, при использовании службы IIS (IIS) сначала необходимо создать CSR с сервера IIS, а затем отправить его в центр выдачи SSL-сертификатов.

Вы не можете выдавать CSR из внутренней подсистемы балансировки нагрузки (ILB) Среда службы приложений. Способ обработки этого ограничения — использовать дикую карта процедуру.

Процедура дикого карта позволяет использовать подтверждение владения DNS-именем вместо CSR. Если вы владеете пространством имен DNS, вы можете поместить в специальную запись DNS TXT, дикую карта процедуру проверка, что запись есть, и если она найдена, знает, что у вас есть DNS-сервер, так как у вас есть правильная запись. На основе этой информации она выдает сертификат, зарегистрированный в доверенном корне, который затем можно отправить в ILB. Вам не нужно использовать отдельные хранилища сертификатов в веб-приложениях, так как у вас есть доверенный корневой SSL-сертификат в ILB.

Сделайте самозаверяющий или внутренне выданный SSL-сертификат работой, если вы хотите выполнять безопасные вызовы между службами, работающими в Среда службы приложений ILB. Другое решение, которое следует рассмотреть, как сделать Среда службы приложений балансировки нагрузки работать с внутренним ssl-сертификатом и как загрузить внутренний ЦС в доверенное корневое хранилище.

При подготовке Среда службы приложений следует учитывать следующие ограничения при выборе доменного имени для среды. Доменные имена не могут быть:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Кроме того, имя личного домена, используемое для приложений и доменное имя, используемое Среда службы приложений подсистемы балансировки нагрузки, не может перекрываться. Для Среда службы приложений подсистемы балансировки нагрузки с доменным именем contoso.com нельзя использовать пользовательские доменные имена для таких приложений, как:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Выберите домен для Среда службы приложений подсистемы балансировки нагрузки, которая не конфликтует с этими именами пользовательских доменов. Вы можете использовать что-то подобное contoso-internal.com для домена вашей среды в этом примере, так как это не конфликтует с именами пользовательских доменов, которые заканчиваются в .contoso.com.

Еще одним моментом, который следует рассмотреть, является DNS. Чтобы разрешить приложениям в Среда службы приложений взаимодействовать друг с другом, например веб-приложение для связи с API, вам потребуется настроить DNS для вашей виртуальной сети, удерживающей среду. Вы можете использовать собственные DNS или частные зоны Azure DNS.

Availability

Масштабируемость

Безопасность

Устойчивость

Развертывание этого сценария

Чтобы развернуть этот сценарий, выполните пошаговые инструкции по развертыванию каждого компонента вручную. Выберите Среда службы приложений версии 3 вместо версии 2 при выполнении руководства. В этом руководстве также содержится пример приложения .NET, в котором используется простое приложение Contoso для создания отчетов о расходах.

Цены

Изучите затраты на выполнение этого сценария. В калькуляторе цен стоимость использования всех служб рассчитывается на основе предварительно выбранных параметров. Чтобы узнать, как изменится цена для конкретного варианта использования, измените соответствующие переменные в соответствии с ожидаемым трафиком.

Мы предоставили три примера профилей затрат на основе объема трафика, который вы ожидаете получить:

  • Малый: этот пример ценообразования представляет компоненты, необходимые для минимального экземпляра уровня производства, обслуживающего несколько тысяч пользователей в месяц. Приложение использует один экземпляр стандартного веб-приложения, которого будет достаточно для автомасштабирования. Каждый из остальных компонентов масштабируется до базового уровня, который свести к минимуму затраты, но по-прежнему обеспечивает поддержку соглашения об уровне обслуживания и достаточную емкость для обработки рабочей нагрузки на уровне рабочей среды.
  • Средний: этот пример ценообразования представляет компоненты, необходимые для развертывания среднего размера. Здесь мы оцениваем примерно 100 000 пользователей в течение месяца. Ожидаемый трафик обрабатывается в одном экземпляре службы приложения со средним стандартным уровнем. Кроме того, в калькулятор добавляются средние уровни когнитивных и поисковых служб.
  • Большой. Этот профиль предполагает развертывание крупномасштабного приложения с миллионами пользователей в месяц и трафиком в терабайты данных. На этом уровне использования требуются высокопроизводительные веб-приложения уровня "Премиум", развернутые в нескольких регионах, перед которыми работает диспетчер трафика. Данные состоят из следующих компонентов: хранилища, базы данных и CDN, настроенные для терабайтов данных.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

  • Фейсал Мустафа | Старший инженер клиента

Следующие шаги