Mẫu chính sách mật khẩu nhóm: khung sẵn dùng

Mẫu phù hợp cho quản lý CNTT, nhân sự và trưởng nhóm cần ban hành chính sách trong một tuần. Sao chép khung, thay các giá trị trong ngoặc bằng quyết định của bạn, rồi đưa qua luật sư hoặc bộ phận tuân thủ. Với nhân sự mới, hãy đưa chính sách vào quy trình hội nhập và ký xác nhận; khi thay đổi công cụ, cập nhật mục quản lý thay đổi và thông báo trước.

Đừng ban hành chính sách mà không có người chịu trách nhiệm kiểm tra và gia hạn hằng năm, nếu không tài liệu sẽ lỗi thời ngay sau lần thay đổi công cụ tiếp theo.

Chính sách mật khẩu bằng văn bản biến bảo mật từ phỏng đoán cá nhân thành chuẩn mực tổ chức. Không có chính sách, các thành viên dùng cách rất khác nhau: người dùng trình quản lý với mật khẩu ngẫu nhiên 20 ký tự, người dùng lại "CompanyName2026" cho mọi dịch vụ. Chính sách rõ ràng xóa bỏ sự thiếu nhất quán và tạo bảo vệ pháp lý bằng chứng minh nỗ lực hợp lý.

Các khung quy định gồm PCI DSS, SOC 2, HIPAA, GDPR và ISO 27001 đều yêu cầu chính sách kiểm soát truy cập có hồ sơ. Khi kiểm toán hoặc điều tra rò rỉ, câu hỏi đầu tiên thường là "cho xem chính sách mật khẩu". Không có hoặc có bản lỗi thời có thể dẫn tới không tuân thủ, phạt cao hơn và trách nhiệm lớn hơn.

Mẫu dưới đây dành cho nhóm 5-500 người. Mẫu bao gồm yêu cầu thiết yếu nhưng vẫn thực tế cho dùng hằng ngày. Hãy điều chỉnh giá trị cụ thể (độ dài tối thiểu, chu kỳ xoay vòng, công cụ) theo mức rủi ro và quy định của tổ chức.

Độ dài tối thiểu: 14 ký tự cho tài khoản người dùng, 20 ký tự cho tài khoản quản trị và dịch vụ. Không giới hạn độ dài tối đa. Mức này vượt tối thiểu NIST 800-63B (8) và PCI DSS v4.0 (12) để có thêm biên an toàn trước tiến bộ bẻ khóa.

Cách tiếp cận độ phức tạp: áp dụng hướng NIST ưu tiên độ dài hơn độ phức tạp. Mật khẩu không được chỉ toàn số hoặc chỉ toàn chữ. Ngoài ra không bắt buộc nhóm ký tự cụ thể. Người dùng được khuyến khích nhưng không bị ép dùng nhiều loại ký tự.

Mật khẩu bị cấm: mọi mật khẩu được kiểm tra với cơ sở dữ liệu Have I Been Pwned khi tạo và đổi. Mật khẩu trùng dữ liệu rò rỉ đã biết bị từ chối kèm giải thích rõ. Ngoài ra, mật khẩu không được chứa tên đăng nhập, email hoặc tên công ty.

Hỗ trợ cụm mật khẩu: khuyến khích dùng cụm (chuỗi từ ngẫu nhiên) thay mật khẩu ký tự ngẫu nhiên cho thông tin phải ghi nhớ. Cụm phải có ít nhất 5 từ từ danh sách lớn, có dấu phân cách giữa các từ.

Mọi thành viên phải dùng trình quản lý mật khẩu được tổ chức phê duyệt cho mọi tài khoản công việc. Trình quản lý được duyệt phải: dùng mã hóa AES-256 hoặc XChaCha20; có kiến trúc zero-knowledge; đã qua kiểm tra bảo mật độc lập trong 24 tháng gần nhất; hỗ trợ mọi nền tảng nhóm dùng; và có kiểm soát quản trị để áp chính sách.

Lựa chọn khuyến nghị: 1Password Business (7,99 USD/người/tháng) có kiểm soát quản trị toàn diện nhất, giám sát rò rỉ Watchtower và travel mode. Bitwarden Teams (4 USD/người/tháng) giá trị tốt với mã nguồn mở minh bạch. Dashlane Business (8 USD/người/tháng) gồm VPN và giám sát dark web.

Mỗi thành viên phải tạo mật khẩu ngẫu nhiên riêng ít nhất 16 ký tự cho mọi tài khoản. Cấm dùng lại mật khẩu giữa bất kỳ tài khoản nào. Phải dùng trình tạo tích hợp của trình quản lý — mật khẩu do người tạo không được phép cho tài khoản công việc.

