Microsoft 365 许可证管理：九国零办公室的远程团队

没有办公室的时候，租户就是公司本身。 在一个完全远程的 Microsoft 365 环境里，真正的风险很少是安全事故——更常见的是失控：没人记得分配给谁的许可证、离职后仍能登录的账号、早已不匹配岗位的许可证档位，以及没人负责的续约。解决这些问题靠的是按周期执行的许可证治理，而不是一整套安全项目。

一个完全远程的团队，一个 Microsoft 365 租户，没有办公室

设想一家大约 120 人的软件公司。它没有传统意义上的总部——工程团队分布在亚洲的几个城市，客户成功团队大多在海湾地区，一个小型产品与设计团队在欧洲工作，销售则覆盖澳大利亚和亚太其他地区，员工分散在各自所在地远程办公。所有人从入职第一天起就是远程雇佣，从来没有人走进过某间办公室、由现场的 IT 人员当面递上一台笔记本电脑。这是一个综合性的示例场景，并非指某一位真实客户，但它的结构对今天很多远程优先的软件或服务型公司来说都不陌生。

对这样一家公司来说，Microsoft 365 不是办公网络之外的附加品，它本身就是办公室。邮件、聊天、文件、日程、视频会议，以及几乎所有其他 SaaS 工具登录所依赖的身份，几乎全部装在同一个 Microsoft 365 租户里。没有需要上锁的机房，没有需要审计的门禁系统，甚至没有一条物理边界。租户本身就是边界，同时也是文件柜、电话系统和大门。

最终要为这件事负责的，往往是运营负责人或首席运营助理这类角色，他们通常并不是自愿去管 IT 的——只是因为总得有人拿着这个 Microsoft 365 管理员账号，日常的租户管理工作也只能挤在招聘、发薪之外的碎片时间里完成。这正是本文要写给的那个人。

为什么"我们不需要一整套安全项目"是一个合理的起点

有必要先说清楚：一家 120 人的远程公司表示不想搭建复杂的安全体系，这并不是疏忽大意。对这样规模的企业来说，如果没有受监管的数据、没有强制要求特定控制框架的合规义务，去搭建一整套安全运营体系——安全运营中心、专职分析团队、按某个具体标准做的正式审计——投入通常会明显超过它当下真实面对的风险。买超出实际需要的安全能力本身也是一种成本，而且这种成本并不能解决日常真正在制造麻烦的那些问题。

在这样的租户里，真正制造麻烦的很少是复杂的攻击手段，而是行政层面的失控：一个六个月前就该停用却还留着的账号、一个买给某个早已不存在的岗位的许可证档位、一次没人重新评估就悄悄续上的订阅。解决这些问题都不需要一套安全项目，需要的是有人像物业管理员管理一栋楼那样管理这个租户——不惊天动地，也不是安全议题，但要按周期去做。

这个区分对后文很重要。本文接下来的内容，不会要求一家 120 人的远程公司去搭建它不需要的安全职能。要求的只是无论规模大小都真正不可谈判的极少数底线，以及把日常的许可证与访问权限治理当作运营工作来对待，而不是留给谁有空谁去做。

一个分布式 Microsoft 365 租户里，实际上会出什么问题？

在那些从未有人明确负责、任其自然生长的租户里，有四种模式反复出现。单独看，每一种都不算什么大事；但一两年积累下来，租户花的钱会比该花的多，而实际掌控力却比所有人以为的要弱。

没人记得分配给谁的许可证

一位承包商项目结束了，账号却从没被停用；一个岗位被重组，旧的许可证仍然挂在一个没人再用的账号上；给某个团队工具试用买了十个席位，实际只有三个被打开过。这些都不是有意的浪费，只是许可证分配一旦完成就很少有人回头检查的必然结果。在一个分布式团队里，没有物业管理员会注意到某张桌子一直空着，所以这类无人认领的许可证往往比在同一间办公室里能存活得久得多。

离职后仍能登录得比任何人预想的都久

