Інтеграція Microsoft Intune для керування мобільним застосунком

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Інтеграція Microsoft Intune для керування мобільним застосунком
Складний
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    745
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1162
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    563

Корпоративні застосунки на iOS та Android потребують політик, які не можна реалізувати через стандартні обмеження ОС. Якщо в організації вже розгорнуті Azure AD, Office 365 і Teams, Microsoft Intune — це де-факто стандарт EMM. Ми спеціалізуємося на інтеграції Intune SDK і MSAL у мобільні застосунки, забезпечуючи Conditional Access на рівні Azure AD та захист даних через MAM. Одного разу нам надійшов проєкт для великого банку: потрібно було за два тижні впровадити Intune MAM у вже існуючий React Native застосунок. Впоралися за 12 робочих днів — і тепер розповімо, як уникнути типових помилок.

Intune — де-факто стандарт EMM для Microsoft-орієнтованих організацій. Якщо інфраструктура на Azure AD, Office 365, Teams — Intune логічний вибір: єдина консоль, Conditional Access на рівні Azure AD, нативна інтеграція з Defender for Endpoint. Для мобільного застосунку інтеграція означає підтримку MAM SDK або App Wrapping + коректну роботу з MSAL для отримання токенів з урахуванням compliance-статусу пристрою.

Реєстрація застосунку в Azure AD

Перший крок — App Registration в Azure Portal. Без коректної реєстрації Intune не зможе застосовувати політики до застосунку.

Мінімальний набір налаштувань:

  1. Створити App Registration в Azure AD.
  2. Додати API Permissions: DeviceManagementApps.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All (якщо застосунок читає політики напряму).
  3. Додати IntuneMAM в Redirect URI: msauth.{bundle-id}://auth.
  4. Увімкнути Public client flows для мобільних клієнтів.
  5. В Intune Portal (portal.azure.com → Intune → Client Apps) додати застосунок в App Protection Policy та призначити на групи.

Як працює Conditional Access з MSAL?

MSAL (Microsoft Authentication Library) — заміна ADAL, обов'язковий компонент для сучасної Intune-інтеграції. Conditional Access працює автоматично: якщо пристрій non-compliant (застаріла ОС, jailbreak за оцінкою Intune), MSAL отримує MSALError з кодом conditionalAccessClaim — застосунок має повторно запитати токен з додатковими claims. MSAL v1.1+ обробляє CA challenge автоматично за умови коректної конфігурації.

iOS (Swift):

import MSAL

let config = MSALPublicClientApplicationConfig(
    clientId: "YOUR_CLIENT_ID",
    redirectUri: "msauth.com.company.app://auth",
    authority: try MSALAADAuthority(url: URL(string: "https://login.microsoftonline.com/YOUR_TENANT_ID")!)
)
config.bypassRedirectURIValidation = false
let application = try MSALPublicClientApplication(configuration: config)

let webParameters = MSALWebviewParameters(authPresentationViewController: viewController)
let interactiveParameters = MSALInteractiveTokenParameters(
    scopes: ["https://graph.microsoft.com/.default"],
    webviewParameters: webParameters
)

application.acquireToken(with: interactiveParameters) { result, error in
    if let result = result {
        // result.accessToken — використовувати для API-запитів
        // result.account — зберегти для silent token refresh
    }
}

Intune MAM SDK: ключові точки інтеграції

Після додавання IntuneMAMSwift (iOS) або intune-mam-sdk (Android) — декілька обов'язкових точок:

Реєстрація акаунта після авторизації:

// Після успішного MSAL login
IntuneMAMEnrollmentManager.instance().loginAndEnrollAccount(userPrincipalName)
// SDK реєструє UPN в MAM-сервісі та запитує політики

Обробка enrollment callback:

class MAMEnrollmentDelegate: NSObject, IntuneMAMEnrollmentDelegate {
    func enrollmentRequestWithStatus(_ status: IntuneMAMEnrollmentStatus) {
        switch status.statusCode {
        case .enrollmentSuccess:
            // Політики застосовано, дозволяємо доступ до корпоративних функцій
        case .enrollmentFailed:
            // Показуємо помилку, обмежуємо доступ
        case .unenrollmentSuccess:
            // Selective wipe завершено
        }
    }
}

Перевірка політики перед дією:

let policyManager = IntuneMAMPolicyManager.instance()
if policyManager.policy(forIdentity: userUPN).isSaveToPersonalAllowed(for: .camera) {
    // Дозволити збереження в Camera Roll
} else {
    showRestrictedActionAlert()
}

Що дає Managed App Configuration?

В Intune Portal для кожного застосунку можна задати Configuration Policy — словник ключів/значень, який застосунок читає через UserDefaults.standard.dictionary(forKey: "com.apple.configuration.managed") (iOS) або RestrictionsManager (Android). Це дозволяє IT-адміністратору змінювати параметри (наприклад, URL бекенду або таймаут сесії) без оновлення застосунку.

Типові параметри для корпоративного застосунку:

<!-- App Configuration Policy в Intune Portal (XML формат) -->
<dict>
    <key>BackendURL</key>
    <string>https://api.corp.example.com</string>
    <key>TenantID</key>
    <string>corp-tenant-001</string>
    <key>EnableVerboseLogging</key>
    <false/>
    <key>SessionTimeoutMinutes</key>
    <integer>30</integer>
</dict>

Інтеграція з Microsoft Defender for Endpoint

Якщо в організації використовується Defender for Endpoint (MDE), Intune може отримувати від нього сигнали про mobile threat defense: джейлбрейк, шкідливі мережі, вразливі застосунки. Conditional Access використовує ці сигнали для блокування токенів. Для цього в застосунок вбудовується Defender SDK — він працює фоном, надсилає threat events в MDE, Intune отримує compliance status. З точки зору застосунку — це окрема залежність, але без змін в основній бізнес-логіці.

Порівняння підходів: MAM SDK проти App Wrapping

Параметр MAM SDK App Wrapping
Зміна коду Потрібна Не потрібна
Гнучкість управління Висока (фінальний контроль) Середня (обмежені політики)
Швидкість впровадження 3–5 тижнів 1 тиждень
Платформи iOS, Android, React Native, Flutter Тільки iOS та Android

MAM SDK дає повний контроль над корпоративними даними без необхідності використовувати App Wrapping — це в 3 рази швидше з точки зору налаштування політик і не потребує зміни коду сторонніх модулів.

Що входить в нашу роботу

Ми забезпечуємо повний цикл інтеграції:

  • Аудит поточного застосунку та конфігурації Azure AD.
  • Реєстрація застосунку в Azure AD та налаштування необхідних дозволів.
  • Інтеграція MSAL з підтримкою Conditional Access.
  • Вбудовування Intune MAM SDK (iOS/Android/React Native/Flutter).
  • Реалізація enrollment lifecycle та selective wipe.
  • Налаштування Managed App Configuration та App Protection Policy.
  • Тестування всіх сценаріїв: Conditional Access, захист перенесення файлів, блокування на non-compliant пристроях.
  • Документація для IT-відділу та навчання адміністраторів.
  • Підтримка на етапі релізу в App Store та Google Play.

Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо комерційну пропозицію протягом дня. Замовте інтеграцію під ключ — терміни від 3 до 8 тижнів залежно від складності.

Наш досвід — 5 років в enterprise мобільній розробці, понад 20 успішних проєктів з Intune, включаючи банки, ритейл та логістику. Гарантуємо чисту інтеграцію без конфліктів з existing-кодом та повне проходження App Store Review.

Етапи інтеграції

Azure AD App Registration → налаштування MSAL → додавання Intune MAM SDK → реалізація enrollment lifecycle → Managed App Configuration → App Protection Policy в Intune Portal → тестування Conditional Access → тестування selective wipe → rollout.

Терміни: інтеграція MSAL + MAM SDK в готовий застосунок — 3–5 тижнів. З налаштуванням Intune Portal, політик та тестуванням — 6–8 тижнів. Вартість розраховується індивідуально.

Детальніше про Intune SDK читайте в офіційній документації Microsoft, а про MSAL — в MSAL для iOS.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

  1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
  2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
  3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

Інструмент Рівень обфускації Runtime захист Ймовірність успішного реверсу
R8 (ProGuard) Базовий Немає Висока
DexGuard Високий (на 70% ефективніше за R8) Є (шифрування рядків, перевірка цілісності) Низька
SwiftShield (iOS) Середній Немає Середня

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Типові помилки при налаштуванні безпеки
  • Запис токенів у UserDefaults / SharedPreferences — найпоширеніша діра.
  • Відсутність backup pin при certificate pinning — гарантія даунтайму.
  • Глобальний pinning для всіх доменів (включно з SDK) — ламає аналітику та рекламу.
  • Неочищені правила ProGuard/R8 з -dontwarn — джерело вразливостей.
  • Одна статична перевірка jailbreak — легко обходиться твіками.

Що входить в роботу з безпеки мобільного додатка

Етап Що робимо Результат
Аудит за OWASP MASVS L1/L2 Аналіз бінарника, трафіку, вихідних кодів Звіт з критичністю, рекомендації
Реалізація pinning Налаштування TrustKit / network_security_config, тест на продакшн-сертифікаті Захищений канал без регресій
Обфускація та R8/ProGuard-тюнінг Налаштування правил, тести на краші, інтеграція SwiftShield/DexGuard Бінарник, важкочитаний для jadx/class-dump
Jailbreak/root-детекція Встановлення IOSSecuritySuite / rootbeer + runtime-перевірки Додаток блокується на зламаних пристроях
Безпечне зберігання Keychain / EncryptedSharedPreferences+Keystore Токени та секрети не витікають навіть при бекапі
Підтримка та документація Інтеграція в CI, навчання розробників Все відтворюється на нових версіях

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

  • Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
  • Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
  • Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.