Модели корпоративных устройств: BYOD, COPE, COBO и COSU

Модель корпоративных устройств выбирают до пилота MDM/UEM, потому что она задаёт не только ответ на вопрос «чей телефон». От неё зависят границы управления устройством, видимость данных для администратора, допустимые команды, управление приложениями, выпуск сертификатов, сетевой доступ, self-service и действия при потере, увольнении или инциденте.

BYOD обычно подходит для личных устройств и рабочих сервисов. COPE — для корпоративного устройства с разрешённым личным использованием. COBO — для строгого корпоративного контроля без личного сценария. COSU — для терминала, киоска, складского устройства или другой управляемой рабочей функции.

Эта страница нужна, когда компания проектирует мобильный или кроссплатформенный корпоративный доступ и должна заранее договориться, какие устройства можно подключать, чем управляет ИТ-команда, какие данные остаются личными и какие требования попадут в MDM/UEM, IAM, PKI, VPN и поддержку.

Модель устройств особенно важна перед пилотом MDM/UEM. Без неё обсуждение быстро превращается в спор о функциях: почта, браузер, файлы, VPN, сертификаты, удаление данных, установка приложений. На самом деле в этот момент ещё не согласована базовая граница контроля.

BYOD, COPE, COBO и COSU — это не просто словарь MDM/UEM. Это способ заранее определить, какую роль устройство играет в корпоративном доступе: личный инструмент сотрудника, корпоративный смартфон с личным использованием, строго рабочий актив или устройство под одну функцию.

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

Одна компания может использовать несколько моделей одновременно: BYOD для почты и согласований, COPE для руководителей и выездных сотрудников, COBO для ролей с повышенными требованиями безопасности, COSU для склада, логистики, точек обслуживания и общих устройств.

BYOD: личное устройство с рабочей зоной

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

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

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

COPE: корпоративное устройство с личным использованием

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

Для COPE нужна отдельная политика личного использования: что можно хранить, какие приложения допустимы, что происходит при увольнении, потере устройства, нарушении политики или передаче устройства другому сотруднику. Модель часто подходит руководителям, менеджерам, выездным сотрудникам и ролям с постоянным корпоративным доступом.

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

COBO: корпоративное устройство только для работы

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

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

COBO уместна для ИБ-чувствительных ролей, сервисных подразделений, массовых корпоративных поставок и сценариев, где личное использование создаёт лишний риск или мешает расследованию инцидентов.

COSU: устройство под рабочую функцию

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

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

Если устройство обслуживает процесс, а не личный рабочий день сотрудника, его лучше проектировать как COSU, а не как ещё один смартфон в MDM.

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

Схему удобно использовать до выбора продукта MDM/UEM, чтобы не спорить о функциях раньше, чем согласована граница контроля.

1. Устройство личное? Если да, сначала проверяют BYOD: достаточно ли рабочего профиля, управляемых приложений, сертификатов и selective wipe без управления всей личной зоной.
2. Устройство покупает компания, но личное использование нужно сохранить? Тогда базовый кандидат — COPE: контроль сильнее, чем в BYOD, но правила приватности и личного использования должны быть описаны заранее.
3. Личный сценарий недопустим? Тогда выбирают COBO: корпоративное устройство, корпоративные аккаунты, строгие политики, управляемые приложения и предсказуемый аудит.
4. Устройство обслуживает процесс, место или смену, а не конкретного сотрудника? Тогда это COSU: терминал, киоск, складское устройство, логистический маршрут или общий рабочий экран.
5. Платформа поддерживает нужную глубину управления? После выбора модели проверяют Android, iOS/iPadOS, macOS и корпоративную инфраструктуру: одинаковая модель может давать разную глубину команд, данных и сетевого доступа.

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

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

• Граница приватности. На личных устройствах нельзя вести себя так же, как на полностью корпоративных. Для BYOD заранее фиксируют, что видит администратор, какие данные не собираются и что удаляется при отключении.
• Глубина контроля. Если нужны полный контроль ОС, массовые команды, строгая конфигурация, тихая установка приложений и высокий уровень расследования инцидентов, BYOD обычно не подходит.
• Тип защищаемых данных. Чем выше чувствительность данных и операций, тем важнее управляемый статус устройства, сертификаты, контроль соответствия политикам и предсказуемый доступ к корпоративному контуру.
• Эксплуатация и поддержка. COPE, COBO и COSU дают больше контроля, но требуют закупки, учёта, выдачи, замены, поддержки, возврата и вывода устройств из эксплуатации.
• Роли пользователей. Для офисных сотрудников, руководителей, выездных ролей, сервисных подразделений и сменных операторов могут потребоваться разные модели.

Ни одна модель не является универсально лучшей. Хорошее решение обычно выглядит как матрица ролей и сценариев: где разрешён BYOD, где нужен COPE, где обязательна COBO-модель, а где устройство должно проектироваться как COSU.

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

• Политики безопасности. Требования к паролю, шифрованию, блокировке, версии ОС, запрету функций и состоянию устройства.
• Данные. Какие сведения об устройстве собираются, что видно администратору и где проходит граница личной информации.
• Приложения. Установка, обновление, удаление, управляемые настройки, разрешённые магазины и запрет обмена между рабочей и личной областью.
• Сертификаты. Выпуск, доставка, отзыв и связь с Wi-Fi, VPN, почтой, proxy и внутренними сервисами.
• Сетевой доступ. Общий VPN, per-app VPN, proxy, доступ только из доверенного состояния или запрет доступа с неподходящих устройств.
• Self-service. Какие операции пользователь может выполнить сам: подключить устройство, посмотреть статус, заблокировать, удалить рабочие данные или запросить помощь.
• Инциденты. Что происходит при потере, увольнении, нарушении политики, компрометации, смене владельца или выводе устройства из эксплуатации.
• Платформы. Android, iOS/iPadOS, macOS и другие платформы дают разную глубину управления, даже если бизнес называет модель одинаково.

Поэтому требования к MDM/UEM должны описывать не только список функций, но и допустимую глубину управления для каждой модели устройства.

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

Одинаковая модель на бумаге не означает одинаковую глубину управления на разных платформах. То, что просто реализуется на Android через рабочий профиль, fully managed или dedicated device, может требовать другого подхода на iOS/iPadOS или зависеть от корпоративной инфраструктуры Apple, способа регистрации устройства и режима supervision.

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

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

Эти страницы раскрывают соседние вопросы, которые обычно появляются после выбора модели устройства.

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