部署 EWA 時的資料安全與隱私保護

為確保 EWA 資料安全，企業必須準確掌握哪些資料會被蒐集、用於何種目的、儲存在哪裡、誰有權存取、會分享給哪些對象，以及何時必須刪除。核心措施至少包括資料最小化、依角色分配權限、強化驗證、加密、金鑰與機密管理、防竄改日誌、異常監控、備份、安全測試、供應商管理與事件應變流程。資料安全不是單一功能，而是貫穿 EWA 整個生命週期的共同責任。

> 注意：這是一套供治理、技術與營運管理參考的框架。具體法律義務取決於各方角色、資料類型、處理目的、資料傳輸流程與實際部署模式。企業應由法務、資訊安全與人資部門共同審查後再採用。

> 術語說明：EWA（已賺取薪資的提前支取） · HRIS（人力資源資訊系統） · ERP（企業資源規劃） · payroll（薪資計算） · API（軟體連接介面） · SFTP（安全檔案傳輸） · token（取代原始資料的代碼） · MFA（多因素驗證） · OTP（一次性密碼） · idempotency（防止交易重複） · webhook/callback（系統間的自動通知） · log（日誌） · SOC（安全監控中心） · go-live（正式上線） · playbook（事件處理手冊） · OWASP ASVS/MASVS（Web／行動應用程式安全測試標準） · backup（備份）。

為什麼 EWA 資料需要高等級保護？

EWA – 已賺取薪資的提前支取 可讓勞工在固定發薪日前，提前取得一部分已經賺取的薪資。為判斷某人是否符合資格，以及還有多少可支取額度，系統通常需要串接多個資料領域：

• 身分識別資訊與在職狀態；

• 所屬單位、職位或薪資群組；

• 出勤資料與核准狀態；

• 薪資水準、薪資週期與部分調整項目；

• 收款帳戶或付款資訊；

• 申請紀錄、金額、時間與交易結果；

• 裝置資料、登入工作階段與用於防詐欺的日誌。

當這些資料被整合在一起時，可能相當詳細地描述個人的勞動關係與財務行為。一次安全事件不只可能造成資訊外洩，也可能導致帳戶遭接管、款項誤轉、額度計算錯誤、發薪中斷、爭議，以及勞工信任下降（另見 部署 EWA 時的風險）。

因此，正確的問題不只是「資料是否已加密」，而是：整套流程是否能防止未經授權的存取、資料被錯誤修改、偽造交易、重複付款，以及資料被用於不當目的？

1. 在選擇安全方案前先建立資料地圖

企業無法保護自己不知道存在於何處的資產。第一步，是從資料產生到刪除，建立完整的 EWA 資料流程圖。

每一條資料流程的紀錄都應能回答：

1. 傳輸的是哪些資料？

2. 資料用於什麼目的？

3. 哪個系統是標準資料來源？

4. 哪一方決定處理目的與處理方式？

5. 哪一方依協議執行處理？

6. 資料透過 API、檔案還是人工輸入傳輸？

7. 資料儲存在哪裡，以及保存多久？

8. 誰可以查看、修改、匯出或刪除？

9. 是否會將資料傳給次級供應商，或傳出既定範圍？

10. 當勞工離職或服務合約結束時，會發生什麼？

資料登錄表範例

以上範本僅作為設計框架。保存期限與分類等級應由企業根據法律依據、合約要求、對帳需求及實際風險評估決定。

2. 只蒐集真正必要的資料

資料最小化可以同時降低風險與保護成本。如果系統只需要知道員工目前在職以及所屬群組，就不一定需要複製完整的人事檔案。

企業應逐一檢視每個資料欄位，回答四個問題：

• 沒有這個欄位，EWA 是否仍能正確執行業務？

• 能否以參照代碼、token 或經遮罩處理的資料取代完整資料？

• 需要保存資料，還是只需在處理工作階段中使用？

• 能否降低資料詳細程度或縮短保存時間？

三種常用技術

