予期しない事態に備える方法 (インシデント発生前)
確実な準備を行い、インシデントの影響を最小限に抑えるには、このユニットで概説する予防的な推奨事項に従うことが不可欠です。 これらのアクションは、インシデント通信プロセスを理解し、関連情報の検出や、タイムリーな更新プログラムを受信するための通知設定に役立ちます。 さらに、アプリケーションの回復性を評価し、推奨される対策を実装すると、より信頼性の高いワークロードを作成し、インシデントの潜在的な影響を軽減するのに役立ちます。 最後に、セキュリティに関するベスト プラクティスを確認して実装すると、環境が強化され、リスクが軽減されます。
常に最新の情報を入手し、影響を軽減し、投資を保護するには、次の 5 つのアクションをお勧めします。
アクション #1: Azure portal の Azure Service Health について十分に理解する
広範な停止のみに関する一般的な状態情報を提供するパブリック azure.status.microsoft ページとは異なり、Azure Service Health では、特定のリソースに合わせてカスタマイズされた詳細が提供されます。 これは、計画メンテナンスや、リソースの可用性に影響を与える可能性のあるその他の変更を予測して準備するのに役立ちます。 サービス イベントに対処し、影響を受けるアプリケーションのビジネス継続性を維持するためのアクションを管理できます。 プラットフォームの脆弱性、セキュリティ インシデント、プライバシー侵害に関する重要な分析情報を Azure サービス レベルで提供し、Azure ワークロードを保護するための迅速な対応を可能にします。
では、インシデントへの備えを強化するために Azure Service Health で利用できるいくつかの主要な機能を確認することにしましょう。
[リソース正常性] ペイン (新しく表示されるようになったエクスペリエンス)
Azure Resource Health は、Azure portal の [サービス正常性] ブレード内にあり、Azure リソースに影響を与えるサービスの問題の診断と解決に役立ちます。 仮想マシン、Web アプリ、SQL データベースなどのリソースについて、さまざまな Azure サービスからのシグナルに基づいて正常性が評価されます。 リソースが異常として識別された場合、Resource Health により、詳細な分析が実行され、問題の根本原因が特定されます。 また、インシデントに関連する問題を解決するための Microsoft のアクションに関する情報も提供され、問題に対処するために実行できる手順が提案されます。
[サービスに関する問題] ペイン (新しく表示されるようになったエクスペリエンス)
[サービスに関する問題] ペインには、リソースに影響を与える可能性のある進行中のサービス インシデントが表示されます。 これにより、問題がいつ始まったかを追跡し、影響を受けるサービスとリージョンを特定できます。 最新の更新プログラムを確認すると、インシデントを解決するための Azure の取り組みについて分析情報を得ることができます。
[サービスに関する問題] ペインの主な機能:
リアルタイムの分析情報: [サービスに関する問題] ダッシュボードには、サブスクリプションとテナントに影響を与えている Azure サービス インシデントがリアルタイムで可視化されます。 テナント管理者であれば、サブスクリプションおよびテナントに関連するアクティブなインシデントまたはアドバイザリを確認できます。
リソースに対する影響の評価: インシデントの詳細セクションにある [影響を受けるリソース] タブには、影響を受けることが確認されたリソースまたはその可能性があるリソースが表示されます。 リソースをクリックすると、[リソース正常性] ペインに直接アクセスできます。
リンクとダウンロード可能な説明: 問題管理システムで使用するために、問題へのリンクを取得できます。 また、PDF ファイルや場合によっては CSV ファイルをダウンロードして、Azure portal にアクセスできない関係者と包括的な説明を共有することもできます。 さらに、リソースに影響を与えている問題について、インシデント後レビュー (PIR) (以前は根本原因分析 (RCA) と呼ばれていました) を要求することもできます。
[セキュリティ アドバイザリ] ペイン
[セキュリティ アドバイザリ] ペインには、サブスクリプションおよびテナントの正常性に影響を与える緊急のセキュリティ関連情報が重点的に表示されます。 プラットフォームの脆弱性、セキュリティ インシデント、プライバシー侵害に関する分析情報が提供されます。
[セキュリティ アドバイザリ] ペインの主な機能:
リアルタイムのセキュリティ分析情報: サブスクリプションとテナントに関連する Azure セキュリティ インシデントを即座に可視化します。
リソースに対する影響の評価: インシデントの詳細セクションにある [影響を受けるリソース] タブでは、影響を受けることが確認されたリソースが強調表示されます。
以下のロールを認められたユーザーは、セキュリティの影響を受けたリソースの情報を確認できます。
サブスクリプション レベルのリソースの表示 テナント レベルのリソースの表示 サブスクリプションの所有者 セキュリティ管理者/セキュリティ閲覧者 サブスクリプション管理 グローバル管理者/テナント管理者 Service Health セキュリティ閲覧者 Azure Service Health プライバシー閲覧者 さらに、説明の PDF ドキュメントをダウンロードして、Azure portal に直接アクセスできない関係者と共有することもできます。
次の例は、サブスクリプションとテナントの両方のスコープから、影響を受けるリソースがあるセキュリティ インシデントを示しています。
Azure Service Health について十分に理解することに加えて、もう 1 つの重要な手順として、Service Health アラートを設定する必要があります。これにより、タイムリーな通知が確実に行われ、ワークロードに影響を与える可能性のあるインシデントや重要な情報を常に把握できます。 次のセクションでは、このトピックについて詳細に説明します。
アクション #2: Service Health アラートを設定して最新情報を常に入手する
プロアクティブなインシデント管理には、サービス正常性アラート通知の構成は不可欠であり、最も重要な行動要請です。 Service Health アラートを設定すると、メール、SMS、Webhook などのさまざまなチャネルを通じてタイムリーな通知を受信できます。 これらのアラートは、サービス インシデント、計画メンテナンス アクティビティ、セキュリティ インシデントに関する最新情報に加えて、ワークロードに影響を与える可能性のあるその他の重要な情報を提供します。
サービス正常性アラートは、Azure portal の [サービス正常性] ブレードにある任意の [有効なイベント] ペインから構成することも、[サービス正常性] ペインで [正常性アラート] をクリックするか、または Azure Resource Graph を利用して構成することもできます。
Azure Service Health 用の Azure Resource Graph サンプル クエリについては、こちらを参照してください。
Service Health を使用すると、サービスに関する問題、計画メンテナンス、正常性の勧告、セキュリティ アドバイザリなど、リソースに影響を与える可能性のあるさまざまな種類の正常性イベントを追跡できます。 サービス正常性アラートを構成する場合、そのアラートの送信方法と送信先を柔軟に選択できます。 サービス正常性通知のクラスと、影響を受けるサブスクリプション、サービス、リージョンに基づいてアラートをカスタマイズできます。
サービス正常性通知のクラス
| サービス正常性イベントの種類 | 説明 |
|---|---|
| サービスに関する問題 | 今すぐ影響を与える Azure サービスの問題。サービス インシデントとも呼ばれます。 |
| 定期的なメンテナンス | 将来のサービスの可用性に影響を与える可能性がある今後のメンテナンス。 |
| 正常性の勧告 | 注意を要する Azure サービスの変更。 例としては、アクションを実行する必要がある場合、Azure 機能が非推奨になった場合、アップグレード要件、使用量クォータを超過した場合などがあります。 |
| セキュリティ アドバイザリ | プラットフォームの脆弱性と、サブスクリプションおよびテナント レベルでのセキュリティとプライバシーの侵害に対処するセキュリティ関連の通知。セキュリティ インシデントやプライバシー インシデントとも呼ばれます。 |
サービスに影響を与える問題が発生した場合、お客様が通知を受け取る必要があることがわかっているので、サービス正常性アラートでは、これらのアラートの送信方法と送信先を選択できるようにしました。 アラートは、サービス正常性通知のクラス、影響を受けるサブスクリプション、影響を受けるサービス、影響を受けるリージョンに基づいて構成できます。 メール、SMS、メッセージ、ロジック アプリ、関数などをトリガーするアラートを設定できます。
アラートがトリガーされると、アクショングループを使用して実行するアクションを定義できます。 アクション グループは、アラートの送信方法と送信先を決定する通知設定のコレクションです。
使用可能な通知の種類の完全な一覧
| 通知のタイプ | 説明 | フィールド |
|---|---|---|
| 電子メールの Azure Resource Manager のロール | それぞれのロールに基づいて、サブスクリプション メンバーに電子メールを送信します。 通知メールは、Microsoft Entra ユーザー用に構成されたプライマリ メール アドレスにのみ送信されます。 メールは、選択されたロールの Microsoft Entra ユーザー メンバーにのみ送信され、Microsoft Entra グループやサービス プリンシパルには送信されません。 |
Microsoft Entra ユーザー用に構成されたプライマリ メール アドレスを入力します。 「電子メール」を参照してください。 |
| メール フィルタリングとマルウェア/スパム防止サービスが適切に構成されていることを確認します。 電子メールは、次の電子メール アドレスから送信されます。 - azure-noreply@microsoft.com - azureemail-noreply@microsoft.com - alerts-noreply@mail.windowsazure.com |
通知を送信するメール アドレスを入力します。 | |
| sms | SMS 通知では双方向通信がサポートされます。 SMS には、次の情報が含まれています。 - このアラートの送信先となったアクション グループの短い名前 - アラートのタイトル。 ユーザーは、次のことを行うために SMS に応答できます。 すべてのアクション グループまたは単一のアクション グループのすべての SMS アラートの登録解除。 - アラートへの再登録 - サポートの要求。 サポートされている SMS の返信の詳細については、「SMS の返信」を参照してください。 |
SMS 受信者の国番号と電話番号を入力します。 Azure portal で国/地域コードを選択できない場合、SMS は国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 お客様の国がサポートされるまでの回避策として、お客様の国/地域をサポートするサード パーティの SMS プロバイダーに Webhook を呼び出すようにアクション グループを構成します。 |
| Azure アプリのプッシュ通知 | Azure mobile app に通知を送信します。 Azure mobile app へのプッシュ通知を有効にするための詳細については、Azure mobile app に関するページを参照してください。 | [Azure アカウントの電子メール] フィールドに、Azure mobile app を構成するときにアカウント ID として使用するメール アドレスを入力します。 |
| 音声 | 音声通知です。 | 通知の受信者の国番号と電話番号を入力します。 Azure portal で国/地域コードを選択できない場合、音声通知はご利用の国/地域ではサポートされていません。 国/地域コードが利用できない場合は、アイデアを共有するで国/地域を追加するために投票できます。 お客様の国がサポートされるまでの回避策として、お客様の国/地域をサポートするサード パーティの音声通話プロバイダーに Webhook を呼び出すようにアクション グループを構成します。 |
トリガーできるアクションの完全な一覧
| アクションの種類 | 詳細 |
|---|---|
| Automation Runbook | Automation Runbook ペイロードの制限の詳細については、「Automation の制限」を参照してください。 |
| Event Hubs | Event Hubs アクションは、通知を Event Hubs に発行します。 Event Hubs の詳細については、「Azure Event Hubs - ビッグ データ ストリーミング プラットフォームとイベント インジェスト サービス」を参照してください。 イベント受信者からアラート通知ストリームをサブスクライブできます。 |
| 関数 | 関数で既存の HTTP トリガー エンドポイントを呼び出します。 詳細については、Azure Functions に関するページを参照してください。 関数アクションを定義すると、関数の HTTP トリガーエンドポイントとアクセスキーがアクション定義に保存されます (https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key> など)。 関数のアクセス キーを変更する場合は、アクション グループで関数アクションを削除して再作成する必要があります。エンドポイントで HTTP POST メソッドがサポートされている必要があります。 関数は、ストレージ アカウントへのアクセス権を持っている必要があります。 アクセス権がない場合、キーを使用できず、関数の URI にアクセスできません。 ストレージ アカウントへのアクセスの復元についてはこちらを参照してください。 |
| ITSM | ITSM アクションには ITSM 接続が必要です。 ITSM 接続の作成方法については、「 ITSM 統合」 を参照してください。 |
| ロジック アプリ | Azure Logic Apps を使用して、統合用のワークフローを構築およびカスタマイズしたり、アラート通知をカスタマイズしたりできます。 |
| セキュリティで保護された Webhook | セキュリティで保護された Webhook アクションを使用する場合、Microsoft Entra ID を使用して、アクション グループとエンドポイント (保護された Web API) 間の接続をセキュリティで保護する必要があります。 セキュリティで保護された Webhook の認証の構成に関するセクションを参照してください。 セキュリティで保護された Webhook では、基本認証はサポートされていません。 基本認証を使用している場合は、Webhook アクションを使用します。 |
| Webhook | Webhook アクションを使用する場合、ターゲット Webhook エンドポイントは、さまざまなアラート ソースが出力する、さまざまな JSON ペイロードを処理できる必要があります。 Webhook アクションを介してセキュリティ証明書を渡すことはできません。 基本認証を使用するには、URI で資格情報を渡す必要があります。 Webhook エンドポイントが特定のスキーマ (Microsoft Teams スキーマなど) を必要とする場合は、Logic Apps アクションの種類を使用して、ターゲット Webhook の想定に合わせてアラート スキーマを操作する必要があります。 Webhook アクションの再試行に使用される規則の詳細については、「Webhook」を参照してください。 |
ほとんどのサービス インシデントは、影響を与えるサブスクリプションの数が少ないため、status.azure.com などの場所には表示されないことに注意してください。 サービス正常性アラートはポータルから構成できます。作成を自動化する場合は、PowerShell または ARM テンプレートを使用して構成することもできます。
Service Health アラートとアクション グループを効果的に構成すると、タイムリーな通知受け取り、適切なアクションを実行して、Azure リソースに対するインシデントの影響を軽減できます。
Note
何を監視するか、何に対してどのアラートを設定する必要があるかについて役立つ情報が必要な場合は、 "Azure Monitor ベースライン アラート" ソリューションが最適です。 これは、ポリシーとイニシアチブを使用してプラットフォーム アラートとサービス正常性アラートのベースラインを Azure 環境に実装するための包括的なガイダンスとコード、および自動または手動デプロイのオプションを提供します。 このソリューションには、すべての種類のサービス正常性イベント (サービスに関する問題、計画メンテナンス、正常性の勧告、セキュリティ アドバイザリ) に関するアラート、アクション グループ、さまざまな種類の Azure リソースに関する警告処理ルールを自動的に作成するための事前定義済みポリシーが含まれています。 これは、Azure ランディング ゾーン (ALZ) の設計環境の監視に重点を置いていますが、現在 ALZ アーキテクチャのブラウンフィールドに対応していないブラウンフィールドのお客様向けのガイダンスも提供します。
アクション #3: リソース固有の問題を通知する Resource Health アラートまたは Scheduled Events を検討する
サービス正常性アラートを設定したら、リソース正常性アラートの導入も検討します。 Azure Resource Health アラートを導入すると、リソースの正常性状態が変化したときに、その理由に関係なく、準リアルタイムで通知を受け取ることができます。
'サービス正常性' アラートと 'リソース正常性' アラートの主な違いは、前者は、現在継続しており、Microsoft が調査中の停止 (サービス インシデント) など、プラットフォームの既知の問題の発生中にトリガーされるのに対して、 後者は、根本的な原因に関係なく、特定のリソースが異常と見なされたときにトリガーされることです。
リソース正常性アラートは、Azure portal の [サービス正常性] ブレードの [リソース正常性] ペインから構成できます。
Azure Resource Manager テンプレートおよび Azure PowerShell を使用して、リソース正常性アラートをプログラムで作成することもできます。 Resource Health アラートをプログラムで作成すると、通知を一括で作成およびカスタマイズできます。
影響を回避するための仮想マシンのスケジュール化されたイベント
スケジュール化されたイベントは、上記の両方の種類の 'アラート' を人またはシステムに通知するもう 1 つの優れたツールであり、スケジュール化されたイベントがリソース自体に通知されます。 これにより、仮想マシンのメンテナンスやいずれかの自動化されたサービス修復イベントに備える時間をアプリケーションに与えることができます。 差し迫っているメンテナンス イベント (たとえば、まもなく開始される再起動など) に関する信号が提供されるため、アプリケーションはそれを認識し、プールからドロップアウトする自動化の実行や、機能の適切な低下などにより、中断を制限する措置を講じることができます。 スケジュール化されたイベントは、Windows と Linux の両方で、PaaS や IaaS を含むすべての種類の Azure Virtual Machine で利用できます。
Note
リソース正常性アラートとスケジュール化されたイベントはどちらも役に立つツールですが、最も重要な行動要請はサービス正常性アラートを構成することです。 これは、リソースで何が起こっているか、そのリソースに対して何を行っているか、いつ軽減されるかを確実に理解するために重要です。
アクション #4: 投資のセキュリティを強化して環境を保護する
運用可能なセキュリティに関するベスト プラクティスに関する記事を確認し、それらを実装して、Azure 内のデータ、アプリケーション、その他の資産を確実に保護します。 これらのベスト プラクティスは、Azure プラットフォームの現在の機能を使用しているユーザーの知識と経験を集約したものです。 この記事は、進化するオプションやテクノロジを反映するために定期的に更新されています。
出発点として、実装に関する次の主要な推奨事項を検討します。
すべてのユーザーに対して 2 段階認証を要求します。 これには、組織内の管理者およびアカウントが侵害された場合に重大な影響を及ぼす可能性のあるその他のユーザー (財務担当者など) が含まれます。 この露出に関する懸念を軽減するには、多要素認証を適用します。
テナントでリスク ポリシーを構成して有効にすると、環境内に '誰' かがいる場合にアラートが通知されます。 これにより、匿名 IP アドレスの使用、変則的な移動、見慣れないサインイン プロパティなどの危険なイベントに対するアラートが作成され、さらに多要素認証、パスワードのリセットなどの修復作業がトリガーされて、お客様の安全性が確保されます。
環境内に '誰' がいるかを認識し、準備するための事前対策として、ディレクトリとの間のサブスクリプションの移動を制御します。 これにより、組織は、使用されているサブスクリプションを完全に把握できるようになり、不明なディレクトリへのサブスクリプションの移動を防ぐことができます。
潜在的なセキュリティ侵害、アカウントの侵害、または特権アクセス許可の不正使用から保護するために、すべての全体管理者とサブスクリプション管理者の資格情報を定期的にローテーションします。 資格情報を定期的にローテーションすると、環境にセキュリティ層が追加され、データおよびリソースの整合性と機密性を維持するのに役立ちます。
テナント内のすべてのグローバル管理者ユーザーのメール アドレスと電話番号を確認し、定期的に更新します
アクション #5: 潜在的な影響を回避するか、最小限に抑えるために、主要な Azure ワークロードの回復性を高める
ワークロードの信頼性を確保するには、Microsoft Azure Well-Architected Review を使用して、Microsoft Azure Well-Architected Framework (WAF) の原則に基づいてワークロードを評価することが重要です。 WAF には、カオス エンジニアリング手法の採用など、回復性テストに関する推奨事項も用意されています。
可用性と回復性の両方を確保するために、アプリケーションのテストを行う必要があります。 可用性は、アプリケーションが多大なダウンタイムを発生することなく動作する期間を指し、回復性は、アプリケーションが障害からどの程度迅速に回復できるかを測定します。
WAF を使用した作業を補完するために、次の重要な推奨事項を実装し、提供されているツールを活用して、アプリケーションの回復性を確認し構築することを検討します。
Azure portal の [Azure Advisor] ブレードの下にある統合された信頼性ブックを利用して、アプリケーションの信頼性の状況を評価し、潜在的なリスクを特定し、改善を計画して実装します。
ワークロードとリソースを複数のリージョンに展開して、事業継続とディザスター リカバリー (BCDR) を強化します。 最適なリージョン間デプロイ オプションについては、Azure リージョン ペアの包括的な一覧を参照してください。
ワークロードおよびリソースのデプロイを Availability Zones 全体に分散して、リージョン内の可用性を最大化します。
高度な分離を必要とするビジネス クリティカルなワークロードには、Azure の分離された仮想マシン サイズを利用することを検討します。 これらのサイズにより、仮想マシンが特定の種類のハードウェア専用となり、独立して動作することが保証されます。 詳細については、「Azure における仮想マシンの分離性 - Azure Virtual Machines | Microsoft Learn」を参照してください。
Azure 仮想マシンの更新の制御と管理を向上するには、メンテナンス構成の利用を検討します。 この機能を使用すると、更新のスケジュールと管理が可能になり、メンテナンス アクティビティ中のダウンタイムを許容できない機密性の高いワークロードの中断を最小限に抑えることができます。
リージョン間またはリージョン内の冗長性を実装して、冗長性を強化します。 ガイダンスについては、高可用性ゾーン冗長 Web アプリケーションの例を参照してください。
Azure Chaos Studio を利用して、アプリケーションの回復性を強化します。 このツールを使用すると、制御された障害を Azure アプリケーションに意図的に導入することができ、アプリケーションの回復性を評価し、ネットワーク遅延、ストレージの停止、シークレットの期限切れ、データセンターの障害などのさまざまな中断に対するアプリケーションの対応を観察できます。
Azure portal の [Azure Advisor] ブレードの下にあるサービスの廃止ブックを利用します。 この統合ツールを使用すると、重要なワークロードに影響を与える可能性のあるサービスの廃止に関する情報を常に入手できるため、必要な移行を効果的に計画して実行できます。
Note
Premier またはユニファイド サポート契約を結んでいるお客様は、カスタマー サクセス チームを利用して、Well-Architected Framework 評価 (WAF) を戦略化し、実装できます。