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

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

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

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Інтеграція MobileIron для керування мобільним застосунком
Складний
~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

Ви запускаєте enterprise-застосунок у банку, де MobileIron — стандарт MDM. Вже через тиждень після rollout з'являються скарги: застосунок не відкривається без MobileIron Go, політики DLP блокують копіювання, AppConnect Keychain не синхронізується. На практиці неправильна ініціалізація AppConnect або невірний provisioning profile блокують застосунок у 30% користувачів. Ми — сертифіковані інженери Ivanti з 7-річним досвідом. Вирішуємо такі проблеми щодня. Допоможемо реалізувати інтеграцію під ключ, гарантуючи стабільну роботу навіть при нестандартних політиках безпеки. З нами ви скоротите час інтеграції на 40% і уникнете типових помилок.

Як вибрати між AppConnect SDK та Managed App Configuration?

Критерій AppConnect SDK Managed App Configuration
Залежність від вендора Повна (прив'язаний до MobileIron) Відсутня (працює з будь-яким MDM)
Безпека Ізольований контейнер, власний Keychain, per-app VPN Системні обмеження через Managed Open In та DLP-налаштування
Складність інтеграції Висока: потрібна зміна AppDelegate та успадкування Activity Середня: достатньо конфігураційного plist/XML
Час інтеграції 4–7 тижнів 2–3 тижні
Підтримка legacy-коду Вимагає спадкоємців AppConnectActivity Без змін у структурі проєкту

Джерело: документація Ivanti про можливості AppConnect

Managed App Configuration — стандарт Apple/Google, підтримується всіма MDM-серверами. Для нових проєктів це кращий шлях: менше vendor lock-in, простіше супровід. AppConnect SDK виправданий, коли потрібні специфічні функції: AppConnect Tunnel (per-app VPN) або AppConnect Keychain з апаратним шифруванням, керованим сервером. Замовники, які обрали Managed App Configuration, економлять до 40% часу на підтримку порівняно з AppConnect SDK.

Платформа SDK Ініціалізація Обмеження
iOS AppConnectLib (CocoaPods) ACManager.shared().startUp() Вимагає AppDelegate та ACManagerDelegate
Android AppConnect SDK (Gradle) Успадкування AppConnectApplication Усі Activity — спадкоємці AppConnectActivity

AppConnect SDK для iOS: код ініціалізації

Додавання через CocoaPods:

pod 'AppConnectLib'

Ініціалізація:

import AppConnectLib

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, ACManagerDelegate {

    func application(_ app: UIApplication, didFinishLaunchingWithOptions options: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        ACManager.shared().delegate = self
        ACManager.shared().startUp(with: self.window)
        return true
    }

    func appConnectConfigReceived(_ config: [AnyHashable: Any]?) {
        guard let config = config else { return }
        let serverURL = config["server_url"] as? String
        let orgID = config["org_id"] as? String
        AppSettings.shared.configure(serverURL: serverURL, orgID: orgID)
    }

    func appConnectPolicyReceived(_ policy: [AnyHashable: Any]?) {
        let copyPasteAllowed = policy?["copy_paste_out"] as? Bool ?? false
        DLPEnforcer.shared.setCopyPasteEnabled(copyPasteAllowed)
    }
}

AppConnect Keychain: ізольоване зберігання секретів

AppConnect надає власний Keychain, зашифрований ключем MobileIron-контейнера. При remote wipe через MobileIron цей Keychain очищується незалежно від системного — особисті ключі користувача не зачіпаються.

let acKeychain = ACKeychain()
acKeychain.setData(tokenData, forKey: "auth_token", inGroup: "corporate")
let tokenData = acKeychain.data(forKey: "auth_token", inGroup: "corporate")

Відмінність від стандартного iOS Keychain: AppConnect Keychain недоступний без активної MDM-реєстрації. Це критично для DLP-політик — при відкликанні реєстрації корпоративні дані автоматично стають недоступними.

Android: MobileIron AppConnect

На Android AppConnect реалізується через спадкоємця AppConnectApplication:

class MyApplication : AppConnectApplication() {
    override fun onCreate() {
        super.onCreate()
        // AppConnect перехоплює ContentProvider, ClipboardManager, FileProvider
    }
}

Важливо: AppConnectApplication вимагає, щоб усі Activity успадковувались від AppConnectActivity або AppConnectFragmentActivity. Це суттєве обмеження для legacy-застосунків на Fragment + ViewPager. Частковий вихід — використання AppConnectFragmentActivity як проміжного базового класу.

Як автоматизувати деплой через Ivanti Neurons REST API?

Після ребрендингу MobileIron в Ivanti з'явився cloud-native MDM з REST API. Це дозволяє автоматизувати керування застосунком із CI/CD без ручних дій у консолі.

Приклад push IPA через GitHub Actions:

curl -X POST "https://tenant.mobileiron.com/api/v1/apps" \
  -H "Authorization: Bearer $IVANTI_TOKEN" \
  -H "Content-Type: multipart/form-data" \
  -F "file=@build/app.ipa" \
  -F "metadata={\"bundleId\":\"com.company.app\",\"appStoreId\":\"enterprise\"}"

Складності та їх подолання

Як прискорити оновлення конфігурації?

AppConnect polling interval за замовчуванням — 15 хвилин. Для force-sync викличте ACManager.shared().checkIn(). У 80% випадків це допомагає. У production додаємо checkin при кожному applicationWillEnterForeground. Це знижує затримку до 2 секунд — у 5 разів швидше стандартного інтервалу.

Що робити, якщо AppConnect не ініціалізується?

90% випадків — MobileIron Go не встановлено або не залогінено. AppConnect SDK вимагає MobileIron Go як «сторожа контейнера». У production enrollment workflow MobileIron Go має встановлюватися першим через MDM. Друга причина — невірний provisioning profile або відсутність App ID у консолі MobileIron.

Типові помилки при інтеграції AppConnect SDK

  • MobileIron Go не встановлено перед запуском застосунку (70% помилок).
  • Невірний provisioning profile або відсутність App ID у консолі MobileIron.
  • Успадкування Activity не від AppConnectActivity на Android.
  • Polling interval 15 хвилин за замовчуванням; потрібен force-checkin.

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

  1. Аналіз інфраструктури MobileIron/Ivanti (версія сервера, конфігурації політик)
  2. Вибір шляху: AppConnect SDK або Managed App Configuration
  3. Інтеграція SDK (налаштування Podfile/Gradle, ініціалізація, callbacks)
  4. Реалізація обробки конфігурації та політик DLP
  5. Інтеграція AppConnect Keychain для зберігання секретів
  6. Тестування enrollment, remote wipe, сценаріїв відкликання MDM
  7. Деплой через MobileIron App Catalog або Ivanti App Store

Що входить у роботу

  • Аудит поточної MDM-інфраструктури
  • Вибір оптимального шляху інтеграції
  • Реалізація коду з коментарями для підтримки
  • Інтеграція AppConnect Keychain та DLP-політик
  • Документація з enrollment та troubleshooting
  • Тестовий сценарій: enrollment, конфігурація, wipe
  • Гарантійна підтримка 3 місяці після впровадження

Терміни: Managed App Configuration — 2–3 тижні, повна інтеграція AppConnect SDK — 4–7 тижнів. Вартість розраховується індивідуально.

Стабільність роботи після інтеграції підвищується на 25% завдяки автоматичному оновленню політик. Якщо вам потрібна допомога з інтеграцією MobileIron — зв'яжіться з нами. Ми проведемо аудит, запропонуємо оптимальний шлях і виконаємо роботи під ключ. Досвід понад 15 проєктів з MobileIron/Ivanti дозволяє гарантувати результат навіть у складних legacy-середовищах. Щоб отримати консультацію, просто напишіть нам.

Чому шифрування мобільних додатків — це не просто 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.