Bảo mật dữ liệu và quyền riêng tư khi triển khai EWA

Để bảo mật dữ liệu EWA, doanh nghiệp cần biết chính xác dữ liệu nào được thu thập, dùng cho mục đích gì, nằm ở đâu, ai được quyền truy cập, chia sẻ cho bên nào và khi nào phải xóa. Các biện pháp cốt lõi gồm tối thiểu hóa dữ liệu, phân quyền theo vai trò, xác thực mạnh, mã hóa, quản lý khóa và bí mật, nhật ký chống sửa đổi, giám sát bất thường, sao lưu, kiểm thử bảo mật, quản lý nhà cung cấp và quy trình ứng phó sự cố. Bảo mật không phải một tính năng riêng lẻ mà là trách nhiệm chung trong toàn bộ vòng đời EWA.

> Lưu ý: Đây là khung tham khảo về quản trị, kỹ thuật và vận hành. Việc xác định nghĩa vụ pháp lý cụ thể phụ thuộc vai trò của từng bên, loại dữ liệu, mục đích xử lý, luồng chuyển dữ liệu và mô hình triển khai thực tế. Doanh nghiệp nên để bộ phận pháp lý, an toàn thông tin và nhân sự cùng rà soát trước khi áp dụng.

> Giải thích thuật ngữ: EWA (nhận lương theo ngày công đã làm) · HRIS (hệ thống thông tin nhân sự) · ERP (hoạch định nguồn lực doanh nghiệp) · payroll (tính lương) · API (giao diện kết nối phần mềm) · SFTP (truyền file bảo mật) · token (mã thay thế dữ liệu gốc) · MFA (xác thực đa yếu tố) · OTP (mã dùng một lần) · idempotency (chống lặp giao dịch) · webhook/callback (thông báo tự động giữa các hệ thống) · log (nhật ký) · SOC (trung tâm giám sát an ninh) · go-live (đưa vào vận hành chính thức) · playbook (cẩm nang xử lý sự cố) · OWASP ASVS/MASVS (bộ tiêu chuẩn kiểm thử bảo mật ứng dụng web/di động) · backup (sao lưu).

Vì sao dữ liệu EWA cần được bảo vệ ở mức cao?

EWA – Earned Wage Access – cho phép người lao động tiếp cận một phần tiền lương đã kiếm được trước ngày trả lương định kỳ. Để xác định một người có đủ điều kiện và còn bao nhiêu hạn mức, hệ thống thường phải kết nối nhiều miền dữ liệu:

• thông tin định danh và tình trạng làm việc;

• đơn vị, vị trí hoặc nhóm trả lương;

• dữ liệu chấm công và trạng thái duyệt;

• mức lương, kỳ lương và một số khoản điều chỉnh;

• tài khoản nhận tiền hoặc thông tin thanh toán;

• lịch sử yêu cầu, số tiền, thời điểm và kết quả giao dịch;

• dữ liệu thiết bị, phiên đăng nhập và nhật ký phục vụ chống gian lận.

Khi các dữ liệu này được ghép lại, chúng có thể mô tả tương đối chi tiết quan hệ lao động và hành vi tài chính của một cá nhân. Một sự cố không chỉ gây lộ thông tin mà còn có thể dẫn đến chiếm tài khoản, chuyển tiền sai người, tính sai hạn mức, gián đoạn trả lương, tranh chấp và suy giảm niềm tin của người lao động (xem thêm các rủi ro khi triển khai EWA).

Vì vậy, câu hỏi đúng không phải chỉ là “dữ liệu có được mã hóa không?”, mà là: toàn bộ quy trình có ngăn được truy cập trái phép, sửa sai dữ liệu, giao dịch giả, chi trả trùng và việc sử dụng dữ liệu sai mục đích hay không?

1. Lập bản đồ dữ liệu trước khi chọn giải pháp bảo mật

Doanh nghiệp không thể bảo vệ một tài sản mà mình chưa biết đang tồn tại ở đâu. Bước đầu tiên là lập bản đồ dữ liệu EWA từ lúc phát sinh đến khi xóa.

Với mỗi luồng, hồ sơ nên trả lời được:

1. Dữ liệu gì được truyền?

2. Dữ liệu phục vụ mục đích nào?

