Mật khẩu, MFA và quản lý truy cập: Nền tảng phòng thủ của mọi tổ chức

Trong nhiều đợt kiểm thử xâm nhập, đường vào hệ thống không phải lỗ hổng phần mềm tinh vi mà là một tài khoản hợp lệ: mật khẩu dùng lại từ dịch vụ đã rò rỉ, VPN không bật MFA hoặc tài khoản nhân viên nghỉ việc vẫn hoạt động. Kẻ tấn công không cần đột nhập khi có thể đăng nhập.

Vì sao credential là mục tiêu số một

Các tổ hợp email–mật khẩu từ những vụ rò rỉ được dùng cho credential stuffing: thử tự động cùng thông tin đăng nhập trên nhiều dịch vụ. Nếu nhân viên dùng lại mật khẩu cá nhân cho email công ty, tổ chức kế thừa rủi ro từ một hệ thống nằm ngoài quyền kiểm soát của mình. Vì vậy, mật khẩu dài nhưng dùng lại vẫn là mật khẩu nguy hiểm.

Chính sách mật khẩu hiện đại: dài hơn, ít phiền hơn

NIST SP 800-63B-4 công bố tháng 7/2025 đã cập nhật nhiều quy tắc mà các chính sách mật khẩu cũ vẫn áp dụng:

• Ưu tiên độ dài thay vì quy tắc thành phần. NIST yêu cầu tối thiểu 15 ký tự khi mật khẩu là yếu tố xác thực duy nhất; nếu mật khẩu chỉ là một phần của MFA thì tối thiểu là 8 ký tự. Hệ thống không nên bắt buộc pha chữ hoa, chữ thường, số và ký tự đặc biệt theo công thức.
• Không bắt đổi mật khẩu định kỳ vô điều kiện. Bắt đổi mỗi 90 ngày khiến người dùng tạo các biến thể tuần tự (Matkhau01 → Matkhau02) — dễ đoán hơn chứ không an toàn hơn. Chỉ bắt đổi khi có dấu hiệu hoặc bằng chứng mật khẩu bị lộ.
• Chặn mật khẩu đã lộ và mật khẩu phổ biến. Khi người dùng đặt mật khẩu, đối chiếu với danh sách mật khẩu đã rò rỉ (ví dụ qua API k-anonymity của Have I Been Pwned — không gửi mật khẩu thật đi đâu) và từ chối các mật khẩu nằm trong danh sách.
• Không dùng câu hỏi bảo mật. 'Tên trường cấp ba của bạn' là thông tin tra được trên Facebook trong 5 phút.

Trình quản lý mật khẩu: một mật khẩu chủ, mọi thứ khác ngẫu nhiên

Con người khó nhớ nhiều mật khẩu mạnh và khác nhau — và không cần phải nhớ. Trình quản lý mật khẩu (password manager) sinh và lưu mật khẩu ngẫu nhiên cho từng dịch vụ; người dùng chỉ nhớ một mật khẩu chủ và bật MFA cho chính két sắt đó. Với tổ chức, công cụ này còn giải quyết bài toán chia sẻ credential nhóm có kiểm soát thay cho file Excel chuyền tay qua chat.

MFA: bật là tốt, nhưng không phải loại nào cũng như nhau

Xác thực đa yếu tố (MFA) thêm một rào cản quan trọng khi mật khẩu bị lộ. Nhưng giữa các phương thức MFA có khoảng cách lớn về khả năng chống phishing:

Kẻ tấn công đã thích nghi với MFA qua MFA fatigue — gửi dồn yêu cầu phê duyệt đến khi nạn nhân bấm chấp nhận — và phishing trung gian để lấy cả OTP lẫn phiên đăng nhập. Number matching giảm rủi ro phê duyệt nhầm; FIDO2/passkey có tính kháng phishing vì quá trình xác thực được ràng buộc với đúng dịch vụ. Bài về phishing và BEC giải thích cách phối hợp lớp kỹ thuật này với quy trình xác minh của doanh nghiệp.

Passkey: hướng đi không mật khẩu

Passkey — chuẩn FIDO2 được Apple, Google, Microsoft đồng loạt hỗ trợ — thay mật khẩu bằng cặp khóa mã hóa gắn với thiết bị, mở khóa bằng vân tay/khuôn mặt. Không có mật khẩu để quên, để lộ, hay để phishing. Với tổ chức, lộ trình thực tế là bật passkey song song mật khẩu cho các hệ thống hỗ trợ (Google Workspace, Microsoft 365 đều đã hỗ trợ), bắt đầu từ nhóm tài khoản quản trị.

