消されにくいバックアップを導入したい。契約前に確認する変更・削除の制限

バックアップは情報セキュリティの基本対策のひとつです。IPAの6か条に『バックアップを取ろう!』が追加されたことを受け、保存データの誤削除や認証情報侵害に備えて、変更できない仕組みを求める企業が見られます。

導入前に確認すべきポイントを整理し、ベンダーへの具体的な質問例と社内で整えるべき運用ルールを示しますので、まずは以下のチェックリストに沿って確認を進めてください。

導入前に確認すべき削除制限の基本項目

データ保持期間の最小保証は？

データ保持期間は、適用される法令や業務上の要件に基づき、必要な保存期間を明確にしたうえでベンダーに確認します。たとえば税務関連の記録は多くの国で7年保存が求められるケースがありますが、実際の要件は自社の所在地や業種により異なるため、該当する法令を確認してください。

ベンダーの保持ポリシーが自社の要件を下回っていないかをチェックし、契約書に「保持期間は○年以内に自動削除しない」などの条項を盛り込むこと、また例外設定が可能かどうかを質問します。

次に、保持期間が過ぎたデータの削除方法についても聞きます。削除が手動か自動か、削除対象がどのように選定されるか、削除前に管理者が承認できるフローがあるかを確認します。これにより、意図しないデータの消失リスクを低減できます。

認証侵害時の書き込みロックは？

認証情報が侵害された場合、バックアップデータへの書き込みが不正に行われるリスクがあります。ベンダーに対し、書き込みロックやWORMモードの有無、侵害が判明した際にロックを適用できる手順や条件について確認します。ロックが有効になる条件や解除手順も重要です。

ロック解除が必要になるケース（例：法的要請やデータ復旧）について、管理者がどのように手続きを行うか、証跡は残るかを確認してください。証跡が残らない場合、監査時に説明が困難になるため、ログが保持されることを条件に入れることが望ましいです。

誤操作防止の権限分離は？

バックアップシステムへのアクセス権は、管理者と一般ユーザーで明確に分離すべきです。ベンダーに対し、権限ごとの操作可能範囲（例：削除は管理者のみ、閲覧は全員可）を文書化したポリシーがあるかを確認します。権限設定が細かくできるか、変更履歴が残るかも重要です。

また、権限変更時に多要素認証や承認フローが組み込まれているかを質問し、実際に運用する際の手順書をベンダーから入手できるかどうかを確認してください。権限分離が不十分だと、誤操作や内部不正によるデータ消失リスクが高まります。

ベンダーに質問すべき具体的な機能

WORM（書き込み一次性）機能の有無

WORMはデータを書き込んだ後に原則として変更や削除ができない仕組みで、イミュータブルバックアップの代表的な機能とされています。ベンダーに対し、WORMモードが提供されているか、どのレイヤー（ストレージ、アプリケーション、クラウド）で実装されているかを具体的に聞きます。実装場所により、コストやパフォーマンスへの影響が異なるため、比較材料にします。

WORM（Write‑Once‑Read‑Many）機能の有効期間についても確認が必要です。ベンダーが提供する期間設定例としては30日、90日、無期限などがありますが、実際の設定は自社の保存要件に合わせて選択します。期間満了後に自動で解除されるか、手動で解除する場合の手順とその操作履歴（証跡）が保存されるかを確認してください。

設定期間が法令上の保存義務と合致しているかを自社で検証し、必要に応じて調整できるかどうかを質問します。

変更履歴の追跡と証跡保存

バックアップデータがいつ、誰によって変更・削除されたかを追跡できるかは、インシデント後の調査に不可欠です。ベンダーに対し、変更履歴が自動で記録され、少なくとも何日間保存されるかを質問します。保存期間は、監査要件や社内規程に合わせて設定できるかも重要です。

また、証跡が改ざん防止機能（ハッシュやデジタル署名）で保護されているか、証跡データを外部にエクスポートできるかを確認してください。証跡が信頼できなければ、削除や改ざんが疑われた際に正確な原因究明ができません。

法令遵守と監査対応のサポート