資料遮罩：只顯示部分資訊，例如收款帳戶的末四碼。

Token 化：以參照代碼取代敏感資訊；完整資料只存在於負責處理的資料域中。

資料分離：如果沒有必要，不要將身分識別資料、帳戶資訊與交易紀錄儲存在同一張表，或賦予同一組存取權限。

資料最小化不代表資料不足以進行控管。系統仍需保留足夠的交易代碼、來源版本、時間戳記與日誌，以防止重複付款並支援對帳。

3. 明確劃分各方角色與責任

一套 EWA 計畫可能涉及雇主企業、EWA 供應商、基礎設施服務商、出勤系統、Payroll、銀行或付款夥伴。如果責任模糊，發生事件時很容易在各方之間互相推諉。

責任矩陣應明確規定：

這套矩陣必須依實際合約調整。不能把「委託供應商」理解為已將資料與資訊安全責任全部轉移出去。

4. 強化驗證，但不要增加勞工使用負擔

EWA 帳戶直接關係到收款能力，因此需要比單純閱讀資訊的帳戶更嚴格的保護。

對勞工

• 啟用帳戶時驗證身分；

• 採用與交易風險程度相符的驗證機制；

• 更換裝置、更換收款帳戶或出現異常行為時，要求加強驗證；

• 限制嘗試次數並偵測密碼試探；

• 不依賴容易猜測的安全問題；

• 新登入、重要資訊變更或交易發生時發送通知；

• 建立安全的帳戶復原流程，避免客服人員自行跳過驗證步驟。

對管理員與營運人員

• 強制使用多因素驗證；

• 優先採用集中式登入與獨立身分帳戶；

• 禁止共用管理員帳戶；

• 在適當情況下，依裝置、網路或風險條件限制登入；

• 對特殊任務提供有期限的權限；

• 完整記錄查看、修改、匯出資料及變更設定的操作。

密碼、OTP 與驗證資訊不得寫入日誌。客服人員也不得要求勞工再次讀出密碼或 OTP。

5. 依角色分配權限，遵循最小權限原則

存取權限應以工作任務為基礎，而不是單純依職位高低決定。

高風險操作應採用職務分離或雙重核准，例如：

• 變更收款帳戶；

• 解鎖疑似詐欺帳戶；

• 修改已完成的交易；

• 大量匯出資料；

• 變更額度規則；

• 授予管理權限；

• 刪除日誌或交易資料。

權限應定期審查，並在人員轉職、離職或不再負責相關任務時立即撤銷。

6. 資料加密與金鑰管理

資料在傳輸與儲存時都應加密，但只有「啟用加密」仍然不夠。

企業需要檢查：

• 應用程式、API、SFTP 與管理系統之間的連線是否加密；

• 資料庫、備份、檔案儲存區與日誌是否受到保護；

• 加密金鑰是否與資料分開儲存；

• 誰有權使用、輪替或撤銷金鑰；

• 是否記錄金鑰的存取活動；

• 金鑰遺失或外洩時如何處理；

• 匯出的 CSV／Excel 是否仍處於保護範圍之外。

API 金鑰、系統密碼與憑證應由專用的機密儲存庫管理。不要將機密放在原始碼、電子郵件、操作文件或廣泛共用的設定檔中。

7. 保護 API 與整合流程

出勤、Payroll、EWA 與付款系統之間的 API，是資料與業務指令（付款指令）的傳輸路徑（詳見 EWA 與出勤、Payroll 及 ERP 的整合）。重要控制措施包括：

• 驗證呼叫系統並依功能分配權限；

• 檢查輸入資料的結構、類型與大小限制；

• 限制頻率並偵測異常行為；

• API 版本與變更流程受控；

• 使用簽章或驗證機制保護 webhook／callback；

• 透過時間、nonce 或適當金鑰防止要求重放；

• 對建立交易的指令使用 idempotency_key；

• 使用 correlation_id 跨系統追蹤；

• 錯誤代碼清單不得洩漏內部細節；

• 控制 retry，尤其是在轉帳結果尚不明確時。

