Phân quyền và quản lý truy cập server cho team: mô hình tối thiểu

Team bạn có 5 người cùng biết mật khẩu root của server production. Một ngày đẹp trời, ai đó chạy nhầm lệnh xóa, và không ai biết ai đã làm — vì log chỉ ghi "root". Nghe quen không? Bài viết này trình bày mô hình phân quyền server tối thiểu: đủ gọn để team nhỏ triển khai trong một ngày, nhưng đủ chặt để mỗi hành động trên server đều có chủ nhân rõ ràng, theo đúng nguyên tắc quyền tối thiểu (least privilege).

Phân quyền server: vì sao "ai cũng có root" là con đường nhanh nhất đến thảm họa

Dùng chung tài khoản root cho cả team tạo ra ba rủi ro lớn. Thứ nhất, mất dấu vết kiểm toán: mọi lệnh đều ghi nhận dưới tên root, khi sự cố xảy ra bạn không thể xác định ai đã chạy lệnh nào, vào lúc nào. Thứ hai, không thể thu hồi quyền cá nhân: khi một thành viên rời team, bạn buộc phải đổi mật khẩu root và thông báo lại cho tất cả mọi người còn lại — quy trình vừa phiền phức vừa dễ sót. Thứ ba, mở rộng bề mặt tấn công: mật khẩu càng nhiều người biết, càng nhiều nơi lưu trữ (note, chat, email), nguy cơ lộ càng cao; chỉ cần một máy tính cá nhân của thành viên bị nhiễm mã độc là kẻ tấn công có ngay quyền cao nhất. Nguyên tắc thay thế rất đơn giản: mỗi người một tài khoản riêng, mỗi tài khoản chỉ có đúng quyền cần cho công việc của mình.

Phân quyền server: nguyên tắc vàng: quyền tối thiểu (least privilege)

Least privilege nghĩa là mỗi người dùng, mỗi tiến trình chỉ được cấp đúng mức quyền tối thiểu để hoàn thành nhiệm vụ — không hơn. Áp dụng vào quản trị server, nguyên tắc này thể hiện qua bốn quyết định: ai được đăng nhập vào server nào (phạm vi truy cập), đăng nhập bằng tài khoản gì (định danh riêng), được chạy những lệnh gì (phạm vi quyền), và trong khung thời gian nào (quyền tạm thời cho công việc đột xuất). Lợi ích không chỉ là bảo mật: khi quyền được phân định rõ, team cũng ít giẫm chân nhau hơn — developer không vô tình restart service của database, người vận hành không vô tình deploy đè code đang chạy. Hãy coi least privilege như "dây an toàn": ban đầu hơi vướng, nhưng là thứ cứu bạn khi có sự cố.

Phân quyền server: mô hình 4 vai trò tối thiểu cho team nhỏ

Thay vì cấp quyền theo từng cá nhân (khó quản lý khi team lớn lên), hãy định nghĩa vai trò (role) rồi gán người vào vai trò. Với team 3–15 người, 4 vai trò sau là đủ:

Người kiêm nhiều vai trò thì được gán nhiều role — nhưng luôn gán theo role, không cấp quyền lẻ tẻ cho cá nhân. Khi team lớn hơn, bạn có thể tách nhỏ thêm (ví dụ tách deploy và vận hành), nhưng đừng bắt đầu với 10 role phức tạp: mô hình càng đơn giản càng dễ duy trì kỷ luật.

Mỗi người một tài khoản riêng, tuyệt đối không dùng chung

Đây là thay đổi nền tảng nhưng ít tốn kém nhất. Trên mỗi server Linux, tạo một user riêng cho từng thành viên (ví dụ useradd -m nguyenvana), đặt họ vào group tương ứng với vai trò. Xóa thói quen share tài khoản "admin", "deploy", "ubuntu" dùng chung — nếu ứng dụng cần một service account để chạy tự động, đó phải là tài khoản kỹ thuật không ai đăng nhập trực tiếp, với quyền bị giới hạn chặt. Lợi ích thấy ngay: log hệ thống (/var/log/auth.log, journalctl) ghi rõ ai đăng nhập lúc nào, chạy lệnh sudo gì; khi có sự cố, bạn truy vết trong vài phút thay vì phỏng đoán. Với server Windows, nguyên tắc tương tự: mỗi người một tài khoản domain/local riêng, nhóm quyền theo role, không dùng chung Administrator.

SSH key thay mật khẩu, tắt đăng nhập root từ xa

