đăng nhập root hoặc người dùng sudo để quản trị máy chủ?

Tôi đang cố gắng hiểu các đối số kỹ thuật/ý nghĩa bảo mật giữa ssh'ing trực tiếp với root hoặc tạo người dùng sudo phụ trợ trong ngữ cảnh duy trì máy chủ. Để làm rõ, chúng ta đang nói về các máy chủ thuộc sở hữu của một quản trị viên. Đối với nhiều người làm việc trên máy, rõ ràng là có lợi ích theo dõi kiểm tra khi có những người dùng duy nhất cho mỗi người thực và các quyền chi tiết.

Tôi nghĩ là, nếu đây là một trạm máy tính để bàn, thì nên sử dụng người dùng không phải root cho các công việc hàng ngày, nhưng trên máy chủ, bạn thường đăng nhập để duy trì nó và 99% số lần tất cả các hoạt động của bạn đều yêu cầu root quyền hạn.

Vì vậy, có bất kỳ lợi ích bảo mật nào trong việc tạo người dùng "proxy" mà bạn sẽ sudo để root thay vì trực tiếp cung cấp quyền truy cập ssh vào root không?

Lợi ích duy nhất tôi có thể nghĩ đến là bảo mật thông qua che khuất, tức là các bot thường cố gắng thăm dò người dùng "root". Nhưng theo quan điểm của tôi, nếu người dùng của sudoers bị xâm phạm, điều đó cũng giống như xâm phạm người dùng root, vì vậy trò chơi kết thúc.

Ngoài ra, hầu hết các khung quản trị từ xa, hệ thống NAS, trình ảo hóa, khuyến khích sử dụng người dùng root để đăng nhập web.

Một điều cần xem xét: Nếu sử dụng khóa SSH để xác thực từ xa, điều gì sẽ xảy ra nếu khóa riêng tư bị xâm phạm?

Nếu root: quyền truy cập root bị xâm phạm. Hy vọng bạn không sử dụng khóa đó để truy cập root trên nhiều máy.

Nếu người dùng: Người dùng đó bị xâm nhập. Tuy nhiên, kẻ tấn công có thể không chạy được sudo vì mật khẩu của người dùng không bị xâm phạm. Chưa. (Giả sử rằng cần có mật khẩu để sử dụng sudo)

Vẫn là một tình huống tồi tệ, nhưng có thể là một tình huống tốt hơn. (Cũng tốt hơn một chút nếu bạn sử dụng cụm mật khẩu cho các khóa SSH của bạn)

Đối với tất cả các mục đích sử dụng, tôi thực sự khuyên bạn nên không dùng nguồn gốc; thậm chí để vô hiệu hóa nó nếu có thể. Tôi thường xuyên tắt root trên các máy chủ Linux/UNIX. Người dùng gốc không thể được rào lại, hành động của nó không được ghi lại. Ít nhất, một lệnh sudo sẽ được ghi lại, rất hữu ích trong trường hợp quản trị viên xử lý sai. Bạn cũng có thể cấp quyền chi tiết cho người dùng, chỉ cấp một số đặc quyền. Tất nhiên với root bị vô hiệu hóa, không thể ghi nhật ký ssh bằng root.

Theo kinh nghiệm, root chỉ bị bỏ sót trong trường hợp bạn cần khởi động ở chế độ một người dùng hoặc khởi động khẩn cấp; một tình huống hiếm gặp khi máy chủ không thể khởi động đúng cách. Nhưng nếu đúng như vậy, bạn có thể kích hoạt nó, thay đổi mật khẩu và tiến hành khôi phục.
Một trường hợp khác là để sao chép các tệp bằng sftp (hoặc ftp, tất nhiên nên tránh, trừ khi chỉ trong các mạng nội bộ), nơi bạn cần sao chép trực tiếp vào/từ các thư mục chỉ với quyền root. Trong trường hợp này, bạn có thể sử dụng ACL để cấp quyền cho người dùng khác và tiếp tục.

trên một máy chủ, bạn thường đăng nhập để duy trì nó và 99% trường hợp tất cả các hoạt động của bạn đều yêu cầu quyền root.

Tôi muốn tranh luận về điều này. Có nhiều tác vụ thường ngày chỉ cần tra cứu thông tin mà bất kỳ người dùng nào cũng có thể nhìn thấy. "top", "ps", "df", xem nhật ký, v.v.

Hãy tập thói quen chỉ chạy những lệnh cần root với quyền root. Và kiểm tra ba lần các lệnh đó để đảm bảo bạn không viết sai chính tả.

Nếu bạn chạy mọi thứ với quyền root, bạn SẼ trở nên cẩu thả. Nó xảy ra với tất cả mọi người.
Khi cẩu thả, bạn SẼ phạm sai lầm. Nó xảy ra với tất cả mọi người.

Đừng có thói quen đó.

(Tôi cũng đồng ý với những gì một số người khác đã nói về việc bạn là quản trị viên duy nhất hôm nay không có nghĩa là bạn sẽ là quản trị viên duy nhất vào ngày mai)

Tư vấn bảo mật tại đây.

Thực hành tốt nhất trên toàn tất cả các ứng dụng, hệ thống, giải pháp, hệ điều hành và bất kỳ thứ gì khác mà bạn có thể nghĩ đến là chỉ sử dụng tài khoản gốc để thiết lập mọi thứ rồi vô hiệu hóa nó.

Bằng mọi cách, hãy tạo một tài khoản người dùng cá nhân với các đặc quyền của quản trị viên để quản lý hàng ngày, nhưng tài khoản gốc, bất kể nó có thể là gì, nên bị vô hiệu hóa sau khi thiết lập hoàn tất.

