【クラウド法務】ログ削除・権限剥奪・保全操作は誰がやるのか問題― SOCがいても、MSPがいても、Microsoftがクラウドでも「決めていない会社」は事故・監査・委託終了で詰まる ―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

はじめに

────────────────────────────

クラウド運用（Azure / M365 など）で、事故・監査・取引先照会が来た瞬間、現場が固まる質問があります。

「ログ削除（保持期間変更やPurge含む）って、誰がやるの？」

「侵害疑いのアカウント権限剥奪、誰が“最終判断”して誰が実行するの？」

「ログ保全（削除停止・隔離・抽出者記録）、誰がやるの？」

SOCを使っている。運用はMSPに委託している。Microsoftの責任分界モデルも理解している。

それでも、この3点が曖昧だと一気に詰みます。

・封じ込めが遅れて被害が広がる

・ログの保全が後手になり、証跡に穴が空く

・「誰が決めたのか」が説明できず、監査・親会社・取引先対応が割れる

・委託先と「契約外」「別料金」「誰の権限で？」でもめる

結論から言うと、これは“技術不足”ではありません。

「破壊的操作（削除）」「権限剥奪（封じ込め）」「保全（証跡）」を、タスクとして責任分界していないことが原因です。

本記事では、なぜこの問題が起きるのか、どこが地雷なのか、どう整理すれば「説明が割れない運用」になるのかを、実務で使える形でまとめます。

────────────────────────────

技術構成の“事実整理”：この3つは似ているようで性質がまったく違う

────────────────────────────

最初に、混ぜると確実に失敗するので、3つを分けて整理します。

────────────────────────────

（A）ログ削除：後処理・コスト・個情/機密の観点で“減らす”操作

────────────────────────────

例（クラウドで起きがち）

・保持期間を短くする（Retentionを縮める）

・ログ保管先をローテして古いログを消す

・SIEM側のデータ削除

・ストレージ上のログ削除

・「Purge」や「完全削除」に相当する操作（サービスによって名称は違う）

特徴

・基本は“急がない”が、やると戻せないことがある

・「消しすぎる」と監査・事故対応で詰む

・「消さない」とコストやデータ管理（必要最小化）の論点が出る

→ 運用としての「ルール化」と「承認」が必要な領域

────────────────────────────

（B）権限剥奪：封じ込めのための“止める”操作（最初の数分で勝負が決まる）

────────────────────────────

例

・ユーザー無効化、パスワードリセット

・セッションの強制失効

・管理者ロールの剥奪（Entra ID / RBAC）

・PIMで付与された特権の強制解除

・条件付きアクセスで“通さない”状態に切り替える

・委託先アカウントの停止（退職・異動・委託終了含む）

特徴

・事故時は“即断即決”が必要（遅れると被害が広がる）

・やり過ぎると業務停止・復旧遅延になる

・「誰が止められるか（権限）」と「誰が止めてよいか（承認）」がズレると地獄

→ 技術（権限）と統制（承認）の両方が必要な領域

────────────────────────────

（C）保全操作：証拠（証跡）として“残す・固定する”操作（後からの説明を左右する）

────────────────────────────

例

・削除停止（保持期間延長、保全対象の固定）

・ログの隔離・スナップショット

・抽出者記録（いつ誰がどの手順で取得したか）

・アクセス制限（閲覧者を絞る）

・契約上の“リーガルホールド相当”の運用（紛争・監査・事故調査に耐える形）

特徴

・事故時の「調査」より先に走らせるべきことがある

・保全が遅れると、原因究明だけでなく対外説明の根拠が失われる

・委託先/SOCが絡むと「保全できるのは誰？」が曖昧になりがち

→ 提出能力（いつまでに出せるか）とセットで設計が必要

ここまでは技術の話。ここからが法務・説明責任の話です。

この3つを“同じノリで”扱うと、事故時に必ず噛み合いません。

────────────────────────────

2. なぜ「誰がやるのか問題」が起きるのか（よくある“法務・運用の地雷”3選）

