В этой статье представлен обзор развертывания безопасных приложений с помощью среды службы приложение Azure. Чтобы ограничить доступ к приложениям из Интернета, используются служба Шлюз приложений Azure и Azure Брандмауэр веб-приложений. В этой статье также приводятся рекомендации по непрерывной интеграции и непрерывному развертыванию (CI/CD) для сред службы приложений с помощью Azure DevOps.
Этот сценарий обычно развертывается в таких отраслях, как банковские и страховые, где клиенты осознают безопасность на уровне платформы в дополнение к безопасности на уровне приложений. Чтобы продемонстрировать эти концепции, мы будем использовать приложение, позволяющее пользователям отправлять отчеты о расходах.
Потенциальные варианты использования
Рассмотрите этот сценарий для следующих вариантов использования:
- Создание веб-приложения Azure, где требуется дополнительная безопасность.
- Предоставление выделенной аренды, а не использование планов Службы приложений с общим арендатором.
- Использование Azure DevOps с внутренней средой службы приложений с балансировкой нагрузки (ILB).
Архитектура
Скачайте файл Visio для этой архитектуры.
Поток данных
- HTTP/HTTPS-запросы сначала поступают в Шлюз приложений.
- При необходимости (не показанная на схеме) можно включить проверку подлинности Microsoft Entra для веб-приложения. После первого попадания трафика в Шлюз приложений пользователю будет предложено предоставить учетные данные для проверки подлинности в приложении.
- Запросы пользователей проходят через внутреннюю подсистему балансировки нагрузки (ILB) среды, которая, в свою очередь, направляет трафик в веб-приложение Expenses.
- Затем пользователь переходит к созданию отчета о расходах.
- При создании отчета о расходах вызывается развернутое приложение API для получения имени и электронной почты руководителя пользователя.
- Созданный отчет о расходах сохраняется в Базе данных SQL Azure.
- Чтобы упростить непрерывное развертывание, код возвращается в экземпляр Azure DevOps.
- На виртуальной машине сборки установлен агент 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 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 PCI DSS.
- Защита от атак DDoS Azure в сочетании с рекомендациями по проектированию приложений предоставляет расширенные функции защиты от атак DDoS. Необходимо включить защиту от атак DDOS Azure в любой виртуальной сети периметра.
Устойчивость
- Рекомендуется использовать геораспределенное масштабирование с Среда службы приложений для повышения устойчивости и масштабируемости.
- Ознакомьтесь с распространенными конструктивными шаблонами для обеспечения устойчивости и реализуйте их, если это уместно.
- Рекомендации по работе со Службой приложений Azure доступны в Центре архитектуры Azure.
- Рассмотрите возможность использования активной георепликации для хранилища данных и геоизбыточного хранилища для изображений и очередей.
- Сведения об обеспечении устойчивости см. в соответствующей статье в Центре архитектуры Azure.
Развертывание этого сценария
Чтобы развернуть этот сценарий, выполните пошаговые инструкции по развертыванию каждого компонента вручную. Выберите Среда службы приложений версии 3 вместо версии 2 при выполнении руководства. В этом руководстве также содержится пример приложения .NET, в котором используется простое приложение Contoso для создания отчетов о расходах.
Ценообразование
Изучите затраты на выполнение этого сценария. В калькуляторе цен стоимость использования всех служб рассчитывается на основе предварительно выбранных параметров. Чтобы узнать, как изменится цена для конкретного варианта использования, измените соответствующие переменные в соответствии с ожидаемым трафиком.
Мы предоставили три примера профилей затрат на основе объема трафика, который вы ожидаете получить:
- Малый: этот пример ценообразования представляет компоненты, необходимые для минимального экземпляра уровня производства, обслуживающего несколько тысяч пользователей в месяц. Приложение использует один экземпляр стандартного веб-приложения, которого будет достаточно для автомасштабирования. Каждый из остальных компонентов масштабируется до базового уровня, который свести к минимуму затраты, но по-прежнему обеспечивает поддержку соглашения об уровне обслуживания и достаточную емкость для обработки рабочей нагрузки на уровне рабочей среды.
- Средний: этот пример ценообразования представляет компоненты, необходимые для развертывания среднего размера. Здесь мы оцениваем примерно 100 000 пользователей в течение месяца. Ожидаемый трафик обрабатывается в одном экземпляре службы приложения со средним стандартным уровнем. Кроме того, в калькулятор добавляются средние уровни когнитивных и поисковых служб.
- Большой. Этот профиль предполагает развертывание крупномасштабного приложения с миллионами пользователей в месяц и трафиком в терабайты данных. На этом уровне использования требуются высокопроизводительные веб-приложения уровня "Премиум", развернутые в нескольких регионах, перед которыми работает диспетчер трафика. Данные состоят из следующих компонентов: хранилища, базы данных и CDN, настроенные для терабайтов данных.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Фейсал Мустафа | Старший инженер клиента
Следующие шаги
- Руководство по пошаговому развертыванию
- Интеграция среды службы приложений с внутренней системой балансировки нагрузки (ILB) со шлюзом приложений Azure
- Интеграция веб-приложений со Шлюзом приложений Azure
- Географическое распределенное масштабирование с помощью Среда службы приложений