Triển khai MFA: ưu tiên ở đâu trước?

1. Email doanh nghiệp — hộp thư là 'chìa khóa vạn năng' (mọi dịch vụ khác reset mật khẩu qua email).
2. VPN và truy cập từ xa — cánh cửa trực diện vào mạng nội bộ; VPN không MFA là nguyên nhân của rất nhiều vụ ransomware.
3. Tài khoản quản trị — admin domain, console cloud, quản trị hệ thống nhân sự/kế toán. Nhóm này nên dùng FIDO2/khóa vật lý, không chỉ OTP.
4. Toàn bộ nhân viên trên các hệ thống lõi — mục tiêu cuối: MFA là mặc định, không phải tùy chọn.

Quản lý truy cập trong tổ chức: rủi ro nằm ở quyền thừa

Trong các đợt đánh giá bảo mật nội bộ, phát hiện lặp lại nhiều nhất không phải mật khẩu yếu mà là quyền truy cập thừa: nhân viên chuyển bộ phận 3 lần và tích lũy quyền của cả 3 vị trí; thực tập sinh có quyền đọc toàn bộ ổ chia sẻ tài chính; tài khoản của nhân viên nghỉ việc từ năm ngoái vẫn đăng nhập được VPN. Mỗi quyền thừa là một bề mặt tấn công cộng thêm — và khi tài khoản đó bị chiếm, kẻ tấn công kế thừa toàn bộ.

• Nguyên tắc đặc quyền tối thiểu (least privilege). Mỗi tài khoản chỉ có đúng quyền cần cho công việc hiện tại. Cấp quyền theo vai trò (RBAC) thay vì theo từng cá nhân để dễ kiểm soát.
• Quy trình Joiner–Mover–Leaver. Nhân viên mới (joiner): cấp quyền theo bộ quyền chuẩn của vị trí. Chuyển vị trí (mover): gỡ quyền cũ trước khi cấp quyền mới — đây là bước hay bị bỏ qua nhất. Nghỉ việc (leaver): vô hiệu hóa tài khoản trong ngày làm việc cuối, thu hồi thiết bị, đổi các mật khẩu dùng chung mà người đó biết.
• Rà soát quyền định kỳ. Mỗi quý, trưởng bộ phận xác nhận danh sách quyền của nhân viên mình — 30 phút mỗi quý đổi lấy việc quyền thừa không tích tụ qua năm tháng.
• Kiểm soát riêng cho tài khoản đặc quyền. Tài khoản admin tách khỏi tài khoản làm việc hằng ngày; thao tác quản trị được ghi log; không dùng chung một tài khoản admin cho cả đội.
• Đừng quên tài khoản phi-con-người. Service account, API key, token tích hợp — chúng không bao giờ 'nghỉ việc', hiếm khi được đổi credentials, và thường có quyền rất lớn. Kiểm kê và luân chuyển định kỳ.

Checklist 30 ngày cho tổ chức

1. Tuần 1 — Bật MFA cho toàn bộ email doanh nghiệp và VPN; lập danh sách tài khoản đặc quyền.
2. Tuần 2 — Rà soát và vô hiệu hóa tài khoản của nhân viên đã nghỉ; kiểm kê service account và API key.
3. Tuần 3 — Cập nhật chính sách theo NIST SP 800-63B-4: tối thiểu 15 ký tự nếu mật khẩu là yếu tố duy nhất, tối thiểu 8 ký tự nếu là một phần của MFA; chặn mật khẩu đã lộ, bỏ bắt đổi định kỳ và triển khai trình quản lý mật khẩu.
4. Tuần 4 — Ban hành quy trình Joiner–Mover–Leaver thành văn bản; đặt lịch rà soát quyền định kỳ hằng quý; lên lộ trình FIDO2/passkey cho nhóm quản trị.

Quản lý danh tính và truy cập không phải dự án làm một lần mà là tập thói quen vận hành. Với doanh nghiệp nguồn lực giới hạn, đây cũng là một trong các ưu tiên bảo mật nền tảng cho SME. Một đợt đánh giá độc lập sau triển khai sẽ kiểm chứng quyền truy cập và cơ chế xác thực bằng bằng chứng thay vì phỏng đoán.