Hệ thống vẫn chạy bình thường không có nghĩa là hệ thống đang an toàn.
Thời gian gần đây, nhiều lỗ hổng bảo mật nghiêm trọng đã được công bố trong hệ điều hành, framework, thư viện phần mềm và các nền tảng công nghệ phổ biến.
Kẻ tấn công có thể lợi dụng một số lỗ hổng này để chạy mã từ xa, chiếm quyền máy chủ, đánh cắp dữ liệu hoặc làm gián đoạn hoạt động của doanh nghiệp. Ngoài ra, AI và các công cụ tự động giúp kẻ tấn công tìm và khai thác lỗ hổng nhanh hơn, trên nhiều hệ thống hơn.
Ngay cả khi mã nguồn không thay đổi, hệ thống vẫn có thể gặp rủi ro bảo mật mới. Vì vậy, doanh nghiệp cần rà soát, cập nhật và giám sát hệ thống thường xuyên, thay vì đợi đến khi có sự cố mới xử lý.
Một số lỗ hổng nghiêm trọng gần đây
| Lỗ hổng | Thành phần bị ảnh hưởng | Mức độ | Tình trạng |
|---|---|---|---|
| PHP2Shell – CVE-2026-109618, CVE-2026-109619 (10/2026) | PHP (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed) | CVSS v4.0 9.2 – chạy mã từ xa mà không cần đăng nhập | Mã khai thác đã được công khai và đã có tấn công thực tế. Bản vá: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| React2Shell – CVE-2025-55182 (12/2025) | React Server Components và các framework dùng RSC như Next.js | CVSS 10.0 – chạy mã từ xa mà không cần đăng nhập | Có trong danh sách CISA KEV. Ứng dụng Next.js dùng cấu hình mặc định cũng bị ảnh hưởng |
| SharePoint – CVE-2026-58644 (07/2026) | Microsoft SharePoint Server | CVSS 9.8 – chạy mã từ xa qua lỗi deserialization | Bị khai thác trước khi Microsoft phát hành bản vá. Có trong danh sách CISA KEV |
| Gitea – CVE-2026-60004 (08/2026) | Gitea (hệ thống quản lý mã nguồn tự host) | CVSS 9.8 – chạy lệnh hệ điều hành trên máy chủ | Có trong danh sách CISA KEV. Đã có máy chủ bị cài mã độc đào tiền ảo |
Các lỗ hổng trên đều nằm trong nền tảng mà ứng dụng sử dụng, không nằm trong mã nguồn do doanh nghiệp tự viết. Một website PHP hoặc Next.js đã chạy ổn định nhiều năm vẫn có thể bị chiếm quyền chỉ vài ngày sau khi lỗ hổng được công bố.
1. Những rủi ro bảo mật doanh nghiệp cần lưu ý
| Thành phần | Rủi ro có thể gặp |
|---|---|
| Hệ điều hành (Linux, Windows) | Leo thang đặc quyền, truy cập trái phép, chiếm quyền máy chủ |
| Ngôn ngữ / Framework (PHP, React, Next.js, Rails, Spring...) | Chạy mã từ xa, vượt qua bước xác thực, rò rỉ dữ liệu |
| Thư viện mã nguồn mở | Thư viện bị chèn mã độc (tấn công chuỗi cung ứng), lỗ hổng trong dependency dẫn tới chạy mã từ xa hoặc rò rỉ dữ liệu |
| Web server / Reverse proxy | Kẻ tấn công lợi dụng lỗ hổng hoặc cấu hình sai để truy cập trái phép |
| Database | Dữ liệu bị lộ, bị sửa hoặc bị xóa |
| Cloud / Hạ tầng | Lộ thông tin xác thực, phân quyền truy cập sai |
| CI/CD và hệ thống quản trị | Kẻ tấn công chiếm quyền triển khai hoặc chèn mã độc vào ứng dụng |
| Con người | Nhân viên bị lừa qua email, lộ mật khẩu hoặc cài nhầm phần mềm độc hại |
Doanh nghiệp cần đặc biệt chú ý đến các hệ thống sau:
- Hệ thống đã vận hành nhiều năm nhưng ít được cập nhật
- Hệ thống không có người phụ trách bảo trì
- Hệ thống dùng phần mềm đã hết hỗ trợ
- Hệ thống có trang quản trị truy cập được từ Internet
- Hệ thống chưa có giám sát hoặc chưa có backup
2. Bảy biện pháp doanh nghiệp nên thực hiện
① Kiểm kê và đánh giá hệ thống
Doanh nghiệp cần nắm rõ mình đang vận hành những gì:
- Lập danh sách máy chủ, ứng dụng, database và dịch vụ cloud đang sử dụng.
- Ghi lại phiên bản hệ điều hành, framework và các thư viện quan trọng.
- Xác định các thành phần đã hết thời hạn hỗ trợ.
- Kiểm tra những dịch vụ nào đang truy cập được từ Internet.
- Phân công người chịu trách nhiệm cho từng hệ thống.
② Kiểm tra lỗ hổng định kỳ
- Quét lỗ hổng cho hệ điều hành, phần mềm máy chủ và thư viện của ứng dụng.
- Rà soát cấu hình bảo mật và theo dõi thông báo bảo mật từ nhà cung cấp.
- Đối chiếu với danh sách CISA – Known Exploited Vulnerabilities Catalog (dữ liệu trên GitHub) để ưu tiên xử lý những lỗ hổng đã bị khai thác thực tế.
- Đánh giá mức độ rủi ro dựa trên khả năng bị khai thác, mức độ hệ thống lộ ra Internet và ảnh hưởng đến hoạt động kinh doanh. Điểm CVSS chỉ là một yếu tố để tham khảo.
③ Cập nhật và vá lỗi kịp thời
- Cài bản vá cho hệ điều hành, framework và thư viện có lỗ hổng.
- Lên kế hoạch thay thế các thành phần đã hết hỗ trợ.
- Nếu có môi trường staging, kiểm thử bản cập nhật trên staging trước khi áp dụng cho production.
- Kiểm tra lại hệ thống sau khi vá.
- Với lỗ hổng nghiêm trọng đang bị khai thác, doanh nghiệp cần xử lý ngay. Nếu nhà cung cấp chưa phát hành bản vá, doanh nghiệp có thể hạn chế truy cập, tắt tính năng bị ảnh hưởng hoặc tách hệ thống ra khỏi mạng.
Lưu ý: Doanh nghiệp không nên cập nhật hàng loạt khi chưa đánh giá tác động, vì việc này có thể gây gián đoạn dịch vụ hoặc lỗi tương thích.
④ Kiểm soát truy cập chặt chẽ hơn
- Không mở dịch vụ quản trị ra Internet nếu không cần thiết.
- Giới hạn nguồn truy cập vào SSH, database và trang quản trị.
- Dùng VPN hoặc một phương thức truy cập an toàn tương đương.
- Bật xác thực đa yếu tố, đặc biệt cho tài khoản quản trị.
- Chỉ cấp quyền vừa đủ cho công việc và thu hồi những quyền không còn dùng.
- Lưu trữ API key, mật khẩu và thông tin xác thực ở nơi an toàn, không để trong mã nguồn.
- Đào tạo nhân viên cách nhận biết email lừa đảo và các thủ đoạn chiếm tài khoản.
⑤ Giám sát và cảnh báo bảo mật
Doanh nghiệp nên theo dõi các dấu hiệu bất thường như: đăng nhập lạ, truy cập trái phép, tệp quan trọng bị thay đổi, tài khoản hoặc tiến trình lạ xuất hiện, kết nối mạng đáng ngờ và các request có dấu hiệu tấn công.
Doanh nghiệp có thể dùng giải pháp SIEM (ví dụ Wazuh) hoặc EDR. Tuy nhiên, chỉ cài công cụ thì chưa đủ. Doanh nghiệp cần có người tiếp nhận, phân tích và xử lý các cảnh báo.
⑥ Sao lưu dữ liệu và thử khôi phục
- Thiết lập backup tự động với tần suất phù hợp với mức độ quan trọng của dữ liệu.
- Lưu bản backup tách biệt khỏi môi trường production. Nếu có thể, hãy dùng backup không sửa/xóa được hoặc backup offline.
- Giới hạn quyền truy cập vào hệ thống backup.
- Thử khôi phục dữ liệu định kỳ và xây dựng quy trình khôi phục khi có sự cố.
Có backup chưa chắc đã khôi phục được dữ liệu. Doanh nghiệp chỉ biết bản backup có dùng được hay không sau khi đã thử khôi phục thành công.
⑦ Xây dựng quy trình quản lý bảo mật thường xuyên
Phát hiện → Đánh giá rủi ro → Ưu tiên → Khắc phục → Kiểm tra lại → Theo dõi
Doanh nghiệp cần phân công rõ ai theo dõi lỗ hổng, ai đánh giá ảnh hưởng, ai khắc phục, ai xác nhận kết quả và ai điều phối khi có sự cố. Với các dự án đang phát triển, nhóm phát triển nên đưa bước kiểm tra bảo mật vào quy trình CI/CD.
3. Checklist: Doanh nghiệp đã sẵn sàng trước rủi ro bảo mật chưa?
| STT | Nội dung kiểm tra | Đã thực hiện |
|---|---|---|
| A | Quản lý hệ thống | |
| 1 | Có danh sách đầy đủ máy chủ, ứng dụng và dịch vụ đang vận hành | ☐ |
| 2 | Nắm được phiên bản hệ điều hành, framework và các thành phần quan trọng | ☐ |
| 3 | Không dùng phần mềm hết hỗ trợ, hoặc đã có biện pháp kiểm soát rủi ro nếu vẫn phải dùng | ☐ |
| B | Quản lý lỗ hổng | |
| 4 | Kiểm tra CVE và lỗ hổng định kỳ | ☐ |
| 5 | Theo dõi cảnh báo bảo mật từ nhà cung cấp | ☐ |
| 6 | Có quy trình ưu tiên và xử lý lỗ hổng nghiêm trọng (ví dụ dựa trên danh sách CISA KEV) | ☐ |
| 7 | Kiểm thử và xác nhận lại hệ thống sau khi vá lỗi | ☐ |
| C | Kiểm soát truy cập | |
| 8 | Dịch vụ quản trị không mở ra Internet khi không cần thiết | ☐ |
| 9 | Tài khoản quản trị được bảo vệ bằng xác thực đa yếu tố | ☐ |
| 10 | Quyền truy cập được giới hạn theo nhu cầu công việc | ☐ |
| 11 | Tài khoản và quyền không còn dùng đã được thu hồi | ☐ |
| 12 | API key và mật khẩu được lưu trữ an toàn, không nằm trong mã nguồn | ☐ |
| 13 | Nhân viên đã được đào tạo cách nhận biết email lừa đảo | ☐ |
| D | Giám sát và phát hiện | |
| 14 | Có thu thập log và giám sát bảo mật | ☐ |
| 15 | Có cảnh báo khi xuất hiện hành vi bất thường | ☐ |
| 16 | Có người chịu trách nhiệm xử lý cảnh báo | ☐ |
| E | Backup và khôi phục | |
| 17 | Có backup tự động và theo dõi kết quả backup | ☐ |
| 18 | Có bản backup tách biệt, được bảo vệ khỏi việc bị xóa/sửa trái phép | ☐ |
| 19 | Đã thử khôi phục dữ liệu định kỳ | ☐ |
| F | Quy trình vận hành | |
| 20 | Có người hoặc đơn vị chịu trách nhiệm bảo trì bảo mật | ☐ |
| 21 | Có quy trình ứng phó sự cố | ☐ |
| 22 | Có bước kiểm tra bảo mật tự động trong CI/CD | ☐ |
| 23 | Có kế hoạch rà soát và cải thiện bảo mật định kỳ | ☐ |
Cách sử dụng checklist
Với mỗi mục chưa đạt, doanh nghiệp nên đánh giá mức độ rủi ro và lập kế hoạch khắc phục. Các trường hợp sau cần được xử lý ngay: đang dùng phần mềm hết hỗ trợ, có lỗ hổng đang bị khai thác, dịch vụ quản trị mở ra Internet, chưa có backup hoặc chưa thử khôi phục, và chưa có người phụ trách bảo mật.
Checklist này chỉ dùng để tự đánh giá sơ bộ và không thay thế cho việc kiểm tra bảo mật chuyên sâu.
4. Lưu ý với hệ thống đã hoàn thành phát triển
Sau khi bàn giao, nhiều hệ thống tiếp tục vận hành trong nhiều năm nhưng không được bảo trì định kỳ. Trong khoảng thời gian đó, các lỗ hổng mới được phát hiện, hệ điều hành và framework hết hỗ trợ, thư viện cũ ngừng cập nhật, còn cấu hình ban đầu không còn phù hợp.
Một hệ thống an toàn tại thời điểm bàn giao chưa chắc sẽ an toàn trong suốt quá trình vận hành.
Vì vậy, dù không phát triển thêm tính năng, doanh nghiệp vẫn cần dành ngân sách và lập kế hoạch bảo trì bảo mật. Doanh nghiệp cũng cần thống nhất rõ trách nhiệm giữa đơn vị phát triển, đơn vị vận hành hạ tầng và bên sở hữu hệ thống.
5. Kết luận: Bảo mật là việc cần làm thường xuyên
Không có hệ thống nào an toàn tuyệt đối. Tuy nhiên, nếu doanh nghiệp thường xuyên rà soát lỗ hổng, cập nhật phần mềm, kiểm soát truy cập, giám sát và sao lưu dữ liệu, nguy cơ bị tấn công sẽ giảm và thiệt hại khi có sự cố cũng được hạn chế.
Doanh nghiệp nên ưu tiên ba việc sau:
- Kiểm tra: Rà soát hệ thống và xác định những lỗ hổng có thể ảnh hưởng.
- Khắc phục: Xử lý trước các lỗ hổng nghiêm trọng, nhất là lỗ hổng đang bị khai thác.
- Duy trì: Bảo trì, cập nhật và giám sát hệ thống định kỳ.
Từ ý tưởng đến hệ thống vận hành ổn định — BUNBU đồng hành cùng quý công ty qua mọi giai đoạn: lập kế hoạch, phân tích yêu cầu, phát triển, kiểm thử và vận hành. Hãy liên hệ để được tư vấn miễn phí.