在有办公室的公司，离职有一个物理触发点：电脑要交还、门禁卡要注销、总有人会注意到那张空椅子。在一家完全远程的公司里，唯一的触发点是有没有人想起来去通知 IT。如果离职者所在的时区与管理租户的人相差八个小时，"今天想起来告诉 IT"很容易变成"三天后才被告知"——而在这三天里，一位已经离职员工的邮箱、文件以及任何已连接的 SaaS 工具，访问权限和他离职前一天完全一样。

许可证档位早已不匹配实际工作内容

许可证档位会一路积累历史。两年前为某个已经结束的项目给某人开了高级档位；新员工接手某个岗位时，往往直接沿用前任的档位，而不管是否真的匹配这份工作。放大到 120 人、经过几年时间，一个租户里通常会出现一批昂贵的许可证挂在只需要基础档位的人身上，偶尔也会出现相反的情况——某人的工作确实需要更高档位，却一直用着入门版，悄悄绕开限制工作，没人注意到。

没人负责的续约

Microsoft 365 订阅到期后会自动续约，不管有没有人先审查过。如果日历上没有一个固定的时间点让某个人负责问一句"这份配置还符合我们现在的团队和业务吗"，续约就只会原样重复去年的分配。稳定的年份里这没什么问题。但经过几年的招聘、组织调整和人员流动之后，续约日期反映的已经不再是公司现状，而是自上次有人认真看过之后租户里悄悄积累的一切。

为什么入职、转岗、离职需要一套流程，而不是一张清单？

一张清单假设总有人记得去执行它，而这个假设恰恰是分布式团队最容易失效的地方，因为本该为某个时区的离职者执行清单的人，常常正在睡觉，或者身处好几个时区之外，又或者根本不是第一个知情的人。真正的流程和一张清单不同，它至少要具备三样东西：一个统一的触发点，不管谁先知道都会启动；一个明确的责任人，即便离职者所在的时区没人醒着，也照样要把流程走完；以及一份记录，可以证明这件事到底有没有真的发生过。

入职是相对简单的一半：新员工从第一天起就需要一个账号、匹配其岗位的许可证档位，以及所在团队实际使用的工具权限——而不是照搬公司里权限最大的人的那一份，这恰恰是过度授权账号最初产生的方式。转岗则是大多数公司完全忽略的一半：一个人在公司内部换了岗位，几乎从不会有人重新审查他原来的权限，于是两年内换过三个岗位的人，很可能同时叠加着三份岗位的历史权限。

离职是时区问题冲击最大的环节。离职流程的触发不应取决于离职者的主管恰好身处哪个时区，而应该在 HR 确认离职日期的那一刻立即触发，由一个明确的责任人负责执行——不管他所在的地方是不是深夜——并按照一套标准顺序完成：立即禁用登录、决定邮箱与文件的去向、在这一点确定后移除许可证、并确认该账号不再出现在任何活跃名单里。把即将离职员工的邮箱转换为共享邮箱，正是微软自己针对这种情况给出的官方做法：账号本身保留下来作为"锚点"，让主管或继任者仍能访问邮件和文件，同时禁用该账号的登录能力，随后即可移除这个账号上的付费许可证——这才是真正停止为一个没人在用的席位付费的关键一步。把这件事当作一套流程而不是一张"有空再做"的清单来对待，区别就在于离职者的访问权限是在几个小时内结束，还是要等到有人碰巧注意到才悄悄拖上很久。

许可证优化应该衡量什么，多久看一次？

许可证优化不需要一次安全审计，它需要的是两个习惯：真实衡量谁在用什么，以及按固定周期去做，而不是等谁有空。

每个月值得跑一次的两份报表

第一份是许可证使用情况视图。Microsoft 365 管理中心的使用情况报表会按应用逐一显示哪些持有许可证的用户实际处于活跃状态，很直观地就能看到某个许可证已经好几个月没被碰过，而挂在它上面的名字甚至可能已经不是现在这个岗位的人了。第二份是登录活动视图。在 Microsoft Entra 管理中心的用户列表里加上"上次交互式登录"和"上次非交互式登录"两列，并按日期排序，就能找出那些已经沉寂下来的账号——这往往是离职流程没有走完，或者某个承包商账号没人记得设定使用期限的最初信号。