────────────────────────────

現場で頻出する地雷を3つに絞ります。どれか1つでも当てはまると、事故・監査で説明が割れます。

────────────────────────────

地雷①：「実行できる人」と「決める人」が分離していない

────────────────────────────

クラウドは権限が強いほど便利です。だからこそ危険です。

よくある状態

・MSPが運用しているのでMSPが実行できる

・SOCが見ているのでSOCが“止める”と思っている

・情シスは権限を持っていない／持っているが夜間にいない

・上司は承認したいが、現場に手順がない

結果

・止めたいのに止められない

・止められる人が勝手に止めてしまい、後で承認が取れず揉める

・「誰が決めたのか」が消えて、監査・取引先で詰む

本当の問題は、権限の強弱ではなく、

意思決定（承認）と実行（操作）が制度として分離されていないことです。

────────────────────────────

地雷②：委託契約（特にSOW）に「やる義務」が落ちていない

────────────────────────────

契約本文に「協力する」「必要な情報を提供する」とあっても、事故の現場では効きません。

事故の現場で効くのは、「何分以内」「何営業日以内」「どの形式」「何をどこまで」が決まっていることです。

決まっていないと起きること

・ログ提出が遅れる（提出は別料金／契約外／時間がかかる）

・保全協力が曖昧（削除停止できない、誰がやるか不明）

・権限剥奪の実行者が不明（MSPは触れるが“止める判断”はできない）

・委託終了時にアカウントが残る／剥奪証明がない

SOC/MSP/再委託（海外SOC含む）が絡むほど、SOWが薄いと燃えます。

────────────────────────────

地雷③：「削除」と「保全」が同じルールで動いてしまう

────────────────────────────

普段の運用では

・古いログは削除（コスト・データ最小化）

が合理的です。

でも事故時は逆です。

・消さない（保全）

・固定する（証跡の真正性）

・提出できる形にする

が必要です。

ここが切り替わらないと、こうなります。

・事故発生後にローテでログが落ちて穴が空く

・保全対象が曖昧で、後から「なぜ残っていないのか」になる

・削除の方針だけが強く、保全の方針がない

→ “ログはあるはず”のまま説明不能に陥る

────────────────────────────

3. 解決のフレーム：この問題は「権限」ではなく“タスク設計”で解く

────────────────────────────

ここからが実務の解決策です。

おすすめは、次の「4点セット」で設計することです。

────────────────────────────

（1）タスクを分ける：封じ込め／保全／削除（後処理）

────────────────────────────

まず「何が起きたとき、どのタスクが発動するか」を分けます。

・封じ込め（権限剥奪・遮断）：数分〜数十分で動く

・保全（削除停止・隔離・抽出者記録）：封じ込めと同時に動く

・削除（後処理・通常運用）：事故が落ち着いた後、承認のもとで動く

この切り分けがないと、普段の削除運用が事故時にも走って証跡が欠けます。

────────────────────────────

（2）RACIで主語を固定する：レイヤーではなくタスクで

────────────────────────────

レイヤー（OS層、NW層）で責任分界しても、事故時の質問に答えられません。

事故時に問われるのは「誰が何をするか」だからです。

最低限、以下をタスクとしてRACI（R=実行、A=最終責任、C=相談、I=共有）で固定します。

【権限剥奪（封じ込め）】

・対象アカウントの無効化／セッション失効

・管理者ロール剥奪

・委託先アカウント停止（緊急・通常）

・条件付きアクセス緊急強化（例外含む）

・“誰が承認し、誰が実行するか”

【保全操作】

・保全トリガー（何が起きたら保全するか）

・削除停止（保持延長、固定、隔離）

・抽出者記録（いつ誰が何を抽出したか）

・保全対象の確定（期間、ログ種別、保存先）

・“誰が責任を持つか（A）”を必ず置く

【ログ削除（通常運用・後処理）】

・保持期間変更（短縮・延長）

・削除・Purge系操作

・削除の承認フロー（2名承認など）

