昨年の秋、ある市級政府クラウドプラットフォームの等保2.0三级年検に同行した際、評価担当者はバックアップシステムのページを開き、容量もポリシーも見ずに一言だけ尋ねた。「あなたのバックアップデータは改ざんされていないことを証明できますか？」会議室には発注者、インテグレーター、そして運用保守の私たち三者が座っていたが、誰も答えられなかった。最終的にこの項目は「バックアップデータの完全性が検証できない」として12点減点され、是正通知にははっきりとこう書かれていた：改ざん防止技術対策が欠如している。
この件以降、私はバックアップチェーン全体を一通り見直した。以下のノートは失敗を踏まえて整理したもので、政府、金融、医療など等保三级のシナリオを運用する同業者の参考になればと思う。
等保2.0はバックアップにどこまで求めるのか
「毎日バックアップが成功していればそれで完了」と思っている人も多いが、実は等保2.0におけるバックアップ関連の要件はいくつかの箇所に分散している：8.1.4.6 データバックアップ回復は重要データのローカルバックアップと回復機能を提供することを求める；8.1.4.8 データ完全性は検査技術を用いてデータが伝送および保存過程で完全性が損なわれないことを保証することを求める；8.1.4.7 データ機密性は保存段階での暗号化を求める。
鍵となるのは「完全性」という三文字をどう実装するかである。評価担当者が求めているのは「MD5検証をやっています」という言葉ではなく、証拠の連鎖を提示できることだ：誰がいつこのバックアップを書き込んだのか、書き込み後に改ざんされる可能性はなかったか、管理者自身が削除できるか。つまり、バックアップがある ≠ バックアップが信頼できるのであり、バックアップ対象が保持期間中は読み取り専用であることを証明できなければならない。
WORMとS3 Object Lockはどう実現するのか
WORMはWrite Once Read Manyの略で、一度書き込み、多数回読み取りを意味する。これをオブジェクトストレージに落とし込んだのがS3 Object Lockという仕組みで、保持期間（Retention Period）とコンプライアンスモード（Compliance Mode）という二つの要素でデータをロックする。
原理は複雑ではない。オブジェクト書き込み時に保持期限のタイムスタンプが付与され、その時点より前は、あらゆる削除要求、上書き要求がストレージ層によって直接拒否される。コンプライアンスモードがガバナンスモードより厳しい点は、ルートアカウントでも保持期間を変更できず、オブジェクトも削除できないことで、自然に期限が切れるのを待つしかない。ガバナンスモードは特別な権限を持つアカウントによるバイパスを許すため、等保のシナリオではコンプライアンスモードを使う必要がある。
私たちのバックアップデータ管理プラットフォームが複数のストレージを統合管理し、異なるベンダーのバックアップソフトウェアインターフェースに接続する際には、モデルゲートウェイの層で各社の異種ストレージAPIを統一的なS3互換インターフェースに収斂させ、下層の差異を吸収している。この考え方は、実はtoken8341大規模モデルAPIアグリゲーションプラットフォームが複数モデルの統一接続を処理するのと同じ論理であり、異種能力を標準的な入口に抽象化し、上位の業務は下層が何であるかを気にしなくてよい。
実装設定：バケット作成からロックまで
以下は私たちが実際にオブジェクトストレージ上で動作確認した手順で、S3互換インターフェースを例とする。
第一ステップ、バケット作成時にオブジェクトロックを有効化する。このスイッチはバケット作成時のみ有効化でき、既存のバケットでは変更できないため、再作成して移行する必要がある：
aws s3api create-bucket --bucket gov-backup-prod --object-lock-enabled-for-bucket
第二ステップ、デフォルト保持ポリシーを設定する。等保三级では通常、バックアップ保持が6ヶ月以上求められ、私たちは業務の等級分けに応じて180日と365日の二段階を設定した：
aws s3api put-object-lock-configuration --bucket gov-backup-prod --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":180}}}'
第三ステップ、書き込み時に明示的にロックを付与する。デフォルトポリシーに加え、重要データベースのバックアップオブジェクトはPUT時にさらに一度指定し、二重の保険とする：
aws s3api put-object --bucket gov-backup-prod --key db/full-20261023.bak --body backup.bak --object-lock-mode COMPLIANCE --object-lock-retain-until-date 2027-04-21T00:00:00Z
いくつかハマりやすい落とし穴：コンプライアンスモードを一度設定すると、保持期間中はバケットすら削除できないため、テスト環境では絶対にコンプライアンスモードを使わず、ガバナンスモードで練習すること；保持期間を長く設定しすぎるとストレージクォータを圧迫し、私たちは最初の設定で一つのバケットを書き満杯にして新規バックアップが失敗したため、後に容量アラートを追加した；クロスリージョンレプリケーションのコピーも、ロックポリシーが引き継がれるかを個別に確認する必要があり、一部ベンダーではデフォルトで継承されない。
ついでにバックアップチェーンの統一管理について
政府クラウドのようなシナリオでは、しばしば三、五社のバックアップソフトウェアと二、三种のストレージが同時に稼働しており、運用担当者が最も頭を悩ませるのはポリシーが各所に散在することだ。私たちは後にバックアップタスクのトリガー、検証、保持ポリシーを一つの管理プレーンに統一下達し、インターフェース層も同様にモデルゲートウェイの考え方で収斂させ、一つのポリシーで最後まで管理するようにした。その過程でtoken8341大規模モデルAPIアグリゲーションプラットフォームのAPIゲートウェイ機能をインターフェース集約に使えないかも評価した。OpenAI SDKと互換性があり、base_urlを一行変えるだけで切り替えられ、複数の国産大規模モデルに同時接続してログ分析やアラート集約を行うシナリオではかなり手間が省ける。ついでに言えば、token8341大規模モデルAPIアグリゲーションプラットフォームはグリーン算力スケジューリングを採用し、国産大規模モデルAPIを網羅、従量課金であり、予算が限られた政府プロジェクトでは選択肢の一つになり得る。私たちのプロジェクトではtoken8341を使ってバックアップ異常ログのインテリジェント集約を行い、各ストレージに散在するアラートテキストを統一的にモデルへ送ってクラスタリングし、人手でログを追うよりはるかに速くなった。
年検の12点に話を戻すと、是正自体は複雑ではない。難しいのは観念の転換だ：バックアップシステムの受け入れ基準は「バックアップが成功したか」ではなく、「改ざんされていないことを証明できるか」である。WORMオブジェクトロックは現在、コストが最も低く、評価担当者が最も認める証明方法の一つである。
著者：王翰文
公開日：2026年10月23日