Yêu cầu mật khẩu chính: cụm ít nhất 6 từ ngẫu nhiên hoặc mật khẩu ngẫu nhiên ít nhất 20 ký tự. Mật khẩu chính phải duy nhất (không dùng cho mục đích khác) và không được lưu kỹ thuật số ngoài trí nhớ người dùng. Có thể giữ bản giấy trong két cá nhân có khóa trong thời gian đầu luyện nhớ.

MFA là bắt buộc cho mọi tài khoản công việc hỗ trợ. Không có ngoại lệ cho bất kỳ ai, kể cả lãnh đạo và nhân viên tạm thời. MFA phải được bật trong 24 giờ sau khi tạo tài khoản. Tài khoản chưa bật MFA sau 48 giờ sẽ bị tạm ngưng cho đến khi cấu hình xong.

Phương thức MFA được duyệt, theo thứ tự ưu tiên: khóa bảo mật phần cứng FIDO2/WebAuthn (YubiKey 5, Google Titan); ứng dụng TOTP (Google Authenticator, Authy, Microsoft Authenticator); thông báo đẩy từ trình quản lý mật khẩu được duyệt; mã SMS (chỉ khi dịch vụ cụ thể không còn cách nào khác).

Yêu cầu khóa phần cứng: thành viên truy cập hệ thống sản phẩm, dữ liệu khách hàng hoặc hệ thống tài chính phải dùng khóa phần cứng làm MFA chính. Tổ chức cấp hai khóa cho mỗi nhân viên đủ điều kiện — một dùng hằng ngày, một dự phòng cất an toàn ở nhà. Mất khóa phải báo trong 2 giờ.

Dự phòng và khôi phục: mọi mã dự phòng MFA phải lưu trong trình quản lý mật khẩu nhóm dưới dạng ghi chú an toàn. Mỗi người phải đăng ký ít nhất hai phương thức MFA hoạt động cho mọi tài khoản quan trọng (ví dụ khóa phần cứng + ứng dụng TOTP). Quy trình khôi phục được ghi lại và kiểm tra hằng năm.

Tài khoản người dùng thường: KHÔNG xoay vòng theo lịch cố định. Theo hướng dẫn NIST 800-63B, xoay vòng định kỳ bắt buộc phản tác dụng. Chỉ đổi khi: có bằng chứng bị xâm phạm; mật khẩu xuất hiện trong cơ sở dữ liệu rò rỉ mới; vai trò nhân viên thay đổi đáng kể; hoặc nhân viên rời tổ chức.

Tài khoản quản trị: xoay vòng mỗi 180 ngày và ngay khi nghi bị xâm phạm. Mật khẩu quản trị phải do trình quản lý tạo (tối thiểu 24 ký tự, hoàn toàn ngẫu nhiên) và không bao giờ chia sẻ.

Tài khoản dịch vụ và khóa API: xoay vòng mỗi 90 ngày. Mọi thông tin tài khoản dịch vụ phải lưu trong hệ thống quản lý bí mật (HashiCorp Vault, AWS Secrets Manager hoặc tương đương) — không bao giờ trong mã nguồn, tệp cấu hình hoặc biến môi trường ở kho chung. Gắn cứng thông tin đăng nhập là lỗi có thể bị sa thải.

Nhân viên rời tổ chức: mọi mật khẩu và token truy cập liên quan phải được xoay vòng hoặc thu hồi trong 4 giờ sau thông báo nghỉ việc. Nhóm CNTT giữ danh sách kiểm tra mọi hệ thống cần xoay thông tin khi nhân viên rời đi.

Khi nghi ngờ hoặc xác nhận thông tin đăng nhập bị xâm phạm, áp dụng quy trình sau. Ngay lập tức (trong 30 phút): vô hiệu hóa tài khoản bị xâm phạm; xoay thông tin bị lộ; kiểm tra log kiểm toán tìm truy cập trái phép; bật giám sát tăng cường trên hệ thống bị ảnh hưởng.

Ngắn hạn (trong 24 giờ): xác định phạm vi xâm phạm — tài khoản được quyền truy cập dữ liệu gì? Xem mọi hành động của tài khoản trong 30 ngày qua. Nếu mật khẩu bị lộ được dùng lại (vi phạm chính sách), xoay mọi tài khoản dùng mật khẩu đó. Thông báo cho bên liên quan theo quy định.

Sau sự cố (trong 7 ngày): phân tích nguyên nhân gốc, ghi lại cách xâm phạm xảy ra, kiểm soát nào thất bại và cần cải tiến gì. Cập nhật chính sách mật khẩu nếu sự cố lộ khoảng trống. Đào tạo bảo mật có mục tiêu cho nhân viên bị ảnh hưởng. Ghi hồ sơ sự cố để tuân thủ.

