Bảo mật người dùng khác nhau trong Linux: Hướng dẫn cho đội IT

Giới thiệu

Trong bài viết trước, chúng ta đã thảo luận về cách truy cập một ứng dụng Linux qua SSH và các phương pháp bảo mật SSH. Bây giờ, chúng ta sẽ chuyển sự chú ý sang việc bảo mật người dùng của những hệ thống này. Hầu hết các môi trường Linux mà tôi thiết lập thường có hai loại người dùng chính: Quản trị viên Linux và Quản trị viên ứng dụng. Những vai trò này thường liên quan đến các chiến lược tăng cường bảo mật đơn giản. Tuy nhiên, điều gì xảy ra khi có thêm các loại người dùng khác được giới thiệu vào hệ thống?

Mục lục

1. Giới thiệu
2. Bảo mật có phải giống nhau cho tất cả không?
3. Thay đổi mật khẩu và khóa tài khoản
4. Máy tính di động và thiết bị cầm tay
5. Người dùng doanh nghiệp
6. Nhà phát triển và quản trị ứng dụng
7. Quản trị viên hệ thống
8. Kết luận

Ngoài các quản trị viên, các tổ chức thường có người dùng doanh nghiệp từ các phòng ban như tài chính, bán hàng, hành chính, nhân sự và tiếp thị, những người được giao các thiết bị cá nhân. Ngoài ra, còn có các thiết bị sử dụng chung như máy tính di động, súng RF, máy quét mã vạch và máy quét QR, có thể được sử dụng bởi nhiều người dùng khác nhau. Chúng ta cũng có nhà phát triển ứng dụng chịu trách nhiệm xây dựng và duy trì phần mềm, và quản trị viên hệ thống—dù họ là Kỹ sư Đám mây, Kỹ sư DevOps hay Kỹ sư Độ tin cậy của trang web—những người cần truy cập sâu vào hệ điều hành để thực hiện các thay đổi ở mức hệ thống. Mỗi loại người dùng này tương tác với hệ điều hành và ngăn xếp ứng dụng theo những cách khác nhau, và do đó, mỗi loại yêu cầu các cân nhắc bảo mật được tùy chỉnh.

Bảo mật có phải giống nhau cho tất cả không?

Có vẻ như thảo luận về mô hình bảo mật phân tầng người dùng là lỗi thời, nhưng những cuộc trò chuyện này vẫn rất có liên quan. Các đội IT nhằm đảm bảo rằng các khoản đầu tư cơ sở hạ tầng của tổ chức vẫn được bảo mật, trong khi các nhà lãnh đạo doanh nghiệp cố gắng tạo ra một môi trường thân thiện cho người dùng của họ. Cả hai mục tiêu đều hợp lệ, và việc tìm kiếm sự cân bằng là điều cần thiết.

Một ví dụ lớn về sự căng thẳng này có thể thấy ở các thiết bị di động và cầm tay. Nhu cầu kinh doanh thường thúc đẩy việc sử dụng mật khẩu đơn giản hơn do bàn phím nhỏ và tập ký tự hạn chế, trong khi các đội IT lại xem những thiết bị này là tài sản có nguy cơ cao, cần kiểm soát nghiêm ngặt hơn. Trong các bài viết tiếp theo, chúng ta sẽ tiếp tục khám phá cách giải quyết những ưu tiên trái ngược này và áp dụng các phương pháp tốt nhất.

Thay đổi mật khẩu và khóa tài khoản

Mật khẩu đang trải qua một sự thay đổi trong triết lý quản lý. NIST SP 800-63B nhấn mạnh mật khẩu mạnh hơn và giám sát vi phạm hơn là các mô hình hết hạn truyền thống. Tuy nhiên, nhiều tổ chức vẫn tiếp tục sử dụng chính sách hết hạn từ 60 đến 90 ngày. Quan trọng hơn, nhưng thường bị bỏ qua, là khóa tài khoản—một lĩnh vực then chốt có thể để lại các hệ thống dễ bị tấn công bởi các tài khoản không hoạt động.