3. Hệ thống nào là nguồn dữ liệu chuẩn?

4. Bên nào quyết định mục đích và phương thức xử lý?

5. Bên nào thực hiện xử lý theo thỏa thuận?

6. Dữ liệu được truyền bằng API, file hay nhập thủ công?

7. Dữ liệu được lưu tại đâu và trong bao lâu?

8. Ai có thể xem, sửa, xuất hoặc xóa?

9. Có chuyển dữ liệu cho nhà cung cấp phụ hoặc ra ngoài phạm vi đã xác định không?

10. Điều gì xảy ra khi người lao động nghỉ việc hoặc hợp đồng dịch vụ kết thúc?

Mẫu sổ đăng ký dữ liệu

Mẫu trên chỉ là khung thiết kế. Thời hạn lưu và mức phân loại phải được doanh nghiệp xác định bằng căn cứ pháp lý, yêu cầu hợp đồng, nhu cầu đối soát và đánh giá rủi ro thực tế.

2. Chỉ thu thập dữ liệu thực sự cần thiết

Tối thiểu hóa dữ liệu làm giảm cả rủi ro lẫn chi phí bảo vệ. Nếu hệ thống chỉ cần biết nhân viên đang hoạt động và thuộc nhóm nào, không nhất thiết phải sao chép toàn bộ hồ sơ nhân sự.

Doanh nghiệp nên xem xét từng trường dữ liệu theo bốn câu hỏi:

• Không có trường này, EWA có thực hiện đúng nghiệp vụ không?

• Có thể thay dữ liệu đầy đủ bằng mã tham chiếu, token hoặc dữ liệu đã che bớt không?

• Có cần lưu lại, hay chỉ cần sử dụng trong phiên xử lý?

• Có thể giảm độ chi tiết hoặc rút ngắn thời gian lưu không?

Ba kỹ thuật thường dùng

Che giấu dữ liệu: chỉ hiển thị một phần, chẳng hạn bốn số cuối của tài khoản nhận tiền.

Token hóa: thay thông tin nhạy cảm bằng một mã tham chiếu; dữ liệu đầy đủ chỉ tồn tại trong miền có trách nhiệm xử lý.

Tách dữ liệu: không lưu hồ sơ định danh, thông tin tài khoản và lịch sử giao dịch trong cùng một bảng hoặc cùng một quyền truy cập nếu không cần thiết.

Tối thiểu hóa không có nghĩa là thiếu dữ liệu để kiểm soát. Hệ thống vẫn cần đủ mã giao dịch, phiên bản nguồn, mốc thời gian và nhật ký để chống chi trả trùng và phục vụ đối soát.

3. Phân định vai trò và trách nhiệm giữa các bên

Một chương trình EWA có thể liên quan đến doanh nghiệp sử dụng lao động, nhà cung cấp EWA, đơn vị hạ tầng, hệ thống chấm công, payroll, ngân hàng hoặc đối tác thanh toán. Nếu trách nhiệm mơ hồ, một sự cố dễ bị đẩy qua lại giữa các bên.

Ma trận trách nhiệm cần quy định rõ:

Ma trận này phải được điều chỉnh theo hợp đồng thực tế. Không nên xem việc “thuê nhà cung cấp” là đã chuyển hết trách nhiệm về dữ liệu và an toàn thông tin.

4. Xác thực mạnh nhưng không gây khó cho người lao động

Tài khoản EWA gắn trực tiếp với khả năng nhận tiền nên cần được bảo vệ chặt hơn một tài khoản chỉ dùng để đọc tin.

Với người lao động

• xác minh danh tính khi kích hoạt tài khoản;

• dùng cơ chế xác thực phù hợp với mức rủi ro của giao dịch;

• yêu cầu xác minh tăng cường khi đổi thiết bị, đổi tài khoản nhận tiền hoặc có hành vi bất thường;

• giới hạn số lần thử và phát hiện dò mã;

• không dựa vào câu hỏi bảo mật dễ đoán;

• thông báo khi có đăng nhập mới, thay đổi thông tin quan trọng hoặc giao dịch;

• có quy trình khôi phục tài khoản an toàn, tránh để nhân viên hỗ trợ tự ý bỏ qua bước xác minh.

Với quản trị viên và nhân sự vận hành

