部署 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 · 企業用已賺取薪酬提早支取方案