BYOD по уму: полевой гайд по защите личных телефонов с помощью Intune
Если вы ведёте небольшую компанию на Microsoft 365 и хотите, чтобы рабочая почта была у каждого на телефоне, вы упираетесь в вопрос, который выглядит простым, но таковым не является: как защитить корпоративные данные на устройстве, которое вам не принадлежит?
Ответ — стек хорошо определённых инструментов с понятными компромиссами. При правильном использовании они дают сильную защиту корпоративных данных и полную приватность личных данных на одном и том же телефоне. Это гайд по концепциям, компромиссам, конкретному сетапу, который мы использовали, — и по проблемам, на которые мы напоролись по пути, потому что их было несколько.
Зачем вообще заморачиваться — факты
Несколько простых причин, почему это стоит сделать как следует:
- Телефоны уже личные. Маленькая компания не раздаёт корпоративное железо. Люди читают почту и Teams на устройстве в своём кармане, так что это устройство уже в зоне риска — управляете вы им или нет.
- Неуправляемый доступ — реальный канал утечки данных. Если ничего не делать, корпоративная почта и файлы лежат в приложениях без требования шифрования, без PIN-кода, без контроля над тем, куда копируются данные, и без возможности удалить их, если телефон потерян или человек уволился.
- Мы храним данные, которые имеют значение. Мы управляем платформой со средствами игроков и персональными данными, поэтому держим собственный внутренний доступ на заданной планке (контроли в духе CIS/SOC 2), а не «как получится».
- Приватность — это требование, а не приятный бонус. Что бы мы ни делали, это не должно расширять доступ ИТ к чьим-либо личным приложениям, фотографиям, сообщениям или геолокации.
Цель была конкретной: каждый путь к корпоративным данным на телефоне должен соответствовать заданному стандарту безопасности — без управления личным устройством вокруг него.
Задача, сформулированная точно
Два требования действуют одновременно:
- Корпоративные данные нужно защищать — шифрование, контроль доступа и возможность удаления, если телефон потерян или человек ушёл.
- Личный телефон принадлежит человеку — фотографии, переписки, приложения и геолокация остаются приватными и вне досягаемости ИТ.
Управление мобильными устройствами — это инструментарий, созданный, чтобы выполнить оба требования сразу. Остальная часть гайда — это набор инструментов и то, как его части складываются вместе.
Инструментарий: три способа управлять телефоном
Microsoft Intune предлагает спектр, а не переключатель:
1. MAM — Mobile Application Management управляет приложением. Вы защищаете рабочие приложения и не трогаете остальной телефон. Без регистрации устройства.
2. MDM — Mobile Device Management управляет устройством, в двух разных вариантах:
- Рабочий профиль / User Enrollment — отдельный зашифрованный рабочий контейнер на личном телефоне. ИТ управляет только контейнером.
- Полностью управляемое устройство — ИТ управляет всем устройством. Подходит для корпоративного железа, но не для личных телефонов.
Большинство команд рассматривают только вариант 1 и «полностью управляемый» край варианта 2, отвергают оба и останавливаются на чём-то расхлябанном. Полезный вариант — тот, что посередине.
Концепция 1: MAM / защита приложений
Политики App Protection в Intune — это слой MAM. Политика, применённая к приложению вроде Outlook:
- Шифрует корпоративные данные внутри приложения.
- Требует PIN-код или биометрию, чтобы его открыть.
- Блокирует
copy,Save AsиOpen inиз корпоративных данных в личные приложения. - Позволяет выборочную очистку только корпоративных данных, не трогая личные.
Ничто из этого не требует регистрации устройства. Телефон остаётся полностью личным; управляются только рабочие приложения. Для многих BYOD-сценариев этого достаточно — и это была наша отправная точка.
Концепция 2: соответствие требованиям подразумевает регистрацию
Концепция, которая связывает всё воедино, — соответствие устройства требованиям.
Устройство «соответствует требованиям», когда оно зарегистрировано в управлении и удовлетворяет заданным вами правилам «здоровья»: включено шифрование диска, настроена блокировка экрана, ОС обновлена, нет root-доступа и так далее. Соответствие — это состояние, о котором устройство отчитывается, а система управления его проверяет.
Ключевой момент: нельзя оценить соответствие требованиям у устройства, которое никогда не было зарегистрировано. Предпосылка MAM — отсутствие регистрации, поэтому телефон только с MAM защищён на уровне приложений, но «соответствующим» не станет никогда — там просто нечего проверять. Require compliant device и «без регистрации» взаимоисключающие по самой конструкции.
Если нужна гарантия на уровне устройства, устройство должно быть где-то зарегистрировано. А это указывает на средний вариант.
Концепция 3: рабочий профиль
На Android средний вариант — это рабочий профиль (через Android Enterprise). На iOS эквивалент — User Enrollment. Модель такая:
Рабочий профиль — это отдельный зашифрованный контейнер на личном телефоне. ИТ управляет только тем, что внутри этого контейнера. Всё за его пределами — личные приложения, фотографии, сообщения, аккаунты — находится в пространстве, которое ИТ не может ни видеть, ни трогать, ни стирать.
Рабочие приложения появляются отдельным набором со значком-бейджем рядом с личным домашним экраном, изолированные в контейнере. Устройство становится зарегистрированным и соответствующим требованиям — в границах рабочего контейнера. Личные данные остаются приватными. «Регистрация» здесь означает, что компания управляет контейнером, а не устройством.
Концепция 4: условный доступ
Условный доступ (Conditional Access, CA) в Microsoft Entra — это шлюз доступа. Прежде чем разрешить вход, он проверяет заданные вами условия. Здесь важны два элемента управления предоставлением доступа:
Require app protection— доступ разрешён, если к приложению применена ваша MAM-политика. Работает в паре с MAM.Require compliant device— доступ разрешён, если устройство зарегистрировано и «здорово». Работает в паре с MDM / рабочим профилем.
CA — это место, где вы принуждаете к выбранной модели. Меняете условие предоставления доступа — меняете планку.
Путь, который мы прошли
Когда модель понятна, сборка проста:
- Начните с MAM. App Protection на рабочих приложениях плюс правило CA, требующее защиты приложений. Минимальное вмешательство.
- Решите, какая гарантия вам нужна. Если «приложение защищено» достаточно — остановитесь здесь, это валидный вариант. Мы хотели гарантию на уровне устройства.
- Включите Android Enterprise, привязав Managed Google Play к тенанту. Одноразовое подключение, которое открывает регистрацию с рабочим профилем.
- Зарегистрируйте телефон как личное устройство с рабочим профилем. Создаётся зашифрованное рабочее пространство с бейджем, личная сторона не затрагивается, и устройство отчитывается как
compliantв течение пары минут. - Доставьте рабочие приложения из Managed Google Play — одобрите Outlook, Teams, Edge и приложения Office, назначьте их, и они установятся в контейнер.
- Переключите условие CA с
Require app protectionнаRequire compliant device— та же планка, что и для ноутбуков.
Это чистая версия. А вот что происходило на самом деле.
Проблемы, на которые мы напоролись, и как мы их решили
1. Каждое управляемое приложение блокировалось с «device is not compliant». Наша MAM-политика App Protection несла правило условного запуска appActionIfDeviceComplianceRequired со значением block. Когда мы попытались его ослабить, Intune принимал только block или wipe — API отклоняет null и warn. В сочетании с концепцией 2 это замкнутый круг: политика требует соответствующее устройство, телефон только с MAM никогда не регистрируется, значит никогда не соответствует, значит каждое приложение блокируется, а Company Portal продолжает попытки регистрации. Всё это принуждается на стороне клиента, поэтому никогда не всплывает как сбой входа в Entra — деталь, которая сильно осложняет диагностику. Решение: перестать бороться со шлюзом. Зарегистрировать устройство (рабочий профиль), чтобы оно реально могло соответствовать требованиям, а затем уйти с MAM на этой платформе (проблема 5).
2. Company Portal: «does not meet requirements to enroll». До подключения Android Enterprise пути регистрации с рабочим профилем просто не существовало, поэтому попытке регистрации некуда было приземлиться. Решение: подключить Managed Google Play, чтобы привязать Android Enterprise. Именно это единственное подключение делает регистрацию с рабочим профилем доступной.
3. Конфликт аккаунтов Google — шаг, который стоил больше всего времени. Managed Google Play привязывается через аккаунт Google, который становится владельцем предприятия. Наша рабочая почта была уже привязана к личному аккаунту Google, а Google считает это конфликтующим аккаунтом — он не даст использовать тот же адрес для создания организационного/Workspace-администратора. Это легко упустить, и это стопорит вообще всё. Решение: сначала разрешить конфликт. Либо освободить адрес через процедуру Google для конфликтующих аккаунтов (переименовать или закрыть существующий личный аккаунт Google на этом адресе), либо использовать выделенный аккаунт без какой-либо предыдущей регистрации в Google. Заложите на это реальное время — это самая вероятная вещь, которая застопорит маленькую команду в первый же день, и к Intune она не имеет никакого отношения.
4. После регистрации рабочий профиль оказался пустым. Приложения рабочего профиля не переносятся с личной стороны. В свежесозданном контейнере нет ничего. Решение: одобрить приложения в Managed Google Play и назначить их своей группе как Required (автоустановка) или Available (самостоятельная установка из магазина рабочего профиля). После этого они появляются в контейнере как приложения с бейджем.
5. Всё ещё «not compliant» — даже когда устройство уже соответствовало. Устройство теперь отчитывалось как compliant, но Outlook по-прежнему отказывал. Причина: MAM-политика App Protection всё ещё была применена к тому же приложению, которое теперь управлялось через MDM в рабочем профиле, и её проверка соответствия устройства конфликтовала с регистрацией. MAM и MDM не хотят совместно управлять одним и тем же приложением. Решение: одна модель на платформу. Мы сняли назначение политики App Protection для Android и переключили условие условного доступа для Android с Require app protection на Require compliant device. Устройство с рабочим профилем удовлетворяет его напрямую; MAM-шлюза, которому можно было бы конфликтовать, больше нет.
6. Наша собственная политика заблокировала наш админский инструментарий — AADSTS530033. При автоматизации изменений в Intune админский вход был отклонён: условный доступ отверг вход по device code, потому что такой токен не привязан к соответствующему устройству. Решение: выполнять привилегированную работу с уже соответствующего требованиям устройства, чтобы токен был привязан к устройству — например, интерактивный Connect-MgGraph с управляемой машины. Вывод, кстати, позитивный: если ваш условный доступ способен остановить вход по device code, значит он настроен правильно.
О разработке с ИИ
Мы строим в открытую и строим с ИИ, в том числе в операционке. ИИ отлично умеет быстро прогонять конфигурацию через множество веток. Мы соединяем это с одним правилом: ИИ предлагает, человек решает — особенно во всём, что касается безопасности. Такое разделение труда позволяет маленькой команде работать в темпе большой.
Ментальные модели, которые стоит запомнить
- MAM управляет приложением; MDM управляет устройством. Выбирайте исходя из гарантии, которая вам нужна.
- Соответствие требованиям подразумевает регистрацию. Нельзя проверить устройство, которое никогда не было зарегистрировано, поэтому
Require compliant deviceи «без регистрации» несовместимы. - Рабочий профиль — средний вариант. Он управляет контейнером, а не устройством — соответствие устройства и личная приватность одновременно.
- Одна модель на приложение. Не оставляйте MAM-политику на приложении, которое перевели на MDM; выберите одну полосу и держитесь её.
- Условный доступ задаёт планку. Выберите условие, соответствующее вашей модели, и дайте ему работать.
Мы вложили столько внимания в несколько рабочих почтовых ящиков, потому что та же дисциплина, что защищает наш мобильный доступ, защищает и ваш аккаунт, ваши средства и ваши данные на платформе. Безопасность — это привычка, которая пронизывает всю внутреннюю работу, а не только те части, что видят клиенты.
Увидимся за столами.
The Salty Korean
Основатель Salty Poker Network. Пишет о техасском покере, создании платформ и будущем онлайн-покера. Подробнее на The Salty Korean.