如果使用批次檔案，應管理獨立的 SFTP 帳戶，必要時對檔案加密，並控制 checksum、批次名稱、處理順序、重複紀錄、部分失敗檔案，以及檔案從中轉區刪除的期限。

OWASP Application Security Verification Standard 可作為建立與測試 Web 應用程式安全控制措施的框架。對行動應用程式而言，OWASP MASVS 則是針對驗證、儲存、網路、程式碼與隱私要求的專門參考標準。

8. 日誌必須足以調查，但不能變成新的外洩來源

日誌有助於偵測詐欺、處理申訴與追查事件。然而，如果日誌包含過多敏感資料，就會形成另一份難以控制的資料副本。

建議記錄

• 已受控的使用者代碼或管理員代碼；

• 操作與受影響的對象；

• 標準化時間與時區；

• 依政策記錄的位址或裝置特徵；

• 成功／失敗結果與原因代碼；

• transactionid、correlationid 與資料版本；

• 權限、設定、額度及收款帳戶的變更；

• 大量匯出資料的操作；

• 帳戶鎖定或異常偵測事件。

不應完整記錄

• 密碼、OTP 與存取金鑰；

• 完整帳戶號碼或完整身分證明文件資訊；

• 包含完整員工檔案的 request／response 內容；

• 尚未失效的工作階段 token；

• 不具監控或調查用途的資料。

重要日誌應防止未經授權的修改或刪除、同步時間、集中送往監控系統，並依情境設定警示。OWASP 強調，應用程式日誌應同時支援安全與營運目的，但日誌中的資料本身也必須受到保護。

9. 裝置、應用程式與登入工作階段管理

勞工可能使用個人手機、更換 SIM 卡或更換裝置。因此，系統需要在安全性與可使用性之間取得平衡。

以下情況應有獨立規則：

• 從新裝置登入；

• 更換電話號碼；

• 裝置已 root／jailbreak 或有遭到干預的跡象；

• 多個帳戶異常共用同一裝置；

• 同一帳戶在短時間內從多個位置登入；

• 剛更換收款資訊後立即提出收款要求；

• 登入工作階段持續過久或 token 被重複使用。

應用程式不應將明文敏感資料儲存在本機記憶體、剪貼簿、螢幕截圖或鎖定畫面通知中。登入工作階段應設定期限、可撤銷，並在敏感操作前要求重新驗證。

10. 在尊重隱私的前提下偵測詐欺

防詐欺可能需要分析裝置、行為與交易模式。然而，資料蒐集必須與明確目的、必要程度及具體保存期限相連結。

一些業務訊號可能包括：

• 變更收款帳戶後立即進行交易；

• 多次驗證失敗；

• 重複提出內容相似的要求；

• 交易超出額度規則；

• 交易前出勤資料出現異常修改；

• 同一帳戶被人工支援過多次；

• 管理員在非工作時間進行大量敏感變更。

不應只根據單一訊號就自動判定某人存在詐欺行為。系統需要風險評分、額外驗證步驟、例外處理機制，以及由有權限的人員進行審查的權利。所有自動化模型都應接受檢查，以避免因裝置資料、地區或使用條件不同，而錯誤阻擋某一群勞工。

11. 備份、可用性與復原能力

資料安全也包括可用性與完整性。一套系統即使沒有發生資料外洩，但如果遺失交易紀錄或在發薪週期停止運作，仍可能造成重大後果。

企業應要求：

• 依各類資料的重要程度進行備份；

• 對備份採取獨立加密與權限管理；

• 建立隔離副本，以降低勒索軟體造成的影響；

• 檢查實際復原能力，而不只是確認「備份成功」；

• 由雙方協議復原時間目標與可接受的資料遺失點；

• 為關鍵元件建立備援架構；

• 在 EWA 或付款管道中斷時提供替代營運流程；

• 系統復原後保留尚未確認結果的交易狀態。

在沒有實際測試數據與正式服務承諾前，不應以具體數字對外宣傳復原時間目標。

