Azure エンクレーブのベスト プラクティス

この記事では、Azure エンクレーブの主要な概念とベスト プラクティスについて説明します。

Azure エンクレーブは、セキュリティで保護され、分離され、準拠しているクラウド環境のデプロイと管理を加速し、合理化します。 これらの環境は、商用環境とエアギャップ環境全体で最も機密性の高いミッションとワークロードを処理するように設計されています。

Azure エンクレーブでワークロードを正常に構築して実行するには、次のようないくつかの重要な概念を理解して実装する必要があります。

Azure エンクレーブ製品グループ、エンジニアリング チーム、フィールド チームは、次のベスト プラクティスと概念に関する記事を作成しました。 この記事は、コミュニティとエンクレーブの所有者と開発者が重要な概念をより深く理解し、適切な機能を実装するのに役立つよう作成されました。

Azure のセットアップ

これらのセットアップ手順を読んで、これらの構成手順がAzureエンクレーブのユース ケースに適合するかどうかを判断します。

Network Watcher のリソース グループを構成する

仮想ネットワーク フロー ログの作成に関する潜在的な問題を回避するには、NetworkWatcherRG リソース グループを事前に手動で設定し、Mission Enclave アプリにそのリソース グループのOwner ロールを割り当てるか、サブスクリプションに最初のエンクレーブを作成する前に、セットアップとロールの割り当てが自動的に発生したことを確認します。

この潜在的な問題を軽減するには、サブスクリプションごとに、新しいサブスクリプションで NetworkWatcherRG という名前の NetworkWatcher リソース グループを手動で作成し、NetworkWatcherRG で Mission Enclave Azure エンクレーブ アプリ Ownerを付与します。

  1. NetworkWatcherRGリソース グループを選択し、Access control (IAM)を選択してから、Addを選択してAdd role assignmentします。

ポータルでのリソース グループの [ロールの追加] の選択を示すスクリーンショット。

  1. Privileged administrator roles選択し、ownerを選択してから、Nextを選択します。

ポータルの [所有者ロールの追加] 選択ビューを示すスクリーンショット。

  1. Select members選択し、検索に「Mission Enclave」と入力し、Mission Enclave アプリを選択し、[Select] を選択してから、Nextします。

ポータルでミッション エンクレーブ アプリを選択する方法を示すスクリーンショット。

  1. サブスクリプションに条件が必要な場合は、[ Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended)] を選択し、[ Review + assign] を選択します。

サブスクリプションで必要な場合に条件の追加ビューを示すスクリーンショット。

  1. 更新が完了したら、エンクレーブ リソースAzureデプロイを開始できます。

コミュニティまたはエンクレーブが作成されると、Azureエンクレーブは次の手順を試みます。

  1. NetworkWatcherRGが存在するかどうかを確認します。 そうでない場合は、そのリソース グループの作成を試みます。
  2. Mission Enclave に Owner アプリの永続的な NetworkWatcherRG 割り当てがあるかどうかを確認します。 そうでない場合は、Mission Enclave の永続的な Owner 割り当てとして NetworkWatcherRG アプリを割り当てるようにします。 継承された Owner アクセス許可が存在する場合でも、永続的な Owner 割り当ての作成が試行されます。
  3. いずれかの手順が失敗した場合、仮想ネットワーク フロー ログを作成しようとしたときにエンクレーブデプロイが失敗する可能性があります。

Azure Enclaveのネットワークおよび組織デザインパターン

マルチテナンシー

ネットワーク設計

Azure エンクレーブは、次のような簡素化されたユーザー インターフェイスで、複数のAzure ネットワーク製品の機能と柔軟性を実現します。

  • Azure Virtual WAN
  • Azure Firewall
  • Azure 仮想ネットワーク
  • ネットワーク セキュリティ グループ

Azure Enclave では、全体として次のことを推奨しています:

  • Azure Firewallを提供するためのネットワーク要件がある場合は、コミュニティをデプロイする必要があります。これは、Azureのインテリジェントなファイアウォール セキュリティであるサービスとしてのプラットフォームです。
  • ハブアンドスポーク Virtual WANを別のハブ アンド スポーク Virtual WANから分離するために、組織またはデータの秘密度の要件がある場合は、コミュニティをデプロイする必要があります。
  • 複数のAzure リージョンにまたがるシステムをサポートするためのネットワーク要件がある場合は、コミュニティをデプロイする必要があります。各リージョンには独自のAzure Firewallが必要です。 マルチハブ Azure Firewallユース ケースの詳細について説明します。
  • 分散ハブアンドスポークのワイド エリア ネットワークで多数のシステムをサポートするためのネットワーク要件がある場合は、コミュニティをデプロイする必要があります。 詳細については、Azure Virtual WANを参照してください。
  • 同じプライベート ネットワークの一部として同様のワークロードをデプロイするためのネットワーク要件がある場合は、エンクレーブをデプロイする必要があります。
  • 仮想ネットワークを必要とするワークロード要件があり、既存のコミュニティと同じVirtual WAN内にある場合は、エンクレーブをデプロイする必要があります。

