Quản lý sudo Linux an toàn: phân quyền admin, audit lệnh và giảm rủi ro production

quản lý sudo Linux là một trong những việc sysadmin phải làm cẩn thận nhất trên server production. Cấp thiếu quyền thì đội vận hành bị kẹt khi xử lý sự cố; cấp thừa quyền thì chỉ một lệnh sai cũng có thể làm dừng dịch vụ, mất dữ liệu hoặc mở đường cho leo thang đặc quyền.

Bài viết này đi từ khái niệm, mô hình phân quyền, cấu hình sudoers, audit lệnh đến troubleshooting. Mục tiêu là giúp anh em xây một cách quản lý sudo Linux đủ chặt để an toàn, nhưng vẫn thực dụng cho vận hành hằng ngày.

1. Sudo là gì và vấn đề thật sự nằm ở đâu?

sudo cho phép user chạy lệnh với quyền user khác, phổ biến nhất là root. Điểm mạnh của sudo là không cần chia sẻ mật khẩu root, có thể ghi log ai chạy lệnh gì, và có thể giới hạn theo user, group, host, command.

Vấn đề trong production thường không phải “có dùng sudo hay không”, mà là dùng sudo quá rộng: cho cả nhóm chạy ALL=(ALL) NOPASSWD:ALL, chỉnh trực tiếp file sudoers không kiểm tra cú pháp, hoặc không có log đủ rõ để truy vết sau incident.

2. Bối cảnh lab và production mẫu

OS: Ubuntu Server 22.04/24.04, Debian 12, RHEL/Rocky/AlmaLinux 9.
Nhóm vận hành: ops, nhóm triển khai ứng dụng: deploy, nhóm quan sát log: support.
Mục tiêu: cấp quyền theo nguyên tắc least privilege, có audit, có rollback.

3. Nguyên tắc thiết kế quyền sudo

Không cấp quyền theo cảm tính

Trước khi viết sudoers, hãy trả lời 4 câu hỏi:

Ai cần quyền?
Họ cần chạy lệnh nào?
Chạy trên máy nào hoặc nhóm máy nào?
Có cần nhập mật khẩu không, và log sẽ kiểm tra ở đâu?

Ưu tiên group thay vì user đơn lẻ

Quản lý bằng group giúp onboarding/offboarding sạch hơn:

sudo groupadd ops
sudo usermod -aG ops alice
id alice

Output mẫu:

uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(ops)

Khi nhân sự rời nhóm, chỉ cần gỡ khỏi group thay vì dò từng rule sudoers.

4. Luôn dùng visudo, không sửa sudoers bừa

visudo khóa file và kiểm tra cú pháp trước khi lưu. Đây là thói quen nhỏ nhưng cứu rất nhiều ca “tự khóa mình khỏi root”.

sudo visudo
sudo visudo -f /etc/sudoers.d/ops

Nên tách rule theo file trong /etc/sudoers.d/ để dễ quản lý cấu hình theo vai trò.

5. Cấu hình sudoers cơ bản cho nhóm ops

Ví dụ cấp quyền vận hành service web, nhưng không cho toàn quyền root:

%ops ALL=(root) /bin/systemctl status nginx, /bin/systemctl restart nginx, /usr/bin/journalctl -u nginx*

Ý nghĩa:

%ops: áp dụng cho group ops.
ALL: trên mọi host theo file này.
(root): chạy với quyền root.
Danh sách sau cùng: chỉ các command được phép.

Đây là ví dụ thực tế của quản lý sudo Linux: cấp đúng quyền cần dùng để xử lý Nginx, không cấp quyền sửa toàn bộ hệ thống.

6. Cấp quyền triển khai ứng dụng cho nhóm deploy

Nhóm deploy thường cần restart một service app và đọc log app:

Cmnd_Alias APP_CMDS = /bin/systemctl restart myapp.service, /bin/systemctl status myapp.service, /usr/bin/journalctl -u myapp.service *
%deploy ALL=(root) APP_CMDS

Cmnd_Alias giúp file dễ đọc hơn khi danh sách lệnh dài. Tuy nhiên, cần rất cẩn thận với wildcard *; wildcard sai có thể mở rộng quyền ngoài ý muốn.

7. Khi nào dùng NOPASSWD?

