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 các đợt kiểm thử xâm nhập, con đường vào hệ thống phổ biến nhất hiếm khi là một lỗ hổng phần mềm tinh vi — mà thường là một tài khoản hợp lệ: mật khẩu yếu hoặc dùng lại từ dịch vụ đã rò rỉ, VPN không bật MFA, tài khoản nhân viên đã nghỉ việc vẫn còn hoạt động. Kẻ tấn công không cần đột nhập khi có thể đăng nhập. Bài viết này tổng hợp các thực hành tốt nhất hiện nay về mật khẩu, xác thực đa yếu tố và quản lý truy cập — áp dụng được cho cả cá nhân lẫn tổ chức.

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

Hàng tỷ tổ hợp email–mật khẩu từ các vụ rò rỉ dữ liệu đang được mua bán và chia sẻ công khai. Kẻ tấn công dùng chúng cho credential stuffing: thử tự động các tổ hợp này trên hàng loạt dịch vụ khác. Nếu một nhân viên dùng cùng mật khẩu cho tài khoản cá nhân (đã bị lộ ở đâu đó) và email công ty — công ty kế thừa toàn bộ rủi ro từ thói quen cá nhân đó. Đây là lý do 'mật khẩu mạnh' thôi là chưa đủ: mật khẩu mạnh nhưng dùng lại vẫn là mật khẩu đã lộ.

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

Hướng dẫn NIST SP 800-63B — được xem là chuẩn tham chiếu toàn cầu về xác thực — đã đảo ngược nhiều quy tắc 'kinh điển' mà rất nhiều tổ chức Việt Nam vẫn áp dụng:

• Ưu tiên độ dài thay vì độ phức tạp. 'mua-ban-hang-rong-tren-pho-co' (passphrase dài) mạnh hơn nhiều so với 'P@ssw0rd1!' (ngắn nhưng 'đủ ký tự đặc biệt'). Yêu cầu tối thiểu nên là 12–16 ký tự; bỏ yêu cầu bắt buộc ký tự đặc biệt vốn chỉ tạo ra các biến thể dễ đoán.
• 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ông thể nhớ 80 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, bản business của các trình quản lý mật khẩu còn giải quyết bài toán chia sẻ credential nhóm có kiểm soát — thay cho file Excel 'TONG_HOP_MAT_KHAU.xlsx' chuyền tay qua Zalo mà chúng tôi vẫn gặp ở không ít doanh nghiệp.

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) chặn được đại đa số các cuộc tấn công chiếm tài khoản tự động. Nhưng giữa các phương thức MFA có khoảng cách lớn về độ an toàn:

Hai điểm đáng chú ý: thứ nhất, kẻ tấn công đã thích nghi với MFA qua kỹ thuật MFA fatigue — spam yêu cầu phê duyệt liên tục lúc nửa đêm đến khi nạn nhân bấm 'Approve' cho yên; number matching (phải nhập số hiển thị trên màn hình đăng nhập) vô hiệu hóa chiêu này. Thứ hai, các bộ công cụ phishing hiện đại (evilginx và tương tự) có thể chiếm phiên đăng nhập ngay cả khi nạn nhân nhập đúng OTP — chỉ FIDO2/passkey miễn nhiễm với lớp tấn công này, vì trình duyệt từ chối xác thực với domain không khớ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 mật khẩu theo hướng NIST (dài tối thiểu 12 ký tự, chặn mật khẩu đã lộ, bỏ bắt đổi định kỳ); triển khai trình quản lý mật khẩu cho các nhóm giữ credential chung.
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 — nó là tập thói quen vận hành. Nhưng so với hầu hết các khoản đầu tư bảo mật khác, đây là nơi mỗi đồng bỏ ra chặn được nhiều con đường tấn công nhất. Nếu doanh nghiệp của bạn muốn biết các kiểm soát truy cập hiện tại đứng vững đến đâu trước một kẻ tấn công thực sự, một đợt đánh giá bảo mật độc lập sẽ trả lời câu hỏi đó bằng bằng chứng thay vì phỏng đoán.