香港MFA部署指南：一家會計師事務所的故事

一句話總結： 一家香港會計師事務所在例行IT檢查中發現了一件令人不安的事：一名員工多年來在公司信箱系統和執業管理平台上使用同一組密碼，而這兩套系統都沒有開啟多重要素驗證（MFA）。事務所的第一反應是制定更嚴格的密碼政策。但真正的解決方案不是換一組更強的密碼，而是不再讓密碼成為攻擊者與客戶資料之間唯一的一道防線。

香港會計師事務所手握的敏感資料，往往比自己以為的更多

這是一個複合情境，並非指名道姓的真實客戶，但在香港中型會計與審計業——處理法定審計、稅務申報及顧問工作，客戶涵蓋中小企業、家族企業乃至日漸增多的受監管企業的三十到六十人規模機構——這種情況相當常見。表面上，這類機構看起來不像是明顯的資安目標：沒有交易大廳，沒有面向客戶的應用程式，沒有金流閘道。但靜靜存在的，卻是銀行以外密度最高的敏感財務資料集中地之一：客戶銀行對帳單、薪資紀錄、稅務申報表、股權結構表，以及——對從事法定審計工作的事務所而言——攻擊者若從其他管道重建，得耗費數週才能取得的客戶內部財務存取權限。

這些資料並不集中放在一處。它分散在事務所的信箱系統（承載客戶往來郵件，也常帶著沒人想到要另外加密的附件）、存放工作底稿與專案檔案的雲端儲存或檔案同步平台，以及一套追蹤客戶檔案、計費、乃至端到端文件流程的執業管理系統之中。這三套系統中的每一套都是一道門。這種規模的機構通常由少數幾名懂技術的員工加上一家外包IT供應商來處理日常支援——沒有專職的資安職能，多數情況下，也沒有人的職責是去追問：這些門是不是都用同樣的方式鎖好了。

背後不斷加大的商業壓力是真實且持續增長的。客戶委任書中越來越多地加入資料處理與資安條款，這源於客戶自身在《個人資料（私隱）條例》（PDPO）下的合規義務，以及——對身處受監管行業的客戶而言——其監管機構對接觸其資料的整條供應鏈的期望。專業責任保險公司在續保時問的問題也比過去更尖銳。這一切都不要求會計師事務所本身持牌或受監管——只要求它被託付了他人需要負責的資料，而這幾乎描述了審計或會計事務所承接的每一項業務。

情境還原：密碼即一切，MFA只在有人想起來的地方開著

以下是這次IT檢查在這個情境中實際發現的狀況，也是同等規模機構中遠比管理層想像的更常見的一種模式。多數系統運作在純密碼存取之上——一組使用者名稱加一組密碼，僅此而已。MFA理論上是存在的，但開啟得很不一致：它曾在某個時點為事務所的核心信箱租戶開啟過，很可能是在某次Microsoft 365部署或續約期間，但從沒有人回頭核實它是否真的對每個信箱都強制生效，也沒人核實它是否延伸涵蓋執業管理平台、雲端儲存帳戶，或員工在旺季在家辦公時使用的VPN。

沒有任何條件式存取原則在統一管理這一切——沒有任何規則區分「從公司網路、用公司配發的筆電登入」和「從陌生IP位址、在凌晨三點嘗試登入」。對每套系統而言，每一次登入看起來都一樣，無論它來自哪裡、來自什麼裝置。自助密碼重設流程也形同虛設——員工忘記密碼時，通常的做法是打電話給負責IT的人，由對方手動重設，往往沒有可靠的方式驗證來電者真的是本人。

密碼重複使用的情況，幾乎是在一次因應客戶盡職調查問卷而進行的例行存取審查中偶然浮現的。一名員工多年來在公司信箱帳戶和執業管理平台登入中使用同一組密碼——嚴格來說並非疏忽，而是因為從沒有人告訴過她不要這樣做，事務所也從未強制執行過一項本可以攔截這種情況的政策。這正是合夥人真正理解之後感到擔憂的細節：一組密碼，在兩套承載著多年客戶財務資料的系統之間重複使用，除了密碼本身，再無其他防線。

這實際上意味著什麼風險——以及為什麼更嚴格的密碼政策解決不了它

事務所深入了解後，浮現出三個真實問題，值得分開來看，因為它們的解決方式各不相同。

