從電商平台接連遭駭事件，看企業密鑰管理的重要性：我們需要更全面的數位密鑰安全

近期臺灣電商產業接連傳出資安事件，從 91APP、1shop、Cyberbiz、meepShop，到第三方 ERP 業者莫筆克科技（Mallbic），多起事件讓企業開始重新檢視第三方服務整合、API 存取及資料安全問題。

這些事件有一個值得企業特別關注的共同議題：當不同應用服務透過 API、資料庫連線及各種服務帳號交換資料時，這些用來驗證身分、授予權限及保護資料的密鑰，究竟由誰管理？

現代企業的應用架構早已不再是單一系統。從前端網站、ERP、CRM、資料庫、金流、物流，到雲端服務及第三方 SaaS，各個系統之間都有大量的通訊與資料交換。

企業即使已經部署防火牆、WAF、端點防護及 TLS 傳輸加密，如果應用程式使用的 API Token、資料庫密碼、Connection String 或加密金鑰仍散落在程式碼、設定檔及環境變數中，一旦其中一個系統遭到入侵，攻擊者仍可能利用已取得的合法存取資訊，進一步存取其他系統及敏感資料。

因此，企業資安不能只停留在數位憑證管理，而必須進一步建立完整的密鑰與 Secrets Management 機制。

一、臺灣電商產業接連傳出資安事件：第三方服務成為企業資安風險的重要環節

2026 年 10 月至 11 月初，臺灣多家電商技術服務業者陸續傳出資安事件及資料存取疑慮。從已公開的資訊來看，不同事件的攻擊途徑並不完全相同，但都凸顯了企業在第三方服務、應用程式權限及敏感資料管理上的挑戰。

1. 91APP：第三方工具漏洞遭利用，攻擊者取得資料庫存取金鑰

2026 年 10 月，91APP 公布旗下 Commerce Cloud 商務平台遭受網路攻擊，部分訂單資料遭到未經授權存取。

根據 91APP 於 10 月 22 日公布的事件調查報告，攻擊者利用內部第三方工具 Appsmith 未及時修補的漏洞，進入內部系統，後續再從 GitLab 取得一組資料庫存取金鑰，進而存取訂單資料庫。

這起事件有一個非常重要的技術細節：攻擊者並非只需要突破資料庫本身的驗證機制，而是透過入侵應用環境及取得既有的資料庫存取金鑰，使用系統原本具備的合法權限進行資料存取。

91APP 後續更換內部系統權杖、資料庫帳號及密碼，並重建 GitLab 權限，限制 CI 主機與資料庫網段之間的連線。

這個案例說明，即使企業已經具備漏洞管理與網路防護機制，若資料庫帳密及存取金鑰仍缺乏完善的集中管理與權限治理，仍可能成為攻擊者進一步取得資料的途徑。

2. 1shop：Mailgun API 金鑰疑似遭竊，訂單通知信可能被讀取

2026 年 10 月 30 日，電商服務業者 1shop 發布資安事件公告。

事件起因是部分消費者收到冒用訂單資訊的詐騙郵件，內容包含真實的消費者姓名、商品及訂單金額。

1shop 初步研判，第三方郵件服務 Mailgun 的 API 金鑰可能遭到他人取得，進而被用來讀取訂單成立通知信內容。

業者隨後更換相關 API 金鑰，停止保存訂單通知信內容，並加強異常存取防護。

這個案例顯示，API 金鑰並非只是系統串接時使用的一組技術參數。當它具有讀取郵件、訂單或其他敏感資料的權限時，其安全性就直接關係到消費者個資及企業營運。

3. Cyberbiz：多家品牌通報訂單資料異常存取

進入 11 月後，使用 Cyberbiz 服務的多家品牌陸續發布資安及防詐提醒。

相關公告提及部分商家訂單資料遭異常讀取，可能涉及會員資料安全疑慮。

由於事件資訊主要來自品牌公告及媒體查證，實際入侵途徑、資料存取方式及影響範圍仍須以業者後續調查結果為準。

這類事件也提醒企業，即使本身並未直接管理電商平台的底層基礎設施，仍必須了解委外服務商如何管理客戶資料、應用程式存取權限及相關機密資訊。

4. meepShop：部分商家訂單資料可能遭未授權取得

同一期間，使用 meepShop 的部分品牌也發布資安事件暨防詐騙提醒。

根據品牌商轉述平台提供的初步說明，部分訂單資料可能遭未經授權取得，涉及的資訊可能包括消費者姓名、聯絡電話、配送地址、電子郵件及訂單紀錄。

實際受影響資料範圍及數量仍待進一步確認。

此事件再次突顯，電商平台所管理的資料不只是平台本身的資產，也包含大量商家及消費者的敏感資訊。

