Quản lý User Linux VPS theo nguyên tắc tối thiểu quyền

Trên Linux VPS, mỗi tài khoản người dùng là một điểm truy cập vào hệ thống. Khi số lượng tài khoản có thể đăng nhập ngày càng nhiều, rủi ro bị tấn công cũng tăng theo. Nếu một tài khoản bị lộ thông tin xác thực hoặc bị khai thác, mức độ thiệt hại sẽ phụ thuộc trực tiếp vào quyền mà tài khoản đó đang nắm giữ. Vì vậy, quản lý user và permission theo nguyên tắc Least Privilege là một trong những biện pháp nền tảng để giảm thiểu rủi ro bảo mật.

Nguyên tắc này yêu cầu mỗi user và mỗi process chỉ được cấp đúng phạm vi quyền cần thiết để hoàn thành nhiệm vụ của mình, không nhiều hơn và cũng không ít hơn. Trong môi trường vận hành thực tế, rất nhiều VPS vẫn đang đi ngược nguyên tắc này: quản trị viên đăng nhập trực tiếp bằng root, tài khoản deploy có toàn quyền sudo, ứng dụng chạy dưới quyền root, và những account cũ không còn sử dụng vẫn còn tồn tại. Chỉ cần một mắt xích bị compromise, toàn bộ máy chủ có thể bị kiểm soát.

User Linux VPS Least Privilege

Bài viết này tập trung vào các bước kiểm tra và siết quyền user trên Linux VPS, bao gồm audit tài khoản có shell access, rà soát quyền sudo, kiểm tra file SUID/SGID, và tổ chức service account theo mô hình tách biệt. Mục tiêu là giúp bạn xây dựng một hệ thống dễ kiểm soát hơn, khó bị leo thang đặc quyền hơn, và an toàn hơn trong vận hành dài hạn.

Least Privilege trên Linux VPS là gì?

Least Privilege có thể hiểu là “quyền tối thiểu cần thiết”. Một user chỉ nên được phép thực hiện những thao tác phục vụ công việc của chính user đó. Một process cũng chỉ nên truy cập đúng file, thư mục, hoặc command mà nó thực sự cần dùng.

Trong quản trị Linux, nguyên tắc này thường được áp dụng vào các tình huống sau:

Không dùng root cho các thao tác thường xuyên nếu không thật sự cần thiết.
Không cấp sudo toàn phần cho mọi user vận hành.
Không để ứng dụng web, tiến trình nền, hoặc job tự động chạy bằng root.
Không giữ lại các tài khoản cũ đã ngừng sử dụng nhưng vẫn còn shell access.
Không cho một tài khoản quyền truy cập vượt quá phạm vi nhiệm vụ của nó.

Lợi ích lớn nhất của mô hình này là giới hạn phạm vi thiệt hại. Nếu một tài khoản ứng dụng bị xâm nhập, kẻ tấn công chỉ có thể thao tác trong phạm vi quyền của tài khoản đó thay vì chiếm toàn bộ VPS. Đây là khác biệt rất lớn giữa một sự cố cục bộ và một sự cố mất quyền kiểm soát hệ thống.

Kiểm tra user hiện có trên server

Bước đầu tiên là xác định trên hệ thống hiện có những user nào có khả năng đăng nhập shell. Không phải mọi dòng trong /etc/passwd đều là tài khoản đáng lo ngại, vì nhiều user hệ thống được tạo ra chỉ để chạy dịch vụ và không có shell thật. Điều cần tập trung là các user có thể đăng nhập tương tác.

Để lọc ra các user không dùng nologin hoặc false, sử dụng lệnh sau:

cat /etc/passwd | grep -v nologin | grep -v false

Kết quả có thể trông như sau:

root:x:0:0:root:/root:/bin/bash
thach:x:1000:1000::/home/thach:/bin/bash
deploy:x:1001:1001::/home/deploy:/bin/bash
olduser:x:1002:1002::/home/olduser:/bin/bash

