Android Enterprise Work Profile: настройка корпоративных приложений

Реализация Work Profile: от DPC до managed configurations

Типичная ситуация: ИТ-отдел хочет установить корпоративное приложение на личные смартфоны сотрудников без полного контроля над устройством. Без Work Profile приходится либо отдавать весь девайс под MDM, либо мириться с отсутствием изоляции. Мы решаем эту задачу настройкой Android Enterprise Work Profile с нуля — это официальное решение Google для BYOD, поддерживаемое с Android 5.0 (API 21). Согласно документации Android Enterprise Overview, Work Profile обеспечивает изоляцию данных на уровне ядра, что критично для соответствия политикам безопасности. Бюджет внедрения рассчитывается индивидуально, при этом экономия на лицензиях MDM может достигать 70%.

Типичные ошибки при интеграции Work Profile

Самая распространённая ошибка — регистрация приложения как Device Owner вместо Profile Owner. Device Owner получает полномочия блокировать Bluetooth, менять обои и другие личные функции, что вызывает негатив. Для BYOD нужен именно ProfileOwner. Проверьте флаг isProfileOwnerApp() using the Device Policy Controller (DPC). Другая частая проблема — cross-profile intent. Если бизнес-логика требует передавать данные из рабочего профиля в личный (например, открыть PDF), нужно явно разрешить intent через DevicePolicyManager.addCrossProfileIntentFilter(). Без этого intent молча глотается — пользователь видит пустой экран, а в Logcat тишина. На одном проекте с Intune мы потратили день на отладку подобного сценария. Также многие команды игнорируют RestrictionsManager для managed configurations, передавая настройки через push-уведомления. Это антипаттерн: EMM-система (Intune, Workspace ONE) должна деплоить конфиг через APP_RESTRICTIONS_CHANGED, а приложение — читать из Bundle. ИТ-администратор может менять сервер, таймауты или фичи без нового релиза.

Как мы реализуем Work Profile на практике?

Процесс начинается с аудита: какой MDM у клиента, какие версии Android в парке (от 5.0 до 14+), BYOD или COBO. Для BYOD через QR-код используем код регистрации Profile Owner:

val dpm = getSystemService(DevicePolicyManager::class.java)
val adminComponent = ComponentName(this, DeviceAdminReceiver::class.java)
if (dpm.isProfileOwnerApp(packageName)) {
    dpm.setProfileName(adminComponent, "Корпоративный профиль")
    dpm.setCrossProfileCalendarPackages(adminComponent, setOf(calendarPackage))
}

Пример настройки managed configurations:

val restrictionsManager = getSystemService(RestrictionsManager::class.java)
val appRestrictions = restrictionsManager.applicationRestrictions
val serverUrl = appRestrictions.getString("server_url") ?: BuildConfig.DEFAULT_SERVER
val ssoEnabled = appRestrictions.getBoolean("sso_enabled", false)

Почему сертификаты и VPN требуют особого подхода?

Установка клиентских сертификатов через KeyChain.createInstallIntent() работает только в личном профиле. В рабочем — только через DevicePolicyManager.installCaCert() и installKeyPair(). Путаница здесь стоит нескольких дней отладки. На одном проекте мы потеряли два дня, пока не поняли, что сертификат нужно устанавливать через DPC. Для VPN в рамках рабочего профиля используйте VpnService с флагом setAlwaysOnVpnPackage() через DPC. Трафик корпоративного профиля уходит через корпоративный VPN, личный — через обычный интернет, пользователь этого не чувствует.

Как настроить managed configurations?

Managed configurations позволяют ИТ-администратору удалённо задавать параметры приложения (сервер, таймауты, SSO). Для этого создаётся XML-схема по стандарту AppConfig Community, а приложение считывает настройки через RestrictionsManager. Это надёжнее push-уведомлений и не требует нового релиза при изменении параметров. Типовой процесс: разрабатываете схему, публикуете в EMM, при подписке на политику конфигурация автоматически применяется.

Пошаговая настройка рабочего профиля

1. Выбор метода провизионирования. Для BYOD используйте QR-код или NFC; для корпоративных — Zero-touch. Убедитесь, что DPC поддерживает Profile Owner.
2. Регистрация DPC как ProfileOwner. В манифесте укажите android:profileOwner=true. После установки приложение запросит права администратора.
3. Настройка managed configurations. Создайте XML-схему по стандарту AppConfig Community. Внедрите RestrictionsManager.
4. Разрешение cross-profile intent. Добавьте фильтры для необходимых intent.
5. Установка сертификатов и VPN. Используйте DevicePolicyManager.installCaCert() и setAlwaysOnVpnPackage() для рабочего профиля.
6. Тестирование. Проверьте на реальных устройствах с TestDPC и разными API (21+).

Сравнение методов провизионирования

Сравнение Profile Owner и Device Owner

Что входит в настройку Work Profile?