バックアップは個人情報保護法や金融機関向け規制など、業界ごとの法令遵守が求められます。ベンダーに対し、イミュータブル機能がこれらの法令要件を満たす設計になっているか、監査時に提示できるレポートや設定例が提供されているかを確認します。

さらに、ベンダーが提供するサポート体制（例：法令改正時の機能追加や設定変更支援）や、監査対応のためのトレーニングがあるかどうかを質問してください。自社だけで対応できない場合、ベンダーのサポートが重要な判断材料となります。

運用ルールと社内手順の整備ポイント

バックアップ対象と除外の明確化

まず、バックアップ対象となるデータと除外対象を社内で明確に定義します。業務システム、ファイルサーバ、メールなど、重要度に応じて優先順位を付け、除外するログや一時ファイルの範囲を決めます。これにより、無駄な容量消費とバックアップウィンドウの短縮が期待できます。

定義した対象リストは、ベンダーの設定画面でどのように登録できるか、除外ルールの変更がリアルタイムに反映されるかを確認してください。また、対象リストの変更履歴が残るかどうかも重要です。変更があった際は、担当者が承認し、証跡を残す手順を作ります。

定期的なリストアテストの実施方法

バックアップが正しく保存されていても、復元できなければ実務上の価値はありません。リストアテストは自社のリスク許容度や業務継続計画に応じて定期的に実施し、実施頻度や対象データは社内で決定します。テストでは本番データの代表的なサブセットを使用し、復元手順と所要時間を記録するとともに、復元後のデータ整合性を確認します。

テスト結果は改善点の洗い出しやSLAの見直しに活用してください。

ベンダーに対し、リストアテスト用のシミュレーション機能や、テスト実行時に本番環境に影響を与えないモードがあるかを質問します。また、テスト結果のレポートが自動生成できるか、保存期間はどれくらいかも確認すると、監査時に有用です。

インシデント時の連絡フローと責任分担

バックアップに関するインシデント（例：削除誤操作、認証情報漏洩）が発生した際の連絡フローを事前に策定します。まず、インシデントの検知者、一次対応者、エスカレーション先を明確にし、連絡手段（メール、電話、チャット）を決めます。

ベンダー側のサポート窓口や対応時間帯、緊急時の対応手順（例：ロック解除依頼の手順）を事前に取得し、社内マニュアルに組み込みます。責任分担が曖昧だと復旧が遅れ、業務停止時間が長くなるため、契約書にSLA（サービスレベル）を明記することも検討してください。

判断材料と次のステップ

ベンダー比較の評価項目チェックリスト

ベンダー選定時は、以下の項目をチェックリスト化して比較します。①イミュータブル機能の有無と有効期間、②変更履歴の保存期間と改ざん防止策、③法令対応レポートの提供有無、④権限分離と多要素認証の実装、⑤サポート体制とSLA。各項目に対し、ベンダーから得た回答を表にまとめ、要件を満たすか点数化すると客観的に比較できます。

チェックリストは、導入前の社内レビュー会議で使用し、関係部門（経営、情報システム、法務）の合意を得る材料にします。点数が低い項目は追加交渉や別ベンダーへの切り替えの根拠となります。

社内リスク評価と導入可否の判断基準

リスク評価は、バックアップが失われた場合の業務影響度と復旧コストを定量化します。たとえば、重要データが失われた際の売上損失や顧客信頼低下をシミュレーションし、イミュータブル機能がリスクをどれだけ低減できるかを算出します。

評価結果でリスク低減効果が導入コストを上回ると判断された場合は導入を検討し、逆の場合は多重バックアップやオフライン保存などの代替策を検討します。最終判断は、経営層への提案資料にまとめ、承認を得るプロセスを踏みます。

専門家への相談タイミングと必要情報

ベンダーからの回答だけで判断が難しい場合、情報セキュリティの専門家（外部コンサルタントや認定情報セキュリティ管理者）に相談します。相談時に必要な情報は、①現在のバックアップ構成図、②ベンダーから取得した機能仕様書、③法令要件の抜粋、④社内リスク評価シートです。

専門家は、上記資料を基にイミュータブル機能の実装可否や運用上の注意点をレビューし、最終的な導入判断をサポートします。必要に応じて、第三者評価レポートを取得し、契約交渉の材料に活用してください。