Rà soát quyền truy cập: Quy trình giảm quyền dư thừa trong doanh nghiệp

Nhân viên chuyển bộ phận nhưng vẫn giữ quyền sửa thư mục cũ; nhà cung cấp hết hợp đồng vẫn còn tài khoản; quyền quản trị cấp tạm chưa được thu hồi. Những quyền dư thừa này có thể tích lũy ngay cả khi doanh nghiệp đã bật MFA và dùng mật khẩu mạnh.

Bài viết đề xuất một đợt rà soát quyền truy cập có phạm vi vừa sức, với người phê duyệt, bằng chứng và bước hậu kiểm. Đây là mẫu vận hành, không phải hướng dẫn tự động khóa tài khoản hàng loạt.

1. Rà soát quyền khác kiểm tra đăng nhập

CIS Control 6 đặt quản lý việc cấp, duy trì và thu hồi quyền vào cùng vòng đời kiểm soát truy cập, bao gồm tài khoản người dùng, quản trị và dịch vụ. Từ nguyên tắc này, câu hỏi của đợt rà soát là: quyền hiện tại còn cần cho công việc hiện tại không?

MFA giúp củng cố xác thực nhưng không trả lời câu hỏi một người có cần quyền xuất toàn bộ dữ liệu khách hàng hay không. Tài khoản đăng nhập thường xuyên cũng không đồng nghĩa mọi quyền gắn với nó đều hợp lý.

2. Bắt đầu bằng một hệ thống quan trọng

Đề xuất chọn một phạm vi như CRM hoặc kho tài liệu, chốt thời điểm lấy dữ liệu và phân công chủ hệ thống. Không bắt đầu bằng danh sách mọi tài khoản trong doanh nghiệp nếu chưa có người đủ thẩm quyền xác nhận nhu cầu từng hệ thống.

Không đưa mật khẩu, secret hoặc token vào bảng này. Danh sách quyền cũng là thông tin nhạy cảm, nên chỉ chia sẻ cho người tham gia đợt rà soát.

3. Ưu tiên quyền có tác động lớn

Xem trước quyền quản trị, xuất dữ liệu, thay đổi thanh toán, chia sẻ công khai và quyền của bên thứ ba. Đối chiếu các sự kiện nghỉ việc, chuyển vai trò, kết thúc hợp đồng và kết thúc dự án với danh sách quyền thực tế.

“Không đăng nhập gần đây” chỉ là tín hiệu điều tra. Tài khoản dịch vụ có thể hoạt động qua API, tác vụ định kỳ hoặc cơ chế không tạo bản ghi đăng nhập giống người dùng. Không khóa tài khoản chỉ vì một cột last login trống.

4. Tách quyết định khỏi thao tác thực hiện

1. Chủ nghiệp vụ xác nhận giữ, giảm, thu hồi hoặc cần điều tra thêm.
2. Đội kỹ thuật xác định quyền đến từ đâu và phụ thuộc nào bị ảnh hưởng.
3. Người có thẩm quyền phê duyệt thay đổi và thời điểm thực hiện.
4. Thực hiện trong phạm vi đã duyệt, lưu mã phiếu hoặc log thay đổi.
5. Kiểm tra quyền hiệu lực sau thay đổi và xác nhận công việc hợp lệ vẫn chạy.

Nếu quyền đến từ nhóm lồng nhau, xóa một quyền trực tiếp chưa chắc đã đủ. Cần xem quyền hiệu lực, không chỉ giao diện vừa báo “đã xóa”. Với quyền khẩn cấp, luôn giữ đường quản trị phục hồi đã được phê duyệt; tránh tự khóa toàn bộ người quản trị.

5. Ngoại lệ phải có hạn và người chịu trách nhiệm

Ví dụ giả định: một nhà cung cấp cần quyền tạm để xử lý lỗi trong tuần. Thay vì giữ vô thời hạn, ghi phạm vi, lý do, người bảo trợ, ngày hết hạn và cách kiểm tra thu hồi. Nếu chưa thể giảm quyền do phụ thuộc kỹ thuật, ghi rủi ro và kế hoạch xử lý thay vì đánh dấu “đã hoàn tất”.

Với service account, xác định ứng dụng sử dụng, người sở hữu và nơi lưu thông tin xác thực theo quy trình bảo mật. Nếu thay đổi cần xoay secret hoặc cập nhật job, phải có kế hoạch đồng bộ và rollback riêng.

6. Đo chất lượng bằng việc đã đóng

• Bao nhiêu quyền đã được chủ nghiệp vụ quyết định?
• Bao nhiêu quyết định thu hồi đã thực hiện và hậu kiểm?
• Còn tài khoản nào chưa xác định được chủ sở hữu?
• Ngoại lệ nào quá hạn hoặc chưa có người chịu trách nhiệm?
• Thay đổi nào gây gián đoạn và bài học cần bổ sung?

Lịch rà soát nên dựa trên độ nhạy cảm, mức biến động và yêu cầu của tổ chức. Đồng thời xử lý quyền khi có sự kiện đổi vai trò hoặc nghỉ việc, không chờ tới kỳ định kỳ mới bắt đầu.

Một đợt rà soát tốt không kết thúc ở bảng tính có dấu duyệt. Nó kết thúc khi quyền thực tế phù hợp quyết định, ngoại lệ được quản lý và có bằng chứng kiểm tra sau thay đổi.