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.

在現代威脅環境中，勒索軟體已從機會主義式的加密演變為高度針對性的多重勒索攻擊。進階持續性威脅 (APT) 和勒索軟體集團現在會在潛伏期間主動搜尋備份基礎設施和資料庫封存檔。如果攻擊者破壞了您的主資料庫，同時刪除或加密了您的備份儲存庫，您的組織將面臨災難性的資料遺失。

對於資料庫管理員 (DBA) 和 DevOps 工程師而言，傳統的 3-2-1 備份策略已不再足夠。為了確保資料的存活能力，基礎設施團隊必須採用 3-2-1-1 規則，其中最後的「1」代表不可變儲存 (Immutable Storage)。

本文將針對資料庫封存檔的不可變儲存架構、實作與管理提供全面且深入的技術探討，以確保絕對的勒索軟體防禦能力。

不可變儲存的機制

不可變儲存依賴於「一次寫入，多次讀取」(WORM) 架構。一旦資料寫入不可變目標，任何使用者（包括擁有 root 權限的管理員或被入侵的服務帳戶）都無法修改、加密或刪除該資料，直到數學強制執行的時間鎖定到期為止。

合規模式 (Compliance Mode) 與治理模式 (Governance Mode)

在實作不可變性時，特別是在 AWS S3、Azure Blob 或支援 S3 的地端 SAN 等雲端物件儲存中，您必須了解這兩種保留模式的區別：

  • 治理模式 (Governance Mode)： 防止一般使用者刪除或變更物件。然而，擁有特定 IAM 權限（例如 s3:BypassGovernanceRetention）的使用者可以覆蓋鎖定。這對於測試很有用，但不足以防禦勒索軟體，因為攻擊者通常會將權限提升至網域管理員或 root。
  • 合規模式 (Compliance Mode)： 勒索軟體防禦的黃金標準。一旦物件在合規模式下被鎖定，其保留期限便無法縮短，且任何人（包括 AWS root 帳戶）都無法刪除該物件。鎖定是在儲存叢集層級強制執行的。

建構不可變備份管線

穩健的資料庫封存架構會將主動資料庫操作與不可變封存層分開。您無法將不可變性應用於主動資料庫檔案（例如 SQL Server 中的 .mdf/.ldf 或 PostgreSQL 中的 pg_data 目錄），因為資料庫需要持續的讀寫存取。

相反地，不可變性應應用於：
1. 完整與差異備份檔案： 資料庫的基準快照。
2. 交易記錄 / WAL 檔案： 進行時間點還原 (PITR) 所需的持續資料庫變更串流。

不可變儲存目標

您可以在不同的基礎設施層級實作不可變儲存：
* 雲端物件儲存： AWS S3 Object Lock、Azure Blob Immutable Storage、Google Cloud Storage Retention Policies。
* 地端物件儲存： 支援 S3 Object Lock API 的 MinIO、Cloudian 或 Pure Storage FlashBlade。
* 區塊/檔案儲存： 具有唯讀快照與委派管理功能的 ZFS，或 Linux 檔案屬性。

實作不可變儲存：技術演練

1. 雲端物件儲存：AWS S3 Object Lock

若要在 AWS 中保護資料庫傾印檔與交易記錄，您必須在建立儲存貯體 (Bucket) 時啟用 Object Lock。

首先，建立已啟用 Object Lock 的儲存貯體：

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

接著，設定預設保留原則。對於資料庫封存檔，30 天的合規鎖定是標準基準，確保您擁有一個月不可竄改的備份。

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

當您的資料庫備份指令碼或代理程式將檔案推送到此儲存貯體時，S3 會根據物件建立時間戳記加上 30 天，自動計算 Retain Until Date（保留至日期）。

2. 地端不可變性：ZFS 與 Linux 屬性

如果您將資料庫封存至地端的 Linux 備份伺服器，可以使用 chattr 指令達成偽不可變性，或使用 ZFS 快照達成真正的不可變性。

使用 Linux chattr：
+i (不可變) 旗標可防止檔案被修改、刪除或重新命名。

# 傾印資料庫
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# 使備份變為不可變
sudo chattr +i /backups/mydb_$(date +%F).dump

# 驗證屬性
lsattr /backups/mydb_$(date +%F).dump
# 輸出: ----i---------e------- /backups/mydb_2023-10-27.dump

注意：雖然 chattr 可以阻止基本的勒索軟體指令碼，但擁有 root 權限的進階攻擊者只需執行 chattr -i 即可。因此，這必須結合嚴格的 RBAC 與隔離的備份網路使用。

使用 ZFS 快照：
ZFS 提供了更強大的防禦。透過建立快照並對其進行「保留 (hold)」，您可以防止快照被銷毀。

# 為備份資料集建立快照
zfs snapshot tank/db_backups@archive_$(date +%F)