每月各跑一次，指定一个人专门负责审查，并把每一个被标记出来的账号当作一个需要确认的问题,而不是自动删除的对象——有些沉寂的账号属于正在休产假或育儿假的人，并不是已经离职的人。这一个习惯每月坚持下去，就能在续约日带来意外之前，提前拦截掉上文描述的大部分失控。

即便是这样的客户，哪些安全措施也不该省？

以下内容不会把一家 120 人的远程公司变成一家运营安全项目的公司。它是任何承载着一家公司整个日常运转的租户都真正不可谈判的极小一部分，跟对更大安全体系的意愿高低无关。

第一项是所有账号一律启用多因素身份验证（MFA），没有例外——包括那些常因为注册麻烦而被悄悄豁免的承包商账号和共享服务账号。第二项是基础的条件访问规则：至少要求访问最敏感的系统时使用受管理或合规的设备，并把来自陌生地点或陌生设备的登录当作值得二次确认的信号，而不是直接放行。这两项都不需要一支安全团队去运营——都是配置一次之后就能持续生效的设定。

为什么微软自带的保留机制不是备份

第三项是对租户内数据做一份可恢复的备份，这一点也是最常被误解的地方。微软内置的保留策略、版本历史和回收站机制，设计初衷是应对日常使用中的短期误删——比如某人删错了一个文件，当周就想找回来，或者某封邮件被删除后不久需要恢复。它们并不是按照企业连续性计划所理解的"备份"去设计、测试和运营的：一份独立的、被持续监控的数据副本，拥有自己的恢复点，可以按你自己设定的周期恢复，而不是恰好符合微软保留设置允许的那个时间窗口。Brocent 的云端托管备份服务正是为了填补这道缺口而存在——它会针对明确的恢复时间目标和恢复点目标设置备份与恢复策略，让备份任务在持续监控下运行而不是无人看管地自行运转，并包含定期的恢复演练，真正验证一次恢复能否成功，而不是想当然地假设它可以。对一家没有现场 IT 人员去发现某次备份悄悄失败的完全远程公司来说，一份被监控、被测试过的备份，几乎接近不可谈判的底线，而不是可有可无的选项——这不是因为这个租户面临什么异常的威胁，而是因为一旦出问题，根本没有别的安全网。

没有办公室的时候，设备该怎么管？

一家远程公司仍然要回答办公室原本默默给出的答案：这台设备有没有被纳管、是否达到最低安全基线，以及员工离职后它该怎么处理。设备纳管应该发生在设备第一次被用于工作之前，而不是事后补做——不论是公司发放的还是员工自己的设备，新员工的笔记本电脑理应和开通 Microsoft 365 账号走同一个流程被纳入设备管理，而不是依赖谁记得去补一步。

一套合理的基线可以很短、也很好落实：开启磁盘加密、保持操作系统更新、并具备在设备丢失或雇佣关系结束时远程清除企业数据的能力——这些都不需要把每一台笔记本都当成正在发生的安全事件来对待。员工个人设备用于办公需要不同的处理方式，因为对一部私人手机做全盘清除，既不是大多数公司想做的事，也不是大多数员工愿意接受的事。更现实的折中方案是把企业数据隔离在设备上一个受管理的独立空间里，需要清除时只清除这部分，不触碰个人照片或消息——这正是我们在《新加坡 SaaS 公司的 MDM 与 BYOD 设备管理指南》一文中详细拆解过的做法，那篇文章针对一个同样分布式的团队讲清楚了这种隔离的具体机制，也讲清楚了 MDM 与 BYOD 管理本身如何完成纳管与容器化。本文不再重复那部分内容——如果设备是你最关心的部分，那篇文章才是接下来该读的。

分布在多个国家的团队，容易在哪些地方栽跟头？

除了许可证和设备之外，还有几个问题只有在团队分布在多个国家、而不是集中在同一栋楼里时才会显现出来，而且往往要等到具体出事才会被注意到。

第一个是数据驻留方面的预期。不同国家、不同客户对数据物理存放位置的预期各不相同，一个员工分布在十几个国家登录的完全远程团队，至少需要清楚自己的 Microsoft 365 数据存放在哪里，以及这是否满足此前已经向某个客户或监管机构做出的承诺——这个问题最好在客户提出来之前先想清楚，而不是之后才补答案。

