Sau khi website bị compromise, đổi mật khẩu là cần thiết nhưng Credential Rotation không nên thực hiện theo kiểu “đổi tất cả ngay lập tức”. Nếu attacker vẫn còn persistence hoặc vẫn đọc được secret mới, việc rotate quá sớm có thể khiến credential mới tiếp tục bị lộ.
Mục tiêu là xác định đúng credential có nguy cơ, containment trước những vector đang active, sau đó rotate theo thứ tự giảm thiểu khả năng attacker tiếp tục truy cập.
Credential nào cần được xem xét sau compromise?
Tài khoản WordPress
Admin, Editor, account service và application password cần được review theo scope. Account không rõ nguồn gốc phải được xử lý như một indicator.
Hosting, SSH/SFTP và control panel
Nếu attacker có thể đã truy cập filesystem hoặc hosting panel, chỉ đổi WordPress password là không đủ.
Database credential
Database username/password trong wp-config.php có thể cần rotate nếu attacker đọc được file cấu hình hoặc có shell access.
API key, webhook secret và third-party token
Payment, SMTP, CDN, backup, analytics, deployment và integration token đều phải được inventory theo phạm vi incident.
Không rotate trước khi hiểu persistence
Nếu webshell, cron, MU-plugin hoặc account đặc quyền trái phép vẫn còn, attacker có thể đọc secret mới sau khi rotate. Vì vậy nên phối hợp Credential Rotation với containment và Root Cause Analysis.
Credential Rotation Matrix
| Credential | Khi nào cần rotate | Điều kiện trước | Verification |
|---|---|---|---|
| WordPress admin | Account compromise hoặc session đáng ngờ | Revoke session, kiểm tra admin/user persistence | Login mới hợp lệ, session cũ hết hiệu lực |
| Hosting/SSH/SFTP | Filesystem/control-plane access bị nghi ngờ | Contain host, review keys/accounts | Old key/password không còn truy cập được |
| Database | wp-config hoặc DB credential có khả năng bị đọc | Kiểm tra application connectivity và backup | App hoạt động với credential mới, credential cũ bị revoke |
| API/Webhook secret | Token có trong source/config bị lộ | Xác định integration phụ thuộc | Webhook/API hoạt động với secret mới, old token invalid |
| Recovery email/registrar | Identity/control-plane compromise | Khôi phục trusted recovery path | MFA/recovery contact đã kiểm chứng |
Thứ tự rotation nên dựa trên blast radius
Không có một thứ tự cố định cho mọi incident. Một nguyên tắc thực dụng là ưu tiên control plane và credential có quyền cao nhất, sau đó đến application, database và integration.
- Khôi phục trusted admin/recovery channel.
- Revoke session/token đang active.
- Rotate hosting/cloud/SSH credential nếu liên quan.
- Rotate WordPress privileged account.
- Rotate database và application secrets nếu có exposure.
- Rotate API key/webhook/SMTP/CDN token bị ảnh hưởng.
- Kiểm chứng dependent service và log.
Đừng quên session, token và key cũ
Đổi password nhưng giữ session/token cũ có thể không ngăn attacker. Vì vậy mỗi rotation action phải xác định cơ chế revoke tương ứng.
Với WordPress, kiểm tra active session, application password và account có role cao. Với SSH, review authorized_keys; với cloud/API, revoke token thay vì chỉ tạo token mới.
Mẫu Credential Rotation Record
| Trường | Nội dung |
|---|---|
| Credential/Service | WordPress admin, SSH, DB, API… |
| Exposure reason | Evidence hoặc hypothesis liên quan |
| Owner | Người chịu trách nhiệm |
| Rotated at | Timestamp + timezone |
| Old revoked? | Có/không + cách xác minh |
| Dependent services | Ứng dụng/integration bị ảnh hưởng |
| Verification | Test chứng minh secret mới hoạt động và secret cũ vô hiệu |
Khi nào Credential Rotation được coi là hoàn tất?
- Credential có risk đã được inventory.
- Old session/token/key đã revoke khi phù hợp.
- Không còn persistence có thể thu lại secret mới trong phạm vi đã biết.
- Dependent service đã test sau rotation.
- Monitoring không ghi nhận sử dụng credential cũ.
- Rotation record được đưa vào Incident Timeline.
Sau rotation, tiếp tục post-incident monitoring để phát hiện reuse credential cũ hoặc dấu hiệu tái xâm nhập.
Nguyên tắc vận hành
Credential Rotation là một phần của containment và recovery, không phải biện pháp thay thế điều tra nguyên nhân gốc. Nếu chưa biết attacker vào bằng cách nào, việc đổi secret chỉ giải quyết một phần của rủi ro.