Drupal bảo trì và vận hành: Vì sao “không cập nhật” lại là rủi ro lớn nhất?

Khi hỏi các khách hàng đang chi trả chi phí bảo trì hàng tháng rằng: “Cụ thể với khoản chi phí đó, bên cung cấp đang thực hiện những công việc gì?”, không ít trường hợp không thể trả lời ngay được. Nhiều hợp đồng bảo trì thường được giải thích là “một dạng bảo hiểm phòng khi có sự cố xảy ra.”
Tuy nhiên, đối với website, việc bảo trì theo kiểu “không có gì xảy ra thì không làm gì cả” không thể được xem là một hình thức bảo hiểm. Bởi vì Drupal có một đặc điểm là bản thân việc không cập nhật đã là một rủi ro.
Trong bài viết này, chúng tôi sẽ tổng hợp các hạng mục thực sự cần thiết trong công tác bảo trì Drupal và sắp xếp chúng theo mức độ ưu tiên trong thực tế.

Điều gì khiến Drupal không thể “để đó là xong”?
Drupal có một đội ngũ bảo mật chuyên trách. Khi phát hiện lỗ hổng bảo mật, thông tin sẽ được công bố dưới dạng Security Advisory (SA).
Điều quan trọng nằm ở đây. SA không chỉ thông báo rằng có lỗ hổng bảo mật tồn tại mà còn công khai nội dung của lỗ hổng đó. Điều này có nghĩa là ngay khi bản vá được phát hành, thông tin về “lỗ hổng nằm ở đâu và có đặc điểm như thế nào” cũng được công khai trên phạm vi toàn cầu. Nói cách khác, các website không được cập nhật sẽ trở thành mục tiêu có thể bị tấn công dựa trên chính những thông tin đã được công bố.

Các số liệu thực tế đã cho thấy điều đó. Drupal 7 chính thức kết thúc hỗ trợ vào ngày 05/01/2025, nhưng ngay trước thời điểm đó vẫn còn khoảng 290.000 website (tương đương khoảng 40% tổng số website Drupal) đang tiếp tục sử dụng Drupal 7. Những website bị bỏ mặc chỉ vì “vẫn đang hoạt động” hiện đang ở trong trạng thái rủi ro cao nhất.

Nguồn: webtechsurvey, Drupal 7 EOL PSA-2025-01-06

4 hạng mục ưu tiên cao nhất
Các hạng mục bảo trì rất đa dạng, nhưng trước hết có 4 hạng mục mà nếu ngừng thực hiện sẽ dễ dẫn đến sự cố trực tiếp.
① Theo dõi và áp dụng Security Advisory (SA) (bao gồm Core và toàn bộ module) – Đối tượng cần theo dõi không chỉ là Drupal Core mà còn là tất cả các Contrib module đang được sử dụng. Trên thực tế, lỗ hổng bảo mật thường được phát hiện ở phía module nhiều hơn là ở Core. Thông thường, các lỗ hổng mức Critical cần được xử lý trong vòng 24 giờ, mức High trong vòng 1 tuần theo SLA. Trước khi áp dụng vào môi trường production, các bản cập nhật luôn phải được kiểm tra trên môi trường staging.　
② Backup và “kiểm tra khôi phục” (restore test) – Có rất nhiều doanh nghiệp thực hiện backup, nhưng lại rất ít doanh nghiệp thực sự thử khôi phục dữ liệu. Cần lưu trữ đầy đủ bộ ba gồm database, file và configuration tại một vị trí tách biệt với môi trường production, đồng thời thực hiện kiểm tra khôi phục và xác nhận hoạt động thực tế ít nhất một lần mỗi năm.
③ Theo dõi các bản cập nhật minor của Core – Drupal 10 và Drupal 11 đều phát hành các phiên bản minor định kỳ, và mỗi phiên bản đều có thời hạn hỗ trợ riêng. Nếu không theo kịp các bản cập nhật này, hệ thống sẽ dần nằm ngoài phạm vi được nhận các bản vá bảo mật.
④ Quản lý tính tương thích của phiên bản PHP – Mỗi phiên bản Drupal chỉ hỗ trợ một số phiên bản PHP nhất định, trong khi bản thân PHP cũng có vòng đời hỗ trợ (EOL). Vì vậy, mọi kế hoạch nâng cấp hoặc thay đổi máy chủ cần được chia sẻ với đội ngũ bảo trì ngay từ đầu.