コミュニティ ネットワークの設計に関する考慮事項

コミュニティ ネットワークを計画するときは、可能な限り、Azure サービスのベスト プラクティスに関するドキュメントに従う必要があります。 次のベスト プラクティスを含めます。

エンクレーブ ネットワークの設計に関する考慮事項

エンクレーブ ネットワークを計画するときは、可能な限り、Azure サービスのベスト プラクティスに関するドキュメントに従う必要があります。 次のベスト プラクティスを含めます。

全体的なAzure ネットワークのベスト プラクティスについて説明します。

ワークロードをデプロイする

  • ワークロードは、エンクレーブ共同作成者がリソースAzureデプロイできるマネージド リソース グループにリンクされます。
  • 既定では、すべてのAzureエンクレーブ ワークロードは、組み込みのAzure Policy イニシアチブによって管理されます
  • カスタム ガバナンス設定を持つコミュニティに関連付けられているワークロードでは、既定の Azure エンクレーブ ガバナンス構成ではなく、この一意の構成を使用します。
  • Azure リソースの名前付けに関する考慮事項

Azure エンクレーブのセキュリティ設計パターン

Azure エンクレーブ環境を設計するときは、これらのセキュリティ設計パターンを検討してください。

セキュリティの境界

Azure エンクレーブは、サイバーセキュリティに関しては多層防御アプローチを採用しています。 コミュニティとエンクレーブをデプロイすると、Azure エンクレーブによって、ネットワーク分離、セキュリティ、アクセス制御、およびログ記録と監視のいくつかのレイヤーが確立されます。

共有セキュリティの責任

Azureのサービスとして、Azure Enclave はクラウドでの共同責任モデルの維持にも取り組んでいます。 Azure Enclave については、ワークロードはお客様の責任です。 PaaS サービスをワークロードにデプロイした場合、Azure共有責任はワークロードで継承されます。

お客様のコミュニティとエンクレーブは、共有責任の対象です。 コミュニティとエンクレーブは共有責任モデルを使用します。ここで、Azureエンクレーブ リソース プロバイダーは、セキュリティで保護された事前構成済みのハブアンドスポーク ネットワーク環境を作成します。 このネットワーク環境を管理するには、 エンクレーブ エンドポイント、 コミュニティ エンドポイント、 トランジット ハブ、または エンクレーブ接続を作成します。 Azure エンクレーブの特定のプレビュー バージョンでは、Azure Virtual WAN、Azure Virtual Network、およびその他の基になるAzure ネットワーク サービスによって提供される基になるコントロールを使用して、ネットワークを手動で変更することもできます。

Azureエンクレーブ ガバナンスも共有責任です。 Azure エンクレーブ リソース プロバイダーは、ワークロードのデプロイごとに、セキュリティで保護された構成済みのAzure Policyイニシアチブの一覧を作成します。 ただし、コミュニティにはコミュニティ Azure Policy イニシアティブをカスタマイズする機能が追加されました。これにより、ワークロードの構成済みリストがオーバーライドされます。 ポリシー要件にもかかわらず、コンプライアンスまたはガバナンスの要件に応じて、これらのAzure Policyイニシアティブの割り当てを手動で除外する機能を保持します。

Azure セキュリティのベスト プラクティス

Azure エンクレーブでは、Azure リソースのデプロイとワークロードの実装に関するMicrosoft Azureセキュリティのベスト プラクティスとパターンに従うことをお勧めします。

Azureセキュリティのベスト プラクティス (システム、クラウド インフラストラクチャ、IT 担当者とチーミング構造、企業のサイバーセキュリティ意識トレーニングを整理するためのクラウド導入フレームワーク) に従う必要があります。

ドメイン ネーム システムを使用したデータ流出