• bắt buộc xác thực đa yếu tố;

• ưu tiên đăng nhập tập trung và tài khoản định danh riêng;

• cấm dùng chung tài khoản quản trị;

• giới hạn đăng nhập theo thiết bị, mạng hoặc điều kiện rủi ro khi phù hợp;

• cấp quyền có thời hạn cho tác vụ đặc biệt;

• ghi nhận đầy đủ hành động xem, sửa, xuất dữ liệu và thay đổi cấu hình.

Mật khẩu, mã OTP và thông tin xác thực không được ghi vào log. Nhân viên hỗ trợ cũng không được yêu cầu người lao động đọc lại mật khẩu hoặc OTP.

5. Phân quyền theo vai trò và nguyên tắc quyền tối thiểu

Quyền truy cập cần dựa trên nhiệm vụ, không dựa đơn thuần vào chức danh cao hay thấp.

Các thao tác rủi ro cao nên áp dụng phân tách nhiệm vụ hoặc phê duyệt hai lớp, ví dụ:

• đổi tài khoản nhận tiền;

• mở khóa tài khoản có dấu hiệu gian lận;

• sửa giao dịch đã hoàn tất;

• xuất dữ liệu hàng loạt;

• thay đổi quy tắc hạn mức;

• cấp quyền quản trị;

• xóa log hoặc dữ liệu giao dịch.

Quyền cần được rà soát định kỳ và thu hồi ngay khi nhân sự chuyển vị trí, nghỉ việc hoặc không còn nhiệm vụ liên quan.

6. Mã hóa dữ liệu và quản lý khóa

Mã hóa cần được áp dụng cho dữ liệu khi truyền và khi lưu, nhưng chỉ “bật mã hóa” là chưa đủ.

Doanh nghiệp cần kiểm tra:

• kết nối giữa ứng dụng, API, SFTP và hệ thống quản trị có được mã hóa hay không;

• cơ sở dữ liệu, bản sao lưu, vùng lưu file và log có được bảo vệ hay không;

• khóa mã hóa được lưu tách khỏi dữ liệu hay không;

• ai có quyền sử dụng, luân chuyển hoặc thu hồi khóa;

• có ghi nhận hoạt động truy cập khóa hay không;

• mất khóa hoặc lộ khóa được xử lý như thế nào;

• dữ liệu xuất ra CSV/Excel có còn nằm ngoài vùng bảo vệ không.

Khóa API, mật khẩu hệ thống và chứng thư nên được quản lý trong kho bí mật chuyên dụng. Không đặt bí mật trong mã nguồn, email, tài liệu hướng dẫn hoặc file cấu hình được chia sẻ rộng rãi.

7. Bảo vệ API và luồng tích hợp

API giữa chấm công, payroll, EWA và thanh toán là đường đi của dữ liệu lẫn lệnh nghiệp vụ (chi tiết ở Tích hợp EWA với chấm công, payroll và ERP). Các kiểm soát quan trọng gồm:

• xác thực hệ thống gọi và phân quyền theo từng chức năng;

• kiểm tra cấu trúc, kiểu và giới hạn dữ liệu đầu vào;

• giới hạn tần suất và phát hiện hành vi bất thường;

• phiên bản API và quy trình thay đổi có kiểm soát;

• chữ ký hoặc cơ chế xác minh webhook/callback;

• chống phát lại yêu cầu bằng thời gian, nonce hoặc khóa phù hợp;

• idempotency_key cho lệnh tạo giao dịch;

• correlation_id để truy vết xuyên hệ thống;

• danh sách mã lỗi không làm lộ chi tiết nội bộ;

• kiểm soát việc retry, đặc biệt khi kết quả chuyển tiền chưa rõ.

Nếu dùng file batch, cần kiểm soát tài khoản SFTP riêng, mã hóa file khi cần, checksum, tên lô, thứ tự xử lý, bản ghi trùng, file lỗi một phần và thời hạn xóa file khỏi vùng trung chuyển.

OWASP Application Security Verification Standard có thể được dùng làm khung xây dựng và kiểm thử các kiểm soát bảo mật ứng dụng web. Với ứng dụng di động, OWASP MASVS là một tham chiếu chuyên biệt cho các yêu cầu xác thực, lưu trữ, mạng, mã và quyền riêng tư.