・削除証明／削除ログの残し方

・事故時は削除を止める切り替え条件

ポイント

SOC/MSPがR（実行）でも、A（最終責任）と対外説明の主語は自社に残るタスクが多いです。

ここを曖昧にすると、事故時に必ず主語が割れます。

────────────────────────────

（3）「できる」と「してよい」を分ける：権限設計＋承認設計

────────────────────────────

同じ“操作できる人”に全部寄せると、統制が崩れます。

逆に、承認者だけで決めようとしても、夜間・休日に止まります。

おすすめの考え方（実務で効きます）

・実行権限（できる人）：最小限の人数、期限付き、個人アカウント

・承認権限（してよい人）：事故時の即時承認ルール（閾値）を用意

・破壊的操作（Purge、保持短縮、バックアップ削除等）：原則2名承認＋記録

・緊急封じ込め（権限剥奪）：事後追認の期限を決める（例：24時間以内）

「止められないから常設で強権限」になりがちですが、

その前に“承認と期限”で回す設計ができると、事故にも監査にも強くなります。

────────────────────────────

（4）証跡をセットで決める：「誰がやったか」を後から証明できる形にする

────────────────────────────

この問題のゴールは「うまく止めた」ではなく、

「なぜ止めたか／誰が決めたか／何をしたか」を説明できることです。

最低限残すべき証跡

・意思決定（誰が、何を根拠に、何時に決めたか）

・実施操作（誰が、何時に、何を実行したか）

・保全（何を、どこに、どの期間、どんな手順で固定したか）

・抽出者記録（ログ提出の真正性の材料）

・委託先が関与した場合の作業証跡（チケット、承認、実施者）

これがないと、事故後に「現場は頑張ったが、説明は崩壊」という状態になります。

────────────────────────────

4. 契約（SOW）で必ず固めたいポイント：委託先が絡むと“誰がやるか”は契約で決まる

────────────────────────────

権限剥奪・保全・ログ削除は、委託が入るほど“契約の空白”で詰まります。

最低限、SOW（別紙：作業範囲と品質）に次を落とすと安定します。

────────────────────────────

（A）権限剥奪（封じ込め）に関する義務

────────────────────────────

・緊急時に「停止・剥奪」を実行できる範囲（どこまで触るか）

・実行の条件（誰の指示で動くか、Severity基準）

・実行までの時間（例：通知から何分以内に着手）

・実行後の報告（何を、どの形式で、いつまでに）

────────────────────────────

（B）保全（削除停止・隔離・抽出者記録）に関する義務

────────────────────────────

・保全の実施主体（誰が操作するか）

・保全対象の確定プロセス（誰が範囲を決めるか）

・削除停止の義務（保全要請があったら止める）

・抽出者記録と証跡提供（いつ誰が取得したか）

・保全中のアクセス制限（閲覧者を絞る運用）

────────────────────────────

（C）ログ提出・削除（後処理）に関する義務

────────────────────────────

・提出期限（何営業日以内）・提出形式・対象範囲

・削除運用のルール（保持期間、削除の承認）

・契約終了時の出口（アクセス剥奪証明、ログ引渡し、削除証明、引継ぎ）

・再委託（海外SOC等）がある場合の範囲特定と監督責任

重要なのは「協力する」ではなく、期限付きの義務として書くことです。

ここが薄いと、事故の現場で材料が揃わず、説明責任が成立しません。

────────────────────────────

5. ケーススタディ（匿名化）：ログもSOCもあるのに“剥奪と保全”で止まった例

────────────────────────────

実務で起きがちな構図を、匿名化して紹介します。

背景

・Azure＋M365運用

・監視はSOC、運用変更はMSPに委託

・ログはSIEMに集約しており「見える」状態

・Microsoftの責任分界モデルも社内資料に掲載済み

事象

・深夜に不審なサインインと管理操作のアラート

・SOCから通知は来たが、社内で「権限剥奪を誰が決めるか」が決まらず停止が遅れる