• Аудит текущей EMM-платформы и парка устройств (50–5000 шт.)
• Разработка или доработка DPC под Profile Owner
• Создание XML-схемы managed configurations по стандарту AppConfig Community
• Интеграционное тестирование с TestDPC и реальными устройствами (Android 7.0–14.0)
• Документация для ИТ-отдела по деплою политик через EMM

Наши результаты

Более 5 лет опыта в MDM-интеграциях. 20+ успешных проектов для компаний с парком от 50 до 5000 устройств. Внедрение Work Profile сокращает время на развёртывание корпоративных приложений на 70% — в 2 раза быстрее, чем при полном MDM-контроле. Полностью исключаются утечки данных через личные приложения. Гарантируем изоляцию корпоративных данных и совместимость с любым EMM.

Сроки и стоимость

Типовой проект (существующее приложение + Work Profile без кастомного DPC) — от 2 рабочих дней. Если требуется собственный DPC с нуля — от 1 недели. Стоимость рассчитывается индивидуально после аудита. Оценим ваш проект бесплатно. Свяжитесь с нами для консультации — поможем выбрать оптимальное решение для вашей инфраструктуры. Закажите аудит прямо сейчас — получите развернутый план внедрения.

Безопасность мобильных приложений: OWASP MASVS, pinning и защита от реверса

Мы провели аудит более 40 мобильных приложений — и на каждом втором находили токены в UserDefaults, отсутствие pinning и открытый для реверса код. OWASP Mobile Application Security Verification Standard (MASVS) — не академический документ. Это чек-лист пентестера. И то, что он находит, часто требует не patch, а переписывания целых модулей. Разберём три самые болезненные точки: certificate pinning, обфускация и хранение секретов. И покажем, как их закрыть без даунтаймов на продакшне.

Почему certificate pinning ломает продакшн?

Certificate Pinning — привязка приложения к конкретному TLS-сертификату или его публичному ключу. Без него трафик перехватывается через Charles или mitmproxy за пять минут — это OWASP MASVS-NETWORK-2. Но в продакшн pinning часто ломает: сертификат истёк, резервный пин не настроен — пользователи не могут войти. Крупное финансовое приложение в 2022 году ушло в даунтайм на 8 часов именно из-за этого.

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

На 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 сломается. Конфигурация должна быть поддоменно-специфичной.

Как защитить данные в 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% за первый месяц.

Обфускация и защита кода

iOS: Swift-код компилируется в нативный бинарник, который не декомпилируется до читаемого Swift. Но Objective-C runtime и Mach-O metadata дают много информации через class-dump и nm. Имена классов, методов, строки в бинарнике — всё видно. Для критичных строк (ключи конфигурации — не API-ключи, их там быть не должно) используем обфускацию через SwiftShield.

Android: Java/Kotlin компилируется в DEX, который читается через jadx за секунды. R8 (включён по умолчанию в release сборках) минифицирует и обфусцирует. Но ProGuard/R8 rules нужно тщательно настраивать: после включения обфускации приложение крашится в production из-за рефлексии или Gson-сериализации. Отладочные -dontwarn правила, накопленные годами — источник дыр в защите.

Для максимальной защиты Android — DexGuard (платный) или свободный DexProtector. Они добавляют runtime-защиту, шифрование строк и проверки целостности. Обфускация DexGuard в среднем снижает вероятность успешного реверс-инжиниринга на 70% по сравнению с базовым R8.

Обнаружение jailbreak и root

MASVS-RESILIENCE-1 требует обнаружения компрометированных устройств. Стандартные проверки: наличие /Applications/Cydia.app, /usr/bin/ssh, способность записать файл за пределами sandbox (/private/jailbreak_test), наличие MobileSubstrate.

Но статические проверки легко обходятся через A-Bypass, Liberty Lite и аналогичные твики. Серьёзная защита строится на нескольких слоях с runtime-проверками, которые не тривиально перехватить через frida или fishhook.

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

Что входит в работу по безопасности мобильного приложения

Как мы реализуем защиту: кейс

Один клиент пришёл с банковским приложением, которое не проходило аудит безопасности. Мы заменили UserDefaults на Keychain, добавили certificate pinning через TrustKit, настроили R8 с кастомными правилами (исключили 15 краш-кейсов, связанных с рефлексией). Через три недели повторный пентест показал 0 критических уязвимостей. С момента внедрения — ни одного инцидента за два года.

Сроки и стоимость

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

Каждый проект оцениваем индивидуально — пишите, пришлём детальный breakdown с учётом вашего стека и объёмов. Работаем под ключ: от анализа до деплоя в сторах.

OWASP Mobile Application Security Verification Standard — основной референс для всех наших аудитов. Подтверждаем соответствие уровню L1 сертификатами, а для enterprise-приложений — L2.

Оценим ваш проект за один рабочий день после получения APK/IPA. Свяжитесь — расскажем, какие дыры закроем в первую очередь.