8. Nhật ký phải đủ điều tra nhưng không trở thành nguồn rò rỉ

Nhật ký giúp phát hiện gian lận, xử lý khiếu nại và truy nguyên sự cố. Tuy nhiên, log chứa quá nhiều dữ liệu nhạy cảm lại tạo thêm một bản sao khó kiểm soát.

Nên ghi nhận

• mã người dùng hoặc mã quản trị đã được kiểm soát;

• hành động và đối tượng bị tác động;

• thời điểm chuẩn hóa và múi giờ;

• địa chỉ hoặc dấu hiệu thiết bị theo chính sách;

• kết quả thành công/thất bại và mã lý do;

• transactionid, correlationid và phiên bản dữ liệu;

• thay đổi quyền, cấu hình, hạn mức và tài khoản nhận tiền;

• hành động xuất dữ liệu hàng loạt;

• sự kiện khóa tài khoản hoặc phát hiện bất thường.

Không nên ghi nguyên vẹn

• mật khẩu, OTP và khóa truy cập;

• số tài khoản hoặc giấy tờ định danh đầy đủ;

• nội dung request/response chứa toàn bộ hồ sơ nhân viên;

• token phiên chưa được vô hiệu hóa;

• dữ liệu không phục vụ mục đích giám sát hay điều tra.

Log quan trọng nên được bảo vệ khỏi sửa hoặc xóa trái phép, đồng bộ thời gian, gửi về hệ thống giám sát tập trung và có cảnh báo theo kịch bản. OWASP nhấn mạnh logging ứng dụng cần hỗ trợ cả mục đích bảo mật và vận hành, nhưng dữ liệu trong log cũng phải được bảo vệ.

9. Quản lý thiết bị, ứng dụng và phiên đăng nhập

Người lao động có thể dùng điện thoại cá nhân, đổi SIM hoặc đổi thiết bị. Vì vậy, hệ thống cần cân bằng giữa an toàn và khả năng tiếp cận.

Các tình huống nên có quy tắc riêng:

• đăng nhập từ thiết bị mới;

• đổi số điện thoại;

• thiết bị đã root/jailbreak hoặc có dấu hiệu can thiệp;

• nhiều tài khoản dùng cùng thiết bị bất thường;

• một tài khoản đăng nhập từ nhiều vị trí trong thời gian ngắn;

• yêu cầu nhận tiền ngay sau khi đổi thông tin nhận tiền;

• phiên đăng nhập kéo dài hoặc token bị sử dụng lại.

Ứng dụng không nên lưu dữ liệu nhạy cảm dạng rõ trong bộ nhớ cục bộ, clipboard, ảnh chụp màn hình hoặc thông báo khóa màn hình. Phiên đăng nhập cần có thời hạn, khả năng thu hồi và tái xác thực trước thao tác nhạy cảm.

10. Phát hiện gian lận mà vẫn tôn trọng quyền riêng tư

Chống gian lận có thể cần phân tích thiết bị, hành vi và mô hình giao dịch. Tuy nhiên, việc thu thập phải gắn với mục đích rõ ràng, mức cần thiết và thời hạn lưu cụ thể.

Một số tín hiệu nghiệp vụ có thể gồm:

• đổi tài khoản nhận tiền rồi giao dịch ngay;

• nhiều lần xác thực thất bại;

• yêu cầu lặp với nội dung tương tự;

• giao dịch vượt quy tắc hạn mức;

• dữ liệu công bị sửa bất thường trước giao dịch;

• một tài khoản được hỗ trợ thủ công quá nhiều lần;

• một quản trị viên thực hiện nhiều thay đổi nhạy cảm ngoài giờ.

Không nên tự động kết luận một người có gian lận chỉ từ một tín hiệu. Hệ thống cần điểm rủi ro, bước xác minh bổ sung, cơ chế xử lý ngoại lệ và quyền xem xét của người có thẩm quyền. Mọi mô hình tự động phải được kiểm tra để tránh chặn nhầm một nhóm người lao động do dữ liệu thiết bị, địa bàn hoặc điều kiện sử dụng khác nhau.

11. Sao lưu, tính sẵn sàng và khả năng phục hồi