Tất cả người dùng có nên có cùng một chính sách mật khẩu và tài khoản không? Ban đầu, câu trả lời của tôi là không, nhưng sau khi phân tích kỹ lưỡng, tình huống đã cho thấy nhiều khía cạnh hơn.

Máy tính di động và thiết bị cầm tay

Những thiết bị này thường được xem là có nguy cơ cao nhất, nhưng tôi đã ngạc nhiên khi phát hiện rằng các phương pháp tốt nhất khuyến nghị không thay đổi mật khẩu hoặc một khoảng thời gian xoay vòng từ 180 đến 365 ngày, và rằng tài khoản không bao giờ hết hạn. Khi xem xét các yêu cầu vận hành, điều này có ý nghĩa. Đây là những công cụ quan trọng cho doanh nghiệp, và việc giới thiệu thay đổi mật khẩu thường xuyên có thể ảnh hưởng đến năng suất.

Để giảm thiểu rủi ro, cần có các biện pháp kiểm soát bổ sung ở phía Linux:

• Ứng dụng được truy cập qua SSH nên là một phiên bản rút gọn chỉ cung cấp các chức năng thiết yếu.
• Sử dụng chỉ thị Match và ForceCommand trong cấu hình SSH để hạn chế hành động của người dùng.
• Nếu những thiết bị này hoạt động trong một mạng con riêng biệt, các khối SSH Match nên phản ánh sự phân đoạn mạng đó.

Trong một cuộc họp gần đây, tôi đã thấy mình suy nghĩ giống như một quản trị viên ứng dụng hơn là một quản trị viên Linux. Khi bạn lùi lại và đánh giá những thực tiễn này:

• Hạn chế lệnh của người dùng,
• Đảm bảo người dùng vẫn ở trong sandbox ứng dụng,
• Giám sát nhật ký SSH thường xuyên,

…thì trở nên rõ ràng tại sao những sự dễ dãi này tồn tại—dù nó vẫn cảm thấy phản trực giác từ một góc độ bảo mật nghiêm ngặt.

# Tài khoản không bao giờ hết hạn
sudo usermod -e '' username

# Vô hiệu hóa hoàn toàn việc thay đổi mật khẩu
sudo chage -M 99999 username

# Yêu cầu thay đổi mật khẩu mỗi 180 ngày
sudo chage -M 180 username

Người dùng doanh nghiệp

Các khuyến nghị bảo mật cho người dùng doanh nghiệp phù hợp hơn với mong đợi. Mật khẩu thường hết hạn mỗi 60–90 ngày, nếu sử dụng chính sách hết hạn mật khẩu. Việc hết hạn tài khoản thường được quyết định bởi tình trạng việc làm của người dùng:

• Nhân viên mùa vụ hoặc tạm thời: Tài khoản được đặt để hết hạn vào ngày kết thúc.
• Nhà thầu: Thời gian hết hạn tài khoản phù hợp với ngày kết thúc hợp đồng.
• Nhân viên chính thức: Khóa tài khoản được ưa thích hơn là hết hạn, đặc biệt sau 45 ngày không hoạt động, hoặc khi người dùng bị sa thải, nghỉ phép, hoặc tài khoản nghi ngờ bị xâm phạm.

# Khóa tài khoản bằng passwd
sudo passwd -l username

# Hoặc khóa tài khoản bằng usermod
sudo usermod -L username

# Mở khóa tài khoản bằng passwd
sudo passwd -u username

# Hoặc mở khóa tài khoản bằng usermod
sudo usermod -U username

Multi-factor authentication (MFA) và xác thực SSH key ở cấp độ người dùng doanh nghiệp vẫn còn hiếm. Điều này không phải do các hạn chế kỹ thuật trong Linux, mà là do rào cản chính sách nhân sự và thách thức về logistics trong việc phân phối thiết bị xác thực bên ngoài cho người dùng không kỹ thuật.

Nhà phát triển và quản trị ứng dụng

Các nhà phát triển ứng dụng và người dùng cấp độ quản trị thường hoạt động trên nhiều môi trường và có quyền truy cập mở rộng, khiến họ trở thành mục tiêu có giá trị cao cho các cuộc tấn công. Do đó, yêu cầu bảo mật của họ nghiêm ngặt hơn:

