小編精選 - 技術文章翻譯 · 08月31日

我調查了透過 API 串接把資料傳到外部是否沒問題｜以 56 個業務系統檢視 OAuth、API 金鑰、儲存位置、停用方式【2026 年 8 月調查】

「把資料交給外部服務，真的沒問題嗎？」

只要在公司內談到系統串接，這個問題幾乎一定會出現。而且，這題很難回答。說「沒問題」沒有根據；說「有風險」又會讓話題直接停住。

問題在於，「安不安全」這個說法太模糊了。把它拆開問，就能回答。

我從官方資料逐一查了日本 56 件業務系統的認證方式、安全性說明、資料保存地點，以及解約時是否可匯出資料。

先講結論。

能從公開資料確認資料保存地點的有 56 件中的 41 件。15 件沒有寫。

認證方式有 48 件、安全性說明有 53 件、解約時是否可帶走資料有 49 件可以確認。

「沒有寫」和「有風險」是兩回事。 但若是在公司內被要求說明時回答不出來，從溝通上來說就是同一個問題。

1. 把「安不安全」拆成 4 個問題

把「安全嗎」拆成「對象、通道、存放處、停止使用時」4 個問題的圖

把模糊的不安，拆成可以提問的形式。

先具體問清楚到底在擔心什麼：

① 對象
這個服務可以讀到什麼、又可以改寫什麼？

② 通道
資料經過哪裡？有沒有加密？

③ 存放處
資料會存在哪個國家、哪個資料中心？

④ 停止使用時
能不能停用？資料能不能帶走？

拆成這 4 類後，就會變成供應商能回答的問題。「安不安全」本身沒辦法直接回答。

而且可能會讓人意外的是，④ 其實是最重要的判斷依據。 因為比起進去的時候，離開的時候更能看出差異。

2. ① 對象 — OAuth 是「入場證」

現代 Web API 廣泛使用的是 OAuth 2.0 這個機制。它由 RFC 6749 這份標準文件所定義。

2-1. 為什麼需要這個機制

對比直接把帳號密碼交給對方，與透過 OAuth 交付入場證的圖。前者無法限制範圍，後者可限定範圍與期限，且可撤銷

直觀來看，要讓外部服務串接，就得把帳號密碼告訴那個服務。這很危險，因為拿到的人幾乎什麼都能做。

OAuth 的做法是，不把密碼交出去，只給有限的權限。如果拿公司的建築物來比喻，它就像是櫃台發出的「入場證」。

OAuth 的用語用建築物來比喻
resource owner 建築物的擁有者（也就是你）
client 要進場工作的廠商
access token 入場證
scope 可進入的範圍（哪一層、哪一間）
expires_in / 有效期限 可使用到什麼時候
revoke / 失效 在櫃台讓這張入場證失效（其他入場證不受影響）

它有時也會被比喻成「萬能鑰匙」，但這個比喻其實不太對。萬能鑰匙是原鑰匙的複製品，和這個機制的本質相反。萬能鑰匙會打開原本鑰匙能打開的所有門，沒有期限，而且要失效只能整組鎖頭更換。OAuth 則正好相反——範圍有限、有期限，而且只要撤銷那一張就好。

在 RFC 6749 裡，授權存取受保護資源的主體稱為 resource owner；當這個主體是人時，則稱為 end-user。

也就是說，「資料屬於使用者」不是理念，而是標準規格中的用語定義。

所以以下這 4 題，完全是應該要問的問題：

「那個串接工具，可以讀到什麼？」

「可以改寫什麼？」

「這個存取權限有效到什麼時候？」

「如果要停用，要從哪裡撤銷？」

關於第 3 和第 4 點，補充精確一點。access token 本身的有效期限即使很短（例如 1 小時），很多實作仍會透過 refresh token 持續自動更新。 也就是說，以使用者的感受來看，常常不是「到期就結束」，而是「撤銷前會一直有效」。因此先確認第 4 點——從哪裡撤銷——很有意義。一般都是在各服務的串接應用程式管理畫面撤銷（規格中也有標準化的 token 失效機制 RFC 7009）。

另外，resource owner 是 OAuth 中表示授權主體的規格用語，不是用來定義法律上資料所有權的詞。這點要分清楚。

2-2. scope 實際上是這樣寫的

這聽起來可能很抽象，但其實都寫在 API 規格文件裡。

Money Forward Cloud Expense 的 API 規格定義了 6 種 scope。像 office_setting:write（管理事業者設定到員工設定）、user_setting:write（管理使用者自己的設定）這樣，可以做什麼、做到哪裡，都明確寫成 scope 名稱。

