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外判方案對你目前的情況來說到底合不合適。