員工共用帳號時：如何在不中斷共用工具的情況下完成離職交接

你的設計師提了離職。他有 Figma 帳號的存取權、Canva Pro 的訂閱、還有你們團隊透過 1Password 共用的 HubSpot 登入資訊。你把 Figma 密碼改了——結果另外三個設計師的工作階段全都被強制登出。你想移除 Canva 帳號——才發現這位設計師是帳單擁有者。HubSpot 密碼轉了，但他的瀏覽器工作階段還會繼續有效 90 天。共用帳號的離職交接，會在個人帳號交接不會出現的地方悄悄出錯，而大多數的離職指南根本沒有涵蓋這一塊。

為什麼共用帳號是新創公司特有的問題

大公司可以為每位員工的每項工具各開一個專屬帳號。但在 15 到 40 人的公司，這個算法行不通。Figma 每位設計師一個席位要 $15 美元／月——但當你有三個設計師因為「我們很少同時在編輯」而共用一個 $15 的席位，你就創造出了 HR 系統根本無法識別的共用憑證情境。同樣的事也發生在 Canva Pro、HubSpot Starter、Adobe Creative Cloud、SEO 工具，以及跟個人信箱綁定的帳單帳號上。共用帳號本來是實際可行的選擇，只有一個時機會出問題：當有人要離職的時候。

共用帳號的三種類型（各有不同的問題）

不同類型的共用帳號需要採取不同的離職交接措施。

類型一：共用憑證 — 一組登入資訊，多人知道密碼。這是最常見的模式：1Password 裡存的 Canva Pro 帳號、圖庫訂閱、你的營運主管和 CEO 都會用到的排程工具。離職員工知道密碼，解法聽起來很簡單——改密碼就好——但實際上不然，因為其他使用這組憑證的人必須「同時」更新自己儲存的副本，否則下次登入就會被鎖帳。

類型二：在共用工作空間中持有擁有者角色的個人帳號 — 這裡每個人有自己的登入帳號，但離職員工持有的擁有者或管理員角色讓他對整個團隊的工作有更高的控制權。設計師是 Figma 專案的擁有者。某人是 Notion 工作空間的管理員。開發者是 GitHub 組織的唯一 Owner。在未先轉移這些角色的情況下直接移除帳號，可能會讓整個團隊無法正常運作。

類型三：服務帳號或機器人帳號 — 與個人信箱綁定的帳單帳號、AWS 根帳號、網域registrar 登入、用於 API 金鑰或串接的帳號。這類帳號最危險，因為它們通常不在標準離職清單上。如果某位工程師把公司的 Cloudflare 帳號註冊在他個人的 Gmail 下，然後他要離職了，這是一場危機，不是一個清單項目。

為什麼光是改密碼還不夠

有人離職時的直覺反應是立刻改掉共用密碼。這個直覺是對的，但還不完整——而且如果做法錯了，反而會製造比解決更多的問題。

工作階段 Cookie 在密碼更改後仍然有效。 很多 SaaS 應用程式即使密碼被更換，現有的瀏覽器工作階段仍然保持有效。HubSpot、Notion 和 Canva 都會發出可持續 30 到 90 天的工作階段 Token。改密碼可以阻止未來的登入，但不會登出現有的工作階段。你必須明確撤銷所有活躍工作階段（大多數應用程式在安全性設定中都有「登出所有裝置」的按鈕）。

密碼管理員中儲存的副本不會自動更新。 如果有四個人各自把舊密碼存在他們的 1Password 個人保險箱裡，更換帳號密碼代表你需要這四個人在同一天更新他們儲存的憑證。只要有一個人沒更新，下次登入時就會被鎖帳——而如果他們用「忘記密碼」來復原，就會把密碼重設成只有他們知道的內容，讓其他人全都被鎖在外面。

擁有者角色在密碼更改後完全不受影響。 在類型二帳號中，離職員工的擁有者或管理員角色與共用密碼毫無關係。移除他們的帳號或更改密碼並不會轉移他們的擁有者角色，那是在應用程式內部的獨立步驟。這是最常見的失誤：公司撤銷了所有個人帳號的存取權、也更換了共用密碼，兩週後才發現離職設計師是三個 Figma 專案的唯一擁有者，沒有任何人能重新命名或刪除它們。