第二个是支持覆盖上的当地假期，它带来的干扰比听起来要大。一份按某一个地区日历排班的值班表，会在其他每一个地区的公众假期上悄悄出现空档，而在一个横跨亚洲、海湾地区、欧洲和澳大利亚的团队里，根本不存在一份能覆盖所有人的统一日历。解决办法不是加人，而是从一开始就按照每一个相关国家的日历去搭建值班计划，而不是等到问题出现的那一天才发现空档。

第三个、也是最常见的一种，是由薪酬系统驱动的入职与离职日期，它正是前文提到的入职、转岗、离职问题最常见的现实来源。HR 和薪酬系统，尤其是横跨多个国家、适用不同劳动法和不同发薪周期的情况下，并不总能在入职或离职日期确定的第一时间就通知 IT——有时是因为系统之间没有打通，有时是因为根本没人明确定义过谁该负责把这两边连起来。入职日期传达晚了，新员工的头几天就没法产出；离职日期传达晚了，就是本文前面那个离职问题最常见的真实版本——不是恶意，也不是清单被漏掉，而是两套系统从来没被安排好互相通知。

为什么这件事更适合放进一个统一的管理型IT外包方案，而不是四个分开的工具？

前面提到的四个问题——无人认领的许可证、离职后仍能访问、档位不匹配、无人负责的续约——再加上入职、转岗、离职流程中的漏洞，以及跨国团队的这些棱角，其实都发生在同一个地方：这个 Microsoft 365 租户，以及与它相连的人员与设备记录。这正是把它们当作一件事来管理、而不是从四个不同供应商分别采购四样东西的现实理由。

分布式团队管理 Microsoft 365 的三种方式

没人正式负责。 最初搭建租户的人依然握着管理员权限，许可证分配全靠有人开口才临时处理，离职流程能不能走完全看有没有人想起来提一句。这是一家快速成长的远程公司会自然滑向的默认状态，不是谁刻意做出的决定，也正是上文所有问题的源头。
每季度做一次表格式清理。 有人每个季度导出一次用户列表，手动比对花名册，清理发现的问题。这种方式最终能兜住最严重的部分，但离职者的访问权限最长可能敞开三个月才等到下一次审查，而且整件事完全取决于当季度负责的人有没有时间去做。
一个统一的管理型IT外包方案，持续运行。 许可证使用情况和登录活动作为日常惯例每月审查，而不是偶尔才启动的项目；入职、转岗、离职的请求走同一套明确流程，不受时区影响；管理这个租户的同一支团队也同时负责设备纳管以及保护它的备份——因为这本来就不是四个不同的问题，而是同一个租户的四个侧面。

这里也涉及一个值得说清楚的具体主张。Brocent 自己的管理型IT外包服务建立在一套自研的统一引擎之上，而不是把多个第三方工具在客户开通时临时拼接在一起——正因为这套平台自身的各个模块之间会共享数据，我们的管理型IT外包服务被设计为把标记出未使用、已预付费的软件席位以及跟踪硬件生命周期，当作平台的日常功能来运行，而不是需要有人另外记得去安排的一次性审计项目。这是这套平台当下实际具备的功能，不是一个假设中的好处——它做的其实和一份表格式清理想要手动逼近的事情一样，只不过是持续运行，而不是一个季度才做一次。同一个平台也协调着一个 Microsoft 365 租户所依赖的云服务，以及上文提到的设备管理这一层——这才是"一套引擎，而不是四个工具"在实际中的样子，而不只是一句口号。

常见问题

120 名远程员工需要一个专门的 IT 团队吗？

不一定需要完整的内部团队。真正需要的是有人——无论是内部员工还是外包服务商——持续、明确地负责这个租户：许可证分配、每月的使用情况与登录审查，以及入职、转岗、离职流程。一家 120 人的公司完全可以由一家管理型IT外包服务商负责运营层面的工作，同时保留一位内部负责人来做服务商不该单独拍板的判断——比如谁真的需要更高档位的许可证。

我们该怎么找到未使用的许可证？