Danh sách này cho bạn cái nhìn ban đầu về các tài khoản có shell access. Với từng user xuất hiện, cần đặt ra một số câu hỏi quan trọng:

User này là ai?
Hiện còn được sử dụng không?
Tại sao user này cần shell access?
User này có quyền sudo hay không?
Nếu có sudo, phạm vi sudo là gì?

Nếu bạn bắt gặp một tài khoản lạ, không rõ nguồn gốc hoặc không nhớ đã từng tạo, đó là tín hiệu cần điều tra ngay. Không nên giả định rằng đó chỉ là account hệ thống vô hại nếu user đó có shell thực sự.

Kiểm tra lần đăng nhập gần nhất của user

Khi nghi ngờ một tài khoản cũ không còn cần thiết, việc xem lịch sử đăng nhập là bước xác minh hữu ích. Bạn có thể dùng lệnh:

last olduser

Lệnh này giúp xác định user đó có còn hoạt động gần đây hay không. Nếu tài khoản đã không đăng nhập trong thời gian dài, không phục vụ tác vụ nào rõ ràng, và vẫn còn shell access, đây là ứng viên nên vô hiệu hóa hoặc xóa bỏ sau khi xác nhận với đội vận hành.

Không nên giữ các account “để phòng khi cần”. Trên máy chủ production, mọi tài khoản tồn tại đều phải có mục đích rõ ràng, người chịu trách nhiệm cụ thể và quyền hạn được kiểm soát.

Audit quyền sudo để phát hiện đặc quyền quá mức

Biết user nào có shell access mới chỉ là một nửa bức tranh. Phần còn lại là xác định ai có thể leo lên quyền root thông qua sudo. Trên Linux, một user có sudo rộng thường gần như tương đương root về mặt rủi ro bảo mật.

Trước tiên, kiểm tra file sudoers chính và loại bỏ comment cũng như dòng trống:

grep -v '^#' /etc/sudoers | grep -v '^$'

Ngoài file chính, nhiều hệ thống còn đặt rule bổ sung trong thư mục /etc/sudoers.d/. Cần kiểm tra cả thư mục này:

ls -la /etc/sudoers.d/
cat /etc/sudoers.d/*

Trong nhiều tình huống, cách nhanh nhất để biết user nào đang có sudo là kiểm tra membership của group quản trị mặc định theo từng họ hệ điều hành:

Trên Ubuntu/Debian:

getent group sudo

Trên CentOS/AlmaLinux:

getent group wheel

Nếu output cho thấy nhiều user cùng nằm trong group sudo hoặc wheel, đó là dấu hiệu cần rà soát lại. Việc cấp full sudo cho quá nhiều tài khoản khiến mọi lớp phòng thủ phía trên gần như mất ý nghĩa, vì chỉ cần compromise một account là attacker có thể mở rộng quyền ngay lập tức.

Những điểm cần xem khi audit sudo

User nào đang có quyền sudo toàn phần?
Quyền được cấp thông qua group hay rule riêng?
Có rule nào cho phép chạy command quá rộng như ALL=(ALL) ALL không?
Có tài khoản automation, deploy hoặc CI/CD nào được cấp sudo không giới hạn không?
Có file nào trong /etc/sudoers.d/ được thêm thủ công nhưng không còn phù hợp nữa không?

Audit sudo không chỉ để giảm quyền, mà còn để hiểu rõ luồng vận hành hiện tại. Nhiều hệ thống tồn tại các rule “tạm thời” nhưng sau đó bị quên, dẫn tới quyền bị mở rộng âm thầm trong thời gian dài.

Cấp sudo theo command cụ thể thay vì full access

Đây là một trong những kỹ thuật quan trọng nhất khi triển khai Least Privilege trên Linux VPS. Thay vì cấp cho user quyền sudo toàn phần, hãy chỉ cho phép chạy đúng các command cần thiết.

Ví dụ, user deploy chỉ cần restart nginx và php-fpm, đồng thời reload nginx trong quá trình triển khai. User này không cần quyền cài package, chỉnh sửa user khác, hay thao tác toàn bộ hệ thống bằng root.

Tạo một file rule riêng bằng:

visudo -f /etc/sudoers.d/deploy

Nội dung cấu hình:

# User deploy — chỉ được restart nginx và php-fpm
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart php*-fpm
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx

Ý nghĩa của từng phần:

deploy: user áp dụng rule.
ALL=(ALL): có thể thực thi từ mọi host và với quyền của bất kỳ user nào theo rule được cho phép.
NOPASSWD:: không yêu cầu nhập password khi chạy các command này, phù hợp cho automation hoặc CI/CD.
Phần cuối là command được phép chạy, bắt buộc dùng đường dẫn tuyệt đối.

Sau khi tạo rule, có thể kiểm tra lại chính xác user đó được phép làm gì bằng lệnh:

sudo -l -U deploy

Output sẽ liệt kê các command mà user deploy có thể chạy với sudo. Đây là cách xác minh rất hữu ích sau khi thay đổi cấu hình.

Tại sao phải dùng đường dẫn tuyệt đối trong sudoers?

Khi khai báo command trong sudoers, luôn dùng full path như /usr/bin/systemctl. Không nên chỉ ghi systemctl. Nếu rule không chỉ rõ đường dẫn tuyệt đối, sẽ phát sinh nguy cơ bị lợi dụng thông qua việc đặt một binary giả mạo cùng tên ở vị trí khác trong môi trường thực thi. Trong bối cảnh attacker đã kiểm soát được user, đây là một đường tắt nguy hiểm để thực thi mã với quyền cao hơn.

Chỉ nên cấp NOPASSWD khi thật sự cần cho automation. Với user đăng nhập tương tác, việc yêu cầu password khi dùng sudo vẫn là một lớp kiểm soát bổ sung có giá trị.

Kiểm tra file SUID/SGID để phát hiện đường leo thang đặc quyền

Ngoài user và sudo, một khu vực thường bị bỏ sót là các file có bit SUID hoặc SGID. Đây là các permission đặc biệt có thể tạo ra cơ chế thực thi với quyền cao hơn quyền của user đang chạy.

Với SUID, khi một file được thực thi, tiến trình sẽ chạy với quyền của owner file, thường là root. SGID hoạt động tương tự nhưng áp dụng theo group. Một số file SUID/SGID là hợp lệ và cần thiết cho hệ thống, nhưng nếu có file lạ hoặc file cũ không còn cần thiết vẫn giữ bit này, đó là rủi ro privilege escalation rất phổ biến.

Để tìm toàn bộ file SUID trên server:

find / -perm -4000 -ls 2>/dev/null

Để tìm file SGID:

find / -perm -2000 -ls 2>/dev/null

Kết quả trả về sẽ là danh sách tất cả file đang mang các bit đặc biệt này. Khi rà soát, cần xem xét kỹ từng mục:

File có thuộc hệ thống hay không?
File có thực sự cần SUID/SGID không?
File nằm ở thư mục chuẩn của hệ điều hành hay ở vị trí bất thường?
Đó có phải binary do ứng dụng hoặc người dùng tự thêm vào không?

Một số file hệ thống như /usr/bin/passwd, /usr/bin/sudo thường là bình thường. Tuy nhiên, nếu xuất hiện file lạ ở vị trí không thuộc package hệ thống, đây là dấu hiệu rất đáng ngờ.

Gỡ bỏ bit SUID/SGID khi không cần thiết

Nếu xác định một file không nên giữ đặc quyền này, có thể xóa bit tương ứng:

# Xóa SUID
chmod u-s /path/to/file

# Xóa SGID
chmod g-s /path/to/file

Trước khi thay đổi trên production, cần xác nhận file đó không phải thành phần phụ thuộc của ứng dụng hoặc của hệ điều hành. Việc gỡ SUID/SGID sai chỗ có thể làm một số chức năng ngừng hoạt động.

Tạo baseline để theo dõi thay đổi định kỳ

Một cách quản trị tốt là lưu danh sách file SUID hiện tại làm mốc chuẩn, sau đó so sánh định kỳ để phát hiện file mới xuất hiện.

Tạo baseline:

find / -perm -4000 -type f 2>/dev/null | sort > /root/suid-baseline.txt

So sánh về sau:

find / -perm -4000 -type f 2>/dev/null | sort | diff /root/suid-baseline.txt -

Nếu xuất hiện chênh lệch mà bạn không chủ động tạo ra, cần kiểm tra ngay. Đây có thể là thay đổi hợp lệ sau khi cài package mới, nhưng cũng có thể là dấu hiệu bị cài cắm công cụ leo thang đặc quyền.

Tách service account: mỗi ứng dụng một user riêng

Một sai lầm phổ biến trên VPS là để nhiều dịch vụ cùng chạy bằng root. Web server, ứng dụng Node.js, cron job, script deploy, thậm chí cả tiến trình phụ trợ đều mang quyền cao nhất. Khi đó, bất kỳ lỗ hổng nào trong một thành phần cũng có thể dẫn thẳng đến quyền root.

Cách tiếp cận an toàn hơn là tách mỗi ứng dụng hoặc nhóm chức năng thành một user riêng. User này chỉ nên có quyền trên đúng thư mục, file và tác vụ mà service cần dùng. Điều này giúp cô lập rủi ro giữa các thành phần của hệ thống.

Ví dụ về nguyên tắc tổ chức:

Ứng dụng web chạy bằng user riêng của ứng dụng.
Tài khoản deploy chỉ dùng để triển khai mã nguồn.
Cron job có quyền giới hạn theo nhiệm vụ.
Dịch vụ hệ thống tiếp tục dùng account hệ thống mặc định nếu phù hợp.

Khi mỗi app có user riêng, nếu một ứng dụng bị khai thác, attacker sẽ khó truy cập sang dữ liệu hoặc tiến trình của ứng dụng khác. Đây là lớp cô lập rất quan trọng trên các VPS chạy nhiều website hoặc nhiều service cùng lúc.

Nguyên tắc thiết kế quyền cho service account

Không cấp shell access nếu service không cần đăng nhập tương tác.
Không thêm service account vào group sudo hoặc wheel.
Chỉ cấp quyền đọc/ghi đúng thư mục ứng dụng cần sử dụng.
Không dùng chung một user cho nhiều ứng dụng không liên quan.
Không để process ứng dụng chạy bằng root nếu không có yêu cầu bắt buộc.

Mô hình này đặc biệt quan trọng với môi trường có CI/CD, nơi tài khoản deploy thường xuyên tương tác với mã nguồn, package và dịch vụ đang chạy. Nếu deploy account bị lộ SSH key hoặc token, việc giới hạn quyền sẽ quyết định liệu sự cố chỉ dừng ở một ứng dụng hay lan ra toàn bộ máy chủ.

Quy trình audit user và quyền nên thực hiện định kỳ

Least Privilege không phải là thao tác làm một lần rồi bỏ đó. Hệ thống luôn thay đổi: nhân sự thay đổi, ứng dụng được thêm mới, rule sudo được mở rộng, package mới được cài, và service account được tạo ra cho nhu cầu tạm thời. Nếu không audit định kỳ, quyền sẽ dần bị phình to theo thời gian.

Một quy trình rà soát thực tế nên bao gồm:

Liệt kê toàn bộ user có shell access.
Xác minh từng user còn cần thiết hay không.
Kiểm tra thời điểm đăng nhập gần nhất với các account nghi ngờ ít dùng.
Rà soát toàn bộ rule trong /etc/sudoers và /etc/sudoers.d/.
Kiểm tra membership của group sudo hoặc wheel.
Xác minh user nào đang có full sudo và thay bằng rule theo command nếu có thể.
Quét file SUID/SGID và đối chiếu với baseline.
Đánh giá lại các service account: có đang chạy bằng root không, có shell access không, có quyền vượt nhu cầu không.

Tần suất thực hiện có thể theo chu kỳ hàng tháng hoặc sau mỗi thay đổi lớn của hệ thống. Với VPS production, audit sau khi onboard hoặc offboard nhân sự cũng là việc rất nên làm.

Các dấu hiệu cấu hình quyền đang có vấn đề

Dưới đây là những biểu hiện thường gặp cho thấy hệ thống chưa tuân thủ tốt nguyên tắc tối thiểu quyền:

Nhiều người cùng SSH trực tiếp bằng root.
Hầu hết user vận hành đều có ALL=(ALL) ALL.
Tài khoản deploy có thể chạy mọi lệnh root.
Account cũ không còn sử dụng nhưng vẫn tồn tại và có shell.
Ứng dụng web hoặc job tự động chạy bằng root.
Không có baseline cho file SUID nên khó phát hiện thay đổi bất thường.
Không ai biết rõ một số rule trong /etc/sudoers.d/ được tạo từ khi nào và để làm gì.

Nếu hệ thống của bạn có nhiều hơn một dấu hiệu trong danh sách này, rất có thể quyền đang được cấp rộng hơn mức cần thiết. Việc siết lại nên được ưu tiên trước khi xảy ra sự cố.

Lỗi thường gặp khi siết quyền và cách xử lý

Xóa quyền quá nhanh làm gián đoạn vận hành

Một số quản trị viên thấy user cũ hoặc rule sudo rộng là xóa ngay lập tức. Cách làm này có thể gây lỗi deploy, lỗi automation hoặc khiến service không khởi động lại được. Trước khi thay đổi, hãy xác định chính xác luồng sử dụng thực tế và kiểm tra lại bằng sudo -l -U username với các user liên quan.

Dùng sudoers sai cú pháp

Chỉnh trực tiếp file sudoers mà không dùng công cụ phù hợp có thể khiến cấu hình sudo bị lỗi. Khi cần tạo rule riêng, nên dùng:

visudo -f /etc/sudoers.d/deploy

Cách này giúp giảm nguy cơ lưu file sai cú pháp và làm mất khả năng dùng sudo.

Quên dùng đường dẫn tuyệt đối cho command

Đây là lỗi rất nguy hiểm. Nếu command trong sudoers không có full path, rule có thể bị lợi dụng. Luôn khai báo như /usr/bin/systemctl thay vì chỉ ghi systemctl.

Nhầm lẫn giữa user hệ thống và user có shell thật

Nhiều tài khoản trong /etc/passwd là account phục vụ dịch vụ và không có khả năng đăng nhập. Vì vậy, cần lọc đúng các user có shell access thay vì hoảng hốt khi thấy danh sách user dài.

Kết luận

Quản lý user Linux VPS theo nguyên tắc Least Privilege không chỉ là một khuyến nghị bảo mật, mà là yêu cầu thiết yếu để vận hành hệ thống an toàn. Mỗi tài khoản có shell, mỗi rule sudo, mỗi file SUID/SGID và mỗi service chạy sai quyền đều có thể trở thành điểm khởi đầu cho một cuộc tấn công leo thang đặc quyền.

Một hệ thống được kiểm soát tốt là hệ thống mà bạn biết rõ:

Ai có thể đăng nhập.
Ai có thể dùng sudo.
Ai được phép chạy command nào.
Dịch vụ nào đang chạy bằng user nào.
Những file đặc quyền nào tồn tại trên máy chủ.

Hãy bắt đầu từ những việc cơ bản nhưng có tác động lớn: audit user có shell, rà soát group sudo hoặc wheel, thay full sudo bằng rule theo command cụ thể, kiểm tra SUID/SGID định kỳ, và tách riêng service account cho từng ứng dụng. Khi quyền được cấp đúng mức cần thiết, bạn không chỉ giảm rủi ro bị chiếm toàn bộ VPS mà còn khiến hệ thống minh bạch, dễ audit và dễ vận hành hơn về lâu dài.

Quản Lý User Linux VPS Theo Nguyên Tắc Least Privilege