Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается, как развертывать безопасные приложения с помощью среды службы приложений. Эта архитектура использует шлюз приложений Azure и брандмауэр веб-приложений Azure для ограничения доступа к приложениям из Интернета. В этой статье также объясняется, как интегрировать непрерывную интеграцию и непрерывное развертывание (CI/CD) с средами службы приложений с помощью Azure DevOps.
Такие отрасли, как банковские и страховые услуги, часто используют это решение, так как клиенты ценят безопасность на уровне платформы и уровня приложений. Чтобы продемонстрировать эти понятия, в следующем примере приложения пользователи могут отправлять отчеты о расходах.
Архитектура
Скачайте файл Visio этой архитектуры.
Поток данных
Следующий поток данных соответствует предыдущей схеме:
HTTP-запросы и HTTPS достигают шлюза приложений.
При необходимости для веб-приложения включена проверка подлинности Microsoft Entra. После достижения трафика шлюза приложений пользователю будет предложено предоставить учетные данные для проверки подлинности в приложении. На схеме этот шаг не отображается.
Запросы пользователя проходят через внутреннюю подсистему балансировки нагрузки (ILB) среды, которая направляет трафик в веб-приложение расходов.
Пользователь создает отчет о расходах.
В рамках создания отчета о расходах развертываемое приложение API вызывается для получения имени и электронной почты руководителя пользователя.
Система хранит отчет о расходах в базе данных SQL Azure.
Чтобы упростить непрерывное развертывание, код возвращается в экземпляр Azure DevOps.
Виртуальная машина сборки включает агент Azure DevOps. Этот агент позволяет виртуальной машине сборки извлекать артефакты веб-приложения и использовать их для развертывания веб-приложения в среде службы приложений. Виртуальная машина сборки находится в подсети в той же виртуальной сети, что и среда службы приложений.
Компоненты
Среда службы приложений предоставляет полностью изолированную выделенную среду для безопасного запуска приложения в большом масштабе. Среда службы приложений и ее рабочие нагрузки находятся за виртуальной сетью, поэтому программа установки добавляет дополнительный уровень безопасности и изоляции. В этом сценарии используется среда службы приложений ILB для обеспечения высокой масштабируемости и изоляции.
Эта рабочая нагрузка использует ценовую категорию "Изолированная служба приложений". Приложение выполняется в частной выделенной среде в центре обработки данных Azure, в котором используются более быстрые процессоры и хранилище SSD-накопителя, а также предоставляет максимальные возможности масштабирования.
Функции веб-приложений и приложений API узла веб-приложений службы приложений и API RESTful. Эти приложения и API размещаются в плане изолированной службы, который также предоставляет автомасштабирование, пользовательские домены и другие возможности в выделенном уровне.
Шлюз приложений — это подсистема балансировки нагрузки веб-трафика уровня 7, которая управляет трафиком в веб-приложение. Он обеспечивает разгрузку уровня SSL, которая удаляет затраты на расшифровку трафика с веб-серверов, на которых размещено приложение.
Брандмауэр веб-приложения — это функция шлюза приложений, повышающего безопасность. Брандмауэр веб-приложения использует правила Open Worldwide Application Security Project (OWASP) для защиты веб-приложения от атак, таких как межсайтовый скрипт, перехват сеансов и внедрение SQL.
База данных SQL хранит данные приложения. Большая часть данных реляционная, с некоторыми данными, хранящимися в виде документов и больших двоичных объектов.
Виртуальная сеть Azure предоставляет различные сетевые возможности в Azure. Вы можете объединить виртуальные сети и установить подключения к локальным центрам обработки данных через ExpressRoute или виртуальную частную сеть типа "сеть — сеть" (VPN). Этот сценарий позволяет конечной точке службы в виртуальной сети обеспечить потоки данных только между виртуальной сетью Azure и экземпляром базы данных SQL.
Azure DevOps поддерживает гибкую разработку, помогая командам сотрудничать во время спринтов и предоставляя средства для создания конвейеров сборки и выпуска.
Виртуальная машина сборки Azure позволяет установленному агенту извлекать соответствующую сборку и развертывать веб-приложение в среде.
Альтернативные варианты
Среда службы приложений может запускать обычные веб-приложения в Windows или, как в этом примере, веб-приложения, которые выполняются как контейнеры Linux, развернутые в среде. Этот сценарий использует среду службы приложений для размещения этих контейнерных приложений с одним экземпляром. При разработке решения рассмотрите следующие варианты:
Приложения контейнеров Azure — это бессерверная платформа, которая снижает нагрузку на инфраструктуру и экономит затраты при выполнении контейнерных приложений. Это устраняет необходимость управления конфигурацией сервера, оркестрацией контейнеров и сведениями о развертывании. Приложения-контейнеры предоставляют все ресурсы сервера up-to-date, необходимые для обеспечения стабильной и безопасной защиты приложений.
Служба Azure Kubernetes (AKS) — это проект с открытым исходным кодом и платформа оркестрации, предназначенная для размещения сложных многоконтайнерных приложений, которые обычно используют архитектуру на основе микрослужб. AKS — это управляемая служба Azure, которая упрощает подготовку и настройку кластера Kubernetes. Для поддержания и администрирования платформы Kubernetes необходимо иметь значительные знания, поэтому размещение только нескольких одиночных экземпляров контейнерных веб-приложений может быть не лучшим вариантом.
Используйте следующую альтернативу для уровня данных:
- Azure Cosmos DB является хорошим вариантом, если большинство данных находится в нереляционном формате.
Потенциальные варианты использования
Рассмотрим это решение для следующих вариантов использования:
- Создайте веб-приложение Azure, требующее дополнительной безопасности.
- Предоставьте выделенный клиент, а не общие планы службы приложений клиента.
- Используйте Azure DevOps с внутренней средой службы приложений с балансировкой нагрузки .
Решения по проектированию TLS и DNS
Параметры системы доменных имен (DNS) для суффикса домена по умолчанию среды службы приложений не ограничивают доступность приложений этими именами. Функция суффикса личного домена для среды службы приложений ILB позволяет использовать собственный суффикс домена для доступа к приложениям, размещенным в среде службы приложений.
Суффикс личного домена определяет корневой домен, который использует среда службы приложений. Для среды службы приложений ILB по умолчанию используется appserviceenvironment.netкорневой домен по умолчанию. Среда службы приложений ILB является внутренней виртуальной сетью клиента, поэтому клиенты могут использовать корневой домен в дополнение к домену по умолчанию, который соответствует своей среде виртуальной сети. Например, корпорация Contoso может использовать корневой домен по умолчанию для приложений, предназначенных internal.contoso.com для разрешения и доступа только в виртуальной сети Компании Contoso. Доступ к приложению в этой виртуальной сети можно получить.APP-NAME.internal.contoso.com
Суффикс личного домена применяется к среде службы приложений. Эта функция отличается от привязки личного домена к отдельному экземпляру службы приложений.
Если сертификат, используемый для суффикса личного домена, содержит запись *.scm.CUSTOM-DOMAINальтернативного имени субъекта (SAN), сайт диспетчера управления версиями (SCM) становится доступным из APP-NAME.scm.CUSTOM-DOMAIN. Доступ к SCM можно получить только через личный домен с помощью базовой проверки подлинности. Единый вход доступен только при использовании корневого домена по умолчанию.
При управлении сертификатами в среде службы приложений ILB следует учитывать следующие факторы:
Храните действительный сертификат SSL или TLS в хранилище ключей Azure. Формат PFX.
Убедитесь, что сертификат меньше 20 КБ.
Используйте подстановочный сертификат для выбранного имени личного домена.
Настройте управляемое удостоверение, назначаемое системой или назначаемое пользователем, для среды службы приложений. Управляемое удостоверение проходит проверку подлинности в хранилище ключей Azure, где находится SSL-сертификат или TLS.
Ожидается, что среда службы приложений будет применять изменения сертификата в течение 24 часов после смены в хранилище ключей.
Сетевой доступ к Azure Key Vault
Вы можете получить доступ к хранилищу ключей публично или через частную конечную точку, доступную из подсети, в которой развернута среда службы приложений.
Если вы используете общедоступный доступ, вы можете защитить хранилище ключей только для приема трафика из исходящего IP-адреса среды службы приложений.
Среда службы приложений использует исходящий IP-адрес платформы в качестве исходного адреса при доступе к хранилищу ключей. Этот IP-адрес можно найти на странице IP-адресов на портале Azure.
Конфигурация DNS
Чтобы получить доступ к приложениям в среде службы приложений с помощью суффикса личного домена, настройте собственный DNS-сервер или настройте DNS в частной зоне DNS Azure для личного домена. Дополнительные сведения см. в разделе "Конфигурация DNS".
Безопасное уникальное имя узла по умолчанию
Функция безопасного уникального имени узла по умолчанию предоставляет долгосрочное решение для защиты ресурсов от переключения записей DNS и переключения поддомена. Если включить эту функцию для ресурсов службы приложений, никто за пределами организации не сможет повторно создать ресурсы, имеющие одно и то же имя узла по умолчанию. Эта защита предотвращает использование злоумышленниками записей DNS и переключения поддоменов злоумышленников. Дополнительные сведения см. в разделе "Безопасные уникальные имена узлов по умолчанию".
Рекомендации
Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. вWell-Architected Framework.
Надёжность
Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Дополнительные сведения см. в контрольном списке проверки конструктора для обеспечения надежности.
Рекомендуется использовать геораспределенное масштабирование с средами службы приложений для повышения устойчивости и масштабируемости.
Просмотрите типичные шаблоны проектирования для обеспечения устойчивости и реализуйте их в соответствии с соответствующими параметрами.
Рекомендуется использовать активную георепликацию для уровня данных и геоизбыточного хранилища для образов и очередей.
Дополнительные сведения см. в следующих ресурсах:
Доступность
При создании облачного приложения рекомендуется применять типичные шаблоны проектирования для доступности .
Ознакомьтесь с рекомендациями по доступности в соответствующей эталонной архитектуре веб-приложения службы приложений.
Дополнительные сведения о доступности см. в руководствах по надежности по службе.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проверки конструктора для безопасности.
Ознакомьтесь с рекомендациями по безопасности в соответствующей эталонной архитектуре веб-приложения службы приложений.
Рассмотрите возможность выполнения процесса жизненного цикла разработки безопасности , чтобы помочь разработчикам создавать более безопасное программное обеспечение и устранять требования к обеспечению безопасности при снижении затрат на разработку.
Используйте рекомендации по защите от атак DDoS Azure и приложения, чтобы повысить защиту от распределенных атак типа "отказ в обслуживании" (DDoS). Включите защиту от атак DDoS в виртуальных сетях периметра.
Оптимизация затрат
Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проверки конструктора для оптимизации затрат.
Изучите затраты на выполнение этого сценария. Следующие примеры профилей затрат основаны на ожидаемом трафике. Все службы предварительно настроены в калькуляторе затрат.
Небольшое развертывание: этот пример ценообразования представляет компоненты для минимального экземпляра рабочего уровня, который обслуживает несколько тысяч пользователей каждый месяц. Приложение использует один небольшой экземпляр изолированного веб-приложения. Каждый дополнительный компонент масштабируется до уровня "Базовый", чтобы свести к минимуму затраты, обеспечивая поддержку соглашения об уровне обслуживания и достаточную емкость для обработки рабочей нагрузки уровня рабочей нагрузки.
Среднее развертывание: этот пример ценообразования представляет компоненты для развертывания среднего размера, которое обслуживает примерно 100 000 пользователей каждый месяц. Экземпляр службы приложений с умеренным размером управляет трафиком. Увеличение емкости шлюза приложений и базы данных SQL для поддержки добавленной рабочей нагрузки.
Крупное развертывание: этот пример ценообразования представляет компоненты для масштабируемого приложения, которое обслуживает миллионы пользователей каждый месяц и перемещает терабайты данных. Для этого уровня использования требуются высокопроизводительные и изолированные веб-приложения, развернутые в нескольких регионах, а также для диспетчера трафика Azure. Оценка включает диспетчер трафика и дополнительные экземпляры шлюза приложений и виртуальной сети. Емкость базы данных SQL увеличивается для поддержки добавленной рабочей нагрузки.
Чтобы просмотреть цены для конкретного варианта использования, измените соответствующие переменные в соответствии с ожидаемым трафиком.
Эффективность производительности
Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Дополнительные сведения см. в контрольном списке проверки конструктора для повышения эффективности.
Узнайте, как работает масштабирование в средах службы приложений.
Ознакомьтесь с рекомендациями по автомасштабированию облачных приложений.
Общие сведения о шаблонах проектирования для масштабируемости при создании облачного приложения.
Ознакомьтесь с рекомендациями по масштабируемости в соответствующей эталонной архитектуре веб-приложения службы приложений.
Соавторы
Корпорация Майкрософт поддерживает эту статью. Следующие участники написали эту статью.
Автор субъекта:
- Николас МакКоллум | Главный инженер клиента
Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Интеграция среды службы приложений ILB с шлюзом приложений Azure
- Геораспределаемый масштаб с средами службы приложений