Soft Deleteだけで安心していた現場の話
- 山崎行政書士事務所
- 5月2日
- 読了時間: 20分
― Azure Blob Storageにおける「復旧できる設計」と「証明できる設計」の差異、ならびにクラウド法務上の説明責任 ―
※本稿は、Azure構成、クラウド運用、監査証跡、契約・規程・責任分界の整理を目的とする一般的情報提供です。個別紛争、訴訟対応、代理交渉、個別法的判断は弁護士等の専門領域となる場合があります。山崎行政書士事務所のクラウド法務としては、行政書士業務の範囲を守りつつ、Azure現場の技術実態を文書・規程・説明資料・証跡へ落とし込む観点から論じます。
要旨
Azure Blob StorageでSoft Delete、すなわちBLOBの論理的な削除を有効化している現場では、「誤削除しても戻せるから大丈夫」と説明されることがある。しかし、実務上の事故では、データを復旧できた後に本当の問題が露呈する。
それは、次の三点である。
上書き前の状態を、どの世代として復元したのか。誰が、いつ、どの権限で削除または変更したのか。保全すべきデータが、通常の運用権限で変更・削除できる状態だったのではないか。
Microsoft Learnでは、BLOBの論理的な削除を有効にすると、削除または上書きされたオブジェクトを保持期間中に復元でき、保持期間は1日から365日の範囲で指定できると説明されている。一方で、MicrosoftはBLOBデータの最適な保護のために、コンテナーの論理的な削除、BLOBのバージョン管理、BLOBの論理的な削除を併用することを推奨している。つまり、Soft Deleteは包括的なデータ保護戦略の一部であって、単独で改ざん防止、世代証明、監査証跡、法的保全までを満たすものではない。
本稿の結論は明確である。Soft Deleteは「戻す」ための機能であり、「改ざんされていないことを証明する」ための設計ではない。 復旧できる設計から、証明できる設計へ。消せる設計ではなく、消されても守れる設計へ。これがAzure Storageにおけるクラウド法務の実務である。
キーワード： Azure Blob Storage、Soft Delete、Blob Versioning、Immutable Storage、WORM、Change Feed、StorageBlobLogs、監査証跡、クラウド法務、情シス
1. 序論：復旧できたのに、なぜ監査で詰まるのか
ある本番環境で、業務ファイルが誤って削除された。
情シスは急いでAzureポータルを開き、削除済みBLOBを表示し、保持期間内であることを確認した。復元操作は成功した。アプリケーションも再起動し、業務部門からは「ファイルが戻った」と連絡が来た。現場には一瞬、安堵の空気が流れた。
しかし、問題はその後だった。
監査担当が聞いた。
「その復元したファイルは、いつ時点の状態ですか」「削除前に上書きされていませんか」「復元したデータが改ざんされていないことは、何で説明しますか」「誰が削除したのですか」「削除した人は、なぜその権限を持っていたのですか」「保全対象データを、通常の運用権限で消せる設計だったのですか」
ここで現場は止まった。
復旧はできた。しかし、証明できなかった。
障害報告書に書けたのは、「Soft Deleteにより復元」だけだった。削除者の特定は弱く、共有キーまたはSAS経由の操作が混ざっていたため、個人単位での追跡が難しかった。上書き前の状態は、明確なバージョンIDとして管理されていなかった。保全すべきデータには不変ポリシーがなく、Blob Data Contributor相当の権限を持つ運用者であれば、読み書き削除が可能な構成だった。
これは、単なるストレージ運用の失敗ではない。「復旧」と「証明」を混同した設計事故である。
2. Soft Deleteの射程：戻せるが、守り切る機能ではない
BLOBのSoft Deleteは、誤削除や一部の上書きからの復旧に有効な機能である。Microsoft Learnでは、BLOBの論理的な削除を使用すると、個々のBLOB、スナップショット、またはバージョンが誤った削除または上書きから保護され、保持期間中は削除された時点の状態に復元できると説明されている。保持期間は、データが削除または上書きされた時点から開始される。
この機能は非常に重要である。誤削除、誤上書き、スクリプトのバグ、アプリケーションの不具合、運用者の操作ミスに対して、初動復旧の選択肢を与えるからである。
しかし、Soft Deleteには明確な限界がある。
第一に、保持期間を過ぎれば完全削除される。第二に、コンテナー削除やストレージアカウント削除には別の保護が必要になる。第三に、復旧できることと、改ざんされていないことを証明できることは別である。第四に、誰が削除したかの証跡は、認証方式とログ設計に依存する。第五に、保全対象データを通常権限で消せる状態であれば、統制としては弱い。
Microsoft Learnでも、BLOBの論理的な削除は個々のBLOB、スナップショット、ディレクトリ、またはバージョンの復元に使用できるが、コンテナーとその内容を復元するにはコンテナーの論理的な削除が必要であり、ストレージアカウント削除を保護するにはストレージアカウントリソースに対するロックが必要であると説明されている。
つまり、Soft Deleteは「復旧の部品」である。データ保全の完成形ではない。
3. 現場の生々しい話：「戻りました」で終わらない
現場でよくある流れはこうである。
まず、障害発生時には復旧が最優先になる。業務部門は「ファイルがない」「画面に出ない」「処理が進まない」と言う。情シスは削除済みBLOBを探し、復元する。数十分後、ファイルが戻る。ユーザーは業務を再開する。
ここまではよい。
問題は、その後の報告会である。
経営層が聞く。「原因は何ですか」
情シスが答える。「誤削除です」
監査担当が聞く。「誰が削除しましたか」
運用担当が言う。「ログを確認中です」
セキュリティ担当が聞く。「復元したファイルは、削除直前の状態ですか。それとも、最後に上書きされる前の状態ですか」
アプリ担当が言う。「そこはBlobの状態を見ないと……」
法務・コンプライアンス担当が聞く。「このファイルは証跡保全対象でしたか。通常権限で削除できてよいデータでしたか」
ここで会議室が重くなる。
復旧できたことは事実である。しかし、復旧したデータの完全性、削除者、権限妥当性、保全対象としての扱いを説明できない。
このとき、現場では「Soft Deleteがあるから安心」という言葉が、急に頼りなくなる。Soft Deleteは事故の被害を軽減した。しかし、説明責任を満たしたわけではない。
4. Versioning：いつの状態へ戻したかを説明する
Soft Deleteだけでは、「いつの状態に戻したのか」の説明が弱くなることがある。特に、同じBLOBに対して繰り返し上書きが発生する業務では、明確な世代管理が必要になる。
BLOB Versioningを有効にすると、以前のバージョンのオブジェクトが自動的に維持される。Microsoft Learnでは、BLOBのバージョン管理が有効な場合、以前のバージョンにアクセスでき、変更または削除されたデータを復旧できると説明されている。また、ストレージアカウントでBLOBのバージョン管理が有効な場合、BLOBが最初に作成され、その後変更されるたびに、一意のIDを持つ新しいバージョンが自動的に作成される。
この「バージョンID」が、監査上きわめて重要である。
「ファイルを戻しました」では弱い。「このBLOBのVersionId Xを現在のバージョンへ昇格させました」と言える状態が強い。
Microsoft Learnでは、BLOBの論理的な削除とバージョン管理の両方が有効な場合、上書き時には書き込み前のBLOB状態を反映する新しい以前のバージョンが作成され、その新しいバージョンは論理削除の保持期間が過ぎても削除されないと説明されている。また、BLOB削除時には現在のバージョンが以前のバージョンになり、現在のバージョンはなくなる。以前のバージョンは、直接削除操作またはライフサイクル管理ポリシーで明示的に削除されるまで保持される。
ここがSoft Delete単独との大きな違いである。
Soft Deleteは、削除・上書きからの復旧可能性を与える。Versioningは、復旧対象の世代を説明可能にする。
現場で必要なのは、次の粒度である。
問い | Soft Deleteだけの回答 | Versioningを含む回答 |
どの状態に戻したか | 削除時点の状態を復元した | VersionIdを指定して復元した |
上書き前の状態はあるか | 保持期間・操作種別に依存する | バージョンとして追跡できる |
監査で再抽出できるか | 操作手順が曖昧になりやすい | バージョンIDで説明しやすい |
復元の根拠 | ポータル操作中心 | バージョン履歴・操作ログ・台帳で説明可能 |
ただし、Versioningにもコストと運用がある。Microsoft Learnは、BLOBのバージョン管理を有効にすると、BLOBに対するすべての書き込み操作で新しいバージョンが作成され、追加コストが発生し得るため、ライフサイクル管理ポリシーで古いバージョンを自動削除することを示している。
つまり、Versioningは「入れれば終わり」ではない。保持期間、削除条件、保全対象、ライフサイクル管理、監査証跡をセットで設計する必要がある。
5. Immutability：保全すべきデータは、戻す前に消せない設計にする
Soft DeleteとVersioningは、削除・変更後の復旧に強い。一方、保全すべきデータに対しては、そもそも変更・削除できない設計が必要になる。
Azure Blob StorageのImmutable Storageは、WORM、すなわちWrite Once, Read Manyの状態でデータを格納する機能である。Microsoft Learnでは、不変ストレージを使うと、ユーザーが指定した間隔でデータを変更または削除できず、BLOBデータに不変ポリシーを構成することで上書きや削除から保護できると説明されている。
Azure Blob Storageの不変ストレージでは、時間ベースの保持ポリシーと訴訟ホールドポリシーがサポートされる。時間ベースの保持ポリシーでは、指定した期間、オブジェクトの作成と読み取りは可能だが、変更または削除はできない。訴訟ホールドでは、ホールドが明示的にクリアされるまで不変データを格納する。
ここで重要なのは、「保全対象データを通常権限で消せる設計」にしてはいけないという点である。
Soft Deleteは、消された後に戻す。Immutabilityは、消されない状態を作る。
これは目的が違う。
たとえば、監査証跡、証明書類、契約関連ファイル、個人データの処理記録、取引ログ、障害調査用ログ、内部統制上の証拠、規制対応で保管すべきファイルについて、「誤って消しても戻せます」と説明するだけでは弱い。
問われるのは、「そもそも誰が消せるのか」「消せる権限を持つ人がいてよいのか」「保持期間中に削除できない仕組みになっているのか」である。
Microsoft Learnでは、ロックされた時間ベースの保持ポリシーは削除できず、保持間隔は延長できても短縮できないと説明されている。また、不変ストレージは、アカウント管理特権を持つユーザーであってもデータを変更・削除できないようにする用途にも説明されている。
クラウド法務上、これは極めて重要である。
復旧可能性は、事故対応の設計である。不変性は、証拠保全の設計である。この二つを混同してはならない。
6. 操作ログ：誰が消したかを説明できるか
本件のもう一つの問題は、「誰が削除したか追跡が弱い」ことである。
Azure Blob Storageでは、データプレーン操作とコントロールプレーン操作を分けて監査する必要がある。Microsoft Learnでは、ストレージアカウントの操作は、ストレージアカウント作成やプロパティ更新などのAzure Resource Manager要求であるコントロールプレーン操作と、BLOBアップロード・ダウンロードなどストレージサービスエンドポイントへの要求として行われるデータプレーン操作に分類されると説明されている。
コントロールプレーン操作はAzure Activity Logに取り込まれる。データプレーン操作はAzure Storageのリソースログに取り込まれ、Log AnalyticsへエクスポートすることでKQLで分析できる。Microsoft Learnでは、データプレーン操作について、TimeGenerated、AuthenticationType、RequesterObjectId、OperationName、Uriを抽出するクエリ例が示されている。
たとえば、削除操作を追う初動KQLは、次のような形になる。
StorageBlobLogs| where TimeGenerated between (datetime(2026-05-01T00:00:00Z) .. datetime(2026-05-02T00:00:00Z))| where OperationName in ("DeleteBlob", "DeleteContainer")| project TimeGenerated, AccountName, OperationName, AuthenticationType, RequesterObjectId, CallerIpAddress, UserAgentHeader, Uri, StatusCode, StatusText| order by TimeGenerated descただし、ここにも落とし穴がある。
Microsoft Learnは、要求の承認にMicrosoft Entra IDを使用している場合は、RequesterObjectIdがセキュリティプリンシパルを識別する信頼性の高い方法になる一方、共有キーとSAS認証では個々のIDを監査する手段がなく、操作元の特定にはcallerIPAddressやuserAgentHeaderが役立つ場合があると説明している。
つまり、共有キーやアカウントSASを多用している環境では、削除操作を「個人単位」で説明しにくい。
現場ではよくある。
「このSAS、誰に渡しましたか」「このアカウントキー、どのシステムが持っていますか」「この削除操作は、バッチですか、人ですか」「このIPは踏み台ですか、委託先ですか」「このUserAgentはツールですか、アプリですか」
この問いに答えられない場合、Soft Deleteで復旧できても、監査上は弱い。
Microsoftは、最適なセキュリティのため、可能な限りMicrosoft Entra IDとマネージドIDを使ってBLOB、キュー、テーブルのデータに対する要求を認可することを推奨している。共有キー認可よりセキュリティが向上し、ストレージアカウントに対する共有キー認可を禁止することも推奨されている。
削除者を説明したいなら、認証方式から設計しなければならない。ログだけ後から見ても、誰かを特定できるとは限らない。
7. 診断設定：ログは自動で“証跡”にはならない
Azure Blob Storageのログも、設定しなければ監査証跡として残らない。
Microsoft Learnでは、リソースログはAzureリソースによって実行された操作に関する分析情報を提供するが、保存するかクエリを実行するには、診断設定を作成してAzure Monitor Logs等へルーティングする必要があると説明されている。既定の推奨先はAzure Monitor Logsであり、Log Analyticsで他のログデータと一緒にクエリできる。
また、Azure Storageログには要求の成功と失敗に関する詳細情報が含まれ、個々の要求の監視や問題診断に利用できるが、要求はベストエフォートで記録されると説明されている。
ここで重要なのは、二つである。
第一に、診断設定がなければ、後から「誰が消したか」を追えない可能性がある。第二に、ログは強力な証跡だが、すべてを絶対的に保証する万能の証明ではない。
したがって、クラウド法務としては、次のように整理する必要がある。
証跡 | 目的 | 注意点 |
Activity Log | ストレージアカウント設定変更、診断設定変更、ロック変更等 | データプレーン操作とは別 |
StorageBlobLogs | BLOBの読み書き削除等のデータプレーン操作 | 診断設定と保持設計が必要 |
Change Feed | BLOBやメタデータ変更の順序付きログ | 変更履歴の補助。誰が実行したかは認証ログと併用 |
Versioning | どの世代に戻したかの説明 | 保持・ライフサイクル管理が必要 |
Immutability | 保全対象データの変更・削除防止 | ロック後の変更制約を理解する |
RBAC/ABAC | 誰が何をできるかの統制 | 共有キー・SAS運用と整合が必要 |
「ログがあります」では足りない。どのログを、どの期間、どの条件で、誰が抽出し、どの報告書に添付するかまで決めて初めて、証跡になる。
8. Change Feed：変更の順序を残すという考え方
「いつ、どのBLOBに変更が起きたのか」を追うには、Azure Blob StorageのChange Feedも重要である。
Microsoft Learnでは、Change Feedの目的は、ストレージアカウント内のBLOBとBLOBメタデータに対して行われたすべての変更のトランザクションログを提供することであり、順序付けられ、保証され、永続的で、不変の読み取り専用ログを提供すると説明されている。また、変更ごとに厳密に1つのトランザクションログエントリが生成される。
Change Feedは、Soft DeleteやVersioningと同じく、単独で完全な監査を実現するものではない。しかし、変更の流れを復元するうえでは非常に有用である。
たとえば、次のような調査に使える。
いつBLOBが作成されたか
いつ上書きされたか
いつ削除されたか
どの順序で変更が発生したか
復旧対象の前後にどの変更イベントがあったか
変更履歴とStorageBlobLogsの操作ログに矛盾がないか
ただし、Change Feedは「誰がやったか」を単独で説明するためのものではない。誰が実行したかは、StorageBlobLogs、Activity Log、Microsoft Entra ID、RBAC、SAS管理台帳と組み合わせて説明する必要がある。
つまり、Change Feedは変更履歴の骨格であり、操作ログは実行主体の説明であり、Versioningは復元対象の世代であり、Immutabilityは保全対象の防壁である。
9. 権限設計：通常権限で消せること自体がリスクである
本件で最も危険だったのは、保全対象データも通常権限で削除できる状態だったことである。
Microsoft Learnでは、Microsoft Entra資格情報でBlobデータへアクセスする場合、Azure RBACにより権限が割り当てられ、Blob Data Readerは読み取り、Blob Data Contributorはコンテナーまたはそのデータの読み取り、書き込み、削除を実行できると説明されている。
つまり、Blob Data Contributorは便利である一方、削除権限を含む。運用担当者全員に広く付けると、保全対象データまで消せる構成になりやすい。
もちろん、業務上、削除権限が必要な場面はある。問題は、「どのデータを」「誰が」「どの条件で」「どの承認に基づいて」削除できるのかが整理されていないことである。
少なくとも、次を分けるべきである。
データ種別 | 推奨される考え方 |
一般業務ファイル | Soft Delete、Versioning、ログ、ライフサイクル管理 |
重要な業務証跡 | Versioning、不変ポリシー、Change Feed、Entra ID認証 |
監査・証拠保全対象 | Immutability、Legal Holdまたは時間ベース保持、厳格な権限分離 |
一時ファイル | 短期保持、ライフサイクル管理、削除権限の限定 |
アプリ生成ログ | ログ保管先の分離、不変化、削除操作の監査 |
取引先提出資料 | Versioning、保管台帳、復元手順、提出履歴 |
Microsoft Learnでは、Azure RBACに加えて、Azure ABACを使い、BLOBリソースのAzureロール割り当てに条件を追加できることも説明されている。
実務上は、RBAC、ABAC、PIM、承認ワークフロー、Break Glass、SAS管理、共有キー禁止、診断設定、不変ポリシーを組み合わせる必要がある。
削除できる人を減らす。削除できる範囲を狭める。削除できる時間を制限する。削除したら必ずログに残る。保全対象は削除できない。削除後も世代と履歴で説明できる。
この設計が必要である。
10. 「復旧」と「証明」の設計モデル
Soft Deleteだけの現場では、復旧設計と証明設計が混同されやすい。クラウド法務の観点では、次の三層で設計するべきである。
層 | 目的 | Azure機能 |
復旧可能性 | 消えても戻せる | Soft Delete、Container Soft Delete、Point-in-Time Restore、バックアップ |
世代説明 | いつの状態に戻したか説明できる | Blob Versioning、Snapshot、Version ID、Change Feed |
保全・不変性 | 消されても守れる、改ざんを防ぐ | Immutable Storage、時間ベース保持、Legal Hold、RBAC/ABAC、共有キー禁止 |
Soft Deleteは第一層である。Versioningは第二層である。Immutabilityは第三層である。
この三層を区別しないと、「戻せたのに説明できない」状態になる。
11. 障害報告書に必要な証跡
Soft Deleteで復旧した場合、障害報告書には少なくとも次を記載すべきである。
項目 | 記載内容 |
対象BLOB | ストレージアカウント、コンテナー、BLOB URI |
発生事象 | 削除、上書き、メタデータ変更、コンテナー削除等 |
発生時刻 | StorageBlobLogs、Change Feed、アプリログで確認 |
操作者 | Microsoft Entra IDの場合はRequesterObjectId、SAS/共有キーの場合は補助情報 |
認証方式 | OAuth、SAS、Account Key、Anonymous等 |
復元方法 | Soft Delete、Version昇格、Snapshot復元、バックアップ復元等 |
復元対象 | VersionId、Snapshot、削除時点、復旧対象範囲 |
改ざん防止 | Immutabilityの有無、保持ポリシー、Legal Holdの有無 |
権限妥当性 | 該当者・アプリに削除権限が必要だったか |
再発防止 | Versioning、不変化、RBAC見直し、共有キー禁止、監視強化 |
証跡保存先 | Log Analytics、チケット、監査フォルダ、報告書添付資料 |
「復旧しました」だけでは足りない。「何を、どの時点へ、誰の操作に対して、どの根拠で戻したか」を書く必要がある。
12. 実務KQL：削除・上書き・復旧を追う
削除操作の初動確認は、次のようなKQLで行う。
StorageBlobLogs| where TimeGenerated > ago(7d)| where OperationName in ("DeleteBlob", "DeleteContainer")| project TimeGenerated, AccountName, OperationName, AuthenticationType, RequesterObjectId, CallerIpAddress, UserAgentHeader, Uri, StatusCode, StatusText| order by TimeGenerated desc上書き・書き込み系操作は、Microsoft Learnの監視ベストプラクティスでも、PutBlob、PutBlock、PutBlockList、AppendBlock、SnapshotBlob、CopyBlob、SetBlobTierなどを使って書き込み操作を集計する例が示されている。
StorageBlobLogs| where TimeGenerated > ago(7d)| where OperationName in ( "PutBlob", "PutBlock", "PutBlockList", "AppendBlock", "SnapshotBlob", "CopyBlob", "SetBlobTier")| project TimeGenerated, AccountName, OperationName, AuthenticationType, RequesterObjectId, CallerIpAddress, UserAgentHeader, Uri, RequestBodySize, StatusCode, StatusText| order by TimeGenerated descSAS経由の操作を確認する場合は、次のように見る。
StorageBlobLogs| where TimeGenerated > ago(7d)| where AuthenticationType == "SAS"| project TimeGenerated, OperationName, AuthenticationType, AuthenticationHash, CallerIpAddress, UserAgentHeader, Uri, StatusCode, StatusText| order by TimeGenerated descただし、SASトークン自体はログに表示されず、SASトークン署名のSHA-256ハッシュがAuthenticationHashフィールドに表示されるとMicrosoft Learnは説明している。SASを誰に渡したかの台帳がなければ、「誰が使ったか」は後から特定しにくい。
このため、監査を考えるなら、KQLだけでなく、SAS発行台帳、ユーザー委任SAS、共有キー禁止、Entra ID認証への移行まで設計しなければならない。
13. NIST CSF 2.0の観点：これはRecoverだけではなくGovernである
Soft Deleteの議論は、一見するとRecover、つまり復旧の話に見える。しかし、本質はGovernである。
NIST CSF 2.0は、サイバーセキュリティリスクを管理するための高レベルな成果分類として、Govern、Identify、Protect、Detect、Respond、Recoverの機能を整理している。NISTは、CSF 2.0が組織のサイバーセキュリティ活動を理解、評価、優先順位付け、コミュニケーションするための分類を提供するものであり、具体的な達成方法を処方するものではないと説明している。
本件をNIST CSF 2.0に沿って見ると、次のようになる。
CSF機能 | 本件で問われること |
Govern | 保全対象、削除権限、復旧責任、証跡提出責任を誰が決めたか |
Identify | どのBLOBが重要データ・証跡データ・保全対象か識別しているか |
Protect | Versioning、Immutability、RBAC、共有キー禁止で守っているか |
Detect | 削除・上書き・不審アクセスをStorageBlobLogsやChange Feedで検知できるか |
Respond | 削除発生時、誰が何を確認し、どのKQLを実行するか |
Recover | どのVersionId、Snapshot、Soft Delete対象から復旧するか |
つまり、「Soft Deleteを入れている」はRecoverの一部にすぎない。「誰が何を消せるのか」「消されたらどう証明するのか」「保全対象は消せないのか」を決めるGovernがなければ、クラウド法務としては不十分である。
14. クラウド法務として整備すべき文書
山崎行政書士事務所のクラウド法務の価値は、Azureの設定画面を読むことだけではない。Azureの実装を、契約、規程、責任分界、監査証跡、障害報告、取引先説明に翻訳することにある。山崎行政書士事務所のクラウド法務×Azure技術支援でも、クラウド法務の本質は、Azureのアーキテクチャ、ID、ログ、バックアップ、DR、監査、インシデント対応を、契約・規程・説明資料・運用手順として一貫した言葉に翻訳することだと整理されている。
本件で整備すべき文書は、少なくとも次である。
14.1 データ保護設計書
ストレージアカウントごとに、Soft Delete、Container Soft Delete、Versioning、Immutability、Change Feed、診断設定、ライフサイクル管理、バックアップ有無を一覧化する。
14.2 データ分類・保全対象台帳
一般ファイル、業務証跡、監査証跡、契約関連ファイル、個人データ、ログ、外部提出資料を分類し、どの分類に不変ポリシーを適用するかを定義する。
14.3 権限マトリクス
誰が読み取り、書き込み、削除、復元、バージョン削除、ポリシー変更、診断設定変更をできるのかを整理する。Blob Data Contributorを広く付与するのではなく、削除権限をどこまで許容するかを明記する。
14.4 ログ・証跡設計書
Activity Log、StorageBlobLogs、Change Feed、アプリログ、SAS発行台帳、PIM履歴、承認チケットをどこに保存し、誰が、いつ、どのKQLで抽出するかを定義する。
14.5 復旧手順書
Soft Deleteによる復旧、Version昇格、Snapshotからの復元、バックアップからの復元を分けて手順化する。復旧時にはVersionId、実行者、実行時刻、対象URI、復旧理由を残す。
14.6 不変化運用手順
時間ベース保持、Legal Hold、ロック操作、保持期間変更、例外処理、解除権限、承認者を定義する。特にロック後に削除や短縮ができない制約は、業務側にも説明する。
14.7 委託先責任分界表
SIer、MSP、SOC、アプリベンダー、自社情シスの間で、削除権限、復旧権限、ログ抽出、証跡提出、SAS発行、共有キー管理、不変ポリシー変更の責任を分ける。
14.8 取引先・監査向け説明資料
「Soft Deleteを有効化しています」ではなく、次のように説明する。
「対象ストレージでは、誤削除対策としてBLOB Soft DeleteおよびContainer Soft Deleteを有効化し、上書き・削除時の世代説明のためにBlob Versioningを使用しています。監査証跡についてはStorageBlobLogsをLog Analyticsへ送信し、データプレーン操作の時刻、操作名、認証方式、RequesterObjectId等を抽出できるようにしています。保全対象データには不変ポリシーを適用し、通常運用権限による削除・変更を抑止しています。」
この粒度で初めて、監査に耐える。
15. 実務チェックリスト
Soft Deleteだけで安心していないか、次を確認すべきである。
観点 | 確認内容 |
Soft Delete | BLOBの保持期間は業務リスクに合っているか |
Container Soft Delete | コンテナー削除時に復元できるか |
Versioning | 上書き・削除前の世代をVersionIdで説明できるか |
Immutability | 保全対象データを変更・削除できない状態にしているか |
Legal Hold | 保全解除まで保持すべきデータに適用方針があるか |
Activity Log | コントロールプレーン操作を追えるか |
StorageBlobLogs | データプレーン削除・上書き操作を追えるか |
Change Feed | 変更の順序を追えるか |
Entra ID | 個人またはサービスプリンシパル単位で追跡できるか |
Shared Key | 共有キーを禁止できるか、少なくとも利用範囲を限定しているか |
SAS | 誰に、何の目的で、いつまで発行したか台帳化しているか |
RBAC | Blob Data Contributorを広く付けすぎていないか |
ABAC | パス・属性・環境条件で削除範囲を制御できるか |
KQL | 削除・上書き・復旧の抽出クエリを保存しているか |
報告書 | 復元対象VersionId、操作ログ、復旧理由を書けるか |
契約 | 委託先の削除権限・ログ提出義務・復旧協力が明記されているか |
このチェックをしないまま「Soft Deleteがあるから安心」と言うのは危険である。
16. 考察：データは戻せても、信頼は戻せない
Soft Deleteの事故で最も怖いのは、データを戻せなかったことではない。データを戻した後に、信頼を戻せないことである。
ユーザーは聞く。「本当に前と同じファイルですか」
監査は聞く。「改ざんされていないことを何で説明しますか」
経営は聞く。「なぜ通常権限で消せたのですか」
取引先は聞く。「削除・復旧の証跡を提出できますか」
この問いに答えるためには、Soft Deleteだけでは足りない。
Versioningで世代を残す。Immutabilityで保全する。StorageBlobLogsで操作を追う。Change Feedで変更の順序を見る。Entra IDで実行主体を識別する。共有キーとSASを管理する。権限を最小化する。復旧手順と報告書を整備する。契約・規程・責任分界に落とす。
ここまで揃って初めて、「復旧できる」から「説明できる」に変わる。
17. 結論：消せる設計ではなく、消されても守れる設計へ
本稿の結論は、次の一文に尽きる。
Soft Deleteは、データ復旧の機能であって、完全性証明・改ざん防止・権限統制・監査証跡を単独で満たす設計ではない。
Soft Deleteで戻せることは重要である。しかし、戻せるだけでは足りない。
どの時点に戻したのか。どのVersionIdを復元したのか。誰が削除したのか。どの認証方式だったのか。なぜその権限を持っていたのか。保全対象データは不変化されていたのか。削除・上書き・復旧のログは残っているのか。監査時に同じ条件で再抽出できるのか。委託先と責任分界は一致しているのか。
これを説明できなければ、復旧はできても、証明はできない。
山崎行政書士事務所のクラウド法務・Azure技術支援は、この「Azureでは復旧できる」と「法務・監査・経営に説明できる」の隙間を埋める支援である。Soft Delete、Versioning、Immutability、Change Feed、StorageBlobLogs、Entra ID、RBAC、SAS管理、契約、規程、障害報告書を一つの設計として整理し、情シスと経営層が同じ言葉で説明できる状態を作る。
消せる設計ではなく、消されても守れる設計へ。復旧できる設計ではなく、証明できる設計へ。Soft Deleteだけで安心せず、世代・不変性・操作ログまで設計せよ。
コメント