Bảo mật còn bao gồm tính sẵn sàng và tính toàn vẹn. Một hệ thống không bị lộ dữ liệu nhưng làm mất lịch sử giao dịch hoặc ngừng hoạt động đúng kỳ lương vẫn gây hậu quả lớn.

Doanh nghiệp nên yêu cầu:

• sao lưu theo mức độ quan trọng của từng dữ liệu;

• mã hóa và phân quyền riêng cho bản sao lưu;

• bản sao tách biệt để hạn chế ảnh hưởng của mã độc tống tiền;

• kiểm tra khả năng khôi phục, không chỉ kiểm tra “backup thành công”;

• mục tiêu thời gian khôi phục và điểm mất dữ liệu được hai bên thống nhất;

• kiến trúc dự phòng cho các thành phần trọng yếu;

• quy trình vận hành thay thế khi EWA hoặc kênh thanh toán gián đoạn;

• bảo toàn trạng thái giao dịch chưa rõ kết quả sau khi hệ thống phục hồi.

Các mục tiêu thời gian không nên được quảng bá bằng con số khi chưa có đo kiểm và cam kết dịch vụ chính thức.

12. Quản lý nhà cung cấp và chuỗi cung ứng

Nhà cung cấp EWA có thể tiếp tục sử dụng hạ tầng đám mây, dịch vụ gửi OTP, giám sát, xác minh danh tính hoặc đối tác thanh toán. Doanh nghiệp cần biết dữ liệu đi qua những bên nào và trách nhiệm mỗi bên ra sao.

Câu hỏi cần đặt trước khi ký hợp đồng

(Xem thêm bộ tiêu chí đầy đủ ở Checklist lựa chọn nhà cung cấp EWA.)

1. Nhà cung cấp xử lý chính xác những nhóm dữ liệu nào?

2. Dữ liệu và bản sao lưu được lưu ở đâu?

3. Có nhà cung cấp phụ nào được tiếp cận dữ liệu?

4. Có cơ chế thông báo trước khi thay đổi nhà cung cấp phụ không?

5. Nhân viên của nhà cung cấp truy cập dữ liệu theo quy trình nào?

6. Có mã hóa, quản lý khóa, MFA và phân tách môi trường không?

7. Kiểm thử xâm nhập được thực hiện với phạm vi và chu kỳ nào?

8. Lỗ hổng được phân loại và khắc phục ra sao?

9. Thời gian thông báo sự cố và đầu mối phối hợp là gì?

10. Khi kết thúc hợp đồng, dữ liệu và bản sao được trả lại hoặc xóa như thế nào?

11. Bằng chứng nào chứng minh việc xóa hoàn tất?

12. Quyền kiểm tra, đánh giá hoặc nhận báo cáo độc lập của doanh nghiệp ra sao?

Chứng nhận là một tín hiệu hữu ích nhưng không thay thế việc kiểm tra đúng phạm vi. Doanh nghiệp cần xem chứng nhận bao phủ hệ thống nào, địa điểm nào, thời hạn nào và có bao gồm nền tảng EWA đang sử dụng hay không.

13. Kiểm thử bảo mật trước và sau go-live

Một lần kiểm thử trước khi ra mắt không đủ cho toàn bộ vòng đời sản phẩm (gắn với kế hoạch pilot EWA 90 ngày). Chương trình phù hợp có thể gồm:

• rà soát kiến trúc và mô hình đe dọa;

• kiểm tra mã nguồn và thư viện phụ thuộc;

• quét lỗ hổng ứng dụng, máy chủ và cấu hình;

• kiểm thử API, web và ứng dụng di động;

• kiểm thử phân quyền theo từng vai trò;

• kiểm thử quy trình khôi phục tài khoản;

• kiểm thử chống giao dịch lặp và callback giả;

• kiểm thử xâm nhập độc lập trước go-live và sau thay đổi lớn;

• diễn tập ứng phó sự cố và khôi phục;

• theo dõi khắc phục đến khi có bằng chứng đóng lỗi.

Kết quả kiểm thử phải phân biệt rõ lỗi nghiêm trọng, lỗi có thể chấp nhận tạm thời và rủi ro còn lại đã được ai phê duyệt. Không nên đưa hệ thống vào vận hành chỉ vì “không tìm thấy lỗi nghiêm trọng” nếu phạm vi kiểm thử chưa bao gồm luồng thanh toán và tích hợp thực tế.

