中小企業的信件、檔案與通訊錄幾乎都放在 Microsoft 365 或 Google Workspace。攻擊者通常不需要攻破伺服器，只要一組能登入的帳號密碼：釣魚網頁騙來的、資訊竊取程式從員工電腦偷走的（見資訊竊取程式與外洩帳密），或用常見密碼逐一試出來的。登入之後，接著就是設定自動轉寄、騙使用者授權惡意應用程式、把檔案分享出去。這些路徑大多能靠租戶層級的設定事先擋掉，但不少設定的預設值偏向方便，需要管理者主動收緊。
這篇寫給負責管理公司 Microsoft 365 或 Google Workspace 租戶的一、兩位 IT 人員：先介紹美國 CISA 的 SCuBA 安全設定基準與免費檢測工具，再逐項說明最值得先改的設定、每一項擋的是哪種攻擊，最後是只有一個下午時的先後順序。帳號已經被盜時的處理步驟，見公司信箱帳號被盜用怎麼辦；本文談的是事前的預防設定。
用 CISA SCuBA 當檢查表
美國 CISA 在 2022 年成立 SCuBA（Secure Cloud Business Applications）專案，替 Microsoft 365 與 Google Workspace 制定安全設定基準；主要目的是保護聯邦機關放在雲端的資料，但 CISA 表示所有組織都可以拿來強化 SaaS 安全[1]。CISA 另外提供兩個免費的檢測工具：ScubaGear 檢查 Microsoft 365 租戶，ScubaGoggles 檢查 Google Workspace，會把租戶目前的設定和基準逐條比對，產出報告指出需要改善的地方；工具與基準都開放給一般企業使用[1]。
2024 年 12 月 17 日，CISA 發布具拘束力的作業指令 BOD 25-01，要求美國聯邦文職行政機關（FCEB）遵循一組指定的基準設定、部署自動檢測工具，並修正不符合的地方[2]。這項指令只約束美國聯邦文職機關，對台灣企業沒有法律效力；CISA 則「強烈建議」其他組織也採用這些設定與檢測工具[2]。必要設定清單會持續更新：Microsoft 365 的條目最近一次在 2026 年 9 月新增，Google Workspace 的條目則要求聯邦機關在 2026 年 12 月 1 日前完成[2]。
拿來用時要記得兩件事。第一，基準是為美國聯邦機關寫的，部分條目不適用台灣企業，例如要求 DMARC 彙整報告寄到美國國土安全部的信箱、Google Workspace 的資料存放區域設為美國[2]，照抄沒有意義。第二，有些條目要靠條件式存取等功能才能做到，而條件式存取至少需要 Microsoft Entra ID P1[3]，中小企業的方案不一定有。報告中「未符合」的項目，先判斷風險與可行性再決定怎麼補強，不要為了分數硬改。
實務上，可以先跑一次 ScubaGear 或 ScubaGoggles，把報告當成待辦清單；CISA 的說明是以最新版工具執行，就會自動比對基準並在報告中列出不符合的項目[2]。以下各節挑出對中小企業最有效的幾項，附上對應的 SCuBA 條目編號，方便對照報告。
身分：MFA、舊式驗證與管理帳號
每個帳號都要 MFA
為什麼：密碼外洩之後，MFA 是讓攻擊者登不進來的關卡。微軟表示，啟用 MFA 並封鎖舊式驗證，可以擋下超過 99.9% 的常見身分攻擊[3]。但 MFA 只在登入時把關，攻擊者若直接偷走登入後的工作階段 Cookie 就能跳過它，這也是後面幾項設定仍然必要的原因（見資訊竊取程式與外洩帳密）。
Microsoft 365 有兩種做法。安全性預設值（security defaults）不需額外授權，開啟後要求所有使用者註冊 MFA、管理員每次登入都要 MFA、一般使用者在微軟判斷有需要時進行 MFA，並封鎖舊式驗證與裝置代碼流程；攻擊者會濫用裝置代碼流程，騙使用者在另一台裝置上輸入代碼[3]。2019 年 10 月 22 日以後建立的租戶可能已經預設開啟；沒有條件式存取原則、沒有進階授權、也沒在使用舊式驗證用戶端的租戶，微軟會先通知再自動開啟[3]。條件式存取（Conditional Access）可以依使用者、應用程式與登入情境自訂規則，但至少需要 Microsoft Entra ID P1；要改用條件式存取，必須先關閉安全性預設值，並應立即啟用替代原則，微軟也提供涵蓋相同保護的「Microsoft 管理的條件式存取原則」[3]。
另外，微軟已對管理入口強制 MFA，與租戶設定無關：第一階段從 2024 年 10 月起涵蓋 Azure 入口網站、Microsoft Entra 系統管理中心與 Intune 系統管理中心，2025 年 2 月起擴及 Microsoft 365 系統管理中心；第二階段從 2025 年 10 月 1 日起涵蓋 Azure CLI、Azure PowerShell、Azure 行動應用程式、IaC 工具與 REST API 的建立、更新、刪除操作[4]。租戶可自行延後的最晚日期，第一階段是 2025 年 9 月 30 日、第二階段是 2026 年 7 月 1 日，兩者都已經過了；強制範圍也包括緊急存取帳號，微軟建議這類帳號改用通行金鑰（FIDO2）或憑證式驗證[4]。拿一般使用者帳號跑自動化腳本的，微軟建議改用受控識別或服務主體等工作負載身分[4]。
Google Workspace 在管理控制台 Security > Authentication > 2-step verification 先開放使用者自行啟用，追蹤註冊進度後再強制執行；強制時可以設定新使用者註冊寬限期（1 天到 6 個月，期間只用密碼就能登入），也可以限制驗證方式，例如排除簡訊與語音驗證碼，或只允許安全金鑰與通行金鑰[5]。Google 指出通行金鑰與安全金鑰的防釣魚程度相同，也表示正在對管理員帳號強制兩步驟驗證[5]。SCuBA 的要求更嚴：兩個平台都要求所有使用者使用抗釣魚 MFA（MS.AAD.3.1v1、GWS.COMMONCONTROLS.1.1v1），Microsoft 365 要停用簡訊、語音與電子郵件一次性密碼（MS.AAD.3.5v2），Google 的新使用者寬限期最長一週（GWS.COMMONCONTROLS.1.4v1）[2]。各種 MFA 的強弱比較與推行順序，見多因素驗證導入指南。
封鎖舊式驗證，找出還在用 SMTP AUTH 的設備
為什麼：舊式驗證（例如以 IMAP、POP3、SMTP 直接送出帳號密碼的用戶端）不支援 MFA，就算租戶已要求 MFA，攻擊者仍可改用舊協定登入、繞過 MFA；微軟表示，目前大多數意圖入侵的登入嘗試來自舊式驗證[3]。
Microsoft 365：安全性預設值會封鎖所有舊式驗證要求，沒有使用安全性預設值的租戶則可用條件式存取封鎖[3]。最常卡住的是用 SMTP AUTH 寄信的事務機、掃描器與老舊系統。微軟在 2026 年 1 月修訂後公布的時程是：到 2026 年 12 月為止行為不變；2026 年 12 月底起，既有租戶的 SMTP AUTH 基本驗證預設停用，但管理員仍可自行開回；2026 年 12 月以後建立的新租戶預設不提供，只支援 OAuth；最終移除日期將在 2027 年下半年公布[6]。這個時程修訂過，動手前請到 Microsoft 365 系統管理中心的訊息中心再確認一次；與其到時候把基本驗證開回來，不如趁現在找出這些設備，改用 OAuth 或其他寄信方式。SCuBA 則要求直接停用 SMTP AUTH（MS.EXO.5.1v1）[2]。
Google Workspace：Google 已在 2025 年 3 月 14 日對所有 Google 帳號關閉「低安全性應用程式」，IMAP、POP、SMTP、CalDAV 與 CardDAV 不再接受只用密碼的基本驗證，必須改用 OAuth；唯一的例外是應用程式密碼，Google 也把設定應用程式密碼列為掃描器等設備的替代做法之一[7]。所以 Google 這邊的重點是盤點應用程式密碼，用不到的就刪除。SCuBA 另外要求停用 POP 與 IMAP 存取（GWS.GMAIL.9.1v1）[2]。
管理帳號：權限越小越好，再留兩個緊急帳號
為什麼：全域管理員或超級管理員帳號一旦被盜，整個租戶都在攻擊者手上。Google 提醒，超級管理員能管理帳戶的所有面向、存取所有企業與員工資料，因此只應在執行特定工作時登入、做完就登出，日常管理改用權限有限的管理員帳號[8]。
- 人數有上下限：SCuBA 要求全域管理員與 Google 超級管理員都維持 2 到 8 人，其他管理工作改用權限較細的角色（MS.AAD.7.1v1、MS.AAD.7.2v1、GWS.COMMONCONTROLS.6.2v1）[2]。Google 的小型企業安全檢查清單也建議增設第二位超級管理員，由另一個人管理，主要帳號遺失或遭入侵時才有備援[8]。
- 管理與日常分開：微軟建議管理員另設專用帳號，和平常收信、處理文件的帳號分開[3]；SCuBA 也要求特權帳號是只存在雲端的帳號，不從地端目錄同步（MS.AAD.7.3v1）[2]。
- 兩個緊急存取帳號（break-glass）：微軟建議建立兩個以上，用在管理員的 MFA 裝置全部無法使用、同盟身分服務中斷、最後一位全域管理員離職等情況[9]。這些帳號應是只存在雲端的
*.onmicrosoft.com帳號、指派全域管理員、不綁定特定員工；以通行金鑰（FIDO2）或憑證式驗證登入，而且和平常的管理帳號使用不同的驗證方式；排除在會封鎖或限制登入的條件式存取原則之外；安全金鑰等認證資訊分開存放在安全的地點；每次登入都要觸發警示，至少每 90 天實際測試一次[9]。
開啟 MFA、封鎖舊式驗證或新增條件式存取原則之前，先把緊急帳號建好；條件式存取原則可以先設為「僅限報告」（report-only），這類原則不會擋下登入[9]，確認影響範圍後再正式啟用。
信箱：自動轉寄、應用程式授權與郵件防護
關閉自動轉寄到外部
為什麼：攻擊者進入信箱後，常設定收件匣規則把信件自動轉寄出去，持續掌握往來內容，再找時機冒充寄出假的付款通知（見網路釣魚與商業郵件詐騙）。微軟也提醒，轉寄到外部的收件匣規則可能是使用者自己設的，也可能是帳號被盜的結果，外流的資訊可能被拿來攻擊公司或合作夥伴[10]。
Microsoft 365 在輸出垃圾郵件原則中控制自動轉寄，有三個選項；預設的 Automatic - System-controlled 在不同組織的實際效果可能不同，微軟建議明確設為 On 或 Off[10]。設為 Off 會讓所有轉寄到外部的收件匣規則與信箱轉寄失效，寄件者會收到 5.7.520 退信，內部之間的轉寄不受影響；確實有業務需要時，可以在原則中允許，再用遠端網域限制只能轉寄到哪些外部網域，兩邊設定衝突時通常是封鎖的一方生效[10]。SCuBA 同樣要求停用自動外部轉寄（MS.EXO.1.1v2）[2]。Google Workspace 的自動轉寄預設開啟，可以在管理控制台 Apps > Google Workspace > Gmail > End User Access 的 Automatic forwarding 關閉，或只允許轉寄到內部地址，也能依機構單位分別設定[11]。
限制使用者自行授權第三方應用程式
為什麼：惡意應用程式會設法誘騙使用者按下「同意」，藉此取得組織資料的存取權限[12]，這類手法常被稱為同意型釣魚（consent phishing）。
Microsoft Entra 預設允許所有使用者自行同意不需管理員同意的權限，例如讓應用程式存取自己的信箱；微軟建議只允許使用者同意「已驗證發行者」的應用程式，而且只限你歸類為低影響的權限，其他交給管理員審核，並可開啟管理員同意工作流程，讓使用者提出申請[12]。要注意，修改設定只影響之後的同意，已經核准的授權仍然有效，要另外清查[12]。SCuBA 要求只有管理員能註冊應用程式、限制使用者同意，並設定管理員同意流程（MS.AAD.5.1v1、5.2v1、5.3v1）[2]。
Google Workspace 在管理控制台 Security > Access and data control > API controls 設定。對尚未設定的第三方應用程式，預設是「允許使用者存取任何第三方應用程式」，這些應用程式可以要求不受限制的 Google 資料；可以改成只允許要求基本登入資訊（姓名、電子郵件、大頭貼）的應用程式，或在管理員設定之前一律不允許，並開放使用者提出存取申請[13]。SCuBA 要求不允許使用者存取未設定的第三方應用程式（GWS.COMMONCONTROLS.10.4v1）[2]。
打開內建的附件與連結防護
為什麼：釣魚信靠的就是惡意附件與連結。兩個平台都有內建掃描，但比較嚴格的設定要管理員主動開啟。
Microsoft 365 的預設安全性原則（preset security policies）把反垃圾郵件、反惡意程式與反釣魚設定打包成微軟的建議值：「標準」適合大多數使用者，「嚴格」給高價值目標或重點使用者，兩者都要管理員開啟並指派使用者才會生效[14]。Safe Links、Safe Attachments 與冒名防護屬於 Defender for Office 365，能不能用取決於你的方案；有這類授權的組織，「內建保護」原則預設會對所有收件者套用 Safe Links 與 Safe Attachments[14]。SCuBA 對 Microsoft 365 要求至少封鎖 .exe、.cmd、.vbe 這類可直接執行的附件，含惡意程式的郵件要隔離或丟棄（MS.SECURITYSUITE.1.1v1、1.3v1）[2]。
Google 的小型企業安全檢查清單建議開啟 Gmail 的強化傳遞前掃描，以及針對附件、連結與外部圖片的額外惡意檔案與連結檢查[8]；SCuBA 逐項列出要開的 Gmail 防護，例如防範來自不受信任寄件者的加密附件與含指令碼附件、辨識縮網址背後的實際連結、點擊不受信任網域的連結前顯示警告（GWS.GMAIL.5.1v1、5.2v1、6.1v1、6.3v1）[2]。防止別人冒用公司網域寄信則要靠 SPF、DKIM 與 DMARC，見SPF、DKIM、DMARC 部署指南。
檔案分享與稽核記錄
收緊外部分享的預設值
為什麼：「任何人」連結不需登入就能開啟，連結被轉傳之後，無法追蹤誰拿到、誰看過[15]。
SharePoint 與 OneDrive 的組織層級外部分享分四級：任何人（Anyone）、新的和現有的來賓、現有的來賓、只有組織中的人員；OneDrive 可以比 SharePoint 嚴格，但不能比它寬鬆，各網站的設定也只能等於或嚴於組織層級[15]。另外可以設定建立分享連結時的預設類型（特定人員、組織中的人員、任何人）、要求「任何人」連結在指定天數內到期或只能檢視，以及只允許或封鎖特定網域[15]。SCuBA 的要求是外部分享限於「現有的來賓」或「只有組織中的人員」、預設連結為「特定人員」且僅能檢視、「任何人」連結 30 天內到期（MS.SHAREPOINT.1.1v1、1.2v1、2.1v1、2.2v1、3.1v1）[2]。常和客戶交換檔案的中小企業不一定能關閉外部分享，但至少可以把預設連結改為「特定人員」，並替「任何人」連結設定到期日。
Google 的小型企業安全檢查清單建議關閉預設的連結分享，讓新檔案在建立者明確分享之前只有本人能開，並在使用者分享給公司外部的人時跳出警告[8]；SCuBA 進一步要求外部分享只限允許清單內的網域（GWS.DRIVEDOCS.1.1v1）[2]。
確認稽核記錄真的有在記
為什麼：帳號被盜之後要查攻擊者讀了什麼、改了什麼，靠的是稽核記錄；記錄沒開，事後就沒有東西可查。Microsoft 365 的稽核若是關閉的，在 Purview 搜尋稽核記錄不會有任何結果[16]。
微軟表示 Microsoft 365 組織的稽核記錄預設開啟，但 Microsoft 365 Business Basic、Business Standard、Business Premium 等中小企業授權，以及使用企業版免費試用的非受管租戶，預設沒有開啟，必須手動啟用[16]。確認方式是在 Exchange Online PowerShell 執行 Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled，結果為 True 才代表有開；一定要在 Exchange Online PowerShell 執行，在安全性與合規性 PowerShell 中這個值永遠顯示 False[16]。如果沒開，到 Microsoft Purview 入口網站的 Audit 頁面，點選 Start recording user and admin activity 橫幅即可，最多約 60 分鐘生效[16]。SCuBA 要求開啟統一稽核記錄與信箱稽核（MS.SECURITYSUITE.5.1v1、MS.EXO.13.1v1）[2]。
Google Workspace 的記錄事件在管理控制台 Reporting > Audit and investigation 查詢，不論使用者是哪一種版本都能搜尋；功能更多的安全性調查工具則只有特定版本才有[17]。也可以選擇把記錄事件分享到 Google Cloud，在 Cloud Logging 查詢並自行決定轉送與保存方式，可分享的資料類型依方案而定[17]。SCuBA 另要求開啟 Google 指定的系統定義警示規則（GWS.COMMONCONTROLS.13.1v1）[2]。雲端記錄各保存多久、該不該匯出到自己的儲存空間，見日誌該記什麼、要保存多久。
只有一個下午：先做這五件事
- 確認稽核記錄有開：Microsoft 365 用上面的指令檢查，使用中小企業方案的租戶尤其要確認。這一步不影響任何使用者，卻決定日後出事時查不查得到。
- 先準備好退路：Microsoft 365 建立兩個緊急存取帳號並綁好通行金鑰或安全金鑰；Google Workspace 確認至少有兩位超級管理員。後面每一項收緊登入的設定，都靠它們避免把自己鎖在門外。
- 讓所有人都有 MFA：沒有條件式存取授權的 Microsoft 365 租戶，直接開啟安全性預設值，同時封鎖舊式驗證；有授權的改用條件式存取。Google Workspace 先對管理員、財務與主管強制兩步驟驗證，再設定寬限期全面強制。開啟前先通知同仁。
- 關閉自動外部轉寄：Microsoft 365 的輸出垃圾郵件原則設為 Off；Google Workspace 關閉自動轉寄或限內部地址。真的有需要的帳號，問清楚原因後列冊開放。
- 收緊第三方應用程式授權：Microsoft Entra 改為只允許已驗證發行者與低影響權限，並開啟管理員同意流程；Google Workspace 把未設定的第三方應用程式改為只允許基本登入資訊或不允許。順手看一下目前已授權的應用程式清單。
剩下的時間或下一週：找出還用 SMTP AUTH 或應用程式密碼寄信的設備、收緊檔案分享預設值、開啟預設安全性原則與 Gmail 的進階防護，然後跑一次 ScubaGear 或 ScubaGoggles，把報告當成接下來的待辦清單。內部人力不足以消化報告時，可以考慮資安健診服務。
行動清單
- 下載最新版 ScubaGear 或 ScubaGoggles 跑一次，保存報告，作為改善前的基準。
- 確認 Microsoft 365 統一稽核記錄為
True；Google Workspace 確認管理員知道到哪裡查記錄事件，並規劃記錄匯出。 - 建立兩個 Microsoft 365 緊急存取帳號（通行金鑰登入、排除在封鎖型條件式存取原則之外、登入即警示），Google Workspace 至少兩位超級管理員；每 90 天測試一次。
- 全域管理員與超級管理員控制在 2 到 8 人，日常工作改用權限有限的帳號。
- 所有帳號強制 MFA，管理員優先改用通行金鑰或安全金鑰。
- 封鎖舊式驗證；列出還在用 SMTP AUTH 寄信的設備與系統，在 2026 年 12 月底前改用 OAuth 或其他方式；Google Workspace 用不到的應用程式密碼一律刪除。
- 關閉自動外部轉寄，例外列冊並定期檢討。
- 限制使用者自行授權第三方應用程式，並清查既有的授權。
- 外部分享的預設連結改為特定人員、僅能檢視，「任何人」連結設定到期日或停用。
- 開啟 Microsoft 365 預設安全性原則（全體至少「標準」，主管與財務用「嚴格」）與 Gmail 的強化掃描。
- 每季重跑一次檢測工具，並留意資安通報中與雲端帳號入侵相關的案例。