ドメイン ネーム システム (DNS) を介したデータ流出は、通常はファイアウォール経由で許可され、悪意のあるアクティビティをほとんど監視しないプロトコルを使用しているため、組織にとって重大なセキュリティ上の懸念事項です。 攻撃者は DNS クエリを悪用し、ドメイン名内の情報をエンコードするか、DNS トンネリング手法を使用して、侵害されたシステムから機密データを密かに抽出することができます。 DNS トラフィックは正当に見え、多くの場合、従来のセキュリティ監視ツールをバイパスするため、この方法は陰湿です。

DNS ベースのデータ流出攻撃では、悪意のあるアクターは、多くの場合、サブドメイン のラベル付けや TXT レコード クエリなどの手法を使用して、盗まれたデータを DNS クエリにエンコードします。 たとえば、攻撃者は機密データをチャンクに分割し、各チャンクをサブドメインとして DNS クエリに攻撃者が制御するドメインに埋め込む可能性があります。 攻撃者の DNS サーバー上の DNS ログからデータを抽出できます。 この方法では、DNS クエリが通常の名前解決要求として表示されるため、低プロファイルを維持しながら大規模なデータセットを段階的に流出できます。

Azure DNS セキュリティ ポリシーを使用したデータ流出への対処

Azure DNS セキュリティ ポリシーは、Azure仮想ネットワーク内の DNS トラフィックをきめ細かく制御することで、DNS ベースのデータ流出攻撃に対する包括的な保護を提供します。 このサービスを使用すると、組織は、データを正常に流出させる前に、疑わしい DNS アクティビティを検出、アラート、ブロックできるプロアクティブなセキュリティ対策を実装できます。

Azure DNSセキュリティ ポリシーは、いくつかの重要なメカニズムを通じて DNS データ流出に対処します。 まず、既知の悪意のあるドメインまたは流出の試行でよく使用される疑わしいドメイン パターンへのクエリをブロックできる DNS トラフィック ルールを作成する機能を提供します。 組織は、コマンドおよび制御インフラストラクチャまたはデータ流出サービスに関連付けられているドメインのブロック リストを維持できます。 次に、このサービスは、保護された仮想ネットワーク内のすべての DNS クエリと応答をキャプチャする包括的な DNS ログ機能を提供します。 このログ記録により、セキュリティ チームは DNS トラフィック パターンを分析し、流出の試行の可能性を特定できます。 3 つ目は、ポリシー エンジンがワイルドカード ドメイン フィルタリングをサポートしているため、組織は疑わしいドメインのカテゴリ全体をブロックしたり、承認された DNS 宛先の許可リストを実装したりできます。

Azure DNSセキュリティ ポリシーの実装により、DNS データ流出に対する防御レイヤーが複数作成されます。 トラフィック ルールは、さまざまな優先度レベルで構成できるため、セキュリティと運用要件のバランスを取る複雑なセキュリティ ポリシーを実現できます。 このサービスでは、悪意のあるクエリをリアルタイムでブロックしながら、フォレンジック分析と脅威ハンティングの詳細なログを提供します。 さらに、仮想ネットワーク リンクにより、保護されたネットワーク セグメント内のすべてのリソースに DNS セキュリティ ポリシーが一貫して適用され、攻撃者がバイパスするのが困難な包括的なセキュリティ境界が作成されます。

Azure Enclave のデプロイでは、Azure DNS Security Policy をセキュリティ アーキテクチャ全体の一部として統合する必要があります。 組織は、エンクレーブ ワークロードからの DNS トラフィックを監視および制御するように DNS セキュリティ ポリシーを構成し、個々のワークロードが侵害された場合でも機密データを保護する必要があります。 DNS ドメイン リストの定期的なレビューと更新は、DNS ログの継続的な監視と組み合わせることで、進化する DNS ベースの脅威に対する継続的な保護を提供し、Azureエンクレーブ環境のセキュリティ整合性を維持するのに役立ちます。

詳細については、 DNS セキュリティ ポリシーのドキュメントを参照してください。

既定で拒否される DNS セキュリティ ポリシーの実装

Azureエンクレーブ環境でセキュリティを最大限に高めるために、組織は DNS フィルタリングに対して "既定で拒否、例外で許可する" アプローチを実装する必要があります。 このセキュリティ モデルにより、明示的に許可されない限り、すべての DNS クエリがブロックされ、DNS ベースのデータ流出とコマンド アンド コントロール通信に対する最も強力な保護が提供されます。

デフォルト拒否アプローチは、Azure DNS Security Policy 内の 2 層の DNS ルール構造を使用して実装されます。