第一，一組被攻破的密碼就足以觸及客戶資料——這不是因為事務所粗心大意，而是因為純密碼存取從設計之初就沒有考慮過憑證一旦落入他人之手該怎麼辦。密碼會被釣魚竊取，會在第三方網站資料外洩中被重複使用而曝光，會被猜中，也可能在一次事務所根本不知情的資料外洩事件中曝光，直到攻擊者真正使用它才被發現。超過80%的資料外洩事件都涉及某個環節上被竊取或強度不足的憑證——這個數字描述的正是這家事務所的真實風險，而不是某種抽象的行業統計。一旦運作純密碼存取的事務所有一組密碼被攻破，攻擊者通常就取得了與合法使用者完全相同的存取權限，能觸及對方能觸及的一切。

第二，沒有任何原則區分公司網路上受信任的裝置與來自世界任何角落的陌生裝置。合夥人用公司配發的筆電在辦公室Wi-Fi下登入，和用一台陌生裝置在另一個國家的家庭網路下登入，在只核對使用者名稱和密碼的系統看來毫無區別。對於員工要出差拜訪客戶現場、在審計旺季偶爾在家辦公到深夜、也越來越多用個人裝置查收郵件的事務所而言，這是一個真實的缺口——這些行為本身都不算異常，但都需要一層純密碼存取根本不具備的政策管控。

第三——也是事務所最容易忽略的一點——設計不當的自助密碼重設流程，本身就會製造出一種社交工程風險。一個依賴電話核實、外加幾個很容易被猜中的驗證問題（「妳的員工編號是多少」「妳的出生日期是哪天」）的重設流程，本身就是一個攻擊面。一個對目標員工做過一點點偵察的攻擊者——從LinkedIn檔案，或事務所自己網站上的「團隊介紹」頁面就能輕易取得資訊——完全可以像真正忘記密碼的員工一樣，順利騙過一個薄弱的重設流程。一家事務所若只解決了密碼重複使用的問題，卻讓重設流程繼續這樣鬆散，等於關上了一道門，卻留了另一道門虛掩著。

本能的因應方式——制定更嚴格的密碼政策、強制更長的密碼、更頻繁地強制重設——實際上並不能解決上述任何一個問題。更長的密碼依然是單一故障點。更頻繁的強制重設，實際效果往往是讓員工使用更容易預測的密碼規律、更多地重複使用密碼，而非相反——這是一個已被充分記錄的現象，使得嚴格的輪換政策反而適得其反。問題從來不在於密碼強度不夠，而在於密碼本身就是唯一的防線。

Brocent的觀點：MFA部署是一項策略設計工作，不是一次性開關

把MFA當成一個勾選項——「打開就好」——這種直覺可以理解，但幾乎總是不完整。只為一套系統、為部分使用者打開MFA，並不能彌補這家事務所實際存在的缺口，只是把它挪了個位置。事務所最初「MFA只在有人想起來的地方不一致地開著」這種狀態本身，正說明了當MFA部署被當作一次性設定工作、而非需要持續涵蓋每套系統、每位使用者、每條存取路徑的常態化原則來處理時，會發生什麼事。

Brocent的MFA解決方案正是從這個前提出發：MFA部署是一項設計工作，不是一個開關。這代表要逐套系統去決定應該在哪裡、以何種方式觸發驗證——信箱、執業管理平台、雲端儲存、VPN，以及任何原生不支援現代身分驗證的老舊應用程式（這是老舊執業管理或會計軟體中真實且常見的問題，需要透過RADIUS、SAML或應用程式代理來解決，而不是因為處理起來麻煩就乾脆放任不管）。這也代表要設計真正能區分受信任辦公裝置與陌生裝置的條件式存取原則——依據裝置合規性、地理位置和IP信譽來決定是否需要升級驗證要求，並將事務所真正信任的裝置與地點列入白名單，藉此降低日常摩擦，而不是把每一次登入都當作同等可疑來對待。同時，這也代表要修復自助重設流程本身，避免它悄悄成為整個部署中最薄弱的一環。

同樣重要的是，部署節奏要經過設計，避免在第一天就把員工鎖在系統外——如果MFA強制生效處理不當，這在事務所最忙碌的旺季會是一個真實風險，也是同等規模的事務所年復一年推遲MFA部署、儘管早已知道該做卻遲遲不做的最大原因。一次有管理的部署會提前規劃好員工告知溝通，給員工留出寬限期和清楚的註冊指引，並在過渡期專門配置支援台，而不是任由困惑的使用者湧入現有的任何支援管道。這從來不是一個做完一次就可以忘記的「一週專案」——而是一種需要持續關注的常態：每月了解究竟有多少人真正完成了註冊、哪裡存在例外情況，以及不斷變化的MFA涵蓋率究竟在向事務所傳達什麼樣的真實風險訊號。

