Microsoft AZ-500: インシデント対応、復旧、レジリエンス — 学習ガイド

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Security Engineer Associate AZ-500 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azureにおけるインシデント対応、回復、回復性は、十分にリハーサルされた運用手順とプラットフォームネイティブの制御を融合させた継続的な能力です。効果的なプログラムは、障害や侵害を予測し、迅速に検出・トリアージし、自動化によって影響範囲を封じ込め、定義された目標に従ってサービスを復旧し、不変の証拠を保全し、そして学んだ教訓に基づいて環境を強化します。AzureネイティブサービスであるMicrosoft Sentinel、Defender for Cloud、Logic Apps、Azure Backup、Azure Site Recovery (ASR)、DDoS Protection、Web Application Firewall (WAF)、Traffic Manager/Front Door、Microsoft Entraが、その構成要素を提供します。設計上の要件は、適切なテレメトリ、IDの非常時アクセス経路、および自動化された強制措置を事前に準備し、チームが数時間ではなく数分以内に対応を実行できるようにすることです。

インシデント対応ライフサイクルとSentinelの運用

• 準備

  • 誰が、いつ、どのツールを使って何を行うかを定義します。Microsoft Sentinelワークスペースを事前にプロビジョニングし、データソース（Activity Log、リソースログ、NSGフローログ、Microsoft Entraサインイン/監査ログ、Defenderシグナル）を接続し、アナリスト、レスポンダー、インシデントコマンダーのためのアクセス制御とRBACを実装します。
  • VMの隔離、ユーザートークンの失効、キーのローテーションなどの一般的な封じ込めアクションのためのプレイブック（Logic Apps）を作成します。隔離用のNSGや専用の「フォレンジック」サブスクリプションを事前に準備します。
  • 診断設定を介してLog Analyticsおよび不変性（WORM）が設定されたAzure Storageアカウントへの不変のログ保持を確立します。

• 検出

  • Sentinelで、認証情報窃取、稀なサインインパターン、不審なプロセス実行、Key Vaultの不正利用、データ窃取に対する分析ルールを有効にします。UEBAとフュージョンルールで補強し、無害なイベントを相関させて意味のあるインシデントにまとめます。アラート疲れを最小限に抑えるため、ルールのしきい値と抑制を調整します。

• 封じ込め

  • 事前に承認されたアクションを実行します：NSGによるNICの隔離、侵害されたサービスプリンシパルの無効化、Entraリフレッシュトークンの失効、シークレットのローテーション、インバウンドのパブリックエンドポイントの無効化、またはWAFの防止モードへの切り替え。Sentinelのオートメーションルールを使用して、重要度によるルーティング、タグの追加、所有者の割り当て、プレイブックのトリガーを行います。

• 根絶

  • 永続化（スタートアップタスク、スケジュールされたジョブ、cloud-initスクリプト、悪意のある拡張機能）を削除し、認証情報をローテーションし、ゴールデンイメージを再デプロイし、Defender for Cloudによってフラグ付けされた脆弱性にパッチを適用します。ID関連のインシデントについては、パスワードのリセットを要求し、条件付きアクセスを強化します。

• 回復

  • クリーンなVNetにAzure Backupから復元し、ASRリカバリプランを使用してフェイルオーバーします。既知の正常なソース（IaCテンプレート、論理削除/消去保護付きのKey Vault）から整合性を検証し、シークレットと構成を再ハイドレートします。RTOとRPOが満たされていることを確認します。

• 教訓

  • 非難を伴わないレビューを実施します。Sentinelのルールとプレイブック、Azure Policyの割り当て、ベースラインイメージ、およびRunbookを更新します。修復策をIaCでコード化し、管理グループを介して強制します。

Sentinelのトリアージ、証拠収集、調査、およびケース管理

• トリアージ

  • エンティティのエンリッチメント（ホスト、ユーザー、IP）とウォッチリストを使用して、重要度、資産の重要性、影響範囲に基づいてインシデントを優先順位付けします。インシデントのグループ化を使用して重複を減らし、タイムラインビューでシーケンスを理解します。

• 証拠収集

  • 注目すべきイベントをブックマークし、生ログを不変ストレージにエクスポートし、影響を受けたVMディスクをオフライン分析用にスナップショットし、Defender for Endpoint連携を介してプロセスツリーをキャプチャします。ハッシュを保存し、フォレンジックリソースグループへのアクセスを制限することで、証拠の連続性を維持します。

• 調査

  • 調査グラフとエンティティページ（ユーザーのサインイン履歴、ホストのプロセスツリー）を使用します。SigninLogs、AuditLogs、SecurityEvent、AzureDiagnosticsにまたがってKQLでハンティングします。調査結果を記録し、アーティファクトを添付し、将来の検出のためにIOCにタグを付けます。

• ケース管理

  • ステータス（新規、アクティブ、進行中、解決済み）、所有者、SLAタイマーを標準化します。チケット発行と変更管理のために、SentinelをITSM（ServiceNow/Azure DevOps）と統合します。オートメーションルールは、既知の無害なアラートを自動的にクローズしたり、特定の戦術をTier 2にエスカレーションしたりできます。

自動化された封じ込めとワークフローのオーケストレーション

• Sentinelオートメーションルール

  • インシデントの作成/更新時にトリガーします。動的に所有者を割り当て、重要度を設定し、タグ（例：QuarantineCandidate）を追加し、1つ以上のプレイブックを呼び出します。理論的根拠：最小権限と事前承認されたプレイブックに沿って、検出からアクションまでを数秒以内に移行します。

