Checklist bảo mật tài khoản quản trị và quyền sudo trên VPS

Trong vận hành máy chủ, việc quản lý quyền truy cập không nên chỉ dừng ở việc "ai có mật khẩu thì vào được". Bạn cần nắm rõ trên VPS hiện có những tài khoản nào, ai là người nắm giữ, phương thức xác thực ra sao và khi nào họ có thể thực thi các lệnh mang quyền hạn root.

Một quy trình quản trị tài khoản an toàn cần tuân thủ 5 nguyên tắc cốt lõi:

1. Tài khoản định danh riêng biệt: Mỗi kỹ sư hoặc người quản trị sử dụng một tài khoản cá nhân và một cặp SSH key riêng, không dùng chung tài khoản.
2. Quyền hạn tối thiểu (Least Privilege): Chỉ những ai thực sự chịu trách nhiệm vận hành hệ thống mới được cấp quyền trong nhóm sudo.
3. Kiểm tra trước khi áp dụng: Mọi thay đổi trong cấu hình sudoers hoặc SSH daemon đều phải kiểm tra cú pháp kỹ lưỡng bằng công cụ chuyên dụng (visudo, sshd -t).
4. Quy tắc phiên làm việc thứ hai: Luôn mở một cửa sổ terminal mới để kiểm tra đăng nhập và lệnh sudo thành công trước khi đóng phiên làm việc hiện tại.
5. Thu hồi quyền triệt để: Khi một thành viên chuyển giao công việc hoặc rời dự án, quy trình thu hồi phải xử lý đồng thời cả mật khẩu, SSH key, cronjob cá nhân và chấm dứt các phiên kết nối đang mở.

Tuyệt đối không tắt các phương thức đăng nhập cũ hoặc xóa quyền quản trị dự phòng khi bạn chưa đi qua "cửa mới" thành công và chưa nắm chắc đường cứu hộ (Rescue Console) từ nhà cung cấp dịch vụ đám mây.

Kiểm kê danh sách tài khoản và các đường truy cập hiện có

Trước khi tiến hành siết chặt bảo mật hay gỡ bỏ quyền hạn, bạn cần lập danh sách toàn bộ các tài khoản đang tồn tại trên hệ điều hành. Với từng tài khoản, hãy làm rõ:

• Ai là chủ sở hữu hoặc dịch vụ nào đang sử dụng tài khoản này.
• Mục đích tồn tại: quản trị hệ thống, triển khai mã nguồn tự động (CI/CD), chạy dịch vụ nền hay tài khoản cứu hộ.
• Phương thức đăng nhập: xác thực bằng SSH key, mật khẩu, hay hoàn toàn không cho phép đăng nhập tương tác (nologin / false).
• Các nhóm (groups) đang tham gia và phạm vi quyền sudo cụ thể.
• Những tiến trình ngầm, cronjob hoặc pipeline nào đang phụ thuộc vào tài khoản này.

Bạn có thể kiểm tra nhanh trên máy chủ Ubuntu bằng các câu lệnh:

# Liệt kê toàn bộ người dùng có shell đăng nhập hợp lệ
grep -vE '(/bin/false|/usr/sbin/nologin)' /etc/passwd | cut -d: -f1,7

# Kiểm tra danh sách thành viên trong nhóm sudo
getent group sudo

# Xem nhóm và quyền của một user cụ thể
id <ten-user>
sudo -l -U <ten-user>

Tệp /etc/passwd chứa rất nhiều tài khoản hệ thống (như www-data, systemd-resolve, nobody). Đây là các tài khoản dịch vụ mặc định của Linux, không phải tài khoản của người dùng thật. Hãy phân loại chính xác trước khi quyết định can thiệp.

Nếu bắt gặp một tài khoản lạ không rõ nguồn gốc trên VPS đang chạy production, đừng vội vàng dùng lệnh userdel để xóa ngay lập tức. Trước tiên, hãy kiểm tra xem có tiến trình nào đang chạy dưới quyền UID đó không, hoặc có tệp tin dữ liệu quan trọng nào thuộc sở hữu của user đó hay không. Xóa đột ngột một tài khoản đang gánh tác vụ nền có thể khiến ứng dụng bị crash ngoài ý muốn.

Tại sao mỗi người quản trị phải có một tài khoản riêng?

Thói quen chia sẻ chung một tài khoản quản trị (hoặc dùng chung trực tiếp tài khoản root) để nhiều người cùng SSH vào làm việc tiềm ẩn rất nhiều rủi ro vận hành:

• Mất dấu vết trách nhiệm: Khi xảy ra sự cố gõ nhầm lệnh làm gián đoạn dịch vụ, bạn không thể truy vết ai là người thực hiện hành động đó trong log hệ thống (/var/log/auth.log hoặc journald).
• Rủi ro lộ thông tin bí mật: Việc gửi private key hoặc chia sẻ mật khẩu qua tin nhắn nội bộ biến thông tin đăng nhập thành dữ liệu mở, rất dễ bị rò rỉ.
• Khó khăn khi thu hồi quyền: Khi một nhân sự nghỉ việc, nếu dùng chung tài khoản, bạn buộc phải đổi mật khẩu và đổi SSH key trên toàn bộ hệ thống, gây xáo trộn công việc của toàn bộ các thành viên còn lại.

Trên hệ điều hành Ubuntu Server, mô hình chuẩn là vô hiệu hóa đăng nhập trực tiếp từ xa của root. Mỗi kỹ sư quản trị sẽ được tạo một tài khoản cá nhân (ví dụ thuan_admin), đăng nhập bằng SSH key riêng của họ và nâng quyền quản trị tạm thời bằng sudo khi cần thao tác các lệnh can thiệp hệ thống.

Quy trình tạo cặp khóa cá nhân và cấu hình bảo mật chi tiết đã được trình bày trong bài Dùng SSH key thế nào để giảm rủi ro mất quyền truy cập VPS?.

Rà soát ai thực sự cần quyền sudo

Trên Ubuntu, người dùng thuộc nhóm sudo mặc định có quyền thực thi bất kỳ câu lệnh nào với tư cách root. Do đó, kiểm tra thành viên nhóm sudo là bước rà soát đầu tiên, nhưng chưa phải là tất cả.

Quyền nâng cao còn có thể được cấp thông qua:

• Các quy tắc gán trực tiếp cho từng user trong /etc/sudoers.
• Các tệp cấu hình riêng lẻ nằm trong thư mục /etc/sudoers.d/.
• Các nhóm người dùng tùy biến khác được khai báo trong hệ thống.

Hãy tự đặt ra 3 câu hỏi cho mỗi tài khoản:

1. Người này có thực sự cần toàn quyền quản trị toàn bộ máy chủ không?
2. Nếu họ chỉ cần thực hiện một tác vụ cụ thể (như khởi động lại dịch vụ web hoặc đọc log), có thể phân quyền hẹp hơn thay vì cấp toàn quyền ALL=(ALL) ALL không?
3. Quyền hạn này cần duy trì thường xuyên hay chỉ cấp tạm thời trong một phiên bảo trì?

Một lập trình viên chỉ cần xem log ứng dụng hoặc restart container không nhất thiết phải có quyền sửa đổi firewall hay tạo user mới. Việc cấp quyền theo nguyên tắc tối thiểu giúp hạn chế tối đa hậu quả của những sai sót vô ý.

Chỉnh sửa sudoers an toàn bằng visudo

Tuyệt đối không bao giờ dùng các trình soạn thảo thông thường như nano hay vim để mở và sửa trực tiếp tệp /etc/sudoers rồi đóng terminal. Nếu bạn vô tình gõ sai một dấu cách hoặc sai cú pháp, hệ điều hành sẽ từ chối thực thi toàn bộ lệnh sudo sau đó. Khi đó, tài khoản của bạn sẽ mất quyền quản trị và không thể sửa lại tệp được nữa.

Công cụ chuẩn bắt buộc phải sử dụng là visudo:

sudo visudo

Nếu bạn tạo tệp phân quyền riêng trong /etc/sudoers.d/, hãy mở bằng lệnh:

sudo visudo -f /etc/sudoers.d/deploy-rules

visudo tự động khóa tệp để tránh xung đột ghi đè, và quan trọng nhất: khi bạn lưu tệp, nó sẽ tự động phân tích cú pháp. Nếu phát hiện lỗi cú pháp, visudo sẽ cảnh báo và yêu cầu bạn sửa lại ngay trước khi ghi đè vào hệ thống.

Sau khi chỉnh sửa xong, hãy chạy lệnh kiểm tra tính hợp lệ của toàn bộ policy:

sudo visudo -c

Quy trình 6 bước thay đổi sudoers an toàn:

1. Giữ nguyên phiên terminal hiện tại đang có quyền root/sudo.
2. Mở và chỉnh sửa tệp bằng visudo hoặc visudo -f.
3. Kiểm tra cú pháp bằng sudo visudo -c.
4. Mở một phiên terminal SSH mới, đăng nhập bằng tài khoản vừa được cấp quyền.
5. Thử chạy một lệnh đặc quyền (ví dụ sudo apt update hoặc sudo systemctl status nginx) để xác nhận quyền hoạt động bình thường.
6. Chỉ đóng phiên làm việc cũ ở Bước 1 sau khi mọi thử nghiệm ở Bước 5 đã hoàn tất thành công.

Cân nhắc kỹ lưỡng trước khi sử dụng cờ NOPASSWD

Tùy chọn NOPASSWD trong sudoers cho phép người dùng chạy lệnh sudo mà không cần nhập mật khẩu. Đây là cấu hình rất thuận tiện cho các script tự động hóa (CI/CD pipeline, backup cronjob), nhưng nó cũng là con dao hai lưỡi.

Nếu bạn cấp NOPASSWD: ALL cho một tài khoản người dùng thông thường, bất kỳ ai chiếm đoạt được SSH key hoặc phiên làm việc của user đó đều có thể kiểm soát toàn bộ máy chủ trong tích tắc mà không gặp bất kỳ rào cản xác thực nào.

Nếu bắt buộc phải dùng NOPASSWD cho tự động hóa, hãy tuân thủ nguyên tắc giới hạn phạm vi:

• Chỉ cấp quyền trên một tài khoản dịch vụ riêng biệt (ví dụ deployer), không cấp cho tài khoản cá nhân.
• Chỉ định đích danh đường dẫn tuyệt đối của câu lệnh được phép chạy, không dùng ký tự đại diện ALL.
• Đảm bảo lệnh được cấp phép không có khả năng mở ra interactive shell (như vim, less, find với cờ -exec) vì kẻ tấn công có thể lợi dụng để leo thang đặc quyền.

Ví dụ về một cấu hình cấp quyền hẹp và an toàn trong /etc/sudoers.d/deployer:

deployer ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx, /usr/bin/docker compose *

Phân biệt rõ ba nhóm tài khoản trên máy chủ

Trên một máy chủ sản xuất, các tài khoản cần được phân loại rõ ràng theo mục đích sử dụng:

Khóa mật khẩu chưa đủ để thu hồi toàn bộ quyền truy cập

Khi một nhân sự chuyển đổi vị trí hoặc rời dự án, thao tác khóa mật khẩu bằng sudo passwd -l <username> là chưa đủ để vô hiệu hóa hoàn toàn quyền truy cập.

Thực tế trên Linux:

• Khóa mật khẩu chỉ ngăn chặn việc xác thực bằng password. Nếu trong thư mục ~/.ssh/authorized_keys của người dùng đó vẫn còn lưu SSH public key, họ vẫn có thể SSH vào máy chủ bình thường.
• Việc khóa tài khoản không tự động ngắt các phiên SSH đang kết nối sẵn (established sessions).
• Các cronjob cá nhân hoặc tiến trình chạy ngầm (screen, tmux) dưới tên tài khoản đó vẫn tiếp tục hoạt động.

Quy trình 5 bước thu hồi quyền truy cập triệt để:

Bước 1: Ngắt phiên kết nối và tiến trình đang chạy

# Buộc dừng toàn bộ tiến trình của user
sudo pkill -u <username>

Bước 2: Xóa SSH public key Xóa hoặc đổi tên tệp authorized_keys của user đó:

sudo rm /home/<username>/.ssh/authorized_keys

Bước 3: Gỡ bỏ khỏi nhóm sudo và thu hồi cấu hình sudoers

sudo gpasswd -d <username> sudo

Kiểm tra và xóa các dòng liên quan đến user này trong /etc/sudoers và thư mục /etc/sudoers.d/.

