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」はイミュータブル（不変）ストレージを表します。

本記事では、ランサムウェアに対する絶対的な耐性を確保するために、データベースアーカイブ向けのイミュータブルストレージを設計、実装、管理するための包括的かつ技術的な詳細を解説します。

イミュータブルストレージの仕組み

イミュータブルストレージは、WORM（Write-Once-Read-Many：一度書き込めば変更不可）アーキテクチャに基づいています。データがイミュータブルなターゲットに書き込まれると、数学的に強制された時間ロックが期限切れになるまで、ルート権限を持つ管理者や侵害されたサービスアカウントを含むいかなるユーザーであっても、そのデータを変更、暗号化、削除することはできません。

コンプライアンスモードとガバナンスモード

AWS S3、Azure Blob、またはS3互換のオンプレミスSANなどのクラウドオブジェクトストレージでイミュータビリティを実装する際は、保持モードの違いを理解しておく必要があります。

  • ガバナンスモード： 標準ユーザーによるオブジェクトの削除や変更を防ぎます。ただし、特定のIAM権限（例：s3:BypassGovernanceRetention）を持つユーザーはロックを上書きできます。これはテストには便利ですが、攻撃者がドメイン管理者やルート権限に昇格することが多いため、ランサムウェア対策としては不十分です。
  • コンプライアンスモード： ランサムウェア対策におけるゴールドスタンダードです。コンプライアンスモードでオブジェクトがロックされると、保持期間を短縮することはできず、AWSルートアカウントを含む誰であってもオブジェクトを削除できません。ロックはストレージクラスターレベルで強制されます。

イミュータブルなバックアップパイプラインの設計

堅牢なデータベースアーカイブアーキテクチャでは、アクティブなデータベース運用とイミュータブルなアーカイブ層を分離します。データベースは継続的な読み取り/書き込みアクセスを必要とするため、アクティブなデータベースファイル（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でデータベースダンプやトランザクションログを保護するには、バケット作成時にObject Lockを有効にする必要があります。

まず、Object Lockを有効にしてバケットを作成します：

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

次に、デフォルトの保持ポリシーを設定します。データベースアーカイブの場合、30日間のコンプライアンスロックが標準的なベースラインであり、1か月分の変更不可能なバックアップを確保できます。

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は基本的なランサムウェアスクリプトを阻止しますが、ルート権限を持つ高度な攻撃者は単にchattr -iを実行する可能性があります。そのため、厳格なRBACおよび分離されたバックアップネットワークと組み合わせる必要があります。

ZFSスナップショットの使用：
ZFSはより強力な防御を提供します。スナップショットを取得し、それに「ホールド（保持）」をかけることで、スナップショットが破棄されるのを防ぎます。

# バックアップデータセットのスナップショットを取得
zfs snapshot tank/db_backups@archive_$(date +%F)

# 削除を防ぐためにスナップショットにホールドをかける
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# ルートであってもホールドを解除せずにこのスナップショットを破棄することはできない
zfs destroy tank/db_backups@archive_$(date +%F)
# 出力: cannot destroy 'tank/db_backups@archive_...': dataset is busy

データベース固有のアーカイブ戦略

ポイントインタイムリカバリ（PITR）を実現するには、トランザクションログをイミュータブルストレージに継続的にアーカイブする必要があります。

pgBackRestによるPostgreSQL WALアーカイブ

pgBackRestは、S3互換ストレージをネイティブにサポートする、PostgreSQL用の非常に信頼性の高いバックアップツールです。Write-Ahead Logs（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エージェントジョブを設定して、.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日間のイミュータブル保持。
* 長期アーカイブ層： 1〜7年間、Vault Lockを使用してGlacier/Deep Archiveに移動された月次フルバックアップ。

4. エアギャップVPCでの定期的なリカバリテスト

イミュータビリティはデータが削除されないことを保証しますが、データに論理的な破損がないことを保証するものではありません。イミュータブルなデータベースアーカイブを、分離されたエアギャップVPCまたはVLANに自動的に復元する必要があります。復元されたデータに対してDBCC CHECKDB（SQL Server）またはpg_amcheck（PostgreSQL）を実行し、構造的な整合性を検証してください。

結論

ランサムウェア対策は、侵害を前提とした取り組みです。SIEMでアラートが鳴る頃には、脅威アクターはすでにバックアップインフラを侵害しようとしている可能性が高いでしょう。コンプライアンスモードでイミュータブルストレージを使用してデータベースアーカイブを設計することで、攻撃者から彼らの主要な武器を奪うことができます。ネイティブのクラウドAPI、ZFSホールド、またはCloudSaveのようなエンタープライズオーケストレーションプラットフォームのいずれを利用する場合でも、WORMストレージの実装はもはやオプションではなく、現代のデータベース管理と災害復旧における必須の柱です。

カテゴリー