Checklist Bảo Mật Cloud Server: 30+ Mục Cần Kiểm Tra Trước Production

Cloud Server là hạ tầng cốt lõi vận hành các hệ thống website, API, cơ sở dữ liệu, container và ứng dụng nội bộ của doanh nghiệp. Mặc dù vậy, khi vừa khởi tạo từ bản phân phối gốc, đa số máy chủ vẫn duy trì các thiết lập mặc định: mở sẵn xác thực SSH bằng mật khẩu, kích hoạt nhiều cổng dịch vụ chưa cần dùng, thiếu cấu hình tường lửa, chưa thiết lập cơ chế tự động cập nhật bản vá bảo mật và chưa có hệ thống cảnh báo sớm. Những yếu tố này vô tình mở rộng bề mặt tấn công trước các đợt dò quét tự động từ không gian mạng.

Bảo mật máy chủ đám mây không dừng lại ở việc cài đặt một công cụ phòng thủ đơn lẻ. Một hệ thống vững chắc phải được xây dựng theo chiến lược phòng thủ đa lớp (Defense-in-Depth): từ quản lý định danh người dùng, kiểm soát truy cập SSH, cấu hình tường lửa mạng, tối ưu hóa ứng dụng, bảo vệ container, cho tới quy trình giám sát liên tục, sao lưu dự phòng và lập sẵn kế hoạch ứng phó sự cố.

1. Quản lý danh tính, phân quyền tài khoản và xác thực truy cập

Lớp bảo vệ đầu tiên đối với bất kỳ Cloud Server nào bắt đầu từ cách thức người dùng xác thực và quyền hạn được gán cho từng tài khoản hoạt động trong hệ thống.

A. Hạn chế sử dụng tài khoản root và phân quyền tối thiểu (Least Privilege)

Tài khoản root trên môi trường Linux sở hữu quyền hạn tối cao và có thể thực thi mọi can thiệp hệ thống. Việc sử dụng trực tiếp tài khoản này cho các thao tác quản trị thường ngày tiềm ẩn nguy cơ sai sót lệnh và khó kiểm toán lịch sử truy cập. Hãy luôn khởi tạo tài khoản riêng có đặc quyền quản trị qua sudo:

# Kiểm tra định danh hiện tại và danh sách tài khoản
whoami
cat /etc/passwd

# Tạo tài khoản riêng và thêm vào nhóm quản trị sudo
sudo adduser deploy
sudo usermod -aG sudo deploy

# Kiểm tra đặc quyền sudo của người dùng mới
su - deploy
sudo whoami
# Kết quả hiển thị 'root' xác nhận tài khoản đã có quyền sudo

Áp dụng triệt để nguyên tắc đặc quyền tối thiểu (Least Privilege): chỉ cung cấp vừa đủ quyền hạn cho từng người dùng thực hiện nhiệm vụ. Đối với các tài khoản chuyên trách, quản trị viên nên dùng lệnh sudo visudo để giới hạn quyền thực thi các tệp nhị phân cụ thể thay vì cấp toàn quyền hệ thống. Kiểm tra các tài khoản nằm trong nhóm sudo qua lệnh:

getent group sudo

B. Thiết lập chính sách mật khẩu mạnh và kiểm tra chất lượng với pam_passwdqc

