Как выбрать мобильное решение для корпоративной инфраструктуры

Выбор мобильного решения для крупной компании начинается с фиксации задач, парка устройств, требований безопасности и интеграций. Платформа должна управлять теми устройствами, приложениями и данными, которые уже используются, без перестройки процессов под ее ограничения. Сначала компания определяет периметр и критерии успеха, затем проводит аудит, сравнивает модели MDM, EMM и UEM, проверяет безопасность и проводит пилот на ограниченной группе пользователей с тестовыми или обезличенными данными. Такой порядок помогает отсеять решения, которые подходят по функциям, но не встраиваются в действующую инфраструктуру — систему управления идентификацией (IdM), систему мониторинга событий информационной безопасности (SIEM), систему управления заявками.

Мобильное решение — это платформа для управления корпоративными устройствами, приложениями, доступом и данными сотрудников. Оно может охватывать смартфоны, планшеты, защищенные мобильные устройства, ноутбуки и рабочие станции — в зависимости от выбранной модели управления.

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

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

Мобильное решение работает как инструмент управления только тогда, когда устройство доверенное, доступ управляется централизованно, а корпоративные данные не попадают в личные облачные хранилища.

Требования полезно разделить на пять групп. Каждая группа должна содержать проверяемые условия.

От автоматизации жизненного цикла пользователя зависит скорость выдачи доступа. Если IdM создает учетную запись и назначает роль, мобильное решение должно применить соответствующую политику к устройству без ручной работы администратора.

Условные политики связывают доступ к данным с состоянием устройства. Устройство без шифрования, актуального PIN-кода или требуемой версии ОС не должно автоматически получать тот же доступ, что и управляемое устройство, прошедшее проверку.

Чем больше ручных операций, тем выше нагрузка на ИТ-службу и стоимость эксплуатации. Если подключение одного сотрудника требует нескольких согласований по почте и ручного ведения списка, ограничением при масштабировании станет не стоимость лицензий, а доступное время ИТ-службы.

Число сценариев и состав шагов зависят от размера компании и количества подразделений.

Приоритет требований определяют по риску. Отзыв доступа при увольнении важнее поддержки почты: поддержка почты — это функция, а несвоевременный отзыв доступа — управляемый риск с понятными последствиями.

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

Инвентаризация устройств — только начало. Необходимо проверить, кто владеет устройством, где оно используется, как подключается к сети и какие данные хранит. Смартфон руководителя, планшет курьера и терминал на складе могут требовать разных политик, хотя формально все они «мобильные».

Корпоративные приложения следует включать в аудит даже тогда, когда они не планируются для установки на устройства в первой волне. Зависимость может обнаружиться позже: например, мобильное приложение требует сертификат, доступ к внутреннему API или отдельный сетевой маршрут.

При сверке списка устройств с сервис-деском и закупками могут обнаружиться тестовые планшеты, терминалы подрядчика и личные устройства топ-менеджеров. Такие исключения нужно выявить до настройки первой политики доступа, иначе они могут нарушить ее работу.

При аудите отделяйте текущую архитектуру от целевой: фиксируйте фактически работающие интеграции, учетные записи и неподдерживаемые устройства. На схеме все уже интегрировано, пользователи заведены, а неподдерживаемые устройства будто исчезли. В реальной корпоративной инфраструктуре они никуда не деваются.

При аудите проверьте неформальные сценарии работы: пересылку файлов в мессенджерах, общие учетные записи на складе и ручную установку приложений. Эти сценарии описывают наравне с официальными, иначе выбранное решение окажется рассчитано на процессы, которых в реальности нет.

Результаты инвентаризации используют для выбора модели управления, состава интеграций и политик безопасности.

Выбор между MDM, EMM и UEM зависит от объекта управления: только устройством, устройством вместе с корпоративными приложениями и данными или всем парком конечных устройств. Эти модели пересекаются по функциям, но не являются взаимозаменяемыми.

MDM (Mobile Device Management) — это управление мобильными устройствами. MDM помогает регистрировать устройства, применять политики, настраивать параметры, контролировать соответствие требованиям и выполнять удаленные действия.

EMM (Enterprise Mobility Management) — это управление корпоративной мобильностью. EMM охватывает не только устройства, но и корпоративные приложения, данные, идентификацию пользователей и правила доступа в мобильных сценариях.

UEM (Unified Endpoint Management) — это унифицированное управление конечными устройствами. UEM объединяет управление мобильными устройствами, ноутбуками, рабочими станциями и другими конечными точками в единой модели администрирования.

MDM работает от устройства к политике, EMM — от мобильного рабочего сценария к приложению и данным, UEM — от всего парка конечных устройств к единому контролю. Модели различаются границами проекта, а не уровнем зрелости.

MDM уместен, когда основной риск связан с конфигурацией устройства и его потерей. EMM нужен, если ключевой вопрос — безопасная работа с корпоративными приложениями и данными на мобильном устройстве. UEM оправдан, когда компания хочет унифицировать управление несколькими классами конечных устройств.

Если UEM выбирают только для небольшого парка планшетов, а ноутбуки остаются в отдельной системе, часть возможностей платформы может не использоваться.

Безопасность мобильного решения следует проверять по управляемым политикам, защите данных, удаленным действиям, журналированию и совместимости с используемыми российскими операционными системами и средствами защиты. Вопрос в том, можно ли применить удаленное действие к нужному типу устройства, подтвердить его выполнение и сохранить след в журнале.

Минимальный набор включает семь проверок:

Риск утечки снижается, когда доступ зависит от проверенного состояния устройства. Если устройство не соответствует заданным условиям, платформа ограничивает доступ по заранее утвержденному сценарию, без участия оператора.

Расследование опирается на связанные между собой события в журналах. Администратор должен сопоставить регистрацию устройства, выдачу доступа, изменение политики и удаленное действие. Без такой цепочки восстановить картину инцидента не удастся.

Для российских компаний важно проверять совместимость мобильного решения с используемыми операционными системами и средствами защиты. В перечень входят Astra Linux, РЕД ОС, Альт, а также мобильная Аврора.

Для мониторинга событий компания может использовать MaxPatrol SIEM, KUMA, RuSIEM, KOMRAD Enterprise SIEM, Ankey SIEM NG. При замене Splunk, IBM QRadar или ArcSight сравните поддержку нужных источников событий, правила корреляции, отчетность и требования к эксплуатации. На этапе пилотного проекта стоит подтвердить формат событий, полноту полей и возможность корреляции именно для мобильных сценариев.

Для управления идентификацией и доступом применяются Avanpost, Platform V IDM, RooX UIDM. Они заменяют Microsoft Identity Manager, SailPoint, Oracle Identity Governance. Мобильное решение должно поддерживать согласованный сценарий: создание учетной записи, назначение роли, выдачу доступа и его отзыв.

В средствах антивирусной защиты и обнаружения угроз на конечных устройствах (EDR) могут использоваться Kaspersky и Dr.Web. Поставщику мобильного решения следует задать прямой вопрос: какие сигналы состояния устройства доступны для политик и какие события передаются в существующие средства ИБ.

Списки продуктов не исчерпывающие: конкретный набор зависит от того, что уже используется в компании и какие требования заданы внутренними стандартами.

В бюджете пилотного проекта заложите расходы на ИБ и соблюдение требований; сумму определяют после диагностики состава интеграций, требований к журналированию и работ по настройке политик.

Попросите показать регистрацию устройства, применение политики, выдачу доступа через IdM/IAM, отправку события в SIEM и удаленное удаление корпоративных данных в пилотном проекте на тестовых или обезличенных данных, без доступа к реальным персональным данным. Если сценарий нельзя воспроизвести на пилотном проекте, его нельзя считать подтвержденной возможностью.

Пилотный проект нужен, чтобы проверить пригодность мобильного решения на ограниченной группе пользователей и в реальных корпоративных сценариях до масштабирования. Успешный пилотный проект подтверждает выполнение заранее согласованных критериев по безопасности, интеграции, стабильности и трудозатратам. Число включенных функций само по себе результатом не является.

Размер пилотной группы определяют после аудита. В нее входят представители ИТ, ИБ, сервис-деска и пользователи с разными типами устройств, а также хотя бы один нестандартный сценарий работы. Без этого проверка не покажет, как решение ведет себя за пределами типовой конфигурации.

Пилотный проект стоит проводить ориентировочно 4–8 недель, срок зависит от числа сценариев и состава интеграций. Этого периода обычно хватает, чтобы проверить регистрацию, применение политик, обновление приложений, отзыв доступа, передачу событий и работу службы поддержки.

Эффективность мобильного решения оценивают через измеримые результаты пилотного проекта: скорость подключения пользователя, долю устройств с примененными политиками, число обращений в сервис-деск, стабильность интеграций и время отзыва доступа. Метрики утверждают до начала пилотного проекта.

Пилотный проект переводит выбор из области экспертных оценок в проверяемое решение. Он показывает, как мобильное решение работает в реальной инфраструктуре: с существующими ролями, неидеальными устройствами, работающими системами ИБ и пользователями, у которых мало времени на освоение новых инструментов.

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

Критичнее всего соответствие мобильного решения реальным бизнес-сценариям, требованиям безопасности и корпоративным интеграциям. Набор функций сам по себе недостаточен для выбора: нужно подтвердить совместимость с устройствами, корпоративными системами и политиками безопасности.

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

EMM выбирают, когда помимо устройств требуется управлять корпоративными приложениями, данными и доступом сотрудников в мобильных сценариях.

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

В первую очередь проверяют IdM, SSO, корпоративную почту, VPN, SIEM, сервис-деск и критичные корпоративные приложения.