Sinh trắc học khuôn mặt thời AI: vì sao các ngân hàng phải siết thiết bị, khóa ứng dụng và bắt buộc xác thực đa yếu tố?

Từ 1/3/2026, khi Thông tư 77 của Ngân hàng Nhà nước chính thức yêu cầu kiểm soát chặt môi trường thiết bị và quản trị phiên bản Mobile Banking, người dùng sẽ ngày càng thấy rõ những thay đổi cụ thể như ứng dụng bị khóa trên thiết bị root/jailbreak, tự động thoát khi phát hiện môi trường không an toàn hoặc buộc phải cập nhật phiên bản mới nhất. Những động thái này cho thấy ngành ngân hàng đang chủ động chuẩn hóa kiến trúc bảo mật trước mốc hiệu lực. Với lộ trình kỹ thuật và nhịp triển khai hiện tại, nhiều dấu hiệu cho thấy giai đoạn 2026–2028 có thể sẽ trở thành chu kỳ chuẩn hóa bảo mật ứng dụng ngân hàng số tại Việt Nam — nơi sinh trắc học không còn vận hành độc lập mà phải nằm trong một hệ thống phòng thủ nhiều lớp và xác thực theo mức rủi ro.

Sinh trắc học khuôn mặt đang là mặc định – nhưng cũng là bề mặt tấn công hấp dẫn nhất

Sinh trắc học khuôn mặt đang trở thành xu hướng mặc định của ngân hàng số vì nhanh, tiện và tính an toàn cao. Nhưng ở góc nhìn bảo mật, đây cũng là bề mặt tấn công hấp dẫn nhất: chỉ cần vượt qua lớp xác thực này, kẻ gian có thể chiếm quyền phiên giao dịch và thao túng các bước tiếp theo.

Thực tế cho thấy, trọng tâm rủi ro không chỉ nằm ở thuật toán nhận diện khuôn mặt mà nằm ở ngữ cảnh triển khai và môi trường thiết bị. Các thống kê về trải nghiệm xác thực tại Việt Nam từng ghi nhận: 58,3% người dùng sử dụng sinh trắc học, đồng thời cứ 3 người có 1 người lo bị đánh cắp/làm giả sinh trắc học và rủi ro giả mạo tăng mạnh trong môi trường trực tuyến với các hình thức như deepfake/voice clone, đặc biệt khi sinh trắc học bị dùng như cơ chế “độc lập”.

1) Vượt qua bảo mật sinh trắc học thường bắt đầu từ môi trường chạy ứng dụng

Một ngộ nhận phổ biến là: “Chỉ cần liveness mạnh thì AI/deepfake được loại bỏ”. Trên thực tế, nhiều kịch bản gian lận đi đường vòng: không đối đầu trực diện với AI nhận diện, mà tấn công vào ứng dụng/thiết bị để can thiệp luồng xử lý.

Vì vậy, từ góc độ kiểm soát rủi ro, xu hướng tất yếu là: ứng dụng Mobile Banking phải tự phát hiện môi trường không an toàn và tự dừng hoạt động, thay vì cố “chịu trận” trong trạng thái bị can thiệp.

Nói cách khác, nếu môi trường chạy đã bị kiểm soát, mọi tín hiệu sinh trắc học phía trên gần như mất ý nghĩa.

Cụ thể, các nhóm dấu hiệu rủi ro thường được nhắc đến gồm:

Ứng dụng chạy trong môi trường giả lập/máy ảo, hoặc bị gắn trình gỡ lỗi, hoặc bật các chế độ can thiệp kỹ thuật (ví dụ ADB trên Android).

Ứng dụng bị hook, ghi lại dữ liệu luồng hàm/API, hoặc bị đóng gói lại (repacking).

Thiết bị bị root/jailbreak hoặc mở khóa bootloader.

Đây là lý do vì sao các biện pháp “khóa ứng dụng trên thiết bị bị can thiệp” không phải là làm khó khách hàng, mà là cắt đứt điều kiện tiên quyết để kẻ gian can thiệp vào luồng xác thực và giao dịch.

2) Bài học từ các ngân hàng lớn: khóa dịch vụ trên thiết bị bị can thiệp

Một số ngân hàng đã triển khai sớm theo hướng này. Ví dụ, Vietcombank từng thông báo ngừng cung cấp VCB Digibank trên thiết bị iOS bị can thiệp (jailbreak/hook) từ 02/11/2024, đồng thời ứng dụng sẽ cảnh báo và tự đóng khi phát hiện dấu hiệu can thiệp.

Ở trong ngành Tài chính – Ngân hàng, các yêu cầu kỹ thuật cũng đang được chuẩn hóa theo hướng: từ 01/3/2026, ứng dụng ngân hàng cần tự thoát/dừng hoạt động khi phát hiện các dấu hiệu môi trường không an toàn như nêu trên; đồng thời yêu cầu kiểm soát phiên bản, chống hạ cấp (downgrade) và đánh giá an toàn định kỳ tối thiểu 3 tháng/lần để giảm nguy cơ bị khai thác qua lỗ hổng tồn tại lâu.

