SaaS 給不同公司用，帳號和資料權限怎麼寫？先把「公司邊界」寫進每一次操作

「每家公司都有自己的帳號，管理員可以管理公司成員。」

這句需求看起來完整，實際上還少了最重要的一層：系統怎麼知道某個人此刻代表哪家公司，以及他能對哪一筆資料做什麼。

多公司共用的 SaaS，不只是多一張公司資料表。需求至少要同時寫清楚公司邊界、使用者和公司的關係、角色、資料範圍與操作權限。否則畫面上的選單即使不同，API、匯出、背景工作或通知仍可能把資料送到錯的公司。

一、先定義 tenant，不要只寫「公司帳號」

在多租戶 SaaS 裡，tenant 是系統用來切開客戶資料與操作範圍的邊界。它可能是一家公司、一個品牌、一間分店或一個獨立事業單位，不能只看畫面上叫什麼名稱。

需求書先回答：

• 什麼單位算一個 tenant？
• 同一家公司能不能有多個 tenant？
• tenant 之間哪些資料絕對不能互相看到？
• 哪些資料可以共用，例如公開商品目錄或系統公告？
• tenant 停用或結束合作時，帳號與資料怎麼處理？

這個邊界如果沒有先決定，後面寫「管理員、主管、一般成員」都還不知道權限要套在哪一家公司。

二、帳號不要直接等於公司，要另外寫 membership

同一個人可能只屬於一家公司，也可能同時服務多家公司。若把使用者帳號直接綁死在一個 company_id，之後遇到顧問、會計師、集團主管或跨品牌營運人員，就容易用共用帳號、重複註冊或人工搬資料補洞。

比較清楚的需求模型是：

• user：這個人是誰；
• tenant：他要進入哪個公司空間；
• membership：這個人和該公司的關係；
• role：他在這家公司擁有什麼角色。

同一個 user 在 A 公司可以是管理員，在 B 公司可以只是檢視者。權限不是貼在這個人身上一輩子，而是跟著他在特定 tenant 的 membership 判斷。

三、用五欄權限矩陣取代「管理員什麼都能做」

角色名稱本身不夠驗收。建議把每一項重要操作拆成五欄：

例如，不要只寫「主管可以核准採購單」，而要寫成：

A 公司的採購主管，只能讀取 A 公司採購單；可以核准自己部門且未超過授權金額的採購單；不能核准自己建立的單據；不能匯出 B 公司資料。

這樣才能測試正常操作、越權操作與邊界條件。

要把這類權限與資料邊界寫進正式需求並實作，可以參考奧微軟體的系統開發服務，涵蓋後台、資料庫與權限控管。

四、前端切換公司不是權限控制

下拉選單顯示「目前公司」只是使用介面。真正的權限判斷必須由伺服器在每一次 request 重新確認：使用者是否仍屬於該 tenant、是否具備這個 action，以及 resource 是否真的屬於同一 tenant。

需求與驗收至少要包含：

• 修改網址或 request 裡的資料 ID，不能讀到別家公司資料；
• 隱藏按鈕後，直接呼叫 API 仍會被拒絕；
• tenant 停用、成員被移除或角色改變後，舊權限不再繼續生效；
• 預設沒有命中的權限規則時應拒絕，而不是放行；
• 後台、手機 App、批次工作與對外 API 使用相同邊界。

OWASP 建議預設拒絕，並在每一次 request 驗證權限。AWS 也特別提醒，身分驗證與一般授權不等於 tenant isolation；已登入的人仍必須被限制在正確的租戶資源內。

五、別漏掉畫面以外的資料出口

多租戶資料外洩不一定發生在列表頁。下列功能也要帶入相同的 tenant 與權限條件：

• CSV、Excel、PDF 匯出；
• Email、簡訊、推播與 webhook；
• 排程報表與背景工作；
• 搜尋索引、快取與檔案下載；
• 操作紀錄、客服代查與管理後台；
• 備份、還原與資料移轉。

需求不能只寫「可匯出報表」，而要寫誰可以匯出、匯出哪個 tenant、哪些欄位、是否需要二次確認，以及誰能查到這次操作。

六、公司管理員能管理到哪裡，也要有邊界

把成員管理交給客戶可以降低日常支援成本，但「公司管理員」不代表可以改所有事情。需求要分清楚：

• 邀請、停用與移除成員；
• 指派哪些角色；
• 是否可查看全部部門資料；
• 是否可匯出敏感資料；
• 是否可建立另一位管理員；
• 權限變更是否留下操作者、時間與前後差異。

若某些高風險權限只能由平台方處理，也應寫出申請、核准與撤銷流程，不要靠客服臨時判斷。

明示虛構教學例：同一位顧問服務兩家公司

以下是完全虛構的教學情境，不是客戶案例。

假設一套顧問專案 SaaS 同時服務甲公司與乙公司。王小姐受兩家公司邀請，用同一個 Email 登入。

在甲公司，她是專案管理員，可以建立專案、邀請成員與查看甲公司的所有任務；在乙公司，她只是外部顧問，只能更新被指派的工作，不能查看財務欄位或其他專案。

合理流程不是替她建立兩個共用密碼，也不是登入後把兩家公司資料混在同一張列表。系統應讓她明確選擇目前 tenant，畫面清楚顯示所在公司；每一次 API 操作都同時核對 membership、role、resource 與 action。

若她嘗試在乙公司網址放入甲公司的專案 ID，伺服器仍應拒絕。若甲公司移除她，她可以繼續使用乙公司的權限，但不能再進入甲公司。

反例：單一內部團隊，不一定需要完整多租戶模型

如果第一版只給同一家公司、同一權限體系的內部團隊使用，而且短期沒有對外提供服務的計畫，為未確定的多租戶情境一次做完整 tenant 切換、跨公司 membership 與複雜政策引擎，可能只是增加開發與測試成本。

但這不代表可以不寫權限。單一組織仍要定義角色、資料範圍與敏感操作。差別是先完成已知的邊界，並保留未來拆分 tenant 的資料設計空間，不把還沒成立的商業模式假裝成第一版需求。

可直接帶進需求書的驗收清單

1. tenant 的定義、建立、停用與資料保留規則；
2. user、tenant、membership 與 role 的關係；
3. 重要 resource 的讀取、建立、修改、刪除、核准與匯出矩陣；
4. 多公司使用者的選擇、切換與顯示方式；
5. 每一次 API、背景工作與資料出口的 tenant 檢查；
6. 成員移除、角色變更與權限撤銷的生效條件；
7. 越權測試、操作紀錄與客服代查邊界。

先把這七項寫清楚，再討論資料庫要共享、分開，或採用哪種授權技術。架構選擇應回應已確認的隔離與營運需求，不應反過來代替需求定義。

如果你的 SaaS 正準備開放多家公司使用，可以先整理一份 tenant、membership 與權限矩陣。奧微軟體可依已確認的流程、資料敏感度與整合邊界協助釐清系統方案；是否適合承作、範圍、時程與費用仍須另行評估。

資料來源與核對日期

• AWS Prescriptive Guidance, Multi-tenant SaaS authorization and API access control，核對日期：2026-09-20。
• AWS SaaS Architecture Fundamentals, Tenant isolation，核對日期：2026-09-20。
• OWASP Cheat Sheet Series, Authorization Cheat Sheet，核對日期：2026-09-20。
• Microsoft Azure Well-Architected Framework, Identity and access management for SaaS workloads，核對日期：2026-09-20。

作者：奧微軟體內容團隊。本文為一般 SaaS 需求與權限設計整理；奧微軟體開發企業社與軟體開發服務有商業關係，本文不構成特定架構、法規遵循、資安、時程、費用或成果承諾。