Những rủi ro cần lưu ý
Đây là những điểm thường bị bỏ sót trong quá trình bảo trì, nhưng lại có thể dẫn đến hậu quả nghiêm trọng.
⁃ “Có backup” và “có thể khôi phục từ backup” là hai việc hoàn toàn khác nhau. Tình huống nghiêm trọng nhất là khi xảy ra sự cố, doanh nghiệp cố gắng khôi phục hệ thống nhưng lại phát hiện file backup đã bị hỏng.
⁃ Đối với các module không còn sử dụng, hãy gỡ cài đặt (uninstall) thay vì chỉ vô hiệu hóa (disable). Nếu vẫn để chúng tồn tại trong hệ thống, chúng sẽ trở thành một bề mặt tấn công tiềm ẩn.
⁃ Các thiết lập phân quyền cũng có xu hướng ngày càng phức tạp trong quá trình vận hành. Đặc biệt cần kiểm tra xem các role của anonymous user và authenticated user có đang được cấp những quyền không cần thiết hay không. Đây là một trong những nguyên nhân điển hình dẫn đến rò rỉ thông tin cá nhân.
⁃ Các lỗi liên quan đến cron thường diễn ra âm thầm. Chúng có thể khiến chỉ mục tìm kiếm không được cập nhật, cache không được xóa hoặc email không được gửi đi, trong khi trên giao diện website vẫn không có dấu hiệu bất thường nào. Nếu không theo dõi log hệ thống, đội ngũ bảo trì gần như không thể phát hiện ra những vấn đề này.

Xu hướng thị trường Nhật Bản
⁃ Công tác bảo trì và vận hành hiện đang ngày càng trở nên quan trọng dưới góc độ bảo mật và tuân thủ (compliance).
⁃ Sau khi Drupal 7 chính thức hết vòng đời hỗ trợ (EOL) vào ngày 05/01/2025, khoảng 40% website chưa hoàn tất migration vẫn tiếp tục phải đối mặt với các thông tin lỗ hổng được công bố công khai thông qua Security Advisory (SA).
⁃ Drupal được sử dụng rộng rãi trong các lĩnh vực đòi hỏi mức độ bảo mật cao như cơ quan nhà nước, trường đại học và tổ chức tài chính. Trong những lĩnh vực này, chất lượng của công tác bảo trì cũng chính là chất lượng của việc đáp ứng các yêu cầu tuân thủ.
Do Drupal có tần suất cập nhật tương đối cao, việc làm thế nào để tối ưu hóa quá trình kiểm tra hồi quy (regression testing) sau mỗi lần cập nhật sẽ ảnh hưởng trực tiếp đến chi phí bảo trì dài hạn.

TTV và năng lực bảo trì Drupal trong thực tế
Đến nay, chúng tôi đã tham gia xây dựng mới và bảo trì hơn 10 website Drupal trong nhiều lĩnh vực khác nhau như eCommerce, website doanh nghiệp, healthcare và hệ thống quản lý hospitality.
Ngoài ra, các chuyên gia Drupal của chúng tôi đã công bố 20 Contrib module cho cộng đồng Drupal dựa trên những nhu cầu phát sinh từ các dự án thực tế. Hai ví dụ tiêu biểu bao gồm:
⁃ Context Breadcrumb – Module cho phép định nghĩa breadcrumb động dựa trên context hiển thị của Drupal.
⁃ Node Preview Context – Module giải quyết vấn đề các điều kiện context của node không được đánh giá chính xác trên màn hình preview.
Danh sách module đã công bố: [drupal.org/u/zipme_hkt](https://www.drupal.org/u/zipme_hkt)
Việc là đơn vị trực tiếp phát triển và công bố module mang lại lợi thế thực tế trong công tác bảo trì. Khi một Security Advisory (SA) được công bố, đội ngũ có thể nhanh chóng đánh giá phạm vi ảnh hưởng và xác định mức độ tác động của lỗ hổng đối với hệ thống.

SLA hỗ trợ

Tất cả các bản cập nhật đều phải được kiểm tra trên môi trường staging trước khi được triển khai lên môi trường production.

Kết luận
Chủ đề chính của bài viết này là: “Bảo trì không có nghĩa là không làm gì cả.”
⁃ Đối với website, bản thân việc không cập nhật đã là một rủi ro (vì nội dung của các lỗ hổng sẽ được công khai thông qua Security Advisory – SA).
⁃ Bốn hạng mục cần được ưu tiên hàng đầu là: theo dõi và áp dụng SA (cho Core và toàn bộ module), kiểm tra khả năng khôi phục từ backup, theo dõi các bản cập nhật minor của Core và quản lý tính tương thích của PHP.
⁃ “Có backup” và”có thể khôi phục từ backup” là hai việc hoàn toàn khác nhau.
⁃ Ngay cả sau khi Drupal 7 hết vòng đời hỗ trợ (EOL), khoảng 40% website vẫn chưa hoàn tất migration. Việc bỏ mặc hệ thống sẽ khiến rủi ro âm thầm tích lũy theo thời gian.
⁃ Đến nay, chúng tôi đã xây dựng và bảo trì hơn 10 website Drupal, đồng thời cam kết xử lý các sự cố Critical trong vòng 24 giờ.
Chúng tôi cũng cung cấp dịch vụ đánh giá sức khỏe bảo trì (maintenance health check) cho các website đang vận hành, bao gồm cả các hệ thống được xây dựng bởi đơn vị khác.
Nếu bạn quan tâm đến công tác bảo trì và vận hành Drupal, hãy liên hệ với chúng tôi để được tư vấn.

Nguồn tham khảo
Drupal Security Advisories
Thông báo Drupal 7 End of Life (EOL)
Drupal usage statistics
Hồ sơ đóng góp Drupal