14. Quy trình ứng phó sự cố dữ liệu EWA

Khi phát hiện dấu hiệu bất thường, mục tiêu đầu tiên là hạn chế thiệt hại mà không làm mất bằng chứng.

Playbook nên quy định:

• thế nào là sự cố và mức độ nghiêm trọng;

• ai có quyền khóa tài khoản, dừng API hoặc tạm ngừng chi trả;

• cách bảo toàn log, ảnh chụp hệ thống và bằng chứng giao dịch;

• cách xác định dữ liệu, người dùng và thời gian bị ảnh hưởng;

• đầu mối pháp lý, nhân sự, truyền thông, bảo mật và nhà cung cấp;

• căn cứ, nội dung và thời điểm thông báo cho cơ quan có thẩm quyền hoặc người bị ảnh hưởng;

• tiêu chí mở lại dịch vụ;

• phương án hỗ trợ người lao động nếu có giao dịch sai;

• báo cáo nguyên nhân gốc và hành động ngăn tái diễn.

Thời hạn thông báo pháp lý phải được đội pháp lý xác định theo loại sự cố và vai trò cụ thể của từng bên, không nên áp dụng một con số chung cho mọi tình huống.

15. Vòng đời dữ liệu: từ tạo mới đến xóa an toàn

Mỗi nhóm dữ liệu cần một lịch lưu trữ riêng. “Lưu vĩnh viễn để khi cần tra cứu” thường làm tăng rủi ro mà không tạo thêm giá trị.

Chính sách cần bao phủ:

• dữ liệu đang dùng trong hệ thống chính;

• bản sao lưu;

• file trung chuyển;

• dữ liệu xuất ra máy người dùng;

• log ứng dụng và log bảo mật;

• dữ liệu thử nghiệm;

• dữ liệu tại nhà cung cấp phụ;

• ticket hỗ trợ và tệp đính kèm;

• dữ liệu của người đã nghỉ việc;

• dữ liệu sau khi hợp đồng dịch vụ kết thúc.

Xóa an toàn cần có lệnh xóa, nhật ký thực hiện, xử lý bản sao và bằng chứng hoàn tất. Trong một số trường hợp, dữ liệu phải tiếp tục được lưu vì nghĩa vụ pháp lý, giải quyết tranh chấp hoặc yêu cầu kiểm toán; khi đó quyền truy cập nên được thu hẹp và mục đích sử dụng bị giới hạn.

16. Khung pháp lý Việt Nam cần lưu ý

Tính đến thời điểm bài viết được biên soạn, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 được ban hành ngày 26/6/2025 và có hiệu lực từ ngày 1/1/2026. Nghị định 356/2025/NĐ-CP, ban hành ngày 31/12/2025 và có hiệu lực từ ngày 1/1/2026, quy định chi tiết một số điều và biện pháp thi hành Luật.

Ngoài ra, tùy luồng nghiệp vụ, doanh nghiệp cần xem xét Luật Giao dịch điện tử số 20/2023/QH15, có hiệu lực từ ngày 1/7/2024; Nghị định 52/2024/NĐ-CP về thanh toán không dùng tiền mặt và các quy định chuyên ngành liên quan.

Việc tuân thủ không nên được hiểu đơn giản là thêm một ô “Tôi đồng ý”. Doanh nghiệp cần xác định đúng vai trò của các bên, mục đích và căn cứ xử lý, thông tin cung cấp cho người lao động, phạm vi chia sẻ, bảo đảm quyền của chủ thể dữ liệu, hồ sơ đánh giá cần thiết, biện pháp bảo vệ và quy trình xử lý sự cố. Những kết luận pháp lý cụ thể phải dựa trên sơ đồ dữ liệu và hợp đồng triển khai thực tế.

17. Checklist bảo mật trước khi phê duyệt triển khai EWA

Quản trị và pháp lý

• [ ] Có chủ sở hữu chương trình EWA và đầu mối an toàn thông tin.

• [ ] Có bản đồ dữ liệu và danh sách hệ thống/nhà cung cấp nhận dữ liệu.

• [ ] Đã xác định vai trò, mục đích và trách nhiệm xử lý của các bên.