一個人在職期間累積的 SaaS 存取擴張 會讓情況更糟——他們可能被授予了你早就忘記的工具的存取權，而每一個都需要獨立的離職交接動作。

共用帳號離職交接的四步驟流程

按照順序執行這些步驟，順序很重要——在完成第二步之前先做第三步會讓你的團隊陷入麻煩。

第一步：在離職日期之前先做盤點，而不是事後。 在員工的最後一天之前，整理出他有存取權的每一個共用工具。查看你的密碼管理員，看他被授予了哪些共用憑證。確認哪些應用程式給予了他管理員或擁有者角色。這不是五分鐘能做完的事——預留 30 到 60 分鐘，並且讓他的直屬主管參與。目標是一份完整的清單，包含：(a) 他知道的共用憑證、(b) 他持有擁有者或管理員角色的應用程式，以及 (c) 任何與其身份綁定的服務帳號或帳單帳號。每季執行一次存取權盤點，可以讓這個步驟快很多，因為你已經有現成的清單。

第二步：在移除帳號之前先轉移擁有者角色。 對每一個類型二帳號，在停用他的帳號之前，先將他的擁有者或管理員角色轉移給另一位團隊成員。趁他還在職的時候做——讓他親自啟動轉移流程，遠比事後聯絡工具的客服團隊來恢復孤立資產容易得多。Figma、Notion、GitHub 和 Google Workspace 都支援在應用程式內部進行擁有者轉移，但前提是原始擁有者的帳號仍然有效。

第三步：同時更換共用憑證並更新所有副本。 選一個全員線上的時間點。在帳號中更換共用密碼，立刻在共用密碼管理員中更新憑證——在同一次操作中完成。通知所有使用該憑證的團隊成員，在下次登入前更新自己儲存的副本。這種緊密的協調，正是防止「有人用忘記密碼來復原存取，卻把所有人都鎖在外面」這種失敗模式的關鍵。

第四步：撤銷所有活躍工作階段。 更換密碼之後，進入每個應用程式的安全性設定，觸發「登出所有裝置」或「撤銷所有工作階段」。這是大多數離職清單都會漏掉的步驟。HubSpot：帳號設定 → 安全性 → 活躍工作階段。Notion：設定 → 我的帳號 → 登出所有裝置。Canva：帳號設定 → 安全性 → 活躍裝置。每個應用程式的操作路徑略有不同，但幾乎所有現代 SaaS 平台都有這個選項。

最關鍵的五個需要轉移擁有者的工具

這些是漏掉第二步會造成最大損害的工具。

Figma。 每個檔案、專案和團隊都有獨立於編輯者或檢視者存取權的「擁有者」角色。如果要離職的設計師擁有團隊專案，在他的帳號停用後，其他人將無法刪除、封存或移動那些專案。在停用帳號前先轉移檔案和專案的擁有權。付費方案可以在 Figma 的設定面板中完成這個操作；免費方案則需要由離職設計師本人主動發起轉移。

Notion。 工作空間「擁有者」（不只是一般成員）對串接、帳單和工作空間設定擁有更高的控制權。前擁有者無法遠端關閉工作空間，但如果沒有任何有效的擁有者，你在修改串接或帳單時會遇到阻礙。

GitHub。 這是風險最高的一個。GitHub 組織隨時至少需要一位 Owner。如果離職的工程師是唯一的組織 Owner，GitHub 將會阻止你移除他的帳號。在辦理離職前先新增第二位 Owner（最好是技術共同創辦人或 CTO）。同時也要確認：儲存庫管理員角色、分支保護規則的負責人，以及他授予的第三方 OAuth 應用程式存取——這些在帳號移除後依然存在。

Google Workspace。 你不能讓超級管理員人數歸零。在移除離職員工的帳號之前，先將另一位使用者指派為超級管理員。另外要確認：他擁有的 Google 群組（群組擁有權不會自動轉移）、他管理的共用雲端硬碟，以及他可能產生的服務帳號金鑰。

