Categories
Database Backup

** Learn how to protect enterprise database archives from ransomware using immutable storage. Discover technical implementation steps for AWS S3 Object Lock, ZFS, PostgreSQL, and SQL Server.

Trong bối cảnh các mối đe dọa hiện đại, mã độc tống tiền (ransomware) đã tiến hóa từ việc mã hóa cơ hội sang các chiến dịch tống tiền đa mục tiêu có chủ đích cao. Các mối đe dọa nâng cao (APT) và các tổ chức ransomware hiện đang tích cực săn lùng cơ sở hạ tầng sao lưu và lưu trữ cơ sở dữ liệu trong thời gian chúng xâm nhập hệ thống. Nếu kẻ tấn công xâm nhập cơ sở dữ liệu chính của bạn và đồng thời xóa hoặc mã hóa các kho lưu trữ sao lưu, tổ chức của bạn sẽ phải đối mặt với tình trạng mất dữ liệu thảm khốc.

Đối với các Quản trị viên Cơ sở dữ liệu (DBA) và kỹ sư DevOps, chiến lược sao lưu 3-2-1 truyền thống không còn đủ. Để đảm bảo khả năng phục hồi dữ liệu, các nhóm cơ sở hạ tầng phải áp dụng quy tắc 3-2-1-1, trong đó số “1” cuối cùng đại diện cho lưu trữ bất biến (immutable storage).

Bài viết này cung cấp một cái nhìn chuyên sâu về kỹ thuật, cách thiết kế, triển khai và quản lý lưu trữ bất biến cho các bản lưu trữ cơ sở dữ liệu nhằm đảm bảo khả năng chống chịu ransomware tuyệt đối.

Cơ chế của Lưu trữ Bất biến

Lưu trữ bất biến dựa trên kiến trúc Ghi một lần – Đọc nhiều lần (WORM). Khi dữ liệu được ghi vào một mục tiêu bất biến, nó không thể bị sửa đổi, mã hóa hoặc xóa bởi bất kỳ người dùng nào—kể cả quản trị viên có đặc quyền root hoặc các tài khoản dịch vụ đã bị xâm nhập—cho đến khi thời gian khóa được thực thi bằng toán học hết hạn.

Chế độ Tuân thủ (Compliance Mode) so với Chế độ Quản trị (Governance Mode)

Khi triển khai tính bất biến, đặc biệt là trong lưu trữ đối tượng đám mây như AWS S3, Azure Blob hoặc các SAN tại chỗ tương thích với S3, bạn phải hiểu sự khác biệt giữa các chế độ lưu giữ:

  • Chế độ Quản trị (Governance Mode): Ngăn người dùng tiêu chuẩn xóa hoặc thay đổi đối tượng. Tuy nhiên, người dùng có quyền IAM cụ thể (ví dụ: s3:BypassGovernanceRetention) có thể ghi đè khóa. Điều này hữu ích cho việc thử nghiệm nhưng không đủ để bảo vệ chống ransomware, vì kẻ tấn công thường leo thang đặc quyền lên quản trị viên miền hoặc root.
  • Chế độ Tuân thủ (Compliance Mode): Tiêu chuẩn vàng cho việc phòng thủ ransomware. Khi một đối tượng bị khóa ở Chế độ Tuân thủ, thời gian lưu giữ của nó không thể bị rút ngắn và đối tượng không thể bị xóa bởi bất kỳ ai, kể cả tài khoản root của AWS. Khóa được thực thi ở cấp độ cụm lưu trữ.

Thiết kế Đường ống Sao lưu Bất biến

Một kiến trúc lưu trữ cơ sở dữ liệu mạnh mẽ sẽ tách biệt các hoạt động cơ sở dữ liệu đang chạy với tầng lưu trữ bất biến. Bạn không thể áp dụng tính bất biến cho các tệp cơ sở dữ liệu đang hoạt động (như .mdf/.ldf trong SQL Server hoặc thư mục pg_data trong PostgreSQL) vì cơ sở dữ liệu yêu cầu quyền truy cập đọc/ghi liên tục.

