Microsoft Azure インシデント対応 - 統合
Azure インシデントが宣言されると、(Azure portal 内) Azure Service Health のサービスの問題ブレードを介して、影響を受けるサブスクリプションまたはテナントに更新情報が通知されます。
インシデントの前に
組織を保護するには、次の手順を準備することをお勧めします。
Azure サービスに影響を与えるインシデントについて通知を受信し、常に最新情報を入手する
問題が発生した場合の「参照先」となる場所である Azure portal で、Azure Service Health についてよく理解します。
Service Health アラートを構成して、サブスクリプション レベル、サービスごと、地域ごとにメール、SMS、Webhook などで問題が通知されるようにします。
サービスの問題通知タイプは、サービスがサービス インシデントの影響を受けることを組織に警告します。
セキュリティ アドバイザリ通知タイプは、サービスがセキュリティ インシデントまたはプライバシー インシデントの影響を受けることを組織に警告します。
基本的なアラート構成の推奨事項を次に示します。
サービスの問題、計画メンテナンス、および正常性アドバイザリの種類の場合:
- 重要なワークロード - 重要なワークロードを強化するサブスクリプションとサービスのアラートをセットアップします。
- Azure Stack の基本サービスのアラートをセットアップします。
- 「ネットワーク インフラストラクチャ」 サービス - IaaS から SaaS までのあらゆる種類のワークロードとアプリケーションが依存する、Azure Stack の基本レイヤー。
- 「Microsoft Azure portal」 サービス - Azure Resources の管理に使用される基本サービス。 その多様性により、様々なシナリオを対象とする「キャッチオール」サービスとして位置付けられ、このサービスで伝達される概要エクスペリエンスに影響を与えます。
セキュリティ アドバイザリの種類の場合:
- すべての Azure サブスクリプションとサービス - 通常、悪意のある攻撃者は使用頻度の低いリソースをターゲットにするため、この種類のアラートがすべての Azure Resources を対象とすることが重要です
さらに、Azure Monitor ベースライン アラート ソリューションでは、自動または手動デプロイのオプションを備えた、プラットフォーム アラートのベースラインと、Azure 環境のポリシーとイニシアチブを介したサービス正常性アラートを実装するための包括的なガイダンスとコードを提供します。
次のロールに正しい連絡先情報があり、最新の状態を維持するために定期的に確認されるようにします。 詳細については、「Azure のセキュリティ問題に関する最新情報を入手する - Azure Service Health | Microsoft Learn」を参照してください。
サブスクリプション管理者およびサブスクリプション所有者 – サブスクリプション レベルで影響するセキュリティ問題に関する通知を (通信要件に応じて、Azure portal やメール経由で) 受信するために使用する連絡先。
テナントのグローバル管理者および技術部連絡先 – テナント レベルで影響するセキュリティ問題に関する通知を (通信要件に応じて、Azure portal やメール経由で) 受信するために使用する連絡先。
セキュリティ管理者 – セキュリティ ポリシーを確認および変更し、推奨事項を適用し、アラートを表示および無視できます。
固有の問題や今後のメンテナンス イベントについて従業員やシステムに通知できるように、固有の問題に関する最新情報を常に入手するには、正常性アラートまたは Scheduled Events の使用を検討してください。
Azure の通信原則を理解するには、「障害時のエクスペリエンス向上 - 自動化、通知、および透明性 | Azure ブログと更新情報 | Microsoft Azure」を参照してください。
セキュリティと回復性の態勢を強化して、インシデントの影響を潜在的に回避または最小限に抑える
データ、アプリケーション、その他の資産、特に次の資産を保護するための運用可能なセキュリティに関するベスト プラクティスを確認して実装します。
多要素認証を適用して、露出に関する懸念を軽減します。
{リスクの高いユーザーにアラートを実装します。 条件付きアクセスを構成して、環境内に「危険なユーザー」が存在する場合に確実に通知されるようにします。
ディレクトリとの間のサブスクリプションの移動を制御します。 ガバナンスを目的として、グローバル管理者は、ディレクトリ ユーザーが組織内で不明なディレクトリを変更することを許可または禁止できます。 これにより、組織は組織のディレクトリで使用されているサブスクリプションを完全に把握できるようになり、不明なディレクトリへのサブスクリプションの移動を防ぐことができます。
Azure Well-Architected フレームワーク (WAF) とレビューを使用して、重要なワークロードの信頼性、セキュリティなどを最適化します。 WAF での作業を補完するために、以下のアクションも考慮してください。
Azure Advisor ブレードの下の Azure portal に統合されている信頼性ワークブックを利用して、アプリケーションの信頼性の状況を確認し、リスクを評価し、改善を計画します。
ビジネス継続性とディザスター リカバリー (BCDR) のために、リージョン間でワークロード/ のデプロイを拡張します。 公開されている Azure リージョン ペアの完全なリストを使用します
可用性ゾーン全体のリージョン内でワークロード/ のデプロイを拡張します。
ビジネス クリティカルなワークロードについては、Azure における VM の分離性 - Azure 仮想マシン | Microsoft Learn を検討します
多くの Azure 仮想マシンの更新を制御および管理できるようにするには、メンテナンス構成を検討します
Azure Chaos Studio を使用して、Azure アプリの回復性を評価します。 実際またはシミュレートされた、制御された障害に Azure アプリを適用し、アプリケーションの回復性と、ネットワーク待ち時間、ストレージの停止、シークレットの期限切れ、データセンターの停止などの中断に対する応答を監視します。
Azure Advisor ブレードの下の Azure portal に統合されているサービス廃止ワークブックを、サービス廃止を示す単一の一元的なリソース レベルのビューとして利用します。 これは、影響の評価、オプションの評価、廃止されるサービスや機能からの移行の計画に役立ちます。
Azure の Advancing Reliability ブログをフォローして、継続的な回復性の取り組みに関する Azure の取り組みの最新情報を入手してください。
インシデント中
主要なサブスクリプションがインシデントの影響を受ける場合、このインシデントに関連する関連情報をどこでどのように参照できるかを知っておくことが重要です。
Azure portal で Azure Service Health アラートを確認して、エンジニアからの最新の更新情報を確認します。
- 「インシデントの前に」セクションに記載している特定のロールの連絡先 (サブスクリプション管理者/所有者、技術部連絡先/プライバシーに関する連絡先、テナント管理者など) も、セキュリティまたはプライバシー インシデントに関するメール通知を受信する可能性があることに注意することが重要です。
ポータルへのアクセスに問題がある場合は、バックアップとして publicAzure 状態ページ azure.status.microsoft を確認します。
状態ページに問題がある場合は、「X」(旧称 Twitter) の @AzureSupport で更新情報を確認します。
パブリック状態ページではなく Service Health を使用する理由
多くの顧客は、潜在的な問題の最初の兆候が現れると、公的にアクセス可能な状態ページ (azure.status.microsoft など) をチェックして、クラウド サービスに既知の問題があるかどうかを確認します。 これらのページには、 特定の条件を満たす広範な問題のみが表示され、顧客に影響を与えるインシデントは少なくなります。
Azure Service Health (Azure portal 内) は、管理しているサブスクリプションとテナントを認識しているため、停止に影響を与える既知の問題をより正確に表示します。 ままた、自動的に通知を受信できるように、アラートを構成することもできます。
サポート ケースを開くと役立つ場合
サービス インシデントがサービス正常性経由で既に通知されている場合は、すべての最新情報がここで提供されるため、サポート要求を開く必要はありません。 サービス インシデントの影響を受けていると思われるが、サービス正常性ページに問題が表示されない場合は、サポート要求を開いてください。
受信したセキュリティ問題に関する資料に記載されていない質問がある場合は、追跡 ID を参照してサポート要求を開いてください。
インシデントの後
Azure Service Health の [正常性の履歴] ウィンドウから (または顧客が構成した Service Health アラート経由で) インシデントの事後レビュー (PIR) を読み、学習した内容を理解します。
パブリックの [状態] ページの条件を満たした重大なインシデントについては、Azure インシデントの振り返りライブストリームに参加して質問の回答を得るか、録画をご覧ください。
SLA クレジットの対象となる可能性があると思われる場合は、問題の種類が「払い戻し要求」の新しいサポート要求を作成し、インシデント追跡 ID を含めます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示