Госкомпания хочет дать сотрудникам мобильное приложение – заявки на отпуск, согласования, корпоративный справочник, push-уведомления. Звучит как стандартный проект. Но как только устройство покидает периметр офиса, оно уносит с собой служебные данные, и требования меняются. На корпоративном смартфоне сотрудника лежат персональные данные, внутренние документы, токены доступа к информационным системам. Здесь работают не общие практики App Store, а сочетание реестрового ПО, MDM и контроля над тем, где физически хранятся данные.

Реестровый стек вместо привычных сервисов

Push через сервисы Google и Apple для госкомпании – слабое место: трафик уходит за рубеж, а доставку нельзя гарантировать при ограничениях. Поэтому базовый выбор – отечественная мобильная ОС из реестра (Аврора) либо собственный билд Android без сервисов Google, с собственным push-сервером внутри контура.

Серверная часть приложения должна быть из единого реестра российского ПО: СУБД (Postgres Pro), сервер приложений, брокер сообщений. Это не формальность – для госзаказчика реестровая запись закрывает требования к импортозамещению и снимает риски при проверках. Когда мы переносим аналитику внутрь периметра, действуют те же принципы, что мы описывали в материале про RAG в закрытом контуре: данные и обработка не должны покидать контролируемую зону.

Отдельный вопрос – качество справочных данных, которые приложение тянет из бэкенда. Если оргструктура и контакты в источнике грязные, мобильный клиент честно покажет дубли и устаревшие должности. Поэтому перед запуском мы прогоняем источники через ту же дисциплину, что и в чистке данных для BI – нормализация, дедупликация, единый справочник подразделений.

MDM: управление устройством, а не только приложением

MDM (Mobile Device Management) отвечает на простой вопрос: что произойдёт с данными, если телефон украдут или сотрудник уволится. Корпоративное приложение без MDM – это служебная информация без замка.

Минимальный набор политик, который мы закладываем на старте:

  • разделение рабочего и личного профилей (work profile), чтобы корпоративные данные не смешивались с личными;
  • принудительное шифрование хранилища и обязательный код-пароль или биометрия;
  • удалённая блокировка и wipe рабочего профиля при потере устройства или увольнении;
  • запрет копирования из рабочих приложений в личные, контроль буфера обмена и скриншотов;
  • белый список приложений и проверка целостности ОС (детект root/jailbreak).

MDM-платформу тоже берём из реестра. Связку «реестровая ОС + реестровый MDM + реестровый бэкенд» проще защищать перед регулятором и при аттестации.

Где проходит граница КИИ

Если мобильное приложение обращается к информационным системам, отнесённым к критической информационной инфраструктуре, мобильный канал становится частью защищаемого периметра. Это меняет требования к каналу связи (VPN с сертифицированной криптографией), к журналированию доступа и к самому процессу разработки. Мы рекомендуем определить статус систем заранее – последовательность шагов мы разобрали в дорожной карте по КИИ, и мобильный проект логично встраивается в неё, а не запускается в обход.

На практике это означает, что архитектуру приложения нужно проектировать вместе со службой безопасности с первого дня, а не приносить готовый продукт на согласование перед релизом.

Вывод

Мобильное приложение для госкомпании – это не «то же самое, но на телефоне». Реестровый стек закрывает импортозамещение, MDM закрывает потерю устройства, а ранний учёт требований КИИ закрывает регуляторные риски. Все три слоя проектируются вместе, и именно из этих ограничений вырастает мобильная разработка для бизнеса и госсектора, а не из готовых шаблонов App Store.