BYOD-політики для мобільного додатку: технічна реалізація

BYOD-політики для мобільного додатку: технічна реалізація

Уявіть: співробітник відкриває корпоративний додаток на особистому iPhone, а IT-відділ хвилюється про безпеку. Це типова ситуація для BYOD. Повний контроль над особистим пристроєм неможливий і неприпустимий. Рішення — грамотна архітектура BYOD-політик, що розділяє корпоративні та особисті дані. Ми накопичили досвід впровадження таких політик на iOS та Android — більш ніж 30 проєктів за 5 років. Без цих механізмів BYOD перетворюється на юридичну фікцію.

Які технічні складності виникають при впровадженні BYOD?

Основна складність — розмежування даних. Платформи пропонують різні механізми. iOS User Enrollment (починаючи з iOS 13) використовує окремий APFS-розділ для managed-даних. MDM бачить лише managed-простір: серійний номер прихований, UDID замінено на Enrollment ID. Android Work Profile — окремий профіль із власним launcher, keystore та ізольованим сховищем. Перемикання між профілями — свайп або іконка-портфель.

Як забезпечити безпеку BYOD на рівні додатку?

Розробник корпоративного додатку відповідає за коректну роботу в managed-середовищі. Ключові вимоги:

• Managed App Configuration. Додаток читає конфігурацію з managed-словника. На iOS — UserDefaults.standard.dictionary(forKey: "com.apple.configuration.managed"), на Android — RestrictionsManager.applicationRestrictions. За допомогою цього можна, наприклад, автоматично налаштувати сервер.
• Data Loss Prevention (DLP) флаги. Якщо MAM-політика забороняє copy-paste, додаток зобов'язаний це дотримуватися. Якщо заборонено save to personal storage — UIDocumentPickerViewController відкривається тільки в managed-просторі.
• Вимкнення знімків екрану в managed-стані. На iOS немає API заборонити screenshot, але UIScreen.isCaptured дозволяє приховати sensitive-контент:

NotificationCenter.default.addObserver(forName: UIScreen.capturedDidChangeNotification, object: nil, queue: .main) { _ in
    self.sensitiveView.isHidden = UIScreen.main.isCaptured
}

На Android — WindowManager.LayoutParams.FLAG_SECURE:

window.addFlags(WindowManager.LayoutParams.FLAG_SECURE)

• Selective Wipe. При отриманні MAM-команди wipe додаток очищає лише корпоративні дані. Реалізується через IntuneMAMPolicyDelegate.wipeDataForAccount() (Intune) або через BroadcastReceiver на Android з action com.microsoft.intune.mam.client.app.MAMSingleIdentityRequirements.WIPE_USER_DATA.
• Conditional Access — ключовий механізм: корпоративний додаток доступний тільки при дотриманні умов. Типовий набір для BYOD:
  • Пристрій зареєстровано в EMM (Intune/Workspace ONE).
  • ОС не старше N версій.
  • Немає ознак jailbreak/root.
  • Увімкнено шифрування диска.

На iOS jailbreak-детекція через додаток ненадійна (Dopamine, palera1n обходять більшість перевірок). Надійніше — Conditional Access на рівні Azure AD: Intune повідомляє про compliance-статус пристрою. Root-детекція на Android через RootBeer або власні перевірки:

val rootChecker = RootBeer(context)
if (rootChecker.isRooted) {
    // Повідомити MAM-політику, заблокувати доступ
}

Що входить в реалізацію BYOD-політик?

Ми пропонуємо комплексну послугу. Етапи:

1. Аудит поточної інфраструктури та типів пристроїв.
2. Вибір MDM/MAM платформи (Intune, Workspace ONE, MobileIron).
3. Проектування enrollment workflow та інтеграція з існуючою IT-архітектурою.
4. Адаптація додатку: Managed Config, DLP, wipe, аутентифікація.
5. Тестування на реальних пристроях в BYOD-сценаріях.
6. Підготовка юридичної документації (політика використання, згода співробітників).
7. Ролаут та навчання співробітників.

Терміни: адаптація готового додатку — 2–4 тижні; повний проєкт з вибором EMM — 6–10 тижнів. Вартість розраховується індивідуально. Отримайте консультацію — напишіть нам.

Організаційна складова

BYOD без чіткої політики використання — юридична проблема. Співробітник повинен підписати угоду: що IT може бачити (compliance status, app inventory в Work Profile), що не може (особисті дані, місцезнаходження поза робочим часом). Додаток на своєму рівні показує користувачеві при першому запуску, які дані збираються і як вони захищені — це не тільки UX, але й вимога GDPR. Наш досвід: правильно налаштований BYOD знижує витрати на 30–50%.

Типові помилки при впровадженні BYOD

• Використання лише MDM без MAM — додаток не отримує managed-конфігурацію.
• Ігнорування DLP-флагів — дані легко скопіювати в особисте сховище.
• Відсутність Selective Wipe — при видаленні користувача/пристрою залишаються корпоративні дані.
• Неправильне налаштування Conditional Access — доступ можливий з compromised-пристрою.

Системний підхід дозволяє уникнути цих помилок. Ми гарантуємо коректну роботу додатку в managed-середовищі та відповідність найкращим практикам безпеки. Замовте оцінку вашого проєкту — зв'яжіться з нами.

Докладніше про BYOD читайте в Wikipedia.

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

На 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 та динамічним аналізом.

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

Кейс з нашої практики: як ми закрили 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.