• Logic Appsプレイブック

  • 一般的なアクション：VMのNICに隔離用NSGを適用する、ユーザーを無効にする、トークンを失効させる、WAFでIPをブロックする、または完全なコンテキストを含むITSMチケットを開く。マネージドIDとAzure RBACを使用して、各プレイブックの権限を正確なリソースセットにスコープします。

• Defender for Cloudワークフローオートメーション

  • 推奨事項またはアラート（例：「インターネットに開かれたRDP」）に対して、プレイブックを自動トリガーして修復（NSGルールの厳格化）、フォローアップのためのリソースへのタグ付け、または所有者への通知を行います。理論的根拠：露出を迅速に閉じ、セキュアスコアを向上させ、攻撃者の滞留時間を短縮します。

例：VMのNICを数秒で隔離する

# Create a high-priority deny-all inbound NSG rule and associate a quarantine NSG to the NIC
az network nsg rule create -g rg-prod -n QuarantineDenyAll --nsg-name nsg-quarantine \
  --priority 100 --access Deny --direction Inbound --protocol '*' --source-address-prefixes '*' \
  --source-port-ranges '*' --destination-address-prefixes '*' --destination-port-ranges '*'

az network nic update -g rg-prod -n vm1-nic --network-security-group nsg-quarantine

侵害されたユーザーのトークン失効

az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/users/user@contoso.com/revokeSignInSessions"

バックアップ、レプリケーション、RTO/RPO、および回復性

Azure Backup のセキュリティ

• Recovery Services コンテナーと Backup コンテナー

  • ワークロードの境界とリージョンごとにコンテナーを使用します。誤った/悪意のあるバックアップ項目の削除から保護するために論理的な削除を有効にし、規制要件に合わせた適切な保持期間を設定します。元に戻せない削除を防ぐために、(サポートされている場合は) 消去保護を有効にします。

• 不変性

  • コンテナーの不変性を構成します。初期チューニング中はロック解除モードを使用し、その後、保持期間の短縮やポリシーの改ざんを防ぐためにロックモードに切り替えます。論理的根拠: バックアップが一度書き込まれると変更不可能であることを保証し、ランサムウェア対策の重要なコントロールとなります。

• 複数ユーザーによる承認 (MUA)

  • 重要なバックアップ操作 (例: データ削除を伴う保護の停止、コンテナー設定の変更) は、別のチームが所有する別のサブスクリプション/リソースグループにある Azure Backup Resource Guard を使用して保護します。論理的根拠: 職務の分離を強制します。攻撃者が回復可能性を破壊するには、異なるスコープにある2つのIDを侵害する必要があります。

• クロスリージョン機能

  • GRS を使用する RSV の場合、プライマリリージョンが利用できなくなった場合でも復旧できるように、クロスリージョンリストアを有効にします。ワークロードで使用される暗号化キーも回復性があることを検証します (Key Vault の論理的な削除/消去保護、および必要に応じて geo 冗長リカバリ計画)。

Azure Site Recovery (ASR)

• レプリケーション

  • Azure-to-Azure、VMware/Hyper-V-to-Azure、および物理サーバー。レプリケーションポリシー (RPO のしきい値、復旧ポイントの保持期間、アプリケーション整合性スナップショットの頻度) を定義します。必要に応じて Mobility service をデプロイします。

• 復旧計画

  • 起動順序、手動ステップ、および Runbook (例: DNS の更新、接続文字列の切り替え) を使用して、多層アプリケーションのフェイルオーバーをオーケストレーションします。資格情報とスクリプトは Key Vault に保管します。

• テストフェイルオーバー

  • マスクされた IP を持つ分離された VNet に対して、定期的に非破壊的なテストを実行します。状態をリセットするには、「テストフェイルオーバーのクリーンアップ」を使用します。論理的根拠: 本番環境に影響を与えることなく、エンドツーエンドのリカバリを検証します。

• フェイルバック

  • プライマリサイトの復旧後、再保護してフェイルバックし、変更を再同期します。ビジネス SLA を満たすために、帯域幅ウィンドウとメンテナンスを計画します。

RTO/RPO を満たすためのアーキテクチャの選択

• 短い RPO (秒〜分) と短い RTO (分)

  • バックアップよりも ASR またはネイティブアプリケーションのレプリケーション (例: SQL Always On, Cosmos DB のマルチリージョン) を優先します。ホットスタンバイまたはウォームスタンバイを維持し、リージョンフェイルオーバーには Front Door/Traffic Manager を使用します。

• 中程度の RPO (時間) と RTO (時間)

  • 頻繁なバックアップとクリティカルな層向けの ASR を組み合わせます。リストア時間を短縮するために、バックアップ高速化機能 (インスタントリストアスナップショット) を使用します。

• 長い RPO (日) と RTO (日)

  • より長い保持期間を持つバックアップのみ。コスト最適化されたアーカイブ層。

運用の論理的根拠: レプリケーションは継続的なコストが高い代わりに短い RPO を実現します。バックアップは安価な長期保持を提供しますが、RTO/RPO は長くなります。ビジネス影響度分析に合わせて、層ごとにこれらを組み合わせます。

← ハイブリッドおよびマルチクラウドのセキュリティ · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →