為什麼您的職場資料需要獨立的資料庫

當 IT 或資安團隊評估職場預訂工具時，問卷通常會問加密、單一登入和伺服器所在地。它很少問對這類資料最重要的那個問題：我們組織的資料是與其他所有客戶實體分離的，還是共用資料表裡的一個欄位？

工位預訂看起來像低風險資料，直到您列出它的內容：誰在哪一天出現在哪棟大樓、坐在哪張工位、旁邊是誰、帶了哪些訪客，以及車停在哪裡。這是您員工的移動紀錄。它值得您對人資或薪資資料所要求的同等隔離。

本文說明 SaaS 供應商儲存多租戶資料的兩種方式、為什麼 Desk & Park 為每個組織提供各自獨立的資料庫，以及這項決定對負責簽核安全、隱私與合規的人意味著什麼。

兩種架構，一個取捨

幾乎每一款 SaaS 產品都是多租戶的：一個應用程式服務許多客戶。問題在於客戶之間的邊界在哪裡。

共用資料庫，租戶欄位

常見的做法。每個客戶的資料列都放在相同的資料表裡，每一列帶有一個 tenant_id。每一個查詢都必須以它過濾。負責把客戶分開的是應用程式，而不是資料庫。

它之所以流行，是因為營運成本低：一個資料庫、一套結構描述、一次遷移。但它也是一整類資安事件的來源。在數千個查詢中只要有一個漏掉 WHERE tenant_id = ?、一份跨資料表 JOIN 卻沒帶過濾條件的報表、一個快取錯誤，客戶 A 就會看到客戶 B 的資料。這些錯誤不是假設；它們是已揭露的 SaaS 資料外洩中反覆出現的類別，而且很難找，因為每個查詢單獨看都是正確的。

每個組織一個獨立資料庫

每個客戶擁有自己的資料庫，有自己的資料表、自己的憑證和自己的備份。應用程式依據發出請求的組織連線到正確的資料庫。沒有會忘記加的 tenant_id 過濾條件，因為資料庫裡沒有其他租戶可以外洩。

這需要供應商付出更多營運紀律：佈建、遷移和監控數百或數千個資料庫，而不是一個。這個成本正是重點。它由供應商一次性地以工程投入支付，而不是由客戶日後以一次事故來支付。

Desk & Park 的架構

Desk & Park 採用每個組織一個資料庫的架構。具體來說：

• 控制平面只保存路由與計費所需的資料：組織名稱、方案、組織與其資料庫的對應關係，以及平台本身的稽核軌跡。它不包含任何預訂、樓層平面圖或員工目錄。
• 每個組織一個 PostgreSQL 資料庫，保存該組織的一切：使用者、角色、地點、地圖、工位、停車位、會議室、預訂、報到、訪客、通知，以及該組織的稽核日誌。
• 每個組織專屬的憑證。 應用程式以僅限該資料庫的憑證開啟組織資料庫的連線。來自組織 A 的請求即使出於錯誤也無法對組織 B 的資料庫執行，因為它從未持有連往那裡的連線。
• 每個組織獨立的備份、還原與刪除。 備份以資料庫為單位。把某個組織還原到昨天的狀態，不會影響任何其他人。合約結束時刪除一個組織，就是卸除它的資料庫——這是可驗證的完整刪除，而不是一句希望自己找齊了每一列的 DELETE WHERE tenant_id。

應用程式程式碼是共用的；資料不是。這就是稽核人員可以指著的邊界。

隔離為簽核者帶來什麼

對資安長：更小的影響範圍

多租戶查詢層的一個弱點會同時暴露所有客戶。有了隔離的資料庫，同一類錯誤無法跨越組織邊界，因為邊界是由資料庫引擎和連線憑證強制執行的，而不是應用程式邏輯。隔離不會讓應用程式對錯誤免疫；它讓某處的錯誤成為單一客戶的問題，而不是整個平台的問題。

對資料保護長：GDPR 問題的清楚答案

資料保護審查會問可預期的問題，而每個組織一個資料庫的架構讓這些問題有簡短的答案。

被遺忘權和限制處理的義務，成為範圍清楚的資料庫操作，而不是必須測試其完整性的應用程式功能。

對合規負責人：站得住腳的控制措施

ISO 27001 和 SOC 2 之類的框架要求供應商證明客戶之間的邏輯分離。「每個查詢都以租戶過濾」是一項每新增一個查詢就必須重新驗證的控制措施。「每個客戶都有自己的資料庫和憑證」則是一項在結構上驗證一次、隨產品成長依然成立的控制措施。第二種對供應商和客戶自身的稽核來說，都容易舉證得多。

對資訊長：可預期的效能與生命週期

一個組織的大型報表不會拖慢另一個組織早上的報到高峰，因為它們不共用資料表或索引。遷移以資料庫為單位逐一推出，所以問題可以在一個組織上被發現，然後才到下一個。客戶離場只是一次卸除，而不是一個清理專案。

安全故事的其餘部分

隔離是地基，不是整棟建築。IT 團隊期待的控制措施建立在其之上，值得逐一列出，因為好的架構配上薄弱的身分驗證仍然薄弱：

• 透過 OpenID Connect 的單一登入，串接您的身分提供者；以及 SCIM 佈建，讓新進與離職人員從您的目錄自動建立與停用，不必手動操作。
• 雙因素驗證（TOTP）與通行金鑰（WebAuthn），並可在組織層級強制要求 MFA。
• 每個組織的安全政策：工作階段逾時、密碼規則、IP 允許清單。
• 作用中工作階段管理，讓管理員可以檢視並撤銷工作階段。
• 每個組織的稽核日誌，記錄誰更改了什麼，存放在該組織自己的資料庫中。
• 透過 Stripe 付款，信用卡資料完全不會進入平台。
• 角色型存取控制：員工檢視與預訂；管理員設定；董事會成員和主管取得限於其團隊範圍的報表。

這些在企業級 SaaS 中都不算罕見。罕見的是把它們與一個客戶邊界是實體邊界的資料層結合起來。

該問任何職場軟體供應商的問題

如果您正在比較工具，這五個問題能區分行銷話術與真正的架構：

1. 我們的資料是在專屬資料庫裡，還是在帶有租戶欄位的共用資料表裡？
2. 備份、還原和刪除是以客戶為單位執行的嗎？
3. 應用程式用什麼憑證存取我們的資料？這些憑證是否僅限於我們？
4. 你們如何向稽核人員舉證客戶之間的分離？
5. 報表或匯出中的錯誤有沒有可能回傳另一個客戶的資料列？

擁有獨立資料庫的供應商可以各用一句話回答這五個問題。使用共用資料庫的供應商則必須描述一套測試流程。

隔離應該是預設值

職場資料是關於您員工實體出席的個人資料。對供應商來說最便宜的架構，是把這些資料放在其他所有客戶的資料旁邊，然後信任應用程式能把它們分開。Desk & Park 選擇了較昂貴的那一種，讓組織之間的邊界是一個資料庫，而不是一個過濾條件。

您可以在使用指南頁面的架構摘要和平台的隱私政策中閱讀技術細節。若要進行含單一登入、SCIM 與安全審查的企業導入，價格頁面上有 Enterprise 的聯絡方式。