Làm xáo trộn tài khoản vẫn không phải là một ý tưởng tồi, tức là không đặt tên cho tài khoản quản trị viên của bạn là quản trị viên nhưng giá trị trong thế giới thực của việc này cực kỳ thấp.Hầu hết các vụ "hack" xảy ra trong nhiều tuần và nhiều tháng thay vì vài giây và vài phút như phương tiện truyền thông/phim/chương trình truyền hình muốn trình bày và bất kỳ ai cũng sẽ có kỹ năng để "hack", bạn cũng sẽ có kỹ năng kiểm tra những thứ như SID quản trị viên windows (luôn là S-1-5-32-544 cho quản trị viên windows tích hợp sẵn).

Đối với hầu hết các công ty, mối quan tâm lớn về bảo mật là bạn cần có dấu vết kiểm tra và trách nhiệm cá nhân.

Các tài khoản (quản trị viên) mặc định như nguồn gốc tài khoản, theo định nghĩa, không phải của cá nhân. Để chúng mở dẫn đến (tương đương với) thực hành bảo mật kém của mật khẩu được chia sẻ và không có trách nhiệm cá nhân/cá nhân.

Thông thường, khi một đồng nghiệp rời công ty, bạn muốn vô hiệu hóa tài khoản của họ và biết rằng điều đó sẽ khóa quyền truy cập của họ.

Bạn không muốn việc rời đi của họ yêu cầu đặt lại mật khẩu (và các tệp ~/.ssh/authorized_keys) của mọi tài khoản gốc và các tài khoản dùng chung khác mà những người rời đi (có thể) đã có quyền truy cập. Đó là công việc quản trị PITA thường không xảy ra, vì vậy bạn cần ngăn điều đó trở thành vấn đề ngay từ đầu.

Vì vậy, ngay cả trong bộ phận CNTT một người, vui lòng thiết lập tài khoản cá nhân cho bạn với tư cách là quản trị viên, cấp cho chính bạn sudo đặc quyền hoặc các vai trò quản trị viên khác và không đăng nhập trực tiếp với quyền root hoặc bất kỳ tài khoản quản trị viên/siêu người dùng mặc định nào khả dụng.

Vì vậy, khi công ty của bạn phát triển và bạn trở thành bộ phận CNTT hai người hoặc bất cứ khi nào bạn rời đi, bạn sẽ không để lại một mớ hỗn độn các đặc quyền quá mức cần được dọn dẹp.

Trong một công việc mới, bạn không muốn dành những ngày làm việc đầu tiên của mình để dọn dẹp “quyền truy cập cửa sau” do người tiền nhiệm để lại, và với tư cách là người nghỉ việc, bạn cũng không cần phải chịu rủi ro về quyền truy cập mà bạn không có… t bị hủy bỏ gây ra vi phạm an ninh.

Giống như tất cả các câu hỏi bảo mật, đó là câu hỏi về khẩu vị rủi ro. Như những người khác đã tuyên bố, SSH với tư cách là người dùng không phải root bằng một khóa và sau đó nâng cấp lên root có nghĩa là có một yếu tố thứ hai đang diễn ra (bạn CÓ khóa, bạn BIẾT mật khẩu), điều này có thể hạn chế bán kính bùng nổ của một thỏa hiệp . Cũng có khía cạnh kiểm toán mà những người khác đã đề cập.

Nếu bạn hài lòng với việc không có lớp bảo vệ bổ sung đó (dù có thể nhẹ), thì hãy làm như bạn muốn.

Hầu hết các hướng dẫn bảo mật đều khuyên bạn nên tắt SSH gốc, chủ yếu vì nó buộc bạn phải cho phép liệt kê quyền của người dùng để làm điều gì đó. Bạn cần có một hành động tích cực để cung cấp cho người dùng đặc quyền sudo. Bạn có thể kiểm soát thêm những hành động mà người dùng có thể thực hiện, do đó, bạn thậm chí có thể có những người dùng riêng biệt cho các tác vụ riêng biệt.Hoặc một người dùng tự động có thể chạy một số lệnh sudo nhất định chứ không phải những lệnh khác.

Dù sao đi nữa - nhiều điểm chuẩn bảo mật khuyến nghị không cho phép SSH và thậm chí không cho phép root từ chính bảng điều khiển. Tôi chỉ tự làm việc này nếu tôi có thể chắc chắn về công cụ sao lưu/xây dựng lại/không thay đổi được của mình, vì nếu không thì không có cách nào để quay lại máy chủ mà không thực hiện một số thủ thuật khởi động CD trực tiếp.

Đây hoàn toàn là một câu hỏi về bảo mật và tiện lợi.

Đăng nhập với quyền root sẽ luôn thuận tiện hơn nhưng kém an toàn hơn đáng kể. Vì vậy, nếu bạn đồng ý với những cảnh báo đó, bạn có thể đăng nhập với quyền root.

Tuy nhiên, công ty của bạn càng lớn, họ sẽ càng coi trọng vấn đề bảo mật hơn.

Ví dụ: công ty hiện tại của tôi là một công ty có hơn 50.000 nhân viên tại 5 quốc gia. Bắt ROOT đăng nhập là hoàn toàn không thể. Và để có được quyền truy cập SUDO cũng mất khoảng 2 tuần, với sự phê duyệt của các cấp Giám đốc.

Nếu bạn đang sử dụng các khóa ssh thì thường khá an toàn khi chỉ cần ssh thẳng vào thư mục gốc thay vì khiến người dùng "Proxy" khó hiểu.