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 бесплатно. Получите детальный разбор архитектуры и рекомендации по внедрению. Свяжитесь с нами для консультации.