Một ứng dụng cần độ tin cậy cao đôi khi không nên phụ thuộc vào duy nhất một phương thức xác thực. Khuôn mặt có thể phù hợp với đa số tình huống, trong khi yếu tố sở hữu thiết bị, mã xác thực hoặc một phương thức sinh trắc học khác có thể hỗ trợ cho trường hợp đặc biệt. Nhưng thêm nhiều mô hình không tự động tạo ra một hệ thống bảo mật tốt hơn; quyết định quan trọng là chính sách rủi ro và cách phối hợp tín hiệu.
AttFace Core hiện tập trung vào năng lực Face AI. Palm recognition được đề cập trong bài như hướng có thể nghiên cứu hoặc tích hợp về sau, không phải tuyên bố đây là mô-đun đã có sẵn trên sản phẩm.
Hình minh họa kiến trúc tương lai gồm tín hiệu face, palm và các yếu tố xác thực.
Xác định chính sách trước khi thiết kế màn hình
Trước khi thêm nút “quét lòng bàn tay”, đội sản phẩm nên trả lời: thao tác nào cần xác thực, thiệt hại nếu chấp nhận sai là gì, người dùng có phương thức thay thế nào, và ai xử lý trường hợp chưa chắc chắn? Một thao tác chấm công và phê duyệt giao dịch tài chính có mức rủi ro khác nhau.
Bộ máy chính sách phải có khả năng xác định khi nào một tín hiệu đủ, khi nào cần thêm tín hiệu và khi nào phải chặn hoặc chuyển kiểm tra thủ công.
Ba cách kết hợp phổ biến
Lựa chọn một trong nhiều phương thức: Người dùng chọn face, mật khẩu hoặc một phương thức được phép khác. Mục tiêu chính có thể là trải nghiệm hoặc khả năng tiếp cận.
Bổ sung khi thất bại: Khi face không đủ chất lượng, hệ thống đề nghị xác thực khác. Đường dự phòng cần an toàn tương đương theo mức rủi ro, tránh trở thành cách vượt bảo vệ.
Xác thực tăng cường: Với tác vụ nhạy cảm, ứng dụng yêu cầu thêm yếu tố bên cạnh kết quả face. Cách kết hợp này cần đánh giá thời gian thao tác và false reject.
Giữ quality, liveness và matching tách biệt
Chất lượng ảnh trả lời “có đủ dữ liệu để so sánh không”; liveness/PAD giúp đánh giá một số kiểu giả mạo trình diện; matching so khớp biểu diễn danh tính. Không nên cộng các điểm số có ý nghĩa khác nhau rồi coi đó là xác suất tổng hợp mà chưa hiệu chuẩn.
Sơ đồ tư duy kiến trúc, không phải pipeline đa phương thức đã được phát hành.
Thiết kế để có thể kiểm thử
Mỗi bước cần có mã trạng thái, thông tin phiên bản mô hình và nguyên nhân chuyển nhánh. Pilot phải đo false accepts, false rejects, khả năng hoàn thành theo từng nhóm người dùng và thời gian thực hiện đầy đủ, không chỉ độ chính xác của một mô hình riêng.
Khi thay đổi ngưỡng hoặc thêm phương thức, phải đánh giá lại toàn bộ chính sách.
Ranh giới dữ liệu, lưu trữ và quyền lựa chọn
Face và palm là những loại dữ liệu riêng, có thể yêu cầu cảm biến và lưu trữ khác nhau. Không nên dùng chung mục đích hay thời hạn lưu theo mặc định. Tổ chức cần kiểm soát ai được truy cập, khi nào xóa và người dùng có thể chọn đường khác ra sao.
Nếu dùng nhiều phương thức, nguy cơ tập trung dữ liệu nhạy cảm cũng tăng; hãy cân nhắc cách lưu tách biệt và chỉ thu dữ liệu thật sự cần thiết.
Bộ điều phối phải độc lập với mô hình
Ứng dụng nên gọi các mô-đun xác thực qua giao diện ổn định rồi để policy engine đưa ra kết quả. Điều này cho phép thay mô hình hoặc phương thức mà không viết lại toàn bộ nghiệp vụ. Quan trọng hơn, mỗi phép xác thực phải gắn với đúng phiên và hành động của người dùng.
Thử nghiệm theo thứ tự ưu tiên
Trước hết xác minh một luồng face đơn lẻ ổn định. Tiếp theo đo các tình huống lỗi thực tế và đường xử lý thay thế. Chỉ đưa phương thức mới vào sau khi có dữ liệu chứng minh lợi ích, tính khả thi thiết bị và mức chấp nhận của người dùng. Palm recognition cần có đánh giá kỹ thuật, bản quyền và khả năng thương mại riêng.
Ý nghĩa với đối tác AttFace Core
Các đối tác có thể xây sản phẩm xác thực theo chính sách dựa trên Face AI của AttFace và những yếu tố khác do họ kiểm soát. Hướng tiếp cận này tạo hệ thống linh hoạt hơn là giả định mọi khách hàng đều cần cùng một bộ sinh trắc học.
Bước tiếp theo: Liên hệ AttFace để thảo luận thiết kế chính sách xác thực theo mức rủi ro.
Tài nguyên bổ sung: AIPractix
