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 权限的管理员或被入侵的服务账户）都无法对其进行修改、加密或删除，直到数学强制的时间锁过期。

合规模式 vs. 管理模式

在实施不可变性时，特别是在 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 不可变存储、Google Cloud Storage 保留策略。
* 本地对象存储： 支持 S3 Object Lock API 的 MinIO、Cloudian 或 Pure Storage FlashBlade。
* 块/文件存储： 具有只读快照和委派管理的 ZFS，或 Linux 文件属性。

实施不可变存储：技术演练

1. 云对象存储：AWS S3 Object Lock

要在 AWS 中保护数据库转储和事务日志，您必须在创建存储桶时启用对象锁定 (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 对象锁定配置一致
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 代理作业，将 .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 不可变存储和本地 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. 在隔离的 VPC 中进行定期恢复测试

不可变性保证了数据不会被删除，但不能保证数据没有逻辑损坏。您必须自动化将不可变数据库归档恢复到隔离的 VPC 或 VLAN 中的过程。在恢复的数据上运行 DBCC CHECKDB (SQL Server) 或 pg_amcheck (PostgreSQL) 以验证结构完整性。

结论

勒索软件防御是一项基于“假设已遭入侵”的练习。当您的 SIEM 发出警报时，威胁行为者很可能已经尝试破坏您的备份基础设施。通过在合规模式下使用不可变存储来架构您的数据库归档，您可以剥夺攻击者的主要筹码。无论您是利用原生云 API、ZFS 保留，还是像 CloudSave 这样的企业编排平台，实施 WORM 存储已不再是可选项，而是现代数据库管理和灾难恢复的强制性支柱。

分类