Điểm quan trọng ở đây không phải là “siết người dùng”, mà là chuẩn hóa trách nhiệm của ngân hàng đối với môi trường chạy ứng dụng – nơi rủi ro thực sự phát sinh.

3) AI/Deepfake khiến liveness phải đi kèm chuẩn hóa và đa lớp

AI/Deepfake không chỉ là video giả nhìn giống, mà là cuộc chạy đua giữa khả năng tạo giả và khả năng phát hiện.

Vì vậy, chúng ta cần:

Chuẩn hóa yêu cầu phát hiện giả mạo sinh trắc học (PAD) theo tiêu chuẩn quốc tế (thường được nhắc tới là ISO 30107 Level 2 hoặc tương đương).

Thừa nhận một nguyên tắc vận hành: PAD/liveness chỉ có giá trị khi ứng dụng và môi trường chạy không bị can thiệp. Nếu thiết bị/ứng dụng đã bị can thiệp, mọi tín hiệu liveness có thể bị làm sai lệch.

4) Sinh trắc học khuôn mặt bắt buộc phải đi kèm với xác thực đa yếu tố (MFA) theo mức rủi ro

Sinh trắc học là yếu tố thuộc về người dùng, nhưng bản thân nó không nên trở thành chìa khóa duy nhất cho các sự kiện rủi ro cao.

Ngay trong các phân tích về trải nghiệm xác thực, các chuyên gia cũng nhấn mạnh: rủi ro sinh trắc học nằm ở bối cảnh ứng dụng, nhiều ứng dụng dùng sinh trắc học như lớp mở khóa cục bộ để kích hoạt một cơ chế khác phía sau.

Trong ngân hàng số, nguyên tắc thiết kế MFA hiệu quả là nâng cấp xác thực theo rủi ro, đặc biệt ở các điểm đổi trạng thái an toàn:

Kích hoạt/đăng nhập trên thiết bị mới, khôi phục tài khoản.

Thay đổi thông tin định danh, thay đổi phương thức xác thực.

Giao dịch giá trị lớn hoặc hành vi bất thường (thiết bị lạ, vị trí lạ, tốc độ thao tác bất thường…).

MFA đúng nghĩa không phải thêm một mã OTP, mà là phối hợp tối thiểu hai trong ba nhóm yếu tố:

Possession: Smart OTP/soft token, thiết bị đã gắn kết, chữ ký giao dịch.

Knowledge: PIN/mật khẩu.

Inherence: khuôn mặt/vân tay (kèm PAD/liveness đạt chuẩn ISO).

5) Khuyến nghị triển khai theo tư duy “defense-in-depth”

Nếu phải cô đọng thành một kiến trúc phòng chống gian lận sinh trắc học khuôn mặt trong ngân hàng số, tôi sẽ tóm lại bằng 5 lớp kiểm soát:

Kiểm soát môi trường thiết bị & runtime: phát hiện root/jailbreak, unlock bootloader, emulator/VM, debugger/ADB, hook/repacking.

Bảo vệ ứng dụng: chống chỉnh sửa/đóng gói lại, chống can thiệp runtime, chống phân tích ngược đảm bảo tính toàn vẹn của luồng dữ liệu.

PAD/Liveness theo chuẩn ISO 30107-3 level 2 trở lên được FIDO công nhận để đối phó deepfake.

MFA theo mức rủi ro cho các hành vi trọng yếu (đặc biệt đổi thiết bị/khôi phục).

Quản trị phiên bản & lỗ hổng: bắt buộc phiên bản an toàn gần nhất, chống downgrade đánh giá an toàn định kỳ tối thiểu 3 tháng/lần.

Sinh trắc học không thất bại — cách triển khai sai mới tạo ra bề mặt tấn công

Sinh trắc học không thất bại.

Cách triển khai sinh trắc học như một lớp độc lập, tách rời khỏi môi trường thiết bị và cơ chế kiểm soát phiên bản mới là nguyên nhân tạo ra bề mặt tấn công.

Giai đoạn 2026–2028 sẽ là thời kỳ chuẩn hóa bảo mật ứng dụng ngân hàng số tại Việt Nam — nơi các yêu cầu về môi trường thiết bị, chống can thiệp runtime, chuẩn hóa PAD và MFA theo rủi ro không còn là “khuyến nghị kỹ thuật”, mà trở thành tiêu chuẩn bắt buộc.

Và khi đó, lợi thế cạnh tranh sẽ không nằm ở việc có sinh trắc học hay không, mà nằm ở kiến trúc phòng thủ nhiều lớp phía sau lớp sinh trắc học đó.