落地到這類規模的事務所，實際會是什麼樣子

部署到位之後，MFA會在信箱和每一套接觸客戶資料的核心系統上被一致地強制執行——不再是「信箱開了，其他地方就忘了」，而是同一套原則以相同方式涵蓋執業管理平台、雲端儲存和遠端存取，並選用與事務所現有環境相符的驗證平台（對已經在使用Microsoft 365的事務所而言，透過Entra ID使用Microsoft Authenticator是最自然的選擇；若應用程式組合有其他需求，Duo Security或Okta也可供選擇）。

條件式存取規則疊加在這層MFA之上，依據地理位置、裝置合規性和IP信譽即時評估每一次登入，而不是把所有登入一視同仁——受信任的辦公裝置和地點可以被列入白名單，維持日常操作的低摩擦；而來自陌生地點或不合規裝置的登入嘗試則會自動觸發更高層級的審查，不必仰賴人工及時察覺並反應。對於客戶群確實高度敏感、或需要保護觸及最核心帳戶的合夥人而言，無密碼驗證和FIDO2硬體金鑰可作為進一步的措施——在最需要的帳戶上徹底消除密碼這個攻擊面，而不必在第一天就在全公司範圍強制推行。

自助密碼重設流程會與MFA部署一併修復，而不是作為一個獨立問題被擱置——修復後的重設流程本身也需要第二要素驗證，而不是仰賴容易被猜中的驗證問題和一通電話，藉此堵上一個設計粗糙的重設流程原本會留下的那條社交工程漏洞。整個部署本身也會經過精心排程：員工告知溝通和註冊指引會在強制生效之前發出，一段寬限期涵蓋過渡階段，專門配置的支援台在部署期間處理註冊相關問題——確保旺季不會演變成一場「被鎖在系統外」的事件。上線之後，持續管理涵蓋原則更新、隨著新員工或新應用程式接入而產生的例外處理，以及每月報告展示MFA涵蓋率、驗證事件和被攔截的存取嘗試——讓合夥人下次再被問及事務所的存取控制是否有效時，能夠給出一個有資料支撐的真實答案。

純密碼存取 vs. MFA不一致開啟 vs. 全面受管的MFA與條件式存取部署

對處於這種位置的事務所而言，現實中存在三種真實狀態，值得精確地說明每一種究竟能保護到什麼程度：

純密碼存取（單一要素，單一故障點）——多數同等規模事務所的起點狀態，也是讓一組被攻破的密碼就足以觸及客戶郵件、執業管理紀錄和雲端存放的工作底稿的狀態。運作成本最低，也是大多數事務所直到一次存取審查或客戶的盡職調查問卷逼出這個問題之前，都沒有意識到自己仍處於其中的狀態。
MFA不一致開啟（「部分系統有」）——比什麼都沒有要好，但常常被誤認為「已經做完了」。MFA只存在於最容易開啟的系統上——通常是信箱——而執業管理平台、雲端儲存和VPN仍悄悄停留在純密碼狀態，或使用著從未被正式部署或強制執行的MFA。這正是本文情境中實際存在的狀態，也是最容易讓事務所錯誤地以為自己的存取控制已經足夠的狀態。
全面受管的MFA與條件式存取部署（Brocent模式）——MFA在信箱、執業管理平台、雲端儲存和遠端存取上被一致地強制執行；條件式存取原則能區分受信任裝置/地點與陌生裝置/地點；自助重設流程不再是薄弱環節；並配有每月的涵蓋率與例外情況報告，確保事務所在任何時候被問到這個問題，都能給出一個真實、即時的答案。

常見問題

MFA會拖慢員工的日常工作嗎？

如果設計得當，通常不會有明顯影響。條件式存取原則會把受信任的裝置和地點列入白名單——合夥人從辦公室用公司配發的筆電登入，通常不會像來自陌生裝置或陌生地點的登入那樣被要求額外驗證。事務所實際感受到的摩擦，幾乎總是源於排程不當的部署——例如一次性對所有人開啟MFA、沒有註冊緩衝期、也沒有支援台配合——而不是MFA本身的問題。

MFA和條件式存取有什麼區別？

MFA要求在密碼之外再提供一個額外要素——一組驗證碼、一次推播核准、或一枚硬體金鑰——才能取得存取權限。條件式存取則是疊加在其上的原則層，依據裝置合規性、地理位置和IP信譽等訊號，來決定*何時*需要觸發這個額外要求。只有MFA而沒有條件式存取，會把所有登入都一視同仁地對待，無論風險高低；而條件式存取讓事務所只在真正有風險的地方才施加更強的驗證。

