Blob Immutable Storage／WORMで監査証跡を守る
- 山崎行政書士事務所
- 7月8日
- 読了時間: 7分
ログ・証跡の改ざん・削除リスクに備える証跡保存ポリシー設計
確認日：2026年7月8日対象読者：情シス担当者、クラウド運用担当者、セキュリティ担当者、監査対応担当者、経営層対象領域：Azure Blob Storage、Immutable Storage、WORM、監査ログ、証跡管理、コンプライアンス
結論
クラウド環境における監査証跡は、「保存している」だけでは十分ではありません。
重要なのは、管理者権限を持つ利用者であっても、一定期間は変更・削除できない状態で証跡を保護することです。
Azure Blob StorageのImmutable Storage（不変ストレージ）を利用することで、監査ログ、操作履歴、バックアップ、セキュリティイベントなどの重要データを、WORM（Write Once, Read Many：一度書き込んだデータを変更不可にする仕組み）として保存できます。
これにより、
「誰がログを消したのか」
「事故発生前後の証跡は残っているのか」
「管理者でも削除できない仕組みになっているか」
「監査期間中、証跡の完全性を保証できるか」
という問いに対して、技術的根拠を持って説明できます。
理由
クラウド環境では、従来型のオンプレミス環境以上に「証跡管理」が重要になります。
理由は、クラウドでは管理操作そのものがAPI経由で実行され、管理者権限を持つユーザーが広範囲な操作を実行できるためです。
例えば、以下のようなケースがあります。
事象 | 問題点 |
Azure Activity Logを保存していたが保存先Storageを削除された | 事故調査時に証跡が存在しない |
Log Analyticsの保存期間が短い | 過去インシデントを調査できない |
管理者がログファイルを上書きした | 証跡の信頼性が失われる |
バックアップデータを削除された | 復旧不能になる |
監査提出直前にログが不足する | コンプライアンス違反リスク |
つまり、証跡管理で重要なのは、
「ログを取得すること」ではなく、「取得したログを改ざんできない状態で保管すること」
です。
数字で見る：証跡管理で整理すべき8つの項目
No | 管理項目 | 内容 |
1 | 対象ログ | Azure Activity Log、Entra IDログ、Defenderログ等 |
2 | 保存先 | Storage Account、Log Analytics等 |
3 | 保存期間 | 1年、3年、7年など |
4 | 不変化方式 | Time-based retention、Legal Hold |
5 | アクセス制御 | RBAC、Privileged Identity Management |
6 | 削除防止 | Immutable Policy、Soft Delete |
7 | 監査証跡 | 誰が設定変更したか |
8 | 例外管理 | 期限付き解除、承認記録 |
1. WORM（Write Once, Read Many）とは
一度書いたデータを変更できない仕組み
WORMとは、
Write Once（1回だけ書込み）Read Many（何度でも読込み可能）
という考え方です。
通常のStorageでは、アクセス権限があれば削除・変更が可能です。
しかし、Immutable Storageでは一定期間、データ変更や削除を防止できます。
図1：通常StorageとImmutable Storageの違い
通常Storage
管理者
│
├── 作成
├── 更新
└── 削除
↓
データ消失可能
────────────────────
Immutable Storage
管理者
│
├── 作成
│
▼
┌────────────────┐
│ Immutable Blob │
│ │
│ 変更不可 │
│ 削除不可 │
│ 保持期間保証 │
└────────────────┘2. Azure Blob Immutable Storageの仕組み
Microsoft公式では、Azure Blob Storageの不変ストレージは、データを変更または削除できない状態で保存する機能として説明されています。
主な用途として、
金融機関の監査記録
医療記録
セキュリティログ
法規制対応
バックアップ保護
などが挙げられています。
出典：Microsoft Learn「Azure Blob Storage の不変ストレージでビジネス クリティカルな BLOB データを保存する」https://learn.microsoft.com/ja-jp/azure/storage/blobs/immutable-storage-overview
3. Immutable Storageの2種類
Azure Blob Immutable Storageには、大きく2種類あります。
表1：保持方式
方式 | 内容 | 利用例 |
Time-based retention | 指定期間、変更・削除不可 | 監査ログ、法定保存 |
Legal Hold | 保持期間を指定せず解除まで保持 | 訴訟対応、調査保全 |
Time-based retention
例：
保存開始日
2026/07/08
保持期間
7年間
削除可能予定
2033/07/08以降期間中は、
Blob削除不可
Blob変更不可
保持期間短縮不可
となります。
Legal Hold
調査期間中など、一時的に削除防止する用途です。
例：
セキュリティ事故発生
↓
証跡保全開始
↓
Legal Hold設定
↓
調査終了
↓
解除4. 監査証跡を守るAzure構成例
図2：監査ログ保管アーキテクチャ
Azure環境
┌──────────────────────┐
│ Entra ID │
│ サインインログ │
└─────────┬────────────┘
│
▼
┌──────────────────────┐
│ Azure Activity Log │
│ 管理操作ログ │
└─────────┬────────────┘
│
▼
┌──────────────────────┐
│ Diagnostic Settings │
│ ログ転送 │
└─────────┬────────────┘
│
▼
┌────────────────────────────┐
│ Storage Account │
│ │
│ Blob Container │
│ │
│ Immutable Policy │
│ WORM保持 │
└────────────────────────────┘5. 何をImmutable化すべきか
すべてのログをImmutable化するとコスト・運用負荷が増えます。
重要度によって分類する必要があります。
表2：Immutable対象候補
データ | 推奨度 | 理由 |
Azure Activity Log | ◎ | 管理操作証跡 |
Entra ID Audit Log | ◎ | 認証・権限変更証跡 |
Microsoft Defenderログ | ◎ | インシデント調査 |
Sentinelログ | ◎ | SOC調査 |
Firewallログ | ○ | 通信証跡 |
WAFログ | ○ | 攻撃分析 |
アプリケーションログ | △ | 重要業務のみ |
開発ログ | △ | 要件次第 |
6. 証跡保存ポリシーを作る
Immutable Storageを導入しても、保存ルールがなければ運用できません。
必要なのは「証跡保存ポリシー」です。
表3：証跡保存ポリシー例
項目 | 内容 |
目的 | 監査・事故調査・内部統制対応 |
対象 | Azure管理ログ、認証ログ、セキュリティログ |
保存場所 | 専用Storage Account |
保存形式 | JSON、CSV等 |
保持期間 | 7年間 |
不変化 | Time-based retention |
アクセス | RBAC＋PIM |
削除権限 | 原則禁止 |
例外 | CISO承認 |
レビュー | 年1回 |
7. RBACとImmutable Storageを組み合わせる
重要なのは、不変化だけではありません。
アクセス制御も必要です。
図3：権限分離モデル
Owner
│
┌─────────┴─────────┐
▼ ▼
運用管理者 監査担当
読込・運用 読込専用
│
▼
Immutable Storage
削除不可
改ざん不可推奨ロール分離
役割 | 権限 |
クラウド管理者 | Storage管理 |
セキュリティ担当 | ログ参照 |
監査担当 | Read Only |
開発者 | 原則アクセス不可 |
8. Azure Policyで標準化する
個別設定では、必ず漏れが発生します。
Azure Policyを利用し、
診断設定必須
Storage暗号化必須
Public Access禁止
HTTPS必須
Immutable設定確認
などを標準化します。
図4：ガバナンスモデル
Azure Policy
↓
標準ルール
↓
各Subscription
↓
Storage Account
↓
Immutable Storage9. インシデント対応で価値が出る
例えば、不正アクセスが疑われる場合。
Immutableなし
攻撃者
↓
管理者権限取得
↓
ログ削除
↓
調査不能Immutableあり
攻撃者
↓
管理者権限取得
↓
ログ削除試行
↓
Immutableにより失敗
↓
調査可能10. 監査で問われるポイント
表4：監査質問と回答準備
質問 | 準備資料 |
ログは保存していますか | ログ保存一覧 |
改ざん防止していますか | Immutable設定証跡 |
管理者でも削除できますか | RBAC設計 |
保存期間根拠はありますか | 保存ポリシー |
例外処理はありますか | 例外管理台帳 |
誰が設定変更しましたか | Activity Log |
定期確認していますか | レビュー記録 |
11. 例外管理が重要
Immutable Storageでは、基本的に削除できません。
そのため、例外ルールが必要です。
表5：例外管理例
項目 | 内容 |
例外番号 | IMM-EX-001 |
対象 | Security Log |
理由 | 法令変更対応 |
期間 | 30日 |
承認者 | 情報セキュリティ責任者 |
代替策 | 別Storageへ保存 |
見直し日 | 2026/8/1 |
12. バックアップとImmutableは役割が違う
よくある誤解があります。
表6：違い
項目 | バックアップ | Immutable Storage |
目的 | 復旧 | 改ざん防止 |
主対象 | システム・データ | 証跡 |
削除防止 | 製品次第 | 明確に設定可能 |
監査向き | △ | ◎ |
両者は競合するものではありません。
13. 情シスが作るべき証跡管理体系
図5：証跡ガバナンス全体像
経営層
│
▼
セキュリティポリシー
│
▼
証跡保存ポリシー
│
┌─────────────┐
▼ ▼
技術設定 運用ルール
Immutable レビュー
RBAC 例外管理
Policy 承認
│
▼
監査対応14. 山崎行政書士事務所としての支援領域
Azureの証跡管理は、単にStorage設定を行うだけでは完成しません。
重要なのは、
何を保存するか
何年間保存するか
誰が閲覧できるか
誰が変更できるか
例外をどう管理するか
監査時にどう説明するか
という企業ガバナンスです。
山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。
支援内容
領域 | 内容 |
Azure設計 | Blob Storage Immutable設計 |
セキュリティ | RBAC、PIM、Policy設計 |
ログ管理 | Activity Log、Entraログ、Sentinel整理 |
監査対応 | 証跡一覧、説明資料作成 |
規程整備 | ログ保存規程、証跡管理規程 |
運用設計 | レビュー、例外管理、承認フロー |
経営説明 | クラウドリスク説明資料 |
行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。
まとめ
監査証跡で最も重要なのは、
「ログを取得していること」
ではありません。
本当に重要なのは、
取得したログを、必要な期間、改ざんされない状態で保持し、誰が見ても説明できること
です。
Azure Blob Immutable Storageは、単なるストレージ機能ではありません。
これは、
内部統制
セキュリティ監査
インシデント対応
コンプライアンス対応
経営説明
を支えるクラウドガバナンス基盤です。
証跡管理を「ログ保存」から「説明できる統制」へ。
Azure環境のImmutable Storage設計、証跡保存ポリシー、監査対応資料、クラウドガバナンス整備は、山崎行政書士事務所へご相談ください。
出典
確認日：2026年7月8日
Microsoft Learn
Azure Blob Storage の不変ストレージ
https://learn.microsoft.com/ja-jp/azure/storage/blobs/immutable-storage-overview
Microsoft Learn
Azure Monitor Activity Log
https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/activity-log
Microsoft Learn
Azure Storageのデータ保護
https://learn.microsoft.com/ja-jp/azure/storage/blobs/data-protection-overview
NIST SP 800-92
Guide to Computer Security Log Management
NIST SP 800-53 Rev.5
Security and Privacy Controls for Information Systems and Organizations
コメント