5. 莫筆克科技（Mallbic）：ERP 系統遭駭，Shopline 更換相關 API Token

2026 年 11 月 4 日，iThome 報導電商 ERP 業者莫筆克科技發生資安事件。

莫筆克科技於 10 月 31 日發現主機異常，後續確認有主機曾遭未經授權執行惡意指令。攻擊者疑似透過品牌官網服務入口進入系統，可能影響的資料不僅限於品牌官網，也可能包含從其他電商平台匯入 ERP 的消費者個資及交易紀錄。

Shopline 在接獲相關通報後，於 11 月 3 日公告已完成相關資料盤查，並全面更換涉及該 ERP 服務的 API 串接金鑰，以降低未授權存取風險。

值得注意的是，這起事件的影響範圍可能跨越不同電商平台及銷售通路。當 ERP 同時整合多個平台，ERP 所持有的 API 存取權限便可能成為跨系統資料交換的重要入口。

從這些事件可以看出什麼？

上述事件的攻擊途徑並不相同：

91APP：第三方工具漏洞遭利用，進一步取得資料庫存取金鑰。
1shop：第三方郵件服務 API 金鑰疑似遭竊。
Cyberbiz、meepShop：部分品牌通報訂單資料異常存取或可能遭未授權取得，實際技術原因仍待釐清。
莫筆克科技：ERP 主機遭未授權執行惡意指令，Shopline 因應事件更換相關 API Token。

我們不應將所有事件都歸因於 API 金鑰外洩，但這些案例共同指出一個重要問題：

企業的資安防護不能只保護系統入口，也必須保護系統取得資料及執行操作時所使用的所有密鑰與存取憑證。

二、企業真正需要管理的是整個應用服務的密鑰，而不只是 SSL 憑證

談到企業憑證管理，許多 IT 人員首先想到的是 SSL/TLS 憑證，例如網站 HTTPS 憑證、企業內部 CA、Root CA、Intermediate CA，以及憑證簽發、更新、撤銷與私鑰管理。

這些確實是企業安全的重要基礎。

然而，現代應用系統的安全並不是只靠 SSL/TLS 憑證就能完成。

試想一個典型的企業應用架構：

使用者透過 HTTPS 存取前端網站。
前端應用程式透過 API 呼叫後端服務。
後端服務透過 Connection String 連接資料庫。
不同微服務之間透過服務帳號及 Token 進行身分驗證。
應用程式透過第三方 API 串接金流、物流及郵件服務。
系統使用加密金鑰保護資料庫、檔案及敏感欄位。

即使每一個網站都已經部署有效的 TLS 憑證，也不代表上述所有存取行為都已受到妥善保護。

例如：

TLS 憑證可以保護通訊過程，但不能阻止攻擊者利用已取得的 API Token 呼叫合法 API。
HTTPS 可以加密網路傳輸，但不能保證應用程式內部儲存的資料庫密碼不會外洩。
資料庫已啟用加密，也不代表連接資料庫的帳號具有適當的存取權限。
應用程式使用 OAuth 驗證，也不代表 Client Secret 與 Refresh Token 已受到完善管理。
資料已經加密，也不代表加密金鑰本身不會被未授權取得。

因此，企業必須從整體應用架構思考密鑰管理，而不是只將 CLM 視為 SSL 憑證到期提醒與更新平台。

企業應納入管理的密鑰與 Secrets

類型	使用情境	主要安全考量
TLS Certificate / Private Key	網站、伺服器及服務間通訊	憑證有效性、私鑰保護及輪替
API Key / API Token	第三方平台與服務串接	權限限制、輪替及撤銷
OAuth Client Secret	應用程式身分驗證	機密保管與更新
Access Token / Refresh Token	API 身分驗證與授權	有效期限、更新及撤銷
Database Credential	資料庫連線	最小權限、動態帳密及稽核
Connection String	應用程式連接資料庫或服務	避免帳密明文寫入設定檔
SSH Private Key	主機及系統遠端管理	私鑰保護、存取授權及輪替
Encryption Key	資料庫、檔案及欄位加密	金鑰保護、版本與輪替
Service Account Credential	微服務與系統間驗證	身分隔離及權限治理

這些資料在技術定義上並不完全相同，但都屬於企業必須保護的機密資產。

企業真正需要的是一套涵蓋憑證、密鑰、Token、帳密及應用服務存取資訊的統一管理機制。

三、HashiCorp Vault：整合密鑰管理、加密服務與動態憑證管理

HashiCorp Vault 的價值，不只是將 API Key 或資料庫密碼集中存放，而是透過不同的 Secrets Engine，提供企業儲存、產生、加密及管理機密資訊的能力。