Mật khẩu là tuyến phòng thủ cơ bản. Một mật khẩu an toàn cần có độ dài tối thiểu từ 12 đến 15 ký tự trở lên, kết hợp đa dạng giữa chữ hoa, chữ thường, chữ số và các ký tự đặc biệt (như !, @, #, $), tuyệt đối tránh các từ ngữ trong từ điển hay ngày sinh.

Trên Linux, quản trị viên có thể cài đặt mô-đun pam_passwdqc để phân tích cú pháp và cưỡng chế quy chuẩn mật khẩu mạnh đối với mọi tài khoản hệ thống.

C. Bắt buộc kích hoạt xác thực 2 lớp (2FA/MFA)

Đối với cổng thông tin quản trị đám mây (Cloud Portal) và các phiên đăng nhập then chốt, bắt buộc kích hoạt xác thực 2 lớp (2FA/MFA) qua các ứng dụng chuyên dụng như Google Authenticator, Microsoft Authenticator hoặc Duo Security. Cơ chế này loại bỏ nguy cơ tài khoản bị đánh cắp trong tình huống mật khẩu chính bị lộ lọt.

D. Sử dụng SSH Key và làm cứng (Hardening) OpenSSH Daemon

Đăng nhập thông qua giao thức SSH bằng mật khẩu thường xuyên trở thành mục tiêu của các cuộc tấn công quét mã (Brute Force). Hãy chuyển dịch hoàn toàn sang xác thực bằng cặp khóa mã hóa SSH Key (khuyến nghị thuật toán ed25519 hiện đại):

# Tạo khóa trên máy tính cá nhân
ssh-keygen -t ed25519

# Sao chép Public Key lên máy chủ đích
ssh-copy-id deploy@server_ip

Sau khi xác thực tài khoản đăng nhập qua khóa thành công, tiến hành chỉnh sửa tệp cấu hình /etc/ssh/sshd_config để chặn đăng nhập mật khẩu và vô hiệu hóa quyền SSH trực tiếp của root:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Kiểm tra tính hợp lệ của cú pháp cấu hình trước khi nạp lại dịch vụ:

sudo sshd -t
sudo systemctl reload ssh

*Lưu ý quan trọng: Luôn duy trì một phiên SSH đang kết nối độc lập trong suốt quá trình thay đổi tham số cấu hình để tránh sự cố tự khóa quyền truy cập của chính mình.

E. Rà soát tài khoản cũ không còn sử dụng

Tài khoản phụ của đối tác, người dùng thử nghiệm hoặc nhân sự đã rời khỏi dự án cần được dọn dẹp định kỳ. Trích xuất danh sách người dùng và thực hiện khóa phiên đăng nhập:

# Liệt kê tất cả user trong hệ thống
cut -d: -f1 /etc/passwd

# Khóa tài khoản tạm thời để kiểm tra ảnh hưởng trước khi xóa hẳn
sudo usermod -L ten_tai_khoan

2. Bảo mật mạng, tường lửa và kiểm soát cổng dịch vụ

Một Cloud Server sẵn sàng cho môi trường Production không được phép mở toàn bộ các cổng mạng trực tiếp ra Internet nếu không có nhu cầu thực tế.

A. Cấu hình tường lửa máy chủ (UFW / iptables) và danh sách IP trắng (Whitelisting)

Quản trị viên có thể sử dụng ufw (Uncomplicated Firewall) hoặc iptables để thiết lập tường lửa máy chủ với chính sách chặn mặc định cho tất cả các kết nối đến (inbound) và chỉ mở các dịch vụ phục vụ người dùng cuối:

# Cấp phép cho cổng SSH quản trị
sudo ufw allow OpenSSH

# Mở cổng dịch vụ Web công khai
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Kích hoạt tường lửa và rà soát thứ tự các rule
sudo ufw enable
sudo ufw status numbered

Đối với các cổng quản trị hệ thống hoặc cơ sở dữ liệu nội bộ, chỉ cho phép kết nối từ dải địa chỉ IP tĩnh cố định (IP Whitelisting) của văn phòng hoặc máy trạm quản trị được cấp phép.

B. Rà soát các cổng đang lắng nghe kết nối (Listening Ports)

Sử dụng các lệnh phân tích mạng để phát hiện các ứng dụng đang mở cổng ra môi trường ngoài:

sudo ss -tulpn
# Hoặc kiểm tra qua lsof
sudo lsof -i -P -n | grep LISTEN

Khi phát hiện bất kỳ cổng nào đang mở, cần đối chiếu 4 câu hỏi:

• Cổng kết nối này thuộc về dịch vụ hoặc ứng dụng nào?
• Dịch vụ đó có bắt buộc phải công khai ra mạng Internet toàn cầu hay không?
• Những nhóm đối tượng nào có quyền truy cập vào cổng này?
• Có thể giới hạn phạm vi truy cập theo địa chỉ IP cố định hay không?

C. Phân lập cơ sở dữ liệu và mạng riêng ảo (Private Network)

Các cổng dữ liệu đặc thù như MySQL (3306), PostgreSQL (5432), Redis (6379), Elasticsearch (9200) tuyệt đối không được mở lắng nghe tại địa chỉ công khai 0.0.0.0. Kiến trúc chuẩn mực cần tuân thủ cấu trúc phân tầng:

Internet ---> Reverse Proxy (Nginx) ---> Application Server ---[Mạng riêng/Private Network]---> Database

Nếu cơ sở dữ liệu chạy trên cùng máy chủ với ứng dụng, hãy ràng buộc địa chỉ kết nối chỉ lắng nghe cục bộ (Localhost):

bind-address = 127.0.0.1

D. Tăng cường phòng thủ tầng ứng dụng với tường lửa WAF

Tường lửa mạng truyền thống chỉ lọc gói tin từ Layer 3 đến Layer 4, hoàn toàn không có khả năng nhận biết các cuộc tấn công khai thác lỗ hổng web tinh vi ở Layer 7 như SQL Injection, Cross-Site Scripting (XSS) hay Remote Code Execution.

Do đó, việc thiết lập Web Application Firewall (WAF) là bước bắt buộc để thanh lọc lưu lượng truy cập trước khi chạm tới ứng dụng. Bạn có thể sử dụng giải pháp mã nguồn mở ModSecurity (tích hợp trực tiếp cho Nginx/Apache), giải pháp mạng biên Cloudflare WAF hoặc hệ thống Cloudbric WAF chuyên biệt.

3. Quản trị hệ điều hành, dọn dẹp dịch vụ và vá lỗ hổng

Hệ điều hành chứa các gói phần mềm lỗi thời là môi trường thuận lợi để kẻ tấn công leo thang đặc quyền hoặc kiểm soát máy chủ từ xa.

A. Quy trình cập nhật bản vá hệ điều hành

Không nên thực hiện cập nhật toàn bộ máy chủ production một cách tùy tiện mà không có kế hoạch kiểm thử. Quy trình chuẩn mực cần đi qua 4 bước: Staging -> Kiểm thử tương thích (Test) -> Tạo bản sao lưu (Backup) -> Áp dụng cập nhật lên Production.

Các thành phần nhạy cảm cần rà soát kỹ lưỡng bao gồm: Kernel, Nginx/Apache, Database, Docker engine, Runtime (PHP/Java/NodeJS) và thư viện OpenSSL.

# Kiểm tra các bản vá có sẵn trên Ubuntu/Debian
sudo apt update
sudo apt list --upgradable
sudo apt upgrade -y

B. Kích hoạt cập nhật bảo mật tự động

Để không bỏ sót các bản vá lỗ hổng nghiêm trọng vừa được công bố (Zero-day patches), hãy thiết lập tính năng tự động vá lỗi bảo mật:

• Trên Ubuntu/Debian: Cài đặt và kích hoạt gói unattended-upgrades:

  sudo apt install unattended-upgrades
  sudo dpkg-reconfigure --priority=low unattended-upgrades

• Trên AlmaLinux / CentOS / RHEL: Thiết lập gói dnf-automatic.
• Đối với hạ tầng quy mô lớn: Sử dụng các công cụ quản lý cấu hình tự động như Ansible để đồng bộ bản vá trên toàn bộ cụm máy chủ.

C. Vô hiệu hóa và gỡ bỏ các daemon, dịch vụ không cần thiết

Mỗi tiến trình chạy ngầm đều làm tăng bề mặt rủi ro. Nếu máy chủ không sử dụng dịch vụ truyền tệp FTP, máy chủ thư nội bộ hoặc các bảng điều khiển web thử nghiệm, hãy dừng và tắt kích hoạt khi khởi động:

# Liệt kê danh sách dịch vụ đang chạy
systemctl --type=service --state=running

# Vô hiệu hóa dịch vụ không dùng đến
sudo systemctl stop ten_dich_vu
sudo systemctl disable ten_dich_vu

D. Rà soát tiến trình khởi tạo (Systemd), Cronjob và đồng bộ thời gian

Mã độc thường lợi dụng cronjob và dịch vụ systemd để duy trì sự tồn tại (persistence) trên máy chủ:

• Kiểm tra cronjob của người dùng và root: crontab -l, sudo crontab -l, kiểm tra các thư mục hệ thống ls -la /etc/cron.d/, /etc/cron.daily/.
• Kiểm tra các đơn vị dịch vụ: systemctl list-unit-files --type=service và xem chi tiết tệp cấu hình qua systemctl cat ten_dich_vu.
• Đồng bộ thời gian chuẩn xác qua NTP: Chạy lệnh timedatectl để đảm bảo máy chủ ghi nhận mốc thời gian đồng nhất. Việc lệch múi giờ sẽ gây khó khăn lớn cho việc đối chiếu nhật ký khi điều tra sự cố bảo mật.

E. Đánh giá an ninh hệ thống với công cụ quét lỗ hổng

Chủ động rà quét định kỳ hệ điều hành bằng công cụ kiểm toán mã nguồn mở Lynis để nhận diện các điểm yếu cấu hình trên Linux. Với các hệ thống cấp doanh nghiệp, có thể mở rộng quét chuyên sâu bằng OpenVAS hoặc Nessus nhằm phát hiện các lỗ hổng CVE đã được định danh.

4. Kiểm soát phân quyền tệp tin, bảo vệ ứng dụng và quản lý mã nguồn

Sai sót trong phân quyền tệp tin trên máy chủ web có thể dẫn tới việc lộ lọt thông tin nhạy cảm hoặc cho phép kẻ tấn công tải lên mã thực thi nguy hiểm.

A. Phân quyền tệp tin an toàn (File Permissions)

Tuyệt đối không sử dụng lệnh chmod -R 777 để xử lý các vấn đề nghẽn quyền đọc/ghi. Đây là sai lầm nguy hiểm biến thư mục thành nơi bất kỳ ai cũng có thể chỉnh sửa và chèn mã độc. Thiết lập quyền chuẩn xác cho các tệp nhạy cảm:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519

Sử dụng công cụ giám sát kiểm toán hệ thống Auditd để theo dõi các sự kiện đọc, sửa đổi hoặc xóa các tệp tin quan trọng theo thời gian thực.

B. Quản lý bí mật (Secrets) và chống lộ tệp tin cấu hình nhạy cảm

Không được lưu trực tiếp mật khẩu cơ sở dữ liệu, API key hoặc khóa giải mã vào mã nguồn được đẩy lên hệ thống Git. Hãy chuyển toàn bộ sang biến môi trường (Environment Variables), sử dụng Secret Manager hoặc cơ chế Docker/Kubernetes Secrets. Thường xuyên rà quét kho mã:

git grep -i "password"
git grep -i "secret"

Đảm bảo máy chủ web chặn tuyệt đối quyền truy cập vào các tệp môi trường và thư mục ẩn. Sử dụng curl -I để kiểm tra, kết quả mong muốn luôn phải là 403 Forbidden hoặc 404 Not Found:

curl -I https://example.com/.env
curl -I https://example.com/.git/config

Tương tự, các tệp như config.php, application.yml, backup.sql, dump.sql tuyệt đối không được đặt trong thư mục gốc công khai của web server (public web root).

C. Cấu hình HTTPS và Security Headers phía máy khách

Môi trường Production bắt buộc sử dụng HTTPS mã hóa toàn bộ dữ liệu truyền tải. Định kỳ kiểm tra hạn chứng chỉ số qua OpenSSL và thiết lập chuyển hướng toàn bộ từ HTTP sang HTTPS. Bên cạnh đó, bổ sung các tiêu đề bảo mật HTTP (Security Headers) để hạn chế rủi ro khai thác từ phía trình duyệt:

• Strict-Transport-Security (HSTS): Ép buộc trình duyệt chỉ kết nối an toàn qua HTTPS.
• X-Content-Type-Options: nosniff: Chống hành vi giả mạo kiểu dữ liệu tệp tin.
• Referrer-Policy: Kiểm soát dữ liệu tham chiếu gửi đi từ trang web.
• Content-Security-Policy (CSP): Khống chế nguồn nạp script, style nhằm ngăn chặn triệt để tấn công XSS. Cần kiểm thử cẩn trọng trước khi đưa vào sản xuất để tránh vô tình làm gián đoạn mã JavaScript hoặc font bên thứ ba.

D. Giới hạn tần suất yêu cầu (Rate Limiting) và kiểm soát kích thước tải lên

Triển khai Rate Limiting trên máy chủ Reverse Proxy (Nginx) để bảo vệ các điểm truy cập nhạy cảm như trang đăng nhập, gửi mã OTP, endpoint tìm kiếm hoặc các API nặng:

# Khai báo vùng nhớ giới hạn trong nginx.conf
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

# Áp dụng cho khối endpoint API cụ thể
location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

Đồng thời, khống chế dung lượng tệp tin gửi lên bằng chỉ thị client_max_body_size 20m;. Ứng dụng phía backend cũng phải kiểm tra chặt chẽ kích thước thực tế, phần mở rộng, kiểu MIME và nội dung nhị phân của tệp để chống tải lên shell mã độc.

5. Bảo mật môi trường Docker Container và phân quyền Cơ sở dữ liệu

A. Thực hành an toàn khi vận hành Docker Container

Việc sử dụng và vận hành Docker Container mang lại sự linh hoạt cao nhưng cũng có thể trở thành bàn đạp chiếm quyền máy chủ vật lý nếu cấu hình lỏng lẻo:

• Tuyệt đối không sử dụng cờ --privileged trong môi trường sản xuất trừ khi có yêu cầu đặc thù của hạ tầng.
• Không gắn tệp socket của host: Tuyệt đối không gắn /var/run/docker.sock vào trong các container không tin cậy vì tiến trình chiếm quyền socket có thể kiểm soát toàn bộ host.
• Không ánh xạ cổng bừa bãi: Tránh cấu hình dạng 0.0.0.0:3306:3306 khiến container mở cổng dịch vụ dữ liệu ra toàn cầu.
• Không chạy ứng dụng trong container bằng root: Luôn định nghĩa chỉ thị USER appuser trong Dockerfile để thu hồi quyền quản trị nếu container bị chiếm đoạt. Thường xuyên cập nhật base image và quét lỗ hổng ảnh trước khi đưa vào kho chứa.

B. Tách biệt tài khoản ứng dụng trong Database

Không để ứng dụng kết nối tới cơ sở dữ liệu bằng tài khoản root hoặc quyền superuser. Hãy tạo một tài khoản riêng biệt chỉ có các quyền thao tác dữ liệu tối thiểu cần thiết như SELECT, INSERT, UPDATE, DELETE; tuyệt đối không cấp các quyền phá hủy cấu trúc như DROP DATABASE, CREATE USER hay GRANT cho người dùng kết nối của web app.

6. Giám sát thời gian thực, phát hiện xâm nhập (IDS/IPS) và quản lý nhật ký

Một hệ thống phòng thủ tốt cần có tai mắt để nhận biết dấu hiệu xâm nhập từ sớm, trước khi kẻ tấn công kịp gây thiệt hại nghiêm trọng.

A. Tự động ngăn chặn tấn công dò quét với Fail2ban

Fail2ban là giải pháp theo dõi tệp tin nhật ký đăng nhập và tự động cập nhật bảng iptables để khóa tức thì các địa chỉ IP có hành vi nhập sai thông tin xác thực nhiều lần liên tiếp:

sudo apt install fail2ban -y
sudo systemctl status fail2ban

# Kiểm tra trạng thái bảo vệ phiên SSH
sudo fail2ban-client status sshd

B. Triển khai hệ thống phát hiện và ngăn chặn xâm nhập (IDS/IPS)

Bên cạnh tường lửa thông thường, việc trang bị hệ thống IDS/IPS giúp nhận diện các mẫu hình lưu lượng độc hại:

• IDS (Intrusion Detection System): Giám sát, phân tích gói tin và phát tín hiệu cảnh báo khi phát hiện lưu lượng có dấu hiệu tấn công.
• IPS (Intrusion Prevention System): Tự động kích hoạt phản ứng chặn lưu lượng bất thường ngay lập tức.
• Công cụ tin cậy: Snort và Suricata cho phân tích lưu lượng mạng sâu (Network IDS/IPS); OSSEC hoặc nền tảng an ninh tập trung Wazuh (SIEM/XDR) để quản lý toàn diện tính toàn vẹn của tệp tin, quét lỗ hổng và đối chiếu log trên quy mô cụm máy chủ.

C. Kiểm tra nhật ký xác thực và tiến trình đang chạy

Rà soát tệp log xác thực của Linux để nhanh chóng phát hiện các nỗ lực truy cập bất thường:

# Theo dõi nhật ký đăng nhập thời gian thực
sudo tail -f /var/log/auth.log

# Lọc các phiên đăng nhập thành công và thất bại
grep "Accepted" /var/log/auth.log
grep "Failed password" /var/log/auth.log

# Tra cứu lịch sử đăng nhập hệ thống
last
lastb

Giám sát các tiến trình tiêu tốn tài nguyên bất thường để phát hiện các script chạy ẩn hoặc phần mềm đào tiền ảo trái phép:

# Lọc các tiến trình chiếm dụng CPU cao nhất
ps aux --sort=-%cpu | head

# Lọc các tiến trình chiếm dụng RAM cao nhất
ps aux --sort=-%mem | head

# Kiểm tra đường dẫn và tệp tin mở bởi tiến trình lạ
lsof -p PID

D. Giám sát tài nguyên và thiết lập ngưỡng cảnh báo (Alerting)

Bảng điều khiển (Dashboard) chỉ có giá trị khi có người trực tiếp quan sát. Một hệ thống bảo mật tiêu chuẩn phải sở hữu cơ chế gửi cảnh báo tự động qua Email/Telegram/Slack khi các chỉ số chạm ngưỡng giới hạn. Cài đặt các công cụ như bộ đôi Prometheus & Grafana, Zabbix hoặc Datadog để theo dõi:

• Tài nguyên hệ thống: CPU > 85%, RAM gần cạn, ổ đĩa sắp đầy (df -h), cạn kiệt chỉ số Inode (df -i). Ổ cứng đầy có thể làm hỏng cơ sở dữ liệu và khiến dịch vụ không thể khởi động lại.
• Chỉ số an ninh: Lưu lượng truy cập đột biến (Traffic Spike), tỷ lệ phản hồi lỗi HTTP 5xx tăng vọt, xuất hiện cổng dịch vụ mới hoặc gia tăng bất thường các đợt chặn từ WAF.

7. Chiến lược sao lưu dữ liệu chuẩn 3-2-1 và Kế hoạch ứng phó sự cố (Runbook)

Không một giải pháp bảo mật nào dám cam kết mức độ an toàn tuyệt đối 100%. Quy trình sao lưu dự phòng là tuyến phòng thủ sau cùng để bảo vệ doanh nghiệp trước các thảm họa ransomware, hỏng hóc vật lý hay lỗi thao tác của con người.

A. Áp dụng nguyên tắc vàng 3-2-1 trong sao lưu dữ liệu

Chiến lược sao lưu chuyên nghiệp phải tuân thủ nghiêm ngặt mô hình 3-2-1:

• 3 bản sao: Duy trì ít nhất 3 bản sao chép của toàn bộ dữ liệu quan trọng (1 bản chính đang chạy và 2 bản dự phòng).
• 2 loại phương tiện: Lưu trữ dữ liệu dự phòng trên tối thiểu 2 phương tiện hoặc hạ tầng công nghệ khác nhau.
• 1 bản sao độc lập ngoài máy chủ (Off-site): Bắt buộc có ít nhất 1 bản lưu trữ hoàn toàn tách biệt với Cloud Server hiện tại (ví dụ: chuyển lên S3 Storage, MinIO biệt lập hoặc máy chủ dự phòng đặt ở trung tâm dữ liệu khác). Một bản backup nằm cùng ổ đĩa với máy chủ chính là vô nghĩa khi máy chủ bị mã hóa hoặc xóa sổ hoàn toàn.

B. Snapshot không thể thay thế hoàn toàn bản Backup độc lập

Tính năng chụp ảnh nhanh Snapshot của hạ tầng đám mây rất thuận tiện để khôi phục nhanh trạng thái đĩa cứng trước khi thử nghiệm một thay đổi lớn. Mặc dù vậy, Snapshot phụ thuộc trực tiếp vào cụm lưu trữ của nhà cung cấp.

Kiến trúc an toàn bền vững phải là sự phối hợp chặt chẽ: Snapshot định kỳ + Bản sao lưu Database riêng biệt + Bản lưu trữ ngoại biên (Offsite Backup) được mã hóa thông qua các công cụ như Restic, BorgBackup hoặc đồng bộ bằng Rclone. Định kỳ tổ chức diễn tập khôi phục (Restore Drill) để đảm bảo dữ liệu sao lưu thực sự sử dụng được khi hữu sự.

C. Kế hoạch ứng phó sự cố xâm nhập (Incident Response Runbook)

Khi phát hiện máy chủ có dấu hiệu bị thâm nhập, hành động vội vã như khởi động lại máy (reboot) hoặc xóa ngay các tệp tin có thể làm mất dấu vết trong bộ nhớ RAM phục vụ công tác điều tra số (Forensics).

Hãy xây dựng quy trình ứng phó theo 7 bước tuần tự:

1. Phát hiện (Detect): Tiếp nhận cảnh báo từ IDS/IPS, WAF, log hệ thống hoặc báo cáo bất thường.
2. Cô lập (Isolate): Ngắt máy chủ khỏi mạng Internet công cộng hoặc đưa vào mạng kiểm dịch (Quarantine Network) thông qua tường lửa để ngăn chặn mã độc phát tán.
3. Thu thập dấu vết (Collect Logs): Trích xuất toàn bộ tệp nhật ký, trạng thái kết nối mạng, danh sách tiến trình trong bộ nhớ phục vụ điều tra.
4. Xác định phạm vi (Assess Scope): Đánh giá mức độ tổn thương, các tài khoản và dịch vụ đã bị can thiệp.
5. Thu hồi và đổi thông tin xác thực (Rotate Credentials): Thay đổi lập tức toàn bộ SSH Key, mật khẩu người dùng, API key, Secret và thông tin truy cập cơ sở dữ liệu.
6. Khôi phục (Recover): Triển khai dựng lại dịch vụ từ bản sao lưu sạch đã kiểm chứng an toàn hoặc khôi phục mã nguồn đã được rà soát.
7. Giám sát hậu sự cố (Monitor): Tăng cường tần suất theo dõi chặt chẽ hành vi hệ thống để bảo đảm không còn cửa sau (backdoor) sót lại.

8. Bảng checklist kiểm tra bảo mật Cloud Server trước khi đưa vào Production

Trước khi chuyển đổi trạng thái máy chủ sang môi trường vận hành thực tế cho khách hàng, quản trị viên hãy đối chiếu toàn bộ các hạng mục trong bảng kiểm tra dưới đây: