模組 1b — 賬戶管理與角色

目標： 以正確的方式組建你的管理團隊——恰當的角色、安全的成員新增方式、基於組的許可權，以及（面向較大組織的）組織（Organizations）——讓許可權做到最小化，且任何人都不會被鎖在門外。


👤 誰來做	賬戶所有者 / IT 管理員
⏱️ 用時	約 20 分鐘
🎯 完成後你將擁有	許可權恰當、職責分明的管理員，以及一份書面的應急（break-glass）方案
✋ 開始前	模組 1 已完成；你是已驗證郵箱的超級管理員

這是對模組 1 E 部分的可選深入。如果你只是單人團隊在評估，一個備用超級管理員就足夠了——需要正式鋪開時再回到這裡。

先理解訪問是如何運作的（務必先讀）

這裡有兩套獨立的許可權體系，混淆它們會造成絕大多數訪問困惑：

體系	控制什麼	在哪裡管理
賬戶角色	誰可以管理 Cloudflare（改設定、賬單、策略）	賬戶控制台 → Manage Account → Members
設備註冊許可權	哪些終端使用者可以連線裝置 / 向你的 Zero Trust 組織認證	Cloudflare One → Settings → WARP Client → Device enrollment permissions（模組 3）

💡 經驗法則： 管理員拿賬戶角色；使用服務的員工拿註冊許可權 + Access 策略。員工使用 WARP 或訪問應用不需要賬戶角色。

A 部分 — 選擇合適的角色

邀請某人時（B 部分），你會分配一個或多個角色。常見的賬戶級角色：

角色	能做	不能做	給誰
Super Administrator – All Privileges	一切：所有設定、採購、賬單、管理成員、建立賬戶級 API 令牌、撤銷其他超管	—	僅限 2–3 名可信負責人
Administrator	訪問整個賬戶、編輯訂閱/設定	管理成員、編輯賬單資料	日常平臺管理員
Administrator Read Only	只讀檢視整個賬戶	更改任何內容	審計、分析、NOC 檢視
Analytics	檢視分析資料	其他一切	報表相關方

資源級角色（範圍窄、最小許可權——適合委派單一事務）：

資源級角色	僅限訪問
Cloudflare Access Service Token Admin	某個特定的 Access 服務令牌
Access for Infrastructure Target Admin	某個特定的基礎設施（SSH/RDP）目標
Individual Cloudflare Tunnel instances	某個特定的 Cloudflare Tunnel
Individual Cloudflare Mesh nodes	某個特定的 Cloudflare Mesh 節點

⭐ 最佳實踐——最小許可權。 把超級管理員控制在少數幾人。給平臺工程師 Administrator，給審計人員 Administrator Read Only，當某人只需管理一個隧道或令牌時用資源級角色。

B 部分 — 新增成員（兩種方式）

你必須是已驗證郵箱的超級管理員才能新增成員。

方式 1 — 郵箱邀請（任何套餐可用）

👉 賬戶控制台（https://dash.cloudflare.com）→ Manage Account → Members。
👉 點選 Invite。
⌨️ 輸入一個或多個郵箱地址。
👉 界定其訪問範圍並選擇一個或多個角色（見 A 部分）。
👉 點選 Continue to summary → 核對 → Invite。
📺 對方在接受郵件邀請前顯示為 Pending。

💡 重發或撤銷： 開啟成員記錄 → Resend Invite（若仍待接受）或展開 → Revoke → 確認。

方式 2 — 直接新增（僅企業版）

如果對方已擁有 Cloudflare 賬戶且你在企業版，可無需郵件往返直接新增：

👉 Members → Invite → 輸入其郵箱。
👉 選擇 Direct Add → 分配角色 → 確認。對方立即獲得訪問權。

之後編輯或移除

更改角色： 開啟記錄 → Edit → 調整角色/範圍 → Continue to summary → Update。
移除某人： 展開其記錄 → Revoke → 確認。
移除你自己： Members → 你的記錄 → Leave。⚠️ 若你是唯一的超級管理員，請在離開之前先邀請另一位超管。

C 部分 — 使用者組（規模化管理許可權，避免重複）

不必逐個給成員分配相同角色，可以一次性建立一個使用者組並把人加進去。成員會繼承該組分配的所有角色（外加各自單獨分配的角色）。

👉 賬戶控制台 → Manage Account → Members → User groups（或 Account → Members 裡的 Groups 選項卡）。
👉 建立一個組，如 Security Admins，併為其分配應有的角色。
👉 將成員加入該組。

💡 提示： 使用者組讓入職/離職變得極簡——把某人加入或移出組即可，無需在賬戶裡逐條編輯角色分配。

D 部分 — 組織（企業 / MSSP / 分銷商）

如果你管理多個 Cloudflare 賬戶（擁有多個賬戶的大型企業，或託管服務提供商），**組織（Organizations）**位於賬戶之上：

初始使用者成為組織超級管理員（Organization Super Administrator）。
組織成員獲得隱式訪問——自動對組織內每個賬戶擁有超級管理員許可權，無需逐個新增。
任何組織超管都可新增/移除其他組織超管。
目前隱式訪問是全有或全無（沒有隻讀隱式訪問），且與已有的單賬戶成員身份相互獨立。

僅當你運營多個賬戶時才相關。單賬戶客戶可跳過。企業版與 MSSP/分銷商的差異詳見 Cloudflare 的 Organizations 文件。

E 部分 — 賬戶級 API 令牌（用於自動化）

當你用指令碼、Terraform 或 CI/CD 自動化 Cloudflare One 時，別把自動化繫結到某個人的登入。

👉 只有超級管理員能建立賬戶級 API 令牌。
👉 賬戶控制台 → Manage Account → API Tokens（賬戶級）→ Create Token。
👉 把令牌限定到所需的最小許可權（如為 IdP 自動化選 Access: Organizations, Identity Providers, and Groups — Edit）。

⚠️ 注意： 像對待密碼一樣對待令牌——存進金鑰管理器、設定有效期並定期輪換。優先用賬戶級令牌而非個人令牌，這樣某人離職後自動化仍能執行。

F 部分 — 記錄你的應急（break-glass）方案

把這份內容放進你的執行手冊 / 密碼保險庫：

應急（BREAK-GLASS）方案
[ ] 主超級管理員：  ____________________ （人）
[ ] 備用超級管理員：____________________ （人 或 受保護的共享郵箱）
[ ] 兩個賬戶都已開啟 2FA，且恢復碼已存入保險庫
[ ] 應急憑據存放位置：____________________ （保險庫位置）
[ ] Cloudflare IdP 上已啟用“Restrict to account members”
[ ] 每季度複查一次

⚠️ 注意： 如果你之後把管理控制台本身放到某個 Access 策略之後，務必確保你的應急身份始終能滿足該策略——否則一個錯誤策略會把所有人鎖在門外。

G 部分 — 保持監控（審計日誌）

賬戶變更（成員、設定）：賬戶控制台 → Manage Account → Audit Log。
Zero Trust 使用者活動與會話： Cloudflare One → Logs，以及 Insights → Dashboards（如 Network session analytics）用於流量可見性。

💡 提示： 任何管理變更後以及定期地複查審計日誌——這是發現異常許可權授予的最快方式。

✅ 模組 1b 完成！

你現在擁有：

✅ 按最小許可權分配角色的管理員（超管數量精簡）
✅ 一套可複用的成員新增方式（Invite 或 Direct Add）與規模化的使用者組
✅ 對**組織（Organizations）**的理解（若你運營多個賬戶）
✅ 用於自動化的賬戶級 API 令牌
✅ 一份書面應急方案，以及檢視審計日誌的位置

快速排障

問題	解決辦法
提示 “You must be a Super Administrator”	只有已驗證郵箱的超管能管理成員——先驗證郵箱或請現有超管操作
無法使用 Direct Add	它需要企業版且對方已有 Cloudflare 賬戶；否則用郵箱邀請
新管理員改不了設定	他可能是 Administrator Read Only 或某個資源級角色——編輯其角色（B 部分）
員工要“管理員角色”才能用 WARP	他不需要——終端使用者使用註冊許可權 + Access 策略，而非賬戶角色（見頂部“兩套體系”）

👉 下一步：模組 2 — 身份提供商

接入你的企業登入（Entra ID / Okta / Google），讓員工用現有企業身份登入。