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

Служба приложений Azure

Шлюз приложений Azure

База данных SQL Azure

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

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

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

Решения по проектированию TLS и DNS

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

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

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

Сделайте самозаверяющий или внутренне выданный SSL-сертификат работой, если вы хотите выполнять безопасные вызовы между службами, работающими в Среда службы приложений ILB. Другое решение, которое следует рассмотреть , как сделать среду службы приложений 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 Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. вWell-Architected Framework.

Надёжность

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Дополнительные сведения см. в контрольном списке проверки конструктора для обеспечения надежности.

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

Доступность

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

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

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проверки конструктора для безопасности.

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

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

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проверки конструктора для оптимизации затрат.

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

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

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

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

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Дополнительные сведения см. в контрольном списке проверки конструктора для повышения эффективности.

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

Соавторы

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

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

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

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

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

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

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

Решения по проектированию TLS и DNS

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

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

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

Сделайте самозаверяющий или внутренне выданный SSL-сертификат работой, если вы хотите выполнять безопасные вызовы между службами, работающими в Среда службы приложений ILB. Другое решение, которое следует рассмотреть , как сделать среду службы приложений 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 Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. вWell-Architected Framework.

Надёжность

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Дополнительные сведения см. в контрольном списке проверки конструктора для обеспечения надежности.

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

Доступность

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

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

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проверки конструктора для безопасности.

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

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

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проверки конструктора для оптимизации затрат.

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

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

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

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

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Дополнительные сведения см. в контрольном списке проверки конструктора для повышения эффективности.

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

Соавторы

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

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

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

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

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

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

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