Bảo vệ file backup, log và file tạm khỏi truy cập công khai

Backup, log và file tạm thường chứa dữ liệu nhạy cảm hơn nội dung public của website: database dump, credential, stack trace, token, email, path hệ thống, source code hoặc bản copy cũ của file cấu hình. Nếu những artifact này nằm trong public webroot hoặc có URL đoán được, attacker có thể tải trực tiếp mà không cần khai thác lỗ hổng phức tạp.

Mục tiêu của hardening là không để artifact nhạy cảm trở thành public resource chỉ vì nó tồn tại trên cùng server với website.

Những loại file thường bị lộ

.sql, .sql.gz, database dump.
ZIP/TAR backup của site.
.env, config backup, file *.bak, *.old.
application log, PHP error log, debug log.
temporary export/import files.
cache hoặc build artifact chứa dữ liệu không public.
staging snapshot.
backup plugin output nằm trong uploads.

1. Ưu tiên lưu ngoài webroot

Control mạnh nhất là không đặt file nhạy cảm trong document root. Nếu web server không map path đó thành URL, rủi ro direct download giảm đáng kể.

Ví dụ, thay vì lưu:

/var/www/html/backups/site.sql.gz

hãy ưu tiên một path tách biệt như:

/srv/secure-backups/site.sql.gz

với permission riêng và không được web server expose.

2. Nếu buộc phải để trong webroot, deny access rõ ràng

Một số plugin hoặc workflow có thể ghi artifact trong public tree. Khi không thể thay đổi ngay, cần deny bằng web server rule và kiểm response thực tế.

Không chỉ rely vào filename “khó đoán”. Security through obscurity không phải access control.

3. Đừng dùng extension làm boundary duy nhất

Web server có thể phục vụ bất kỳ file nào nếu path public và không bị deny. File .log, .txt, .bak hoặc .sql không tự an toàn chỉ vì không executable.

Với file backup nén, attacker chỉ cần download và giải nén offline.

4. Permission phải theo least privilege

File nhạy cảm chỉ nên readable/writable bởi account/service thật sự cần. Tránh permission rộng như world-readable hoặc shared group không kiểm soát.

Với backup repository, nên tách quyền create, read, delete nếu platform hỗ trợ. Ransomware hoặc compromised app account không nên mặc nhiên có quyền xóa mọi backup.

5. Giới hạn URL và delivery path

Nếu file phải được tải qua website, nên phục vụ qua authenticated application handler thay vì static public URL. Handler có thể:

kiểm authentication;
kiểm authorization;
ghi audit log;
set Content-Disposition: attachment;
không reveal filesystem path;
thêm rate limit khi cần.

6. Log cần tránh ghi secret

Hardening log không chỉ là access control. Cần kiểm nội dung log:

không ghi password;
không ghi full access token;
không ghi session cookie;
mask API key;
tránh dump toàn request body có PII nếu không cần.

Một log file được bảo vệ tốt vẫn có thể trở thành security risk nếu chứa secret quá mức cần thiết.

7. Debug mode phải được quản lý

Debug log hữu ích trên staging nhưng có thể lộ path, query, plugin name, stack trace hoặc dữ liệu request. Production nên có policy rõ về nơi ghi log, retention và người được đọc.

8. File tạm phải có lifecycle

Import/export thường tạo file tạm rồi bị bỏ quên. Mỗi workflow nên xác định:

file tạo ở đâu;
ai có quyền đọc;
bao lâu bị xóa;
xóa bằng cron/job nào;
nếu cleanup fail thì alert ra sao.

“Temporary” không có nghĩa tự động biến mất.

9. Backup cần tách failure domain

Backup đặt cùng server, cùng account và cùng storage với production có thể bị mất cùng lúc khi server compromise hoặc storage failure. Nên có offsite/offline/immutable layer phù hợp threat model.

Quan trọng hơn, backup phải được restore-test. Xem Backup Recoverability.

10. Kiểm bằng request thật

Sau khi cấu hình deny, hãy thử request các pattern:

/backup.zip
/db.sql
/debug.log
/.env
/wp-config.php.bak

Mục tiêu là xác minh frontend response, không chỉ nhìn config file. CDN/reverse proxy hoặc route khác có thể thay đổi behavior.

11. Monitoring các artifact mới

Nên cảnh báo khi xuất hiện file nhạy cảm mới trong webroot hoặc uploads, đặc biệt:

archive lớn;
database dump;
config backup;
debug log;
extension lạ;
file được tạo ngoài deployment window.

Baseline giúp phân biệt artifact hợp lệ với drift. Xem Security Monitoring Baseline.

Checklist nhanh

Backup/log/temp ưu tiên ngoài webroot.
Không có static public URL nếu file private.
Permission theo least privilege.
Không log secret không cần thiết.
Retention và cleanup có owner.
Backup tách failure domain.
Restore test định kỳ.
Request thực tế xác nhận deny rule.
Monitor artifact mới trong public path.

Kết luận

File nhạy cảm không nên được bảo vệ bằng tên khó đoán. Boundary tốt nhất là storage location + access control + permission + retention + monitoring.

Nếu cần xây dựng recovery architecture tổng thể, xem Backup & Recovery.