次の方法で共有

Microsoft Defender for Cloud DevOps のセキュリティの信頼性について

  • [アーティクル]

この記事では、Microsoft Defender for Cloud DevOps のセキュリティ機能の信頼性のサポートについて説明します。これには、リージョン間の復旧とビジネスの継続性が含まれます。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

この記事は、リージョンが停止した場合の復旧に特化して記述しています。 既存の DevOps コネクタを新しいリージョンに移動しようとしている場合は、「Defender for DevOps に関する一般的な質問」を参照してください

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

Microsoft Defender for Cloud DevOps のセキュリティでは、単一リージョンのディザスター リカバリーがサポートされています。 そのため、複数リージョンのディザスター リカバリー プロセスでは、このドキュメントに記載されている単一リージョンのディザスター リカバリー プロセスを実装するだけです。

サポートされているリージョン

Defender for Cloud で DevOps セキュリティをサポートするリージョンについては、「DevOps セキュリティ リージョン サポート」を参照してください。

単一リージョンのディザスター リカバリー プロセス

DevOps セキュリティ機能の単一リージョンのディザスター リカバリー プロセスは、共有責任モデルのに基づいているため、お客様と Microsoft の両方の手順が含まれます。

顧客の責任

あるリージョンがダウンすると、そのリージョンのコネクタの構成が失われます。 失われた構成には、お客様トークン、自動検出構成、ADO 注釈の構成などが含まれます。

ダウンしたリージョンに作成されたコネクタの復旧を要求するには、次のようにします。

  1. 新しいリージョンに新しいコネクタを作成します。 Azure DevOps、GitHub、GitLab のオンボード ドキュメントを参照してください。

    Note

    新しいリージョンでの既存のコネクタの使用は、古いコネクタでの DevOps リソースのスコープへのアクセス権が認証されていれば可能です。

  2. 新しいサポート要求を開き、古いコネクタから DevOps リソースの所有権をリリースします。

    1. Azure portal で [ヘルプとサポート] に移動します
    2. 以下をフォームに入力します。
      1. 問題の種類: Technical
      2. サービスの種類: Microsoft Defender for Cloud
      3. 概要: "リージョンの停止 - DevOps コネクタの復旧"
      4. 問題の種類: Defender CSPM plan
      5. 問題のサブタイプ: DevOps security

  3. 新規の DevOps コネクタと古い DevOps コネクタのリソース ID をコピーします。 この情報は Azure Resource Graph で入手可能です。 リソース ID の形式: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/securityConnectors/{connectorName}

    Azure Resource Graph Explorer を使用して、次のクエリを実行してリソース ID を見つけることができます。

    resources
 | extend connectorType = tostring(parse_json(properties["environmentName"]))
 | where type == "microsoft.security/securityconnectors"
 | where connectorType in ("AzureDevOps", "Github", "GitLab")
 | project connectorResourceId = id, region = location

  4. DevOps リソースが古いコネクタからリリースされ、新しいコネクタ用に表示されたら、必要に応じて pull request の注釈を再構成します。

  5. 新しいコネクタがプライマリになります。 リージョンが停止から復旧したら、古いコネクタを安全に削除できます。

Microsoft の責任

リージョンがダウンして、新しいコネクタが確立されている場合には、Microsoft では古いコネクタから新しいコネクタにすべてのアラート、推奨事項、Cloud Security Graph エンティティを再作成します。

重要

Microsoft では、以前の実行からのコンテナー マッピング データ、1 週間以上前のアラート データ、コードとしてのインフラストラクチャ (IaC) マッピング履歴データなどの、一部の機能の履歴を再作成しません。

ディザスター リカバリー プロセスをテストする

ディザスター リカバリー プロセスをテストするには、2 つ目のコネクタを作成し、上記のサポート手順に従って、失われたコネクタをシミュレートできます。

次のステップ

この記事で説明した項目の詳細については、次を参照してください。

Azure での信頼性