手順 1: 既定の拒否規則を作成する ルート ドメイン . (ドット) のみを含む DNS ドメイン リストを作成します。 このワイルドカード ドメインは、考えられるすべての DNS クエリと一致します。 このドメイン リストを、次の設定で構成された DNS トラフィック ルールに関連付けます。

  • 優先度: 65000 (最も低い優先度)
  • アクション: ブロック
  • ドメイン 一覧: ルート ドメイン (.)

この規則は、優先度の高い規則で明示的に許可されていない DNS クエリをブロックするキャッチオールとして機能します。

手順 2: 許可リストルールを作成する 正当なビジネス操作に必要な特定のドメインを含む個別の DNS ドメイン リストを作成します。 たとえば、次のようなものがあります。

  • 重要なAzure サービス (*.azure.com、*.microsoft.comなど)
  • 企業ドメインと信頼できる Microsoft 以外のサービス
  • オペレーティング システムの更新サービス
  • 証明機関ドメイン

次を使用して構成された DNS トラフィック ルールに許可リストを関連付けます。

  • 優先度: 500 から 1000 (既定の拒否よりも高い優先度)
  • アクション: 許可
  • ドメイン リスト: 特定の承認済みドメイン

セキュリティ ポリシー Azure DNS優先度ベースのルール処理では、規則が優先順位で処理されます (数値が小さい = 優先度が高い)。 DNS クエリが作成された場合:

  1. システムは、最初に優先度の高い許可規則を評価します (優先度 500 から 1000)
  2. ドメインが許可リストと一致する場合、クエリは許可されます
  3. allowルールが一致しない場合、クエリは既定の拒否規則 (優先度 65000) に分類され、トラフィックはブロックされます

この方法には、いくつかのセキュリティ上の利点があります。

  • ゼロ トラスト モデル: 明示的に承認されていない限り、DNS クエリは許可されません
  • きめ細かい制御: 組織は、アクセス可能なドメインを正確に制御できます
  • 監査証跡: ブロックされたすべてのクエリがログに記録され、潜在的な脅威を可視化します
  • 増分更新: 新しい承認済みドメインを追加して、既定の拒否規則を変更せずにリストを許可できます

実装例:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

このアプローチを実装する組織は、必要なドメインの包括的なインベントリから開始し、運用ニーズとセキュリティ ログに基づいて許可されるドメインの一覧を徐々に絞り込む必要があります。 ブロックされたクエリを定期的に確認すると、強力なセキュリティ体制を維持しながら、許可リストに追加する必要がある正当なドメインを特定できます。

Windows DNS サーバーを使用した既定の DNS ポリシーの拒否の実装

Azure DNSセキュリティ ポリシーを利用できない環境や、オンプレミスの DNS 制御が必要な環境では、DNS ポリシー機能を備えた Windows DNS サーバーを使用して、同様の既定の拒否セキュリティを実装できます。 このアプローチでは、既存のWindows インフラストラクチャとの互換性を維持しながら、DNS ベースのデータ流出に対して同等の保護が提供されます。

Windows DNS サーバー (Windows Server 2016 以降) では、組織が高度な DNS フィルター規則を実装できるようにする DNS ポリシー機能がサポートされています。 既定による拒否モデルは、 DNS ポリシー規則 とゾーン構成の組み合わせを使用して実現できます。

Azure エンクレーブ内のマネージド リソース グループ

Azure エンクレーブによって管理されるリソースを含むリソース グループ。

コミュニティで管理されるリソース グループ

Community マネージド リソース グループには、「コミュニティとは」で説明されているインフラストラクチャ リソースが含まれています。

コミュニティ マネージド リソース グループ名は、 myCommunityName-HostedResources-<GUID>という名前付け規則に従います。 すべてのコミュニティ デプロイでは、このリソース グループが作成され、その中にコミュニティ インフラストラクチャが配置されます。 コミュニティを削除すると、Azure エンクレーブ リソース プロバイダーによってコミュニティマネージド リソース グループが自動的に削除されます。

Azure エンクレーブによって管理されているコミュニティ リソースの例を示すスクリーンショット。

コミュニティ マネージド リソース グループには、次の制限があります。

  • コミュニティマネージドリソースグループに既存のリソースグループを指定することはできません。
  • コミュニティマネージドリソースグループに別のサブスクリプションを指定することはできません。
  • コミュニティの作成後に、コミュニティで管理されるリソース グループ名を変更することはできません。
  • コミュニティ マネージド リソース グループ内のマネージド リソースの名前を指定することはできません。
  • コミュニティ マネージド リソース グループ内Azure作成されたマネージド リソースのタグを変更または削除することはできません。

