Всем привет! Меня зовут Александр Конин, я продакт-менеджер «Аврора Центр». Платформа управляет устройствами на Авроре, Android и российских дистрибутивах Linux, но в этой статье речь пойдёт о банках и биометрии.
Два банка из ТОП-5 уже собирают биометрию на устройствах с Авророй, управляемых через «Аврора Центр». Ещё в нескольких крупнейших банках идёт пилотирование.
За последние годы внедрений платформы управления устройствами мы уже отработали техническую часть требований, а вот особенности, связанные с внутренними регламентами каждого банка, часто бывают новые.
В этой статье я расскажу, как это выглядит на практике, с какими задачами мы столкнулись при внедрении и что из нашего опыта пригодится при выборе MDM-системы.
Откуда взялась задача
Банки являются субъектами критической информационной инфраструктуры и должны использовать отечественное ПО в значимых системах. Переход на отечественное ПО идет не первый год, критичные зоны уже давно закрыты, в остальных сферах принятые меры по импортозамещению постепенно реализуются, но на практике зарубежные решения еще используются.
Со сбором биометрии ситуация обстоит иначе — это новый вид деятельности для банков, поэтому регулятор изначально установил конкретные требования к доверенной среде. В октябре 2024 года Банк России выпустил методические рекомендации 18-МР и 19-МР. Вместе с федеральным законом 572-ФЗ они установили: устройства, на которых банк собирает подтверждённую биометрию, должны работать в доверенной среде — на сертифицированной российской ОС. Использовать для этого Android-планшет или iPad нельзя.
Банки стали закупать устройства на доверенной ОС Аврора. Это единственная мобильная ОС в реестре российского ПО с 2016 года, которая регулярно проходит сертификацию российскими регуляторами и имеет сертификаты ФСТЭК (А4/УД4) и ФСБ России (АК3/КС3). Набор инструментов для разработки приложений Аврора SDK также включен в реестр отечественного программного обеспечения.
При этом мало просто купить устройства, ими нужно управлять: настраивать, обновлять, при необходимости блокировать удалённо. Это особенно важно, когда речь идет о тысячах устройств и больше. Для этого нужна развитая MDM-система с подтвержденной эффективностью управления большим парком устройств, которая работает с Авророй и сертифицирована ФСТЭК. Так банки пришли к нам. «Аврора Центр», к слову, в реестре отечественного ПО с 2020 года, регулярно проходит сертификацию российскими регуляторами, соответствует требованиям к техническим условиям (ТУ) и 4 уровню доверия ФСТЭК.
Основной задачей MDM является установка нужных приложений на устройство и их настройка, а остальная часть обращений пользователей довольно бытовая: забыли пароль от устройства, на точке изменился пароль от WiFi, планшет перенесли в другое отделение с другими настройками сети. Без централизованного управления администратору пришлось бы ехать на каждую точку — а точек по стране сотни.
Требования к MDM: когда банк приходит с Android-шаблоном
Работа с банком начинается с технического задания на MDM. И здесь сразу начинается интересное. Администраторы банка привыкли работать с Android и iOS, а ОС Аврора для них — новая территория. Поэтому требования к MDM часто приходят как копия с того, что банк использовал раньше. Среди пунктов, например, проскальзывают ссылки на документацию Google по процедуре ввода Android-устройства в эксплуатацию — с предложением реализовать такой же процесс на Авроре. Или требование поддержать разделение рабочей и личной среды на устройстве — сценарий, актуальный для Samsung Knox, но неприменимый к Авроре, где устройство изначально корпоративное.
Такие пункты мы обсуждаем с банком и объясняем, что именно неприменимо и почему. Это нормальная часть процесса — банковские команды быстро разбираются в различиях, когда видят конкретику.
Другая часть требований универсальная, и «Аврора Центр» закрывает их «из коробки». Белый и чёрный списки приложений, сброс пароля, push-уведомления средствами MDM, скрытая установка приложений без подтверждения со стороны пользователя, полная очистка устройства по команде администратора — всё это работает.
А есть требования, которые выглядят стандартно на бумаге, но на практике оказываются нетривиальными. Они «всплывают» на пилоте, когда MDM-система встречается с конкретной инфраструктурой конкретного банка. Прямо сейчас мы пилотируемся в банке, где в перспективе возможно масштабирование до нескольких тысяч устройств. В рамках пилота используется привязка устройства к конкретному пользователю с помощью авторизации через доменную учётную запись. Из-за особенностей конфигурации LDAP на стороне банка мы получали ошибку привязки, при этом на тестовых стендах это сложно воспроизвести. Это не то, что можно предусмотреть заранее — это видно только при столкновении с реальной инфраструктурой.
Но именно для этого и существует пилот. Пока он идёт, мы успеваем выпустить новый релиз с исправлением — в этом случае мы включили исправление в ближайший релиз сроком в 6 недель разработки, к этому ещё добавляется период сертификации во ФСТЭК около 5 недель. Такие сроки возможны потому, что у нас сертифицированный РБПО процесс безопасной разработки: мы не сертифицируем продукт по новой, а выпускаем обновления в рамках действующего сертификата. Поэтому к моменту, когда банк принимает решение о масштабировании, исправленная версия уже готова и сертифицирована.
Скрипт, которому не дали прав
Развёртывание в контуре банка является самым чувствительным этапом проекта. Банковская инфраструктура устроена жёстче, чем в других отраслях: строгие процедуры, разделение полномочий, согласования на каждом шаге.
Например, «Аврора Центр» при установке на сервер должен выполнить ряд последовательных процедур, чтобы все прошло успешно. Для упрощения этих процедур мы их объединили в один скрипт, который идет поэтапно, проверяет верность выполнения той или иной процедуры, и, если все прошло хорошо, идет дальше. Для части процедур требуются права администратора.
При выполнении пилота в одном из банков развертывание решения не вызвало вопросов, более того, оно не вызывало вопросов при развертывании и в других банках, однако после старта масштабирования подключился отдел, отвечающий за администрирование Linux-систем, и они выдали запрет на развертывание, поскольку скрипту требуются администраторские права.
И здесь мы столкнулись с тем, что подразделение банка, которое отвечает за внедрение системы, понимает нашу аргументацию зачем использовать общий скрипт, но другое подразделение четко следует инструкциям. Обе стороны правы, и нужно было устраивать глубокое погружение в технику для обеих команд.
На этом этапе подключается наш архитектор, который и так на протяжении всего проекта сопровождает внедрение, но здесь мы прошлись глубоко по составу скриптов, показали что выполняется и где действительно нужны админские права.
Худший сценарий после этой встречи выглядел так: администраторы банка вручную выполняют каждую команду из наших скриптов, проверяют результат и только потом переходят к следующему шагу. При первой установке это терпимо. При обновлении это десятки ручных операций с высокой вероятностью ошибки.
Полностью ручной процесс не устроил никого. В итоге нашли компромисс: базу данных банк развернул вручную по своим регламентам, а остальные компоненты «Аврора Центра» развернули нашими скриптами с минимальными модификациями. Параллельно инфраструктурная команда банка фиксирует, какие из операций в скриптах нарушают их внутренние правила, и мы оцениваем, что из этого можно исправить в ближайших релизах, а что решается точечными ручными правками.
Хоть это и не идеальная схема, главное — она рабочая. И главный урок здесь не технический: в банке решение о развёртывании принимает не та команда, которая его пилотировала. Подразделение, отвечающее за инфраструктуру, подключается позже, следует своим регламентам и имеет право вето. Если не заложить время на эту коммуникацию, проект встанет не из-за бага, а из-за процедуры.
Спящий режим как блокер
Параллельно с описанным выше внедрением у нас идет еще один проект, который сейчас на стадии пилота. Устройства управляются, биометрия собирается. Всё готово к масштабированию. Но ИБ банка поставили условие: в MDM-системе должна быть политика настройки спящего режима. Администратор должен иметь возможность задать, через сколько секунд неактивности устройство заблокирует экран.
Логика понятна. Планшет, на котором собираются биометрические данные, не должен оставаться разблокированным, если сотрудник банка отошёл. Нет этой политики — нет гарантии. Нет гарантии — нет масштабирования.
В MDM-системах есть десятки подобных политик. Часть из них — офлайн-сценарии, которые работают, даже если у устройства нет подключения к сети: автоматическая блокировка камеры и микрофона при попадании в определённую геозону, очистка устройства при смене SIM-карты, блокировка при попытке рутования. Каждая из них может стать обязательным условием для ИБ конкретного банка. Пройдя через множество внедрений мы закрыли большую часть из них, но что может стать блокером в этот раз обычно узнаёшь «на последней миле» — когда уже всё работает и команда управления MDM довольна, но в масштабирование не пускают из-за блокеров со стороны ИБ.
Настройка спящего режима — не то, что приходит в голову, когда думаешь о блокерах проектов на несколько тысяч устройств. Но в банках любая политика безопасности, которую ИБ считает обязательной, останавливает всё. В результате доработку запланировали и в роадмапах ОС Аврора, и в «Аврора Центре» и банк получит поддержку этой политики.
API как способ разгрузить администраторов
Планшетов для сбора биометрии — тысячи по всей стране. А администраторов платформы, которые управляют всем парком, — несколько человек. И вот типичная ситуация: сотрудник в отделении забыл пин-код от планшета для сбора биометрии, устройство заблокировано, клиент ждёт. Сотрудник пишет заявку. Администратор в Москве видит её в очереди из двадцати таких же. Пин-код сбрасывается через пять минут — но клиент решил не ждать и ушел.
От нескольких банков пришел запрос: дайте возможность локальным командам выполнять простые операции самостоятельно — сбросить пин-код, заблокировать пропавшее устройство, — не дожидаясь центрального администратора.
Раньше это можно было сделать только через полную консоль с доступом ко всему парку. Давать такой доступ сотням сотрудников на местах — очевидный риск. С появлением API банк может собрать свой упрощённый интерфейс: ограниченный набор операций, только свои устройства, без доступа к остальному парку. Локальная команда решает типовые заявки сама, администратор занимается тем, что действительно требует его внимания.
В перспективе API открывает и другие сценарии автоматизации — вплоть до управления устройствами из чата через интеграцию «Аврора Центра» и ИИ.
Что происходит после развёртывания
История выше — про путь до запуска. Но после подключения устройств MDM-система должна постоянно контролировать парк.
Главное, что спрашивают банки, — контроль целостности доставленного контента. MDM доставляет на устройства приложения, конфигурации. Если кто-то подменил файл после доставки — случайно или намеренно, — система должна это обнаружить и отреагировать. «Аврора Центр» мониторит доставленный контент на неизменность: при обнаружении подмены уведомляет администратора о несоответствии устройства политике и автоматически восстанавливает корректную версию.
Второй частый запрос — офлайн-сценарии. Планшет для сбора биометрии может оказаться без связи: в подвальном отделении, в выездной точке, в зоне плохого покрытия. «Аврора Центр» позволяет настроить автоматические реакции, которые сработают без подключения к серверу: заблокировать устройство при смене SIM-карты, ограничить функции при выходе из геозоны, очистить данные при попытке рутования. Для банков, работающих с биометрическими данными, это очень важные требования по безопасности.
Дальше — конкретика по продукту для тех, кто уже выбирает решение
Я не буду сравнивать нас с конкурентами, поскольку это не цель данной статьи. Вместо этого расскажу, что мы знаем про свой продукт и что из этого важно при выборе MDM для банка.
«Аврора Центр» разрабатывается параллельно с ОС Аврора. Мы поддерживаем все версии ОС, которые выходят, и каждый релиз проходит регрессионное тестирование на нескольких устройствах разных поколений. Это не формальная «поддержка Авроры» — это полноценный цикл проверки. В биометрии это критично: регулятор обновляет требования к сбору данных — выходит новая версия ОС — если MDM её не поддерживает, банк физически не может собирать биометрию по новым правилам.
Стоимость «Аврора Центра» для устройств на ОС Аврора — условная. Она позволяет организации взять ПО на баланс, но фактически банк получает MDM-систему для всего парка устройств на Авроре без затрат на лицензирование.
Помимо Авроры, мы управляем устройствами на Android — с развитым режимом киоска, удалённым доступом к экрану и поддержкой широкой линейки терминалов сбора данных. Крупнейшая инсталляция «Аврора Центра» в скором времени составит 2 млн устройств на Android.
Также мы управляем рабочими ПК и ноутбуками на Linux — с агентской схемой управления и корпоративным маркетом приложений. Для банков, которые переводят рабочие станции с Windows на Linux, это отдельный большой сценарий. При этом наше решение является аналогом MS SCCM при миграции ПК и ноутбуков с Windows на российские дистрибутивы Linux.
Пять вопросов вендору MDM под Аврору
Вот что мы советуем спрашивать у любого вендора, включая нас.
Сколько политик безопасности реализовано для нужной ОС? «Поддерживаем Аврору» может означать что угодно. Попросите список. Есть ли поддержка быстрого ввода устройства в эксплуатацию без захода в режим администратора, передача файлов на устройство, настройка LBS-серверов и управление AGPS, офлайн-сценарии — блокировка при смене SIM-карты, при выходе из геозоны, — удалённый сброс пароля, управление обновлениями ОС. Каждая из этих вещей может стать блокером.
Как быстро вендор реагирует на нестандартные запросы? Доработать продукт может любой вендор — вопрос в том, за какое время от запроса до сертифицированного релиза. Попросите конкретные примеры из реальных проектов, а не обещания из презентаций.
Как защищён агент MDM на устройстве, есть ли возможность принудительно перевести устройство из режима администратора в режим пользователя?
Как выглядит пилот? Для ориентира: в нашем случае его можно запустить за один день на обычной виртуальной машине, и такая конфигурация держит до двух–трёх тысяч устройств. Но пилот еще не внедрение. Важно на этапе пилота проверить ключевые сценарии именно на ваших устройствах: одна и та же политика может работать по-разному из-за различий в прошивках производителей.
Что именно сертифицировано и как? Ответ «есть сертификат ФСТЭК» — лишь начало разговора. Без сертифицированного процесса безопасной разработки каждое обновление продукта потребует полной пересертификации, а это месяцы ожидания. С таким процессом вендор выпускает обновления в рамках действующего сертификата ФСТЭК, и запрос на доработку с пилота попадает в сертифицированный релиз за пару месяцев, а не за полгода–год.
За 7 лет разработки «Аврора Центра» мы прошли десятки внедрений в крупнейших компаниях и банках страны. Каждое — это новые требования ИБ, нестандартные конфигурации, особенности, которые не воспроизводятся на тестовых стендах. Всё это делает продукт сильнее. Поэтому каждый новый банк получает решение, в котором уже учтён опыт предыдущих.