• Nhà thầu: Thời gian hết hạn tài khoản phù hợp với ngày kết thúc hợp đồng.
• Thời gian hết hạn mật khẩu thường được đặt từ 30–60 ngày.
• Giống như người dùng doanh nghiệp, việc khóa tài khoản được ưa thích hơn là hết hạn, lý tưởng là sau 30 đến 45 ngày không hoạt động.

# Khóa không hoạt động trong 30 ngày
sudo chage -I 30 username

Xác thực dựa trên SSH key và MFA là phổ biến và được mong đợi trong nhóm này, vì những người dùng này thường có kỹ năng kỹ thuật để quản lý việc tạo và xoay vòng key.

Quản trị viên hệ thống

Các chính sách bảo mật cho quản trị viên hệ thống còn nghiêm ngặt hơn. Ngạc nhiên là các phương pháp tốt nhất khuyến nghị thời gian hết hạn mật khẩu trong 15–30 ngày, ngắn hơn bất kỳ điều gì mà tôi từng gặp trước đây. Do quyền truy cập sâu vào cơ sở hạ tầng, các quản trị viên thường dựa vào:

• Nhà thầu: Thời gian hết hạn tài khoản phù hợp với ngày kết thúc hợp đồng.
• Kho mật khẩu để lưu trữ và xoay vòng an toàn,
• Khóa xác thực SSH hoặc chứng chỉ SSH có thời gian ngắn,
• MFA bắt buộc, ngày càng được coi là yêu cầu cơ bản.

Khóa tài khoản một lần nữa được ưa thích hơn hết hạn, trong khoảng thời gian 15–30 ngày không hoạt động.

# Tìm tài khoản không hoạt động không đăng nhập trong 30 ngày qua
sudo lastlog -b 30

Kết luận

Mặc dù nhiều điều tôi khám phá phù hợp với mong đợi, nhưng cũng có một số bất ngờ. Suy ngẫm về sự cần thiết của bài viết này—vâng, nó hoàn toàn cần thiết. Qua nhiều tổ chức mà tôi đã làm việc, và trong các cuộc trò chuyện với đồng nghiệp, rõ ràng rằng các chính sách bảo mật người dùng tiêu chuẩn thường không được tài liệu hóa.

Các thực tiễn này nên được xem như là các ngưỡng tối thiểu—các giới hạn thấp mà các tổ chức nên phấn đấu để đạt được. Từ đó, các chính sách bảo mật bổ sung có thể và nên được bổ sung, tùy thuộc vào độ nhạy cảm của môi trường, tư thế rủi ro và yêu cầu kinh doanh. Chìa khóa là coi những khuyến nghị này không phải là một giới hạn tối đa mà là một nền tảng để xây dựng.

Bước đầu tiên trong việc thắt chặt bảo mật người dùng là tài liệu hóa các thực tiễn hiện tại và xác định các tiêu chuẩn để hướng tới. Thường thì, khoảng cách giữa tư thế bảo mật hiện tại và mong muốn cảm thấy rất áp lực, nhưng việc thực hiện các cải tiến nhỏ, từng bước có thể dần dần thu hẹp khoảng cách đó. Trong bài viết tiếp theo, chúng ta sẽ đi sâu vào các chiến lược chính sách mật khẩu đa tầng.

Cần chuyên môn về Linux? Tôi giúp các doanh nghiệp tối ưu hóa máy chủ, bảo mật cơ sở hạ tầng và tự động hóa quy trình làm việc. Dù bạn đang khắc phục sự cố, tối ưu hóa hay xây dựng từ đầu—tôi luôn sẵn sàng hỗ trợ.

📬 Gửi bình luận hoặc email cho tôi để hợp tác. Để biết thêm hướng dẫn, công cụ và thông tin, hãy truy cập sebostechnology.com.

☕ Bạn thấy bài viết này hữu ích chứ?
Hãy xem xét việc hỗ trợ nhiều nội dung như thế này bằng cách mời tôi một ly cà phê:
Mời Tôi Một Ly Cà Phê
Sự hỗ trợ của bạn giúp tôi viết thêm nhiều mẹo, hướng dẫn và thông tin sâu về Linux.