把 BYOD 做对:用 Intune 保护个人手机的实战指南

如果你用 Microsoft 365 运营一家小公司,又想让每个人的手机都能收工作邮件,你就会撞上一个看起来简单、实际并不简单的问题:如何在一台不属于你的设备上保护公司数据?

答案是一整套定义清晰、各有取舍的工具。用对了,它们能在同一部手机上同时做到:公司数据得到强保护,个人数据享有完全隐私。这篇文章讲概念、讲取舍、讲我们实际采用的配置 — 也讲我们一路踩过的坑,因为坑还真不少。

为什么值得做 — 摆事实

几个朴素的理由,说明这件事值得认真做:

• 手机本来就是个人的。小公司不会给员工配发公司硬件。大家就是用口袋里那台设备查邮件、上 Teams,所以不管你管不管,那台设备已经在射程之内了。
• 不受管理的访问是一条真实的数据通道。放任不管的话,公司邮件和文件就躺在没有加密要求、没有 PIN、无法控制数据被复制到哪里的应用里,手机丢了或者人离职了,也没有任何办法把数据收回来。
• 我们手里的数据事关重大。我们运营的平台涉及玩家资金和个人信息,所以我们对自己内部访问的要求是一条明确的基准线(CIS/SOC 2 风格的控制),而不是“尽力而为”。
• 隐私是硬性要求,不是加分项。无论我们怎么做,都不能让 IT 的手伸进任何人的个人应用、照片、消息或位置信息。

目标很具体:手机上通往公司数据的每一条路径,都必须达到一个明确的安全标准,同时不去管理它周围的那台个人设备。

把问题说精确

两个要求同时成立:

• 公司数据需要保护 — 加密、访问受控,并且在手机丢失或人员离职时可以移除。
• 个人手机属于个人 — 照片、聊天、应用和位置保持私密,处在 IT 触及范围之外。

移动设备管理正是为了同时满足这两条而生的工具。本文剩下的部分,就是这个工具箱,以及各个零件如何拼在一起。

工具箱:管理一部手机的三种方式

Microsoft Intune 提供的是一个光谱,而不是一个开关:

1. MAM — 移动应用管理(Mobile Application Management)管理的是应用。你保护工作应用,手机的其余部分完全不碰。无需注册设备。

2. MDM — 移动设备管理(Mobile Device Management)管理的是设备,又分两种截然不同的形态:

• 工作资料 / 用户注册 — 个人手机上一个独立、加密的工作容器。IT 只管理这个容器。
• 完全托管 — IT 管理整台设备。适合公司自有硬件,不适合个人手机。

大多数团队只考虑选项 1 和选项 2 里“完全托管”的那一端,两个都否掉,然后凑合用一个松散的方案。真正有用的,是中间那个选项。

概念 1:MAM / 应用保护

Intune 的应用保护策略就是 MAM 这一层。应用到 Outlook 这类应用上的策略会:

• 加密应用内的公司数据。
• 要求 PIN 或生物识别才能打开。
• 阻止把公司数据 copy、Save As、Open in 到个人应用。
• 允许选择性擦除,只清除公司数据,个人数据分毫不动。

这些都不需要注册设备。手机完全保持个人属性;被管理的只有工作应用。对很多 BYOD 场景来说,这已经够用了 — 我们也是从这里起步的。

概念 2:合规意味着注册

把一切串起来的概念是设备合规。

一台设备要在两件事同时成立时才算“合规”:它已注册到管理之中,并且满足你定义的健康规则 — 磁盘加密开启、设置了锁屏、系统打了补丁、没有被 root,等等。合规是一种由设备上报、由管理端验证的状态。

关键在于:你无法在一台从未注册的设备上评估合规性。MAM 的前提就是不注册,所以只有 MAM 的手机虽然在应用层受保护,却永远不可能“合规” — 根本没有已注册的东西可查。Require compliant device 和“不注册”在设计上就是互斥的。

如果你想要设备级的保证,设备就必须注册进某个东西。这就指向了中间那个选项。

概念 3:工作资料

在 Android 上,中间选项是工作资料(通过 Android Enterprise)。在 iOS 上,对应的是用户注册(User Enrollment)。模型是这样的:

