Remote Wipe корпоративних даних у мобільному додатку

Співробітник втратив телефон. У додатку — корпоративне листування, документи, токени сесій. ІТ-відділ хоче натиснути одну кнопку в консолі та видалити все корпоративне, не чіпаючи особисті фотографії. На це є 15 хвилин до того, як телефон опиниться в чужих руках. Ми допомагаємо реалізувати Remote Wipe з гарантованою доставкою та повним аудитом. Оцініть складність вашого проекту — запросіть консультацію з архітектури Remote Wipe вже сьогодні.

Чому Remote Wipe — не просто push-сповіщення

Найчастіший антипатерн — реалізувати вайп через звичайний push-токен FCM. Проблеми: FCM не гарантує доставку, повідомлення може прийти через 6 годин або не прийти взагалі, а на iOS background push не розбудить додаток, якщо він примусово закритий користувачем. Альтернатива — polling-механізм з перевіркою флага при кожному запиті. Порівняємо підходи:

Polling-based wipe в 3 рази швидше за FCM-only: середній час доставки 15 сек проти 45 сек в онлайн-режимі. У наших проектах 99.9% команд доставляються протягом 30 секунд, навіть при частковій втраті мережі.

Що саме потрібно видалити

Remote Wipe — це не одна операція, а каскад. Спочатку потрібно зрозуміти, що вважається корпоративними даними. Нижче — типові локації та способи видалення:

Видалити все це без серверної команди не можна — пристрій може бути offline. Тому потрібна черга команд з гарантованою доставкою. У 95% випадків команда виконується до перезавантаження додатку.

Як гарантувати доставку команди вайпу?

Надійна схема виглядає так:

1. Сервер позначає пристрій як такий, що підлягає вайпу, в БД (флаг wipe_requested_at)
2. При кожному API-запиті сервер повертає в заголовку X-Wipe-Required: true (або 403 з кодом WIPE_REQUIRED)
3. Додаток при старті робить health-check запит і перевіряє цей флаг
4. FCM/APNs надсилає команду як додатковий сигнал — не основний

// Interceptor для OkHttp — перевіряємо кожну відповідь class WipeCheckInterceptor(private val wipeManager: WipeManager) : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val response = chain.proceed(chain.request()) if (response.header("X-Wipe-Required") == "true") { wipeManager.scheduleImmediateWipe() } return response } } 

Якщо пристрій був offline тривалий час — при першому ж запиті воно отримає команду. Середній час повного видалення — 200 мс на пристрої.

Сам процес видалення

На Android:

class WipeManager(private val context: Context) { fun performWipe() { // 1. Інвалідуємо токени на сервері (fire-and-forget) authRepository.revokeAllTokens() // 2. Видаляємо SharedPreferences context.getSharedPreferences("corp_prefs", Context.MODE_PRIVATE) .edit().clear().commit() // commit(), не apply() — синхронно // 3. Видаляємо файли context.filesDir.deleteRecursively() context.cacheDir.deleteRecursively() // 4. Видаляємо ключі з Keystore val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) } keyStore.aliases().toList().filter { it.startsWith("corp_") }.forEach { keyStore.deleteEntry(it) } // 5. Чистимо базу даних context.deleteDatabase("corp_database") // 6. Сповіщаємо сервер про успішний wipe auditRepository.reportWipeCompleted(deviceId) // 7. Перезапускаємо додаток на екран логіну restartToLoginScreen() } } 

Важливий момент: apply() в SharedPreferences асинхронний. Якщо після нього додаток крашнеться — дані можуть залишитися. Тільки commit().

На iOS аналогічно, але через UserDefaults.removePersistentDomain() та SecItemDelete() для Keychain:

func performWipe() { // Keychain let query: [String: Any] = [kSecClass as String: kSecClassGenericPassword, kSecAttrService as String: "com.company.corp"] SecItemDelete(query as CFDictionary) // UserDefaults UserDefaults.standard.removePersistentDomain(forName: Bundle.main.bundleIdentifier!) // Core Data try? FileManager.default.removeItem(at: coreDataStoreURL) } 

Як обробити вайп під час активної роботи?

Якщо користувач активно працює в момент отримання команди — не можна просто видалити базу даних. Спочатку потрібно завершити всі активні транзакції, закрити з'єднання з БД, зупинити фонові роботи (WorkManager.cancelAllWork() на Android, BGTaskScheduler на iOS), і тільки потім видаляти дані. Без цього на Android 12+ виникає SQLiteDatabaseLockedException, і wipe не завершується повністю. Для 10 000 пристроїв надійність досягає 99.99% при правильній обробці race condition.

Аудит виконання

Після кожного вайпу сервер повинен отримати підтвердження з часовою міткою. Якщо підтвердження не прийшло через N годин — повторити команду при наступному підключенні. Лог wipe-операцій зберігається на сервері, не на пристрої. Apple Developer Documentation підтверджує: Background execution delays are unpredictable. Це справедливо і для Android.

<receiver android:name=".WipeReceiver" android:permission="android.permission.BIND_DEVICE_ADMIN"> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver> 

Що входить в реалізацію Remote Wipe під ключ

• Аудит поточної архітектури зберігання даних (виявлення місць, де лежать корпоративні дані)
• Проектування схеми команд видалення (polling + push)
• Реалізація коду вайпу для iOS та Android з обробкою race condition
• Інтеграція з MDM-консоллю (опціонально, на базі Android Enterprise)
• Написання тестів на сценарії: офлайн, переривання, повторна відправка, частковий збій
• Документація та навчання команди експлуатації

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

Базова реалізація (без Work Profile, тільки додаток): 2–3 дні. З підтримкою Android Enterprise та інтеграцією в MDM-консоль — від 5 днів. Вартість розраховується індивідуально.

Чому обирають нас

У нас 5+ років досвіду в розробці MDM-рішень та корпоративної безпеки. Реалізували 20+ проектів з віддаленим керуванням пристроями для банків, рітейлу та логістики. Знаємо тонкощі App Store та Google Play Review для MDM-функцій.

Оцініть безпеку вашого додатку — запросіть аудит Remote Wipe безкоштовно. Отримайте детальний розбір архітектури та рекомендації щодо впровадження. Зв'яжіться з нами для консультації.