Thay vào đó, tính bất biến được áp dụng cho:
1. Các tệp sao lưu đầy đủ và khác biệt (Full and Differential Backup Files): Các bản chụp cơ sở dữ liệu cơ sở.
2. Nhật ký giao dịch / Tệp WAL (Transaction Logs / WAL Files): Luồng thay đổi cơ sở dữ liệu liên tục cần thiết cho Phục hồi tại thời điểm cụ thể (PITR).

Mục tiêu lưu trữ cho tính bất biến

Bạn có thể triển khai lưu trữ bất biến trên các tầng cơ sở hạ tầng khác nhau:
* Lưu trữ đối tượng đám mây: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lưu trữ đối tượng tại chỗ: MinIO, Cloudian hoặc Pure Storage FlashBlade hỗ trợ API S3 Object Lock.
* Lưu trữ khối/tệp: ZFS với các bản chụp chỉ đọc và quản trị được ủy quyền, hoặc các thuộc tính tệp của Linux.

Triển khai Lưu trữ Bất biến: Hướng dẫn Kỹ thuật

1. Lưu trữ đối tượng đám mây: AWS S3 Object Lock

Để bảo vệ các bản dump cơ sở dữ liệu và nhật ký giao dịch trong AWS, bạn phải bật Object Lock tại thời điểm tạo bucket.

Trước tiên, hãy tạo bucket với Object Lock được bật:

aws s3api create-bucket 
    --bucket prod-db-archive-immutable 
    --region us-east-1 
    --object-lock-enabled-for-bucket

Tiếp theo, cấu hình chính sách lưu giữ mặc định. Đối với các bản lưu trữ cơ sở dữ liệu, khóa tuân thủ 30 ngày là mức cơ bản tiêu chuẩn, đảm bảo bạn có một tháng sao lưu không thể thay đổi.

aws s3api put-object-lock-configuration 
    --bucket prod-db-archive-immutable 
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }'

Khi tập lệnh hoặc tác nhân sao lưu cơ sở dữ liệu của bạn đẩy tệp vào bucket này, S3 sẽ tự động tính toán Retain Until Date dựa trên dấu thời gian tạo đối tượng cộng thêm 30 ngày.

2. Tính bất biến tại chỗ: ZFS và Thuộc tính Linux

Nếu bạn đang lưu trữ cơ sở dữ liệu vào máy chủ sao lưu Linux tại chỗ, bạn có thể đạt được tính bất biến giả bằng lệnh chattr, hoặc tính bất biến thực sự bằng các bản chụp ZFS.

Sử dụng chattr trên Linux:
Cờ +i (bất biến) ngăn chặn việc sửa đổi, xóa hoặc đổi tên tệp.

# Dump cơ sở dữ liệu
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Làm cho bản sao lưu trở nên bất biến
sudo chattr +i /backups/mydb_$(date +%F).dump

# Xác minh thuộc tính
lsattr /backups/mydb_$(date +%F).dump
# Kết quả: ----i---------e------- /backups/mydb_2023-10-27.dump

Lưu ý: Mặc dù chattr ngăn chặn các tập lệnh ransomware cơ bản, nhưng một kẻ tấn công tinh vi có quyền root có thể chỉ cần chạy chattr -i. Do đó, điều này phải được kết hợp với RBAC nghiêm ngặt và các mạng sao lưu cô lập.

Sử dụng ZFS Snapshots:
ZFS cung cấp khả năng phòng thủ mạnh mẽ hơn nhiều. Bằng cách tạo một bản chụp và đặt “giữ” (hold) trên đó, bạn ngăn không cho bản chụp bị xóa.

# Tạo bản chụp của tập dữ liệu sao lưu
zfs snapshot tank/db_backups@archive_$(date +%F)

# Đặt giữ trên bản chụp để ngăn xóa
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Ngay cả root cũng không thể xóa bản chụp này nếu không giải phóng lệnh giữ
zfs destroy tank/db_backups@archive_$(date +%F)
# Kết quả: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Chiến lược lưu trữ dành riêng cho cơ sở dữ liệu

