Эта страница изначально написана на английском. Переводы сделаны с помощью ИИ и всё ещё дорабатываются — сообщите нам если что-то звучит неправильно.
BYOD по уму: полевой гайд по защите личных телефонов с помощью Intune
tech

BYOD по уму: полевой гайд по защите личных телефонов с помощью Intune

July 20, 2026 Автор: The Salty Korean 9 мин чтения

Если вы ведёте небольшую компанию на 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 — это место, где вы принуждаете к выбранной модели. Меняете условие предоставления доступа — меняете планку.

Путь, который мы прошли

Когда модель понятна, сборка проста:

  1. Начните с MAM. App Protection на рабочих приложениях плюс правило CA, требующее защиты приложений. Минимальное вмешательство.
  2. Решите, какая гарантия вам нужна. Если «приложение защищено» достаточно — остановитесь здесь, это валидный вариант. Мы хотели гарантию на уровне устройства.
  3. Включите Android Enterprise, привязав Managed Google Play к тенанту. Одноразовое подключение, которое открывает регистрацию с рабочим профилем.
  4. Зарегистрируйте телефон как личное устройство с рабочим профилем. Создаётся зашифрованное рабочее пространство с бейджем, личная сторона не затрагивается, и устройство отчитывается как compliant в течение пары минут.
  5. Доставьте рабочие приложения из Managed Google Play — одобрите Outlook, Teams, Edge и приложения Office, назначьте их, и они установятся в контейнер.
  6. Переключите условие 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, значит он настроен правильно.

О разработке с ИИ

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

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

  1. MAM управляет приложением; MDM управляет устройством. Выбирайте исходя из гарантии, которая вам нужна.
  2. Соответствие требованиям подразумевает регистрацию. Нельзя проверить устройство, которое никогда не было зарегистрировано, поэтому Require compliant device и «без регистрации» несовместимы.
  3. Рабочий профиль — средний вариант. Он управляет контейнером, а не устройством — соответствие устройства и личная приватность одновременно.
  4. Одна модель на приложение. Не оставляйте MAM-политику на приложении, которое перевели на MDM; выберите одну полосу и держитесь её.
  5. Условный доступ задаёт планку. Выберите условие, соответствующее вашей модели, и дайте ему работать.

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

Увидимся за столами.

Теги: security mobile intune mdm mam android-enterprise conditional-access byod building-in-public poker-tech
Поделиться:

The Salty Korean

Основатель Salty Poker Network. Пишет о техасском покере, создании платформ и будущем онлайн-покера. Подробнее на The Salty Korean.