Mật khẩu có thể bị đoán mò (brute-force), SSH key thì praktisch không. Quy trình chuẩn: mỗi thành viên tự tạo cặp khóa trên máy cá nhân, gửi public key cho quản trị viên để thêm vào ~/.ssh/authorized_keys của user tương ứng trên server; private key không bao giờ rời khỏi máy cá nhân và nên đặt passphrase. Sau khi tất cả đã đăng nhập được bằng key, cấu hình SSH server: tắt đăng nhập bằng mật khẩu (PasswordAuthentication no), tắt đăng nhập trực tiếp bằng root (PermitRootPassword no hoặc PermitRootLogin no), đổi port mặc định nếu muốn giảm log rác (không phải biện pháp bảo mật thực sự), và bật xác thực đa yếu tố cho các server quan trọng. Lưu ý: giữ một phương án truy cập dự phòng (console qua KVM/IPMI của nhà cung cấp) để không bị khóa ngoài khi key gặp sự cố.

Sudo có giới hạn: cấp quyền theo lệnh, không cấp ALL

Sai lầm phổ biến là cho mọi thành viên vào group sudo với quyền ALL=(ALL) ALL — thực chất đó vẫn là "ai cũng có root", chỉ khác tên gọi. Sudo đúng cách là cấp quyền theo từng lệnh cụ thể trong file /etc/sudoers.d/ riêng cho từng role. Ví dụ: role vận hành chỉ được systemctl restart/start/stop một số service nhất định và xem log; role DBA chỉ được chạy lệnh backup/restore database; chỉ sysadmin mới có quyền rộng — và ngay cả sysadmin cũng nên dùng tài khoản thường ngày, chỉ sudo khi cần. Mẹo thực tế: bật log đầy đủ cho sudo để mọi lệnh nâng quyền đều được ghi lại kèm người thực hiện; định kỳ rà soát file sudoers vì đây là nơi quyền hạn "phình" nhanh nhất theo thời gian.

Quy trình cấp quyền khi có người mới và thu hồi khi người nghỉ

Phân quyền chỉ hiệu quả khi đi kèm quy trình nhân sự. Khi có người mới: quản trị viên tạo user, gán role theo mô tả công việc đã được quản lý phê duyệt, cấp SSH key, và ghi nhận vào danh sách truy cập tập trung (một file hoặc bảng đơn giản cũng được, miễn là luôn cập nhật). Khi có người nghỉ việc hoặc chuyển team: thu hồi ngay trong ngày — xóa user hoặc khóa tài khoản (usermod -L), xóa SSH key khỏi mọi server, thu hồi khỏi các group sudo, đổi các mật khẩu dùng chung mà người đó từng biết (database, service account), và rà soát log xem có truy cập bất thường trong những ngày cuối không. Với quyền tạm thời (ví dụ thuê ngoài xử lý sự cố), luôn đặt thời hạn hết hiệu lực và có người nội bộ giám sát phiên làm việc.

Ghi log và giám sát mọi hành động quản trị

"Tin nhưng vẫn kiểm chứng" — hệ thống phân quyền cần đi kèm giám sát. Tối thiểu, hãy đảm bảo: log đăng nhập SSH được lưu tập trung và giữ ít nhất 90 ngày; mọi lệnh sudo được ghi lại đầy đủ; có cảnh báo khi phát hiện đăng nhập từ IP lạ, đăng nhập thất bại liên tiếp, hoặc user thường ngày bỗng chạy lệnh quản trị bất thường. Với team lớn hơn hoặc hệ thống quan trọng, cân nhắc giải pháp quản lý truy cập đặc quyền (PAM) hoặc bastion host: mọi người chỉ đăng nhập qua một cổng duy nhất, mọi phiên làm việc được ghi hình/ghi log, và bạn có một điểm duy nhất để thu hồi quyền. Đừng quên kiểm thử định kỳ: mỗi quý, rà soát một lần danh sách user trên từng server production và đối chiếu với danh sách nhân sự hiện tại — tài khoản "ma" của người đã nghỉ là lỗ hổng kinh điển.

Checklist triển khai mô hình tối thiểu trong một ngày

Buổi sáng: (1) Liệt kê toàn bộ server và ai đang có quyền truy cập — bạn sẽ bất ngờ về số lượng. (2) Định nghĩa 4 role và gán mỗi thành viên vào role phù hợp, có quản lý phê duyệt. (3) Tạo user riêng cho từng người trên từng server, xóa các tài khoản dùng chung. Buổi chiều: (4) Thu thập public key của mọi người, cấu hình SSH key-only, tắt đăng nhập root và mật khẩu. (5) Viết file sudoers giới hạn theo role, kiểm thử từng role đăng nhập và chạy đúng lệnh được phép. (6) Bật log tập trung cho SSH và sudo, thiết lập cảnh báo cơ bản. Cuối ngày: (7) Lập danh sách truy cập chính thức, đặt lịch rà soát hàng quý, và viết quy trình cấp/thu hồi quyền thành tài liệu 1 trang để lần sau không phải làm lại từ đầu. Tổng thời gian cho team 5–10 người với vài server thường chỉ trong một ngày làm việc.

