Azure自動是正を“事故らせない”ための安全装置
- 山崎行政書士事務所
- 2 時間前
- 読了時間: 8分
〜Dry-run／影響上限（爆風半径）／承認フロー／ロールバックの実務設計〜
Azureの自動是正（Policyの修復タスク・Runbook・Functions等）は、情シスにとって“運用を救う武器”です。一方で、設計を誤ると「全社規模の変更」を一気に走らせる事故装置にもなります。
Microsoft自身も、Azure Policyの導入や新規ポリシーの展開は段階的に検証しながら進めることを推奨しています（擬陽性＝誤検知の排除、DoNotEnforceの活用、resourceSelectorsで段階ロールアウト、継続監視など）。
ここでは、情シス運用として“提出物にできる形”で、自動是正の安全装置4点セットを実務ルールに落とします。（※当事務所は行政書士として、規程・手順・台帳・証跡設計を支援します。個別紛争や訴訟対応など弁護士領域の業務は行いません。）
0. 前提：自動是正は「自動修復」ではなく“変更管理”そのもの
自動是正を安全にするコツはシンプルで、
変更前に「何が変わるか」を確実に見える化（Dry-run）
変える範囲と速度を物理的に制限（影響上限）
重要変更は人の承認ゲートを通す（承認フロー）
失敗時に止められて、戻せる（ロールバック）
この4つを仕組みとして組み込むことです。
1) Dry-run（シミュレーション）――“何が変わるか”を先に見せる
1-1. IaCは「What-If」を必ず通す（ARM/Bicep）
Bicep/ARMでデプロイする変更は、What-If操作で差分プレビューできます。What-Ifは「変更予測」であり、既存リソースに変更を加えないと明記されています。
さらに、削除を伴う可能性がある“Completeモード”のような危険操作は、Azure CLIで --confirm-with-what-if を使って、What-If結果を見てから確定できます。
実務ルール（情シス向け） 本番相当の変更は必ずWhat-If結果をチケットに添付（証跡化） What-Ifで Delete が含まれる場合は 必ず承認フローに乗せる（後述）
補足：BicepはWhat-Ifに加え、bicep snapshot でAzure接続なしのローカル比較テストもでき、意図しないロジック変更の検出に役立つ、と説明されています。
1-2. Azure Policyは「enforcementMode = DoNotEnforce」で“当ててみる”
Azure Policyの割り当てには enforcementMode があり、ポリシー適用（強制）やアクティビティログのトリガーなしに、既存リソースに対する結果をテストできる、と公式に明記されています。
Default：作成/更新時に効果が適用される
DoNotEnforce：作成/更新時に効果が適用されない（テスト向け）
実務ルール 新しいPolicyは、最初はDev環境＋DoNotEnforce “擬陽性（誤検知）”がないことを確認してから段階展開 DINE（deployIfNotExists）系は、テンプレート変更の検証にARM What-Ifの併用が推奨されています
1-3. Runbookは「DryRunパラメータ」を必須化する（+テストペイン）
Azure Automation Runbookは入力パラメータを持てます。 ここに -DryRun（既定 True）を必須で入れて、本番では承認済みのときだけ DryRun=False にする設計が強いです。
さらに、Runbookはポータルのテストペインでドラフト版を実行でき、その実行はアクティビティログにも記録される（通常実行と区別される）点が公式に触れられています。
実務ルール Runbookは (1)テストペインでDryRun → (2)本番でDryRun → (3)承認後に実行 の3段階 DryRun時は「対象一覧」「予定変更内容」「変更件数」を必ずログ出力して証跡化
2) 影響上限（爆風半径）――“範囲”と“速度”を物理的に縛る
2-1. スコープを段階的に広げる（RG → Sub → MG）
Microsoftの手順でも、新しいPolicyは最初にリソースグループなどサブセットから開始し、段階的にスコープを拡張することが推奨されています。
段階ロールアウトの具体策として、Policy割り当ての resourceSelectors を使い、場所やリソース種類などで“まず一部だけ評価”ができます。これは安全なデプロイ（Safe Deployment Practices）を容易にする、と説明されています。
2-2. 除外の使い分け：notScopes（恒久） vs 適用除外（期限付き）
Policyでは「除外」を2種類に分けて運用すると事故が減ります。
notScopes：評価から除外（恒久的な除外に向く）
適用除外（Exemption）：一時的な特別承認など、期限付き例外に向く
expiresOn で期限設定でき、期限が来てもオブジェクトは削除されず“無効になる”（記録保持）と明記
カテゴリ（軽減済み/免除）など、例外に理由を持たせられます
実務ルール notScopes：設計上どうしても対象外にする“構造的除外” Exemption：例外台帳に載せる“期限付きの逸脱” Exemptionは 必ず期限（expiresOn）＋理由＋代替統制（軽減策） をセットで管理
2-3. 修復タスク（Remediation task）に“速度制限”を掛ける
Policyの自動是正（modify / deployIfNotExists）の修復タスクは、そもそも構造として
resourceCount（修復対象件数）
parallelDeployments（同時修復数）
failureThreshold（失敗率が閾値を超えたら止める）
修復フィルター（場所など）
検出モード（再評価してから修復など）
を持ちます。
しかも数値の範囲まで明記されており、例えばresourceCount は既定 500、最大 50,000、parallelDeployments は 1〜30（既定10）などが示されています。
実務ルール（おすすめ初期値） parallelDeployments：1〜3（まず遅く、安全に） resourceCount：50〜200（小さく区切ってチケットで回す） failureThreshold：5〜10%（失敗が出たら即止めて原因調査） “場所フィルター”で先に一部リージョンだけ修復 → 問題なければ拡大
補足：修復タスクのリソースは、最後の変更から60日で削除されると明記されています。監査証跡の保持が必要なら、結果をExportして別途保管する設計が安全です。
2-4. 自動化ID（Managed Identity）の権限を最小化する（＝爆風半径の最終防壁）
自動是正の“最終防壁”は権限です。Azure Automationのセキュリティ ガイドラインでも、最小特権原則に従い、広範なロール/スコープを割り当てない、ワイルドカードを含むロールを避ける、と強く書かれています。
実務ルール 自動化用MIは 対象RG単位でRBACを付与（サブスク全体付与を避ける） “例外処理”が必要な場合は、MIの権限を広げるのではなく 承認フローに逃がす（次章）
3) 承認フロー（Human-in-the-loop）――“危険な変更”は人が止める
3-1. 王道：DevOpsの環境「承認とチェック」をゲートにする
Azure DevOpsでは、環境に対して「承認」チェックを追加し、ステージの実行タイミングを手動で制御できます（運用環境へのデプロイ制御など）。
実務ルール 本番サブスク/本番MGに影響する変更は 必ず環境承認を必須 承認者は情シス運用責任者＋システムOwner（最低2名） 承認条件：What-If差分、影響上限設定、ロールバック手順、実行ログ保存先
3-2. 運用系：アラート→承認→WebhookでRunbook起動
監視起点の自動是正は、Azure Monitorのアクション グループで WebhookやAzure Functions等を呼べます。 そしてAzure Automationは WebhookでRunbook起動できます。
この2つを組み合わせると、情シスが欲しい「自動化＋統制」が作れます。
例：非準拠検知 → チケット → 承認 → 実行
Policy/Monitorで逸脱検知
Action GroupでLogic Apps/Functionsへ
Teams/ITSMで承認（承認ID発行）
承認後にAutomation Webhookを叩いてRunbook起動（DryRun=False＋承認ID必須）
実務ルール Runbookは 承認IDがないと本実行できない（パラメータで強制） “緊急自動是正”を許すのは、停止や隔離など 戻しやすい操作だけ に限定
4) ロールバック（戻し）――「止める」→「戻す」→「再発防止」を分ける
4-1. ロールバック設計は2段階：「キルスイッチ」と「復元」
事故時に必要なのは、いきなり完全復元ではなく、順番です。
止血（キルスイッチ）：これ以上変更が広がらないように止める
復元（ロールバック）：元に戻す（または安全な状態に寄せる）
再発防止：擬陽性、権限、範囲、承認条件の見直し
4-2. IaCのロールバックは「Gitで戻して再デプロイ」＋What-Ifで確認
IaC（Bicep/ARM）の強みは、ロールバックもデプロイとして行えることです。戻しでもWhat-Ifで差分を見てから実行すれば、二次被害を防げます。
4-3. Azure Policyのロールバックは「DoNotEnforce化」か「割当削除」
Policyで事故が起きたときの“止血”は速いです。enforcementMode=DoNotEnforce にすれば、作成/更新時の効果が適用されない（テストモード）と明記されています。
実務ルール 事故時の一次対応は (a) DoNotEnforce化 or (b)割当削除 を手順化 その後、適用済みの変更（タグや設定）を“復元Runbook”で戻す
加えて、Policy割り当ては definitionVersion を使って評価対象バージョンを制御できます（ワイルドカードでマイナー/パッチ更新を取り込むなど）。 “いつの間にかポリシー内容が変わる”事故を防ぐため、バージョン運用はかなり効きます。
4-4. 修復タスクは“取り消し”ができるが、適用済み変更は別途戻す
修復タスク自体はCLIでも管理でき、cancel コマンドがあります。 ただし、すでに変更されたリソースは自動で元に戻りません。だから、復元は以下が現実解です。
変更前状態の退避（バックアップ）：タグ、設定値、診断設定などをRunbookで保存
逆操作Runbook（復元Runbook）：退避した状態へ戻す
Policyの modify 効果は、作成/更新時にプロパティ/タグを追加・更新・削除する用途で使える、と説明されています。 つまり、変更が入る設計にするなら、“戻しの設計”も同じ粒度で用意するのが安全です。
4-5. Runbookは「中断すると先頭から再開」＝冪等設計が必須
Azure Automationでは、Runbookが中断された場合「先頭から再開される」と明記されています。 この仕様を知らずに“副作用のある処理”を書いていると、再実行で二重適用が起きます。
実務ルール Runbookは必ず 冪等（何回やっても同じ結果） に寄せる 変更前の状態をログに残す（復元に必要） 長い処理は段階分割・チェックポイントを検討（Workflow利用時の注意点も公式で触れられています）
5) ISMS/監査で刺さる「提出物」セット（情シスが楽になるやつ）
自動是正は、監査視点では“統制対象の変更”です。最低限、次の提出物があると、監査対応が急に楽になります。
自動是正台帳（Runbook/Policy/Functions：目的、トリガー、権限、影響範囲、Owner、ロールバック）
例外台帳（Policy Exemption：理由、軽減策、期限expiresOn、承認者）
変更記録（Change票）（What-If結果、影響上限、承認ログ、実行ログ、確認結果）
事故時手順（キルスイッチ手順）（DoNotEnforce化、修復タスクCancel、Runbook停止）
演習記録（半年に1回でもいいので“止めて戻す”訓練ログ）
参考リンク（Microsoft公式URL）
# Azure Policy：影響評価・段階展開
# Azure Policy：適用除外（Exemption）
# Azure Policy：修復タスク（Remediation）
# Azure Resource Manager / Bicep：What-If
# Azure Automation：Webhook / Runbook運用
# Azure Monitor：アクション グループ（通知＋自動アクション）
# Azure DevOps：承認（環境の承認とチェック）
コメント