Để đạt được Phục hồi tại thời điểm cụ thể (PITR), bạn phải liên tục lưu trữ nhật ký giao dịch vào bộ lưu trữ bất biến của mình.

Lưu trữ WAL của PostgreSQL với pgBackRest

pgBackRest là một công cụ sao lưu rất đáng tin cậy cho PostgreSQL, hỗ trợ lưu trữ tương thích với S3. Để bảo vệ các Nhật ký ghi trước (WAL) của bạn, hãy cấu hình pgBackRest để đẩy trực tiếp vào bucket S3 bất biến của bạn.

Trong tệp pgbackrest.conf của bạn:

[global]
repo1-type=s3
repo1-s3-bucket=prod-db-archive-immutable
repo1-s3-region=us-east-1
repo1-s3-endpoint=s3.amazonaws.com
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Đảm bảo thời gian lưu giữ phù hợp với cấu hình S3 Object Lock của bạn
repo1-retention-full=2
repo1-retention-archive=2

[prod_cluster]
pg1-path=/var/lib/postgresql/14/main

Cân nhắc quan trọng: Nếu bucket S3 của bạn thực thi khóa Tuân thủ 30 ngày, nhưng pgBackRest cố gắng hết hạn và xóa các tệp WAL sau 14 ngày dựa trên repo1-retention-archive, các lệnh gọi API xóa sẽ thất bại. Bạn phải đảm bảo chính sách lưu giữ của phần mềm sao lưu lớn hơn hoặc bằng khóa bất biến ở cấp lưu trữ.

Microsoft SQL Server: Sao lưu tới URL

SQL Server hỗ trợ sao lưu gốc trực tiếp vào lưu trữ đối tượng tương thích với S3. Bạn có thể cấu hình một tác vụ SQL Server Agent để ghi các tệp .bak và .trn trực tiếp vào một bucket bất biến.

CREATE CREDENTIAL [s3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com]
WITH IDENTITY = 'S3 Access Key',
SECRET = 'AccessKeyID:SecretAccessKey';
GO

BACKUP DATABASE [ProductionDB]
TO URL = 's3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com/ProductionDB_Full.bak'
WITH FORMAT, COMPRESSION, STATS = 10;
GO

Tự động hóa và Điều phối với CloudSave

Việc quản lý các cờ lưu giữ bất biến, xoay vòng khóa truy cập và đảm bảo đồng bộ hóa giữa các chính sách lưu giữ cơ sở dữ liệu và khóa lưu trữ thông qua các tập lệnh tùy chỉnh rất dễ xảy ra lỗi. Một cấu hình sai trong cron job hoặc lệnh gọi API có thể khiến các bản lưu trữ của bạn bị lộ hoặc dẫn đến chi phí lưu trữ đám mây tăng vọt do các đối tượng bị khóa không còn được sử dụng.

Các nền tảng sao lưu doanh nghiệp như CloudSave đơn giản hóa kiến trúc này. CloudSave tích hợp sẵn với AWS S3 Object Lock, Azure Blob Immutable Storage và các API tương thích với S3 tại chỗ.

Khi cấu hình kế hoạch sao lưu cơ sở dữ liệu trong CloudSave:
1. Nền tảng tự động xử lý việc tạm dừng VSS (Volume Shadow Copy Service) cho SQL Server hoặc API pg_start_backup() cho PostgreSQL.
2. Nó truyền dữ liệu sao lưu đã được khử trùng lặp và mã hóa trực tiếp đến mục tiêu lưu trữ.
3. CloudSave áp dụng linh hoạt các lệnh gọi API WORM (ví dụ: PutObjectRetention) trên cơ sở từng đối tượng, căn chỉnh hoàn hảo thời gian khóa lưu trữ với lịch trình lưu giữ được xác định bởi chính sách.
4. Nếu kẻ tấn công xâm nhập bảng điều khiển quản lý CloudSave, chúng vẫn không thể xóa các bản sao lưu, vì khóa tuân thủ được thực thi bởi cơ sở hạ tầng lưu trữ bên dưới, chứ không phải phần mềm sao lưu.