・MSPは操作できるが「承認がないとできない」

・一方で保全（削除停止）を誰がやるか決まっておらず、ログのローテーション運用が継続

・翌日、取引先照会で「当該期間の証跡提出」と「意思決定の記録」を求められ、説明が割れる

どこが詰まりポイントだったか

・封じ込めの承認者と実行者が未固定

・保全トリガーと保全責任者が未固定

・SOWに“保全協力／提出期限／権限剥奪の動き方”が薄い

・「ログはある」前提で、提出能力（期限・形式・抽出者記録）が未整備

立て直しでやったこと（方向性）

・タスク別RACIを作成（権限剥奪、保全、提出、対外説明まで）

・保全プロトコル（削除停止・抽出者記録・アクセス制限）を作成

・SOWを見直し、一次通知・保全協力・提出期限・特権アクセス統制を義務化

・破壊的操作（削除・Purge等）に二名承認と記録を導入

結果

・技術構成を変える前に、まず「誰がやるか」が固定され、事故時の動きと説明が安定した

という流れです。

────────────────────────────

6. すぐ使えるチェックリスト：この問題が起きる会社はここが抜けている

────────────────────────────

以下がYESで揃わないと、事故時に高確率で詰まります。

【権限剥奪（封じ込め）】

□ 不正アクセス疑いのとき、誰が最終判断してアカウント停止できるか決まっている

□ 夜間・休日の即時対応ルール（事後追認含む）がある

□ 委託先アカウントを緊急停止できる（自社でできる／委託先に義務がある）

□ 剥奪した操作の記録（誰が・いつ・なぜ）が残る

【保全操作（証跡）】

□ 何が起きたら保全するか（保全トリガー）が決まっている

□ 削除停止・保持延長・隔離などの保全手順がある

□ 抽出者記録（いつ誰が何を取得したか）を残せる

□ 保全中の閲覧者制限（アクセス制御）ができる

【ログ削除（後処理）】

□ 通常時の削除ルール（保持期間・削除方法・削除証明）が決まっている

□ 事故時に削除を止める切り替え条件がある

□ 破壊的操作（Purge、保持短縮、バックアップ削除等）に二名承認がある

□ 削除や保持変更の操作ログが残る

【委託（SOC/MSP/海外SOC）】

□ SOWに、一次通知・権限剥奪支援・保全協力・ログ提出期限が義務として入っている

□ 再委託（国外）範囲と監督責任が説明できる

□ 契約終了時の出口（アクセス剥奪証明、ログ引渡し、削除証明）が決まっている

────────────────────────────

7. まとめ：「誰がやるか」は、最初に決めないと“必ず事故で決める羽目になる”

────────────────────────────

ログ削除・権限剥奪・保全操作は、クラウド運用の“急所”です。

ここが曖昧だと、SOCがいても、MSPがいても、ログがあっても、説明責任は軽くなりません。

解き方はシンプルです。

・タスクを分ける（封じ込め／保全／削除）

・タスク別RACIで主語を固定する

・「できる」と「してよい」を分ける（権限＋承認）

・証跡をセットで残す（抽出者記録、意思決定記録）

・委託があるならSOWに期限付き義務として落とす

これが揃うと、クラウドは「動いている」だけでなく「説明できる」運用になります。

────────────────────────────

8. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure / M365 等のクラウド運用において、

技術構成と契約・規程・監査対応をセットで整理し、事故時に「誰がやるのか」で止まらない形に整えるクラウド法務支援を行っています。

・権限剥奪／保全／ログ提出を、タスク別RACIで1枚にしたい

・SOC/MSP/再委託（海外SOC含む）を含めた責任分界を事故対応まで落としたい

・SOWに一次通知・保全協力・ログ提出期限・特権アクセス統制を入れたい

・削除運用（保持期間・Purge系）を“監査で説明できる承認フロー”にしたい

といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。

お問い合わせの際に「ログ削除・権限剥奪・保全操作の記事を見た」と書いていただけるとスムーズです。