HubSpot。 「超級管理員」角色控制帳單、串接和使用者管理。如果離職的員工是你唯一的超級管理員，在重新指派之前，你將失去管理使用者和串接的能力。另外要確認：他擁有的工作流程、序列和報表——在他的帳號移除後這些不會中斷，但孤立的資產會越來越難管理。

共用帳號什麼時候是可以的（什麼時候不行）

不是每個共用帳號都需要走完整個流程。這裡有一個快速判斷依據：

風險較低的共用帳號： 唯讀的研究工具（Crunchbase、G2）、沒有客戶資料的圖庫訂閱、沒有生產環境存取權的訂閱整合工具。這些仍然需要在有人離職時更換密碼，但殘留工作階段的風險相對較低。

風險較高的共用帳號： 任何存有客戶資料的工具（HubSpot、Salesforce、Intercom）、任何對生產環境或程式碼有寫入存取權的工具（GitHub、AWS、Vercel）、任何該員工持有帳單或擁有者角色的工具，以及任何因工作階段持續有效而可能讓人在離職後進行資料匯出或刪除的帳號。這些都應該執行完整的四步驟流程。

根本的問題——人們累積了遠超過他們實際使用量的存取權——在HR 工具與 IT 工具之間的離職缺口中有更詳細的說明。共用帳號是最容易從這個缺口掉落的類別，因為 HR 軟體追蹤的是「這個人是員工」，IT 工具追蹤的是個人 SSO 登入——而在席位上限帳號中的共用憑證，兩者都不歸它管。

手動 vs. 自動化：流程看起來是什麼樣子

手動流程在 5 人公司可以運作。當公司有 20 到 40 人、每年都有人員異動，這個流程不是因為團隊不夠謹慎而失敗，而是因為根本沒有一個系統能把 HR 事件（這個人要離職了）連結到他的完整存取範圍。

常見問題

更改共用密碼後會立即讓離職員工登出嗎？ 不一定。密碼更改可以阻止未來的登入，但現有的瀏覽器工作階段通常在過期（通常是 30 到 90 天）或被明確撤銷之前仍然有效。更換共用密碼後，務必使用應用程式安全性設定中的「登出所有裝置」選項。

如果離職員工是某個關鍵工具的唯一擁有者，而且不配合怎麼辦？ 對於大多數 SaaS 工具，你可以攜帶業務擁有權的證明（帳單記錄、網域擁有權）聯絡客服來恢復管理員存取權。針對 GitHub，你可以提交類似 DMCA 的組織恢復申請。預防勝於補救：確保每個關鍵工具上始終至少有兩位擁有者。

我們應該完全停止使用共用帳號嗎？ 對於存有敏感資料或生產環境存取權的工具，是的——每人一個席位是值得的費用。對於低風險的唯讀工具，只要在每次離職時都有憑證更換流程，透過密碼管理員使用共用憑證是可以接受的。目標不是零共用帳號，而是清楚知道你有哪些共用帳號，並且對它們有流程可循。

我們如何追蹤哪些員工有共用帳號的存取權？ 最簡單的方式：維護一份共用帳號登記表——一份列出所有共用憑證、誰有存取權，以及上次更換時間的文件或試算表。在有人入職或離職時更新它。每季一次的存取審查是讓這份清單保持準確的好時機。

告別離職交接的混亂

Optserv 將 HR 事件——這個人要離職了——連結到他的完整存取範圍，包括共用帳號、擁有者角色和團隊憑證。當有人的離職被記錄下來，離職工作流程就會呈現他接觸過的所有共用憑證，並在一個流程中引導團隊完成更換、擁有者轉移和工作階段撤銷。在 app.optserv.ai 開始免費試用，讓下一次離職交接不再手忙腳亂。

參考資料

• Figma 說明中心 — 團隊權限與擁有者轉移：https://help.figma.com/hc/en-us/articles/360039970673-Team-permissions
• GitHub 文件 — 管理組織擁有者連續性：https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/maintaining-ownership-continuity-for-your-organization
• HubSpot 知識庫 — 使用者權限指南：https://knowledge.hubspot.com/user-management/hubspot-user-permissions-guide