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

В этой статье представлен обзор развертывания безопасных приложений с помощью Среда службы приложений. Чтобы ограничить доступ к приложениям из Интернета, используются служба Шлюз приложений 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 размещают веб-приложения и API RESTful. Эти приложения и API размещаются в плане изолированной службы, который также предлагает автомасштабирование, пользовательские домены и т. д., но на выделенном уровне.
• Шлюз приложений Azure — это подсистема балансировки нагрузки веб-трафика, работающая на уровне 7 и предназначенная для управления трафиком веб-приложения. Он предлагает разгрузку SSL, которая удаляет дополнительные затраты с веб-серверов, на которых размещено веб-приложение, чтобы расшифровать трафик снова.
• Брандмауэр веб-приложений — это функция Шлюз приложений. Включение брандмауэра веб-приложения в шлюзе приложений повышает безопасность. Брандмауэр веб-приложения использует правила Open Worldwide Application Security Project (OWASP) для защиты веб-приложения от атак, таких как межсайтовый скрипт, перехват сеансов и внедрение SQL.
• База данных SQL Azure была выбрана, так как большая часть данных в этом приложении является реляционными данными, и лишь часть данных — это документы и большие двоичные объекты.
• Сеть Azure предоставляет различные сетевые возможности в Azure, а сети могут быть пиринговые с другими виртуальными сетями в Azure. Подключения также можно установить с локальными центрами обработки данных через ExpressRoute или site-to-site. В этом случае в виртуальной сети включается конечная точка службы, чтобы обеспечить передачу данных только между виртуальной сетью Azure и экземпляром Базы данных SQL.
• Azure DevOps используется для совместной работы команд во время спринтов, использования функций, поддерживающих гибкую разработку, а также для создания конвейеров сборки и выпуска.
• Была создана виртуальная машина сборки Azure, чтобы установленный агент смог извлечь соответствующую сборку и развернуть веб-приложение в среде.

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

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

• Azure Service Fabric. Если ваша среда в основном основана на Windows, а рабочие нагрузки в основном платформа .NET Framework основаны на платформа .NET Framework, и вы не рассматриваете перезаведение в .NET Core, а затем используйте Service Fabric для поддержки и развертывания контейнеров Windows Server. Кроме того, Service Fabric поддерживает интерфейсы программирования API для C# и Java, а для разработки собственных микрослужб можно подготовить кластеры на Windows или Linux.
• Служба Azure Kubernetes Service (AKS) — это проект с открытым кодом и платформа оркестрации, хорошо подходящая для размещения сложных многоконтейнерных приложений, которые обычно используют архитектуру на основе микрослужб. AKS — это управляемая служба Azure, которая абстрагирует сложности подготовки и настройки кластера Kubernetes. Однако для поддержки и поддержки требуется значительное знание платформы Kubernetes, поэтому размещение нескольких контейнерных веб-приложений с одним экземпляром может оказаться не лучшим вариантом.

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

• 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.

Надёжность

• Рекомендуется использовать геораспределенное масштабирование с Среда службы приложений для повышения устойчивости и масштабируемости.
• Ознакомьтесь с распространенными конструктивными шаблонами для обеспечения устойчивости и реализуйте их, если это уместно.
• Рекомендации по работе со Службой приложений Azure доступны в Центре архитектуры Azure.
• Рассмотрите возможность использования активной георепликации для хранилища данных и геоизбыточного хранилища для изображений и очередей.
• Сведения об обеспечении устойчивости см. в соответствующей статье в Центре архитектуры Azure.

Availability

• Рассмотрите возможность использования распространенных конструктивных шаблонов для обеспечения доступности при создании облачного приложения.
• Ознакомьтесь с вопросами доступности в соответствующем описании эталонной архитектуры для веб-приложения в Службе приложений.
• Дополнительные сведения о доступности см . в контрольном списке доступности в Центре архитектуры Azure.

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

• Ознакомьтесь с общими сведениями о компоненте безопасности.
• Ознакомьтесь с вопросами безопасности в соответствующем описании эталонной архитектуры для веб-приложения в службе приложений.
• Рассмотрим возможность применения процесса безопасного жизненного цикла разработки, чтобы помочь разработчикам создавать более безопасное программное обеспечения, выполнять требования к безопасности и снизить стоимость разработки.
• Ознакомьтесь со схемой архитектуры для соответствия требованиям Azure PCI DSS.
• Защита от атак DDoS Azure в сочетании с рекомендациями по проектированию приложений предоставляет расширенные функции защиты от атак DDoS. Необходимо включить защиту от атак DDoS Azure в любой виртуальной сети периметра.

Оптимизация затрат

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

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

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

Эффективность производительности

• Узнайте, как работает масштабирование в Среда службы приложений.
• Ознакомьтесь с рекомендациями по автомасштабированию облачных приложений.
• При создании облачного приложения следует учитывать распространенные конструктивные шаблоны для обеспечения масштабируемости.
• Ознакомьтесь с вопросами масштабируемости в соответствующем описании эталонной архитектуры для веб-приложения в Службе приложений.
• Дополнительные сведения о масштабируемости см . в контрольном списке производительности, доступном в Центре архитектуры Azure.

Соавторы

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

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

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

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

• Интеграция Среда службы приложений балансировки нагрузки с шлюзом приложений Azure
• Географическое распределенное масштабирование с помощью Среда службы приложений

Связанные ресурсы

• Эталонная архитектура веб-приложения в Службе приложений
• Высокодоступное корпоративное развертывание с помощью среды Служба приложений s