Thời hạn thông báo rò rỉ: GDPR yêu cầu thông báo trong 72 giờ sau khi phát hiện; PCI DSS yêu cầu báo ngay cho các thương hiệu thanh toán; luật thông báo rò rỉ cấp bang khác nhau. Nhóm pháp lý phải được thông báo trong 2 giờ khi nghi rò rỉ liên quan dữ liệu khách hàng.

Mọi nhân viên phải hoàn thành đào tạo bảo mật mật khẩu trong tuần đầu và hằng năm sau đó. Nội dung gồm: cách dùng trình quản lý mật khẩu của tổ chức; cách tạo và quản lý cụm mật khẩu; nhận diện lừa đảo nhắm thông tin đăng nhập; xử lý đúng thiết bị MFA và mã dự phòng; và quy trình báo cáo sự cố.

Tuân thủ được xác minh qua kiểm toán hằng quý bảng sức khỏe của trình quản lý mật khẩu nhóm. Chỉ số theo dõi gồm: tỷ lệ tài khoản dùng mật khẩu riêng; độ dài trung bình; số mật khẩu xuất hiện trong cơ sở dữ liệu rò rỉ; tỷ lệ dùng MFA; và thời gian khắc phục vấn đề bị gắn cờ.

Vi phạm chính sách được xử lý tăng dần: lần đầu nhận đào tạo thêm và cảnh cáo bằng văn bản; lần hai nhận khiển trách chính thức và buổi vệ sinh mật khẩu có giám sát; lần ba bị hạn chế truy cập hệ thống chờ đánh giá bảo mật. Vi phạm cố ý (chia sẻ thông tin, tắt MFA, gắn cứng bí mật) có thể bị xử lý kỷ luật ngay.

Để triển khai: trước hết, thuyết phục lãnh đạo bằng cách so chi phí rò rỉ thông tin đăng nhập với chi phí đăng ký trình quản lý mật khẩu. IBM báo cáo chi phí rò rỉ trung bình 4,88 triệu USD — đăng ký trình quản lý chỉ là một phần nhỏ của rủi ro đó.

Thứ hai, chọn và triển khai trình quản lý mật khẩu trước khi công bố chính sách. Cấu hình sẵn kho nhóm, nhập thông tin chia sẻ hiện có và tạo tài liệu hướng dẫn. Chuyển đổi càng mượt, tỷ lệ áp dụng càng cao.

Thứ ba, công bố chính sách kèm thời gian ân hạn (thường 30 ngày) để tuân thủ đầy đủ. Trong thời gian này, tổ chức buổi hỗ trợ trực tiếp để thành viên thiết lập trình quản lý, tạo mật khẩu mới và cấu hình MFA với hướng dẫn của CNTT.

Cuối cùng, xem xét và cập nhật chính sách ít nhất hằng năm. Mối đe dọa thay đổi, công cụ mới xuất hiện và quy định cũng đổi. Mỗi lần rà soát nên gồm bài học từ sự cố năm trước và phản hồi của thành viên về khó khăn thực tế.

Chính sách nên dài bao nhiêu? Đủ ngắn để nhân viên đọc trong 10 phút, đủ cụ thể để xử lý tình huống thường gặp. Mẫu này khoảng 6 phần; tổ chức nhỏ có thể gộp phần đào tạo và ứng phó sự cố, nhưng không nên bỏ yêu cầu MFA và quản lý mật khẩu.

Bao lâu rà soát lại? Ít nhất mỗi năm một lần, và ngay sau khi đổi công cụ, sáp nhập nhóm hoặc có sự cố rò rỉ. Ghi ngày rà soát và người phê duyệt vào cuối tài liệu để chứng minh với kiểm toán.

Nhân viên không tuân thủ thì sao? Áp dụng quy trình kỷ luật tăng dần đã nêu: nhắc nhở và đào tạo, khiển trách chính thức, hạn chế quyền truy cập. Trường hợp cố ý chia sẻ mật khẩu hoặc tắt MFA cần xử lý ngay, vì rủi ro không dừng ở cá nhân vi phạm.

Ví dụ triển khai: phòng nhân sự đưa chính sách vào sổ tay nhân viên và buổi hội nhập; quản lý trực tiếp xác nhận từng thành viên đã cài trình quản lý trước khi cấp quyền; bộ phận CNTT kiểm tra quyền truy cập khi nhân viên nghỉ việc hoặc chuyển bộ phận. Nhà thầu và thời gian thử việc cũng cần cùng mức yêu cầu.

Khi hội nhập: tạo tài khoản trên HRIS, cấp badge, mở VPN, thêm vào mail group, tạo thư mục vault và ký thỏa thuận bảo mật. Khi nghỉ việc: thu hồi badge, đóng tài khoản, xóa khỏi mail group, chuyển quyền sở hữu vault và phỏng vấn bàn giao. Nhà thầu áp dụng cùng danh sách. Ví dụ: công ty logistics, phòng khám tư và trường tư thục đều dùng được khung này.