コミュニティ マネージド リソース グループAzure作成されたタグ、リソース、およびその他のリソース プロパティを変更または削除すると、予期しない結果が表示される可能性があります。 Azureエンクレーブがコミュニティ マネージド リソース グループ内のインフラストラクチャのライフサイクルを管理する場合、変更によってエンクレーブがサポートされていない状態に移行する可能性があります。

リソースを変更する一般的なシナリオは、タグを使用することです。 Azure エンクレーブを使用すると、コミュニティマネージドリソースグループ内のリソースに伝達されるタグを作成および変更できます。 たとえばビジネス単位やコスト センターを割り当てるために、カスタム タグを作成または変更することがあります。 これは、コミュニティマネージドリソースグループのスコープを持つAzureポリシーを作成することによっても実現できます。

Note

コミュニティマネージドリソースグループのロックダウンを有効にしていない場合は、コミュニティマネージドリソースグループ内の任意のリソースを直接変更できます。 コミュニティで管理されているリソース グループ内のリソースを直接変更すると、エンクレーブが不安定になったり、応答しなくなる可能性があります。

マネージド リソース グループをエンクレーブする

エンクレーブ マネージド リソース グループには、「エンクレーブとは」で説明されているインフラストラクチャ リソースが含まれています。

エンクレーブ マネージド リソース グループ名は、 myEnclaveName-HostedResources-<GUID>という名前付け規則に従います。 すべてのエンクレーブ デプロイでは、このリソース グループが作成され、その中にエンクレーブ インフラストラクチャが配置されます。 エンクレーブを削除すると、Azure エンクレーブ リソース プロバイダーによってエンクレーブマネージド リソース グループが自動的に削除されます。

Azure エンクレーブによって管理されているエンクレーブ リソースの例を示すスクリーンショット。

エンクレーブ マネージド リソース グループには、次の制限があります。

  • エンクレーブ マネージド リソース グループに既存のリソース グループを指定することはできません。
  • エンクレーブ マネージド リソース グループに別のサブスクリプションを指定することはできません。
  • エンクレーブの作成後にエンクレーブ マネージド リソース グループ名を変更することはできません。
  • エンクレーブ マネージド リソース グループ内のマネージド リソースの名前を指定することはできません。
  • エンクレーブ マネージド リソース グループ内Azure作成されたマネージド リソースのタグを変更または削除することはできません。

エンクレーブマネージド リソース グループAzure作成されたタグ、リソース、およびその他のリソース プロパティを変更または削除すると、ネットワーク、アクセス、監視エラーなどの予期しない結果が得られる可能性があります。 エンクレーブAzureエンクレーブがエンクレーブ マネージド リソース グループ内のインフラストラクチャのライフサイクルを管理する場合、変更によってエンクレーブがサポートされていない状態に移行する可能性があります。

リソースを変更する一般的なシナリオは、タグを使用することです。 Azure エンクレーブを使用すると、エンクレーブ マネージド リソース グループ内のリソースに伝達されるタグを作成および変更できます。 たとえばビジネス単位やコスト センターを割り当てるために、カスタム タグを作成または変更することがあります。 リソースタグ付けは、エンクレーブマネージドリソースグループのスコープを持つAzureポリシーを作成することによっても実現できます。

Warning

エンクレーブ マネージド リソース グループ内のリソースを変更すると、エンクレーブが不安定になったり、応答しなくなる可能性があります。

ワークロード リソース グループ

ワークロードは、Azure リソースを作成および整理できる 1 つ以上のリソース グループにリンクされています。

ワークロードにリソース グループを追加する

通常、新しいリソース グループを追加するには、ユーザーに新しいリソース グループを作成するためのアクセス許可が必要です。 サブスクリプション Owner ロールまたは Contributor ロールにはこのアクセス許可がありますが、ワークロード リソース グループを作成しているユーザーには、この特権アクセス許可がない、または必要な場合があります。 Azure エンクレーブは、ユーザーのアクセス許可の要件が最も高いものから最も低いものまで、新しいリソース グループを作成する 3 つの方法を試み、ユーザーに柔軟性を提供します。

  • オプション 1: ワークロードを作成または更新する個人に対して最も特権の高いアクセス許可が必要です。完全な制御を提供しますが、昇格されたアクセスが必要です。
  • オプション 2: サブスクリプション レベルで Mission Enclave アプリケーションの所有権を付与するようにユーザーが手動で設定する必要があります。これは、ユーザーの設定と一致しない可能性があります。
  • オプション 3: ユーザーまたは Mission Enclave アプリケーションに対するアクセス許可は必要ありません。最も簡単な方法ですが、リソース グループとワークロードの間に厳密な 1 対 1 の関係を課します。