Các phương pháp hay nhất cho Lưu trữ Cơ sở dữ liệu Bất biến

Để đảm bảo kiến trúc bất biến của bạn thực sự kiên cường, hãy tuân thủ các phương pháp hay nhất về kỹ thuật hệ thống sau đây:

1. Đồng bộ hóa NTP nghiêm ngặt

Các khóa bất biến được gắn kết toán học với dấu thời gian. Nếu dịch vụ NTP (Giao thức thời gian mạng) trên mảng lưu trữ hoặc máy chủ sao lưu của bạn bị xâm nhập hoặc sai lệch, nó có thể khiến các khóa hết hạn sớm hoặc không bao giờ hết hạn. Đảm bảo cơ sở hạ tầng lưu trữ của bạn sử dụng các nguồn NTP được xác thực và dự phòng.

2. Cô lập các vai trò và thông tin xác thực IAM

Thông tin xác thực được sử dụng để ghi vào bucket bất biến chỉ được có quyền s3:PutObject và s3:PutObjectRetention. Chúng không bao giờ được có quyền s3:DeleteObject hoặc s3:PutBucketObjectLockConfiguration.

Ví dụ về chính sách IAM đặc quyền tối thiểu cho một tác nhân sao lưu cơ sở dữ liệu:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetBucketObjectLockConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::prod-db-archive-immutable",
                "arn:aws:s3:::prod-db-archive-immutable/*"
            ]
        }
    ]
}

3. Định cỡ thời gian lưu giữ

Không đặt khóa tuân thủ trong thời gian quá dài (ví dụ: 7 năm để tuân thủ) trên tầng phục hồi nhanh chính của bạn. Cơ sở dữ liệu tạo ra lượng dữ liệu WAL/nhật ký giao dịch khổng lồ. Khóa dữ liệu này trong nhiều năm sẽ dẫn đến chi phí lưu trữ tăng theo cấp số nhân.
Thay vào đó, hãy sử dụng phương pháp phân tầng:
* Tầng phục hồi vận hành: 14 đến 30 ngày lưu giữ bất biến cho các bản Full và Log.
* Tầng lưu trữ dài hạn: Các bản sao lưu đầy đủ hàng tháng được chuyển sang Glacier/Deep Archive với Vault Lock trong 1-7 năm.

4. Kiểm tra phục hồi thường xuyên trong các VPC cô lập (Air-gapped)

Tính bất biến đảm bảo dữ liệu không thể bị xóa, nhưng không đảm bảo dữ liệu không bị hỏng logic. Bạn phải tự động hóa việc khôi phục các bản lưu trữ cơ sở dữ liệu bất biến của mình vào một VPC hoặc VLAN cô lập. Chạy DBCC CHECKDB (SQL Server) hoặc pg_amcheck (PostgreSQL) trên dữ liệu đã khôi phục để xác minh tính toàn vẹn cấu trúc.

Kết luận

Phòng thủ ransomware là một bài tập về việc giả định sự xâm nhập. Vào thời điểm cảnh báo được kích hoạt trong SIEM của bạn, những kẻ tấn công có khả năng đã cố gắng xâm nhập cơ sở hạ tầng sao lưu của bạn. Bằng cách thiết kế các bản lưu trữ cơ sở dữ liệu của bạn bằng lưu trữ bất biến ở Chế độ Tuân thủ, bạn tước bỏ đòn bẩy chính của kẻ tấn công. Cho dù bạn sử dụng API đám mây gốc, ZFS holds hay nền tảng điều phối doanh nghiệp như CloudSave, việc triển khai lưu trữ WORM không còn là tùy chọn—đó là một trụ cột bắt buộc của quản trị cơ sở dữ liệu hiện đại và phục hồi sau thảm họa.

Danh mục