Bước 4: Khóa tài khoản và vô hiệu hóa shell

sudo usermod -L -s /usr/sbin/nologin <username>

Bước 5: Xóa cronjob cá nhân

sudo crontab -u <username> -r

Sau khi hoàn tất thu hồi, bạn hãy lưu trữ dữ liệu thư mục /home/<username> nếu cần bàn giao, hoặc xóa hẳn khi đã hết thời gian lưu vết.

Giám sát các hoạt động đăng nhập và sử dụng quyền sudo

Mọi thao tác quản trị đặc quyền cần để lại dấu vết rõ ràng để phục vụ việc điều tra khi có sự cố. Trên Ubuntu, hệ thống ghi nhận toàn bộ hoạt động đăng nhập và các câu lệnh thực thi qua sudo vào system journal.

Một số câu lệnh kiểm tra thực tế:

# Xem lịch sử các lần đăng nhập gần nhất
last -a -n 20

# Kiểm tra các lần đăng nhập SSH gần đây
sudo journalctl -u ssh --since "yesterday"

# Tra cứu lịch sử các lệnh đã được thực thi bằng sudo
sudo journalctl -g "sudo" --since "yesterday"

Khi theo dõi log, hãy chú ý đến các dấu hiệu bất thường:

• Các lần thử đăng nhập SSH thất bại dồn dập từ các IP lạ.
• Các lệnh sudo bị báo lỗi từ chối quyền (authentication failure hoặc user không nằm trong sudoers).
• Sự xuất hiện của các lệnh sudo lạ vào những khung giờ ngoài giờ làm việc.

Việc kết hợp giám sát log này cùng với hệ thống cảnh báo vận hành toàn diện đã được mô tả chi tiết trong bài Nên monitoring những gì trên một VPS chạy website?.

Checklist rà soát bảo mật tài khoản định kỳ

Thực hiện kiểm tra danh sách này trong quy trình quản trị VPS hàng tháng để đảm bảo hệ thống luôn trong tầm kiểm soát:

• ☐ Toàn bộ tài khoản có shell hợp lệ đều được định danh rõ ràng người sở hữu hoặc dịch vụ phụ trách.
• ☐ Không có người dùng nào dùng chung tài khoản đăng nhập hoặc chia sẻ private key.
• ☐ Đăng nhập từ xa bằng tài khoản root đã bị tắt hoàn toàn (PermitRootLogin no trong sshd_config).
• ☐ Xác thực mật khẩu qua SSH đã được tắt, chỉ cho phép SSH key (PasswordAuthentication no).
• ☐ Danh sách thành viên nhóm sudo chỉ bao gồm những người trực tiếp chịu trách nhiệm vận hành.
• ☐ Mọi tệp cấu hình trong /etc/sudoers và /etc/sudoers.d/ đều vượt qua kiểm tra cú pháp của visudo -c.
• ☐ Các quyền NOPASSWD (nếu có) được giới hạn chặt chẽ theo từng lệnh cụ thể, không dùng ALL.
• ☐ Các tài khoản dịch vụ chạy web (www-data) tuyệt đối không có quyền sudo.
• ☐ Đã thu hồi toàn diện tài khoản, SSH key và tiến trình ngầm của các nhân sự đã rời dự án.
• ☐ Luôn kiểm tra quyền truy cập trên một cửa sổ terminal mới trước khi đóng phiên làm việc hiện tại.
• ☐ Thông tin truy cập Web Console / Rescue Mode của nhà cung cấp VPS luôn sẵn sàng để xử lý sự cố khẩn cấp.

Bảo mật máy chủ không phải là một đích đến cố định, mà là một quy trình vận hành kỷ luật. Bằng cách kiểm soát chặt chẽ từng tài khoản và duy trì nguyên tắc đặc quyền tối thiểu, bạn đã loại bỏ phần lớn nguy cơ xâm nhập và sự cố thao tác nhầm trên hệ thống của mình.

Nguồn tham khảo

• Ubuntu Server Documentation — User Management
• Ubuntu Manpages — sudoers
• Ubuntu Manpages — visudo
• OpenSSH Manual — sshd_config
• Sudo project — Sudoers manual and security policies