12. 供應商與供應鏈管理

EWA 供應商可能進一步使用雲端基礎設施、OTP 發送服務、監控服務、身分驗證服務或付款夥伴。企業需要知道資料會經過哪些對象，以及每一方的責任為何。

簽約前應提出的問題

（另見 EWA 供應商選擇檢查清單。）

1. 供應商確切處理哪些資料群組？

2. 資料與備份儲存在哪裡？

3. 是否有任何次級供應商可以接觸資料？

4. 更換次級供應商前是否有事先通知機制？

5. 供應商員工依什麼流程存取資料？

6. 是否具備加密、金鑰管理、MFA 與環境隔離？

7. 滲透測試的範圍與週期為何？

8. 漏洞如何分級與修復？

9. 事件通知時間與協調窗口為何？

10. 合約結束時，資料與副本如何返還或刪除？

11. 以何種證據證明刪除已完成？

12. 企業有哪些權利可以進行檢查、評估或取得獨立報告？

認證是一項有用的訊號，但不能取代對實際範圍的檢查。企業需要確認認證涵蓋哪些系統、哪些地點、哪些期間，以及是否包含正在使用的 EWA 平台。

13. 在正式上線前後進行安全測試

在正式推出前進行一次測試，並不足以覆蓋產品的整個生命週期（可搭配 90 天 EWA 試點計畫）。適當的方案可以包括：

• 審查架構與威脅模型；

• 檢查原始碼與相依套件；

• 掃描應用程式、伺服器與設定漏洞；

• 測試 API、Web 與行動應用程式；

• 依各角色測試權限控制；

• 測試帳戶復原流程；

• 測試防止重複交易與偽造 callback；

• 在正式上線前，以及重大變更後進行獨立滲透測試；

• 演練事件應變與復原；

• 持續追蹤修復，直到取得結案證據。

測試結果必須清楚區分嚴重缺陷、可暫時接受的缺陷，以及已由誰核准承擔的剩餘風險。如果測試範圍尚未涵蓋實際付款流程與整合流程，就不應僅因為「沒有發現嚴重問題」便將系統投入正式運作。

14. EWA 資料安全事件應變流程

發現異常跡象後，首要目標是在不破壞證據的情況下限制損害。

事件處理手冊應規定：

• 何謂事件，以及嚴重程度如何分級；

• 誰有權鎖定帳戶、停止 API 或暫停付款；

• 如何保存日誌、系統截圖與交易證據；

• 如何確認受影響的資料、使用者與時間範圍；

• 法務、人資、傳播、安全與供應商的聯絡窗口；

• 通知主管機關或受影響人員的依據、內容與時間；

• 重新開放服務的條件；

• 發生錯誤交易時支援勞工的方案；

• 根因報告與防止再次發生的措施。

法律通知期限應由法務團隊依事件類型與各方具體角色判定，不應對所有情況套用同一個時間數字。

15. 資料生命週期：從建立到安全刪除

每一類資料都需要獨立的保存計畫。「永久保存，以便日後查詢」通常會增加風險，卻不一定創造額外價值。

政策需要涵蓋：

• 主系統中正在使用的資料；

• 備份副本；

• 中轉檔案；

• 匯出至使用者電腦的資料；

• 應用程式日誌與安全日誌；

• 測試資料；

• 次級供應商處的資料；

• 支援工單與附件；

• 已離職人員的資料；

• 服務合約結束後的資料。

安全刪除需要具備刪除指令、執行日誌、副本處理方式與完成證據。在某些情況下，因法律義務、爭議處理或稽核要求，資料仍須繼續保存；此時應縮小存取權限並限制使用目的。

16. 越南法律框架需要注意的事項

截至本文編寫時，《個人資料保護法》第 91/2025/QH15 號於 2025 年 6 月 26 日公布，並自 2026 年 1 月 1 日起生效。第 356/2025/NĐ-CP 號法令於 2025 年 12 月 31 日發布，自 2026 年 1 月 1 日起生效，詳細規定法律的部分條款及執行措施。