NOPASSWD tiện cho automation nhưng không nên dùng đại trà cho user tương tác. Ví dụ phù hợp:

%deploy ALL=(root) NOPASSWD: /bin/systemctl restart myapp.service

Không nên dùng:

%ops ALL=(ALL) NOPASSWD:ALL

Rule này biến mọi thành viên ops thành root không rào chắn. Nếu tài khoản bị lộ SSH key, kẻ tấn công có quyền root ngay.

8. Audit lệnh sudo

Trên Ubuntu/Debian, log sudo thường nằm trong /var/log/auth.log; trên RHEL-family thường ở /var/log/secure. Với systemd, có thể dùng journalctl:

sudo journalctl _COMM=sudo --since today
sudo grep 'COMMAND=' /var/log/auth.log

Output mẫu:

sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/bin/systemctl restart nginx

Dòng này cho biết ai chạy, từ đâu, tại thư mục nào, chuyển sang user nào và chạy command gì. Khi điều tra incident, đây là dữ liệu rất quan trọng.

9. Bật log input/output cho phiên sudo nhạy cảm

Một số bản sudo hỗ trợ I/O logging. Có thể cấu hình:

Defaults log_output
Defaults iolog_dir=/var/log/sudo-io/%{user}

Hãy kiểm tra phiên bản và tài liệu hệ điều hành trước khi bật trên diện rộng, vì log output có thể chứa dữ liệu nhạy cảm. Với server quan trọng, nên giới hạn quyền đọc thư mục log này.

10. Hardening SSH kết hợp với sudo

Sudo không thay thế bảo mật SSH. Một cấu hình vận hành hợp lý thường gồm:

Tắt đăng nhập root trực tiếp: PermitRootLogin no.
Ưu tiên SSH key, hạn chế password login.
Tách user cá nhân, không dùng chung tài khoản admin.
Ghi log sudo để truy vết hành động sau đăng nhập.

Như vậy, khi có sự cố, anh em biết tài khoản nào đăng nhập và đã chạy lệnh gì.

11. Troubleshooting lỗi sudo thường gặp

User không có quyền sudo

sudo -l -U alice
id alice

Nếu user chưa thuộc group đúng, thêm group rồi yêu cầu đăng xuất/đăng nhập lại để session nhận group mới.

Lỗi cú pháp sudoers

Nếu chỉnh bằng visudo, công cụ sẽ cảnh báo trước khi lưu. Nếu lỡ tạo file sai trong /etc/sudoers.d/, hãy vào bằng root console hoặc recovery mode để sửa.

Command được cấp nhưng vẫn bị từ chối

Kiểm tra đường dẫn tuyệt đối:

which systemctl
command -v journalctl
sudo -l

Sudoers so khớp command theo path. Nếu rule dùng /bin/systemctl nhưng hệ thống gọi /usr/bin/systemctl, có thể bị từ chối tùy distro.

12. Tài liệu chính thống nên đọc

13. Checklist nghiệm thu cấu hình sudo

Không có rule NOPASSWD:ALL cho user/group tương tác.
Quyền được cấp theo group, có quy trình thêm/gỡ thành viên.
Rule quan trọng nằm trong /etc/sudoers.d/ và được kiểm tra bằng visudo -c.
Command dùng path tuyệt đối, hạn chế wildcard.
Log sudo đọc được bằng journalctl hoặc file auth/secure.
Root login trực tiếp qua SSH đã bị tắt trên server production.
Có người thứ hai review rule trước khi áp dụng lên máy quan trọng.

14. Bài tập lab cuối bài

Tạo group ops và user test alice.
Cho alice chỉ được chạy systemctl status nginx và journalctl -u nginx.
Dùng sudo -l -U alice để xác minh quyền.
Chạy thử một lệnh không được phép, ví dụ sudo cat /etc/shadow, và quan sát log.
Viết checklist rollback nếu rule sudoers làm user mất quyền vận hành.

Kết luận: quản lý sudo Linux tốt không phải là cấp quyền càng nhiều càng tiện. Cấu hình tốt là cấu hình giúp đội vận hành làm đúng việc cần làm, có log để audit, có giới hạn để giảm blast radius và có quy trình kiểm tra trước khi đụng vào production.