工作资料是个人手机上一个独立、加密的容器。IT 只管理容器内部的东西。容器之外的一切 — 个人应用、照片、消息、账号 — 都处在一个 IT 看不到、碰不着、也擦不掉的空间里。

工作应用以一组带徽章的图标出现在个人主屏旁边,沙箱隔离在容器里。设备变成已注册且合规,但范围只限于工作容器。个人数据保持私密。这里的“注册”意味着公司管理的是一个容器,而不是整台设备。

概念 4:条件访问

Microsoft Entra 里的条件访问(Conditional Access,CA)是访问的闸门。在放行一次登录之前,它会检查你定义的条件。这里相关的授权控制有两个:

• Require app protection — 应用套上了你的 MAM 策略才放行。与 MAM 配对。
• Require compliant device — 设备已注册且健康才放行。与 MDM / 工作资料配对。

CA 就是你落地所选模型的地方。改一下授权控制,访问的门槛就跟着变。

我们走的路

模型理清之后,搭建就很直接了:

1. 从 MAM 开始。给工作应用套上应用保护,再加一条要求应用保护的 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. 所有受管应用都被“设备不合规”挡住。我们的 MAM 应用保护策略带着一条条件启动规则 appActionIfDeviceComplianceRequired,值设为 block。想放宽时,Intune 只接受 block 或 wipe — API 直接拒绝 null 和 warn。结合概念 2,这是一个死循环:策略要求设备合规,而只有 MAM 的手机永远不会注册,所以永远不合规,于是所有应用都被挡住,Company Portal 还在不停地拉你去注册。这条规则是在客户端强制执行的,所以它永远不会以 Entra 登录失败的形式出现 — 这个细节让它格外难排查。

解决:别跟闸门较劲。把设备注册进来(工作资料),让它真的能合规,然后在这个平台上放弃 MAM(见问题 5)。

2. Company Portal:“不满足注册要求”。在连接 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. 还是“不合规” — 哪怕设备已经合规了。设备此时已经上报 compliant,Outlook 却仍然拒绝。原因是:MAM 应用保护策略仍然套在那个已经在工作资料里被 MDM 管理的应用上,它的设备合规闸门和注册状态起了冲突。MAM 和 MDM 不愿意共管同一个应用。

解决:每个平台只认一种模型。我们取消了 Android 应用保护策略的分配,并把 Android 的条件访问授权从 Require app protection 换成 Require compliant device。工作资料设备直接就能满足它;不再有 MAM 闸门来添乱。

6. 我们自己的策略挡住了我们自己的管理工具 — AADSTS530033。在自动化 Intune 变更时,一次管理员登录被拒:条件访问拒绝了设备代码登录,因为那种令牌没有绑定到一台合规设备上。

解决:在一台已经合规的设备上执行特权操作,让令牌绑定到设备 — 比如在受管机器上交互式运行 Connect-MgGraph。这个结论其实是件好事:如果你的条件访问能拦住设备代码登录,说明它配对了。

关于和 AI 一起构建

我们公开构建,也和 AI 一起构建,包括运维这一块。AI 很擅长快速把一个配置在多个分支里推演一遍。我们给它配了一条规则:AI 提议,人来拍板 — 尤其是任何触及安全的东西。这种分工让一个小团队能以更大团队的节奏运转。

值得留下的心智模型

1. MAM 管应用;MDM 管设备。按你需要的保证来选。
2. 合规意味着注册。你无法验证一台从未注册的设备,所以 Require compliant device 和“不注册”不可能共存。
3. 工作资料是中间选项。它管理的是一个容器,而不是设备 — 设备合规和个人隐私一次拿到。
4. 一个应用只用一种模型。别把 MAM 策略留在已经转到 MDM 的应用上;选定一条道。
5. 条件访问定门槛。选择匹配你模型的授权控制,让它去执行。

我们为几个工作邮箱投入这样的细致程度,是因为保护我们移动访问的这份纪律,和保护你在平台上的账户、资金和数据的,是同一份纪律。安全是一种贯穿内部工作的习惯,而不只是客户看得见的那部分。

牌桌上见。