這些功能可以依照企業應用架構的需求，整合成完整的密鑰管理體系。

1. KV Secrets Engine：集中保管 API Key、Token 及 Connection String

企業可以使用 Vault KV Secrets Engine 儲存各種靜態機密資訊，例如：

SHOPLINE API Token。
Mailgun API Key。
第三方金流及物流服務的 API Secret。
OAuth Client Secret。
資料庫帳號與密碼。
含有帳密的 Database Connection String。
應用程式及服務所需的其他敏感設定。

Vault 會在資料寫入儲存後端之前進行加密，避免後端儲存系統直接接觸明文 Secrets。

KV v2 也支援版本管理，企業可以追蹤不同版本的機密資訊，並依照權限政策控制讀取、更新及刪除。

更重要的是，應用程式不需要將所有 API Key 與資料庫密碼直接寫在程式碼或設定檔中，而是可以在執行時透過身分驗證向 Vault 取得所需的機密資料。

2. Dynamic Secrets：讓資料庫與服務憑證不再長期固定

這是 Vault 非常重要的能力，也是企業從傳統密鑰保管走向主動式安全管理的關鍵。

傳統應用程式常使用固定的資料庫帳號及密碼，這些帳密可能長期存在於程式碼、環境變數或 Connection String 中。

即使企業定期更換密碼，仍然必須處理所有使用該帳密的應用程式，容易產生維運負擔。

Vault Dynamic Secrets 採取不同的方式：

當應用程式需要連接資料庫時，先向 Vault 驗證自身身分，再依照授權政策取得專屬的動態資料庫帳號及密碼。

Vault Database Secrets Engine 可以依據設定的角色及權限，動態建立資料庫帳號，並透過 Lease 管理有效期限。

例如：

訂單服務取得一組專屬資料庫帳號。
報表服務取得另一組唯讀資料庫帳號。
每個服務使用不同的身分，避免共用同一組高權限帳密。
憑證到期後，由 Vault 執行支援的撤銷作業。
應用程式依需求更新 Lease 或重新申請憑證。

這種方式不只降低固定密碼長期存在的風險，也能讓企業在調查異常資料存取時，透過不同服務使用的資料庫帳號，追查可能涉及的應用程式。

3. API Secrets Management：管理第三方服務的存取憑證

以本次電商資安事件為例，企業可能同時使用多個電商平台、郵件服務、金流及物流 API。

這些服務通常需要 API Key、Access Token 或 Client Secret 才能進行資料交換。

Vault 可以集中管理這些憑證，透過 Policy 控制不同應用程式能夠取得哪些 Secrets。

例如：

訂單服務只能取得訂單系統所需的 API Token。
郵件服務只能取得 Mailgun 的相關 API Key。
金流服務只能取得金流 API 所需的 Secret。
不同商家的 ERP 工作程序只能存取各自授權的憑證。

當發生資安事件時，管理者可以依照事件影響範圍，找出相關 Secrets，調整存取權限，並透過外部服務支援的 API 進行憑證輪替或撤銷。

對於支援動態憑證的外部服務，也可以進一步整合 Vault Dynamic Secrets 或自訂 Secrets Engine，讓憑證的申請、更新及撤銷自動化。

必須注意，並非所有第三方 API 平台都支援動態簽發及撤銷 Token。對於只提供固定 API Key 的平台，仍需要由平台提供更新介面，或透過自動化程序配合 Vault 管理。

4. Transit Secrets Engine：將加密能力納入集中管理

除了存取憑證，企業還必須管理資料本身的加密金鑰。

Vault Transit Secrets Engine 提供 Encryption as a Service（加密即服務）能力。

應用程式可以透過 API 將需要加密的資料交給 Vault 處理，而不必自行持有及管理完整的加密金鑰。

Transit 可提供：

資料加密與解密。
金鑰版本管理及輪替。
數位簽章與驗證。
HMAC 與雜湊運算。
Data Key 產生。

例如，企業可以將客戶敏感資料交由應用程式呼叫 Vault Transit 加密，再將加密後的資料存入資料庫。

如此一來，資料儲存系統不需要直接持有 Transit 的主加密金鑰。

需要區分的是，Transit 負責的是資料加密相關的密碼學運算，不是取代 HTTPS、TLS 或網路傳輸加密協定。

5. PKI Secrets Engine：管理企業數位憑證與服務身分

Vault PKI Secrets Engine 可以動態簽發 X.509 憑證，支援企業建立內部 PKI，並透過較短的憑證有效期限及自動化流程，降低長期使用固定憑證的風險。

在微服務及容器化環境中，不同服務實例可以取得各自的服務憑證，減少共用私鑰所造成的風險。

