Bảo mật SSH và SFTP khi quản trị website WordPress

SSH và SFTP là kênh quản trị mạnh hơn wp-admin. Chúng cho phép sửa file, đọc cấu hình và chạy lệnh trên máy chủ; vì vậy phải quản lý khóa, tài khoản, sudo và log như quyền đặc biệt.

Mỗi người một tài khoản và khóa riêng

Không chia sẻ root password hoặc một private key cho cả đội. Tài khoản cá nhân giúp thu hồi đúng người và giữ audit trail. Khóa phải có passphrase, được lưu trong agent/manager phù hợp.

Tắt đăng nhập không cần thiết

Ưu tiên key authentication, tắt password login sau khi đã kiểm thử kênh dự phòng và hạn chế root login trực tiếp. Thay đổi SSH port chỉ giảm nhiễu, không thay thế xác thực mạnh.

Giới hạn nguồn và đặc quyền

Dùng firewall, VPN, bastion hoặc allowlist khi phù hợp. Sudo chỉ cấp lệnh cần thiết; tác vụ deploy không nên mặc định có toàn quyền hệ thống.

Quản lý host key và fingerprint

Khi client cảnh báo host key thay đổi, không bấm bỏ qua theo thói quen. Xác minh qua kênh đáng tin cậy vì đây có thể là server được dựng lại hoặc dấu hiệu xen giữa kết nối.

Thu hồi khóa có quy trình

Lập danh sách public key, owner, thiết bị và ngày hết hạn. Khi nhân sự rời dự án hoặc máy tính mất, xóa key trên mọi server, thu hồi token CI/CD và rà login gần nhất.

Ghi log và phát hiện bất thường

Theo dõi login thành công/thất bại, IP, sudo, thay authorized_keys và truyền file bất thường. Đồng bộ thời gian và đẩy log ra ngoài server để attacker khó xóa dấu vết.

Khi nghi private key bị lộ

Thu hồi key, khóa session, tạo key mới trên thiết bị sạch và rà command, file, cron, user, tunnel quanh thời điểm truy cập. Đừng chỉ thay key mà bỏ qua persistence đã được cài.

Một private key bị sao chép không phát ra tiếng động

Mật khẩu bị đổi có thể khiến người dùng chú ý; private key bị sao chép vẫn hoạt động bình thường trên máy của chủ sở hữu. Kẻ tấn công có thể chờ nhiều tuần rồi đăng nhập từ hạ tầng khác. Nếu server không ghi log và không có inventory key, đội ngũ khó biết đó là ai.

Vì vậy, “key authentication” không tự động đồng nghĩa an toàn. Giá trị nằm ở key riêng cho từng người, passphrase, thiết bị được bảo vệ, thời hạn và khả năng thu hồi. Một key chung lưu trong nhóm chat chỉ là mật khẩu dùng chung ở hình thức khác.

Phân biệt tài khoản con người và tài khoản triển khai

Người vận hành cần session tương tác; CI/CD chỉ cần một số lệnh và đường dẫn. Dùng chung một key root cho cả hai làm mất dấu vết và khiến pipeline bị lộ có toàn quyền server. Service account nên bị giới hạn command, thư mục, nguồn kết nối và thời gian sử dụng khi khả thi.

Cảnh báo host key không phải hộp thoại phiền phức

Khi fingerprint thay đổi, có ba khả năng: server được dựng lại, DNS/IP trỏ sang máy khác, hoặc kết nối đang bị can thiệp. Xóa dòng trong known_hosts để tiếp tục mà không xác minh sẽ bỏ qua chính cơ chế bảo vệ danh tính máy chủ.

Tình huống nhân sự rời dự án

Chỉ xóa tài khoản hosting là chưa đủ nếu public key còn nằm trong nhiều user, bastion, deploy server hoặc repository secret. Checklist offboarding cần tìm mọi nơi key/token đã được cấp, thu hồi session, xoay secret dùng chung và rà login sau thời điểm bàn giao.

Nhật ký nào giúp dựng lại sự việc?

• Thời gian, IP và user của phiên SSH thành công/thất bại.
• Lệnh sudo, thay đổi user/group và chỉnh authorized_keys.
• File được truyền hoặc thay đổi quanh thời điểm nghi vấn.
• Process, tunnel, cron và service mới xuất hiện.
• Sự kiện từ firewall, VPN hoặc bastion liên quan.

Giữ lối thoát trước khi siết cấu hình

Nhiều đội tắt password và root login ngay trên phiên SSH duy nhất rồi tự khóa mình khỏi server. Thay đổi bảo mật phải được kiểm tra bằng một phiên thứ hai, có console hoặc kênh cứu hộ của nhà cung cấp và bản sao cấu hình. Nếu dùng firewall allowlist, hãy xác nhận IP vận hành không thay đổi ngoài dự kiến.

Sự cẩn thận này không làm giảm mức an toàn. Nó giúp doanh nghiệp siết quyền mà vẫn kiểm soát được rủi ro vận hành — đặc biệt quan trọng khi server đang phục vụ khách hàng và một lần mất truy cập có thể kéo dài hàng giờ.