這和Microsoft 365相容嗎？

相容——對多數已經在使用Microsoft雲端生產力套件的香港會計師事務所而言，Microsoft 365和Entra ID（原Azure Active Directory）是最自然的平台選擇，透過Entra條件式存取搭配Microsoft Authenticator，也是Brocent為這類規模事務所部署最常見的配置。同一次部署也會把涵蓋範圍延伸到Microsoft 365之外的系統——執業管理平台、雲端儲存和老舊應用程式，透過RADIUS、SAML或應用程式代理方式整合那些原生不支援現代身分驗證的系統。

部署節奏該如何安排才不會把人鎖在系統外？

註冊通知和清楚的操作指引會在強制生效前發出，一段寬限期涵蓋過渡階段，讓員工可以完成註冊而不至於在工作日中途被鎖定，專門配置的支援台在部署期間處理註冊問題和裝置變更。強制執行通常是分階段進行的——先從試點小組或干擾風險最小的系統開始——而不是對所有系統、所有使用者同時啟動。

這能滿足網路保險對MFA的要求嗎？

如今大多數網路保險保單以及越來越多的合規框架都要求MFA，但保險公司問的問題比「你們有沒有MFA」更具體——它涵蓋哪些系統、執行是否一致、例外情況是否被追蹤記錄。一次受管、一致執行、並配有每月涵蓋率報告的部署，能讓事務所對這些問題給出一個真實、即時的答案，而不是一個只涵蓋了最容易開啟MFA的那套系統的片面答案。

如果有人的MFA裝置遺失了怎麼辦？

一次設計得當的部署會為此配備一套安全、有管理的流程——經過驗證的重新註冊，而非一次簡單的密碼重設，這樣遺失的手機或硬體金鑰就不會變成繞過其本應強制執行的這項控制的後門。這正是一個設計粗糙的自助重設流程原本會留下的缺口，也正是受管部署要堵上的那個缺口。

這項服務包含在受管IT計畫中嗎？

基礎的密碼與憑證管理已經包含在Brocent受管IT支援計畫的每一個層級中——它是計畫本身已經在管理的內容，而不是另一筆獨立的採購。一次涵蓋每套系統、包含老舊應用程式整合和每月持續報告的完整MFA與條件式存取部署，則作為計畫資安治理工作的一部分來界定範圍，依事務所自身規模量身打造，而不是作為一個獨立專案單獨出售。各計畫層級如何涵蓋這部分內容，可參考最新價格。

這在受管IT計畫中的定位

這家事務所真正的解決之道，從來都不是一套更嚴格的密碼政策——而是認清MFA與條件式存取部署，是需要持續擁有的一項治理工作，而不是做完一次就可以打勾了事的專案。這正是為什麼它應該內建在按使用者計費的受管IT計畫裡，而不是作為一次獨立採購：密碼與憑證管理已經是Brocent受管IT支援計畫每一個層級——Startup、Established、Growth、Enterprise——的一部分，與全天候監控、支援台、受管防火牆和修補程式管理並列。而一次完整的MFA與條件式存取部署，延伸涵蓋Microsoft 365和Entra ID等受管雲端服務，同樣屬於這層治理關係的一部分，而不是另一份帶著自己的合約、也帶著自己缺口的獨立供應商合作。

對於一家剛剛發現某組密碼在承載多年客戶財務資料的系統之間被重複使用的香港會計師事務所而言，真正有用的下一步，不是獨自去尋找一家MFA供應商，而是就事務所自身規模，聊一聊按使用者計費的受管IT計畫會是什麼樣子——把MFA與條件式存取部署，作為計畫本身已經在承擔的資安治理工作的一部分來規劃。把MFA當作一次性專案，單獨向某個專業供應商採購，脫離負責事務所日常IT工作的團隊，恰恰是事務所最終又回到最初困境的原因：一項控制措施只在某套系統上被開啟過一次，此後再也沒人回頭檢視過。

完整的價格詳情見此，涵蓋全部四個計畫層級，以及MFA與條件式存取部署這類資安治理工作如何融入其中。想知道一次受管部署對貴機構這樣規模的事務所究竟會是什麼樣子——包括像本文情境中的密碼重複使用與MFA涵蓋不一致，能有多快得到解決——最快的方式是直接聯繫Brocent，而不是僅憑一張價格頁去自行推斷。