各オプションには、さまざまなニーズに合わせた利点と制限、バランス制御、利便性、柔軟性があります。 これらのオプションはそれぞれオプション 1 から評価され、成功する最初のオプションを使用して新しいリソース グループが作成されます。

オプション 3 を使用して 1 つのワークロード リソース グループを作成すると、そのワークロードの次のワークロード リソース グループにオプション 3 を使用できないという警告が表示されます。 また、オプション 3 をもう一度使用して、新しいワークロードを作成してから、新しいワークロード リソース グループを作成することもできます。

リソース グループをエンクレーブに追加します。

  1. ワークロードのAzure ポータル ページを開きます。
  2. Manageを選択し、Resource Groupsします。
  3. Add a resource group を選択します。
  4. 開いたサイド ウィンドウで、 Create new を選択して新しい空のリソース グループの名前を指定するか、 Resource Group ドロップダウンを選択して既存のリソース グループを選択します。
  5. OKを選択し、Saveします。

ワークロード リソース グループと他のAzure リソース グループの違い

ワークロード リソース グループは、重要なリソースが作成される場所であるため、Azureエンクレーブのセキュリティとコンプライアンスの重要なコンポーネントです。 これらのワークロード リソース グループはワークロードにリンクされ、ワークロードはエンクレーブにリンクされているため、Azure エンクレーブはワークロードマネージド リソース グループの削除を管理します。

さらに、ポリシーはワークロード リソース グループに適用されます。 コミュニティ ポリシーがエンクレーブに流れるのと同様に、エンクレーブ ポリシーは ワークロード リソースと ワークロード リソース グループに送られます。 新しいワークロード リソース グループを作成すると、ロールはエンクレーブ レベルで設定され、サブスクリプションから継承されます。 これらのポリシーの一部はコミュニティから継承されており、エンクレーブ上で、ワークロードおよびワークロード リソース グループに適用されるポリシーを作成することもできます。

ワークロード リソース グループ内のリソースの整理

リソースを 2 つのリソース グループに分割する場合は、次のいずれかのオプションを選択できます。

  • 1 つのワークロードにリンクされた 2 つのリソース グループ間でそれらのリソースを分割する
  • 1 つ以上のリソース グループを持つ 2 つのワークロード間でこれらのリソースを分割する

ワークロードの削除

ワークロードの削除が要求されると、ワークロード リソース グループが空であることを確認するためにチェックされます。 ワークロード リソース グループにリソースが含まれている場合、要求されたワークロードの削除は失敗し、エラーが表示されます。 ワークロードとワークロード リソース グループを削除するには、まずワークロード リソース グループを空にします。 空のワークロード リソース グループは、重要なリソースが誤って削除されるのを防ぐのに役立ちます。

ワークロードにリンクされているリソースの削除は、同じ動作に従います。 たとえば、コミュニティの削除が要求されても、すべてのワークロード リソース グループが空でない場合、操作にはエラーが表示されます。 ワークロード リソース グループを空にして、もう一度やり直してください。

ワークロード管理リソース グループには、次の制限があります。

  • ワークロード管理リソース グループに既存のリソース グループを指定することはできません。
  • ワークロードで管理されるリソース グループに別のサブスクリプションを指定することはできません。
  • ワークロードの作成後に、ワークロード管理リソース グループ名を変更することはできません。
  • ワークロード マネージド リソース グループ内のマネージド リソースに対する、Azure によって作成されたタグは変更または削除できません。

リソースを変更する一般的なシナリオは、タグを使用することです。 Azure エンクレーブを使用すると、ワークロード管理リソース グループ内のリソースに伝達されるタグを作成および変更できます。 たとえばビジネス単位やコスト センターを割り当てるために、カスタム タグを作成または変更することがあります。 タグ付けは、ワークロードマネージドリソースグループのスコープを持つAzureポリシーを作成することによっても実現できます。

その他のAzureのベスト プラクティス

Azureでコミュニティ、エンクレーブ、ワークロードを構築するときは、次のユニバーサル 設計原則に留意することが重要です。

  • Last updated on