Money Forward Cloud Invoice 則有 mfc/invoice/data.read（讀取）與 mfc/invoice/data.write（更新）兩種。也就是可以選擇只給「只讀」權限。

導入串接工具時，只要問「會要求哪些 scope」就知道會把什麼權限交出去。

2-3. API key 不是入場證，而是萬用鑰匙

將 OAuth 比喻成櫃台發出的入場證，API key 比喻成門鎖複製出的萬用鑰匙，對比是否能限制範圍、是否能個別撤銷的圖

另一種方式是 API key。這種方式要特別注意。

API key 比較像是門鎖的複製品，也就是「萬用鑰匙」。只要持有一串字串（key）就能呼叫，所以基本上沒有範圍限制，也沒有期限。而且要讓它失效，只能「換鎖」——也就是重新發行 key，結果所有使用這把 key 的串接都會失效。 所以發放方式與保存方式就變成問題。

方式　比喻　交出去之後能做什麼
OAuth　入場證（櫃台發出）　可進入的範圍與期限都能控制，且可在櫃台立即失效；對方不會拿到密碼
API key　萬用鑰匙（門鎖的複製品）　基本上沒有範圍與期限；要失效只能換鎖，也就是所有使用這把 key 的串接都停掉

board 在這裡做了設計上的折衷。它必須同時使用兩種方式：① API key（每個帳號發行 1 個）＋② API token（可發行多個，且可指定每個 token 能使用哪些 endpoint）。雖然沒有 OAuth，但它讓權限可以以 token 為單位做範圍控制。

2-4. 56 件的認證方式

將主要系統的認證方式依官方資料記載逐一列出的圖

編輯部調查的範圍內，48 件可以確認認證方式的記載。

這裡補充一點用語。嚴格來說，OAuth 2.0 是「授權」（允許什麼）的框架，不是「認證」（確認本人身分）本身；認證通常是由 OpenID Connect 等其他機制負責。本文因為各家官方資料都以「認證方式」作為標題，所以統一用認證方式來說明。

主要方式如下。

系統　認證方式
freee 會計　OAuth 2.0（authorization_code）
Salesforce Sales Cloud　OAuth 2.0（註冊連接應用程式並走授權流程）
Google Workspace　OAuth（在 Google Cloud 專案中定義 scope，經使用者同意）
HubSpot　OAuth。多帳號可存取的應用程式與 Marketplace 上架應用程式必須使用 OAuth
kintone　密碼驗證／API token／session 驗證／OAuth 的4 種方式
board　API key＋API token併用必須
SmartHR　access token 方式

行政系統則是不同機制。e-Gov 電子申請有3 種帳號方式（e-Gov 帳號／GbizID／其他認證服務），而且依手續不同，有時還需要電子證明書。網站本身也說明，這相當於紙本手續中的印鑑與印鑑證明。

有趣的是 jGrants：申請補助金需要 GbizID，但只讀補助金資訊的公開 API 沒有寫明認證，實際上也能不用金鑰直接回應。 也就是說，它把「只讀」設計成對所有人開放。

3. ② 通道，以及 ③ 存放處

雲端、地端、與本機電腦三種情境下，伺服器所在地與員工電腦／手機之間連線關係的構成圖

3-1. 安全性說明有 53 件可以確認

加密、認證取得（如 ISMS）、防止未授權存取等說明，在 56 件中有 53 件能確認到。大多數服務都有提供某種說明。

不過，不能把「有認證」直接等同於「安全」。 ISMS（ISO/IEC 27001）只是認證「資訊安全管理制度已建立」，並不保證不會發生個別事故。請把它當作比較時的其中一個參考。

3-2. 資料保存地點有 15 件無法確認

從公開資料可讀出資料保存地點的是41件，無法讀出的是15件的堆疊長條圖

以某個日期為界，說明依註冊時間決定資料保存地，且之後不能變更的圖

這是本文的核心。能從公開資料確認資料會放在哪個國家、哪個資料中心的，有 56 件中的 41 件。

有寫清楚的例子如下。

