自動是正の対象は「A〜D」に分類せよ
- 山崎行政書士事務所
- 4月4日
- 読了時間: 6分
〜タグ補完は自動OK／診断設定は承認必須／ネットワーク変更は原則禁止…を“運用ルール”として固定する〜
山崎行政書士事務所（クラウド法務）です。Azure運用の自動化は、情シスの生産性を爆上げします。ですが同時に、設計を誤ると“全社規模の設定変更”が一瞬で走るのがAzure自動是正の怖さです。
前提として、前回の「安全装置」（Dry-run、影響上限、承認フロー、ロールバック）を組み込みます。そのうえで今回のテーマは、“何を自動是正の対象にしてよいか”を分類し、社内ルールとして固定することです。
なぜ「分類」が必要か
自動是正は、便利さが先行すると次が起きます。
“軽いメタデータ修正”のつもりが、本番の可用性やネットワーク境界に触れてしまう
“とりあえず回す”で、承認や証跡がなく監査で説明できない
例外が増殖して、いつの間にか統制不能になる
これを止める最短ルートが「分類」です。分類＝自動化の許可範囲を決めること。つまり、情シスの“運用規程”そのものになります。
前提となる「安全装置」4点（超要約）
分類の前に、必ずこの4つを仕込むのが前提です。
Dry-run（差分だけ出す）
ARM/BicepのWhat-Ifは、デプロイ前に変更をプレビューでき、既存リソースを変更しません。
影響上限（爆風半径）
Azure Policyの修復タスクは resourceCount（対象件数）、parallelDeployments（並列数）、failureThreshold（失敗率閾値）などを持ち、“速度”と“範囲”を制限できます。
新しいポリシーは、リソースグループ等のサブセットから開始し、resourceSelectors でフィルタしながら段階展開することが推奨されています。
さらにMicrosoftは、Azure Policy割り当てにSDP（安全なデプロイプラクティス）を適用して段階ロールアウトすることを推奨しています。
承認フロー（Human-in-the-loop）
Azure DevOpsの「承認とチェック」を使うと、ステージの実行タイミングを手動で制御できます（運用環境のデプロイ制御に使う想定）。
ロールバック（止血→復元）
Runbookは中断された場合、先頭から再開されるため、冪等設計や復元手順が重要です。
結論：自動是正の対象は「A〜D」で分類する
情シス運用ルールとしては、4分類に固定するとブレません。
Class A：自動OK（低リスク・追加型・可逆）
例：タグ補完、軽微なメタデータ整形
条件：誤っても致命傷にならず、戻せる／対象が限定できる
実装の強み：Azure Policyのmodifyは、タグやプロパティの追加・更新・削除に使え、既存非準拠も修復タスクで是正できます（修復にはマネージドIDが必要）。
タグガバナンスは、Policyで整えるチュートリアルも用意されています。
Aでも必須の安全装置
Dry-run相当（対象一覧と“予定変更”をログに出す）
最小権限（自動化IDのRBACは広げない）
Azure Automation側も、最小特権を徹底し、広範なスコープ付与やワイルドカード権限を避ける、と明記されています。
Class B：自動（影響上限つき）
例：アラート検知→軽微な是正（Sev2/3相当）、ロック付与など「誤っても復旧できる」系
条件：影響上限（件数・並列・失敗閾値）で爆風を縛れること
Bの安全装置（これが本体）
修復タスクの resourceCount と parallelDeployments を小さく
failureThreshold で失敗が出たら止める
キルスイッチ（停止手順）を運用手順に書く
Class C：承認必須（中〜高リスク）
例：診断設定（ログ転送）の全体適用、TLS/暗号等の互換性に影響する設定、コストに直結する設定
条件：人の承認と証跡が必要（＝Changeとして扱う）
なぜ「診断設定」は承認必須になりやすいか
診断設定は“追加型”に見えて、実際は
ログの量＝コスト
どこに転送するか＝情報管理
保持・参照権限＝監査設計
に直結します。
Microsoft Learnでも、Azure Policyの組み込みポリシーで、サポートされるリソースのログをLog Analytics／Event Hub／Storageへ転送し「大規模にログ記録を有効化する」方法が整理されています。 つまり“簡単に全体へ展開できる”からこそ、承認と設計が必要です。
Cの実装パターン（王道）
IaC（Bicep/ARM）で実装し、What-Ifで差分確認してから反映
Azure DevOpsの承認ゲートを通して本番反映
Policyの場合は、まず DoNotEnforce で評価だけ行う（強制しない）
Class D：原則禁止（自動化しない）
例：ネットワーク境界・経路（NSG/UDR/Firewall/Public公開）、RBAC特権付与、削除（破壊的）
原則：自動是正はしない。やるなら「検知→通知→隔離（可能なら）」まで。
ここは、情シスの経験則としても事故の温床です。“戻せるつもり”でも、通信断や公開設定のミスは、被害範囲が大きすぎます。
Dで自動化するなら「是正」ではなく、こうです：
逸脱を検知 → 即通知
既知の安全手順で一時隔離（可能なら）
実施は二人承認＋手動Change
迷ったら、この判定基準で決める
まず、変更を3つに分解する
Add（追加型）：ログ転送の追加、タグ付与など
Restrict（制限型）：deny/lock/強制など（互換性や運用影響が出る）
Destructive（破壊型）：削除・パージ・復旧不能の操作
そして次の質問にYesが多いほど、ClassはC→Dへ寄せます。
それは“戻せる”か？（復元Runbookや逆操作があるか）
対象を限定できるか？（RG/タグ/resourceSelectors 等）
コスト・保持・情報管理に影響するか？（ログ転送は典型）
権限や境界（ネットワーク）に触れるか？
誤検知したときの被害が大きいか？
よくある項目の「推奨分類」早見（情シスルール例）
A：自動OK（標準運用へ）
タグ補完（costCenter/owner/Envなど）
Policy modify で実装しやすい
B：自動＋影響上限（件数・並列・失敗閾値）
低リスクの構成是正（対象を限定でき、戻しが容易）
修復タスクで resourceCount / parallelDeployments / failureThreshold を縛る
C：承認必須（Change扱い）
診断設定（ログ転送）を全体適用
組み込みPolicyで大規模展開できる＝承認と設計が必要
コスト抑止（予算しきい値到達時に“自動アクション”）
予算しきい値到達でAzure Monitorのアクショングループを使えると整理されています
本番互換性に影響するセキュア設定の強制（TLS等）
D：原則禁止（検知は自動、是正は手動）
ネットワーク経路・境界変更（NSG/Firewall/Public公開）
RBAC特権付与/剥奪
削除・破壊的変更（自動クリーンアップ等）
例外は「期限付き」で運用する（これをやらないと破綻）
“例外”を永続化すると、統制が崩壊します。Azure Policyには**適用除外（Exemption）**があり、期限（expiresOn）を持たせられます。
情シス運用ルールとしては、例外は必ず次をセットにします。
期限（expiresOn）
例外カテゴリ（Mitigated/Waiver）
理由（技術制約/移行中/代替統制あり等）
代替統制（軽減策）
次回レビュー日
“運用として回す”ための最小提出物（監査・引継ぎが一気に楽）
この分類を決めても、台帳と証跡がなければ運用は死にます。最低限これだけは固定します。
自動是正対象カタログ（台帳）
対象、分類（A〜D）、実装方式、影響上限、承認要否、ロールバック
Change記録（C以上は必須）
What-If差分、承認ログ、実行ログ、確認結果
What-Ifで差分を事前に見られる
自動化の起動線（監視→アクション）
Azure Monitorのアクショングループは、メール/Webhook/Azure関数などの通知・アクションを持てます
RunbookはWebhookで起動できます
Runbook入力パラメータで「DryRun」「承認ID」「影響上限」を強制できます
最小権限（RBAC）設計
Azure Automationのベストプラクティスとして、最小特権・広範スコープ付与回避・ワイルドカード権限回避が明記されています
うまく開けない場合：Auto_Remediation_Target_Classification.zip
参考リンク（Microsoft公式URL）
# What-If（ARM/Bicep）
# Azure Policy（割当/影響評価/安全なデプロイ/修復）
# 診断設定（大規模適用）
# Azure Monitor（アクション グループ）
# Azure Automation（Runbook/Webhook/安全運用）
# Azure DevOps（承認とチェック）
# コスト予算（しきい値→アクション グループ）
最後に（情シスの現場向けメッセージ）
自動是正は「全部自動にする」が正解ではありません。“自動化してよい対象”を分類し、分類ごとに安全装置と証跡を固定するのが、最も事故が少なく、監査にも強い進め方です。
山崎行政書士事務所では、行政書士としての文書・運用設計（台帳・手順・例外管理・提出物化）と、Azure現場の実装現実（Policy/Monitor/Automation/DevOps）を矛盾なく繋げて、情シスの運用が回るところまで落とし込みます。必要なら、あなたの組織のサブスク構成・運用体制・ISMS/監査要求に合わせて、A〜D分類を“社内規程”として成立する文章に整えた上で、実装の設計図まで一気通貫で作れます。
コメント