2026-06-12

權限矩陣實作：RBAC 在小型公民團體的落地方法

適用對象：組織管理者、顧問帶領情境

這篇要解決的問題是：組織裡「每個人好像都能看到所有東西」，但你不確定誰真的需要看什麼，也不知道要怎麼系統性地縮減存取範圍，而不造成日常工作的阻礙。

問題情境

你的 Google Drive 裡，所有資料夾都對組織全員開放。財務報表、人事資料、捐款人名冊，每個成員都能看到。不是因為你覺得這樣好，而是因為「限制權限很麻煩」，而且「大家都是自己人，應該沒關係」。

這種狀況在小型公民組織裡非常普遍。問題不是信任問題，而是：一旦任何一個人的帳號被入侵，攻擊者就能立刻存取所有資料。最小化每個帳號的存取範圍，可以大幅縮小單一帳號被接管後的影響範圍。

RBAC（Role-Based Access Control，角色型存取控制）是這個問題的標準解法。

核心觀念

RBAC 的核心邏輯

RBAC 的做法是：不把權限直接給「人」，而是給「角色」。每個人屬於一個或多個角色，透過角色取得對應的存取權限。

好處是：調職時只需要調整角色，不需要逐一修改每個資料夾的設定。離職時移除角色，所有關聯的存取自動失效。

三個基本要素

• 角色：對應組織內的職務或功能。例如：「執行長」、「財務」、「計畫人員」、「志工」。
• 資源：需要控管存取的資料或服務。例如：「財務資料夾」、「人事資料夾」、「活動資料」、「公開文件」。
• 操作：對資源可以做什麼。例如：「可以查看」、「可以編輯」、「可以管理（包含分享）」。

從現況出發，不從理想出發

很多組織在「設計完美的 RBAC 架構」這個目標上卡住，最後什麼都沒做。對小型組織來說，最小可行的 RBAC 是：把現有資源分成「敏感」和「一般」兩類，並確保敏感類資源只有需要的角色可以存取。

最小可行做法

1. 列出需要管控的資源清單：先把組織中最敏感的資料找出來。常見類別：財務（帳目、合約、薪資）、人事（成員資料、評核）、捐款人或服務對象資料、內部策略文件。不需要列出所有東西，先聚焦在「外洩後影響最大」的資源。
2. 定義 3 至 5 個角色：不要一開始就設計十幾個角色。對小型組織而言，3 至 5 個角色通常足夠覆蓋大多數情況。例如：「管理層」、「計畫執行」、「行政財務」、「外部協作者」。
3. 畫出權限矩陣：用一張表格，橫軸是角色，縱軸是資源，每個格子填入「可查看」、「可編輯」或「無權限」。這張表是後續設定的依據，也是稽核時的對照標準。
4. 在 Google Drive（或你使用的服務）上執行設定：把資料夾的共用設定從「組織全員」改為「特定群組」或「特定人員」，根據你畫出的權限矩陣執行。Google Workspace 的群組功能可以讓你建立對應角色的群組，之後只需管理群組成員，不需要逐一設定資料夾。
5. 記錄角色定義與對應的存取範圍：把角色定義和權限矩陣文件化，放在組織的內部文件庫，讓新加入的管理者可以參考。
6. 設定定期複審週期：每半年或每年複審一次權限矩陣，確認它反映的是目前的組織結構，而不是兩年前的狀況。

常見錯誤與風險邊界

• 角色設計過於精細：每個人都有自己的「客製化角色」，等於回到了直接給個人授權的狀態，失去了 RBAC 的管理優勢。角色應該對應職務類型，而不是個別人員。
• 臨時權限沒有設定期限：「先給他暫時的存取權限，做完再拿掉」，然後「再拿掉」這件事從來沒有發生。臨時存取應該設定明確的到期時間，或在專案結束後立刻移除。
• 只設定初始權限，從不複審：組織成員會異動，業務重點會改變，過去合理的權限可能已經不再適合。沒有複審機制，權限矩陣會隨時間偏離實際需求。
• 管理員帳號太多：每個人都有管理員權限等於沒有管理員權限。管理員數量應該最小化（通常 2 至 3 人即可），並確保管理員帳號有最強的 MFA 保護。
• 文件不更新：權限矩陣畫了但沒有人維護，實際設定和文件脫鉤後，下次稽核時還是要從頭重新盤點。

何時升級

• 組織使用多個不同服務，需要跨服務統一管理身分：評估身分提供者（IdP）方案（例如：Google Workspace 的群組、Microsoft Entra ID），讓一個角色設定同時管理多個服務的存取。
• 你需要存取行為的稽核日誌：知道「誰可以存取」之外，有時候需要知道「誰實際上存取了哪些資料」。這需要服務本身支援存取日誌，部分進階方案才提供。
• 你在處理個人資料，有個資法規遵循需求：存取控制和稽核紀錄的設計需要對應法規要求，建議尋求法律或資安顧問的協助。

參考文件

• 資料存取角色管理 — 組織資安指引
• 資料存取複審 — 組織資安指引