运行 Microsoft 365 管理中心的使用情况报表，查看每个应用中哪些持有许可证的用户实际处于活跃状态，并与当前的花名册做比对，而不是拿租户刚搭建时的名单去比。任何持有许可证却长期不活跃的账号，在移除之前都值得直接问一下这个人的主管，因为有些不活跃是正当的——休假、换岗，或者这个人日常工作确实用不到这个工具。

离职员工的邮箱和文件会怎么处理？

标准做法是把即将离职员工的邮箱转换为共享邮箱，而不是直接删除，这样主管或继任者仍能访问邮件和文件，同时禁用这个人的登录能力。完成转换之后，就可以移除这个账号上的付费许可证，这才是真正停止产生费用的环节——在决定好邮箱内容该怎么处理之前就直接删除账号，往往是错误的第一步。

我们需要 Intune 吗？

只要公司会发放设备、或者允许员工个人设备访问企业数据，就需要某种形式的移动设备管理平台，而对一家以 Microsoft 365 为核心的公司来说，Microsoft Intune 是自然的选择，因为它本身就在同一个生态里。是否需要它，取决于目前设备有没有任何纳管或基线，而不是公司规模本身——一家目前完全没有设备管理的公司，需要补的缺口远比选哪个平台更大。

微软自带的备份够用吗？

微软内置的保留策略和回收站功能是为短期误删设计的，并不是一份经过测试、被持续监控、拥有自己恢复点目标和恢复演练计划的备份。对一家没有现场 IT 人员去发现备份悄悄失败的完全远程公司来说，一项独立的托管备份服务——比如 Brocent 的云端托管备份——可以补上这道缺口，而完全不需要搭建一整套安全项目。

我们应该用哪个许可证档位？

这取决于每个岗位实际要做什么，而不是这个岗位的上一任恰好用的是什么，微软自己公布的档位和当前价格应该在做决定的那一刻直接核实一遍，因为它们会变化。上文提到的每月使用情况报表，正是续约时回答这个问题的正确起点，因为它显示的是每个档位今天实际被用来做什么，而不是当初为什么买它。

这怎么收费？

Brocent 的按人头计费的管理型IT外包方案按每位员工每月计费，这正好匹配这个问题本身的形状——许可证、访问权限和设备都是挂在一个人身上的，而不是挂在一个站点或服务器数量上。当前各档位的价格和覆盖范围可以在我们的定价页面查看。

你们能接手一个不是自己搭建的租户吗？

可以，这是常见的起点，而不是例外情况。一个已经在没有明确负责人的情况下自然生长了两三年的租户，正是管理型IT外包服务商最擅长接手的场景：第一步就是上文提到的那套使用情况与登录审查，先作为一次性的基线评估跑一遍，通常第一轮就能发现大部分无人认领的许可证和沉寂账号。

从许可证治理到可预测的按人头账单

本文所讲的一切都不是安全项目，也不应该被当作安全项目卖给你。这只是一家公司日常的运营卫生工作，只不过这家公司的办公室恰好是一个 Microsoft 365 租户,而不是一栋楼:许可证匹配持有它的人、离职者的访问权限在几个小时内结束而不是拖上几周、一小组真正不可谈判的安全底线、被纳管而不是被想当然的设备，以及一个每月坚持的习惯,在续约日把意外变成惊喜之前提前拦截失控。这些都与任何迁移事件无关——如果你面对的确实是一次迁移,比如更换服务商或第一次上线 Microsoft 365,可以参考我们的 Microsoft 365 迁移清单,那是一个有不同步骤的不同项目;如果是并购之后合并租户,欢迎直接联系我们。

之所以这件事更适合放进一个按月计费的统一方案,而不是一堆分开采购的单点工具,是因为这个问题本身的形状就是按人头分布的,而 Brocent 的管理型IT外包方案也是按同样的方式计价——按人头、按月,所以一个 120 人的分布式团队付的是 120 个人的钱,而不是为一堆各自解决其中一小块问题、分别授权的工具叠加付费。如果你想在做任何决定之前,先就目前的租户听一个第二意见,联系我们的团队——我们会告诉你,如果是我们来看,会先看哪里,以及一个完整的管理型IT外包方案对你目前的情况来说到底合不合适。