Backup Security là việc bảo vệ chính hệ thống backup khỏi bị đọc, sửa, xóa hoặc mã hóa trái phép. Backup thường chứa bản sao dữ liệu production, cấu hình và đôi khi cả secrets, nên kho backup có thể trở thành mục tiêu có giá trị ngang hoặc cao hơn website đang chạy.
Nếu attacker chiếm được cùng tài khoản quản trị có quyền xóa production và backup, một chiến lược backup “đầy đủ” vẫn có thể thất bại. Vì vậy backup phải được thiết kế như một security boundary riêng, không chỉ là một thư mục lưu file.
Threat model của kho backup
| Rủi ro | Ví dụ | Control chính |
|---|---|---|
| Unauthorized read | Backup database bị tải xuống | Encryption + least privilege |
| Unauthorized delete | Attacker xóa restore points | Account separation + immutable/offline copy |
| Ransomware | Backup mount bị mã hóa cùng production | Offline/immutable + separate credentials |
| Credential compromise | API key backup bị lộ trên server | Secret management + rotation |
| Silent corruption | Backup hỏng nhưng job vẫn báo success | Integrity check + restore test |
Silent corruption hoặc backup set không đầy đủ có thể chỉ lộ ra khi restore thật; case có backup nhưng website vẫn không restore được là ví dụ cần dùng để kiểm recoverability thay vì chỉ trạng thái job.
Thiết kế security boundary cho kho backup
Tách backup khỏi cùng failure domain
Nếu backup nằm cùng server, cùng volume, cùng tài khoản cloud hoặc cùng credential với production, sự cố của một lớp có thể lan sang backup. NIST SP 800-34 Rev. 1 đề cập offsite storage như một phần của contingency strategy; CISA cũng khuyến nghị duy trì backup offline/encrypted và kiểm thử định kỳ.
Tách failure domain có thể là khác account, khác storage system, khác provider hoặc offline copy tùy mức rủi ro. “Khác thư mục trên cùng server” không phải separation đủ mạnh cho nhiều kịch bản. Xem thêm quy tắc Backup 3-2-1 và Offsite Backup để thiết kế các lớp tách biệt. Một ví dụ về giá trị của failure-domain separation là server hỏng nhưng website phục hồi được nhờ Offsite Backup.
Least privilege cho hệ thống backup
Tách quyền tạo backup và quyền xóa backup
Nếu nền tảng hỗ trợ, backup job chỉ nên có quyền ghi bản mới và đọc metadata cần thiết; quyền xóa hoặc thay retention nên giới hạn cho admin riêng. Điều này giảm blast radius khi credential của backup agent bị lộ.
Không dùng Administrator chung cho mọi thứ
Tài khoản vận hành WordPress không nhất thiết cần quyền quản trị backup repository. Tách identity và credential giúp attribution rõ hơn và giảm khả năng một account compromise phá cả recovery layer.
Bảo vệ identity, secrets và dữ liệu backup
MFA, secret management và recovery credential
Tài khoản quản trị kho backup, cloud storage hoặc console nên dùng MFA khi hệ thống hỗ trợ. API key/service credential cần owner, rotation và lưu trong secret manager hoặc cơ chế phù hợp, không hard-code trong plugin/theme hay repository.
Nếu backup encryption dùng key riêng, phải có recovery procedure cho key. Encryption mạnh nhưng mất key cũng có thể khiến backup không thể restore.
Encryption: bảo vệ khi truyền và khi lưu
Backup có thể chứa dữ liệu cá nhân, credential hash, configuration và business data. Bảo vệ transport khi upload/replicate và encryption at rest khi phù hợp với threat model. Quan trọng hơn, phải biết ai giữ key và cách chứng minh backup vẫn giải mã được trong restore test.
Với backup, log hoặc file tạm vô tình nằm trong public path, cần xử lý như một exposure riêng; xem cách bảo vệ file backup, log và file tạm khỏi truy cập công khai.
Immutable và offline backup khác nhau thế nào?
Immutable backup được lưu với cơ chế ngăn sửa/xóa trong khoảng thời gian xác định. Offline backup không luôn trực tiếp reachable từ hệ thống production. Hai cơ chế giảm các kiểu rủi ro khác nhau và có thể bổ trợ nhau.
Đừng chỉ tin nhãn “immutable”. Hãy kiểm tra ai có thể thay retention policy, xóa account, rotate key hoặc thay object-lock configuration. Security boundary phải được đánh giá tới control plane.
Chống ransomware phá backup
- Không mount toàn bộ kho backup read-write vào production nếu không cần.
- Dùng credential tách biệt, privilege nhỏ nhất.
- Duy trì ít nhất một restore path attacker trên production khó xóa trực tiếp.
- Giám sát thao tác xóa hàng loạt, retention change và login quản trị.
- Test restore từ bản backup tách biệt.
- Ghi runbook khi backup console/storage account bị compromise.
CISA StopRansomware Guide nhấn mạnh offline, encrypted backups và kiểm tra integrity/availability thường xuyên vì nhiều ransomware cố tìm và xóa hoặc mã hóa backup có thể truy cập.
Monitoring kho backup
Không chỉ alert khi job thất bại. Nên theo dõi:
- Restore point mới nhất quá tuổi.
- Backup size thay đổi bất thường.
- Retention policy bị sửa.
- Số lượng object/file bị xóa tăng đột biến.
- Admin login hoặc API call từ context lạ.
- Encryption/key error.
- Restore test thất bại.
Alert cần owner và escalation path. Dashboard “backup success” không đủ nếu không phát hiện deletion hoặc control-plane change. Xem Backup Monitoring để triển khai freshness, repository health và restore-readiness signal. Case Backup Job thất bại nhiều tuần cho thấy vì sao freshness và alert ownership phải được kiểm riêng khỏi lịch cấu hình.
Backup Security Control Matrix
| Control | PASS khi | Evidence |
|---|---|---|
| Account separation | Production admin không tự động có quyền xóa backup | IAM/role map |
| MFA | Console admin có MFA/recovery | Account policy |
| Encryption | Backup nhạy cảm được bảo vệ và key có recovery | Storage/key config |
| Immutability/offline | Có restore point khó bị xóa từ production compromise | Retention/object lock/offline procedure |
| Audit | Delete/config/admin action truy vết được | Audit log |
| Monitoring | Job + repository health có alert | Alert history |
| Restore test | Bản backup bảo vệ vẫn restore được | Test record |
Backup trong security incident
Nếu website bị compromise, đừng dùng credential mới để ghi backup vào một repository đã có dấu hiệu bị attacker kiểm soát mà chưa đánh giá scope. Ngược lại, đừng xóa backup cũ trước khi xác định bản nào có thể là known-good và bản nào cần giữ làm evidence.
Trong Incident Response, recovery phải phối hợp với containment, credential rotation và integrity verification. Xem Incident Recovery Plan và Credential Rotation sau compromise.
Operational artifact: Backup Repository Security Record
repository: <name>
owner: <team/person>
production_account_separated: yes|no
admin_mfa: yes|no
backup_agent_permissions: <read/write/delete scope>
encryption_at_rest: <model>
encryption_key_owner: <owner>
immutable_or_offline_copy: <method>
retention_change_authority: <role>
delete_audit_enabled: yes|no
last_restore_test: <date/result>
last_access_review: <date>
Nguồn kỹ thuật
- CISA StopRansomware Guide
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
- WordPress Developer — Backups
Kết luận
Backup Security phải bảo vệ cả dữ liệu backup và control plane quản trị nó. Tách failure domain, least privilege, MFA, encryption, immutable/offline restore points, audit và restore test là những lớp bổ trợ nhau. Một backup mà attacker có thể xóa bằng cùng credential với production chưa phải recovery layer đáng tin cậy.
Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ backup website.