企業也可以將 PKI 憑證生命週期管理與其他 Secrets 管理功能整合，讓服務間的身分驗證及存取控制更加完整。

四、從單一憑證管理，走向完整的應用服務密鑰治理

如果將上述功能放在同一個企業應用架構中，就能看出 Vault 的價值並不侷限於 SSL 憑證。

例如，一套電商系統可能包含以下安全需求：

應用場景	需要管理的安全資訊	Vault 對應能力
使用者連線網站	TLS 憑證與私鑰	PKI Secrets Engine
ERP 呼叫電商平台	API Token、Client Secret	KV / 整合式 Secrets Engine
ERP 連接資料庫	Database Account、Password	Database Secrets Engine
微服務之間通訊	Service Identity、X.509 Certificate	PKI / Auth Methods
儲存消費者敏感資料	Encryption Key	Transit Secrets Engine
應用程式讀取機密設定	API Key、Connection String	KV Secrets Engine
資安事件應變	憑證及 Secrets 撤銷、輪替	Lease / Revoke / Rotation

透過這種方式，企業可以逐步建立一致的管理流程：

Discover： 盤點系統中使用的憑證、API Key、資料庫帳密及加密金鑰。
Centralize： 將機密資訊集中至 Vault，避免散落於程式碼及設定檔。
Authenticate： 驗證應用程式及服務的身分。
Authorize： 依照最小權限原則，限制各服務可存取的 Secrets。
Rotate： 定期或依事件需求更新憑證及密鑰。
Revoke： 在服務異常或憑證遭竊時，撤銷支援撤銷機制的憑證。
Audit： 留存存取及管理紀錄，作為後續稽核與事件調查依據。

這才是完整的 Enterprise Secrets Lifecycle Management。

五、歐立威科技 Vault CLM：從 Certificate Lifecycle Management 延伸至 Enterprise Secrets Management

歐立威科技提供的 Vault CLM 整合方案，以 HashiCorp Vault 為核心，結合企業憑證生命週期管理及 Secrets Management 能力。

我們認為，企業憑證管理不應只停留在 SSL/TLS 憑證的簽發、更新與到期通知。

在現代應用架構中，企業需要管理的不只是伺服器憑證，還包含應用程式之間的通訊憑證、API 存取 Token、資料庫連線帳密、Connection String，以及保護敏感資料的加密金鑰。

Vault CLM 的整合方向，是讓企業能夠在一致的安全管理架構中，處理不同類型的憑證與機密資訊：

Certificate Lifecycle Management： 整合企業 PKI、數位憑證簽發、更新、撤銷及自動化部署。
API Secrets Management： 集中管理 API Key、Access Token、Refresh Token 及 OAuth Client Secret。
Database Secrets Management： 管理資料庫帳密、動態資料庫憑證及應用程式連線資訊。
Dynamic Secrets Management： 依照服務需求產生具有效期限的動態憑證，並管理 Lease、Renew 與 Revoke。
Encryption Key Management： 透過 Transit 提供集中式加密、解密及金鑰輪替能力。
Access Governance： 透過身分驗證、Policy 及稽核機制，管理應用程式與服務的存取權限。

其中，企業憑證管理介面及生命週期治理流程，搭配 Vault 本身的 Secrets Engine，讓管理者不只掌握憑證狀態，也能進一步管理應用服務所依賴的各類密鑰與存取資訊。

這代表企業可以從傳統的憑證管理，逐步邁向更完整的機密資訊與服務身分治理。

結語：應用系統的安全，取決於每一個存取環節是否受到妥善管理

從近期臺灣電商產業接連發生的資安事件可以看出，企業的資料安全邊界已經不再侷限於自己的資料中心。

每一個第三方服務、每一組 API Token、每一條資料庫連線，以及每一個應用程式所使用的加密金鑰，都可能成為企業資安架構中的重要環節。

企業不能只確保網站使用 HTTPS，也不能只確認 SSL 憑證尚未過期。

真正需要檢視的是：應用程式如何驗證身分？服務之間如何建立信任？API 存取權限是否受到限制？資料庫帳密是否長期固定？Connection String 是否含有明文密碼？加密金鑰由誰保管？當憑證遭到竊取時，能否快速撤銷及更新？

真正完整的企業密鑰管理，不只是保護憑證，更是管理整個應用服務架構中的信任、存取權限及加密機制。

歐立威科技透過 Vault CLM 整合方案，協助企業從傳統數位憑證管理，進一步延伸至 API Secrets、資料庫存取憑證、動態密鑰及資料加密管理。

讓企業不只是保護每一條通訊連線，更能掌握每一個應用程式、每一項服務及每一次資料存取背後的安全依據。