系統在跑,帳號在誰手上?一份數位資產所有權盤點清單
系統在跑,但您真的擁有它嗎?
您的官網正常運作、訂單系統每天進單、客服機器人回覆順暢——直到有一天,前一位外包工程師離職了、失聯了,您才發現一件事:網域登記在他的個人帳號、雲端主機是他的信用卡在扣款、資料庫管理介面的密碼只有他知道。
系統還在跑,但您不知道明年網域到期時會發生什麼事,也不確定哪天主機帳單沒繳會不會突然斷線。這種「能用但不在手上」的狀態,比系統當機更讓人焦慮。
這篇文章不談技術細節,而是從數位資產所有權的角度,幫您盤點關鍵帳號、判斷風險優先順序,以及在不影響系統運作的前提下,逐步收回控制權。
先盤點:哪些帳號決定您的系統生死
<cite index="21-1,21-20">數位資產盤點的第一步,是建立一份試算表,記錄每項資產的所有權、登入憑證與目前狀態。</cite>以下是中小企業最容易忽略、但影響最直接的五類帳號:
1. 網域名稱(Domain Name)
您的 .com.tw、.com 網址登記在誰名下?<cite index="4-10,4-13">網域所有權轉移分為兩種:registrar 之間的轉移(例如從 GoDaddy 轉到另一家),以及 registrant 之間的轉移(從個人名義轉到公司名義)。</cite>如果當初是外包商用他的帳號註冊,網域法律上不屬於您的公司。
2. 雲端主機與伺服器帳號
AWS、Google Cloud、Azure,或是台灣常見的 Linode、DigitalOcean、甚至虛擬主機商如 Bluehost——<cite index="11-6,11-7,11-8">主機商通常不會主動介入帳號所有權糾紛,而是要求客戶自行釐清並提供明確的所有權證明,以免自己承擔責任。</cite>
3. 資料庫管理帳號
MySQL、PostgreSQL、MongoDB 的 root 或 admin 帳號在誰手上?如果資料庫託管在 AWS RDS 或 Google Cloud SQL,那主帳號就更關鍵——它能直接刪除整個資料庫實例。
4. 第三方服務串接帳號
Stripe、綠界金流、LINE Official Account、Google Analytics、Facebook Business Manager——<cite index="21-18,21-19">這些帳號不只影響功能,還會直接影響企業估值。</cite>例如 Stripe 帳號掌握了您的金流、LINE 官方帳號握有客戶名單。
5. DNS 管理權限
網域可能在 A 註冊商,但 DNS 代管在 Cloudflare 或 AWS Route 53。如果 DNS 管理帳號在外包手上,他能瞬間把您的網站指向別的地方,或是直接讓網站消失。
盤點時,不只要列出「有哪些服務」,更要確認:
- 帳號是用誰的 email 註冊的?
- 付款方式是誰的信用卡或公司帳戶?
- 有沒有啟用雙重驗證(2FA),驗證碼會傳到誰的手機?
- 合約文件、授權書、發票是開給誰的?
如果這些問題的答案不是「公司」或「您本人」,那就是潛在風險點。
收回所有權:分階段、不中斷的安全路徑
發現帳號不在公司名下,不代表要立刻強硬收回——尤其當系統正在服務客戶時。以下是三階段建議:
第一階段:取得「備用管理員」權限
如果外包商還在合作、或願意配合,優先爭取的不是「移交所有權」,而是「新增一組公司自己的管理員帳號」。例如:
- 網域:在註冊商後台新增公司 email 為次要聯絡人
- 雲端主機:建立一組新的 IAM 使用者並賦予 admin 權限
- DNS:新增公司同仁為協作管理員
這個階段的目標是「能看、能改、能救」,而不是完全取代對方。這樣做有兩個好處:風險降低(萬一對方失聯,您還有備用鑰匙)、關係不撕破臉(對方還在幫忙維護時,不會因為感覺被「趕走」而消極配合)。
第二階段:正式轉移所有權
當系統穩定、交接文件完整,就可以啟動正式轉移。<cite index="4-1,4-2">轉移網域註冊商時,網域名稱本身不會改變,網站和 email 也不受影響——只是管理該網域的公司換了。</cite>
具體步驟因服務而異,但核心流程相似:
- 網域轉移:向原註冊商索取 EPP code(或稱 Auth Code),解除網域鎖定,在新註冊商發起轉入申請。通常需要 email 確認,整個流程約 5-7 天。
- 主機帳號:部分雲端服務商支援帳號所有權轉移(例如 AWS Organizations 可以跨帳號移動資源),但更常見的做法是「重新部署到新帳號」,再把舊帳號停掉。
- 第三方服務:例如 Stripe、LINE Official Account,通常可以在後台「轉移所有權」或「變更公司主體」,但需要提供公司證明文件(如營業登記證)。
這階段最容易出錯的是「DNS 更新時間差」:當網域轉到新註冊商、DNS 重新指向時,可能有數小時到 48 小時的傳播延遲。建議在離峰時段操作,並事先備妥回復計畫。
第三階段:建立「未來不再踩坑」的機制
收回一次不代表問題解決。真正的解法是建立制度:
- 統一數位資產登記名義:所有新服務一律用公司 email 註冊,付款用公司帳戶
- 定期盤點與續約提醒:每季檢查網域、SSL 憑證、雲端帳單的到期日,設定提前 30 天通知
- 交接清單制度化:未來任何外包合作,從一開始就在合約附件裡明列「哪些帳號必須登記在公司名下」、「交接時必須提供哪些憑證」
如果公司內部沒有技術人員能管理這些帳號,也可以考慮委託有 DevOps 或系統維運經驗的團隊代管,但帳號所有權仍應登記在公司名下,對方只是「受委任的管理員」。
最後提醒:這不是技術問題,是風險管理問題
很多老闆覺得「系統能動就好、帳號誰管無所謂」,直到某天想換廠商、或遇到糾紛,才發現自己沒有談判籌碼。<cite index="15-3">業界長期建議:把網域註冊商與主機商分開,避免單一廠商同時掌握兩者而形成挾持風險。</cite>
數位資產所有權不只關乎「能不能上線」,更關乎「能不能安全地繼續經營」。如果您現在手上有系統正在跑,但不確定關鍵帳號在誰手上,建議這週就花一小時把上面的盤點清單填完。
當您確認網域在自己名下、主機帳單是公司在付、資料庫備份能隨時取得,您才真正擁有這套系統——而不只是「租用」它的運作權而已。
如果盤點後發現狀況複雜、不知道該優先處理哪一項,或是想確認收回流程不會影響線上服務,歡迎透過免費健診服務讓我們協助您評估風險優先順序與安全轉移路徑。