# 對快照進行保留以防止刪除
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# 即使是 root 也無法在不解除保留的情況下銷毀此快照
zfs destroy tank/db_backups@archive_$(date +%F)
# 輸出: cannot destroy 'tank/db_backups@archive_...': dataset is busy

資料庫專屬的封存策略

為了達成時間點還原 (PITR)，您必須持續將交易記錄封存至您的不可變儲存空間。

使用 pgBackRest 進行 PostgreSQL WAL 封存

pgBackRest 是一款高度可靠的 PostgreSQL 備份工具，原生支援 S3 相容儲存。為了保護您的預寫記錄 (WAL)，請將 pgBackRest 設定為直接推送到您的不可變 S3 儲存貯體。

在您的 pgbackrest.conf 中：

[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

# 確保保留期限與您的 S3 Object Lock 設定一致
repo1-retention-full=2
repo1-retention-archive=2

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

關鍵考量： 如果您的 S3 儲存貯體強制執行 30 天的合規鎖定，但 pgBackRest 根據 repo1-retention-archive 嘗試在 14 天後過期並刪除 WAL 檔案，刪除 API 呼叫將會失敗。您必須確保備份軟體的保留原則大於或等於儲存層級的不可變鎖定。

Microsoft SQL Server：備份至 URL

SQL Server 支援直接備份至 S3 相容的物件儲存。您可以設定 SQL Server Agent 工作，將 .bak 和 .trn 檔案直接寫入不可變儲存貯體。

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

使用 CloudSave 進行自動化與編排

透過自訂指令碼來管理不可變保留旗標、輪替存取金鑰，並確保資料庫保留原則與儲存鎖定之間的同步，極易出錯。Cron 工作或 API 呼叫中的單一錯誤設定，可能會導致您的封存檔暴露，或因孤立的鎖定物件而導致雲端儲存成本飆升。

像 CloudSave 這樣的企業級備份平台簡化了此架構。CloudSave 原生整合了 AWS S3 Object Lock、Azure Blob Immutable Storage 以及地端 S3 相容 API。

在 CloudSave 中設定資料庫備份計畫時：
1. 該平台會自動處理 SQL Server 的 VSS (磁碟區陰影複製服務) 靜止，或 PostgreSQL 的 pg_start_backup() API。
2. 它會將去重複、加密後的備份資料直接串流傳輸至儲存目標。
3. CloudSave 會動態地以每個物件為基礎套用 WORM API 呼叫 (例如 PutObjectRetention)，將儲存鎖定持續時間與原則定義的保留排程完美對齊。
4. 如果攻擊者破壞了 CloudSave 管理主控台，他們仍然無法刪除備份，因為合規鎖定是由底層儲存基礎設施強制執行的，而非備份軟體。

不可變資料庫封存的最佳實踐

為了確保您的不可變架構真正具有韌性，請遵循以下系統工程最佳實踐：

1. 嚴格的 NTP 同步

不可變鎖定在數學上與時間戳記綁定。如果您的儲存陣列或備份伺服器上的 NTP (網路時間協定) 服務被破壞或發生偏移，可能會導致鎖定過早過期或永遠不過期。請確保您的儲存基礎設施使用經過驗證的冗餘 NTP 來源。

2. 隔離 IAM 角色與憑證

用於寫入不可變儲存貯體的憑證必須僅擁有 s3:PutObject 和 s3:PutObjectRetention 權限。它們絕不應擁有 s3:DeleteObject 或 s3:PutBucketObjectLockConfiguration 權限。

資料庫備份代理程式的最小權限 IAM 原則範例：

{
    "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. 設定保留期限

請勿在您的主要快速復原層上設定過長的合規鎖定（例如 7 年的合規性）。資料庫會產生大量的 WAL/交易記錄資料。將這些資料鎖定數年將導致儲存成本呈指數級成長。
請改用分層方法：
* 營運復原層： 針對完整備份與記錄檔進行 14 到 30 天的不可變保留。
* 長期封存層： 將每月完整備份移至 Glacier/Deep Archive，並使用 Vault Lock 鎖定 1-7 年。

4. 在氣隙 (Air-Gapped) VPC 中進行定期復原測試

不可變性保證了資料不會被刪除，但不能保證資料沒有邏輯損壞。您必須自動將不可變資料庫封存檔還原至隔離的氣隙 VPC 或 VLAN 中。在還原的資料上執行 DBCC CHECKDB (SQL Server) 或 pg_amcheck (PostgreSQL) 以驗證結構完整性。

結論

勒索軟體防禦是一種「假設已遭入侵」的練習。當您的 SIEM 發出警報時，威脅行為者很可能已經嘗試破壞您的備份基礎設施。透過在合規模式下使用不可變儲存來建構您的資料庫封存檔，您可以剝奪攻擊者的主要籌碼。無論您是利用原生雲端 API、ZFS 保留機制，還是像 CloudSave 這樣的企業編排平台，實作 WORM 儲存已不再是選項，而是現代資料庫管理與災難復原的必要支柱。

分類