• [ ] Thông báo, điều khoản và cơ chế thực hiện quyền của người lao động đã được rà soát.

• [ ] Có thời hạn lưu và quy trình xóa cho từng nhóm dữ liệu.

• [ ] Hợp đồng quy định sự cố, nhà cung cấp phụ, kiểm tra và kết thúc dịch vụ.

Danh tính và phân quyền

• [ ] Người lao động được xác minh khi kích hoạt và khi thay đổi thông tin nhạy cảm.

• [ ] Quản trị viên bắt buộc dùng MFA và tài khoản riêng.

• [ ] Quyền được cấp theo vai trò, phạm vi tổ chức và nhiệm vụ.

• [ ] Thao tác rủi ro cao có phê duyệt hai lớp hoặc phân tách nhiệm vụ.

• [ ] Quyền được rà soát định kỳ và thu hồi khi chuyển việc/nghỉ việc.

Dữ liệu và tích hợp

• [ ] Chỉ truyền các trường thực sự cần thiết.

• [ ] Dữ liệu nhạy cảm được token hóa hoặc che bớt khi có thể.

• [ ] Kết nối và dữ liệu lưu trữ được mã hóa.

• [ ] Khóa và bí mật được quản lý tách khỏi mã nguồn.

• [ ] API/webhook có xác thực, chống phát lại và giới hạn tải.

• [ ] Giao dịch có idempotency và khả năng truy vết xuyên hệ thống.

Ứng dụng và vận hành

• [ ] Web, API và ứng dụng di động đã được kiểm thử bảo mật đúng phạm vi.

• [ ] Log ghi đủ sự kiện nhưng không chứa bí mật/dữ liệu nhạy cảm đầy đủ.

• [ ] Có giám sát, cảnh báo và người nhận cảnh báo rõ ràng.

• [ ] Sao lưu được bảo vệ và đã thử khôi phục thành công.

• [ ] Có playbook cho chiếm tài khoản, lộ dữ liệu và chuyển tiền sai.

• [ ] Có kế hoạch duy trì nghiệp vụ khi nền tảng hoặc thanh toán gián đoạn.

Go-live và sau triển khai

• [ ] Mọi lỗi nghiêm trọng đã được khắc phục và kiểm tra lại.

• [ ] Rủi ro còn lại có người có thẩm quyền chấp nhận bằng văn bản.

• [ ] Danh sách liên hệ khẩn cấp giữa các bên đã được kiểm tra.

• [ ] Người lao động biết kênh báo mất tài khoản hoặc giao dịch bất thường.

• [ ] Có lịch rà soát quyền, lỗ hổng, nhà cung cấp và hiệu quả cảnh báo.

• [ ] Có bằng chứng kiểm tra sau thay đổi lớn.

Kết luận

Bảo mật dữ liệu EWA bắt đầu từ việc hiểu luồng dữ liệu và trách nhiệm, không bắt đầu từ danh sách công nghệ. Một chương trình đáng tin cậy phải giới hạn dữ liệu thu thập, xác thực đúng người, cấp đúng quyền, bảo vệ API và giao dịch, ghi đủ nhật ký, kiểm soát nhà cung cấp, khôi phục được khi gián đoạn và xử lý minh bạch khi có sự cố.

Nếu doanh nghiệp đang đánh giá giải pháp Lương Ngày, hãy chuẩn bị bản đồ hệ thống, nhóm dữ liệu dự kiến tích hợp và checklist kiểm soát nội bộ, rồi tìm hiểu Lương Ngày cho doanh nghiệp để yêu cầu hồ sơ bảo mật, tài liệu tích hợp và phạm vi đánh giá kỹ thuật trước khi triển khai pilot.

Nguồn tham khảo

• Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15

• Nghị định 356/2025/NĐ-CP hướng dẫn Luật Bảo vệ dữ liệu cá nhân

• Luật Giao dịch điện tử số 20/2023/QH15

• Nghị định 52/2024/NĐ-CP về thanh toán không dùng tiền mặt

• OWASP Application Security Verification Standard

• OWASP Mobile Application Security Verification Standard

• OWASP Logging Cheat Sheet

Tác giả: Nguyễn Tấn Lộc — Chuyên viên Ban Chiến Lược, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

Tư vấn giải pháp Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Lương Ngày cho doanh nghiệp