Dell Command | Secure BIOS Configuration - SaaS Offer via Microsoft Azure Marketplace

Уражені продукти:

• Dell Command | Безпечна конфігурація BIOS
• Комерційні клієнтські пристрої Dell (ноутбуки, настільні комп'ютери, робочі станції)

Зміст

• Вступ
• Модель розгортання — хостинг клієнтом на Azure
• DCSBC Cloud проти DCSBC On-Premises (DCC)
• Інфраструктура як код (Terraform)
• Підготовчі дії
• Початок — доступ до хмарного порталу DCSBC
• Створення політик BIOS
  • Робочий процес політики автентифікації
  • Робочий процес політики налаштувань BIOS
  • Робочий процес політики депровізінгу
• Вимоги до сертифіката та завантаження
• Політики публікації в Microsoft Intune
• Контроль безпеки
• Запитання й відповіді:

Вступ

Інтерфейси керованості базуються на відкритих інтерфейсах або командах, автентифікованих паролем. Автентифікація за паролем вразлива до грубої сили або словникової атаки, тому є менш безпечною порівняно з автентифікацією на основі ключів. Потрібен кращий автентифікований інтерфейс керованості для забезпечення цілісності та конфіденційності даних і команд. Dell Command | Secure BIOS Configuration (DCSBC) — це підхід для відходу від автентифікації команд DACI за допомогою паролів BIOS. DCSBC забезпечує довірену комунікацію, створюючи інтерфейс, що використовує механізми автентифікації PKI (Public Key Infrastructure) та зашифровані канали для передачі повідомлень між платформою та клієнтом. Такий підхід забезпечує як цілісність, так і конфіденційність для захисту даних клієнтів.
DCSBC Cloud розширює цю можливість на хмарну SaaS-модель, розгорнуту у власній підписці Azure клієнта. Замість встановлення та підтримки сервера DCSBC локально з Dell Command | Configure(DCC), ІТ-адміністратори отримують доступ до веб-порталу, розміщеного у власному середовищі Azure. Вся інфраструктура автоматично надається через Terraform (Infrastructure as Code). Політики створюються через керований покроковий веб-портал і публікуються безпосередньо в Microsoft Intune — без локального налаштування сервера, без генерації автономних виконуваних файлів (SCE) і без необхідності встановлення агента кінцевої точки.

Ключові переваги хмари DCSBC:

• Клієнт володіє своїми даними —Вся інфраструктура працює за підпискою Azure клієнта. Політики BIOS, криптографічні ключі, дані конфігурації та журнали аудиту залишаються під повним контролем і власністю клієнта. Dell не має доступу до даних клієнтів.
• Суверенітет і дотримання даних — Клієнти обирають регіон Azure для розгортання, забезпечуючи виконання вимог щодо проживання даних. Усі дані залишаються в межах вибраного регіону.
• Інфраструктура як код - Усе рішення надається через Terraform, забезпечуючи повторювані, аудитовані та контрольовані версіями розгортання інфраструктури.
• Немає локальної інфраструктури - Усуває необхідність встановлювати та підтримувати сервер DCSBC з Dell Command | Налаштуйте.
• Веб-управління політиками — Створюйте та керуйте політиками BIOS з будь-якого браузера за допомогою інтуїтивного покрокового майстра.
• Рідна інтеграція з Intune — Політики публікуються безпосередньо в Microsoft Intune як Win32 LOB-додатки одним кліком.
• Безагентне розгортання — На кінцевих точках агент не потрібен. Розгорнутий пакет є автономним.
• Azure Managed HSM signing - Усі корисні навантаження BIOS криптографічно підписуються за допомогою Azure Managed HSM (RS384), що гарантує, що пристрої потрапляють лише авторизовані зміни.
• Архітектура з нульовою довірою — Довіра існує лише між BIOS та сервісом DCSBC Cloud; Довіра не потрібна для клієнта/кінцевої точки.
• Вбудоване запобігання атак повтору — кожна сесія BIOS використовує унікальні криптографічні nonces та ефемерні обміни ключами, що гарантує, що раніше захоплені корисні навантаження не можуть бути повторно використані або відтворені проти пристроїв.
• Криптографічно прив'язані до пристрою корисні навантаження — конфігураційні навантаження BIOS криптографічно прив'язані до кожного окремого пристрою під час встановлення сесії, що запобігає застосуванні корисних навантажень, призначених для одного пристрою, до іншого.

Повернутися до початку

Модель розгортання — хостинг клієнтом на Azure

На відміну від традиційних SaaS-пропозицій, де постачальник розміщує інфраструктуру, DCSBC Cloud розгортається у власній підписці Microsoft Azure клієнта. Ця архітектура надає кілька ключових переваг:

• Володіння та контроль даних: Усі ресурси Azure — обчислювальні ресурси, сховище, база даних, HSM, мережа — розміщені в орендарі Azure та підписці клієнта. Конфігурації політик BIOS, криптографічні ключі підпису, дані сесій та журнали аудиту зберігаються у власній Azure SQL Database клієнта, Azure Key Vault / Managed HSM та Azure Storage Account. Dell Technologies не має доступу до даних, ключів чи інфраструктури клієнта. Клієнт зберігає повний адміністративний контроль.
• Суверенітет даних та відповідність: Клієнт обирає регіон Azure для розгортання (наприклад, Східна частина США 2, Західна Європа, Австралія Схід). Усі ресурси забезпечуються в межах цього одного регіону.
  Сховище за замовчуванням використовує локально резервне сховище (LRS), що гарантує, що дані не покидають вибраний регіон. Це можна налаштувати на георезервне зберігання (GRS) або зонально-резервне зберігання (ZRS) залежно від вимог клієнта. Модель, розміщена клієнтом, підтримує дотримання правил щодо проживання даних (GDPR, закони про суверенітет даних, галузеві вимоги), оскільки клієнт контролює, де знаходяться дані.
• Ізоляція орендарів: Кожен клієнт отримує повністю ізольоване розгортання: власну Групу ресурсів, Віртуальну мережу, підмережі, бази даних, ключові сховища та всі інші ресурси. Ізоляція мережі забезпечується через приватні кінцеві точки, групи мережевої безпеки та міжмережевий екран Azure.
• Прозорість витрат: Усі витрати на ресурси Azure відображаються у власному білінгу клієнта в Azure Billing, що забезпечує повну видимість витрат на інфраструктуру. Клієнт може використовувати існуючі зобов'язання Azure (MACC — Microsoft Azure Consumption Commitment) та зарезервовані екземпляри.

Повернутися до початку

DCSBC Cloud проти DCSBC On-Premises (DCC)

Примітка:
Обидва рішення мають однаковий базовий протокол рівня BIOS, включно з сесійними командами з обміном ключами Діффі-Хеллмана, захистом від повтору без основ та PKI-автентифікацією (PKI). Політики, створені в будь-якому з цих рішень, сумісні з тими ж комерційними клієнтськими реалізаціями BIOS Dell.

Повернутися до початку

Інфраструктура як код (Terraform)

Вся хмарна інфраструктура DCSBC налаштована за допомогою Terraform (HashiCorp), забезпечуючи повторювані, аудитовані та контрольовані версіями розгортання. Конфігурація Terraform є модульною та параметризованою, що дозволяє кожне розгортання клієнта налаштовуватися під їхній регіон Azure, правила іменування та вимоги масштабу.
Огляд конфігурації Terraform:

• Версія Terraform: >= 1.3.0
• AzureRM provider: ~> 4.37.0
• Державне управління: Віддалений стан, збережений у Azure Storage Account (Azure AD auth)
• Azure Resources Provisioned: Наступні ресурси автоматично надаються у підписку Azure клієнта:

Повернутися до початку

Підготовчі дії

Перед використанням DCSBC Cloud переконайтеся, що виконані такі вимоги:

• Microsoft Azure Subscription - A active Azure subscription with an Azure Entra ID (Azure AD) tenant.
• Microsoft Intune — активне середовище Microsoft Intune, налаштоване для керування пристроями.
• Комерційні клієнтські пристрої Dell — цільовими пристроями мають бути комерційні ноутбуки, настільні комп'ютери або робочі станції Dell з BIOS з підтримкою DCSBC, зареєстровані в Microsoft Intune.
• Azure Managed HSM або Azure Key Vault — Azure Managed HSM або Key Vault екземпляр, наданий ключами RSA-HSM, що відповідають сертифікатам, що використовуються для автентифікації BIOS. Приватний ключ має зберігатися в HSM; лише публічний сертифікат (.pem) завантажується на портал DCSBC Cloud.
• Сертифікати X.509 — сертифікати RSA, що відповідають таким вимогам:
  • Довжина ключа: 3072-бітна RSA (точно)
  • Формат: PEM (розширення файлу .pem)
  • Версія: X.509 v3
  • Розмір файлу: максимум 8 КБ
  • Алгоритм: RSA (OID 1.2.840.113549.1.1.1)
• Підтримуваний браузер — сучасний веб-браузер (Microsoft Edge, Google Chrome, Mozilla Firefox).

Повернутися до початку

Початок — доступ до хмарного порталу DCSBC

• Підписатися — придбати Dell Command | Secure BIOS Configuration Cloud через Microsoft Azure Marketplace.
• Увійти — перейдіть за URL хмарного порталу DCSBC, який надається після підписки. Увійдіть за допомогою своїх облікових даних Microsoft Entra ID (Azure AD). Портал використовує Microsoft Authentication Library (MSAL) для одноразового входу.
• Цільова сторінка — після автентифікації вас перенаправляють на панель BIOS Policies. Звідси ви можете:
  • Перегляньте існуючі політики BIOS, опубліковані для вашого орендаря Intune
  • Створіть нову політику за допомогою покрокового веб-порталу

Повернутися до початку

Створення політик BIOS

На сторінці політик BIOS натисніть Створити нову політику. Ви побачите три типи полісів:

Виберіть тип політики для початку керованого чарівника. Ці політики розгортаються безпосередньо з Intune на ваші кінцеві точки без необхідності встановлення жодних агентів кінцевих пристроїв.

Примітка.

У будь-якому випадку на клієнтській машині можна встановити лише один ключ забезпечення.

Примітка.

На клієнтській машині одночасно можна встановити до семи командних ключів.

Робочий процес політики автентифікації

Майстер політики автентифікації має 3 кроки:

Крок 1 — Назвіть свою політику

• Введіть назву політики (обов'язково, максимум 488 символів). Автоматично додаються префікс AUTH_ та суфікс часової мітки _DD.MM.YY_HH:mm_UTC.
• Введіть необов'язковий опис (максимум 1000 символів).
• Повна назва політики (включаючи префікс і суфікс, максимум 512 символів) переглядається перед продовженням.
• Дубльовані імена політик автоматично виявляються шляхом перевірки існуючих опублікованих політик в Intune.

Крок 2 — Керування безпекою BIOS (завантаження сертифіката)

• Завантажити до 3 сертифікатів загалом:
  • 1 Сертифікат провізінгу (обов'язковий) — використовується для автентифікації безпечного підключення для операцій провізингу.
  • До 2 сертифікатів команд — використовуються для підписання корисних навантажень при зміні конфігурації BIOS.
• Для кожного сертифіката оберіть: 
  • Тип: Забезпечення або командування
  • Політичні дії: Додати (забезпечити новий ключ)
• Сертифікати перевіряються на стороні клієнта (див. Вимоги до сертифіката та завантаження).
• Кнопка «Наступний» активується, коли:
  • Завантажується сертифікат налагодження
  • 1 Командний сертифікат завантажено

Крок 3 — Огляд і публікація

• Перегляньте назву, опис і тип поліса.
• Натисніть «Опублікувати», щоб опублікувати політику в Microsoft Intune (див. Політики публікації в Microsoft Intune).

Повернутися до початку

Робочий процес політики налаштувань BIOS

Майстер політики налаштувань BIOS має 4 або 5 кроків (залежно від наявності існуючих політик BIOS в Intune):

Крок 1 — Скопіювати та відредагувати, або Почати з нуля (умовно — показується лише, якщо існують існуючі політики)

• Почніть порожній файл політики — Почніть з порожньої конфігурації.
• Копіювати, потім редагувати — Скопіюйте значення атрибутів BIOS з існуючої опублікованої політики та змініть їх. Модаль показує пошуковий, сортований, пагінований список існуючих політик BIOS.

Крок 2 — Назвіть свою політику

• Те саме, що й політика автентифікації, але з префіксом BIOS_.

Крок 3 — Виберіть атрибути та значення BIOS

• Таблиця відображає всі доступні атрибути BIOS з реєстру атрибутів Dell.
• Шукайте атрибути за назвою, фільтруйте за категоріями та перемикайтеся, щоб показувати лише вибрані атрибути.
• Виберіть атрибут, натиснувши його галочку, а потім налаштуйте його значення:
  • Атрибути enum (наприклад, SecureBoot, WakeOnLan) — Виберіть із випадаючого списку дозволених значень.
  • Атрибути цілих чисел (наприклад, AutoOnHr, CustomChargeStart) — Введіть число в межах діапазону min-max.
  • Атрибути рядків (наприклад, AssetTag) — Введіть текст до 80 символів.
  • Власні функції (наприклад, планування AutoOn, налаштування заряду батареї, колір підсвічування клавіатури) — натисніть «Переглянути/Змінити», щоб відкрити спеціальний модаль конфігурації.
• Панель попереднього перегляду коду показує живий попередній перегляд обраної конфігурації у форматі CCTK:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• Кнопка «Наступний» вимкнена, якщо не вибрано жодного атрибута або будь-який вибраний атрибут має недійсне значення.

Крок 4 — Керування безпекою BIOS

• Завантажте той самий сертифікат команди , який використовувався для політики автентифікації.
• Для продовження потрібен один сертифікат командування.

Крок 5 — Огляд і публікація

• Перегляньте та опублікуйте їх у Microsoft Intune.

Повернутися до початку

Робочий процес політики депровізінгу

Майстер політики депровізування має 3 кроки:

Крок 1 — Назвіть свою політику

• Так само, як і в інших полісах, з префіксом DPRV_.

Крок 2 — Управління безпекою BIOS

• Завантажте той самий сертифікат Provisioning , який використовувався для політики автентифікації.
• Потрібен один сертифікат Provisioning.
• Примітка: Прострочені сертифікати дозволені для операцій з депровізінгу, оскільки мета полягає у видаленні провізінгу з пристроїв.

Крок 3 — Огляд і публікація

• Рецензуйте та опублікуйте. Політика депровізінгу використовує операцію Clear DACI для видалення всіх наданих ключів із цільових пристроїв.

Повернутися до початку

Вимоги до сертифіката та завантаження

DCSBC Cloud вимагає сертифікати X.509 у форматі PEM для підписування корисних навантажень BIOS. Приватний ключ має зберігатися в Azure Managed HSM або Azure Premium Key Vault; лише публічний сертифікат завантажується на портал DCSBC.

Правила перевірки сертифікатів:

Валідація здійснюється на стороні клієнта. Після завантаження сертифіката портал відображає:

• Значок статусу валідації (Успіх / Провал)
• Видано за датою
• Дійсна дата до кінця (вказано червоним, якщо вона закінчена)
• Інформація про емітента: Загальна назва (CN), Організаційна одиниця (OU), Організація (O), Місцезнаходження (L)

Повідомлення про помилку

• "Будь ласка, завантажте дійсний .pem-файл." -- Файл не у форматі PEM або має неправильне розширення.
• "Ім'я файлу містить недійсні символи." -- Ім'я файлу містить пробіли або спеціальні символи.
• "Максимальний розмір файлу — 8KB" — файл перевищує ліміт у 8 КБ.
• "Цей файл недійсний, пошкоджений або порожній. Виберіть інший файл із дійсним сертифікатом x509 і спробуйте знову.» --Сертифікат не вдалося проаналізувати або не проходить перевірку X.509 v3 / RSA / 3072-біт.
• "Цей сертифікат не може бути використаний." -- Сертифікат прострочений, і дії політики — «Додати».

Повернутися до початку

Політики публікації в Microsoft Intune

Після завершення майстера політики натисніть кнопку «Публікувати » на кроці «Перегляд і публікація». Портал виконує автоматизований 11-ступеневий конвеєр публікації:

Індикатор прогресу та детальний трекер сцени показують статус публікації в реальному часі. Після успішного завершення:

• Відображається повідомлення «Політика {policyName} опублікована в Intune і буде доступна протягом кількох хвилин».
• Перегляд в Intune — Відкриває портал адміністратора Microsoft Intune у новій вкладці.
• Повернення до політик — повернення до панелі BIOS Policies.

Обробка помилок: Якщо якийсь етап не провалює, з'являється повідомлення про помилку кнопкою Retry (до 3 повторень). Поширені помилки включають тайм-аути Intune API, збої завантаження пам'яті та затримки фіксації файлів.

Повернутися до початку

Контроль безпеки

DCSBC Cloud впроваджує захист у глибині захисту на всіх рівнях інфраструктури. Оскільки рішення працює в підписці Azure, усі системи безпеки підлягають аудиту і контролюються під управлінням клієнта.

Безпека мережі

• Приватні кінцеві точки гарантують, що трафік між Azure сервісами (база даних, сховище ключів, HSM, сховище, сервіси додатків) ніколи не перетинає публічний інтернет.
• Доступ до публічної мережі за замовчуванням вимкнений для всіх сервісів на площині даних. Публічно доступні лише шлюз API та кінцеві точки CDN.
• Групи мережевої безпеки (NSG) контролюють вхідний і вихідний трафік для кожної підмережі за детальними правилами.
• Ізоляція віртуальної мережі — Усі ресурси розгортаються в одному VNet з розділеними підмережами для кожного рівня сервісу.

Безпека додатків:

• Веб-додатковий міжмережевий екран (WAF) з керованими правилами OWASP у режимі Prevention, що забезпечує захист від поширених веб-експлойтів (SQL-ін'єкції, XSS тощо).
• Міжмережевий екран рівня CDN забезпечує додатковий шар WAF на периферії.
• Обмеження швидкості API — Обмеження швидкості на основі IP-операцій захищає бекенд-сервіси від зловживань і атак відмови в обслуговуванні.
• Валідація токена Azure AD JWT — Усі виклики API перевіряються для токенів автентифікації Azure AD, що гарантує, що доступ до бекенд-сервісів можуть лише авторизовані користувачі.
• Обмеження CORS — Крос-запити обмежуються лише авторизованими джерелами.

Шифрування

• Мінімальний стандарт TLS 1.2 застосовується у всіх сервісах, дозволяючи лише сильні шифрові набори.
• Azure Managed HSM — Криптографічні операції підписування використовують апаратні модулі безпеки FIPS 140-2 рівня 3, що гарантує, що ключі ніколи не розкриваються в програмному забезпеченні.
• Дані у стані спокою шифруються за допомогою шифрування платформи Azure у всіх сервісах зберігання.

Ідентичність і доступ:

• Керовані ідентичності (нуль збережених облікових даних) — Azure Managed Identities використовуються для всієї автентифікації сервіс-сервіс. У конфігурації додатку не зберігаються паролі, рядки з'єднання чи секрети.
• RBAC з найменшими привілеями — Кожна керована ідентичність отримує лише мінімально необхідні ролі відповідно до принципу найменших привілеїв.
• Azure Bastion — Безпечний адміністративний доступ до керуючих віртуальних машин без розкриття публічних IP.

Моніторинг і сповіщення:

• Автоматизовані сповіщення про критичні події безпеки та операцій, включно з порушеннями обмеження швидкості, помилками бекенду, спробами несанкціонованого доступу, шаблонами блокування WAF, аномаліями затримки API та збоями з підписуванням HSM.
• Комплексне діагностичне логування на всіх компонентах інфраструктури — API-шлюзі, шлюзі додатків, веб-додатках, базі даних, сховищі ключів і HSM — з журналами, зібраними в централізованому робочому просторі Log Analytics.
• Дашборди для видимості операцій у реальному часі та аналізу тенденцій.

Управління

• Перевірки політик перед розгортанням (на основі OPA) забезпечують базові стандарти безпеки перед налаштуванням інфраструктури, включно з обмеженнями доступу до публічних мереж, мінімальними TLS-версіями, вимогами до захисту від очищення та публічними IP-контролями.
• Блокування ресурсів запобігає випадковому видаленню критично важливих сховищ даних (сховища ключів, бази даних, облікові записи зберігання).

Повернутися до початку

Запитання й відповіді:

Питання: Я вже використовую DCSBC з Dell Command | Налаштуйте локально. Чи можу я мігрувати на DCSBC Cloud?

Так. Обидва рішення використовують однаковий протокол рівня BIOS (DACI з PKI-автентифікацією). Пристрої, надані локальним рішенням, можуть керуватися через DCSBC Cloud і навпаки, за умови використання тих самих сертифікатів/ключів. Вам потрібно завантажити свої існуючі сертифікати на портал DCSBC Cloud і переконатися, що відповідні приватні ключі доступні в Azure Managed HSM або Key Vault.

Питання: Де працює DCSBC Cloud? Чи розміщує її Dell?

Ні. DCSBC Cloud розгортається у вашій власній підписці Microsoft Azure. Вся інфраструктура — обчислювальна, сховище, база даних, HSM, мережа — працює у вашому орендарі Azure. Dell не хостить і не має доступу до ваших даних чи інфраструктури. Повне рішення автоматично надається за допомогою Terraform.

Питання: Чи має Dell доступ до моїх політик BIOS, ключів або конфігураційних даних?

Ні. Оскільки DCSBC Cloud працює повністю в межах вашої підписки Azure, усі дані залишаються під вашим контролем. Dell надає програмне забезпечення та шаблони Terraform, але не отримує доступ, не зберігає і не обробляє ваші дані.

Питання: Чи можу я обрати, в якому регіоні Azure розгортати?

Так. Область Azure є параметром у конфігурації Terraform. Ви можете розгортати його в будь-якому підтримуваному регіоні Azure, щоб відповідати вимогам щодо зберігання даних і відповідності. Усі ресурси забезпечуються в межах одного обраного регіону.

Питання: Чи потрібно мені встановлювати Dell Command | Налаштувати на сервері DCSBC Cloud?

Ні. Локального сервера немає. Інфраструктура налаштована у вашій підписці Azure через Terraform, а додаток працює як сервіси, керовані Azure (App Service, Function App, Static Web App).

Питання: Чи потрібно встановлювати програмне забезпечення Dell на кінцеві пристрої?

Ні. Пакети .intunewin, розгорнуті через Intune, є автономними і містять усі необхідні компоненти. Встановлення агента кінцевих пристроїв не потрібне.

Питання: Які консолі розгортання підтримуються?

DCSBC Cloud наразі підтримує Microsoft Intune як консоль розгортання. Локальний DCSBC з DCC додатково підтримує SCCM та WorkspaceONE.

Питання: Чи можу я використовувати власного HSM-провайдера замість Azure Managed HSM?

DCSBC Cloud розроблений для роботи з Azure Managed HSM або Azure Key Vault. Якщо вам потрібен інший провайдер HSM, розгляньте можливість використання локального DCSBC з DCC, який підтримує HSM, незалежний від постачальника, через налаштовуваний HSMSigning.bat скрипт.

Питання: Які розміри ключів RSA підтримуються?

DCSBC Cloud вимагає рівно 3072-бітних RSA-ключів. Ключі інших розмірів (2048-біт, 4096-біт тощо) будуть відхилені під час перевірки сертифіката.

Питання: Чи можу я використовувати один і той самий сертифікат як для локальних, так і для хмарних рішень DCSBC?

Так, якщо приватний ключ доступний у обох середовищах — зберігається у вашому локальному HSM/сховищі сертифікатів для локального рішення, а також у Azure Managed HSM або Key Vault для хмарного рішення.

Питання: Що станеться, якщо мій сертифікат закінчиться?

Прострочені сертифікати не можуть використовуватися для операцій «Додавання» (провізинг). Однак для операцій з депровізінгу приймаються прострочені сертифікати, оскільки мета полягає у видаленні провізінгу з пристроїв.

Питання: Які налаштування BIOS я можу налаштувати?

DCSBC Cloud включає комплексний реєстр атрибутів BIOS, що охоплює такі категорії, як безпека, управління живленням і продуктивністю, конфігурація системи, відео та розширені конфігурації. Прикладами є SecureBoot, WakeOnLan, порядок завантаження, планування AutoOn, конфігурація заряду батареї, колір підсвічування клавіатури та багато інших.

Питання: Яка версія Terraform потрібна для розгортання DCSBC Cloud?

Terraform >= 1.3.0 потрібен, з провайдером AzureRM ~> 4.37.0.

Питання: Чи можу я налаштувати розгортання Terraform (наприклад, розміри SKU, масштабування, резервування зберігання)?

Так. Конфігурація Terraform повністю параметризована за допомогою змінних. Ви можете налаштувати SKU App Service Plan, рівень бази даних, тип реплікації сховища (LRS/GRS/ZRS), налаштування автоматичного масштабування App Gateway та інше залежно від ваших вимог до масштабу та доступності.