系統　寫了什麼
kintone　日本國內資料中心（符合金融機構用 FISC 安全對策基準）。為因應東日本大災害，在西日本也做了備援
Money Forward Cloud Accounting　「伺服器設置於日本國內，並使用高可信度的雲端服務業者」
Zoho CRM　2022 年 2 月 10 日之後從日本註冊的帳號會使用日本資料中心（東京主站、大阪備援）。更早註冊的帳號仍留在美國，也就是保存地點由註冊時間決定，之後不能變更
Shopify　未明示資料中心國家或區域。隱私權政策則明白寫出「作為加拿大公司，會在全球處理資料，且可能會將個人資料傳送到美國等海外地區」

Zoho CRM 的例子特別實用。 就算問到「是在日本資料中心嗎」，答案仍會因為你的帳號是什麼時候建立的而不同。更重要的是，之後不能改。

至於沒有確認到的例子：

freee 會計：官方安全頁有寫加密、備份體制、TRUSTe 認證，但沒有明示保存國家
SmartHR：官方安全頁與 FAQ 都找不到保存地點的記載。不過它公開了供導入評估使用的「安全檢查表」，詳細內容要從那裡確認

正如 SmartHR 的例子所示，公開頁面沒寫，不代表藏起來。 有些資訊會另外放在給評估中的客戶看的資料裡。

所以問了才知道。 本文想表達的是，**「只看公開頁面看不出來，所以必須去問」**。

Salesforce Sales Cloud 也是一個比較微妙的例子。它的寫法是可透過 Hyperforce 選擇保存地，但該頁面明確列出的運作區域只有 EU 與瑞士，日本的處理方式並沒有在那裡寫清楚。

4. ④ 停止使用時 — 最容易分歧的地方

停止使用時要確認的4件事（能不能停用、能帶出什麼、到什麼時候、誰來刪除）的圖

解約時的處理方式在各產品之間完全相反的圖，從解約當天就有期限的例子到資料不會消失的例子一字排開

最後來看出口。49 件可以確認相關說明。

「解約後資料怎麼處理」，其實應該在導入前就先確認。

系統　解約時的處理
kintone　解約日翌日起 30 天後刪除資料。若在期間內重新簽約，可繼續使用
freee 會計　停止付款後，剩餘期間結束就會回到「未訂閱方案」＝資料不會刪除。重新訂閱付費方案後，可再次查看過去資料。退會分三階段（① 停止付款 ② 停止電子報 ③ 刪除事業所）
board　「不是所有登錄資料都能匯出，但主要資料可以用 CSV 匯出。」可隨時退會（沒有最低合約期間）
弥生　資料原本就保存在自己的電腦裡，不是解約後才會消失的雲端代管資料。帳簿與傳票可輸出成文字檔
SmartHR　只有在特定方案與付款方式下才能自行退會；其他情況需透過負責人或客服聊天

這 5 個的處理方式完全不同。

kintone 是30 天後刪除
freee 會計是不刪除（而是保留在未訂閱方案狀態）
board 很誠實地寫了「不是全部都能匯出」
弥生是資料本來就在本機
SmartHR 則是依方案不同，未必能自行退會

board 的寫法很誠實。 它直接寫明「主要資料可以匯出，但不是全部」，也把不能匯出的範圍說清楚。比起只寫「可以匯出」，這樣反而更能知道該確認什麼。

4-1. 把實際記載列出來

KING OF TIME — 截止日就是解約當天

解約日的隔天起，包含登入管理畫面在內的所有操作都不能使用，且「※資料的瀏覽與輸出也都不能進行」

也就是說，最後能把資料帶走的日期就是解約當天。 官方說明也明白寫著：「如果解約前需要資料，請事先將各產品資料匯出。」

光知道這一件，就足以理解為什麼要先看出口。 如果以為「解約後需要時再匯出就好」，那其實已經來不及了。

其他幾件的出口規則也都不同。

系統　官方寫了什麼
Garoon　30 天緩衝期：「解約日翌日起 30 天後將刪除資料」（cybozu.com 共通標準保存期間）。若在期間內重新簽約，可繼續使用
HubSpot　依方案而不同：Marketing Hub 付費方案在解約或到期後 30 天內，書面申請可提供暫時存取或副本；Smart CRM 與免費方案則不提供存取
Jotform　一鍵匯出 ZIP：從設定的 Data 分頁操作。表單 HTML、回應 CSV、上傳檔案會打包成一個 ZIP
Microsoft Forms　有兩種方式：「用 Excel 開啟」是附帶即時連線的版本（儲存在 OneDrive / SharePoint，新的回應會同步）；「下載副本」則是沒有連線的離線活頁簿
CLIUS　只寫「可以」：在轉換到其他診所系統時的資料輸出，FAQ 只明言「可以」。格式、費用、範圍都沒寫