Checklist bảo mật Open Source SaaS: 9 điểm phải kiểm tra

Checklist đánh giá bảo mật trước khi dùng open source SaaS alternative

Bạn tìm thấy một công cụ open source thay thế SaaS: miễn phí, tự host được, không bị khóa nhà cung cấp, dữ liệu nằm trong tay mình. Nghe rất hấp dẫn. Nhưng “open source” không tự động đồng nghĩa với “an toàn”. Mã nguồn mở giúp có thể kiểm tra, không đảm bảo đã được kiểm tra.

Rủi ro thường không nằm ở ý tưởng sản phẩm, mà ở phần vận hành: cấu hình mặc định yếu, secret lộ trong file .env, container chạy quyền root, backup không mã hóa, dự án bị bỏ hoang, hoặc dependency dính CVE chưa vá. Trước khi thay một SaaS đang ổn bằng bản open source tự host, cần checklist rõ ràng.

Dưới đây là checklist thực tế để đánh giá bảo mật trước khi triển khai.

1. Xác định dữ liệu sẽ đưa vào hệ thống

Trước khi xem repo, hãy hỏi: hệ thống này sẽ giữ dữ liệu gì?

Cần phân loại dữ liệu

– Dữ liệu công khai: blog, landing page, tài liệu public. – Dữ liệu nội bộ: ticket, roadmap, wiki, log vận hành. – Dữ liệu nhạy cảm: thông tin khách hàng, email, số điện thoại, hợp đồng. – Dữ liệu đặc biệt nhạy cảm: thanh toán, y tế, định danh, tài liệu pháp lý, secret kỹ thuật.

Mức bảo mật cần thiết phụ thuộc vào loại dữ liệu. Một công cụ ghi chú nội bộ khác hoàn toàn một hệ thống CRM chứa dữ liệu khách hàng.

Câu hỏi nhanh

– Nếu hệ thống bị lộ DB, thiệt hại gì? – Có dữ liệu cá nhân không? – Có yêu cầu pháp lý như GDPR, HIPAA, ISO, SOC 2? – Dữ liệu có cần xóa vĩnh viễn theo yêu cầu không? – Có log chứa token, password, email, IP không?

Nếu câu trả lời mơ hồ → chưa nên triển khai.

2. Kiểm tra sức khỏe dự án open source

Repo đẹp chưa đủ. Cần xem dự án còn sống không.

Dấu hiệu tốt

– Commit gần đây, release đều. – Issue bảo mật được phản hồi. – Có changelog rõ. – Có hướng dẫn upgrade. – Có policy báo cáo lỗ hổng. – Có maintainer hoặc công ty đứng sau. – Có cộng đồng dùng thật.

Dấu hiệu nguy hiểm

– Release cuối cách đây vài năm. – Pull request tồn đọng lâu. – Issue bảo mật bị bỏ mặc. – Không có tài liệu deploy production. – Docker image không rõ nguồn. – Fork nhiều nhưng upstream chết.

Open source bị bỏ hoang là rủi ro lớn. Bạn sẽ thành maintainer bất đắc dĩ.

3. Đọc tài liệu bảo mật, không chỉ README

README thường bán lợi ích. Tài liệu bảo mật mới nói sự thật.

Cần tìm

– SECURITY.md – Hướng dẫn production deployment. – Cấu hình auth. – Cấu hình TLS / HTTPS. – Cấu hình secret. – Backup / restore. – Upgrade / migration. – Hardening guide. – Known limitations.

Nếu dự án không nói gì về production security, xem đó là tín hiệu đỏ.

Câu hỏi cần trả lời

– Có hỗ trợ HTTPS sau reverse proxy không? – Có hướng dẫn rotate secret không? – Có cảnh báo về default password không? – Có cơ chế reset admin an toàn không? – Có bật debug mode mặc định không? – Có khuyến nghị quyền DB tối thiểu không?

4. Đánh giá authentication và authorization

Auth là nơi SaaS alternative hay yếu.

Authentication cần có

– Password hashing bằng thuật toán phù hợp: bcrypt, Argon2, scrypt. – Không lưu password plain text. – Session cookie có HttpOnly, Secure, SameSite. – Có giới hạn brute force hoặc tích hợp reverse proxy rate limit. – Có MFA nếu dữ liệu nhạy cảm. – Có SSO/OIDC/SAML nếu dùng trong doanh nghiệp.

Authorization cần kiểm tra

– Có role rõ ràng không? – Admin/user tách biệt không? – User A có thể truy cập dữ liệu user B không? – API có kiểm tra quyền ở server không? – Link chia sẻ public có expiry/token đủ mạnh không?

Đừng chỉ kiểm tra UI. Nhiều lỗi phân quyền nằm ở API.

5. Kiểm tra cấu hình mặc định

Mặc định tiện lợi thường không an toàn.

Phải kiểm tra

– Default admin/password. – Debug mode. – Public registration. – Anonymous access. – Upload file. – CORS. – SMTP. – Webhook. – API token. – Telemetry. – Demo data. – Exposed metrics.

Nguyên tắc

– Tắt public registration nếu không cần. – Tắt demo/debug ở production. – Chỉ mở port cần thiết. – Chặn admin khỏi internet nếu có thể. – Đặt allowlist domain cho callback/webhook. – Không dùng secret mặc định trong docs.

Một lệnh docker compose up hiếm khi đủ an toàn cho production.

6. Soát container, image, dependency

Nhiều SaaS alternative được triển khai bằng Docker. Cần xem image có sạch không.

Checklist Docker

– Image có tag version cụ thể, không dùng latest. – Image có nguồn chính thức. – Container không chạy bằng root nếu không cần. – Volume rõ ràng. – Secret không hardcode trong image. – Không mount Docker socket trừ khi bắt buộc. – Không dùng privileged: true. – Healthcheck có nhưng không lộ dữ liệu. – Port nội bộ không expose ra internet.

Dependency

– Có lockfile: package-lock.json, pnpm-lock.yaml, poetry.lock, go.sum, v.v. – Dependency được cập nhật. – Không có package lạ ít người dùng. – Có tool scan CVE trong pipeline hoặc release. – Có SBOM càng tốt.

Không cần paranoia mọi CVE. Nhưng CVE critical chưa vá trong auth, parser, upload, template engine → nên dừng.

7. Kiểm tra database và lưu trữ

DB là tài sản chính.

Cần đảm bảo

– DB không public internet. – User DB chỉ có quyền cần thiết. – Password mạnh, không reuse. – Backup mã hóa. – Restore được test. – Migration có rollback hoặc kế hoạch phục hồi. – Dữ liệu nhạy cảm mã hóa at rest nếu cần. – File upload lưu ở nơi có quyền truy cập kiểm soát.

Câu hỏi thực tế

– Nếu server mất, có khôi phục được trong bao lâu? – Nếu upgrade lỗi migration, rollback thế nào? – Backup nằm cùng server hay khác nơi? – Ai có quyền đọc backup? – Có lifecycle xóa backup cũ không?

Backup không test restore = chưa có backup.

8. Logging, audit, monitoring

Bảo mật không chỉ là ngăn chặn. Còn là phát hiện.

Logging cần có

– Login success/fail. – Thay đổi quyền. – Tạo/xóa API key. – Export dữ liệu. – Thay đổi cấu hình. – Lỗi bất thường. – Webhook fail. – Admin action.

Tránh log

– Password. – Token. – Session cookie. – Secret. – Nội dung dữ liệu nhạy cảm nếu không cần.

Monitoring tối thiểu

– Uptime. – Disk usage. – CPU/RAM. – DB connection. – Error rate. – Failed login spike. – Certificate expiry. – Backup status.

Không có log → khi sự cố xảy ra chỉ còn đoán.

9. Kiểm tra network exposure

Một triển khai an toàn thường đơn giản: ít cổng, ít bề mặt tấn công.

Nên làm

– Đặt sau reverse proxy: Nginx, Caddy, Traefik. – Bắt buộc HTTPS. – Chỉ expose web port. – DB/cache chỉ trong private network. – Admin endpoint giới hạn IP/VPN. – Rate limit login/API. – Bật security headers cơ bản. – Tách môi trường staging/production.

Security headers nên có

– Strict-Transport-Security – X-Content-Type-Options – Content-Security-Policy – Referrer-Policy – Frame-Options hoặc CSP frame-ancestors

Không phải app nào cũng tự xử lý tốt phần này. Reverse proxy là nơi phù hợp để enforce.

10. Đánh giá quy trình cập nhật

Tự host nghĩa là tự chịu trách nhiệm patch.

Cần có

– Lịch kiểm tra update. – Theo dõi release/security advisory. – Môi trường test upgrade. – Backup trước upgrade. – Ghi lại version đang chạy. – Quy trình rollback. – Người chịu trách nhiệm rõ ràng.

Câu hỏi quan trọng

– Ai vá khi có CVE? – Bao lâu vá critical? – Có downtime được không? – Upgrade có phá schema không? – Có migration tự động không?

Nếu không có người vận hành, SaaS trả phí có thể rẻ hơn.

11. Kiểm tra license và rủi ro pháp lý

Bảo mật không tách khỏi pháp lý.

Cần xem

– License: MIT, Apache-2.0, GPL, AGPL, SSPL, custom. – Nghĩa vụ khi sửa code. – Nghĩa vụ khi cung cấp dịch vụ qua mạng. – Trademark. – Telemetry. – Data processing. – Export control nếu liên quan.

Đặc biệt với AGPL, nếu bạn sửa code và cung cấp qua network, có thể phải công bố mã nguồn phần sửa đổi. Không xấu, nhưng cần biết trước.

12. Chạy thử như một kẻ tấn công nhẹ

Không cần pentest lớn ngay. Nhưng cần kiểm tra cơ bản.

Test tối thiểu

– Đăng nhập sai nhiều lần. – Thử truy cập URL admin khi chưa login. – Thử đổi ID trong API/request. – Upload file lạ. – Kiểm tra reset password. – Kiểm tra invite link. – Kiểm tra logout/session expiry. – Kiểm tra CORS. – Quét port public. – Chạy scanner dependency/container nếu có.

Mục tiêu: bắt lỗi cấu hình và lỗi phân quyền rõ ràng trước khi dữ liệu thật vào hệ thống.

Kết luận: open source tốt, nhưng phải vận hành đúng

Open source SaaS alternative có thể là lựa chọn rất mạnh: kiểm soát dữ liệu, tùy biến cao, tránh vendor lock-in. Nhưng lợi ích đó đi kèm trách nhiệm: cập nhật, cấu hình, backup, giám sát, xử lý sự cố.

Checklist ngắn để quyết định:

– Dự án còn được duy trì? – Auth/phân quyền đủ mạnh? – Cấu hình production rõ? – Không expose DB/secret? – Có backup và restore test? – Có quy trình update? – Có log/audit đủ điều tra? – License phù hợp? – Có người chịu trách nhiệm vận hành?

Nếu câu trả lời phần lớn là “không biết”, chưa nên dùng cho dữ liệu quan trọng. Hãy bắt đầu với môi trường thử nghiệm, dữ liệu giả, quyền hạn thấp. Khi checklist đạt mức chấp nhận được, hãy triển khai từng bước.

Open source không miễn phí nếu tính cả vận hành. Nhưng nếu đánh giá đúng từ đầu, nó có thể là nền tảng an toàn, linh hoạt và bền vững hơn nhiều SaaS đóng.