此外，依業務流程不同，企業還需考慮 《電子交易法》第 20/2023/QH15 號（自 2024 年 7 月 1 日起生效）、第 52/2024/NĐ-CP 號關於非現金支付的法令及其他相關專業規定。

合規不應被簡化理解為多加一個「我同意」勾選框。企業需要正確確認各方角色、處理目的與法律依據、向勞工提供的資訊、資料分享範圍、保障資料主體權利的措施、必要性評估文件、安全措施及事件處理流程。具體法律結論必須建立在實際資料流程圖與部署合約的基礎上。

17. 核准 EWA 部署前的安全檢查清單

治理與法務

• [ ] 已指定 EWA 計畫負責人與資訊安全窗口。

• [ ] 已建立資料地圖，以及接收資料的系統／供應商清單。

• [ ] 已確認各方的角色、目的與資料處理責任。

• [ ] 已審查通知、條款與勞工行使權利的機制。

• [ ] 已為每類資料制定保存期限與刪除流程。

• [ ] 合約已規定事件、次級供應商、檢查與服務終止事項。

身分與權限

• [ ] 勞工在啟用帳戶及變更敏感資訊時均會接受驗證。

• [ ] 管理員必須使用 MFA 與獨立帳戶。

• [ ] 權限依角色、組織範圍與工作任務授予。

• [ ] 高風險操作具備雙重核准或職務分離。

• [ ] 權限定期審查，並於轉職／離職時撤銷。

資料與整合

• [ ] 只傳輸真正必要的資料欄位。

• [ ] 敏感資料可行時採用 token 化或遮罩。

• [ ] 連線與儲存資料均已加密。

• [ ] 金鑰與機密與原始碼分開管理。

• [ ] API／webhook 具備驗證、防重放與負載限制。

• [ ] 交易具備 idempotency 與跨系統追蹤能力。

應用程式與營運

• [ ] Web、API 與行動應用程式已在適當範圍內完成安全測試。

• [ ] 日誌記錄足夠事件，但不包含機密或完整敏感資料。

• [ ] 已建立監控、警示與明確的警示接收人。

• [ ] 備份受到保護，且已成功測試復原。

• [ ] 已針對帳戶接管、資料外洩與錯誤轉帳建立事件處理手冊。

• [ ] 已制定平台或付款中斷時的業務持續方案。

正式上線與部署後

• [ ] 所有嚴重問題均已修復並重新測試。

• [ ] 剩餘風險已由有權限的人員以書面方式接受。

• [ ] 已確認各方緊急聯絡清單。

• [ ] 勞工知道如何回報帳戶遺失或異常交易。

• [ ] 已建立權限、漏洞、供應商與警示成效的定期審查時程。

• [ ] 重大變更後已有測試證據。

結論

EWA 資料安全始於理解資料流程與責任，而不是從技術清單開始。一套值得信賴的方案必須限制資料蒐集、正確驗證身分、授予適當權限、保護 API 與交易、完整記錄日誌、控管供應商、在中斷時具備復原能力，並在發生事件時透明處理。

如果企業正在評估已賺取薪資提前支取方案，建議先準備系統架構圖、預計整合的資料群組與內部控制檢查清單，再進一步了解 企業用已賺取薪資提前支取方案，以便在開始試點前要求安全文件、整合文件與技術評估範圍。

參考資料

• 越南《個人資料保護法》第 91/2025/QH15 號

• 第 356/2025/NĐ-CP 號法令：個人資料保護法指導文件

• 越南《電子交易法》第 20/2023/QH15 號

• 第 52/2024/NĐ-CP 號非現金支付法令

• OWASP Application Security Verification Standard

• OWASP Mobile Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

作者：Nguyen Tan Loc — 策略部專員，Nhan Kiet Manpower Supply Co., Ltd.

企業已賺取薪資提前支取方案諮詢： Hotline 0937.022.655 · Email info@nhankiet.vn · 企業用已賺取薪資提前支取方案