Kết luận

Phân quyền server không cần phức tạp: mỗi người một tài khoản riêng, đăng nhập bằng SSH key, quyền giới hạn theo 4 vai trò (sysadmin, vận hành, DBA, giám sát), sudo cấp theo lệnh cụ thể thay vì ALL, và quy trình cấp/thu hồi quyền gắn với vòng đời nhân sự. Mô hình tối thiểu này giải quyết được 80% rủi ro truy cập của team nhỏ với chi phí triển khai chỉ một ngày công. Bước tiếp theo: ngay tuần này, hãy liệt kê ai đang có quyền root trên server production của bạn — đó là điểm bắt đầu của mọi cải tiến.

Nếu hạ tầng của bạn đang chạy trên SunCloud, việc quản lý truy cập càng thuận tiện: portal quản trị tập trung giúp bạn quản lý nhiều Cloud Server/VPS, tính năng snapshot cho phép chụp nhanh trạng thái trước mỗi thay đổi quản trị, và đội ngũ kỹ thuật 24/7/365 sẵn sàng hỗ trợ khi bạn cần tư vấn cấu hình phân quyền an toàn. Để được tư vấn mô hình phân quyền phù hợp với quy mô team của bạn, liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn.

Câu hỏi thường gặp

Team chỉ có 2–3 người có cần phân quyền phức tạp không?

Không cần phức tạp, nhưng vẫn cần nguyên tắc cơ bản: mỗi người một tài khoản riêng, SSH key thay mật khẩu, không dùng chung root. Với team nhỏ, bạn có thể gộp role (ví dụ một người vừa sysadmin vừa DBA) nhưng vẫn duy trì tài khoản riêng và log đầy đủ — vì rủi ro lớn nhất của team nhỏ là "tưởng không cần" cho đến khi sự cố xảy ra.

Có nên cho developer quyền truy cập server production không?

Nên hạn chế. Developer thường chỉ cần quyền deploy qua pipeline CI/CD tự động và quyền xem log để debug — không cần SSH trực tiếp vào production. Nếu bắt buộc cấp, hãy dùng role read-only hoặc quyền giới hạn theo lệnh, có thời hạn, và mọi phiên truy cập đều được log. Môi trường staging nên là nơi developer được quyền rộng rãi hơn.

SSH key bị mất thì xử lý thế nào?

Ngay lập tức xóa public key tương ứng khỏi authorized_keys trên mọi server, tạo cặp khóa mới cho thành viên đó, và kiểm tra log xem có dấu hiệu key bị lạm dụng không. Đây cũng là lý do private key nên đặt passphrase và không lưu trên máy dùng chung — mất key có passphrase thì kẻ nhặt được cũng khó sử dụng.

Bastion host là gì và khi nào cần dùng?

Bastion host là một server trung gian: mọi người chỉ SSH vào bastion, từ đó mới nhảy tiếp vào các server nội bộ — server nội bộ không mở SSH ra Internet. Nên dùng khi bạn có từ 5 server trở lên hoặc hệ thống chứa dữ liệu nhạy cảm, vì nó tập trung log, kiểm soát truy cập và thu hồi quyền tại một điểm duy nhất.

Nên dùng mật khẩu sudo hay cấu hình NOPASSWD?

Với môi trường production, nên yêu cầu nhập mật khẩu khi sudo (hoặc ít nhất với các lệnh nhạy cảm) để tránh trường hợp ai đó ngồi vào máy đang mở sẵn terminal là có ngay quyền root. NOPASSWD chỉ nên dùng cho các service account chạy tự động, với lệnh được giới hạn rất hẹp.

Làm sao phát hiện tài khoản "ma" của nhân viên đã nghỉ?

Định kỳ hàng quý, đối chiếu danh sách user trên từng server (/etc/passwd, group sudo) với danh sách nhân sự hiện tại của công ty. Bất kỳ tài khoản nào không còn tương ứng với nhân sự đang làm việc đều phải bị khóa hoặc xóa ngay. Tự động hóa việc này bằng script kiểm tra là cách tốt nhất để không bị sót khi số lượng server tăng lên.

Nguồn tham khảo: - MuaChungTool – Hướng dẫn quản lý user và phân quyền file (chmod/chown) trên Linux - vqvinh1909/linux – Role Separation và Least Privilege trong triển khai doanh nghiệp