Quản lý user và sudo trên VPS: cấp và thu hồi quyền
Quản lý tài khoản VPS cần biết ai có quyền, quyền đến từ đâu và cách thu hồi khi nhiệm vụ kết thúc. Một root password chung cho cả đội làm khó đối chiếu thay đổi và xử lý khi một người không còn tham gia dự án.

Quản lý tài khoản VPS cần biết ai có quyền, quyền đến từ đâu và cách thu hồi khi nhiệm vụ kết thúc. Một root password chung cho cả đội làm khó đối chiếu thay đổi và xử lý khi một người không còn tham gia dự án.
Phân biệt ba loại tài khoản
| Loại | Phạm vi nên thiết kế |
|---|---|
| Cá nhân quản trị | Định danh người dùng, key riêng và sudo phù hợp |
| Dịch vụ ứng dụng | Chạy process với quyền cần thiết |
| Khẩn cấp | Truy cập phục hồi được kiểm soát và ghi nhận |
Tài khoản dịch vụ không nên được cấp sudo toàn bộ chỉ để tiện deploy. Tài khoản cá nhân cũng cần mức quyền phù hợp nhiệm vụ. Quyền đọc secret, Docker socket hoặc sửa file chạy bằng root có thể mạnh không kém sudo; phải kiểm tra ngoài group.
Bước 1: kiểm kê
getent passwd
getent group sudo
who
sudo -lLệnh getent passwd có cả tài khoản hệ thống; không xóa tài khoản chỉ vì không nhận ra tên. sudo -l xem quyền của tài khoản đang chạy. Khi kiểm tra một user cụ thể, dùng sudo -l -U TEN_USER, thay TEN_USER bằng tên thật và chạy với quyền đủ.
- Tài khoản nào thuộc người quản trị còn hoạt động?
- SSH key nào có chủ rõ ràng?
- Có sudoers/drop-in hoặc nhóm quyền mạnh nào?
- Ai giữ secret, token deploy và truy cập console?
- Nguồn tài khoản có LDAP/SSO hay chỉ local?
Bước 2: cấp user riêng
sudo adduser opsadmin
sudo usermod -aG sudo opsadminVí dụ Ubuntu này cấp quyền quản trị mạnh cho opsadmin; đổi tên và chỉ thêm group sudo nếu cần quyền đó. Thử phiên đăng nhập mới, key và sudo trước khi hạn chế tài khoản bàn giao cũ.
Bước 3: thay sudoers đúng công cụ
Dùng visudo hoặc visudo -f cho drop-in cần sửa để có kiểm tra cú pháp. Không append bằng lệnh shell không kiểm tra rồi đóng phiên quản trị. Với quyền lệnh giới hạn, đánh giá cả khả năng lệnh mở shell, sửa file hoặc gọi chương trình khác.
sudo visudo -cKiểm tra cú pháp không chứng minh chính sách ít quyền. Một rule NOPASSWD rộng có thể tăng rủi ro nếu key bị mất. Chỉ dùng theo yêu cầu và đánh giá tác động.
Bước 4: thu hồi đầy đủ
- Xác nhận người/tài khoản kết thúc nhiệm vụ và công việc còn phụ thuộc.
- Thu hồi key, chứng chỉ SSH hoặc quyền SSO tương ứng.
- Gỡ quyền sudo/group và credential dịch vụ đã được cấp.
- Đánh giá phiên đang mở, cron và process theo chính sách.
- Chuyển quyền sở hữu file/backup cần giữ.
- Thử tài khoản còn lại và ghi nhận bàn giao.
Ubuntu lưu ý khóa password chưa chắc chặn mọi phương thức truy cập như SSH key. Không dùng passwd -l như bằng chứng user đã mất toàn bộ quyền. Xóa user cũng cần đánh giá file và process; tránh tùy tiện xóa home có dữ liệu dự án.
Quyền file và secret
Không dùng chmod -R 777 để sửa lỗi quyền ứng dụng. Xác định user chạy process, group cần chia sẻ và đường dẫn thật sự cần ghi. Secret cần được giữ ngoài browser/repository và chỉ cấp cho dịch vụ cần dùng.
Lập lịch kiểm kê định kỳ và sau thay đổi nhân sự. Lưu thông tin chủ key và nhiệm vụ nhưng không lưu private key trong bảng phân quyền. Nếu nghi key lộ, cần thay secret liên quan và điều tra phạm vi thay vì chỉ xóa một public key.
Khi thuê VPS, xác nhận quyền console và tài khoản hỗ trợ của nhà cung cấp. Phân quyền ứng dụng vẫn là phần riêng ngoài quyền OS.
Khóa password có ngăn SSH key không?
Không thể mặc định. Cần thu hồi key và các phương thức xác thực/quyền truy cập khác.
Thành viên group Docker có quyền nhạy cảm không?
Có. Truy cập Docker daemon/socket cần được đánh giá như quyền mạnh trên host theo cấu hình.
Cần máy chủ cho workload này?
NOC thuemaychu.vn hỗ trợ chọn CPU, GPU và băng thông. PoC trong 24 giờ.
Bài viết liên quan
Bảo mậtChống DDoS cho máy chủ dedicated: lớp L3/L4/L7 thực tế
Phân biệt chống nghẽn đường truyền và chống quá tải ứng dụng; xác định trách nhiệm nhà cung cấp và đội vận hành.
Cloud VPSDedicated Server hay VPS: khi nào nên thuê máy chủ riêng?
Chọn VPS hay dedicated dựa trên tải, giới hạn dịch vụ, ngân sách và yêu cầu kiểm soát; không mặc định mọi doanh nghiệp cần máy vật lý.
Bảo mậtCloudflare Organizations: CTO cần biết trước khi gom tài khoản
Cloudflare mở Organizations ngày 07/10/2026. Bài dành cho CTO muốn quản lý nhiều tài khoản, với checklist quyền truy cập, giới hạn và thử nghiệm trước khi triển khai.